Release Cycle¶

This document defines the end-to-end release cycle for FCC — not just the packaging mechanics (which live in RELEASING.md), but the full hardening-and-validation loop that follows every release, culminating in a manual-UAT hand-off to the maintainer.

It is the default, expected path. It exists so the cycle is followed consistently rather than reconstructed from memory each time.

Governing principle — no silent deviation¶

The documented workflow below is the default. If a request appears to deviate from it — or if there is any temptation to shortcut a step (for speed, to work around a flake, or to act on an opportunistic find) — stop and get explicit maintainer validation before circumventing the workflow.

A terse instruction does not implicitly authorize skipping a standard step. When unsure whether something is a deviation, treat it as one and confirm. Asking is cheap; an unauthorized process change is not.

The cycle¶

A release has two halves: ship (packaging mechanics) and harden + validate (this document's focus).

commit → PR → push → build the release        ← RELEASING.md (packaging)
      → create the hardening patch
      → run AND extend automated UAT
      → build up the performance model
      → extend testing
      → run AI vision (qwen3-vl vision-diff)
      → fix all issues found, on the patch
      → stand up a build for MANUAL UAT        ← hand-off (below)

1. Ship the release¶

Follow RELEASING.md: version bump → changelog → PR → CI green → merge → GitHub Release → CI publishes (TestPyPI → PyPI). The package publish is irreversible — never cut the GitHub Release without explicit maintainer go-ahead.

2. Create the hardening patch¶

After a release — especially a minor or major — open the next patch (x.y.0 → x.y.1) as the vehicle for the hardening-and-validation work below. The feature/minor ships capability; the patch immediately following it is where validation deepens.

3. Run and extend automated UAT¶

Run the executable probe / UAT suite against the running services. Every cycle, extend it — add probes, journey-stream coverage, and tripwires. The goal is accumulation, not a static mirror: each pass leaves the automated suite stronger than the last.

4. Build up the performance model¶

Capture and refine the performance envelope (the Quick ≤250 ms / Moderate ≤2 s / Slow >2 s bands), recording API-layer and UI-layer implications. Track progress and regressions across patches.

5. Extend testing¶

Broaden unit/integration/contract coverage for whatever the release touched, at the standing 98 % line / 80 % branch gate (CI == Release).

6. Run AI vision¶

Run the qwen3-vl vision-diff baselines over the frontend and /admin surfaces. Track how vision coverage progresses and what it surfaces.

7. Fix all issues found — on the patch¶

Everything surfaced by steps 3–6 is fixed on the hardening patch before hand-off.

8. Stand up a build for manual UAT — the hand-off¶

Stand up a running build for the maintainer's manual UAT. The hand-off is not just "here's a build" — it must report:

Manual validation guide — the specific flows the maintainer should walk through by hand.
Automated UAT — what was extended this cycle (new probes / streams / tripwires), and current pass state.
Performance model — progress, new measurements, and any regressions or issues in the envelope.
AI vision — how vision-diff coverage is progressing and what it found.

Current status (as of v1.9.x)¶

The automated-UAT / performance-model / AI-vision machinery does not exist yet — it is the Phase 2 (v1.10.0) build-out (executable make uat-probe, three journey streams, performance bands, cross-surface tripwires, FCC-native Playwright + qwen3-vl vision-diff). FCC's own service ports are still being stood up there.

Therefore:

Phase 2 (v1.10.0) performs the initial build-out of the machinery and produces the first manual-UAT hand-off.
From v1.10.0 onward, the per-release patch → (run + extend UAT / perf / vision) → fix → manual-UAT hand-off cadence is standing practice after every minor/major.
Earlier patches (e.g. v1.9.1) are scoped hardening patches that do not yet run the full validation loop, because there is nothing to run until Phase 2 builds it.

See ROADMAP.md for the phased plan.