bmad-module-skill-forge 2.2.0 → 4.0.0

package/src/skf-verify-stack/references/requirements.md

@@ -1,5 +1,6 @@
 ---
 nextStepFile: 'synthesize.md'
+coverageTallyScript: 'scripts/skf-coverage-tally.py'
 feasibilitySchemaProbeOrder:
   - '{project-root}/_bmad/skf/shared/references/feasibility-report-schema.md'
   - '{project-root}/src/shared/references/feasibility-report-schema.md'
@@ -7,7 +8,12 @@ atomicWriteProbeOrder:
   - '{project-root}/_bmad/skf/shared/scripts/skf-atomic-write.py'
   - '{project-root}/src/shared/scripts/skf-atomic-write.py'
 outputFile: '{outputFolderPath}/feasibility-report-{project_slug}-{timestamp}.md'
-outputFileLatest: '{outputFolderPath}/feasibility-report-{project_slug}-latest.md'
+emitEnvelopeProbeOrder:
+  - '{project-root}/_bmad/skf/shared/scripts/skf-emit-result-envelope.py'
+  - '{project-root}/src/shared/scripts/skf-emit-result-envelope.py'
+# The skill summaries integrations.md §3 wrote: one per skill matched to a
+# Covered technology, with its exports and capabilities.
+skillSummariesFile: '{run_dir}/skill-summaries.json'
 ---
 
 <!-- Config: communicate in {communication_language}. Append the Requirements Coverage section to the report in {document_output_language}. -->
@@ -26,9 +32,17 @@ If a PRD or vision document was provided in Step 01, verify that the combined ca
 
 ## MANDATORY SEQUENCE
 
+**Halt envelope.** Every HALT in this step names its exit code, `halt_reason` and phase. In headless mode, stage `{run_dir}/halt.json` as `{"phase": "<phase>", "reason": "<the halt message>", "halt_reason": "<halt_reason>", "report_path": "{outputFile}"}`, adding `"path"` when the halt names one, resolve `{emitEnvelopeHelper}` from `{emitEnvelopeProbeOrder}` if it is not bound (first existing path wins), then run:
+
+```bash
+uv run {emitEnvelopeHelper} emit-halt --workflow skf-verify-stack --run-dir "{run_dir}" --target stderr < "{run_dir}/halt.json"
+```
+
+Display the line it prints, then stop with the halt's exit code (`references/exit-codes.md` describes the envelope). If no candidate exists, or the emitter exits non-zero or prints no line, display the halt message alone. An interactive HALT displays its message and emits nothing.
+
 ### 1. Check PRD Availability
 
-**Resolve `{atomicWriteHelper}`** from `{atomicWriteProbeOrder}`; first existing path wins. If no candidate exists: HALT (exit code 3, `halt_reason: "resolution-failure"`); in headless, emit the error envelope.
+**Resolve `{atomicWriteHelper}`** from `{atomicWriteProbeOrder}`; first existing path wins. If no candidate exists: HALT (exit code 3, `halt_reason: "resolution-failure"`) at phase `requirements:report`.
 
 **Read `prdAvailable` from `{outputFile}` frontmatter (set in Step 01). If `prdAvailable` is false (no PRD/vision document was provided):**
 
@@ -40,7 +54,7 @@ To include this pass, re-run **[VS]** with a PRD or vision document path.
 
 **Proceeding to synthesis...**"
 
-Update `{outputFile}` frontmatter: append `'requirements'` to `stepsCompleted`; set `requirementsPass: "skipped"`. Pipe the updated content through `python3 {atomicWriteHelper} write --target {outputFile}` and again with `--target {outputFileLatest}`.
+Update `{outputFile}` frontmatter: append `'requirements'` to `stepsCompleted`; set `requirementsPass: "skipped"`. Pipe the updated content through `python3 {atomicWriteHelper} write --target {outputFile}`. On a non-zero exit: HALT (exit code 4, `halt_reason: "write-failed"`) at phase `requirements:report`, with `"path": "{outputFile}"`.
 
 Load, read the full file and then execute `{nextStepFile}`. The no-PRD path ends here — sections 2-6 are the PRD-present branch and do not run.
 
@@ -65,13 +79,14 @@ Parse the PRD/vision document for capability requirements.
 
 ### 3. Assess Stack Coverage
 
-For each requirement, evaluate whether the combined capabilities of the generated skills address it.
+For each requirement, evaluate whether the combined capabilities of the generated skills address it. Work from the summaries step 3 wrote to `{skillSummariesFile}`, one per skill matched to a Covered technology (its `exports`, `capabilities`, `protocols_inferred` and `data_formats_inferred`), never from a SKILL.md read in this context: step 3 already read each one in a subagent.
 
 **Assessment method:**
-- Read each skill's SKILL.md exports, description, and capabilities sections
+- Match each requirement against the skills' `capabilities` and `exports`
 - Check if skill exports provide functions, types, or patterns relevant to the requirement
 - Consider combinations of multiple skills that together address a requirement
-- For non-functional requirements, check if skills document relevant configuration or patterns
+- For non-functional requirements, check if the summaries name relevant configuration or patterns
+- When a verdict turns on a detail no summary holds, delegate it: one subagent reads that skill's SKILL.md and returns only `{"requirement_id": "…", "verdict": "Fulfilled|Partially Fulfilled|Not Addressed", "evidence": "…"}`
 
 **Assign verdict per requirement:**
 - **Fulfilled** — one or more skills clearly provide the needed capability, with specific exports or patterns identified
@@ -83,6 +98,14 @@ For each requirement, evaluate whether the combined capabilities of the generate
 - Specific exports or capabilities from those skills that are relevant
 - For Partially Fulfilled: what gap remains
 
+**Count the verdicts deterministically.** Assigning each verdict is judgment; counting them has one correct answer, so delegate it. Write `{run_dir}/requirement-rows.json` as `{"rows": [{"requirement_id": "R1", "verdict": "Fulfilled|Partially Fulfilled|Not Addressed"}, …]}`, one row per requirement, and run:
+
+```bash
+uv run {coverageTallyScript} --kind requirements --stdin < "{run_dir}/requirement-rows.json"
+```
+
+It returns `requirements_fulfilled`, `requirements_partial`, `requirements_not_addressed` and `requirement_count` (run `uv run {coverageTallyScript} --help` for the contract). When it exits non-zero, it rejected its input and says why (its JSON `error`): fix the rows and run it again. Section 4 displays these counts and section 5 persists them.
+
 ### 4. Display Requirements Results
 
 "**Pass 3: Requirements Coverage**
@@ -91,7 +114,7 @@ For each requirement, evaluate whether the combined capabilities of the generate
 |----|-------------|----------|---------|-------------------|
 | {id} | {requirement_text} | {category} | {Fulfilled/Partially Fulfilled/Not Addressed} | {skill_names or '—'} |
 
-**Coverage: {fulfilled_count} Fulfilled, {partial_count} Partially Fulfilled, {not_addressed_count} Not Addressed**
+**Coverage: {requirements_fulfilled} Fulfilled, {requirements_partial} Partially Fulfilled, {requirements_not_addressed} Not Addressed**
 
 {IF any Not Addressed:}
 **Unaddressed Requirements — Recommendations:**
@@ -110,8 +133,8 @@ Write the Requirements Coverage content under the `## Recommendations` section (
 - Include recommendations for Not Addressed and Partially Fulfilled items
 - Update frontmatter: append `'requirements'` to `stepsCompleted`
 - Set `requirementsPass: "completed"`
-- Set `requirementsFulfilled`, `requirementsPartial`, `requirementsNotAddressed` counts
-- Pipe the updated full content through `python3 {atomicWriteHelper} write --target {outputFile}` and again with `--target {outputFileLatest}`
+- From the §3 tally, set `requirementsFulfilled` ← `requirements_fulfilled`, `requirementsPartial` ← `requirements_partial` and `requirementsNotAddressed` ← `requirements_not_addressed`
+- Pipe the updated full content through `python3 {atomicWriteHelper} write --target {outputFile}`. On a non-zero exit: HALT (exit code 4, `halt_reason: "write-failed"`) at phase `requirements:report`, with `"path": "{outputFile}"`.
 
 ### 6. Auto-Proceed to Next Step
 

package/src/skf-verify-stack/references/synthesize.md

@@ -9,7 +9,10 @@ atomicWriteProbeOrder:
   - '{project-root}/_bmad/skf/shared/scripts/skf-atomic-write.py'
   - '{project-root}/src/shared/scripts/skf-atomic-write.py'
 outputFile: '{outputFolderPath}/feasibility-report-{project_slug}-{timestamp}.md'
-outputFileLatest: '{outputFolderPath}/feasibility-report-{project_slug}-latest.md'
+emitEnvelopeProbeOrder:
+  - '{project-root}/_bmad/skf/shared/scripts/skf-emit-result-envelope.py'
+  - '{project-root}/src/shared/scripts/skf-emit-result-envelope.py'
+inventoryFile: '{run_dir}/skill-inventory.json'
 ---
 
 <!-- Config: communicate in {communication_language}. Append the Executive Summary, synthesized verdict, and Recommendations to the report in {document_output_language}. -->
@@ -27,37 +30,42 @@ Calculate the overall feasibility verdict based on all three analysis passes, ge
 
 ## MANDATORY SEQUENCE
 
+**Halt envelope.** Every HALT in this step names its exit code, `halt_reason` and phase. In headless mode, stage `{run_dir}/halt.json` as `{"phase": "<phase>", "reason": "<the halt message>", "halt_reason": "<halt_reason>", "report_path": "{outputFile}"}`, adding `"path"` when the halt names one, resolve `{emitEnvelopeHelper}` from `{emitEnvelopeProbeOrder}` if it is not bound (first existing path wins), then run:
+
+```bash
+uv run {emitEnvelopeHelper} emit-halt --workflow skf-verify-stack --run-dir "{run_dir}" --target stderr < "{run_dir}/halt.json"
+```
+
+Display the line it prints, then stop with the halt's exit code (`references/exit-codes.md` describes the envelope). If no candidate exists, or the emitter exits non-zero or prints no line, display the halt message alone. An interactive HALT displays its message and emits nothing.
+
 ### 1. Calculate Overall Verdict
 
-**The verdict token is deterministic — do not walk the ladder in prose.** All three passes have already persisted their counts (`coveragePercentage`, `pairsBlocked`/`pairsRisky`/`pairsPlausible`/`pairsVerified`, `requirementsPass` + `requirementsNotAddressed`/`requirementsPartial` in `{outputFile}` frontmatter; the Missing technology count in the Coverage Analysis table). Rolling those already-decided counts up into one token has a single correct answer per input, so delegate it. Count Missing rows directly from the Coverage table — half-up rounding can leave `coveragePercentage == 100` with one technology still Missing — assemble the counts, and run:
+**The verdict token is deterministic: do not walk the ladder in prose.** All three passes have already persisted their counts in the `{outputFile}` frontmatter, each from its tally helper. Rolling them up into one token has a single correct answer per input, and so has the number of recommendations they call for, so delegate both, and let the script read the counts from the report itself:
 
 ```bash
-echo '<counts JSON>' | uv run {verdictRollupScript} --stdin
+uv run {verdictRollupScript} --report "{outputFile}"
 ```
 
-Input keys: `coveragePercentage`, `missingCount`, `pairsBlocked`, `pairsRisky`, `pairsPlausible`, `pairsVerified`; plus, only when the requirements pass ran (`requirementsPass == "completed"`), `requirementsEvaluated: true` with `requirementsNotAddressed`/`requirementsPartial`; plus `continuedPastZeroState: true` if the user pressed `[C] Continue anyway` past a step-2 zero-state gate (all-Replaced or 0%-coverage). The script (run `uv run {verdictRollupScript} --help` for the contract) returns `overallVerdict` (one of `FEASIBLE`/`CONDITIONALLY_FEASIBLE`/`NOT_FEASIBLE`), `matchedConditions` (the condition codes that fired), and `zeroPairsGuardFired`. If `uv` is unavailable (e.g. claude.ai web), apply the ladder below inline.
+`--report` reads `coverageCovered`, `coverageMissing` and the other counts steps 2 to 4 persisted, once `stepsCompleted` lists `coverage`, `integrations` and `requirements`; `uv run {verdictRollupScript} --help` gives each key, the input it fills and the ladder. The script returns `overallVerdict` (one of `FEASIBLE`/`CONDITIONALLY_FEASIBLE`/`NOT_FEASIBLE`), `matchedConditions` (the condition codes that fired), `zeroPairsGuardFired`, `recommendations` (how many recommendations of each kind section 2 writes) and `recommendationCount` (their sum). Branch on its exit code and its JSON `code`:
 
-**The ladder it applies (documented so the rationale can cite it — the script is the executor; evaluate top-to-bottom, first match wins):**
-- `coveragePercentage == 0` → `NOT_FEASIBLE` (short-circuit: no live coverage, analysis vacuous).
-- Any Blocked integration → `NOT_FEASIBLE` (fundamental architectural incompatibility).
-- Any Missing technology, any Risky integration, or — when requirements ran — any Not Addressed / Partially Fulfilled requirement → `CONDITIONALLY_FEASIBLE`.
-- Otherwise → `FEASIBLE`, but any pair capped at `Plausible` (including Check-4-missing caps) downgrades to `CONDITIONALLY_FEASIBLE`.
-- Post-verdict guard: when all four integration counts are 0 and the user continued past a step-2 zero-state gate, `zeroPairsGuardFired` is true — a `FEASIBLE` verdict is overridden to `CONDITIONALLY_FEASIBLE`.
+- `HELPER_MISSING` (exit 1): the shared report reader it loads is not installed; HALT (exit code 3, `halt_reason: "resolution-failure"`) at phase `synthesize:rollup`.
+- `INVALID_REPORT` or `INVALID_INPUT` (exit 2): its `error` names a stage `stepsCompleted` does not list, a count a stage left out of the frontmatter, or counts that disagree; HALT (exit code 5, `halt_reason: "schema-violation"`) at phase `synthesize:rollup`, naming that `error`.
+- Any other non-zero exit (no JSON on stdout): HALT (exit code 3, `halt_reason: "resolution-failure"`) at phase `synthesize:rollup` with its stderr.
 
-Technologies marked **Replaced** in Step 02 are intentionally being removed and are already excluded from `missingCount` and the coverage denominator — they never trigger `CONDITIONALLY_FEASIBLE` or a [CS]/[QS] recommendation.
+Technologies marked **Replaced** in Step 02 are intentionally being removed and are already excluded from `missingCount` and the coverage denominator: they never trigger `CONDITIONALLY_FEASIBLE` or a [CS]/[QS] recommendation.
 
 **Write the rationale** from `matchedConditions`, naming the specific findings behind each code:
-- `zero-coverage` → "no coverage — analysis vacuous: zero generated skills match the architecture's referenced technologies, so integration and requirements verdicts cannot produce meaningful evidence." Then proceed directly to section 2 to generate recommendations for the Missing and/or Replaced technologies surfaced by Step 02.
+- `zero-coverage` → "no coverage, analysis vacuous: zero generated skills match the architecture's referenced technologies, so integration and requirements verdicts cannot produce meaningful evidence." Then proceed directly to section 2 to generate recommendations for the Missing and/or Replaced technologies surfaced by Step 02.
 - `blocked-integration` → a blocked integration is a fundamental architectural incompatibility; name each Blocked pair and note any co-occurring `missing-coverage`/`risky-integration` codes so the user sees the full set of problems.
 - `missing-coverage` / `risky-integration` / `requirements-not-addressed` / `requirements-partial` / `plausible-cap` → the stack can work but has gaps, risks, or unverified assumptions that must be addressed; name the specific items behind each code.
-- No codes (`FEASIBLE`) → {IF requirements pass completed:} the stack can support the architecture as described — all requirements fully fulfilled, every integration pair has a literal cross-reference. {IF requirements pass was skipped:} the stack can support the architecture as described — requirements were not evaluated (no PRD provided).
-- `zero-integration-pairs` (present whenever the guard fired, regardless of verdict) → append: "No integration claims were found in the architecture document prose. Manual review recommended to confirm that technology relationships are not documented exclusively in diagrams or implied without explicit co-mention."
+- `zero-integration-pairs` (whatever the verdict) → append: "No integration pair between two covered technologies was found in the architecture document prose, so no integration was verified. Relationships drawn only in diagrams, or implied without an explicit co-mention, are not checked: describe them in prose to have them verified."
+- No codes (`FEASIBLE`) → the stack can support the architecture as described: every live technology has a skill, every integration pair is `Verified` (at least one of its two skills cites the other literally), and {IF requirements pass completed:} every requirement is fulfilled {IF requirements pass was skipped:} requirements were not evaluated (no PRD provided). {IF `pairsVerified` is 0:} The architecture names a single live technology, so it has no integration pair to verify.
 
 Store the verdict for use in the report.
 
 ### 2. Generate Prescriptive Recommendations
 
-For each non-verified finding across all passes, generate an actionable next step:
+For each non-verified finding across all passes, generate one actionable next step: exactly the number of each kind the §1 rollup's `recommendations` gives (one per Blocked, Missing, Replaced, Risky and Plausible item, one for the zero-pairs note, and one per Not Addressed or Partially Fulfilled requirement when the requirements pass ran), so the list matches the `recommendationCount` the report and the envelope carry:
 
 **Missing skill (from Step 02):**
 - "Run **[CS] Create Skill** or **[QS] Quick Skill** for `{library_name}`, then re-run **[VS]** to verify coverage."
@@ -69,7 +77,11 @@ For each non-verified finding across all passes, generate an actionable next ste
 **Risky integration (from Step 03):**
 - If protocol mismatch → "Consider adding a bridge layer between `{lib_a}` and `{lib_b}` (e.g., HTTP adapter, message queue). Document the bridge in the architecture."
 - If type incompatibility → "Add a serialization/conversion layer between `{lib_a}` and `{lib_b}` to resolve the type mismatch identified in their API surfaces."
-- If weak evidence (Check 4 missing literal cross-reference) → "Run **[SS] Create Stack Skill** to compose `{lib_a}` and `{lib_b}` and surface integration evidence via the stack manifest, then re-run **[VS]** — the stack manifest's `integration_patterns` block will provide the literal cross-references that promote this pair from `Plausible` to `Verified`."
+- If circular dependency (a step 3 cycle row: `cycle` in its `lib_a`, the chain in its `lib_b`) → "`{A → B → C → A}` form a circular integration dependency: each skill's SKILL.md cites the next. Check that the architecture gives the calls between them one direction, or place an adapter between them, before you build on it."
+- If a skill changed mid-run (the rationale "skill modified mid-run") → "`{skill}` changed while this run read it, so `{lib_a}` ↔ `{lib_b}` was not rated: re-run **[VS]**."
+
+**Plausible integration (from Step 03; neither skill cites the other):**
+- "Neither `{lib_a}`'s nor `{lib_b}`'s SKILL.md names the other, so the pair stays `Plausible` until one of them does. When a page documents how the two work together (a `{lib_a}` guide that uses `{lib_b}`, say), add it to that skill's brief as a `doc_urls` entry with **[BS] Brief Skill**, re-create the skill with **[CS] Create Skill**, then re-run **[VS]**. Until then, prototype the integration before you rely on it."
 
 **Blocked integration (from Step 03):**
 - If language barrier → "Replace `{lib_a}` with a `{lib_b_language}`-compatible alternative, or introduce an IPC/FFI bridge. Redesign the integration path in the architecture document."
@@ -83,27 +95,26 @@ For each non-verified finding across all passes, generate an actionable next ste
 - "Gap in `{requirement}`: {what_is_missing}. Consider extending `{contributing_skill}` or adding a dedicated library."
 
 **Zero integration pairs (from Step 03):**
-- If zero integration pairs were found AND the architecture references 2+ technologies: "No integration claims were found in the architecture document prose. Add explicit prose descriptions of how your technologies interact (not only in diagrams), then re-run **[VS]** to verify integrations."
+- When `matchedConditions` holds `zero-integration-pairs` (no pair across two or more covered technologies): "No integration claims were found in the architecture document prose. Add explicit prose descriptions of how your technologies interact (not only in diagrams), then re-run **[VS]** to verify integrations."
 
 ### 3. Check for Previous Report
 
-Read `previousReport` from `{outputFile}` frontmatter (set in Step 01). Each run writes a new timestamped `feasibility-report-{projectSlug}-{timestamp}.md`, so prior reports persist on disk automatically — Step 01 auto-discovers the most recent one for delta comparison when no path is supplied. `previousReport` holds the resolved path, or is empty when no prior report exists or the user skipped the comparison.
+Read `previousReport` from `{outputFile}` frontmatter (set in step 1): an earlier run's report, or empty when there is none or the user skipped the comparison. Step 1 compares against the newest earlier report unless the user names another; to compare against an older run, pass its timestamped report in step 1.
 
-**Note:** A manual backup is only needed to compare against a *specific older* snapshot rather than the most recent prior run; provide that backup path when prompted in Step 01.
+**If `previousReport` is set:** comparing two runs has one correct answer, and so does reading their findings: each sits in a table with a pinned header. The delta helper reads both reports itself: the Coverage Analysis rows and the canonical `| lib_a | lib_b | verdict | rationale |` table of each, and the `evidence_tier` column of the previous report's `## Evidence Sources` table (section 5 writes it). It reads this run's tiers, each skill's `evidence_tier`, from `{inventoryFile}`. Run:
 
-**If a previous report is found:**
-- Extract from both reports (current run + the previous report's tables/inventory block): the coverage findings (`{technology, verdict}`), the integration findings (`{libA, libB, verdict}`), and each skill's `confidence_tier`. Reading the tables is judgment; classifying the difference is not — so hand the two extracted finding sets to the delta helper rather than diffing in prose (matching pair keys and applying the verdict ranking by hand drifts between runs).
-- Serialize as `{"previous": {"coverage": […], "integration": […]}, "current": {…}, "previousTiers": {skill: tier}, "currentTiers": {…}}` and run:
+```bash
+uv run {reportDeltaScript} --previous-report "{previousReport}" --current-report "{outputFile}" --inventory "{inventoryFile}"
+```
 
-  ```bash
-  echo '<delta JSON>' | uv run {reportDeltaScript} --stdin
-  ```
+The script (run `uv run {reportDeltaScript} --help` for the contract and rankings) returns `improved`/`regressed`/`unchanged`/`new`/`dropped`/`replaced` label lists with counts, `tierDowngrades` (each `{skill, from, to}`: a drop along `T1` > `T1-low` > `T2` > `T3`, such as `T1` to `T1-low`, counts as a regression) and `previousTiersRecorded`. Branch on its exit code and its JSON `code`:
 
-  The script (run `uv run {reportDeltaScript} --help` for the contract and rankings) returns `improved`/`regressed`/`unchanged`/`new`/`dropped`/`replaced` label lists with counts, plus `tierDowngrades` (each `{skill, from, to}`) — a tier drop (Tier 1 → Tier 2, or T1 → T1-low) counts as a regression. If `uv` is unavailable, apply the ranking from `--help` inline (coverage Missing<Covered; integration Blocked<Risky<Plausible<Verified; tier T2<T1-low<T1; Replaced findings bucketed, not scored).
-- Render the delta section from those results. For each tier downgrade, flag: "skill `{skill}` regressed from `{from}` to `{to}` — re-extract with [CS] at the prior tier level".
+- Exit 0: render the delta section from those results. When `previousTiersRecorded` is false (a report written before tiers were recorded), add "The previous report records no skill tiers, so tier changes were not compared." For each tier downgrade, flag: "skill `{skill}` evidence fell from `{from}` to `{to}`: check the forge tier with [SF] Setup Forge, then re-create the skill at its earlier tier with [CS] ([SS] for a stack skill)".
+- `UNKNOWN_TIER` or `INVALID_INPUT` (exit 2): a tier outside the scale, or an `{inventoryFile}` it cannot read. Run it again with `--no-tiers` added, render the delta section from that run, and add "Tier changes were not compared: {error}".
+- `INVALID_REPORT` (exit 2): its `error` names a report that is not read (a `schemaVersion` other than `1.0`, a missing coverage or verdict table, the verdict table twice, or a verdict outside its token set). Write "No delta: {error}" in place of the delta section.
+- `HELPER_MISSING` (exit 1): the shared report reader it loads is not installed; HALT per the Workflow Rules (exit code 3, `halt_reason: "resolution-failure"`) at phase `synthesize:delta`.
 
-**If no previous report found:**
-- Note: "First verification run — no delta available."
+**If `previousReport` is empty:** note "First verification run: no delta available."
 
 ### 4. Compile Synthesis Section
 
@@ -111,12 +122,15 @@ Assemble the following for the report:
 
 **Overall verdict** with rationale citing the decision logic.
 
-**Recommendation list** ordered by priority (count total recommendations as `recommendationCount` — persist this count to `{outputFile}` frontmatter for use in step 6):
+**Recommendation list** ordered by priority, the order the §1 rollup's `recommendations` lists its kinds in (`recommendationCount` is the §1 rollup's `recommendationCount`, never a count of your own; section 5 persists it for step 6):
 1. Blocked integrations (if any)
 2. Missing skills
-3. Risky integrations
-4. Not Addressed requirements
-5. Partially Fulfilled requirements
+3. Replaced technologies
+4. Risky integrations
+5. Plausible integrations
+6. Zero integration pairs
+7. Not Addressed requirements
+8. Partially Fulfilled requirements
 
 **Delta from previous run** (if applicable):
 - Improved, regressed, new, unchanged counts
@@ -129,7 +143,7 @@ Assemble the following for the report:
 
 ### 5. Append to Report
 
-**Resolve `{atomicWriteHelper}`** from `{atomicWriteProbeOrder}`; first existing path wins. If no candidate exists: HALT (exit code 3, `halt_reason: "resolution-failure"`); in headless, emit the error envelope.
+**Resolve `{atomicWriteHelper}`** from `{atomicWriteProbeOrder}`; first existing path wins. If no candidate exists: HALT (exit code 3, `halt_reason: "resolution-failure"`) at phase `synthesize:report`.
 
 **Resolve `{feasibilitySchemaRef}`** from `{feasibilitySchemaProbeOrder}`; first existing path wins (installed SKF module path first, dev-checkout `src/` fallback).
 
@@ -138,15 +152,15 @@ Write the **Recommendations** and **Evidence Sources** sections to `{outputFile}
 - Include prioritized recommendation list under `## Recommendations`
 - Include delta from previous run (if applicable) under `## Recommendations` as a subsection
 - Include suggested next workflow at the end of `## Recommendations`
-- Populate `## Evidence Sources` with per-skill citations (SKILL.md path, `metadata_schema_version`, `confidence_tier`, stack manifest if any) and architecture/PRD doc paths
+- Populate `## Evidence Sources`: the template already holds its table, with the header `| skill | evidence_tier | confidence_tier | metadata_schema_version | skill_md |`. Fill it in place with one row per skill in `skill_inventory` (`{inventoryFile}`: `name`, `evidence_tier`, `confidence_tier` or `none`, `metadata_schema_version` or `none`, and `{skills_output_folder}/{path}/SKILL.md`); the next run's delta reads its `evidence_tier` column (section 3). Below it, list the architecture and PRD document paths.
 - Update frontmatter (shared-schema keys):
   - Append `'synthesize'` to `stepsCompleted`
   - Set `overallVerdict` to one of `FEASIBLE`, `CONDITIONALLY_FEASIBLE`, `NOT_FEASIBLE` (case-sensitive, underscores not spaces)
-  - Set `recommendationCount` to the total number of recommendations
+  - Set `recommendationCount` to the §1 rollup's `recommendationCount`
   - If delta was computed (section 3), set `deltaImproved`, `deltaRegressed`, `deltaNew`, `deltaUnchanged` from the delta helper's `improvedCount` / `regressedCount` / `newCount` / `unchangedCount`
-  - Verify that `pairsVerified`, `pairsPlausible`, `pairsRisky`, `pairsBlocked` match the counts from Step 03 (these were set in Step 03). If a discrepancy is found, overwrite the frontmatter counts with the values from Step 03 — the report file is the system of record
-- **Overall verdict enforcement (schema producer obligation):** write the `overallVerdict` the §1 rollup script returned verbatim — do not re-derive the ladder here. §1 (via `{verdictRollupScript}`) is its single source of truth (the 100%-coverage + zero-Blocked + zero-Check-4-missing bar for `FEASIBLE`, and the `coveragePercentage == 0` → `NOT_FEASIBLE` short-circuit included).
-- Pipe the updated full content through `python3 {atomicWriteHelper} write --target {outputFile}` and again with `--target {outputFileLatest}`
+  - Leave the pair and requirement counts as their stages' tallies wrote them: the report file is the system of record
+- Write the `overallVerdict` the §1 rollup returned, verbatim.
+- Pipe the updated full content through `python3 {atomicWriteHelper} write --target {outputFile}`. On a non-zero exit: HALT (exit code 4, `halt_reason: "write-failed"`) at phase `synthesize:report`, with `"path": "{outputFile}"`.
 
 ### 6. Auto-Proceed to Next Step