Run acceptance tests and make the ship call

From a fresh clone/directory, run the commands that prove cutover < 30s; rollback restores green with zero dual-write divergence. A second person plays release engineer flipping 100% router cut after green smoke and follows your script without coaching. The demo includes limitations: what RAG API with complete green/v1 and blue/v2 stacks behind one router still will not do.

Bundle: contract snippet, passing tests, metric snapshot for cutover_seconds and postcut_error_rate, security negative probe, rollback note, owner name. Reference BG-SCHEMA-ONESIDE-11 as the drill you rehearsed. If any item is missing, the ship gate fails even if the happy path dazzles.

For Blue-green deploy lab, name the human who gets paged, the review date for thresholds, and the condition that triggers reevaluation. Endpoint router → green|blue /v1/rag/answer remains the production surface you operate for RAG API with complete green/v1 and blue/v2 stacks behind one router — not a slide. Keep BG-SCHEMA-ONESIDE-11 in the handoff template so the next owner inherits the drill.

After the peer demo, schedule the next threshold review date. File a short changelog that mentions BG-SCHEMA-ONESIDE-11 and the control that addresses it. Archive the evidence pack where your team already stores launch records. Resist rewriting everything “for real production” in one weekend — operate this slice until the metrics bore you, then widen. Final self-check: if telemetry vanished, would you still know to hold? If yes, you learned the operating posture this lane teaches.

Trim the demo script until every command is necessary. Record a peer signature line: name, date UTC, pass/fail. File known limitations as bullets, not apologies. Link the evidence pack from the README. Schedule the next game day on a calendar, even if it is solo. Archive the branch tag or release digest you actually shipped. In this chapter the product is RAG API with complete green/v1 and blue/v2 stacks behind one router, the human stakeholder is release engineer flipping 100% router cut after green smoke, and the incident id you design against is BG-SCHEMA-ONESIDE-11. Re-state the oracle in your notes — cutover < 30s; rollback restores green with zero dual-write divergence — and keep the invariant visible: blue must pass smoke + /readyz before cut; old green kept warm for 30m rollback. Track cutover_seconds and postcut_error_rate as the scoreboard. Surface under change control: router → green|blue /v1/rag/answer. If you only have forty minutes, finish the fixture for schema migration applied only on blue — green rollback serves 500s before polishing UI. Promotion language stays ternary: promote, hold, or roll back based on evidence, not hope.