devflow-kit 3.9.0 → 3.11.0

package/src/assets/commands/implement.mds

@@ -8,12 +8,12 @@ output-dir: dist/commands
 @import { evidence_policy } from "./_partials/_evidence_policy.mds"
 @import { issue_ref_grammar, issue_capture_contract } from "./_partials/_tracker.mds"
 @import { test_plan_line } from "./_partials/_plan_contract.mds"
-@import { publication_gate } from "./_partials/_publication.mds"
+@import { publication_gate, publication_resolve } from "./_partials/_publication.mds"
 @import "./_partials/_compliance.mds" as compliance
 @import "./_partials/_settings.mds" as settings
 # Implement Command
 
-Orchestrate a single task through implementation by spawning specialized agents.
+Orchestrate a single task by spawning agents.
 
 ## Usage
 
@@ -49,9 +49,17 @@ When the user explicitly asks to re-validate, re-check, or re-run quality gates
 ### Phase 1: Setup
 
 <!-- curation:on -->
+<!-- compliance:on -->
 **Produces:** TASK_ID, BASE_BRANCH, BASE_REF, EXECUTION_PLAN, DECISIONS_CONTEXT, FEATURE_KNOWLEDGE, FEATURE_KNOWLEDGE_RULES, PR_DESCRIPTION_GUIDANCE, ISSUE_NUMBER, ISSUE_PR_LINK, EVIDENCE_POLICY, ISSUE_REQUIRED, APPLY_CONVENTIONS, REQUIRE_NON_AUTHOR_APPROVAL, PR_EXCEPTIONS, TEST_PLAN, EVIDENCE_FILE, PR_TEST_PLAN_BLOCK, REVIEW_PUBLICATION, GATE_LEVEL
+<!-- compliance:off -->
+**Produces:** TASK_ID, BASE_BRANCH, BASE_REF, EXECUTION_PLAN, DECISIONS_CONTEXT, FEATURE_KNOWLEDGE, FEATURE_KNOWLEDGE_RULES, PR_DESCRIPTION_GUIDANCE, ISSUE_NUMBER, ISSUE_PR_LINK, EVIDENCE_POLICY, ISSUE_REQUIRED, APPLY_CONVENTIONS, REQUIRE_NON_AUTHOR_APPROVAL, EVIDENCE_EXCEPTIONS, TEST_PLAN, EVIDENCE_FILE, REVIEW_PUBLICATION, GATE_LEVEL
+<!-- compliance:end -->
 <!-- curation:off -->
+<!-- compliance:on -->
 **Produces:** TASK_ID, BASE_BRANCH, BASE_REF, EXECUTION_PLAN, FEATURE_KNOWLEDGE, FEATURE_KNOWLEDGE_RULES, PR_DESCRIPTION_GUIDANCE, ISSUE_NUMBER, ISSUE_PR_LINK, EVIDENCE_POLICY, ISSUE_REQUIRED, APPLY_CONVENTIONS, REQUIRE_NON_AUTHOR_APPROVAL, PR_EXCEPTIONS, TEST_PLAN, EVIDENCE_FILE, PR_TEST_PLAN_BLOCK, REVIEW_PUBLICATION, GATE_LEVEL
+<!-- compliance:off -->
+**Produces:** TASK_ID, BASE_BRANCH, BASE_REF, EXECUTION_PLAN, FEATURE_KNOWLEDGE, FEATURE_KNOWLEDGE_RULES, PR_DESCRIPTION_GUIDANCE, ISSUE_NUMBER, ISSUE_PR_LINK, EVIDENCE_POLICY, ISSUE_REQUIRED, APPLY_CONVENTIONS, REQUIRE_NON_AUTHOR_APPROVAL, EVIDENCE_EXCEPTIONS, TEST_PLAN, EVIDENCE_FILE, REVIEW_PUBLICATION, GATE_LEVEL
+<!-- compliance:end -->
 <!-- curation:end -->
 
 Record the current branch name as `BASE_BRANCH`. Stop the run unless it matches `^(?![-#]|origin\/|(?:@|(?:FETCH_|ORIG_|MERGE_)?HEAD)$)(?!.*\.\.)[A-Za-z0-9._\/+@,#-]{1,200}$` (judge the match by reading; never pass the value to a command), telling the user it allows only ASCII letters, digits and `._/+@,#-`, at most 200; no leading `-` or `#`, no `origin/` prefix, no `..`, not `@` or a HEAD name.
@@ -59,6 +67,9 @@ Record the current branch name as `BASE_BRANCH`. Stop the run unless it matches
 {{docs_root()}}
 
 {{evidence_policy()}}
+<!-- compliance:off -->
+When `EVIDENCE_POLICY` is `required`, record `TRACEABILITY: DEGRADED (compliance off on this machine; the repository requires evidence)` once, for the Phase 12 report.
+<!-- compliance:end -->
 
 **Plan Document Handling** (when `COMMAND_INPUT` is a path ending in `.md`):
 1. Read the plan document from the path provided
@@ -73,7 +84,7 @@ If `PR_DESCRIPTION_GUIDANCE` was not set above (non-plan paths: issue input or t
 
 **Empty input.** When `COMMAND_INPUT` is empty — a plan handoff arrives this way, with the plan already in the conversation — there is no argument to name the branch from, and the Git agent sees none of this conversation. Write the description yourself: one line, taken from the plan's title or, with no plan, from the conversation. Send it as the setup-task `TASK_DESCRIPTION` below.
 
-Spawn Git agent to set up the task:
+Spawn Git agent:
 
 ```
 Agent(subagent_type="Git"):
@@ -83,14 +94,20 @@ ISSUE_INPUT: {COMMAND_INPUT verbatim, when it is a single whitespace-delimited t
 TASK_DESCRIPTION: {COMMAND_INPUT verbatim, when it is two or more whitespace-delimited tokens; when COMMAND_INPUT is empty, the one-line description you wrote above — otherwise omit}
 ISSUE_REQUIRED: {ISSUE_REQUIRED}
 APPLY_CONVENTIONS: {APPLY_CONVENTIONS}
+<!-- compliance:on -->
 PLAN_ARTIFACT_PATH: {path to plan document if COMMAND_INPUT ends in .md, otherwise (none)}
+<!-- compliance:end -->
 Derive branch name from issue or description, create feature branch, and fetch issue if specified.
 Return the branch setup summary."
 ```
 
 The issue token is forwarded **unclassified**; routing is by SHAPE alone (the token count of `COMMAND_INPUT` and a `.md` ending). Only `setup-task` has resolved a provider, so a `starts with #` test would be a github test that reclassifies `PROJ-12` and `ENG-12` as task descriptions: the branch comes from prose, no issue is fetched and nothing reports it. Token COUNT is provider-neutral: every issue spelling is one token and no free-text description is.
 
+<!-- compliance:on -->
 - **Extension.** A path ending in `.md` is a plan document, never an issue reference: it goes to `PLAN_ARTIFACT_PATH` only, and `ISSUE_INPUT` carries the plan's frontmatter `issue`, never the path (Plan Document Handling step 4).
+<!-- compliance:off -->
+- **Extension.** A path ending in `.md` is a plan document, never an issue reference: `ISSUE_INPUT` carries the plan's frontmatter `issue`, never the path (Plan Document Handling step 4).
+<!-- compliance:end -->
 - **Token count.** One token is an issue reference; two or more is prose. Forwarding the FIRST token alone would send `/implement fix the login bug` as `ISSUE_INPUT: fix` with no description, so the request is dropped.
 
 **Capture from Git agent output** (used throughout flow):
@@ -101,11 +118,39 @@ The issue token is forwarded **unclassified**; routing is by SHAPE alone (the to
 
 {{issue_capture_contract()}}
 
+<!-- compliance:on -->
 **Ticket link, only when `ISSUE_REQUIRED` is `true`:** when the capture above holds no `ISSUE_PR_LINK` (absent, or `(none)`), run `d="${CLAUDE_CONFIG_DIR:-}"; case "$d" in /*) ;; *) d="$HOME/.claude" ;; esac; printf '%s\n' "$d"` in Bash, Read `<that directory>/skills/devflow:agent-references/references/commands/implement-evidence-asks.md` with the Read tool (once per run), then run its ticket link ask and **Record the exception at once** as it directs, before any Code spawn. `PR_EXCEPTIONS` is `(none)` until an exception is recorded.
+<!-- compliance:off -->
+**Ticket link, only when `ISSUE_REQUIRED` is `true`:** when the capture above holds no `ISSUE_PR_LINK` (absent, or `(none)`), ask with AskUserQuestion before any Code spawn — "No tracker issue is linked to this task. Record a self-attested exception, or stop?" — offering exactly these two options:
+- **Record an exception** — the user gives the reason as free text. Render it with the exception grammar below, as kind `ticket-link`; when the rendered reason is empty, ask for it once more, and stop as below if it is empty again.
+- **Stop** — report `BLOCKED (no ticket link)`, name the branch setup-task created (`TASK_ID`) and `BASE_BRANCH` so it can be reused or removed, and give the remedy: create or link the tracker issue and re-run `/implement` with its reference, or — for a team that does not want ticket links — commit `.devflow/project.json` as `{"version":1,"evidence":"standard"}` on the default branch. Spawn nothing further.
 
+**Exception grammar.** Render each evidence exception as one line under a `## Evidence Exceptions` heading, in exactly this shape:
+
+```markdown
+## Evidence Exceptions
+- `<kind>` self-attested by @<login> at <utc>: <reason>
+```
+
+- `<kind>` is `ticket-link` or `test-plan` — a closed set; the section holds each kind at most once.
+- `@<login>` is `@` followed by the output of `gh api user --jq .login` when that output matches `^[A-Za-z0-9][A-Za-z0-9-]{0,38}$`. On any other output, or a failed call, it is `(login unavailable)` instead, with no `@`.
+- `<utc>` is the output of `date -u +%Y-%m-%dT%H:%M:%SZ`.
+- `<reason>` is the user's own words, made inert: replace every character outside printable ASCII (newlines and tabs included) with a space, remove every `<`, `>`, `` ` ``, `[`, `]`, `\`, `/`, `#`, `@`, `&` and `$`, collapse runs of spaces, trim, keep the first 200 characters, and trim again. A reason that is empty after this is no reason.
+
+**Record the exception at once**, before any Code spawn: set `EVIDENCE_EXCEPTIONS` to the rendered section. The test plan step below writes it into `EVIDENCE_FILE`, its one home. `EVIDENCE_EXCEPTIONS` is `(none)` until an exception is recorded.
+<!-- compliance:end -->
+
+<!-- compliance:on -->
 **Test plan.** Before any Code spawn, give the task a test plan in the evidence file `{worktree}/.devflow/docs/evidence-{branch_slug}.md` (`EVIDENCE_FILE`) — unlike the handoff file, it stays after the PR exists. It holds up to three sections, in this order and nothing else: `## Test Plan`; `## Evidence Exceptions`, a byte copy of `PR_EXCEPTIONS` present only while that is not `(none)`; and `## Claims`, always last, so every claim is appended at the end of the file. Create the file if absent; if it exists, replace its `## Test Plan` and `## Evidence Exceptions` sections and keep `## Claims` byte-identical.
+<!-- compliance:off -->
+**Test plan.** Before any Code spawn, give the task a test plan in the evidence file `{worktree}/.devflow/docs/evidence-{branch_slug}.md` (`EVIDENCE_FILE`) — unlike the handoff file, it stays after the PR exists. It holds up to three sections, in this order and nothing else: `## Test Plan`; `## Evidence Exceptions`, a byte copy of `EVIDENCE_EXCEPTIONS` present only while that is not `(none)`; and `## Claims`, always last, so every claim is appended at the end of the file. Create the file if absent; if it exists, replace its `## Test Plan` and `## Evidence Exceptions` sections and keep `## Claims` byte-identical.
+<!-- compliance:end -->
 
+<!-- compliance:on -->
 Write the `## Test Plan` section: when `COMMAND_INPUT` is a plan document with a `## Test Plan` section, copy that section's lines verbatim; otherwise write one TP line per acceptance criterion the plan, the issue or the task text states, numbered from `TP-1`. Never invent a criterion, and word every scenario yourself in plain words: the lines reach the PR body, so a scenario holds no `#`, `@` or `/` — no issue reference, mention, closing keyword target or URL — and the files a TP covers go in its `files:` field. Each line follows the TP-line contract:
+<!-- compliance:off -->
+Write the `## Test Plan` section: when `COMMAND_INPUT` is a plan document with a `## Test Plan` section, copy that section's lines verbatim; otherwise write one TP line per acceptance criterion the plan, the issue or the task text states, numbered from `TP-1`. Never invent a criterion, and word every scenario yourself in plain words: a scenario holds no `#`, `@` or `/` — no issue reference, mention, closing keyword target or URL — and the files a TP covers go in its `files:` field. Each line follows the TP-line contract:
+<!-- compliance:end -->
 
 {{test_plan_line()}}
 
@@ -117,12 +162,19 @@ node "$HOME/.devflow/scripts/verify-evidence.cjs" check tp "{worktree}/.devflow/
 
 `exit=0` passes. On any other result, rewrite the section once — the script names the failing line and its code on stderr — and check again. Still failing, or no line to write, means the test plan is **missing**: drop the `## Test Plan` section from the file.
 
+<!-- compliance:on -->
 **Missing test plan, only when `EVIDENCE_POLICY` is `required`:** when the check above leaves the test plan missing, Read the evidence-asks reference as in the ticket link step (when this run has not) and run its missing test plan ask before any Code spawn.
+<!-- compliance:off -->
+**Missing test plan, only when `EVIDENCE_POLICY` is `required`:** when the check above leaves the test plan missing, ask with AskUserQuestion before any Code spawn — "No test plan could be written for this task. Record a self-attested exception, or stop?" — offering exactly these two options:
+- **Record an exception** — the user gives the reason as free text. Render it with the exception grammar above, as kind `test-plan`; when the rendered reason is empty, ask for it once more, and stop as below if it is empty again. Add the rendered line to the `## Evidence Exceptions` section of `EVIDENCE_FILE` — after any `ticket-link` line, creating the section when absent — and set `EVIDENCE_EXCEPTIONS` to that section.
+- **Stop** — report `BLOCKED (no test plan)`, name `TASK_ID` and `BASE_BRANCH` so the branch can be reused or removed, and give the remedy: state the acceptance criteria in the task, the issue or a `/plan` document (its `## Test Plan` section is copied) and re-run `/implement`, or — for a team that does not want test plans enforced — commit `.devflow/project.json` as `{"version":1,"evidence":"standard"}` on the default branch. Spawn nothing further.
+<!-- compliance:end -->
 
 When `EVIDENCE_POLICY` is `standard`, a missing test plan is never asked about: carry `Test plan: missing` to the Phase 12 report.
 
 **Test-plan outputs**, set once before any Code spawn:
 - `TEST_PLAN` — the TP lines of the evidence file's `## Test Plan` section, or `(none)` when the test plan is missing.
+<!-- compliance:on -->
 - `PR_TEST_PLAN_BLOCK` — when the test plan is present and this render ends in `exit=0`, its stdout byte for byte without that `exit=` line; `(none)` otherwise:
 
 ```bash
@@ -130,11 +182,19 @@ node "$HOME/.devflow/scripts/verify-evidence.cjs" render --plan "{worktree}/.dev
 ```
 
 - `EVIDENCE_FILE` — `{worktree}/.devflow/docs/evidence-{branch_slug}.md`, its `## Evidence Exceptions` section now a byte copy of `PR_EXCEPTIONS` (absent when that is `(none)`).
+<!-- compliance:off -->
+- `EVIDENCE_FILE` — `{worktree}/.devflow/docs/evidence-{branch_slug}.md`, its `## Evidence Exceptions` section now a byte copy of `EVIDENCE_EXCEPTIONS` (absent when that is `(none)`).
+<!-- compliance:end -->
 
 {{settings.settings_resolve()}}
 
+<!-- compliance:on -->
 {{publication_gate()}}
 Phase 11 passes the resolved value to the evidence script (`publish`), which decides what each value means for the evidence comment. From the same line: {{compliance.compliance_frameworks()}}
+<!-- compliance:off -->
+{{publication_resolve()}}
+Phase 11 passes no publication value: the local verify posts nothing. From the same line: {{compliance.compliance_frameworks()}}
+<!-- compliance:end -->
 
 {{compliance.compliance_inject()}}
 
@@ -189,7 +249,7 @@ DECISIONS_CONTEXT: {decisions_context}
 
 **SEQUENTIAL_CODE_AGENTS**:
 
-Spawn Code agents one at a time. Each appends its own phase section to the handoff file, and the next reads only the section before it:
+Spawn Code agents one at a time:
 
 **Phase 1 Code agent:**
 ```
@@ -278,7 +338,7 @@ DECISIONS_CONTEXT: {decisions_context}
 - If the Read fails, or the file has no `## Phases` heading with the `| Phase | standard | lean |` header, or a row breaks its grammar, apply no row, keep `GATE_LEVEL` and say `level reference unreadable: no level rows applied`.
 - Validate, the CI gate, the evidence claims and the compliance directive run at every level. An enabled compliance lens keeps Harden.
 
-After the Code agent completes, spawn Polish agent to polish the code. The Phase 6 Validate covers its commits. `{branch_diff}` is the output of `git diff --name-only --diff-filter=d {BASE_REF}...HEAD`, run again at each spawn; a non-zero exit stops, and an empty list counts only on exit 0.
+After the Code agent completes, spawn Polish agent. `{branch_diff}` is the output of `git diff --name-only --diff-filter=d {BASE_REF}...HEAD`, run again at each spawn; a non-zero exit stops, and an empty list counts only on exit 0.
 
 ```
 Agent(subagent_type="Polish"):
@@ -294,7 +354,7 @@ Commit any improvements with a conventional-commit message."
 **Produces:** HARDEN_OUTPUT
 **Requires:** BASE_REF
 
-After Phase 3, spawn Harden agent as the quality gate:
+After Phase 3, spawn Harden agent:
 
 ```
 Agent(subagent_type="Harden"):
@@ -309,12 +369,14 @@ Evaluate 9 pillars, fix P0/P1 issues, report status"
 
 Harden agent reports `### Status: PASS | FIXED | BLOCKED`. **If BLOCKED:** report to user and halt. **If PASS or FIXED:** continue to Phase 5. A FIXED status commits fixes and starts no Validate of its own: the Phase 6 run covers them.
 
+Harden never reviews a deleted file or the old path of a rename; an empty list is no review, and Harden reports `no files reviewed`.
+
 ### Phase 5: Alignment Check
 
 **Produces:** ALIGNMENT_RESULT
 **Requires:** BASE_REF, EXECUTION_PLAN
 
-After Harden agent passes, spawn Evaluate agent to validate alignment. Evaluate agent receives `FEATURE_KNOWLEDGE_RULES` as acceptance context only; pattern and anti-pattern judgments belong to Harden agent:
+After Harden agent passes, spawn Evaluate agent:
 
 ```
 Agent(subagent_type="Evaluate"):
@@ -332,7 +394,7 @@ Validate alignment with request and plan. Report ALIGNED or MISALIGNED with deta
 1. Extract misalignment details from Evaluate agent output
 2. Increment `alignment_fix_count`
 3. If `alignment_fix_count <= 2`:
-   - Spawn Fix agent to fix misalignments:
+   - Spawn Fix agent:
    ```
    Agent(subagent_type="Fix"):
    "OPERATION: alignment-fix
@@ -353,7 +415,9 @@ Validate alignment with request and plan. Report ALIGNED or MISALIGNED with deta
 **Produces:** VALIDATION_RESULT, VALIDATED_HEAD
 **Requires:** BASE_REF, GATE_LEVEL
 
-Validate takes the one full-suite slot, after every commit it must cover: Code, Polish, Harden and the alignment fixes. After Evaluate agent passes, spawn Validate agent. `FILES_CHANGED` is the branch diff:
+Alignment-fix commits get no self-review: Phase 6 Validate and `/code-review` check them.
+
+After Evaluate agent passes, spawn Validate agent:
 
 ```
 Agent(subagent_type="Validate"):
@@ -365,10 +429,9 @@ Run build, typecheck, lint, test. Report pass/fail with failure details."
 ```
 
 **If FAIL:**
-1. Extract failure details from Validate agent output
-2. Increment `validation_retry_count`
-3. If `validation_retry_count <= 2`:
-   - Spawn Fix agent with fix context:
+1. Increment `validation_retry_count`
+2. If `validation_retry_count <= 2`:
+   - Spawn Fix agent:
    ```
    Agent(subagent_type="Fix"):
    "OPERATION: validation-fix
@@ -382,10 +445,14 @@ Run build, typecheck, lint, test. Report pass/fail with failure details."
    {COMPLIANCE_DIRECTIVE}"
    ```
    - Loop back to Phase 6 (re-validate at the new HEAD, full scope)
-4. If `validation_retry_count > 2`: Report failures to user and halt
+3. Else report failures to user and halt
+
+**If BLOCKED:** report its cause and log path, then halt.
 
 **If PASS:** append a `gate:validate` claim, run `git rev-parse HEAD` and record the result as `VALIDATED_HEAD`, then continue to Phase 7.
 
+Any other or missing Status: report and halt; never PASS.
+
 **Evidence claims** are lines appended to the `## Claims` section of `EVIDENCE_FILE` — the file's last section, created when absent. Append only: never edit or remove a claim; the last valid one per target wins. Each line takes exactly one of these shapes, where `<head>` is the 40-hex `HEAD:` the agent's report shows:
 
 ```
@@ -402,7 +469,7 @@ Run build, typecheck, lint, test. Report pass/fail with failure details."
 **Produces:** QA_RESULT
 **Requires:** BASE_REF, EXECUTION_PLAN, TEST_PLAN, VALIDATED_HEAD
 
-After Phase 6 passes, spawn Test agent for scenario-based acceptance testing:
+After Phase 6 passes, spawn Test agent:
 
 ```
 Agent(subagent_type="Test"):
@@ -411,18 +478,17 @@ EXECUTION_PLAN: {execution plan from Phase 1}
 FILES_CHANGED: {branch_diff}
 ACCEPTANCE_CRITERIA: {extracted criteria if available}
 TEST_PLAN: {the TP lines of the evidence file's ## Test Plan section, or (none)}
-Design and execute scenario-based acceptance tests. Report PASS or FAIL with evidence."
+Design and execute scenario-based acceptance tests. Report your Status with evidence."
 ```
 
-After every Test agent run — PASS or FAIL, first run or retry — append its TP claims (Phase 6's **Evidence claims**).
+After every Test agent run — whatever its Status, first run or retry — append its TP claims (Phase 6's **Evidence claims**).
 
-**If PASS:** Continue to Phase 8
+**If PASS** (first word of the Status): Continue to Phase 8
 
 **If FAIL:**
-1. Extract failure details from Test agent output
-2. Increment `qa_retry_count`
-3. If `qa_retry_count <= 2`:
-   - Spawn Fix agent to fix QA failures:
+1. Increment `qa_retry_count`
+2. If `qa_retry_count <= 2`:
+   - Spawn Fix agent:
    ```
    Agent(subagent_type="Fix"):
    "OPERATION: qa-fix
@@ -435,15 +501,17 @@ After every Test agent run — PASS or FAIL, first run or retry — append its T
    <!-- curation:end -->
    {COMPLIANCE_DIRECTIVE}"
    ```
-   - Loop back to Phase 7 (re-run Test agent). The fix is not validated here: Phase 8 covers it.
-4. If `qa_retry_count > 2`: Report QA failures to user for decision. The run stops at the report (Phase 12), so Phases 8 to 11 do not run.
+   - Loop back to Phase 7.
+3. If `qa_retry_count > 2`: Report QA failures to user for decision. The run stops at the report (Phase 12), so Phases 8 to 11 do not run.
+
+**If BLOCKED, or any other or missing Status:** report its cause and log path, and stop as in step 3; no Fix agent.
 
 ### Phase 8: Re-Validate (only if a qa-fix committed)
 
 **Produces:** REVALIDATION_RESULT
-**Requires:** QA_RESULT, VALIDATED_HEAD
+**Requires:** QA_RESULT, VALIDATED_HEAD, BASE_REF, GATE_LEVEL
 
-Run this phase only if a qa-fix committed (`git rev-parse HEAD` differs from `VALIDATED_HEAD`); otherwise skip it and continue to Phase 9. Spawn Validate agent over what changed since the Phase 6 run:
+Run this phase only if a qa-fix committed (`git rev-parse HEAD` differs from `VALIDATED_HEAD`); else skip to Phase 9. Spawn Validate agent:
 
 ```
 Agent(subagent_type="Validate"):
@@ -452,16 +520,30 @@ VALIDATION_SCOPE: changed-only
 Verify the qa-fix commits did not break anything."
 ```
 
+At `lean`, open the prompt with Phase 6's `GATE_LEVEL` and `BASE_SHA` lines; its `Lint pack:` line, or `Lint pack: UNVERIFIED` if it prints none, replaces Phase 6's in VALIDATION_RESULT.
+
 **If FAIL:** Report the failures to user and halt.
 
+**If BLOCKED:** as in Phase 6.
+
 **If PASS:** append a `gate:validate` claim (Phase 6's **Evidence claims**), then continue to Phase 9.
 
+Any other or missing Status: report and halt; never PASS.
+
 ### Phase 9: Open PR
 
 **Produces:** PR_NUMBER
+<!-- compliance:on -->
 **Requires:** BASE_BRANCH, BASE_REF, TASK_ID, ISSUE_NUMBER, ISSUE_PR_LINK, PR_EXCEPTIONS, PR_TEST_PLAN_BLOCK, PR_DESCRIPTION_GUIDANCE, APPLY_CONVENTIONS, CODE_AGENT_OUTPUT
+<!-- compliance:off -->
+**Requires:** BASE_BRANCH, BASE_REF, TASK_ID, ISSUE_NUMBER, ISSUE_PR_LINK, PR_DESCRIPTION_GUIDANCE, APPLY_CONVENTIONS
+<!-- compliance:end -->
 
+<!-- compliance:on -->
 Run once, after the gates, under every strategy. No Code agent opens a PR: the Git agent does, and it pastes `ISSUE_PR_LINK`, `PR_EXCEPTIONS` and `PR_TEST_PLAN_BLOCK` through their paste gates and scrubs the body (D11) before `gh pr create`. This command renders no link line and creates no PR itself: the Git agent's Phase-1 rendering is the only one, forwarded verbatim.
+<!-- compliance:off -->
+Run once, after the gates, under every strategy. No Code agent opens a PR: the Git agent does, and it pastes `ISSUE_PR_LINK` through its paste gate and scrubs the body (D11) before `gh pr create`. This command renders no link line and creates no PR itself: the Git agent's Phase-1 rendering is the only one, forwarded verbatim.
+<!-- compliance:end -->
 
 ```
 Agent(subagent_type="Git"):
@@ -472,9 +554,13 @@ BASE_REF: {BASE_REF}
 TASK_ID: {task-id}
 ISSUE_NUMBER: {ISSUE_ID captured in Phase 1, or (none)}
 ISSUE_PR_LINK: {ISSUE_PR_LINK captured in Phase 1, or (none)}
+<!-- compliance:on -->
 PR_EXCEPTIONS: {the ## Evidence Exceptions section of {worktree}/.devflow/docs/handoff-{branch_slug}.md verbatim, or (none)}
 PR_TEST_PLAN_BLOCK: {PR_TEST_PLAN_BLOCK verbatim, or (none)}
 PR_DESCRIPTION_GUIDANCE: {pr_description_guidance from Phase 1 unless it is (none), then the Code agents' reports from CODE_AGENT_OUTPUT in spawn order — Implementation, Commits and Key Decisions, and a sequential agent's ## Phase {N} Implementation Summary, then Validate's `Lint pack:` line if UNVERIFIED, for Testing}
+<!-- compliance:off -->
+PR_DESCRIPTION_GUIDANCE: {pr_description_guidance from Phase 1, or (none)}
+<!-- compliance:end -->
 APPLY_CONVENTIONS: {APPLY_CONVENTIONS}
 COMMIT_UNCOMMITTED: false
 Open the pull request for this branch and return the pre-flight summary."
@@ -498,23 +584,27 @@ git push origin HEAD; echo "exit=$?"
 `exit=0` continues to the gate. Any other result, a rejected non-fast-forward push included, records `TRACEABILITY: DEGRADED (ci push failed)` for the Phase 12 report, reports "CI status unknown — verify manually before merging" and proceeds to Phase 11 without waiting.
 
 <!-- PATTERN: ci-status-gate -->
-1. Wait: run `cd {worktree} && HEAD_SHA=$(git rev-parse HEAD) && node "$HOME/.devflow/scripts/ci-wait.cjs" --pr {PR_NUMBER} --head "$HEAD_SHA"` through the Bash tool with `timeout: 600000`. Each run is one wait of at most 570 seconds and prints one line, `CI <STATUS> pr=… head=… failing=… pending=… waited=…` (INDETERMINATE adds `reason=…`). A missing or unparseable line, a status outside the six below, or a non-zero exit is INDETERMINATE.
+1. Wait: run `cd {worktree} && HEAD_SHA=$(git rev-parse HEAD) && node "$HOME/.devflow/scripts/ci-wait.cjs" --pr {PR_NUMBER} --head "$HEAD_SHA"` through the Bash tool with `timeout: 600000`. Each run waits at most 570 seconds and prints one line, `CI <STATUS> pr=… head=… failing=… pending=… waited=…` (INDETERMINATE adds `reason=…`). A missing or unparseable line, an unknown status or a non-zero exit is INDETERMINATE.
 2. **If PASSING** → proceed to Phase 11.
 3. **If NO_PR or NO_CI** → skip: "No PR/CI configured, skipping CI validation." Proceed to Phase 11.
-4. **If PENDING** and fewer than 3 waits have run → wait again (step 1). After the third wait → report "CI still running — verify manually before merging" and proceed.
-5. **If INDETERMINATE** and fewer than 3 waits have run → wait again (step 1). After the third wait → report "CI status unknown — verify manually before merging" and proceed.
+4. **If PENDING** and fewer than 3 waits have run → wait again. Otherwise → report "CI still running — verify manually before merging" and proceed.
+5. **If INDETERMINATE** and fewer than 3 waits have run → wait again, unless `waited=570` with `reason=head-mismatch` or `no-workflow-check`. Otherwise → report "CI status unknown — verify manually before merging" and proceed.
 <!-- curation:on -->
 6. **If FAILING** and fewer than 2 fixes have run → report the failing checks from the line. Spawn `Agent(subagent_type="Fix")` whose prompt opens with `OPERATION: ci-fix`, with `COMPLIANCE_DIRECTIVE` (when it is not empty), `CI_FAILURES`, `DECISIONS_CONTEXT` and `PUSH: false`; `CI_FAILURES` holds the failing-check names from the line and nothing else, because the Fix agent fetches the full names and reads the logs itself and this command reads none. After a fix, push with the command above and, if a wait remains, wait again (step 1); a failed push records `TRACEABILITY: DEGRADED (ci push failed)`, reports "CI status unknown — verify manually before merging" and stops waiting. After the second fix still FAILING → report the failing checks and proceed.
 <!-- curation:off -->
 6. **If FAILING** and fewer than 2 fixes have run → report the failing checks from the line. Spawn `Agent(subagent_type="Fix")` whose prompt opens with `OPERATION: ci-fix`, with `COMPLIANCE_DIRECTIVE` (when it is not empty), `CI_FAILURES` and `PUSH: false`; `CI_FAILURES` holds the failing-check names from the line and nothing else, because the Fix agent fetches the full names and reads the logs itself and this command reads none. After a fix, push with the command above and, if a wait remains, wait again (step 1); a failed push records `TRACEABILITY: DEGRADED (ci push failed)`, reports "CI status unknown — verify manually before merging" and stops waiting. After the second fix still FAILING → report the failing checks and proceed.
 <!-- curation:end -->
-7. **Budget**: at most 3 waits and 2 fixes in all. When one is spent, report the current status and proceed.
+7. **Budget**: at most 3 waits and 2 fixes in all. When one is spent, report the status and proceed.
 <!-- /PATTERN: ci-status-gate -->
 
 ### Phase 11: Evidence
 
 **Produces:** EVIDENCE_RESULT
+<!-- compliance:on -->
 **Requires:** PR_NUMBER, EVIDENCE_FILE, REVIEW_PUBLICATION
+<!-- compliance:off -->
+**Requires:** PR_NUMBER, EVIDENCE_FILE
+<!-- compliance:end -->
 
 Run once, after Phase 10, under every strategy. Skip it only when Phase 9 stopped the run. A `ci` TP reads `INDETERMINATE` only when the CI gate could not tell or did not run.
 
@@ -526,6 +616,7 @@ git push origin HEAD; echo "exit=$?"
 
 `exit=0` continues to the script. Any other result, a rejected non-fast-forward push included, does not block: record `TRACEABILITY: DEGRADED (evidence push failed)` for the Phase 12 report and run the script anyway.
 
+<!-- compliance:on -->
 **Then refresh, inline.** The refresh is plumbing, so no Git agent runs it: `verify-evidence.cjs publish` is the whole `update-pr-evidence` operation — verify, the scrubbed block edit with its read-back, the scrubbed evidence comment — in one call. Use the Bash tool with `timeout: 180000`:
 
 ```bash
@@ -533,16 +624,33 @@ cd "{worktree}" && node "$HOME/.devflow/scripts/verify-evidence.cjs" publish --p
 ```
 
 Drop the `--evidence` pair when that file does not exist or its path does not match `^[A-Za-z0-9._/-]{1,255}$`. `{PR_NUMBER}` is digits only, and the publication value is `auto`, `full`, `off` or `stub`. Capture its stdout as `EVIDENCE_RESULT`: the `## PR Evidence` block — its `EVIDENCE` line and its `**Body**:` / `**Comment**:` line — and any `TRACEABILITY: DEGRADED ({reason})` lines after it (exit 0), or the one line `TRACEABILITY: DEGRADED (evidence unavailable)` (exit 2). Empty stdout or any other exit is `TRACEABILITY: DEGRADED (evidence unavailable)`. It never blocks: whatever it returns, continue to Phase 12.
+<!-- compliance:off -->
+**Then verify, inline.** The verify is plumbing, so no Git agent runs it: `verify-evidence.cjs verify` reads the PR and the local evidence file, and writes the local result file. It writes nothing to GitHub:
+
+```bash
+cd "{worktree}" && node "$HOME/.devflow/scripts/verify-evidence.cjs" verify --pr {PR_NUMBER} --evidence ".devflow/docs/evidence-{branch_slug}.md" --comment-out ".devflow/docs/evidence-result-{branch_slug}.md"; echo "exit=$?"
+```
+
+Drop the `--evidence` pair when that file does not exist or its path does not match `^[A-Za-z0-9._/-]{1,255}$`. `{PR_NUMBER}` is digits only. Capture its stdout as `EVIDENCE_RESULT`: its one `EVIDENCE` line (exit 0), or the one line `TRACEABILITY: DEGRADED (evidence unavailable)` (exit 2). Empty stdout or any other exit is `TRACEABILITY: DEGRADED (evidence unavailable)`. It never blocks: whatever it returns, continue to Phase 12.
+<!-- compliance:end -->
 
 ### Phase 12: Report
 
 **Requires:** VALIDATION_RESULT, ALIGNMENT_RESULT, QA_RESULT, PR_NUMBER, EVIDENCE_RESULT, GATE_LEVEL
 
-Display completion summary with phase status, `Gate level: {GATE_LEVEL}` with any level note, Validate's `Lint pack:` line if any, PR info, and next steps.
+Display completion summary with phase status, `Gate level: {GATE_LEVEL}` with any level note, Harden's `no files reviewed` line if any, Validate's `Lint pack:` line if any, PR info, and next steps.
 
+<!-- compliance:on -->
 Show the test plan's evidence from Phase 11: `Test plan: {VERIFIED-CI + ATTESTED-LOCAL}/{total} verified (VERIFIED-CI {n}, ATTESTED-LOCAL {n})`, read from the `EVIDENCE` line and never inferred, then its `**Body**:` / `**Comment**:` line verbatim. Without an `EVIDENCE` line, show `Test plan: evidence unavailable`; with no test plan, `Test plan: missing`.
+<!-- compliance:off -->
+Show the test plan's evidence from Phase 11: `Test plan: {VERIFIED-CI + ATTESTED-LOCAL}/{total} verified (VERIFIED-CI {n}, ATTESTED-LOCAL {n})`, read from the `EVIDENCE` line and never inferred, then `Evidence result: .devflow/docs/evidence-result-{branch_slug}.md (local; not posted)`. Without an `EVIDENCE` line, show `Test plan: evidence unavailable`; with no test plan, `Test plan: missing`.
+<!-- compliance:end -->
 
+<!-- compliance:on -->
 If any Git agent output emitted `TRACEABILITY: DEGRADED ({reason})` lines during the run, or the fresh base step, Phase 10's push, Phase 11's push or Phase 11's script output carried one, surface them verbatim in the report under a `### Traceability` subsection so the user can act on them.
+<!-- compliance:off -->
+If any Git agent output emitted `TRACEABILITY: DEGRADED ({reason})` lines during the run, or the compliance-off line of Phase 1, the fresh base step, Phase 10's push, Phase 11's push or Phase 11's script output carried one, surface them verbatim in the report under a `### Traceability` subsection so the user can act on them.
+<!-- compliance:end -->
 
 If Phase 9 listed uncommitted files, show them as a `### Uncommitted files` subsection: the user commits them or discards them.
 
@@ -563,9 +671,9 @@ If Phase 1 recorded an evidence exception, show its `## Evidence Exceptions` lin
 ├─ Phase 6: Validate (the one full-suite slot)
 ├─ Phase 7: QA Testing
 ├─ Phase 8: Re-Validate (only if a qa-fix committed)
-├─ Phase 9: Open PR (every strategy, outside the strategy branches)
+├─ Phase 9: Open PR (every strategy)
 ├─ Phase 10: CI Status Gate (every strategy)
-├─ Phase 11: Evidence (every strategy)
+├─ Phase 11: Evidence
 ├─ Phase 12: Report
 │
 └─ Feature Knowledge Write-Back (Conditional)
@@ -573,7 +681,11 @@ If Phase 1 recorded an evidence exception, show its `## Evidence Exceptions` lin
 
 ## Principles
 
+<!-- compliance:on -->
 1. **Orchestration only** - Command spawns agents, never does work itself (no tests, builds or fixes); "Spawn X" means call the Agent tool; the inline calls are the bounded plumbing the charter allows: the fresh base step's resolver calls (Phase 1, re-validation), the Phase 10 and 11 pushes, the Phase 10 ci-wait call, the Phase 11 evidence publish call and the evidence script checks
+<!-- compliance:off -->
+1. **Orchestration only** - Command spawns agents, never does work itself (no tests, builds or fixes); "Spawn X" means call the Agent tool; the inline calls are the bounded plumbing the charter allows: the fresh base step's resolver calls (Phase 1, re-validation), the Phase 10 and 11 pushes, the Phase 10 ci-wait call, the Phase 11 evidence verify call and the evidence script checks
+<!-- compliance:end -->
 2. **Honest reporting** - Display agent outputs directly
 3. **Loop limits** - Max 2 validation retries, max 2 alignment fix iterations, max 2 QA retries before escalating to user; the CI gate allows at most 3 waits and 2 fixes
 4. **CI awareness** - CI status is checked before merge; test-plan evidence (Phase 11) is recorded under every strategy

package/src/assets/commands/plan.mds

@@ -456,7 +456,11 @@ Required sections:
 9. **Integration Points** — entry points, services, models to connect
 10. **Design Review Results** — anti-pattern findings with mitigations
 11. **Risk Assessment** — context risk level, unresolved risks
+<!-- compliance:on -->
 12. **PR Description Guidance** — problem being solved, key changes, breaking changes, Reviewer Focus Areas
+<!-- compliance:off -->
+12. **PR Description Guidance** — problem being solved, key changes, breaking changes
+<!-- compliance:end -->
 13. **Test Plan** — the TP lines Gate 2 confirmed, under a `## Test Plan` heading: at least one per acceptance criterion, each citing the criterion it covers
 
 ### 12. PR Description Guidance
@@ -473,9 +477,11 @@ Required sections:
 ### Breaking Changes
 {from gap analysis, or "None expected"}
 
+<!-- compliance:on -->
 ### Reviewer Focus Areas
 {areas needing careful review, with reasons}
 
+<!-- compliance:end -->
 ### Related Issues
 Closes {ISSUE_REF}
 ```
@@ -493,6 +499,9 @@ node "$HOME/.devflow/scripts/verify-evidence.cjs" check tp <that file>; echo "ex
 **Write the artifact now** — frontmatter `issue: {ISSUE_ID}` if an issue is already known, else `issue: pending`.
 
 {{evidence_policy()}}
+<!-- compliance:off -->
+When `EVIDENCE_POLICY` is `required`, record `TRACEABILITY: DEGRADED (compliance off on this machine; the repository requires evidence)` once, for the report below.
+<!-- compliance:end -->
 
 **Create or enrich tracker issue:**
 
@@ -508,12 +517,18 @@ Agent(subagent_type="Git"):
 ISSUE_INPUT: {the raw candidate token from COMMAND_INPUT if /plan was invoked with an issue reference, else omit}
 TASK_DESCRIPTION: {Gate 0 confirmed scope — one-line title}
 INITIAL_REQUEST: {the Gate 0 confirmed scope statement}
+<!-- compliance:on -->
 REQUIREMENTS: {discovered requirements summary from Phase 6 gap synthesis}
 PLAN_ARTIFACT_PATH: {the design artifact path written above, relative to {worktree} — never absolute}
+<!-- compliance:end -->
 WORKTREE_PATH: {worktree}
 LABELS: feature
+<!-- compliance:on -->
 The Git agent will create a tracker issue (or enrich an existing one) using the D3 template,
 post the design artifact as a collapsed details comment, and link it from the Implementation Plan section.
+<!-- compliance:off -->
+The Git agent will create a tracker issue (or enrich an existing one) using the D3 template.
+<!-- compliance:end -->
 Return the issue number."
 ```
 
@@ -527,7 +542,11 @@ Surface any `TRACEABILITY: DEGRADED ({reason})` lines from the Git agent output
 
 Display completion summary:
 - Design artifact path
+<!-- compliance:on -->
 - Issue URL (if created or enriched) — and any `TRACEABILITY: DEGRADED ({reason})` lines from the Git agent
+<!-- compliance:off -->
+- Issue URL (if created or enriched) — the fixed line recorded above when it applies, and any `TRACEABILITY: DEGRADED ({reason})` lines from the Git agent
+<!-- compliance:end -->
 - Gap analysis summary (N blocking, M should-address)
 - Design review summary (N anti-patterns found, M mitigated in plan)
 - Gate level: {GATE_LEVEL}, with any level note