CICDv2 rollback playbook — retired

There is no cicd_v2 rollback procedure any more. This page used to document how to flip the cicd_v2 feature flag back (per-tenant or cluster-wide) after promoting a fleet onto the v2 dispatch controller. That controller was sunset before it ever shipped a dispatch loop, and the flag and every surface that read it were removed from the backend repo.

Nothing on a current deployment can be "on v2", so nothing can be rolled back off it. The page is kept because operators still reach it from old links and from the CI/CD runbook index; it records what was removed and where the still live procedures live.

---

What was removed

The v2 dispatch path had two chokepoints. Both are gone, along with the flag that drove them.

Removed	What it did
The cicd_v2 master feature flag	Selected between the v1 worker path and the v2 controller path. No longer registered in the admin settings surface; Settings.Set("cicd_v2", …) returns an unknown-setting error.
internal/api/cicdv2_router_gate.go	The router-level gate. Stamped the X-CICD-Controller response header and short-circuited gated pipeline writes with a structured 503 (controller=v2, phase=cicd-phase-one) while the flag was on.
internal/api/admin_cicd_flag.go	The per-tenant overlay editor behind GET / PATCH /api/v1/orgs/{owner}/cicd, plus the flag-change audit emission. Both routes are gone and now return 404.
internal/cicd/feature_flag.go	The engine-side FlagReader seam and the NotImplementedV2Dispatcher placeholder that returned the not-implemented-yet error.
The engine flag-routing seam in internal/cicd/engine.go	Engine.activeDispatcher, Engine.SetFlagReader and Engine.SetV2Dispatcher. The engine now dispatches unconditionally through its single v1 dispatcher.
POST /api/v1/runner-controller/jobs:next	The v1 worker long-poll deprecation stub that answered 410 while the flag was on.

The engine-layer reroute tests that pinned the mid-flip contract (internal/cicd/feature_flag_test.go, internal/cicd/feature_flag_rollback_test.go) were deleted with the code they covered.

What is still there, and is not a rollback lever

• The cicd_v2 row in app_settings still exists. Its seed migration, 000181_cicd_v2_feature_flag.up.sql, is immutable and still runs, so every deployment carries a cicd_v2 row with value "false". The row is inert: nothing reads it, the admin settings surface no longer registers the key, and editing it (including a direct SQL write) changes no behaviour. Do not treat its presence as evidence that a v2 path exists.
• GET / PATCH /api/v1/admin/cicd-defaults is live but unrelated. It edits the instance-wide CI/CD policy defaults stored as cicd.defaults.* rows, and takes a per-field JSON body — not the {"value":"false"} flag payload this page used to show. The sibling /api/v1/orgs/{owner}/cicd-policy and /api/v1/repos/.../cicd-policy surfaces are the same policy family. None of them selects a dispatcher.
• The host pool and its lifecycle ops are live. Registering, draining and decommissioning runner hosts, and the mTLS / PKI machinery behind them, were explicitly preserved through the sunset. They are simply not fed by any dispatcher.

Where to go instead

Goal	Page
Install / attach a host-agent; drain and decommission a host	CICDv2 operator runbook
Rotate control-plane mTLS leaf certs or the private CA	CICDv2 mTLS certificate rotation
Understand what dispatches jobs today, and why runner_hosts is empty	Job dispatch
Clear a stuck or hanging pipeline job	If a job is stuck below, then Job dispatch — placement is the v1 worker plus ci_runners. The operator runbook covers host lifecycle only and has no stuck-job triage.

If a job is stuck

The reflex this page used to serve — "flip back to v1" — no longer applies, because every deployment is already on the v1 queue-only path. A pipeline job sitting in pending means the polling cmd/worker process is not running, is not reachable, or no runner in ci_runners is eligible for it. Diagnose there. An empty runner_hosts table is expected and is never the cause.