strikethroo 3.17.2 → 3.18.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

package/templates/harness/skills/st-full-workflow/SKILL.md

@@ -509,36 +509,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>
 
@@ -546,11 +543,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.
 
 #### 7. Append execution summary
 
@@ -559,7 +556,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
 
 #### 8. Archive the plan

package/templates/strikethroo/config/hooks/CODE_REVIEW.md

@@ -2,13 +2,13 @@
 
 ## Automated Code Review Gate
 
-This hook governs an unattended review loop that runs at the end of blueprint execution, after mechanical gates (lint, tests, Self Validation) report success. A reviewer on a discovered external harness critiques the plan's cumulative diff and emits findings; findings at or above the severity and confidence floors trigger automatic remediation, followed by a full re-run of the mechanical gates and re-verification.
+This hook governs a review step that runs at the end of blueprint execution, after the mechanical gates (lint, tests, Self Validation) report success. A reviewer on a discovered external harness critiques the plan's cumulative diff and emits findings. The findings are validated against the vendored schema and recorded.
 
-The gate terminates on exhausted round budget or when no findings above threshold remain.
+The gate reports; it does not decide. Nothing is applied automatically, and the implementer reads the recorded findings and chooses what to act on.
 
 ## Mandate: Conformance and Defects Only
 
-The reviewer checks the diff against the **plan's stated requirements** and for **demonstrable defects**. It does **not** raise general code-quality opinions, style notes, design critiques, or taste judgments — the linter owns style. Every finding must cite concrete evidence and trace to:
+The reviewer checks the diff against the **plan's stated requirements** and for **demonstrable defects**. It does **not** raise general code-quality opinions, style notes, design critiques, or taste judgments. The linter owns style. Every finding must cite concrete evidence and trace to:
 
 - An explicit requirement stated in the plan, **or**
 - A demonstrable defect in the code as written
@@ -17,41 +17,31 @@ Anything else is out of scope and must not be included in findings.
 
 ## Finding Categories In Scope
 
-- **Requirement conformance** — the code does not implement what the plan explicitly asked for
-- **Demonstrable defects** — the code fails at runtime, produces wrong behaviour, violates a contract it declares, has a security hole, causes data loss, or breaks something else in the plan
+- **Requirement conformance**: the code does not implement what the plan explicitly asked for
+- **Demonstrable defects**: the code fails at runtime, produces wrong behaviour, violates a contract it declares, has a security hole, causes data loss, or breaks something else in the plan
 
-## Severity Floor: `major`
+## Severity and Confidence
 
-Findings below `major` are recorded in the review output but never auto-applied. The severity levels, ordered from most to least consequential:
+Both are advisory triage labels carried on every finding so that whoever reads the review can sort it. Nothing thresholds on them and nothing is filtered out before the implementer sees it.
 
-- `critical` — causes data loss, security hole, crash, or corruption on a path real usage reaches
-- `major` — produces wrong behaviour or breaks a documented contract; nothing destroyed
-- `minor` — real but bounded (mishandled edge case, missing test, maintenance hazard); behaviour correct today
-- `info` — no defect (style, naming, question for author, recorded context)
+Severity, from most to least consequential:
 
-If a finding omits the severity attribute, it falls below the floor and is never auto-applied.
+- `critical`: causes data loss, a security hole, a crash, or corruption on a path real usage reaches
+- `major`: produces wrong behaviour or breaks a documented contract; nothing destroyed
+- `minor`: real but bounded (mishandled edge case, maintenance hazard); behaviour correct today
+- `info`: no defect (recorded context, a question for the author)
 
-## Confidence Floor: `high`
+Confidence, from most to least sure:
 
-Findings below `high` are recorded but never auto-applied. The confidence levels, ordered from most to least sure:
+- `high`: the evidence is in the code that was read, and the failure traces from the diff alone
+- `medium`: likely real, but rests on one assumption that was not verified (how a caller behaves, what a dependency guarantees, what a requirement was)
+- `low`: speculative (failure scenario imagined rather than traced, constraint invented, intent could not be inferred)
 
-- `high` — evidence is in the code that was read; failure can be traced from the diff alone, no assumptions needed
-- `medium` — likely real, but rests on one assumption not verified (how a caller behaves, what a dependency guarantees, what a requirement was)
-- `low` — speculative (failure scenario imagined, not traced; constraint invented; intent could not be inferred)
+Confidence matters most when it is low. LLM reviewers overstate certainty, so a reviewer that marks its own guess as `medium` is doing the reader a service. Record the label honestly rather than upgrading it to be taken seriously.
 
-If a finding omits the confidence attribute, it falls below the floor and is never auto-applied.
+## What the Gate Guarantees
 
-This attribute has no schema default on purpose. Findings that omit confidence are treated as falling below any floor. An automated consumer relies on confidence being lowered honestly; LLM reviewers systematically overstate certainty.
-
-## Round Budget: 3
-
-The gate runs up to three detect-and-fix cycles:
-
-1. Reviewer critiques the cumulative diff → findings
-2. If findings above floor exist: implement fixes, re-run mechanical gates, verify
-3. Reviewer re-checks → repeat until no new findings above floor or budget exhausted
-
-This value expressed here is advisory prose only. **Termination is enforced in code and cannot be bypassed by editing this file.** If the round budget is exhausted, the gate halts exactly as any mechanical gate failure does: the plan stays in `plans/`, findings are recorded, and the failure is documented.
+Exactly one thing, and it is enforced in code rather than here: a review that could not be certified is never reported as a clean one. A findings document that is absent, invalid against the schema, or unvalidatable because `xmllint` is missing halts the gate and says which of those happened. "The reviewer found nothing" and "the reviewer never ran" are never collapsed into each other.
 
 ## Disable the Gate
 

package/dist-web/assets/channel-DmY2Krrw.js

@@ -1 +0,0 @@
-import{U as a,C as n}from"./mermaid.core-CxfmFJso.js";const t=(r,o)=>a.lang.round(n.parse(r)[o]);export{t as c};

package/dist-web/assets/classDiagram-4FO5ZUOK-C91aiCZF.js

@@ -1 +0,0 @@
-import{s as a,a as s,c as e,C as t}from"./chunk-727SXJPM-BZxIJIkN.js";import{b as i}from"./mermaid.core-CxfmFJso.js";import"./chunk-FMBD7UC4-BkIlqLqc.js";import"./chunk-ND2GUHAM-BZAfIvWk.js";import"./chunk-55IACEB6-BYY5vsbu.js";import"./chunk-2J33WTMH-3QS28848.js";import"./index-B5AkN942.js";var n={parser:e,get db(){return new t},renderer:s,styles:a,init:i(r=>{r.class||(r.class={}),r.class.arrowMarkerAbsolute=r.arrowMarkerAbsolute},"init")};export{n as diagram};

package/dist-web/assets/classDiagram-v2-Q7XG4LA2-C91aiCZF.js

@@ -1 +0,0 @@
-import{s as a,a as s,c as e,C as t}from"./chunk-727SXJPM-BZxIJIkN.js";import{b as i}from"./mermaid.core-CxfmFJso.js";import"./chunk-FMBD7UC4-BkIlqLqc.js";import"./chunk-ND2GUHAM-BZAfIvWk.js";import"./chunk-55IACEB6-BYY5vsbu.js";import"./chunk-2J33WTMH-3QS28848.js";import"./index-B5AkN942.js";var n={parser:e,get db(){return new t},renderer:s,styles:a,init:i(r=>{r.class||(r.class={}),r.class.arrowMarkerAbsolute=r.arrowMarkerAbsolute},"init")};export{n as diagram};

package/dist-web/assets/stateDiagram-v2-BHNVJYJU-DQIao4rH.js

@@ -1 +0,0 @@
-import{b as e,a as r,s as a,S as s}from"./chunk-AQP2D5EJ-Dwpt8x10.js";import{b as i}from"./mermaid.core-CxfmFJso.js";import"./chunk-55IACEB6-BYY5vsbu.js";import"./chunk-2J33WTMH-3QS28848.js";import"./index-B5AkN942.js";var u={parser:a,get db(){return new s(2)},renderer:r,styles:e,init:i(t=>{t.state||(t.state={}),t.state.arrowMarkerAbsolute=t.arrowMarkerAbsolute},"init")};export{u as diagram};