ai-fob 1.9.8 → 1.10.0

package/assets/agents/architect-agent.md

@@ -20,3 +20,22 @@ You are an expert system architect. Help the user plan/design a new feature, bug
 2. Collaborate with the user to brainstorm the best approach to the problem.
 3. Finalise the plan and present it to the user for approval.
 
+## Appendix A: SUCCESS/FAILURE response contract (opt-in)
+
+When the calling command supplies an `ARTIFACT_PATH` in your prompt, after writing the plan respond on a single final line:
+
+- On success: `SUCCESS: wrote {ARTIFACT_PATH} ({line_count} lines)`
+- On failure: `FAILURE: could not write {ARTIFACT_PATH}: {reason}`
+
+Do not return the full plan body when an ARTIFACT_PATH is provided — the orchestrator reads the file from disk. Calling commands that do not supply an ARTIFACT_PATH (e.g. an interactive brainstorm session) should ignore this contract and present the plan inline as usual.
+
+## Appendix B: Validation metadata preservation (opt-in)
+
+When the calling command's spawn prompt asks you to preserve HL-plan validation tags on success criteria (e.g. `[must-pass]`, `[operator-followup]`, `[unsafe-manual]`, `[pre-release]`, `[agent-executable]`, `[operator-required]`, `[external-provider]`, `[dashboard]`, `[destructive]`, `[credentialed]`):
+
+- Carry every supplied tag through verbatim into your plan's `## Success Criteria Verification` table and `## Phase {N} Validation` checklist.
+- For untagged criteria, do not invent policy tags as facts. You may add an inferred validation note when the reason is grounded in HL plan/research, but explicitly mark it as inferred.
+- For operator-only, provider-dashboard, destructive, credentialed, or pre-release validation, state whether it is intended as a follow-up and what substitute evidence the builder/validator can collect.
+
+This appendix only applies when the spawn prompt asks for it; standalone brainstorming sessions are unaffected.
+

package/assets/agents/build-validator-agent.md

@@ -30,6 +30,18 @@ Run every validation check. Report exactly what you observe. If a check fails, d
 
 NEVER use the macOS `open` command to open URLs in a browser. ALWAYS use `agent-browser open <url>` for all browser-based checks. The `open` command launches Safari, which cannot be automated, snapshotted, or device-emulated. All browser interactions MUST go through `agent-browser` (Chromium via Playwright).
 
+## Validation Taxonomy Reference
+
+For BLOCKED checks and aggregate-result derivation, follow the **Validation Taxonomy and Blocked Check Severity** section of the `testing-and-validation` skill. Specifically:
+
+- Classify every BLOCKED check as `severity: terminal` or `severity: non-terminal`.
+- Record `criticality`, `executor`, `risk` from the taxonomy.
+- Apply the **overall-result derivation** rules to compute the aggregate result: `pass | fail | blocked | pass-with-followups`.
+- Apply the **self-consistency requirement**: if no terminal blockers exist, the overall result must be `pass-with-followups`, not `blocked`.
+- For auth-required browser checks, follow the **Auth and Provider Runtime Configuration** section of the same skill (look up `.claude/skills/testing-and-validation/auth.json`; never mark auth BLOCKED if valid credentials are configured; never print raw secrets).
+
+The detailed check schema (Criticality/Executor/Risk columns, `[HL]` prefix semantics, fix-cycle interaction) is provided by the calling command's spawn prompt — this agent applies the taxonomy generically and lets the spawn prompt specify column layout.
+
 ## Checks
 
 The calling prompt provides a numbered list of checks to run. Execute every check listed -- no more, no fewer. For each check:
@@ -106,3 +118,54 @@ Overall result determination:
 - **PASS**: ALL checks passed (no FAIL, no BLOCKED).
 - **FAIL**: At least one check has result FAIL (regardless of BLOCKED count).
 - **BLOCKED**: No checks FAILed, but at least one check is BLOCKED. This means the build may be correct but cannot be fully verified.
+
+## Extended report variant (when the spawn prompt provides taxonomy parameters)
+
+When the calling command's spawn prompt supplies `severity classification`, `Continuation Assessment`, or `pass-with-followups` as allowed outcomes, use this extended frontmatter and structure in addition to the standard template above. This variant is BACKWARD-COMPATIBLE — fields below are additive and may be omitted when the spawn prompt does not request them.
+
+```yaml
+---
+task: {TASK_NAME}
+phase: {PHASE_NUMBER}
+phase-name: {PHASE_NAME}
+type: build-validation-report
+cycle: {CYCLE}
+result: pass | fail | blocked | pass-with-followups
+checks-passed: X/Y
+checks-blocked: Z/Y
+checks-blocked-terminal: A/Y
+checks-blocked-nonterminal: B/Y
+date: {current date}
+---
+```
+
+Extra report sections (append after the standard Verified Checks section):
+
+```markdown
+## Blocked Checks
+| Check | Severity | Criticality | Executor | Risk | Reason | Substitute Evidence | Continuation Impact | Follow-Up |
+|-------|----------|-------------|----------|------|--------|---------------------|---------------------|-----------|
+| {check name} | terminal | non-terminal | {must-pass | should-pass | operator-followup | unsafe-manual | pre-release | unknown} | {agent-executable | agent-with-env | operator-required | external-provider | dashboard | unknown} | {safe | state-mutating | destructive | credentialed | unknown} | {reason} | {evidence or "none"} | {blocks future development | does not block future development | unknown} | {required action} |
+
+If none blocked, write: None.
+
+## Non-Terminal Follow-Ups
+- {check name}: {follow-up description and substitute evidence}
+
+If none, write: None.
+
+## Continuation Assessment
+- Can later phases safely continue? {yes | no | unknown}
+- Reason: {brief evidence-based reason}
+- Blocking issues: {terminal blockers or None}
+- Non-terminal follow-ups: {summary or None}
+```
+
+## SUCCESS/FAILURE response contract
+
+When the calling command supplies an `ARTIFACT_PATH`, after writing the report respond on a single final line:
+
+- On success: `SUCCESS: wrote {ARTIFACT_PATH} ({line_count} lines) result={pass|fail|blocked|pass-with-followups} checks-passed=X/Y checks-blocked=Z/Y`
+- On failure: `FAILURE: could not write {ARTIFACT_PATH}: {reason}`
+
+Do not return the full report body in your response when an ARTIFACT_PATH is provided — the orchestrator will read the file from disk. Calling commands that do not supply an ARTIFACT_PATH should ignore this contract; the standard template above still applies.

package/assets/agents/builder-agent.md

@@ -95,3 +95,12 @@ Use the format matching your assignment mode.
 
 ### Overall: {PASS | FAIL}
 ```
+
+## SUCCESS/FAILURE response contract (opt-in)
+
+When the calling command supplies an `ARTIFACT_PATH` (or a domain-specific path such as `BUILD_REPORT_PATH` or `FIX_REPORT_PATH`) in your prompt, after writing the report respond on a single final line:
+
+- On success: `SUCCESS: wrote {ARTIFACT_PATH} ({line_count} lines)`
+- On failure: `FAILURE: could not write {ARTIFACT_PATH}: {reason}`
+
+Do not return the full report body when an ARTIFACT_PATH is provided — the orchestrator reads the file from disk. Calling commands that do not supply an ARTIFACT_PATH should ignore this contract; the existing Build-Only and Build+Validate templates above still apply.

package/assets/agents/plan-validator-agent.md

@@ -85,3 +85,16 @@ For each FAIL, provide:
 ```
 
 Overall is PASS only if ALL checks pass. Any single FAIL makes the overall FAIL.
+
+## SUCCESS/FAILURE response contract
+
+When the calling command supplies an `ARTIFACT_PATH` in your prompt, after writing the report respond on a single final line:
+
+- On success: `SUCCESS: wrote {ARTIFACT_PATH} ({line_count} lines) result={pass|fail} checks-passed=X/N`
+- On failure: `FAILURE: could not write {ARTIFACT_PATH}: {reason}`
+
+Do not return the full report body when an ARTIFACT_PATH is provided — the orchestrator reads the file from disk. Calling commands that do not supply an ARTIFACT_PATH should ignore this contract; the standard report at lines 53-85 still applies.
+
+## Validation metadata preservation (optional, opt-in via spawn prompt)
+
+When the calling command's spawn prompt supplies HL-plan validation tags (e.g. `[must-pass]`, `[operator-followup]`, `[unsafe-manual]`, `[pre-release]`, `[agent-executable]`, `[operator-required]`, `[external-provider]`, `[dashboard]`, `[destructive]`, `[credentialed]`), verify the plan preserves them in `## Phase {N} Validation` and `## Success Criteria Verification`. Flag any tag dropped or downgraded without justification. This check is in addition to the standard checks specified by the spawn prompt.

package/assets/commands/build-feature.md

@@ -246,7 +246,7 @@ Enter a polling loop. Each iteration:
      3. Cross-reference against HL_CRITERIA[LAST_POLL_PHASE] (the original criteria extracted in Step 0). For each original criterion:
         - If a matching row exists in the report table with result PASS: mark as **complete**.
         - If a matching row exists with result FAIL: mark as **incomplete**.
-        - If a matching row exists with result BLOCKED: mark as **blocked**.
+        - If a matching row exists with result BLOCKED: read the criterion's severity if present (terminal | non-terminal). Mark **blocked-terminal** if severity is terminal (or severity is absent and BUILD_VALIDATION_RESULT is "blocked"); mark **blocked-nonterminal** if severity is non-terminal (or severity is absent and BUILD_VALIDATION_RESULT is "pass-with-followups"). If the criterion appears under the new "## Non-Terminal Follow-Ups" section of the report rather than the main results table, also treat as **blocked-nonterminal**.
         - If no matching row exists (criterion was dropped from the report): mark as **incomplete** and flag as "DROPPED -- not present in phase completion report."
      4. Check for extra rows in the report table that do not correspond to any original HL plan criterion. Flag these as "EXTRA -- not in original HL plan."
      5. Log the results to LEARNINGS_FILE:
@@ -518,8 +518,8 @@ When the build process exits (detected in Step 2b.2):
      find "{SPEC_DIR}" -maxdepth 1 -type d -name "phase{N}_*" 2>/dev/null | head -1
      ```
    - If the directory exists, read `{PHASE_DIR}/phase_completion_report.md` using the Read tool.
-     - If the file exists: Parse its YAML frontmatter for the `status:` field.
-       - If `status:` starts with `completed`: phase **succeeded**.
+     - If the file exists: Parse its YAML frontmatter for the `status:` field AND the new `build-validation-result:` field if present.
+       - If `status:` starts with `completed`: phase **succeeded**. Sub-classify using `build-validation-result` (if present): "pass" → clean success; "pass-with-followups" → success with N non-terminal follow-ups (read N from `checks-blocked-nonterminal`); "blocked" → success only if the `status:` value is `completed-with-blockers` (terminal blockers surfaced); otherwise treat as inconsistent and flag.
        - If `status:` is any other value: phase **completed with issues**.
      - If the file does not exist: phase **failed or was interrupted**.
 
@@ -541,11 +541,11 @@ When the build process exits (detected in Step 2b.2):
    Duration: {minutes}m
 
    ### Per-Phase Results
-   | Phase | Steps Completed | Status | Interventions |
-   |-------|-----------------|--------|---------------|
-   | 1     | {count}/6       | {status} | {count} |
-   | 2     | {count}/6       | {status} | {count} |
-   | ...   | ...             | ...    | ...           |
+   | Phase | Steps Completed | Status | Followups | Interventions |
+   |-------|-----------------|--------|-----------|---------------|
+   | 1     | {count}/6       | {status} | {count of non-terminal blockers, or 0} | {count} |
+   | 2     | {count}/6       | {status} | {count} | {count} |
+   | ...   | ...             | ...    | ...       | ...           |
    ```
 
 6. **Comprehensive success criteria audit.** For each phase 1 through TOTAL_PHASES that was NOT already verified during a phase transition in Step 2b.4 (e.g., the final phase, or phases that completed between polls), perform the same verification procedure described in Step 2b.4 (resolve phase directory, read phase_completion_report.md, extract `## HL Plan Success Criteria Results`, cross-reference against HL_CRITERIA[N], log results). Then produce a full audit summary appended to LEARNINGS_FILE:
@@ -554,12 +554,12 @@ When the build process exits (detected in Step 2b.2):
    ## Success Criteria Audit: Full Build
    Timestamp: {ISO-8601 timestamp}
 
-   | Phase | Total Criteria | Complete | Incomplete | Blocked | Dropped |
-   |-------|---------------|----------|------------|---------|---------|
-   | 1     | {count}       | {count}  | {count}    | {count} | {count} |
-   | 2     | {count}       | {count}  | {count}    | {count} | {count} |
-   | ...   | ...           | ...      | ...        | ...     | ...     |
-   | TOTAL | {sum}         | {sum}    | {sum}      | {sum}   | {sum}   |
+   | Phase | Total Criteria | Complete | Incomplete | Blocked (terminal) | Blocked (non-terminal) | Dropped |
+   |-------|---------------|----------|------------|--------------------|------------------------|---------|
+   | 1     | {count}       | {count}  | {count}    | {count}            | {count}                | {count} |
+   | 2     | {count}       | {count}  | {count}    | {count}            | {count}                | {count} |
+   | ...   | ...           | ...      | ...        | ...                | ...                    | ...     |
+   | TOTAL | {sum}         | {sum}    | {sum}      | {sum}              | {sum}                  | {sum}   |
 
    {If all criteria across all phases are complete: "All success criteria verified complete across all phases."}
    {If any are incomplete/blocked/dropped: "WARNING: {total_incomplete + total_blocked + total_dropped} criteria not fully met. Review per-phase verification logs above for details."}

package/assets/commands/build-phase-V2.md

@@ -101,7 +101,7 @@ Used during resume detection to verify step outputs are genuine and complete (no
 - OR one or more `{PHASE_DIR}/build_report_*.md` files exist, each with more than 5 lines
 
 ### Step 5 (Validate Build)
-- `{PHASE_DIR}/build_validation_report.md`: VALID if exists AND YAML frontmatter contains `result: pass` AND has a `checks-passed:` field
+- `{PHASE_DIR}/build_validation_report.md`: VALID if exists AND YAML frontmatter contains `result: pass` OR `result: pass-with-followups` AND has a `checks-passed:` field. Resume detection treats both as a completed successful Step 5; downstream consumers (Step 6) read the actual `result` value to differentiate.
 
 ### Step 6 (Report)
 - `{PHASE_DIR}/phase_completion_report.md`: VALID if exists AND has more than 10 lines AND YAML frontmatter contains `type: phase-report`
@@ -299,7 +299,13 @@ Run MARK_STEP_START(1).
    Write your complete findings to: {PHASE_DIR}/explorer_findings.md
    Structure your report with these sections: Prerequisites Status, Key Files, Existing Patterns, Integration Points, Shared Utilities, Potential Conflicts, Success Criteria Grounding, Data Flow, File Size Audit.
    Write the file using the Write tool.
-   Return the file path in your response.
+   ARTIFACT_PATH: {PHASE_DIR}/explorer_findings.md
+
+   ## Response contract
+   After writing the artifact, respond on a single final line:
+   - On success: `SUCCESS: wrote {ARTIFACT_PATH} ({line_count} lines)`
+   - On failure: `FAILURE: could not write {ARTIFACT_PATH}: {reason}`
+   Do NOT return the full findings body in your response — the orchestrator will read the file from disk.
    ```
 
 2. **Conditionally spawn Docs Researcher** via Task tool (`subagent_type: "docs-researcher-agent"`).
@@ -334,10 +340,20 @@ Run MARK_STEP_START(1).
    Write your complete findings to: {PHASE_DIR}/docs_research.md
    Structure your report with these sections: Technologies Researched, Key API References, Configuration Requirements, Pitfalls and Gotchas, Deprecation Notices.
    Write the file using the Write tool.
-   Return the file path in your response.
+   ARTIFACT_PATH: {PHASE_DIR}/docs_research.md
+
+   ## Response contract
+   After writing the artifact, respond on a single final line:
+   - On success: `SUCCESS: wrote {ARTIFACT_PATH} ({line_count} lines)`
+   - On failure: `FAILURE: could not write {ARTIFACT_PATH}: {reason}`
+   Do NOT return the full findings body in your response.
    ```
 
-3. **Verify output files**: After both Task calls return, read `{PHASE_DIR}/explorer_findings.md` (required) and `{PHASE_DIR}/docs_research.md` (if docs researcher was spawned). Verify files exist and contain substantive content (not empty or trivial). If a file was not written by the agent (e.g., permission mode blocked writes), write the returned content to the expected path using the Write tool. If a file is missing and no content was returned, warn and note in the report.
+3. **Verify output files**: After both Task calls return:
+   a. Parse the final line of each sub-agent response. Expect either `SUCCESS: wrote {ARTIFACT_PATH} ({line_count} lines)` or `FAILURE: could not write {ARTIFACT_PATH}: {reason}`.
+   b. If `SUCCESS`, read `{PHASE_DIR}/explorer_findings.md` (required) and `{PHASE_DIR}/docs_research.md` (if docs researcher was spawned) using the Read tool, and verify they exist and contain substantive content (not empty or trivial). If they do, proceed.
+   c. If `FAILURE`, abort this step and present the failure reason to the user. Do NOT silently fabricate the file by writing the response body — a sub-agent that could not write its own artifact should not have its response treated as authoritative content.
+   d. If the sub-agent did not emit either `SUCCESS:` or `FAILURE:` (legacy or malformed response), fall back to the previous behavior: check whether the expected file exists; if not, treat as FAILURE and abort. Do NOT write the sub-agent's prose response to the artifact path — only treat content as canonical when emitted from the Write tool by the agent itself.
 
 Run MARK_STEP_COMPLETE(1).
 
@@ -440,15 +456,27 @@ After research is complete, spawn the architect agent to create the implementati
    Then follow the Single-Phase Implementation Plan format provided below.
 
    Write the file using the Write tool.
-   Return the file path in your response.
+   ARTIFACT_PATH: {PHASE_DIR}/plan_V1.md
+
+   ## Validation metadata preservation
+   This phase's HL plan MAY include validation tags on success criteria such as `[must-pass]`, `[should-pass]`, `[operator-followup]`, `[unsafe-manual]`, `[pre-release]`, `[agent-executable]`, `[agent-with-env]`, `[operator-required]`, `[external-provider]`, `[dashboard]`, `[requires-approval]`, `[destructive]`, `[credentialed]`. Carry every supplied tag through verbatim into your plan's `## Success Criteria Verification` table and `## Phase {N} Validation` checklist. For untagged criteria, do not invent policy tags as facts; you may add an inferred validation note grounded in HL plan/research and explicitly mark it as inferred. For operator-only/provider-dashboard/destructive/credentialed/pre-release validation, state whether it is intended as a follow-up and what substitute evidence can be collected.
+
+   ## Response contract
+   After writing the artifact, respond on a single final line:
+   - On success: `SUCCESS: wrote {ARTIFACT_PATH} ({line_count} lines)`
+   - On failure: `FAILURE: could not write {ARTIFACT_PATH}: {reason}`
+   Do NOT return the full plan body in your response — the orchestrator will read the file from disk.
    ```
 
-3. **Verify output file**: After the Task call returns, read `{PHASE_DIR}/plan_V1.md`. Verify the file exists and contains:
-   - YAML frontmatter with correct fields (`task`, `category`, `spec`, `phase`, `phase-name`, `type`, `version`, `status`, `date`, `source`)
-   - All required sections from the Single-Phase Implementation Plan format
-   - Inline source citations (look for `// per:` patterns)
-   - Docs gap flags if applicable (look for `⚠️ DOCS GAP`)
-   If the file was not written by the agent, write the returned content to `{PHASE_DIR}/plan_V1.md` using the Write tool. If the file is missing and no content was returned, warn and note in the report.
+3. **Verify output file**: After the Task call returns:
+   a. Parse the final line of the sub-agent response. Expect either `SUCCESS: wrote {ARTIFACT_PATH} ({line_count} lines)` or `FAILURE: could not write {ARTIFACT_PATH}: {reason}`.
+   b. If `SUCCESS`, read `{PHASE_DIR}/plan_V1.md` and verify the file exists and contains:
+      - YAML frontmatter with correct fields (`task`, `category`, `spec`, `phase`, `phase-name`, `type`, `version`, `status`, `date`, `source`)
+      - All required sections from the Single-Phase Implementation Plan format
+      - Inline source citations (look for `// per:` patterns)
+      - Docs gap flags if applicable (look for `⚠️ DOCS GAP`)
+   c. If `FAILURE`, abort this step and present the failure reason. Do NOT write the sub-agent's prose response to `plan_V1.md` — only treat content as canonical when emitted from the Write tool by the agent itself.
+   d. If the response is malformed (no SUCCESS/FAILURE line), check whether the file exists; if not, abort. Do not synthesize the plan from the response body.
 
 Run MARK_STEP_COMPLETE(2).
 
@@ -629,12 +657,25 @@ Write your validation report to: {PHASE_DIR}/plan_validation_report.md
 Use the YAML frontmatter format from your agent instructions with the parameters above. Include `checks-passed: X/11` in the frontmatter.
 
 Write the file using the Write tool.
-Return the file path AND the overall result (pass or fail) in your response.
+ARTIFACT_PATH: {PHASE_DIR}/plan_validation_report.md
+
+## Additional check: Validation tag preservation
+In addition to the 11 standard checks, verify that the plan preserves every HL-plan validation tag (`[must-pass]`, `[should-pass]`, `[operator-followup]`, `[unsafe-manual]`, `[pre-release]`, `[agent-executable]`, `[agent-with-env]`, `[operator-required]`, `[external-provider]`, `[dashboard]`, `[requires-approval]`, `[destructive]`, `[credentialed]`) supplied by the HL plan's success criteria. Flag any dropped, downgraded, or invented tag. Treat this as part of check 9 (Validation step coverage) for the purposes of pass/fail counting.
+
+## Response contract
+After writing the artifact, respond on a single final line:
+- On success: `SUCCESS: wrote {ARTIFACT_PATH} ({line_count} lines) result={pass|fail} checks-passed=X/11`
+- On failure: `FAILURE: could not write {ARTIFACT_PATH}: {reason}`
+Do NOT return the full report body in your response — the orchestrator will read the file from disk.
 ```
 
 #### 3b. Read Validation Result
 
-After the Task returns, read `{PHASE_DIR}/plan_validation_report.md`. Extract the `result` field from the YAML frontmatter.
+After the Task returns:
+1. Parse the final line of the sub-agent response. Expect `SUCCESS: wrote {ARTIFACT_PATH} ({line_count} lines) result={pass|fail} checks-passed=X/11` or `FAILURE: ...`.
+2. If `SUCCESS`, read `{PHASE_DIR}/plan_validation_report.md` and extract the `result` field from the YAML frontmatter. The frontmatter is authoritative; the SUCCESS line is a fast-path hint.
+3. If `FAILURE`, present the failure reason and abort this step. Do NOT write the sub-agent's prose response to the report path.
+4. If the response is malformed (no SUCCESS/FAILURE), check whether the report exists; if not, abort. Do not synthesize the report from the response body.
 
 - **If `result: pass`**: Set `VALIDATION_RESULT = "pass"`. Run MARK_STEP_COMPLETE(3). Proceed to Step 4 (Build).
 - **If `result: fail`**: Proceed to 3c (Correction).
@@ -796,7 +837,13 @@ Package Manager: {PACKAGE_MANAGER}
 ## Output
 Write your build report to: {PHASE_DIR}/build_report.md
 Write the file using the Write tool.
-Return the file path in your response.
+ARTIFACT_PATH: {PHASE_DIR}/build_report.md
+
+## Response contract
+After writing the artifact, respond on a single final line:
+- On success: `SUCCESS: wrote {ARTIFACT_PATH} ({line_count} lines)`
+- On failure: `FAILURE: could not write {ARTIFACT_PATH}: {reason}`
+Do NOT return the full report body — the orchestrator will read the file from disk.
 ```
 
 **Parallel domain builders** (domains marked `| PARALLEL`):
@@ -845,7 +892,13 @@ Package Manager: {PACKAGE_MANAGER}
 ## Output
 Write your build report to: {PHASE_DIR}/build_report_{DOMAIN_NAME_KEBAB}.md
 Write the file using the Write tool.
-Return the file path in your response.
+ARTIFACT_PATH: {PHASE_DIR}/build_report_{DOMAIN_NAME_KEBAB}.md
+
+## Response contract
+After writing the artifact, respond on a single final line:
+- On success: `SUCCESS: wrote {ARTIFACT_PATH} ({line_count} lines)`
+- On failure: `FAILURE: could not write {ARTIFACT_PATH}: {reason}`
+Do NOT return the full report body — the orchestrator will read the file from disk.
 ```
 
 For any domains NOT marked `| PARALLEL`, combine them into a single sequential builder using the single-builder prompt pattern above, with only those domains' content included.
@@ -854,9 +907,11 @@ For any domains NOT marked `| PARALLEL`, combine them into a single sequential b
 
 After all Task calls return:
 
-1. Read each builder report file (`build_report.md` or `build_report_{domain}.md`)
-2. If a report file was not written by the agent, write the returned content to the expected path using the Write tool
-3. Extract `### Issues Encountered` from each report
+1. For each builder, parse the final line of its response. Expect `SUCCESS: wrote {ARTIFACT_PATH} ({line_count} lines)` or `FAILURE: ...`.
+2. If `SUCCESS`, read each builder report file (`build_report.md` or `build_report_{domain}.md`) using the Read tool.
+3. If `FAILURE` on any builder, present the failure reason and abort Step 4. Do NOT write the builder's prose response to the report path — only treat content as canonical when emitted from the Write tool by the agent itself.
+4. If a builder response is malformed (no SUCCESS/FAILURE line), check whether the expected file exists; if not, treat as FAILURE and abort.
+5. Extract `### Issues Encountered` from each report
 4. If ANY builder reports issues (section content is not "None"):
    - Present:
      ```
@@ -981,34 +1036,42 @@ Read the build report(s) for context on what was built:
   "No dev server is running. There are no browser checks in this validation."}
 
 ## Test Credentials
-{Read the Test Credentials section from the testing-and-validation skill. Extract the Login URL, Username, Password, and Post-Login URL values.
+{Look up `.claude/skills/testing-and-validation/auth.json` (the gitignored local credentials file). If `auth.json` does not exist, fall back to the legacy SKILL.md fields ("Login URL / Username / Password / Post-Login URL" in the Test Credentials table) for backward compatibility with projects scaffolded before auth.json was introduced.
+
+ Source resolution:
+   PRIMARY:   `.claude/skills/testing-and-validation/auth.json` if it exists. Read `browserAuth.enabled`, `browserAuth.loginUrl`, `browserAuth.postLoginUrl`, `browserAuth.users.primary.username`, `browserAuth.users.primary.password`.
+   FALLBACK:  the Test Credentials section of `.claude/skills/testing-and-validation/SKILL.md` (Login URL / Username / Password / Post-Login URL).
 
- If Username is NOT "NONE" and NOT "REPLACE_WITH_TEST_USERNAME":
-  "Test credentials are configured for this project. You MUST authenticate before running browser checks that require a logged-in session.
+ Then branch:
 
-  - Login URL: {Login URL from skill}
-  - Username: {Username from skill}
-  - Password: {Password from skill}
-  - Post-Login URL: {Post-Login URL from skill}
+ If browserAuth.enabled is true AND primary username is set AND is NOT "REPLACE_WITH_TEST_USERNAME" (or legacy Username is NOT "NONE" and NOT "REPLACE_WITH_TEST_USERNAME"):
+  "Test credentials are configured. You MUST authenticate before running browser checks that require a logged-in session.
+
+  - Login URL: {browserAuth.loginUrl OR legacy Login URL}
+  - Username: [REDACTED — present]
+  - Password: [REDACTED — present]
+  - Post-Login URL: {browserAuth.postLoginUrl OR legacy Post-Login URL}
 
   Authentication procedure (use the agent-browser skill workflow):
   1. Open the Login URL: `agent-browser open {Login URL}`
   2. Take a snapshot to identify form elements: `agent-browser snapshot -i`
-  3. Fill in the username field with the Username value
-  4. Fill in the password field with the Password value
+  3. Fill in the username field with the configured username
+  4. Fill in the password field with the configured password
   5. Click the submit/login button
   6. Wait for navigation to the Post-Login URL: `agent-browser wait --url \"**{Post-Login URL path}\"`
   7. Take a snapshot to confirm successful login
-  8. Save the authenticated state: `agent-browser state save auth.json`
-  9. For subsequent browser checks, load the saved state: `agent-browser state load auth.json`
+  8. Save the authenticated browser state: `agent-browser state save browser-state.json`  (NOTE: this is the agent-browser playwright state file; it is DISTINCT from the credentials file `auth.json` in the skill directory)
+  9. For subsequent browser checks, load the saved state: `agent-browser state load browser-state.json`
+
+  REDACTION REQUIREMENT: Never print raw usernames, passwords, API keys, webhook secrets, or full credential values in your report, evidence, or summary. Redact as `[REDACTED]` or report only presence/absence. Failure to redact must be treated as a critical reporting bug.
 
-  IMPORTANT: Because credentials are configured, you MUST NOT mark any browser check as BLOCKED due to authentication requirements. If authentication fails, mark the check as FAIL (not BLOCKED) and include the error details."
+  IMPORTANT: Because credentials are configured, you MUST NOT mark any browser check as BLOCKED due to authentication requirements. If authentication fails, mark the check as FAIL (not BLOCKED) and include the error details with credentials redacted."
 
- If Username is "NONE":
+ If browserAuth.enabled is false AND no legacy credentials configured (or Username is "NONE"):
   "This project does not require authentication for browser tests. No login step is needed."
 
- If Username is "REPLACE_WITH_TEST_USERNAME":
-  "Test credentials have NOT been configured in the testing-and-validation skill. The placeholder values have not been replaced. Browser checks that require authentication MUST be marked as BLOCKED with reason: 'Test credentials not configured in testing-and-validation skill -- user must replace placeholder values.'"}
+ If neither auth.json nor legacy SKILL.md contain valid credentials (auth.json missing AND legacy Username is "REPLACE_WITH_TEST_USERNAME", or auth.json browserAuth.enabled is true but users.primary.username is "REPLACE_WITH_TEST_USERNAME"):
+  "Test credentials have NOT been configured. Browser checks that require authentication MUST be marked as BLOCKED with severity classification per the Validation Taxonomy in the testing-and-validation skill. Use reason: 'Test credentials not configured (no auth.json present and SKILL.md placeholder unchanged) — user must populate .claude/skills/testing-and-validation/auth.json from auth.example.json.' Mark severity as non-terminal if substitute evidence for the underlying behavior exists (source review, build/lint/typecheck pass, adjacent non-auth flows pass); mark terminal if the entire phase depends on authenticated browser flow."}
 
 ## Mobile Device Testing
 {Read the Mobile Test Devices section from the testing-and-validation skill. Extract the Primary Device and Secondary Device values.
@@ -1042,10 +1105,21 @@ The checks prefixed with `[HL]` are the authoritative success criteria from the
 - If you cannot execute a check (e.g., requires a service that is not running, requires manual user action, depends on an external system), mark it as BLOCKED with a specific reason
 
 ## Check Result States
-For each check, report one of three results:
+For each check, report one of three per-check results: PASS, FAIL, or BLOCKED.
 - **PASS**: The check was executed and the criterion is fully satisfied. Include concrete evidence.
 - **FAIL**: The check was executed and the criterion is NOT satisfied. Include what was expected vs. what was observed.
-- **BLOCKED**: The check could NOT be executed due to infrastructure or environmental limitations OUTSIDE your control. Include the specific reason why (e.g., "Dev server not running", "External API unavailable", "Test credentials not configured in testing-and-validation skill"). BLOCKED is a non-pass result. IMPORTANT: If test credentials are provided in the Test Credentials section above, you MUST NOT mark browser checks as BLOCKED due to authentication -- you must authenticate using the provided credentials and report PASS or FAIL based on the result.
+- **BLOCKED**: The check could NOT be executed due to infrastructure or environmental limitations OUTSIDE your control. Include the specific reason why (e.g., "Dev server not running", "External API unavailable", "Test credentials not configured"). BLOCKED is a non-pass result. IMPORTANT: If test credentials are provided in the Test Credentials section above, you MUST NOT mark browser checks as BLOCKED due to authentication -- you must authenticate using the provided credentials and report PASS or FAIL based on the result.
+
+For every BLOCKED check, follow the **Validation Taxonomy and Blocked Check Severity** section of the `testing-and-validation` skill: record `severity: terminal | non-terminal`, `criticality`, `executor`, `risk`, blocked reason, substitute evidence (or why none exists), continuation impact, and recommended follow-up. Use the extended report variant in your agent instructions for the Blocked Checks table, Non-Terminal Follow-Ups list, and Continuation Assessment section.
+
+## Overall result derivation
+Compute the aggregate `result` for the report frontmatter using these rules in order:
+1. If any check is FAIL → `result: fail`.
+2. Else if any BLOCKED check is **terminal** → `result: blocked`.
+3. Else if any BLOCKED check is **non-terminal** AND substitute evidence is documented → `result: pass-with-followups`.
+4. Else → `result: pass`.
+
+Self-consistency requirement: do not write `result: blocked` when `checks-blocked-terminal == 0`; in that case write `pass-with-followups`. Do not write `result: pass` when any non-terminal blockers exist — write `pass-with-followups` (or `blocked` if substitute evidence is missing).
 
 ## Validation Parameters
 - task: {TASK_NAME}
@@ -1059,21 +1133,40 @@ For each check, report one of three results:
 ## Output
 Write your validation report to: {PHASE_DIR}/build_validation_report.md
 
-Use the YAML frontmatter format from your agent instructions with the parameters above. Include `checks-passed: X/{BUILD_CHECK_COUNT}` and `checks-blocked: Y/{BUILD_CHECK_COUNT}` in the frontmatter.
+Use the **extended report variant** from your agent instructions (the variant with taxonomy-aware frontmatter and Blocked Checks/Non-Terminal Follow-Ups/Continuation Assessment sections). Frontmatter MUST include:
+- `result: pass | fail | blocked | pass-with-followups` (per the Overall result derivation rules above)
+- `checks-passed: X/{BUILD_CHECK_COUNT}`
+- `checks-blocked: Y/{BUILD_CHECK_COUNT}`
+- `checks-blocked-terminal: A/{BUILD_CHECK_COUNT}`
+- `checks-blocked-nonterminal: B/{BUILD_CHECK_COUNT}`
 
 Write the file using the Write tool.
-Return the file path AND the overall result (pass, fail, or blocked) in your response.
+ARTIFACT_PATH: {PHASE_DIR}/build_validation_report.md
+
+## Response contract
+After writing the artifact, respond on a single final line:
+- On success: `SUCCESS: wrote {ARTIFACT_PATH} ({line_count} lines) result={pass|fail|blocked|pass-with-followups} checks-passed=X/Y checks-blocked=Z/Y checks-blocked-terminal=A/Y checks-blocked-nonterminal=B/Y`
+- On failure: `FAILURE: could not write {ARTIFACT_PATH}: {reason}`
+Do NOT return the full report body — the orchestrator will read the file from disk.
 ```
 
 #### 5d. Read Build Validation Result
 
-After the Task returns, read `{PHASE_DIR}/build_validation_report.md`. Extract the `result` field from the YAML frontmatter.
+After the Task returns:
+1. Parse the final line of the sub-agent response. Expect `SUCCESS: wrote {ARTIFACT_PATH} ({line_count} lines) result={...} ...` or `FAILURE: ...`.
+2. If `SUCCESS`, read `{PHASE_DIR}/build_validation_report.md` and extract the `result`, `checks-passed`, `checks-blocked`, `checks-blocked-terminal`, and `checks-blocked-nonterminal` fields from the YAML frontmatter. The frontmatter is authoritative.
+3. If `FAILURE`, present the failure reason and treat as a cycle failure (proceed to 5e).
+4. If the response is malformed (no SUCCESS/FAILURE line), check whether the report exists; if not, treat as FAIL and proceed to 5e. Do NOT write the sub-agent's prose response to the report path.
 
-If the file was not written by the agent, write the returned content to `{PHASE_DIR}/build_validation_report.md` using the Write tool. If the file is missing and no content was returned, warn and treat as FAIL.
+Then branch on `result`:
 
-- **If `result: pass`**: Set `BUILD_VALIDATION_RESULT = "pass"`. Extract `checks-passed` value as `BUILD_CHECKS_PASSED`. Extract `checks-blocked` value as `BUILD_CHECKS_BLOCKED`. Proceed to 5f (Cleanup).
-- **If `result: fail`**: Extract `checks-passed` value as `BUILD_CHECKS_PASSED`. Extract `checks-blocked` value as `BUILD_CHECKS_BLOCKED`. Proceed to 5e (Fix and Re-validate).
-- **If `result: blocked`**: Extract `checks-passed` value as `BUILD_CHECKS_PASSED`. Extract `checks-blocked` value as `BUILD_CHECKS_BLOCKED`. Review each BLOCKED check reason. If any BLOCKED check cites "authentication", "login", "credentials", or "authenticated session" AND test credentials are configured in the testing-and-validation skill (Username is not "NONE" and not "REPLACE_WITH_TEST_USERNAME"), this is a validation error -- the validator should have authenticated. Log a warning: "Validator marked auth-requiring check as BLOCKED despite credentials being configured. Re-running validation." Decrement BUILD_VALIDATION_CYCLE by 1 (to not count this as a failed cycle) and return to 5c to re-spawn the validator. Otherwise, if ALL non-pass results are genuinely BLOCKED (infrastructure/environmental), set `BUILD_VALIDATION_RESULT = "blocked"`. Do NOT enter the fix loop -- genuinely BLOCKED checks cannot be fixed by a builder agent. Proceed to 5f (Cleanup). The blocked checks will be surfaced in the phase completion report for human action.
+- **If `result: pass`**: Set `BUILD_VALIDATION_RESULT = "pass"`. Extract `checks-passed`, `checks-blocked`, `checks-blocked-terminal`, `checks-blocked-nonterminal`. Proceed to 5f (Cleanup).
+- **If `result: pass-with-followups`**: Set `BUILD_VALIDATION_RESULT = "pass-with-followups"`. Extract the same fields. The build is accepted; non-terminal follow-ups will be surfaced in the phase completion report for human action. Proceed to 5f (Cleanup). Do NOT enter the fix loop — non-terminal blockers are operator/dashboard/external work, not code defects.
+- **If `result: fail`**: Extract all five fields. Proceed to 5e (Fix and Re-validate).
+- **If `result: blocked`**: Extract all five fields. This means at least one TERMINAL blocker exists. Auth-credentials recovery check (constrained):
+  - Review each terminal BLOCKED check reason. If a BLOCKED check cites "authentication", "login", "credentials", or "authenticated session" AND `auth.json` is present with `browserAuth.enabled: true` AND `users.primary.username` is set (or legacy SKILL.md Username is not "NONE" and not "REPLACE_WITH_TEST_USERNAME") AND this is the FIRST cycle (BUILD_VALIDATION_CYCLE == 1) AND the check has no documented substitute evidence: re-spawn the validator ONCE without incrementing BUILD_VALIDATION_CYCLE. Log: "Validator marked auth-requiring check as BLOCKED despite configured credentials on first cycle. Re-running once without cycle increment."
+  - The no-increment recovery is allowed ONLY when ALL of the conditions above hold. On any subsequent cycle, on any non-auth-related blocker, or when credentials are unconfigured, increment the cycle normally and treat the result as terminal-blocked.
+  - If recovery does not apply, set `BUILD_VALIDATION_RESULT = "blocked"`. Do NOT enter the fix loop — genuinely BLOCKED checks cannot be fixed by a builder agent. Proceed to 5f (Cleanup). The terminal blocked checks will be surfaced in the phase completion report for human action.
 
 #### 5e. Fix and Re-validate
 
@@ -1139,13 +1232,21 @@ Use this format:
 - ... (or "None")
 
 Write the file using the Write tool.
-Return the file path in your response.
+ARTIFACT_PATH: {PHASE_DIR}/fix_report_cycle{BUILD_VALIDATION_CYCLE}.md
+
+## Response contract
+After writing the artifact, respond on a single final line:
+- On success: `SUCCESS: wrote {ARTIFACT_PATH} ({line_count} lines)`
+- On failure: `FAILURE: could not write {ARTIFACT_PATH}: {reason}`
+Do NOT return the full fix-report body — the orchestrator will read the file from disk.
 ```
 
 After the Task returns:
-1. Read `{PHASE_DIR}/fix_report_cycle{BUILD_VALIDATION_CYCLE}.md`
-2. If the file was not written by the agent, write the returned content to the expected path using the Write tool
-3. Check for "Unresolved Issues" -- if any exist (section content is not "None"), note them for the summary
+1. Parse the final line of the sub-agent response. Expect `SUCCESS: wrote {ARTIFACT_PATH} ({line_count} lines)` or `FAILURE: ...`.
+2. If `SUCCESS`, read `{PHASE_DIR}/fix_report_cycle{BUILD_VALIDATION_CYCLE}.md` using the Read tool.
+3. If `FAILURE`, present the failure reason and abort the fix cycle (treat as if no fix progress was made — proceed to 5e-iv re-validation which will likely re-FAIL and consume a cycle).
+4. If the response is malformed (no SUCCESS/FAILURE line), check whether the fix report exists; if not, treat as no-progress and proceed to 5e-iv. Do NOT write the sub-agent's prose response to the fix report path.
+5. Check for "Unresolved Issues" — if any exist (section content is not "None"), note them for the summary.
 
 ##### 5e-ii. Post-fix git checkpoint
 
@@ -1165,7 +1266,8 @@ If DEV_SERVER_STARTED == true:
 Repeat from 5c -- spawn the build validator again with `cycle: {BUILD_VALIDATION_CYCLE}`. The validator reads the (possibly fixed) codebase and overwrites `build_validation_report.md`.
 
 - **If `result: pass`**: Set `BUILD_VALIDATION_RESULT = "pass"`. Proceed to 5f (Cleanup).
-- **If `result: blocked`**: All non-pass results are BLOCKED (no FAIL items remain). Set `BUILD_VALIDATION_RESULT = "blocked"`. Extract `checks-blocked` value as `BUILD_CHECKS_BLOCKED`. Proceed to 5f (Cleanup) -- do not re-enter the fix loop.
+- **If `result: pass-with-followups`**: Set `BUILD_VALIDATION_RESULT = "pass-with-followups"`. Extract `checks-blocked-terminal` (must be 0) and `checks-blocked-nonterminal` for the report. Proceed to 5f (Cleanup) -- do not re-enter the fix loop. Non-terminal follow-ups are operator/dashboard work, not code defects.
+- **If `result: blocked`**: At least one terminal blocker remains (no FAIL items, but core correctness cannot be established). Set `BUILD_VALIDATION_RESULT = "blocked"`. Extract `checks-blocked` and `checks-blocked-terminal`. Proceed to 5f (Cleanup) -- do not re-enter the fix loop.
 - **If `result: fail`**: Repeat fix (5e).
 
 ##### 5e-v. Abort on Final Failure
@@ -1204,16 +1306,19 @@ Stop execution. Do not proceed to Step 6.
 If DEV_SERVER_STARTED == true:
 1. Kill any process on port 3000: run `lsof -ti:3000 | xargs kill -9 2>/dev/null` via Bash.
 
-**Git post-validation checkpoint** (only on success):
-If GIT_AVAILABLE == true AND BUILD_VALIDATION_RESULT == "pass":
-1. Run `git add -A && git commit -m "checkpoint: phase-{PHASE_NUMBER} build validated ({PHASE_NAME_KEBAB})"` via Bash.
-2. If nothing to commit, skip silently.
+**Git post-validation checkpoint** (on success or pass-with-followups):
+If GIT_AVAILABLE == true AND (BUILD_VALIDATION_RESULT == "pass" OR BUILD_VALIDATION_RESULT == "pass-with-followups"):
+1. Build commit message suffix: if BUILD_VALIDATION_RESULT == "pass-with-followups", use "build validated (pass-with-followups: N non-terminal blockers) ({PHASE_NAME_KEBAB})" where N is parsed from BUILD_CHECKS_BLOCKED_NONTERMINAL. Otherwise use "build validated ({PHASE_NAME_KEBAB})".
+2. Run `git add -A && git commit -m "checkpoint: phase-{PHASE_NUMBER} {suffix}"` via Bash.
+3. If nothing to commit, skip silently.
 
 **Store summary variables** for Step 6:
-- BUILD_VALIDATION_RESULT: "pass", "fail", or "blocked" (should be "pass" or "blocked" if we reached here from 5d/5e-iv)
+- BUILD_VALIDATION_RESULT: "pass", "pass-with-followups", "fail", or "blocked" (should be "pass", "pass-with-followups", or "blocked" if we reached here from 5d/5e-iv)
 - BUILD_VALIDATION_CYCLE: final cycle number (1 if passed first try)
 - BUILD_CHECKS_PASSED: "{X}/{BUILD_CHECK_COUNT}" from the final validation report
 - BUILD_CHECKS_BLOCKED: "{Y}/{BUILD_CHECK_COUNT}" from the final validation report (0 if none blocked)
+- BUILD_CHECKS_BLOCKED_TERMINAL: "{A}/{BUILD_CHECK_COUNT}" from the final validation report (new field; default "0/{BUILD_CHECK_COUNT}" if old-format report)
+- BUILD_CHECKS_BLOCKED_NONTERMINAL: "{B}/{BUILD_CHECK_COUNT}" from the final validation report (new field; default "0/{BUILD_CHECK_COUNT}" if old-format report)
 - FIX_REPORTS: list of fix report file paths (empty if passed on first try)
 
 Run MARK_STEP_COMPLETE(5).
@@ -1256,7 +1361,14 @@ Cross-reference sources:
 
 For each deviation, write: area, what HL plan assumed, what actually happened, why, impact.
 
-Set `REPORT_STATUS`: "completed-with-deviations" if any deviations were identified, otherwise "completed".
+Set `REPORT_STATUS` using this matrix (priority order):
+- If BUILD_VALIDATION_RESULT == "blocked": `REPORT_STATUS = "completed-with-blockers"` (terminal blockers exist; later phases may be unable to proceed).
+- Else if BUILD_VALIDATION_RESULT == "pass-with-followups" AND any deviations were identified: `REPORT_STATUS = "completed-with-deviations-and-followups"`.
+- Else if BUILD_VALIDATION_RESULT == "pass-with-followups": `REPORT_STATUS = "completed-with-followups"`.
+- Else if any deviations were identified: `REPORT_STATUS = "completed-with-deviations"`.
+- Else: `REPORT_STATUS = "completed"`.
+
+All `REPORT_STATUS` values that start with `completed` are treated as successful builds by downstream consumers (e.g. build-feature.md). Only `failed` or absent reports should be treated as build failures. The new `completed-with-followups` and `completed-with-deviations-and-followups` values preserve backward compatibility with downstream consumers that match on the `completed` prefix.
 
 #### 6e. Identify Impacts on Future Phases
 
@@ -1277,6 +1389,11 @@ status: {REPORT_STATUS}
 date: {current date}
 pre-phase-sha: {PRE_PHASE_SHA | "(git unavailable)"}
 post-build-sha: {POST_BUILD_SHA | "(git unavailable)"}
+build-validation-result: {BUILD_VALIDATION_RESULT}
+checks-passed: {BUILD_CHECKS_PASSED}
+checks-blocked: {BUILD_CHECKS_BLOCKED}
+checks-blocked-terminal: {BUILD_CHECKS_BLOCKED_TERMINAL}
+checks-blocked-nonterminal: {BUILD_CHECKS_BLOCKED_NONTERMINAL}
 ---
 
 # Phase {N} Report: {PHASE_NAME}
@@ -1292,11 +1409,28 @@ post-build-sha: {POST_BUILD_SHA | "(git unavailable)"}
 |---|-----------|--------|----------|
 {rows from 6c -- Result is PASS, FAIL, or BLOCKED}
 
-{If any BLOCKED results exist:}
-### Blocked Criteria -- Action Required
-The following success criteria could not be verified automatically and require human verification:
-{For each BLOCKED criterion:}
+{If any BLOCKED results exist, classified as terminal:}
+### Terminal Blocked Criteria -- Action Required
+The following success criteria could not be verified automatically and represent terminal blockers (core correctness could not be established):
+{For each terminal-BLOCKED criterion:}
+- **{criterion text}**: {blocked reason}
+  - severity: terminal
+  - criticality: {must-pass | should-pass | unknown}
+  - substitute evidence: {summary or "none"}
+  - continuation impact: {summary}
+  - recommended follow-up: {action}
+
+{If any BLOCKED results exist, classified as non-terminal (new section, additive):}
+## Non-Terminal Follow-Ups
+The following checks could not be executed safely as part of automated validation, but core functionality has been verified through substitute evidence. These items are recommended human/operator follow-ups; they do NOT block future phases:
+{For each non-terminal-BLOCKED criterion:}
 - **{criterion text}**: {blocked reason}
+  - severity: non-terminal
+  - criticality: {operator-followup | unsafe-manual | pre-release | unknown}
+  - executor: {operator-required | external-provider | dashboard | unknown}
+  - substitute evidence: {what was verified instead}
+  - continuation impact: does not block future development
+  - recommended follow-up: {action}
 
 ## Deviations from HL Plan
 {bullets from 6d, or "None. Implementation matched the HL plan as specified."}
@@ -1314,6 +1448,8 @@ The following success criteria could not be verified automatically and require h
 - Plan validation: {VALIDATION_RESULT} (cycle {VALIDATION_CYCLE})
 - Build validation: {BUILD_VALIDATION_RESULT} (cycle {BUILD_VALIDATION_CYCLE})
 - Checks passed: {BUILD_CHECKS_PASSED}
+- Checks blocked (terminal): {BUILD_CHECKS_BLOCKED_TERMINAL}
+- Checks blocked (non-terminal): {BUILD_CHECKS_BLOCKED_NONTERMINAL}
 - Fix cycles: {BUILD_VALIDATION_CYCLE - 1}
 ```