strikethroo 3.17.2 → 3.19.0

package/templates/strikethroo/config/config.yaml

@@ -1,12 +1,16 @@
 # Strikethroo workspace configuration.
 #
-# This is the single structured configuration file for the workspace: every
-# configurable feature claims one top-level section here rather than adding
-# its own YAML file. Edit it directly or through the Config tab of the
-# Customize section in the web app (`npx strikethroo serve`) — note that
-# saving from the web UI rewrites this file and does not preserve comments.
+# This file is local to this workspace and ignored by the workspace .gitignore.
+# Harness permissions, installed models, and routing preferences can differ by
+# developer and machine. Edit it directly or through the Config tab of the
+# Customize section in the web app (`npx strikethroo serve`). Saving from the
+# web UI rewrites this file and does not preserve comments.
 #
 # Sections:
+#   harnesses — exact ordered argv elements added when Strikethroo invokes the
+#     named external CLI. The local user owns the resulting permissions. Values
+#     are never split or shell-expanded. Keep secrets and machine paths out of
+#     argv; use each harness's authentication and user configuration instead.
 #   execution_routing — automatic per-task execution routing. Profiles are
 #     arbitrary, project-defined routing categories;
 #     each `description` tells the task-generation LLM when the profile
@@ -23,5 +27,90 @@
 #     contract and an illustrative example:
 #     https://strikethroo.canpicasoft.com/customization.html
 
+harnesses:
+  claude:
+    cli_args:
+      - --dangerously-skip-permissions
+  codex:
+    cli_args:
+      - --sandbox
+      - workspace-write
+  cursor:
+    cli_args:
+      - --force
+  gemini:
+    cli_args:
+      - --approval-mode
+      - yolo
+  copilot:
+    cli_args:
+      - --allow-all
+  opencode:
+    cli_args:
+      - --auto
+
 execution_routing:
-  profiles: {}
+  profiles:
+    docs-and-config:
+      description: >-
+        Prose, documentation, and declarative configuration edits with no
+        intricate control flow: Markdown authoring, README and docs-site
+        updates, technical writing, skill-prompt copy, and YAML/JSON config
+        changes. Typical skills: markdown, technical-writing, documentation,
+        yaml, json, jekyll, markdown-authoring. Complexity score roughly 3-4.
+        Choose this only when the task requires no cross-module code reasoning.
+      models:
+        - model: sonnet
+          harness: claude
+          reasoning_effort: medium
+        - model: gpt-5.6-sol
+          harness: codex
+          reasoning_effort: low
+        - model: opencode-go/minimax-m3
+          harness: opencode
+        - model: composer-2.5
+          harness: cursor
+    standard-implementation:
+      description: >-
+        Everyday feature and bug-fix work scoped to a handful of files with
+        clear acceptance criteria: TypeScript/Node CLI logic, React components
+        and Tailwind/CSS styling, Bash scripts, and their unit/e2e tests
+        (Vitest, Jest, Playwright). Typical skills: typescript, react,
+        react-components, css, tailwindcss, bash, nodejs, vitest, jest,
+        playwright, testing. Complexity score roughly 4-6. This is the default
+        profile when a task fits neither docs-and-config nor
+        complex-architecture.
+      models:
+        - model: opus
+          harness: claude
+          reasoning_effort: medium
+        - model: gpt-5.6-sol
+          harness: codex
+          reasoning_effort: medium
+        - model: opencode-go/kimi-k2.7-code
+          harness: opencode
+        - model: composer-2.5
+          harness: cursor
+    complex-architecture:
+      description: >-
+        High-difficulty, cross-cutting, or design-heavy work: data-model and
+        type-system design, non-trivial refactors, build-tooling and bundler
+        changes (esbuild, Vite), server/HTTP/SSE and API design, runtime prompt
+        composition, MCP/protocol work, and any task whose blast radius spans
+        multiple subsystems or carries subtle correctness constraints. Typical
+        skills: data-modeling, typescript-refactoring, refactoring,
+        build-tooling, esbuild, vite, node-http, server-sent-events,
+        mcp-protocol, secure-coding, html-sanitization. Complexity score roughly
+        6-7, or any task with wide blast radius regardless of score.
+      models:
+        - model: opus
+          harness: claude
+          reasoning_effort: xhigh
+        - model: gpt-5.6-sol
+          harness: codex
+          reasoning_effort: high
+        - model: opencode-go/glm-5.2
+          harness: opencode
+          reasoning_effort: max
+        - model: composer-2.5
+          harness: cursor

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/templates/strikethroo/gitignore

@@ -1,18 +1,21 @@
+# Local workspace configuration.
+#
+# Harness permissions, model routing, and resolver settings depend on the
+# developer's machine. Init still creates and hash-tracks this file so re-runs
+# can preserve local edits and report template conflicts.
+config/config.yaml
+
 # Code review gate artifacts.
 #
-# The review gate writes a recorded base commit and one directory per round
-# (review.xml plus the recorded-versus-actionable findings partition) into the
-# plan it is reviewing. All of it is machine-generated output scoped to a single
-# execution: the base commit is live only from capture through the final round,
-# and each round supersedes the last.
+# The report-only review gate writes a recorded base commit and review.xml into
+# the plan it is reviewing. A failed review may also leave reviewer-output.txt
+# for diagnosis. These files are machine-generated output for one execution.
 #
 # Ignoring it also keeps the gate from reviewing itself. The reviewed diff runs
 # from the recorded base against the working tree, and untracked files are in
-# scope — the gate synthesizes an add-diff for each one. What keeps review
-# output out of the next round is these ignore rules: the gate enumerates
-# untracked paths with `git ls-files --others --exclude-standard`, which applies
-# them, so a round-1 review.xml is invisible to round 2 whether or not anything
-# committed it.
+# scope. The gate synthesizes an add-diff for each one. These rules keep its own
+# output out because the gate enumerates untracked paths with
+# `git ls-files --others --exclude-standard`.
 #
 # Both locations are listed because a completed plan directory is moved from
 # plans/ to archive/ wholesale, carrying its review/ directory with it.

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};