jonah-fleet 1.21.0 → 1.22.0

package/CHANGELOG.md

@@ -5,6 +5,13 @@ All notable changes to `jonah-fleet` will be documented in this file.
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
 and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
+## [1.22.0](https://github.com/juliendurandeu/jonah-fleet/compare/v1.21.0...v1.22.0) (2026-09-20)
+
+
+### Features
+
+* **orchestration:** adopt Chief of Staff verification and Red Gate discipline ([#308](https://github.com/juliendurandeu/jonah-fleet/issues/308)) ([7e669de](https://github.com/juliendurandeu/jonah-fleet/commit/7e669de7e56a0fbe0feb0f694b2d29439416b421))
+
 ## [1.21.0](https://github.com/juliendurandeu/jonah-fleet/compare/v1.20.0...v1.21.0) (2026-09-20)
 
 
@@ -16,6 +23,11 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ### Features
 
+* **orchestration:** adopt Chief of Staff verification discipline, mandatory Red Gate protocol, Bogus Green Check defect taxonomy, disk read-back verification, and precision path-scoped git commits across prompts and engineering skills.
+* **prompts:** embed 6-part Bogus Green Check defect taxonomy (Vacuous assertion, Silent no-match, Errored check, Wrong reference, Stale premise, Scope mismatch) into `peer-review.md` and `/code-review`.
+* **prompts:** add mandatory Red Gate pre-implementation check to `autowork.md` and `/tdd`, catching already-resolved tasks and vacuous tests before code changes.
+* **prompts:** enforce disk read-back verification directly from written files and precision path-scoped git commits (`git commit -m "..." -- <paths>`).
+* **prompts:** enforce autonomous surfacing cadence without rhetorical permission halts ("Shall I continue?") across routines.
 * **guard:** exempt `manage_task` status and list polling from action repetition and ping-pong circuit breaker trips in `run-with-loop-guard.js`.
 * **housekeeping:** close `status:failure` routine log issues immediately (0-hour delay) if target is already closed or merged, and lower untargeted runner crash threshold to 12 hours.
 * **autowork:** update Step 9 idle sweep to close resolved-target failures immediately and untargeted crashes after 12 hours.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "jonah-fleet",
-  "version": "1.21.0",
+  "version": "1.22.0",
   "description": "Standalone autonomous agent fleet with Symphony orchestration, claim protocols, and continuous improvement loops",
   "main": "dist/index.js",
   "types": "dist/index.d.ts",

package/templates/docs/AGENTS.template.md

@@ -40,6 +40,11 @@ tests/            # Test suites
 - **Separation of Concerns**: Keep business logic pure and isolated from UI rendering and framework adapters.
 - **Error Handling**: Validate inputs at server and module boundaries. Return explicit structured errors.
 - **Testing Philosophy**: Write regression unit tests for every bug fix and integration tests for key workflows.
+- **The Red Gate Invariant**: Always execute a failing test or verifier before modifying code. If the check passes before changes, diagnose immediately whether the issue is already resolved or the test is a vacuous assertion.
+- **Defect Taxonomy of Bogus Green Checks**: Interrogate verification against the 6 defect shapes (Vacuous assertion, Silent no-match, Errored check, Wrong reference, Stale premise, Scope mismatch). Always prove a positive before believing a negative.
+- **Anti-Hallucination Disk Read-Back**: Verify generated code, configs, and artifacts by reading values directly back from the file on disk, never from in-memory variables or shell command echoes.
+- **Precision Git Scoping**: Never run bare `git commit` or blind `git add .` in multi-agent environments. Scope commits explicitly (`git commit -m "..." -- <paths>`).
+- **Autonomous Surfacing Cadence**: Timeboxing is for surfacing progress, never for stopping. Checkpoints report status without halting execution. Never yield the turn or ask rhetorical permission questions ("Shall I continue?").
 
 ## Requirements Discovery & Inquisitive Stance
 

package/templates/prompts/ORCHESTRATION.md

@@ -321,6 +321,48 @@ How autonomous routines escalate decisions, ambiguities, and blockers to human m
 
 ---
 
+## The Red Gate Protocol & Verification Discipline
+
+How agent routines ensure that tests, benchmarks, and verification commands are authoritative rather than vacuous:
+
+1. **The Red Gate (Pre-Implementation Failure Proof)**:
+   - Before writing any production code, the agent MUST formulate a reproduction test or verifier and execute it.
+   - **The check MUST fail** (red). If the check passes before any source code is changed, the subsequent work proves nothing.
+   - **Already Green Check**: If the check passes before changes, stop and evaluate:
+     - *Already Resolved*: If the requested behavior is already present in `origin/main`, close the issue as resolved, release the claim, and proceed to the next candidate. This single command check saves hours of redundant implementation.
+     - *Vacuous Assertion*: If the feature is missing but the test is green, the test is vacuous. Refactor the test until it reliably fails against the baseline before modifying code.
+2. **Defect Taxonomy of Bogus Green Checks**:
+   The most expensive errors in agentic engineering come from checks that report success for work they did not do. Verifiers and peer reviewers must audit for the 6 bogus green defect classes:
+   - **Vacuous assertion**: A test that passes whether or not the feature works (deleting the implementation under test leaves it green).
+   - **Silent no-match**: A grep, regex, linter, or predicate that matches nothing; zero matches falsely reads as "clean".
+   - **Errored check**: A command that failed to run or crashed (e.g. exit code 127 or syntax error), but the error was swallowed, reading absence as success. Exit codes are authoritative; agent summaries are intent.
+   - **Wrong reference**: A filter or diff baseline keyed on the wrong commit or tag (e.g. `HEAD~1` instead of `origin/main`), letting regressions slip through.
+   - **Stale premise**: An assertion whose expected value was copied directly off existing broken code, cementing the bug it was meant to catch.
+   - **Scope mismatch**: A green check executed only over a narrow subset presented as the whole (missing denominator).
+3. **Prove a Positive Before Believing a Negative**:
+   Before accepting an assertion that a defect or pattern is absent, verify that the check or tool flags a known-bad positive control. A tool that reports "clean" and a tool that is broken produce identical zero output.
+4. **Anti-Hallucination Disk Read-Back Verification**:
+   Always verify generated files, configs, and artifacts by reading values directly back from the written artifact on disk (`cat`, `jq`, file assertions), never from an in-memory variable, shell echo, or assumption.
+
+---
+
+## Durable Channels Beat Ephemeral Ones
+
+How autonomous agents manage state, handoffs, and communication across sessions:
+
+1. **Messages are Nudges, Files are Contracts**: Direct messaging between agents or subagents is useful for lightweight coordination, but can be dropped, delayed, or compacted. Anything that must survive and govern execution belongs in a durable channel:
+   - **Committed Policy**: Coding standards, conventions, and invariants belong in committed files (`AGENTS.md`, `.github/prompts/`).
+   - **Work Contracts**: Task descriptions, acceptance criteria, and status belong on the board (GitHub Issues, PR descriptions, or committed markdown briefs like `docs/briefs/`).
+   - **Pointer-Based Dispatch**: Pass links or file paths (`Context: <url>` or `Read docs/briefs/task.md`) in subagent launch prompts rather than pasting massive volatile blobs of text into prompts.
+2. **Policy vs. Ephemeral Separation**:
+   Keep long-lived policy (rules that govern every cycle) strictly separate from ephemeral session scratch. Never mix temporary task artifacts into long-lived documentation.
+3. **Autonomous Surfacing Cadence (No Permission Traps)**:
+   Timeboxing in autonomous runs is for surfacing progress, never for stopping. Checkpoints report status without halting execution. Autonomous agents MUST NEVER yield turns or ask rhetorical permission questions (e.g. "Shall I continue?", "Proceed to merge?").
+4. **Precision Git Scoping in Multi-Agent Environments**:
+   In environments where multiple agents, subagents, or local background commands operate, never execute bare `git commit` or blind `git add .`. Always scope commits explicitly with `git commit -m "..." -- <paths>` or verify `git status --porcelain` to avoid sweeping in uncommitted scratch files or parallel agent artifacts.
+
+---
+
 ## 3-Tier Prompt Prefix Caching Architecture
 
 How Jonah Fleet partitions prompt structures into Static $\rightarrow$ Semi-Stable $\rightarrow$ Dynamic tiers inspired by Orbital v0.4.2's prefix-caching architecture to achieve $>90\%$ cache hit rates on modern LLMs (Gemini, Anthropic, OpenAI), drastically reducing invocation latency and safeguarding the 70% weekly token budget ceiling:

package/templates/prompts/_prompt-template.md

@@ -49,12 +49,19 @@ If any criterion cannot be met, stop immediately and log FAILURE with the reason
 - **No speculative work**: only take actions directly required by the Definition of Done. Do not refactor adjacent code, open bonus issues, or add improvements not requested.
 - **Language Requirement**: All GitHub issue titles, descriptions, task checklists, and comments MUST be written in **English**.
 - **Session link footer**: sign every GitHub post with the Antigravity run footer (`_Generated by [Antigravity](${GITHUB_SERVER_URL}/${GITHUB_REPOSITORY}/actions/runs/${GITHUB_RUN_ID})_`).
+- **Autonomous Surfacing Cadence (No Permission Traps)**: Timeboxing is for surfacing progress, never for stopping. Checkpoints report status without halting execution. Never yield the turn or ask rhetorical permission questions (e.g. "Shall I continue?"). Proceed autonomously.
+- **Defect Taxonomy of Bogus Green Checks**: The most expensive errors in agentic engineering come from checks reporting success for work they did not do. Interrogate verification against the 6 defect classes (Vacuous assertion, Silent no-match, Errored check, Wrong reference, Stale premise, Scope mismatch). Exit codes decide, summaries are intent.
+- **Anti-Hallucination Disk Read-Back Verification**: Always verify generated code, configs, and artifacts by reading values directly back from the written artifact on disk, never from in-memory variables or shell echoes.
+- **Precision Git Scoping**: Never execute bare `git commit` or blind `git add .`. Scope commits explicitly with `git commit -m "..." -- <paths>` or verify `git status --porcelain` to avoid sweeping in uncommitted scratch files or parallel agent artifacts.
 
 ## Negative examples (DO NOT do these)
 
 - {Example of a wasteful pattern, e.g. "Do not re-read files you already read in this run"}
 - {Example of scope creep, e.g. "Do not fix lint warnings unrelated to the task"}
 - {Example of token burn, e.g. "Do not retry a failing API call more than twice"}
+- Do not pause or prompt rhetorical questions ("Shall I proceed?", "Do you want me to continue?")—execute the steps autonomously.
+- Do not use bare `git commit` or blind `git add .` without scoping specific paths (`git commit -m "..." -- <paths>`).
+- Do not verify generated files by checking in-memory strings; read values back out of the file on disk.
 
 ## Instructions
 

package/templates/prompts/autowork.md

@@ -38,6 +38,10 @@ If any criterion cannot be met, stop immediately and log FAILURE with the reason
 - **Language Requirement**: All GitHub issue titles, descriptions, task checklists, and comments MUST be written in **English**.
 - **Session link footer**: sign every GitHub post (issue comments, PR comments, PR descriptions) with the Antigravity run footer (`_Generated by [Antigravity](${GITHUB_SERVER_URL}/${GITHUB_REPOSITORY}/actions/runs/${GITHUB_RUN_ID})_`). Inline review-thread line comments are exempt.
 - **Headless Execution & Asynchronous Non-Yielding Guardrail**: You are running in a headless autonomous session. You MUST NEVER call `schedule` or yield the turn with plain text while waiting for background tasks or verification checks. If a verification command runs in the background, actively inspect its completion with `manage_task` or run with sufficient `WaitMsBeforeAsync` (up to `10000` ms). Never stop calling tools or yield your turn until the routine's terminal Definition of Done is fully reached.
+- **Autonomous Surfacing Cadence (No Permission Traps)**: Timeboxing is for surfacing progress, never for stopping. Checkpoints report status without halting execution. Never yield the turn or ask rhetorical permission questions (e.g. "Shall I continue?", "Proceed with implementation?"). Proceed with the next step autonomously.
+- **Defect Taxonomy of Bogus Green Checks & Red Gate Verification**: Always establish a failing reproduction check or verifier before modifying code (the Red Gate). Interrogate checks against the 6 bogus green defect classes (Vacuous assertion, Silent no-match, Errored check, Wrong reference, Stale premise, Scope mismatch). Exit codes decide; summaries are intent.
+- **Anti-Hallucination Disk Read-Back Verification**: Always verify generated code, configs, and artifacts by reading values directly back out of the written artifact on disk, never from in-memory variables or shell command echoes.
+- **Precision Git Scoping**: Never execute bare `git commit` or blind `git add .` without scoping. Always commit designated paths explicitly (`git commit -m "..." -- <paths>`) or verify `git status --porcelain` to avoid sweeping in uncommitted scratch artifacts or concurrent session files.
 
 ## Negative examples (DO NOT do these)
 
@@ -55,6 +59,10 @@ If any criterion cannot be met, stop immediately and log FAILURE with the reason
 - Do not fall into the **Telemetry Rabbit Hole**: do not spend cycles instrumenting elaborate fallback telemetry or defensive error handling for features that suffer from lack of user intent rather than software bugs.
 - Do not guess or invent arbitrary specifications for ambiguous issues — post the 4-part escalation card ('Why I believe this'), label `needs-info`, and release the claim instead of blindly writing code.
 - Do not call `schedule` or yield the turn with plain text while waiting for background verification tasks — stay in the tool loop until the Definition of Done is met.
+- Do not write implementation code before proving that the reproduction test or verifier fails (the Red Gate).
+- Do not pause or prompt rhetorical questions ("Shall I continue?", "Should I start implementing?")—proceed autonomously.
+- Do not use bare `git commit` or blind `git add .` without scoping specific paths (`git commit -m "..." -- <paths>`).
+- Do not verify generated files by checking in-memory strings or shell variables; read values back out of the file on disk.
 
 ## Instructions
 
@@ -206,6 +214,11 @@ _Generated by [Antigravity](${GITHUB_SERVER_URL}/${GITHUB_REPOSITORY}/actions/ru
     - If bug: use `/diagnosing-bugs` to establish reproduction test before fixing.
     - If large/complex: use `/domain-modeling` and `/codebase-design`.
     - **Pre-Flight Memory Scan**: If `LESSONS.md` exists, grep matching subsystem tags (`grep -E "^### \[(subsystem)\]" LESSONS.md -A 4`) to incorporate known landmines into implementation plans before writing code.
+    - **The Red Gate Protocol (Pre-Implementation Verifier Check)**: Before writing ANY production implementation code, define the verifier or write a reproduction test, and execute it:
+      - **The check MUST fail** (red). If the verifier passes before you touch production code, the subsequent work proves nothing.
+      - **Already Green Check**: If the verifier passes *before* code changes, stop immediately and evaluate:
+        1. *Already Resolved*: If the requested behavior or fix is already present in `origin/main` (e.g. shipped under another card or refactor), verify thoroughly, close the issue immediately (`gh issue close <ISSUE_NUMBER> --comment "Closed: verified already resolved on main."`), release the claim, and proceed to the next candidate. Running the Red Gate first catches stale work in seconds and saves hours of redundant coding.
+        2. *Vacuous Assertion (Bogus Green)*: If the feature is missing but the test passes, the test is vacuous (silent no-match, erring swallowed command, or trivial assertion). Refactor the test until it reliably fails against the baseline before implementing.
     - **Ambiguity & Missing Acceptance Criteria Gate**: Challenge underspecified or incomplete requests before writing any code. If the issue lacks observable acceptance criteria, relies on unverified assumptions, or leaves critical technical/UX decisions ambiguous:
       - Do NOT guess or invent arbitrary requirements to force completion.
       - Post the mandatory 4-part escalation card on the issue:
@@ -242,9 +255,11 @@ _Generated by [Antigravity](${GITHUB_SERVER_URL}/${GITHUB_REPOSITORY}/actions/ru
       ```
 13. **Implementation & PR creation:**
     - Branch from freshly fetched `origin/main` with descriptive name (e.g. `feat/...` or `fix/...`).
-    - Drive implementation via `/tdd` (red-green-refactor).
+    - Drive implementation via `/tdd` (red-green-refactor): execute the Red Gate test first, write minimal code to pass, and refactor cleanly.
+    - **Precision Git Scoping**: Never use bare `git commit` or `git add .` blindly. Stage and commit only designated paths explicitly: `git commit -m "<type>(<scope>): <subject>" -- <paths>`, or verify `git status --porcelain` before committing to avoid sweeping in scratch files or parallel artifacts.
     - **Diagnostic Reflex**: On unexpected test/build failure during TDD, grep symptom text in `LESSONS.md` before making speculative code edits.
     - Run repository tests and verification.
+    - **Disk Read-Back Verification**: Verify written configs, schemas, and generated files by reading values directly back from disk files (`cat`, `jq`, test assertions), never from shell variables or memory.
     - **Pre-PR Lessons Capture Gate**: If solving the issue required overcoming a non-obvious quirk not caught by tests/linters, append a 3-line structured entry on the active PR branch adhering to the 25-entry hard cap. Never write to `LESSONS.md` directly on `main`.
     - **Milestone 2 (Verification & Tests)**: Once implementation passes tests and type checks, emit milestone card if `$ROUTINE_ISSUE_NUMBER` is set:
       ```bash

package/templates/prompts/peer-review.md

@@ -43,6 +43,10 @@ If any criterion cannot be met, stop immediately and log FAILURE with the reason
 - **Session link footer**: sign every GitHub post with the Antigravity run footer (`_Generated by [Antigravity](${GITHUB_SERVER_URL}/${GITHUB_REPOSITORY}/actions/runs/${GITHUB_RUN_ID})_`).
 - **Headless Execution & Asynchronous Non-Yielding Guardrail**: You are running in a headless autonomous CLI session. You MUST NEVER call `schedule` or yield the turn with plain text to "wait" for background tasks, timers, or long-running commands. In headless CLI mode, yielding the turn terminates the session immediately before reaching the Definition of Done. When invoking `run_command` for test runs or type checks, ALWAYS set `WaitMsBeforeAsync` high enough (up to the maximum `10000` ms) or if a command moves to the background, keep your execution turn active by checking task status (`manage_task(Action='status')`) or inspecting files; NEVER call `schedule` or emit a terminal turn with plain text before taking the final action.
 - **Verification Command & CI Discipline**: When remote CI checks (e.g. GitHub Actions, Vercel preview deployments) are already present and passed on the PR's head commit, treat CI as verified and green. Avoid executing slow, redundant local full test suites or full type-checks when CI is already green. Run local verification commands (`npm test`, `npm run type-check`) ONLY if CI is missing, unconfirmed, or failing.
+- **Autonomous Surfacing Cadence (No Permission Traps)**: Timeboxing is for surfacing progress, never for stopping. Checkpoints report status without halting execution. Never yield the turn or prompt rhetorical permission questions (e.g. "Shall I continue?", "Proceed to merge?"). Take authoritative final action autonomously.
+- **Defect Taxonomy of Bogus Green Checks**: The most expensive errors in agentic engineering come from checks reporting success for work they did not do. Audit verification against the 6 defect shapes (Vacuous assertion, Silent no-match, Errored check, Wrong reference, Stale premise, Scope mismatch). Exit codes and concrete diffs are authoritative; agent summaries are merely intent.
+- **Anti-Hallucination Disk Read-Back Verification**: Verify artifacts, generated configs, or outputs by reading values directly back out of the written artifact on disk, never from an in-memory variable, shell echo, or assumption.
+- **Reader / Writer Separation**: Peer Review is strictly an evaluator and merge authority. Never write or commit code modifications to the PR branch directly; bounce to draft so the author or autowork session applies the fix in their warm context.
 
 ## Final action: merge or bounce to draft
 
@@ -70,6 +74,9 @@ Every review ends in exactly one of two states:
 - Do not bounce an external contributor PR purely for missing `Closes #N` when the PR description provides a clear specification.
 - Do not call `schedule` or yield the turn with plain text while waiting for background verification tasks — stay in the tool loop until the final action is taken.
 - Do not rerun full local test suites when remote CI checks on the head commit are already green and passing.
+- Do not write implementation code or modify the PR branch directly—bounce to draft with specific actionable findings instead.
+- Do not accept checks or tests that pass vacantly or match zero items without positive controls.
+- Do not pause or prompt rhetorical questions ("Shall I proceed?", "Do you want me to merge?")—execute the final action autonomously.
 
 ## Instructions
 
@@ -136,6 +143,16 @@ Check if `$PR_NUMBER` is set:
    - **Funnel Completeness**: For new Tier 1 user funnels or critical workflows, verify the telemetry contract: impression denominator (`_shown`), interaction (`_clicked`), and failure states (`_failed` with `reason`) are captured, and events are documented in the custom events catalog (`ARCHITECTURE.md` / `DATA_CONTEXT.md`). Flag missing denominators on core funnels as blocking.
 5. If PR modifies rendered UI, verify screenshots or visual components if tooling/scripts are available.
 6. Run repository verification commands (tests, type-check) ONLY if CI status is unconfirmed or failing. If remote CI (such as GitHub Actions or Vercel preview) is already green and passing on the head commit, treat CI as verified. If verification commands must be run locally, specify `WaitMsBeforeAsync: 10000` and NEVER call `schedule` or yield the turn with plain text while waiting for background tasks.
+7. **Anti-Vacuity & Verifier Audit Pass (The 6 Bogus Green Shapes)**:
+   Actively interrogate new or modified tests and verification commands against the 6 bogus green defect classes:
+   - **Vacuous assertion**: Test passes whether or not the feature works (e.g. deleting the implementation under test leaves it green). Require a red-gate failure or mutation check.
+   - **Silent no-match**: A grep, regex, linter, or predicate that matches nothing; 0 matches falsely reads as "clean / no errors".
+   - **Errored check**: A command that failed to run or crashed (e.g. exit code 127 or syntax error), but the failure was swallowed, reading absence as success. Exit codes decide; summaries are merely intent.
+   - **Wrong reference**: A filter or diff baseline keyed on the wrong commit, tag, or branch (e.g. `HEAD~1` instead of `origin/main`), letting intervening regressions slip through.
+   - **Stale premise**: An assertion whose expected value was copied directly off existing broken code, cementing the bug it was meant to catch.
+   - **Scope mismatch**: A green check executed only over a narrow subset presented as the whole (missing denominator).
+   - **Prove a positive before believing a negative**: Before accepting an assertion that a defect or pattern is absent, verify that the check flags a known-bad positive control.
+   - **Disk Read-Back Verification**: Verify written configs, schemas, and generated artifacts by reading values directly back from the file on disk, not from shell variables or memory.
 
 ### Step 5: Classify Findings & Make Decision
 

package/templates/skills/code-review/SKILL.md

@@ -67,7 +67,7 @@ Each smell reads *what it is* → *how to fix*; match it against the diff:
 
 - The diff command and commit list.
 - The path or fetched contents of the spec.
-- The brief: "Report: (a) requirements the spec asked for that are missing or partial; (b) behaviour in the diff that wasn't asked for (scope creep); (c) requirements that look implemented but where the implementation looks wrong. Quote the spec line for each finding. Under 400 words."
+- The brief: "Report: (a) requirements the spec asked for that are missing or partial; (b) behaviour in the diff that wasn't asked for (scope creep); (c) requirements that look implemented but where the implementation looks wrong. Quote the spec line for each finding. (d) Anti-Vacuity / Bogus Green Check audit: evaluate any new or modified tests against the 6 defect shapes (Vacuous assertion, Silent no-match, Errored check, Wrong reference, Stale premise, Scope mismatch). Verify that tests would actually fail if the implementation were removed, and that checks asserting absence prove a positive control first. Under 400 words."
 
 If the spec is missing, skip the Spec sub-agent and note this in the final report.
 

package/templates/skills/tdd/SKILL.md

@@ -28,11 +28,14 @@ When the shape of that interface is itself in question (how deep the module is,
 ## Anti-patterns
 
 - **Implementation-coupled**: mocks internal collaborators, tests private methods, or verifies through a side channel (querying the database instead of using the interface). The tell: the test breaks when you refactor but behavior hasn't changed.
-- **Tautological**: the assertion recomputes the expected value the way the code does (`expect(add(a, b)).toBe(a + b)`, a snapshot derived by hand the same way, a constant asserted equal to itself), so it passes by construction and can never disagree with the code. Expected values must come from an independent source of truth: a known-good literal, a worked example, the spec.
+- **Tautological / Vacuous Assertion**: the assertion recomputes the expected value the way the code does (`expect(add(a, b)).toBe(a + b)`, a snapshot derived by hand the same way, a constant asserted equal to itself), or asserts a condition that passes whether or not the feature works. Deleting the code under test must make the test fail.
+- **Silent No-Match**: a test filter, grep, or predicate that matches zero cases and reads as clean. Always prove a positive control before believing absence.
+- **Stale Premise**: an assertion whose expected value was copied directly off broken code, cementing the bug it was meant to catch.
 - **Horizontal slicing**: writing all tests first, then all implementation. Bulk tests verify _imagined_ behavior: you test the _shape_ of things rather than user-facing behavior, the tests go insensitive to real changes, and you commit to test structure before understanding the implementation. Work in **vertical slices** instead: one test → one implementation → repeat, each test a **tracer bullet** that responds to what the last cycle taught you.
 
 ## Rules of the loop
 
-- **Red before green.** Write the failing test first, then only enough code to pass it. Don't anticipate future tests or add speculative features.
+- **The Red Gate (Red before green).** Write the failing test first, run it, and confirm it fails. If it passes before code is written, STOP: either the feature already exists (avoiding redundant work), or the test is vacuous. Only write enough code to turn the red gate green. Don't anticipate future tests or add speculative features.
 - **One slice at a time.** One seam, one test, one minimal implementation per cycle.
+- **Disk Read-Back Verification.** Verify artifacts and written configs by reading values directly back from the file on disk (`cat`, `jq`, file assertions), never from in-memory variables.
 - **Refactoring is not part of the loop.** It belongs to the review stage (see the `code-review` skill), not the red → green implementation cycle.