strikethroo 3.17.2 → 3.19.0

package/templates/harness/skills/st-execute-blueprint/SKILL.md

@@ -166,36 +166,33 @@ Before declaring execution complete, apply the evidence gate in `<root>/config/s
 
 #### Run the code review gate
 
-After `POST_EXECUTION.md` reports green and before appending the execution summary, follow the `st-code-review` skill and run one review round with its bundled mechanism:
+After `POST_EXECUTION.md` reports green and before appending the execution summary, follow the `st-code-review` skill and run its bundled mechanism once:
 
 ```text
-code-review.cjs <plan-id> <current-harness> <round>
+code-review.cjs <plan-id> <current-harness>
 ```
 
 `code-review.cjs` ships with the `st-code-review` skill and lives in that skill's own `scripts` directory, a sibling of this one. Resolve it there; it is not bundled with this skill. If the `st-code-review` skill is not installed on this harness, record that as the review outcome in the execution summary and continue to the summary and archival.
 
-`<current-harness>` is the exact supported harness identifier running this skill. `<round>` is `1` on the first invocation, and thereafter the exact `decision.nextRound` the previous round returned. The command emits exactly one JSON line on stdout. Reviewer output is captured and teed to stderr, so stdout carries the verdict JSON line and nothing else. Read its `kind`, then — when `kind` is `reviewed` — its `decision.kind`, and do exactly what the matching row states.
+`<current-harness>` is the exact supported harness identifier running this skill. The command runs one review and emits exactly one JSON line on stdout. Reviewer output is captured and teed to stderr, so stdout carries the verdict JSON line and nothing else. Read its `kind`, then, when `kind` is `reviewed`, its `verdict.kind`, and do exactly what the matching row states.
 
 | Result | What you do |
 | --- | --- |
 | `skipped` | The gate is disabled or unconfigured. Record `reason` and `detail` verbatim in the execution summary, then continue to the summary and archival. A skip is never a failure. |
-| `reviewed`, `decision.kind` = `gate-passed` | The gate passed. Record `findingsGate.recorded` and `findingsGate.aboveFloorWithoutSuggestion` — real findings deliberately not applied — then continue to the summary and archival. |
-| `reviewed`, `decision.kind` = `fix-and-continue` | Apply the `actionable` set from `<plan-dir>/review/round-<n>/findings.json` on the implementer route. Re-run `POST_EXECUTION.md` in full. Then run the gate again with `<round>` set to `decision.nextRound`. |
-| `reviewed`, `decision.kind` = `budget-exhausted` | Halt exactly as any mechanical gate failure. Leave the plan in `plans/`, do not append a completion summary, do not archive, and report the outstanding findings with actionable next steps. |
-| `reviewed`, `decision.kind` = `round-failed` | The round was not certified — the findings document was absent or invalid, or no validator was available. Halt and report `decision.detail`. Never report an uncertified round as clean. |
-| `budget-exhausted` | A round past the enforced budget was requested and no reviewer was dispatched. Halt exactly as `decision.kind` = `budget-exhausted` above. |
+| `reviewed`, `verdict.kind` = `review-recorded` | A reviewer ran and its findings were certified. Record `verdict.detail` and the `findingsGate.counts` in the execution summary, then read `<plan-dir>/review/review.xml` and decide for yourself which findings to act on. Nothing was applied for you. |
+| `reviewed`, `verdict.kind` = `review-failed` | The findings were not certified: the document was absent or invalid, or no validator was available. Halt and report `verdict.detail`. Never report an uncertified review as clean. |
 | `launched-failure` | The reviewer harness exited non-zero. Halt and report `detail`. |
-| `fallback` | The reviewer never ran — the harness was unavailable or authentication failed. Record `reason` and `detail` verbatim in the execution summary, then continue to the summary and archival. |
+| `fallback` | The reviewer never ran, because the harness was unavailable or authentication failed. Record `reason` and `detail` verbatim in the execution summary, then continue to the summary and archival. |
 | `infrastructure-failure` | A real error. Halt and report `detail`. Do not retry on a different route. |
 
 <details>
-<summary>Applying an actionable finding</summary>
+<summary>Acting on the findings</summary>
 
-`<plan-dir>/review/round-<n>/findings.json` holds that round's partition. Its `actionable` array is the only set you apply. Its `recorded` array is inspection material and is never applied.
+`<plan-dir>/review/review.xml` is the reviewer's document and `<plan-dir>/review/findings.json` is the same findings as data. Read them and use your own judgement: the reviewer is a second opinion on a diff you know better than it does, and it has neither run the tests nor read the whole codebase.
 
-Each actionable entry names a file, a location, and a suggestion whose `original-code` was copied verbatim from that file. Apply it as an exact text replacement of `original-code` by `proposed-code`, and change nothing else. When `original-code` no longer matches the file, record the finding as not applied and move to the next one. Do not reconstruct the fix, widen it, or refactor around it.
+Fix what is a genuine requirement gap or defect. Ignore what is wrong, out of scope, or already handled elsewhere, and say in the execution summary which findings you ignored and why. `severity` and `confidence` are the reviewer's own triage labels, useful for sorting and never binding; a `low` confidence finding is one the reviewer could not trace, so read it with that in mind.
 
-Dispatch every fix on the implementer route. Earlier rounds' rulings are carried into the next round by the mechanism itself, which reads the partitions it already wrote; do not pass them back on the command line.
+Dispatch any fix you decide to make on the implementer route.
 
 </details>
 
@@ -203,11 +200,11 @@ Hard rules:
 
 - The gate creates no task files.
 - The gate never mutates the Execution Blueprint.
-- The gate is terminal only — never per phase, never per task.
+- The gate is terminal only, never per phase and never per task.
 - The reviewer never fixes its own findings. Detection runs on the reviewer route, fixes run on the implementer route.
-- Any applied fix invalidates the green build that preceded it. Re-run `POST_EXECUTION.md` in full — lint, tests, and Self Validation — before the gate runs again. Never re-verify against the prior green build.
-- Whether another round runs is `decision.kind`'s to state and yours to obey. Do not count rounds, reason about the budget, or invoke a round the mechanism did not name.
-- A green gate is not a correctness guarantee. It reduces the exposure a human PR approval reduces, and it leaves the same exposure behind.
+- Any fix you apply invalidates the green build that preceded it. Re-run `POST_EXECUTION.md` in full (lint, tests, and Self Validation) before declaring execution complete. Never re-verify against the prior green build.
+- The review runs once. Do not re-run the gate to check your own fixes.
+- A certified review is not a correctness guarantee. It reduces the exposure a human PR approval reduces, and it leaves the same exposure behind.
 
 ### 9. Append execution summary
 
@@ -216,7 +213,7 @@ Append an execution summary section to the plan document using the format descri
 - **Status**: Completed Successfully
 - **Completed Date**: current date
 - **Results**: brief summary of deliverables
-- **Noteworthy Events**: all decisions, issues, and outcomes encountered during execution. Always record the review gate's outcome here: the reviewer harness, the number of rounds run, and the counts of findings recorded versus applied — or, when the gate did not run, its `reason` and `detail` verbatim. If nothing else occurred, state "No significant issues encountered." after the review outcome.
+- **Noteworthy Events**: all decisions, issues, and outcomes encountered during execution. Always record the review gate's outcome here: the reviewer harness, the finding counts, and which findings you acted on versus ignored and why. When the gate did not run, record its `reason` and `detail` verbatim. If nothing else occurred, state "No significant issues encountered." after the review outcome.
 - **Necessary follow-ups**: any follow-up actions or optimizations
 
 ### 10. Archive the plan