## Host orchestration rules — implementation-planning These are the rules the **host orchestrator** follows around an `implementation-planning` run: when a stage genuinely cannot write a RED step, and what only the user can grant. They are not lead phase rules — the lead's rules live in `prompts/profiles/`. ### Step 5.1 (implementation-planning only): user-confirmed TDD bypass offer Every plan stage must open with a `RED:` step whose outcome is FAIL and reach a later `GREEN:` step (validator S10c). `tddExemption` waives that, and until 2026-09-10 only for `doc-only`, `config-only`, or `pure-rename` work — so a stage that is truthfully none of the three had no passable value, and the plan got through by filing the nearest category. That is the failure this flag exists to remove: **a closed reason list with no escape makes the plan misdescribe itself.** `render-bundle` accepts an optional `--tdd-bypass ":"` flag (implementation-planning only). It records a **user-acknowledged** bypass into `/qa/tdd-bypass.json`, and S10e then accepts that stage declaring `tddExemption: user-bypass`. The reason is stored **verbatim**. Offer it only when the run's own output says the stage cannot reach RED — a planning report blocked at S10e on a `user-bypass` stage, or a plan-body verification round whose disagreements say the expected FAIL is unreachable (e.g. the stage worktree HEAD is already the accepted commit). Never offer it to save a stage that simply has no test written yet; that stage's answer is the RED step. This is **never** a lead/worker self-exemption — only the user may grant it, and the lead has no command that writes this record. Surface it as a 3-option recommendation picker (per the run-prompt recommendation rule): 1. (recommended) Keep the RED/GREEN requirement — re-plan the stage so its first step writes the failing test. 2. Bypass this stage — ask the user for the stage number and reason, then pass `--tdd-bypass ":"` to `render-bundle` (reason = the user's words, unedited). 3. Enter directly — the user types the full `:` value. When the user picks a bypass, append `--tdd-bypass ":"` to the `render-bundle` invocation. Omit the flag entirely otherwise (do **not** pass `--tdd-bypass ""`). A malformed value aborts `render-bundle` with a `PrepareError`. The grant is per stage number and per task, and it persists across runs of that task — the next plan of the same stage may still declare `user-bypass` until the user's grant is removed from the ledger. **A stage whose work already landed is usually not a bypass case.** When the product change is committed and its conformance result is PASS but the stage never registered as done, the honest fix is to close that stage rather than to re-plan it without a RED step. Check `okstra stage-map ` first: when `doneStages` omits a stage whose commit is on the stage branch, close it with `okstra stage-close --stage --from-commit ` and re-plan only what is left. That command refuses unless the commit exists and the stage's conformance gate permits progress, so it cannot close a stage the run validator would have blocked. If `okstra stage-map` cannot read the prior plan during this planning run, follow the analysis packet's Stage Ledger recovery guidance. A notation error in an existing `dependsOn` cell is work for the new plan, not a reason to ask the user to edit JSON. Preserve the prior report, existing stage numbers and completed work; do not close or execute a stage from an unreadable map. An ambiguous dependency or stage identity remains a blocker.