Refine CI workflow (stages, sharding, paths-filter, coverage gates)

[tayebmokni]

Summary

Refine the CI workflow per §15: lint → unit → integration/contract → e2e → publish, with security and a11y in parallel. Stage gating uses make targets (make test-unit, make test-int, make test-e2e) so the workflow stays tool-portable. Sharding via gotestsum --packages=... × 4 runners and Vitest --shard=k/n. Path-filter-based affected-package selection on PR, full suite on main.

Design reference

• docs/11-testing-ci.md §15 (CI Pipeline Structure)

Acceptance criteria

• .github/workflows/ci.yml matches the §15.1 staging diagram
• Required stages per §15.2: lint, unit, integration, contract (api/plugin/theme), e2e, security static, a11y
• Informational stages: security dynamic (weekly), perf (nightly on main / required on perf/* branches), mutation, visual regression
• Sharding: Go integration across 4 runners via gotestsum; Vitest --shard=k/n; Playwright 4 workers × 2 machines
• Paths-filter affected-package selection on PR; full suite on main
• Conservative rule: any change to internal/plugin/..., internal/policy/..., internal/migrations/..., openapi.yaml, or GraphQL schema triggers the full suite regardless
• Artifact retention: JUnit XML 30d, coverage 30d (latest pinned on main), Playwright traces 14d, k6 reports 90d
• Self-hosted runners (ARC-managed on EKS) for e2e and load
• Coverage gate per §3.5: 80% domain, 75% store, 85% + 100% capability matrix for plugin, 60% overall

Dependencies

#232, #240, #241

Complexity

L

[tayebmokni]

Closing — shipped in the final-wave PR (#487-#492). Auto-close only fires for first ref.