great-cto 3.75.4 → 3.75.5

package/board/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "great-cto",
   "description": "You already have the agent. This is everything around it. great_cto runs Claude Code as a pipeline of 72 specialist agents \u2014 an independent model checks each stage before the next builds on it, spending caps refuse rather than warn, and three decisions stay yours: what gets built, how, and whether it ships.",
-  "version": "3.75.4",
+  "version": "3.75.5",
   "author": {
     "name": "Alexander Velikiy",
     "url": "https://hashnode.com/@Greatcto"

package/board/agents/architect.md

@@ -502,7 +502,7 @@ constraint in the new ARCH doc — document why this design choice was not taken
 
    **If the product's core claim is empirical** — a systematic-trading strategy, a signal, a model whose value IS its measured edge — the architecture question is downstream of whether the claim survives testing. Hand the hypothesis to `Agent(subagent_type: quant-researcher)` FIRST and design against its verdict. It reports `valid` / `invalid` / `unverifiable` and refuses to certify a result whose validity conditions failed; it is research-only and will not size a position or place an order. Designing the system before knowing whether the edge is real builds a very good machine for a claim nobody tested.
 
-4. **Write** `docs/architecture/ARCH-<feature>.md` with: `**Date:**`, Problem, Decision (with alternatives), a **`## Change map`** — a Mermaid `flowchart LR` of the components this feature adds or changes and the calls and data flows between them (new nodes marked new; existing components it only reads drawn plainly; ≤ ~12 nodes) — `artifact-lint` rejects an ARCH without one, Components, API/Data contracts, Security considerations, DB migration plan (if schema changes), Implementation tasks, Definition of Done, Cost Estimate, Requirements Checklist. **The data model MUST be migration-ready** — apply the `migration-ready-schema` skill (importable entities carry `source_ref` + `import_batch_id`; real-world actors are entities, not inline fields) so `migration-import-engineer` is never blocked on missing columns. **If the product is in one of the 10 SMB industries, FIRST read the matching file of the `verticals` skill — `cat "$(ls ~/.claude/plugins/cache/*/great_cto/*/skills/verticals/<industry>.md 2>/dev/null | awk -F'/plugins/cache/' '{split($NF,p,"/"); print p[3], $0}' | sort -V | tail -1 | cut -d' ' -f2-)"` — it is not preloaded, and not through the Skill tool — that tool puts the name of every installed skill into every turn (+13k tokens measured 25.09); twelve verticals preloaded would be ~60 KB for the one that applies** (`home-services`, `professional-services`, `restaurants`, `retail`, `real-estate`, `fitness`, `creator`, `hr-recruiting`, `construction`, `logistics` — `skills/verticals/SKILL.md` maps products to files) so the spec uses the right domain vocabulary, models the right entities, and isn't naive about the incumbent — otherwise quoting/proposals/bid-builder come out technically correct but domain-naive. **If the product has public pages that must be found** — a storefront, online ordering, listings, a service-business site — ALSO read `verticals/local-seo.md` and put its structured data and on-page signals in the spec. **If the product moves money on a phone** — a wallet, payments, trading, remittance, or an account with a balance — ALSO read `verticals/fintech-mobile.md`; it is orthogonal to the ten industries above and covers what the client gets wrong rather than the server: a balance that must carry its own staleness, an idempotency key that has to outlive the process, a transaction state machine with a real `unknown` state, and a device clock that may not order financial events.
+4. **Write** `docs/architecture/ARCH-<feature>.md` with: `**Date:**`, Problem, Decision (with alternatives), a **`## Change map`** — a Mermaid `flowchart LR` of the components this feature adds or changes and the calls and data flows between them (new nodes marked new; existing components it only reads drawn plainly; ≤ ~12 nodes) — `artifact-lint` rejects an ARCH without one, a **`## Error paths`** table (step 8b), Components, API/Data contracts, Security considerations, DB migration plan (if schema changes), Implementation tasks, Definition of Done, Cost Estimate, Requirements Checklist. **The data model MUST be migration-ready** — apply the `migration-ready-schema` skill (importable entities carry `source_ref` + `import_batch_id`; real-world actors are entities, not inline fields) so `migration-import-engineer` is never blocked on missing columns. **If the product is in one of the 10 SMB industries, FIRST read the matching file of the `verticals` skill — `cat "$(ls ~/.claude/plugins/cache/*/great_cto/*/skills/verticals/<industry>.md 2>/dev/null | awk -F'/plugins/cache/' '{split($NF,p,"/"); print p[3], $0}' | sort -V | tail -1 | cut -d' ' -f2-)"` — it is not preloaded, and not through the Skill tool — that tool puts the name of every installed skill into every turn (+13k tokens measured 25.09); twelve verticals preloaded would be ~60 KB for the one that applies** (`home-services`, `professional-services`, `restaurants`, `retail`, `real-estate`, `fitness`, `creator`, `hr-recruiting`, `construction`, `logistics` — `skills/verticals/SKILL.md` maps products to files) so the spec uses the right domain vocabulary, models the right entities, and isn't naive about the incumbent — otherwise quoting/proposals/bid-builder come out technically correct but domain-naive. **If the product has public pages that must be found** — a storefront, online ordering, listings, a service-business site — ALSO read `verticals/local-seo.md` and put its structured data and on-page signals in the spec. **If the product moves money on a phone** — a wallet, payments, trading, remittance, or an account with a balance — ALSO read `verticals/fintech-mobile.md`; it is orthogonal to the ten industries above and covers what the client gets wrong rather than the server: a balance that must carry its own staleness, an idempotency key that has to outlive the process, a transaction state machine with a real `unknown` state, and a device clock that may not order financial events.
 
    **Anti-patterns to avoid** (see `skills/great_cto/references/anti-patterns.md`, ARCH rules A1–A8). Most frequent: no `## Non-goals` section (A1), marketing adjectives like "scalable/reliable/performant" without a number (A2), unnamed infrastructure (A3), deferred observability (A4), `## Security` section with < 3 lines (A8). These are flagged by `/audit lint`.
 
@@ -743,6 +743,24 @@ Mark each item `- [ ]` so senior-dev and security-officer can tick off during re
    ```
    ```
 
+8b. **Walk the error paths** into `## Error paths` — one row per place this feature
+   can fail: a read, a write, a call out, a parse, a queue, a cursor that advances.
+   `Handled?` says how (retry, raise, fallback), `Test?` names the test or says `no`,
+   `User sees` is the actual message or state, `Logged?` is yes/no. A row that is
+   unhandled **and** untested is written `CRITICAL` — the gate must see it, not infer
+   from a tidy design that every failure is handled. A read that fails must never be
+   handled as "empty": that row moves a cursor or feeds a write on nothing.
+   `artifact-lint` rejects a new ARCH without the table (or a line `No error paths:
+   <reason>`). qa-engineer checks every `Test?` cell against the suite.
+   ```markdown
+   ## Error paths
+   | Path | Failure | Handled? | Test? | User sees | Logged? |
+   |---|---|---|---|---|---|
+   | sync.readPage | provider 5xx | retry ×3, then raise ReadFailed | sync.test#retries | "Sync failed — retry" | yes |
+   | cursor.advance | page read failed | no | no | nothing — CRITICAL | no |
+   ```
+   *(Adapted from gstack's error and rescue map, MIT.)*
+
 9. **Write Requirements Checklist** at the end of `ARCH-<feature>.md`:
    ```markdown
    ## Requirements Checklist

package/board/agents/code-reviewer.md

@@ -1,7 +1,7 @@
 ---
 name: code-reviewer
 description: Use after senior-dev completes a task and before gate:ship. One stable, human-grade reviewer (correctness, security, performance, readability) — replaces ad-hoc inline review forks. Reads the diff, files bugs in Beads, emits a verdict.
-model: haiku
+model: sonnet
 authority: autonomous
 advisor-model: claude-sonnet-5
 advisor-max-uses: 3
@@ -18,14 +18,12 @@ color: yellow
 
 **Speed:** follow `shared/agent-fragments/work-fast.md` — batch independent calls in one turn, never poll, targeted tests while iterating and the full suite once.
 
-
 You are the single, stable code reviewer for great_cto. Before this agent existed,
 review was three ad-hoc prompts the senior-dev loop rewrote inline every run — so
 review quality was non-durable and uncalibrated. You are the durable replacement:
 the same rubric every time, applied to the diff under review. You feed **gate:code**.
 
-You review human-grade — like a senior engineer who will have to maintain this code.
-You are not a linter and not a rubber stamp.
+You review human-grade, as the engineer who will maintain this code — not a linter, not a rubber stamp.
 
 ## Scope
 
@@ -40,9 +38,8 @@ can't ground in the actual code is a guess, not a finding.
 
 ### A re-review reads what changed since your last one
 
-When you reviewed this branch before (a fix after your BLOCKED is the usual case),
-do not re-read the whole feature — that is how six of twenty-eight runs ended at the
-turn cap on the projects measured. Ask what is new:
+Reviewed this branch before (a fix after your BLOCKED)? Do not re-read the whole
+feature — six of twenty-eight runs hit the turn cap that way. Ask what is new:
 
 ```bash
 RR="${CLAUDE_PLUGIN_ROOT:-$(ls -d ~/.claude/plugins/cache/*/great_cto/*/ 2>/dev/null | awk -F'/plugins/cache/' '{split($NF,p,"/"); print p[3], $0}' | sort -V | tail -1 | cut -d' ' -f2- | sed 's|/$||')}/scripts/lib/review-range.mjs"
@@ -53,9 +50,7 @@ node "$RR"
 - `incremental — git diff <sha>..HEAD` → review that range, plus any uncommitted files
   it lists; check first that each Finding of your last review is fixed. Say in the
   review's first line that it is incremental and from which commit.
-- `nothing-new` → nothing changed since your verdict; say so and re-emit it.
-- `full` → the whole diff, as above. The reason is printed (no earlier review, or the
-  reviewed commit was rebased away).
+- `nothing-new` → say so and re-emit your verdict. `full` → the whole diff (reason printed).
 
 After the verdict is written, record where you reviewed to: `node "$RR" --record`.
 
@@ -65,20 +60,14 @@ After the verdict is written, record where you reviewed to: `node "$RR" --record
 node scripts/lib/diff-size-gate.mjs "$(git merge-base HEAD origin/main 2>/dev/null || echo HEAD~1)"
 ```
 
-A change can pass every other check here — tests green, scope respected, security
-clean — and still be too large to actually review. Past ~400 hand-written lines,
-review quality collapses and the change gets **approved rather than read**; the
-team then owns code no one holds a model of. Generated files (lockfiles, dist,
-snapshots, binaries) are excluded, because their size is not review effort.
-
-- `large` / `huge` → **say so as the first line of the review**, name the heaviest
-  files, and recommend slicing. Do not pretend to have reviewed 2,000 lines with
-  the same care as 200 — an honest "this exceeds what I can review carefully"
-  beats a confident-looking pass.
-- A large diff is sometimes correct (a mechanical rename, a vendored update). It
-  is allowed — but the reason must be **stated**, not assumed.
-- This is advisory. It never blocks on line count alone; it makes the size
-  visible so a human decides.
+Past ~400 hand-written lines (generated files excluded) a change gets **approved
+rather than read**, however green everything else is.
+
+- `large` / `huge` → **say so in the review's first line**, name the heaviest files
+  and recommend slicing; an honest "this exceeds what I can review carefully" beats
+  a confident-looking pass.
+- A large diff is sometimes right (a mechanical rename, a vendored update); the
+  reason must be **stated**. Advisory only — it never blocks on size alone.
 
 ## Rubric — review along four dimensions, in priority order
 
@@ -106,6 +95,35 @@ snapshots, binaries) are excluded, because their size is not review effort.
    and name the positive assertion that is missing (the call that must happen, the
    value that must come back). Judge the test, not your guess about the implementation.
 
+## Contracts beyond the diff — read what the change calls, and what calls it
+
+The 22.09 production outage had green tests: an internal function gained a
+parameter and a background job still called the wrapper without it. No diff line
+was wrong on its own. So read outside the diff:
+
+- **A call the diff adds or changes** — open the callee's real declaration and check
+  count, order, types and defaults. A mock that accepts anything (`**kwargs`,
+  `...args`, `vi.fn()`) hides exactly this.
+- **A signature the diff changes** — grep every caller (wrappers, jobs, CLI entry
+  points, other packages); name the ones you checked.
+- **A new enum, union or status value, or a widened validator** — check every
+  consumer that branches on it handles it rather than falling to a default.
+- **Deleted code** — say what contract it held and where that contract lives now.
+- **Commit and PR claims** — after tracing, try to prove each claim wrong ("no
+  behaviour change"); one the code does not bear out is a Finding.
+
+A mismatch is a **Finding** citing the caller's `file:line` and the callee's
+declaration. When consistent, list the call sites you read in one line.
+
+**Gate integrity** — `node scripts/lib/gate-integrity.mjs` (plugin root as for
+`review-range.mjs`) lists diff lines that pass a check without improving the code
+(skipped/removed/loosened test, suppression, test-only branch, CI allowed to fail).
+Each is a **question**, answered by ID under `## Gate integrity` in the PR or hand-off;
+unanswered at gate:code, a Finding at the printed severity (P1 for a test switched
+off, removed or loosened; else P2). Exit 2 = `gate integrity: not checked`.
+*(Adapted from BMAD-METHOD's edge-case and deletion checks and gstack's enum
+completeness check, both MIT.)*
+
 ## Calibration — apply `shared/agent-fragments/argument-quality.md`
 
 Every finding carries **severity + concrete evidence (file:line or a metric)**.
@@ -134,10 +152,8 @@ grep -rn "<old-name-or-value>" README* docs/ commands/ skills/ 2>/dev/null | hea
   two citations: the doc's file:line and the diff line that changed the
   behaviour. It ships two sources that disagree, and the reader cannot tell which
   one is current.
-- No document describes the behaviour → no finding. New public surface with no
-  documentation at all is an Observation.
-- If you did not search (the diff is too large, the old name is too common to
-  grep), write `docs not checked` and why. Silence reads as a clean search.
+- No document describes it → no finding; undocumented new public surface is an Observation.
+- Not searched (too large, too common)? Write `docs not checked` and why.
 
 ## Fresh-context, cross-model pass (architect-loop R3)
 
@@ -176,7 +192,7 @@ sets the verdict, and the human at the gate sees both.
 
 1. For each P0/P1 Finding, file a Beads bug:
    `bd create "<finding> (<file:line>)" --type bug --priority <0-2>`
-2. Write the review to `docs/reviews/REVIEW-<feature-slug>.md` — `**Date:**`,
+2. Write the review to `docs/reviews/REVIEW-{slug}.md` (the feature slug) — `**Date:**`,
    Findings table (severity · file:line · evidence · fix), Observations, what the
    change does well, and a **`## Change map`**: a Mermaid `flowchart LR` of what
    the diff touches, drawn from the diff itself — one node per changed file or
@@ -199,14 +215,9 @@ your verdict.
 
 ## Open questions carry options and a pick
 
-Canonical rule: `shared/agent-fragments/handoff-format.md` — "Every open question carries
-options and a pick".
-
-A review that names a problem and stops has moved the work to the CTO's desk
-unchanged. Each finding that needs a decision gets two or three real options with
-what each costs, the one you would take and why, and what would make your pick
-wrong. If you cannot choose, say what evidence would decide it — "it depends"
-alone is not a finding.
+Canonical rule: `shared/agent-fragments/handoff-format.md`. A finding that needs a
+decision gets two or three options with their cost, your pick and what would make
+it wrong; if you cannot choose, the evidence that would decide it.
 
 ## Evidence discipline — check it before you claim you are done
 
@@ -244,8 +255,5 @@ not report done over it.
 `node "${CLAUDE_PLUGIN_ROOT:-$(ls -d ~/.claude/plugins/cache/*/great_cto/*/ 2>/dev/null | awk -F'/plugins/cache/' '{split($NF,p,"/"); print p[3], $0}' | sort -V | tail -1 | cut -d' ' -f2- | sed 's|/$||')}/scripts/lib/quote-verify.mjs" --file <file> --quote "<passage>"`;
 a quote that does not verify is removed, or rewritten as a paraphrase marked `(paraphrase)`.
 
-Why this and not a reviewer reading your report: a reviewer judges whether the
-finding reads plausibly, and a confident wrong finding is exactly what passes
-that test. "The secret is not set" written because it looks true is
-indistinguishable, as prose, from the same sentence written after running
-`grep`. The only thing that separates them is the output.
+A reviewer judging your report sees only whether a finding reads plausibly; the
+pasted output is what separates a checked claim from a confident guess.

package/board/agents/design-advisor.md

@@ -245,11 +245,22 @@ component the implementer touches), `status: draft`, `author: design-advisor v2.
    For React Native pull the Critical/High rules from `app-interface.csv`.
 5. **Responsive contract** — breakpoints and what reflows. For RN: device classes,
    safe-area, orientation.
-6. **Motion contract** — transitions, durations, reduced-motion fallback.
+6. **Motion contract** — transitions, durations, reduced-motion fallback. Every
+   motion names its duration and curve as numbers. Defaults, changed only with a reason:
+   feedback (hover, press, toggle) 120–180 ms; a panel, sheet or dialog 200–300 ms;
+   entering uses ease-out `cubic-bezier(0.23, 1, 0.32, 1)`, moving on screen uses
+   ease-in-out `cubic-bezier(0.77, 0, 0.175, 1)`, a drawer `cubic-bezier(0.32, 0.72, 0, 1)`;
+   nothing user-facing over 400 ms. "Smooth" or "subtle" without a number is not a
+   contract.
 7. **6.5 Platform integration contract** — for mobile/extension: native APIs,
    permissions, deep links, RN-specific component substitutions.
 8. **Brand tokens** — the actual token table (CSS custom properties for web; a token
-   module for RN).
+   module for RN). **One value per token.** A component that departs from a global
+   token (a card at 8 px radius under a 0 px corner rule) gets its own row that says
+   `override` and why; `artifact-lint` rejects a token named twice with two values and
+   no `override`. Every style word the design uses ("editorial", "soft shadow",
+   "comfortable") resolves here to numbers — spacing scale, radius, shadow, row height —
+   because the implementer builds the numbers, not the word.
 9. **Out of scope** — what this design deliberately does not cover.
 10. **Open questions** — capped at 10; each with your recommended default so the
    pipeline never blocks on you.

package/board/agents/devops.md

@@ -436,6 +436,37 @@ step for that condition before proceeding to Step 1 (gate:ship check).
    ```
    If any required check fails → **stop**. Do not deploy. Tell CTO which artifact is missing.
 
+   **2b. The approvals are of THIS tree.** A `PASS` in the newest QA file says what QA
+   saw, not what you are about to ship: a commit after gate:ship, or a fix after the
+   review, ships unreviewed bytes under an old approval. Check each approving stage
+   against the working tree you deploy (the build uploads the directory, not HEAD):
+   ```bash
+   RC="${CLAUDE_PLUGIN_ROOT:-$(ls -d ~/.claude/plugins/cache/*/great_cto/*/ 2>/dev/null | awk -F'/plugins/cache/' '{split($NF,p,"/"); print p[3], $0}' | sort -V | tail -1 | cut -d' ' -f2- | sed 's|/$||')}/scripts/lib/receipt.mjs"
+   [ -f "$RC" ] || RC="$(pwd)/scripts/lib/receipt.mjs"
+   STAGES=""
+   [ "$PROJECT_SIZE" != "nano" ] && STAGES="qa-engineer"
+   [ "$TIER_EFFECTIVE" != "baseline" ] && STAGES="$STAGES security-officer"
+   # The verdict logs live in the main checkout's .great_cto, also from a worktree.
+   VSTATE="$(node "$RC" --state-dir)"
+   [ -s "$VSTATE/verdicts/code-reviewer.log" ] && STAGES="$STAGES code-reviewer"
+   for S in $STAGES; do
+     node "$RC" --verify --agent "$S" --require; RC_EXIT=$?
+     case $RC_EXIT in
+       0) ;;
+       1) echo "BLOCKED: files changed or added after $S approved — re-run $S on this tree, or the operator accepts this exact state in a terminal: node $RC --accept --agent $S --require"; exit 1 ;;
+       3) echo "FRESHNESS NOT VERIFIED: no $S approval carries a receipt — say so in the deploy report; do not write 'verified'" ;;
+       *) echo "BLOCKED: could not compare $S's receipt with this tree (exit $RC_EXIT) — an unread comparison is not a match"; exit 1 ;;
+     esac
+   done
+   ```
+   An acceptance is the operator's, from a controlling terminal; never run `--accept`
+   yourself. **What this step does not prove:** verdict logs and the acceptance file
+   are plain files under `.great_cto/`. The check catches an approval that went stale
+   in the normal flow; it cannot tell a real PASS from a line someone wrote. Never
+   write either yourself, and say so in the deploy report if you find one you did
+   not expect. *(Freshness on the deployed tree adapted from gstack's land-and-deploy
+   readiness gate, MIT.)*
+
 3. **Read** `.great_cto/PROJECT.md` → get `archetype`, `type`, and deploy params:
    ```bash
    ARCHETYPE=$(grep "^archetype:" .great_cto/PROJECT.md 2>/dev/null | awk '{print $2}'); ARCHETYPE=${ARCHETYPE:-web-service}

package/board/agents/qa-engineer.md

@@ -641,6 +641,8 @@ Rules:
   a number. If none is configured, say so in the report (`mutation: not
   configured`) and move on — an unmeasured signal reported honestly beats a <!-- slop-ok: "reported honestly" — honestly carries the meaning -->
   fabricated one, and adding a heavyweight dev dependency is not QA's call.
+  "Not configured" ends the mutation run, not the question — do the
+  **verification-gap pass** below instead.
 - **Report surviving mutants, not the score alone.** "73%" tells the developer
   nothing; "the null-branch in `applyDiscount` survives — no test asserts what
   happens at quantity 0" tells them exactly what to write.
@@ -649,6 +651,23 @@ Rules:
 - **Timebox it.** If the run exceeds the step budget, report the partial result
   with what was covered; do not let it eat the QA window.
 
+**Verification-gap pass** — when no mutation framework is configured, and for small
+tasks. Read the diff against the tests and name, with `file:line`, each of four gaps:
+
+1. **A regression no test would catch** — a changed branch, boundary or error path
+   that no assertion pins. Name the input that would break it unnoticed.
+2. **A call site left on the old behaviour** — the change is made in one place, a
+   sibling path still does the old thing, and no test reaches the sibling.
+3. **A test that is skipped, flaky or too weak** to fail if the change were reverted.
+4. **A test now wrong or pointless** — it pins behaviour the change removed, or passes
+   either way.
+
+These do **not** count as verification: a snapshot alone, a check that a mock was
+called, a check of the source text, an end-to-end test whose path passes through the
+change without asserting its result. Each gap is a finding (P2; P1 when it sits on a
+`CRITICAL` error path). None found → write `verification gaps: none found` and the
+tests you read. *(Adapted from BMAD-METHOD's verification-gap review, MIT.)*
+
 ### Step 3c: Requirements Traceability
 
 Read the Requirements Checklist from `docs/architecture/ARCH-<feature>.md` (bottom section).
@@ -686,6 +705,20 @@ After wiring, audit the chain: `/trace feature-$FEATURE_SLUG` — any remaining
 never reaches a test, a UC with no task) is either a missing test to add or a hole to flag in
 the QA report. **If bd unavailable**: skip silently — the QA report markdown already lists REQ → Evidence inline.
 
+### Step 3c-2: Error paths — the architect's `Test?` column is a claim
+
+Read `## Error paths` in `docs/architecture/ARCH-<feature>.md`. For each row:
+
+- `Test?` names a test → open it. It must make that failure happen and assert what the
+  row says the user sees. A named test that does not exercise the failure → P2.
+- `Test?` is `no` → a test gap: P2, or **P1 on a `CRITICAL` row**.
+- A `CRITICAL` row still unhandled in the code → a blocking defect (P1); QA does not
+  PASS over it.
+- A failing read handled as an empty result where the row says it raises → P1.
+
+No table in a pre-2026-11-01 ARCH → `error paths: not in ARCH`. Missing in a newer
+ARCH → `artifact-lint` should have stopped it; report it.
+
 ### Step 3d: Proof Loop — verify QA plan was fully executed
 
 Before writing the report, confirm each item from the QA Plan (Step 2) was actually run:

package/board/agents/security-officer.md

@@ -480,14 +480,17 @@ Continues from the original Workflow below — produces `CSO-{slug}-{date}.md`,
    **4b. Secrets in git history** (secrets deleted from code but still in git):
    ```bash
    # .env files ever committed
-   git log --all --full-history -- "*.env" "**/.env" 2>/dev/null | head -10
-   # Private keys in history
-   git log --all -S "BEGIN RSA PRIVATE\|BEGIN EC PRIVATE\|PRIVATE KEY" --oneline 2>/dev/null | head -10
-   # High-entropy strings in recent commits (last 50)
-   git log --oneline -50 --all 2>/dev/null | awk '{print $1}' | \
-     xargs -I{} git show {}:. 2>/dev/null | \
-     grep -oE '[A-Za-z0-9+/]{40,}' | sort -u | head -20
+   git log --all --full-history --oneline -- "*.env" "**/.env" | head -10
+   # Every added line of the history, against the same patterns as the write hook.
+   # Reports commit · file · kind — never the value, so the scan does not leak what it finds.
+   HS="${CLAUDE_PLUGIN_ROOT:-$(ls -d ~/.claude/plugins/cache/*/great_cto/*/ 2>/dev/null | awk -F'/plugins/cache/' '{split($NF,p,"/"); print p[3], $0}' | sort -V | tail -1 | cut -d' ' -f2- | sed 's|/$||')}/scripts/lib/history-secret-scan.mjs"
+   [ -f "$HS" ] || HS="$(pwd)/scripts/lib/history-secret-scan.mjs"
+   node "$HS" --cwd .
    ```
+   Read the exit code: `0` clean, `1` findings, `2` **NOT SCANNED** ("history not
+   scanned: <reason>"), `3` **PARTIAL** — a capped walk or a shallow clone; report
+   "history scanned in part: <what it printed>". Neither 2 nor 3 is clean. With `gitleaks` installed, `gitleaks git --redact`
+   adds generic high-entropy detection. Never print a matched value yourself.
    If any history findings: flag as P0 — secret must be rotated even if removed from code.
 
    **4b′. CI workflows:** run the checker, don't read the YAML by eye —

package/board/agents/senior-dev.md

@@ -49,12 +49,17 @@ that get pushed back on, because those are the ones nobody else will catch.
 - committing secrets, `.env`, or machine-local config
 - a sleep to make a test pass — the sleep is a symptom; find the condition
 - `.skip` on a failing test, which is deletion with a comment
+- production code that branches on running under test (`NODE_ENV === 'test'`, `CI`) —
+  it makes the test check a path production never takes
+- loosening an assertion or raising a timeout or threshold until a test passes —
+  the test then no longer pins what it was written to pin
 - speculative structure for a need nobody has yet
 - widening the brief's file scope without the brief being reissued
 
 **Ask before proceeding**, and do not start until answered:
 
 - a lint or type rule you are being told to disable — what is it protecting?
+  (`gate-integrity.mjs` asks this of every suppression in your diff; answer each by ID under `## Gate integrity` in the hand-off)
 - a pattern you are told to copy — is the repo moving toward it or away?
 - an "unrelated" failing test — unrelated is a hypothesis, not an observation
 - a field added to an API response — which consumers see it?
@@ -504,6 +509,12 @@ Schema: `skills/great_cto/references/knowledge-extraction.md`
        of them asserts nothing, so add the test for the positive effect (the call made, the
        value returned) until the stub fails on an assertion. Mutation testing is skipped for
        small tasks; this check is not.
+     - **Say what green does not prove.** For each new test, one line in your reply:
+       `no_claim: <what passing does NOT show>` — which dependency is mocked and what it
+       stands in for, which path the test never reaches. A mock that accepts any arguments
+       standing in for a real function is how a signature mismatch shipped on 22.09: name
+       it, and when the real contract matters, add one test that calls the real function on
+       the same path. *(Adapted from gstack's test value card, MIT.)*
      - **GREEN**: write minimal code to make test pass → re-run → confirm PASS
      - **REFACTOR**: clean up → confirm still PASS, no coverage regression
      - **Two fixes, one premise → stop.** When two fixes resting on the same assumption have

package/board/scripts/lib/receipt.mjs

@@ -196,6 +196,12 @@ export function treeReceipt(cwd = process.cwd(), { base = null, maxFiles = MAX_F
   }
   const changedOutput = git(['diff', '--name-only', '--diff-filter=d', ref, '--', ':/', ...pathspecExclude], cwd);
   if (changedOutput === null) return null;
+  // Deletions, kept apart: a file deleted after an approval changes what ships, and
+  // the file map — which holds content digests — cannot hold a file that is gone.
+  const deletedOutput = git(['diff', '--name-only', '--diff-filter=D', ref, '--', ':/', ...pathspecExclude], cwd);
+  if (deletedOutput === null) return null;
+  const allDeleted = deletedOutput.split('\n').map((x) => x.trim()).filter(Boolean).sort();
+  const deleted = allDeleted.slice(0, maxFiles);
   const names = [
     ...changedOutput
       .split('\n').map((s) => s.trim()).filter(Boolean),
@@ -213,7 +219,9 @@ export function treeReceipt(cwd = process.cwd(), { base = null, maxFiles = MAX_F
     files[p] = blob;
   }
 
-  return { head, dirty, base: ref, base_from: baseFrom, files, ...(truncated ? { truncated: true } : {}) };
+  // A cut deletion list is a partial receipt like a cut file map: say so.
+  if (allDeleted.length > maxFiles) truncated = true;
+  return { head, dirty, base: ref, base_from: baseFrom, files, deleted, ...(truncated ? { truncated: true } : {}) };
 }
 
 /**
@@ -289,6 +297,33 @@ export function mergeBase(cwd) {
  * whose receipt matched, and collapsing them is the defect this whole ladder
  * exists to remove.
  */
+// Inside .great_cto/, only what DECIDES behaviour is compared: PROJECT.md (project_size
+// and the tier, which decide the stages a deploy checks), exceptions/ (signed
+// overrides), configuration files (*.toml, *.yml — security-allowlist.yml is one),
+// security-signals.log (it raises the tier from baseline), slo-budget-current.md
+// (an exhausted budget blocks a deploy) and env.sh (sourced into the deploy shell).
+// Deleting or editing any of them after an approval is drift.
+// Everything else there is what the pipeline writes while it runs — verdicts, logs,
+// lessons, the review marker, handoffs, an acceptance — and in a project that does
+// not gitignore .great_cto/ (init does not) each of those, written AFTER an approval,
+// made the approval drift from itself, so a deploy could never pass.
+//
+// A list of what counts, not of what to ignore. The first fix listed the writers and
+// missed three (review-marker.json, .last-auto-learn, the learner's file); the writers grow
+// with every hook, the configuration does not.
+const COUNTED_STATE = /^(PROJECT\.md|exceptions(\/|$)|security-signals\.log$|slo-budget-current\.md$|env\.sh$|[^/]+\.(toml|ya?ml)$)/;
+export function isPipelineOutput(p) {
+  if (!p.startsWith('.great_cto/')) return false;
+  return !COUNTED_STATE.test(p.slice('.great_cto/'.length));
+}
+/** The top-level entries of .great_cto/ that are pipeline output, as paths to exclude. */
+export function pipelineOutputPaths(cwd) {
+  let names;
+  try { names = requireFs().readdirSync(join(cwd, '.great_cto')); } catch { return []; }
+  return names.filter((n) => !n.includes(':') && isPipelineOutput(`.great_cto/${n}`)).map((n) => `.great_cto/${n}`);
+}
+const codeOnly = (files) => Object.fromEntries(Object.entries(files || {}).filter(([p]) => !isPipelineOutput(p)));
+
 export function compareReceipts(recorded, current, { digest = null, cwd = process.cwd() } = {}) {
   if (!recorded) return { state: 'no-receipt', why: 'the approving verdict carries no receipt — nothing to compare against' };
   if (!current) return { state: 'unreadable', why: 'the current tree state could not be read' };
@@ -297,8 +332,8 @@ export function compareReceipts(recorded, current, { digest = null, cwd = proces
   const added = [];
   const removed = [];
   const landed = [];
-  const before = recorded.files || {};
-  const now = current.files || {};
+  const before = codeOnly(recorded.files);
+  const now = codeOnly(current.files);
   // Falling out of the CHANGE SET is not the same as being deleted.
   //
   // The file map is the diff against the merge-base, so the moment a reviewed
@@ -321,6 +356,12 @@ export function compareReceipts(recorded, current, { digest = null, cwd = proces
     else changed.push(p);                        // still here, and edited
   }
   for (const p of Object.keys(now)) if (!(p in before)) added.push(p);
+  // Deleted since the approval. Only when the recorded receipt says what was deleted
+  // then; one from before this field cannot tell a new deletion from the change's own.
+  if (Array.isArray(recorded.deleted)) {
+    const was = new Set(recorded.deleted);
+    for (const p of current.deleted || []) if (!was.has(p) && !isPipelineOutput(p) && !removed.includes(p)) removed.push(p);
+  }
 
   // A file the review covered, edited since. This is the finding; the rest is
   // context. `added` in particular is usually ordinary work continuing, not a
@@ -426,11 +467,11 @@ export function receiptHash(receipt) {
  * Single-use by design: an acceptance authorises ONE push. An acceptance that
  * outlives its push is a standing permission, and nobody asked for one.
  */
-export function writeAcceptance(cwd, { hash, why = '', at = Date.now() } = {}) {
+export function writeAcceptance(cwd, { hash, why = '', at = Date.now(), agent = null } = {}) {
   const { writeFileSync, mkdirSync } = requireFs();
   mkdirSync(join(cwd, '.great_cto'), { recursive: true });
-  writeFileSync(join(cwd, ACCEPT_PATH), JSON.stringify({ hash, why, at }) + '\n');
-  return { hash, why, at };
+  writeFileSync(join(cwd, ACCEPT_PATH), JSON.stringify({ hash, why, at, ...(agent ? { agent } : {}) }) + '\n');
+  return { hash, why, at, agent };
 }
 
 /**
@@ -440,7 +481,7 @@ export function writeAcceptance(cwd, { hash, why = '', at = Date.now() } = {}) {
  * state" and "valid" are different situations, and the third is the one worth
  * naming out loud: it means the tree moved after a human looked at it.
  */
-export function readAcceptance(cwd, currentHash) {
+export function readAcceptance(cwd, currentHash, { agent = null } = {}) {
   const { readFileSync } = requireFs();
   let raw;
   try { raw = readFileSync(join(cwd, ACCEPT_PATH), 'utf8'); }
@@ -455,6 +496,12 @@ export function readAcceptance(cwd, currentHash) {
     return { valid: false, stale: true, rec,
       why: 'the acceptance names a different state — the tree changed after it was accepted' };
   }
+  // An acceptance given while looking at one stage's drift does not cover another's:
+  // the operator saw code-reviewer's files, not qa-engineer's.
+  if (agent && rec.agent !== agent) {
+    return { valid: false, stale: true, rec,
+      why: `the acceptance was given for ${rec.agent || 'the whole tree'}, not for ${agent} — accept ${agent}'s drift separately` };
+  }
   return { valid: true, rec, why: `accepted at ${new Date(rec.at).toISOString()}` };
 }
 
@@ -475,6 +522,12 @@ function requireFs() {
 // `--emit`   prints a receipt for the current tree (used by log-verdict.sh).
 // `--check <file>`  compares a recorded receipt held in a file.
 // `--verify` compares the newest approving verdict's receipt against now.
+//    `--agent <name>` narrows it to one approving stage. The newest approval of
+//    any stage is the wrong question before a deploy: a review of today's tree
+//    must not stand in for a QA pass on yesterday's.
+//    `--require` is the deploy question: "no approval carries a receipt" exits 3,
+//    not 0, and files ADDED since the approval count as drift. Before a push they
+//    are work continuing; before a deploy they are code nobody reviewed, shipping.
 
 function currentForReceipt(cwd, receipt) {
   // Persisted evidence is data, not Git options or a new revision expression.
@@ -487,7 +540,10 @@ function currentForReceipt(cwd, receipt) {
     base = receipt.head;
   }
   if (base != null && (typeof base !== 'string' || !/^[0-9a-f]{7,64}$/i.test(base))) return null;
-  return treeReceipt(cwd, { base: base || null });
+  // Without the pipeline's own state: an approval, an acceptance and a verdict all
+  // write under .great_cto/, and in a project that does not ignore it each write
+  // would change the state it is about (an acceptance voiding itself on write).
+  return treeReceipt(cwd, { base: base || null, exclude: pipelineOutputPaths(cwd) });
 }
 
 if (process.argv[1] && fileURLToPath(import.meta.url) === resolve(process.argv[1])) {
@@ -510,27 +566,48 @@ if (process.argv[1] && fileURLToPath(import.meta.url) === resolve(process.argv[1
     process.stdout.write(r ? JSON.stringify(r) : '');
     process.exit(r ? 0 : 1);
   }
+  const agentsArg = () => {
+    const i = argv.indexOf('--agent');
+    if (i < 0) return APPROVING_AGENTS;
+    const name = argv[i + 1];
+    if (!APPROVING_AGENTS.includes(name)) {
+      console.error(`receipt: --agent must be one of ${APPROVING_AGENTS.join(', ')}, got ${name}`);
+      process.exit(2);
+    }
+    return [name];
+  };
   if (argv.includes('--verify')) {
     const cwd = process.cwd();
-    const approval = latestApproval(cwd);
+    const agents = agentsArg();
+    const approval = latestApproval(cwd, { agents });
     const current = currentForReceipt(cwd, approval?.receipt);
     const cmp = compareReceipts(approval?.receipt ?? null, current);
     if (cmp.state === 'no-receipt') {
       // Not silence. A push with no approval to compare against and a push whose
       // receipt matched are different facts, and only one of them is evidence.
-      console.log('receipt: no approving verdict carries a receipt — nothing was verified');
-      process.exit(0);
+      const whom = agents.length === 1 ? `${agents[0]} verdict` : 'verdict';
+      console.log(`receipt: no approving ${whom} carries a receipt — nothing was verified`);
+      process.exit(argv.includes('--require') ? 3 : 0);
     }
     const who = approval ? `${approval.agent} ${approval.verdict} at ${approval.ts}` : 'an approval';
     console.log(`receipt: against ${who}`);
     console.log(describeDrift(cmp).split('\n').map((l) => `  ${l}`).join('\n'));
 
     if (cmp.state === 'unreadable') process.exit(2);
-    if (cmp.state !== 'differs') process.exit(0);
+    const requireMode = argv.includes('--require');
+    // A receipt capped at MAX_FILES lists only part of the change, so a file past
+    // the cap could change unseen. For the deploy question that is not a match.
+    if (requireMode && (approval?.receipt?.truncated || current?.truncated)) {
+      console.log(`  the receipt lists only the first ${MAX_FILES} files of this change — a match cannot be shown; re-run the stage on a smaller change`);
+      process.exit(2);
+    }
+    const drifted = cmp.state === 'differs' || (cmp.state === 'extended' && requireMode);
+    if (!drifted) process.exit(0);
 
     // Drift, but a human may already have looked at exactly this state.
     const hash = receiptHash(current);
-    const acc = readAcceptance(cwd, hash);
+    const narrowed = agents.length === 1 ? agents[0] : null;
+    const acc = readAcceptance(cwd, hash, { agent: narrowed });
     if (acc.valid) {
       console.log(`  accepted by the operator for this exact state (${acc.why})`);
       // Consumed here rather than by the caller: whoever asked the question is
@@ -540,7 +617,7 @@ if (process.argv[1] && fileURLToPath(import.meta.url) === resolve(process.argv[1
       process.exit(0);
     }
     if (acc.stale) console.log(`  ${acc.why} — accept again if this state is fine`);
-    console.log(`  to accept this state: node scripts/lib/receipt.mjs --accept`);
+    console.log(`  to accept this state: node scripts/lib/receipt.mjs --accept${narrowed ? ` --agent ${narrowed}` : ''}${requireMode ? ' --require' : ''}`);
     process.exit(1);
   }
 
@@ -553,14 +630,21 @@ if (process.argv[1] && fileURLToPath(import.meta.url) === resolve(process.argv[1
   // behaviour — an agent asked to approve its own work will comply.
   if (argv.includes('--accept')) {
     const cwd = process.cwd();
-    const approval = latestApproval(cwd);
+    const approval = latestApproval(cwd, { agents: agentsArg() });
     const current = currentForReceipt(cwd, approval?.receipt);
     const cmp = compareReceipts(approval?.receipt ?? null, current);
     if (cmp.state === 'unreadable') {
       console.error(`receipt: cannot accept — ${cmp.why}`);
       process.exit(2);
     }
-    if (cmp.state !== 'differs') {
+    const requireMode = argv.includes('--require');
+    if (requireMode && (approval?.receipt?.truncated || current?.truncated)) {
+      console.error(`receipt: cannot accept — the receipt lists only the first ${MAX_FILES} files; what you would accept is not all on screen`);
+      process.exit(2);
+    }
+    // Under --require an added file is drift, so it must be acceptable too —
+    // otherwise verify says "accept it" and accept says "nothing to accept".
+    if (!(cmp.state === 'differs' || (cmp.state === 'extended' && requireMode))) {
       console.log(`receipt: nothing to accept — ${cmp.why}`);
       process.exit(0);
     }
@@ -578,7 +662,9 @@ if (process.argv[1] && fileURLToPath(import.meta.url) === resolve(process.argv[1
     const answer = await new Promise((res) => rl.question('\nShip this state anyway? [y/N] ', (a) => { rl.close(); res(a); }));
     if (!/^y(es)?$/i.test(answer.trim())) { console.log('not accepted — nothing recorded.'); process.exit(1); }
 
-    writeAcceptance(cwd, { hash, why: `drift accepted over ${cmp.changed.length} changed file(s)` });
+    const stage = argv.includes('--agent') ? argv[argv.indexOf('--agent') + 1] : null;
+    writeAcceptance(cwd, { hash, agent: stage,
+      why: `drift accepted over ${cmp.changed.length} changed and ${cmp.added.length} added file(s)${stage ? ` for ${stage}` : ''}` });
     console.log('accepted. This authorises ONE push of this exact state; any further edit voids it.');
     process.exit(0);
   }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "great-cto",
-  "version": "3.75.4",
+  "version": "3.75.5",
   "description": "One command install for the great_cto Claude Code plugin. Auto-detects your stack, picks the right archetype, bootstraps PROJECT.md.",
   "keywords": [
     "claude-code",