SLICE-005: CI and Quality Gates

• Status: Proposed
• Date: 2026-04-22
• Depends on: Requirements, Evolution Roadmap

Goal

Give the repository a stable, enforced build-and-test baseline so that every later slice — especially the Phase 1 simulator-scaling work — can be measured against a known-good reference.

Why This Slice

The prototype has 216 passing tests and a clean layered design, but there is no automated gate. Regressions currently depend on the author running dotnet test locally before every commit. That is acceptable for a demo and unacceptable for any work whose purpose is to observe pressure and compare before-and-after numbers.

Without a green-build gate:

• Phase 1 "did the simulator scaling change the drop counter?" cannot be answered reproducibly
• Phase 2 "did slicing AppState make the hot path faster?" becomes vibes
• Warnings, dead code, and drift accumulate silently between slices

This slice is not about the yaml file. It is about removing "works on my machine" as a state the project is allowed to occupy.

Requirements Coverage

• 04. UI and Technical Requirements: automated test enforcement
• 07. AI Delivery Constraints and Roadmap: each slice must be verifiable by automation, not manual inspection

In Scope

• a GitHub Actions workflow at .github/workflows/ci.yml that runs restore, build, and test on push and pull request
• Directory.Build.props at repo root with TreatWarningsAsErrors=true and nullable enabled consistently across projects
• Directory.Packages.props at repo root with centralized package versions (central package management)
• .editorconfig at repo root capturing current formatting conventions
• coverage collection via coverlet.collector (or equivalent) and upload as a CI artifact
• a status badge in the root README (or equivalent) so the current build state is visible at a glance
• branch protection guidance documented, even if the GitHub setting itself is applied out-of-band

Out of Scope

• release pipelines, code signing, MSIX/installer production (deferred to Phase 4)
• deployment, publishing, or artifact distribution
• performance or benchmark gates (deferred to Phase 1)
• external coverage services (Codecov, Coveralls) — local artifact is sufficient for now
• pre-commit hooks, husky-style git hooks
• static analysis beyond what the Roslyn analyzers already emit

Runtime Behavior

This slice does not change application runtime behavior. It changes what the repository considers a valid state.

Build

• dotnet build at the solution root must succeed with zero warnings
• any new warning surfaced by analyzers fails the build
• package versions are declared once in Directory.Packages.props and referenced without versions in individual .csproj files

CI Workflow

• triggers: push to master, and every pull request
• steps: checkout, setup .NET 10, restore, build (--no-restore), test (--no-build), collect coverage, upload coverage artifact
• runs on windows-latest (WPF + .NET 10 desktop target)
• fails fast on first broken step
• total wall time under ~5 minutes for a clean run — longer CI runs get skipped by humans and defeat the purpose

Contributor Experience

• a failed CI run produces a red status on the PR; a PR without green CI cannot be merged
• the coverage artifact is downloadable from the workflow summary
• local dotnet build and dotnet test produce the same result as CI (no CI-only magic)

Acceptance Criteria

This slice is satisfied only if all of the following are true:

1. A push or pull request to the repository triggers a CI workflow that runs restore, build, and test, and reports pass or fail on the commit.
2. Directory.Build.props exists at repo root and enables TreatWarningsAsErrors and consistent nullable settings across all projects.
3. Directory.Packages.props exists at repo root and centralizes every package version; individual .csproj files reference packages without version attributes.
4. .editorconfig exists at repo root and captures at least indentation, newline, and trimming conventions used in the current codebase.
5. The CI workflow collects test coverage and uploads it as a workflow artifact.
6. Branch-protection expectations (CI must be green before merge) are documented in the repository — even if the actual GitHub setting is applied outside this slice.
7. A build or test regression introduced on a branch produces a visible red CI status on the corresponding pull request.
8. The current 216 tests continue to pass under the new build settings (warnings-as-errors does not silently disable anything load-bearing).

Verification Notes

The implementation task for this spec must include verification for:

• CI workflow actually runs on push and pull request (verified by opening a throwaway PR or checking the Actions tab)
• warnings-as-errors actually fails the build (verified by intentionally introducing an unused variable)
• central package management is real (verified by checking a .csproj contains no Version= attributes)
• coverage artifact appears on the workflow run summary
• existing tests continue to pass under new settings without suppression files