summer-engine 2.3.0 → 2.6.0

package/skills/workflow/playtesting-a-feature/SKILL.md

@@ -0,0 +1,173 @@
+---
+name: playtesting-a-feature
+description: Use when about to claim a gameplay feature is done, shipped, or working — requires actually running the game and walking through the feature before declaring completion. Static diagnostics and type checks do not count as playtesting.
+---
+
+# Playtesting A Feature
+
+## Overview
+
+A game feature is not done because it compiles. It is not done because the tests pass. It is not done because `summer_get_diagnostics` is clean. It is done when someone has played it and the thing it promised actually happens.
+
+**Core principle:** If you have not pressed play and walked the feature, you have not shipped it.
+
+This skill governs the play-the-game layer of verification. It does not replace:
+
+- `summer:verification-before-completion` — type checks, build output, test runs. Run that for the code layer.
+- `summer:debug` — operational triage when a feature is actively broken or crashing.
+- `summer:investigating-bugs` — root-cause analysis once a specific bug is reproducible.
+
+Use those skills first if they apply. This skill runs **after** code-level verification, **before** telling the user the feature is done.
+
+<EXTREMELY-IMPORTANT>
+Static analysis is necessary but never sufficient for gameplay features. A clean `summer_get_diagnostics` after `summer_play` only proves the game booted. It does NOT prove the feature works. Auto-fire weapons, level transitions, UI flows, input handling, multi-frame physics — none of these surface in diagnostics until they fire during real play.
+</EXTREMELY-IMPORTANT>
+
+## The Iron Law
+
+```
+NO "FEATURE SHIPPED" CLAIM WITHOUT A PLAYED WALKTHROUGH
+```
+
+If you have not, in this session, called `summer_play` and either:
+
+1. Walked the feature yourself via MCP-driven repros where possible, OR
+2. Asked the user to walk it and confirmed the result via `summer_get_console` / `summer_get_debugger_errors`
+
+— then you cannot claim the feature works.
+
+## The Loop
+
+```
+  Define golden path → Play → Walk it → Probe edges → Capture state → Decide
+```
+
+### 1. Define the golden path
+
+Before pressing play, write down — in one or two sentences — what "feature works" means as a user-visible sequence. Be concrete.
+
+> **Good:** "Player walks to chest, presses E, chest opens, item drops, item enters inventory, inventory UI updates."
+> **Bad:** "Inventory pickup works."
+
+If you cannot describe the golden path in one sentence, you do not understand the feature well enough to verify it. Ask the user.
+
+### 2. Press play
+
+```
+  summer_clear_console
+  summer_play
+  summer_is_running  (confirm)
+```
+
+`summer_clear_console` first so the buffer is not polluted by a previous session's errors. If you skip this, you will chase ghost errors that have nothing to do with the current feature.
+
+### 3. Walk the golden path
+
+The MCP cannot simulate keyboard input, mouse motion, or controller. So either:
+
+- **The user plays.** Ask them to walk the exact golden path you defined. Wait for their confirmation that they did. Then check state.
+- **You drive via scene mutation.** For features that can be triggered through `summer_set_prop` or function calls exposed to the editor (e.g. autoload methods), drive them programmatically. Be honest about which path you took.
+
+After the walkthrough:
+
+```
+  summer_get_console            (look for unexpected prints, warnings)
+  summer_get_debugger_errors    (runtime errors caught mid-play)
+  summer_get_diagnostics        (overall counts)
+```
+
+If anything is non-zero or unexpected, the feature is not done. Go to `summer:debug`.
+
+### 4. Probe the edges
+
+The golden path proves the happy case. Most gameplay bugs live in the edges. Before claiming done, probe at least these four classes:
+
+| Edge | What to try | Why |
+|---|---|---|
+| Input spam | Press the action button 10x in a row, hold it, mash during a transition | Race conditions, state machines that swallow input, double-trigger bugs |
+| Off-screen / out-of-range | Trigger the feature when the actor is far from the camera, off the navmesh, in a different scene | `@onready` paths that assume specific parent, signal connections that drop when nodes free |
+| Paused / state-change | Trigger during pause, mid-cutscene, while another modal is open | `process_mode` mistakes, `get_tree().paused` not respected |
+| Multi-frame | Repeat the feature 5 times in a row without restarting the scene | Leaked nodes, accumulating signals, growing arrays, sound stacking |
+
+You do not need to probe every edge for every feature. Pick the 2-3 that are most relevant to the feature's mechanics. Skip with a one-line note if you skip: "Did not probe pause-state — feature only runs in main menu."
+
+### 5. Capture state, then decide
+
+After the walkthrough and edge probes, capture one final snapshot:
+
+```
+  summer_get_diagnostics
+  summer_get_console  (if anything looked off)
+```
+
+State the result in plain language:
+
+> "Played the chest-open feature: golden path works (chest opens, item enters inventory, UI updates). Probed input spam (no double-pickup), probed pause (correctly disabled). Diagnostics clean. Feature done."
+
+Or:
+
+> "Played the chest-open feature: golden path works, but pressing E twice in 100ms duplicates the pickup. Not done — going to summer:debug."
+
+## "Looks right" vs "is right"
+
+A common failure mode: the feature visually looks correct on first try, you stop there, ship it, and a deeper bug surfaces later.
+
+**Looks right** means the rendered frame matches expectations.
+
+**Is right** means the rendered frame matches expectations AND the underlying state is consistent AND it survives repetition AND no errors are silently logged.
+
+The console catches "looks right but isn't right" cases — silent errors, deprecation warnings, signal misfires that don't crash but indicate a real bug. **Always read `summer_get_console` after a playthrough, even when the visuals looked fine.**
+
+## When to record video vs when console+diagnostics is enough
+
+Console + diagnostics + your walkthrough description is usually enough. Ask the user for a video or screenshot when:
+
+- The feature is **visual** (camera, lighting, particles, animation, UI layout) and the user is the only one who can see the result.
+- The feature **feels wrong** — see `summer:debugging-game-feel`. Frame counts and console output cannot capture "the jump feels floaty."
+- The bug is **non-deterministic** — sometimes-works features need a recording to share with anyone diagnosing later.
+
+Don't ask for video reflexively. Most features can be verified through `summer_get_console` + a "did the golden path work?" question. Cost-aware.
+
+## Red Flags — STOP
+
+| Red flag | Reality |
+|---|---|
+| "Compiles clean, shipping it" | Compiling is not playing. Press play. |
+| "Diagnostics returned 0 errors after boot" | Boot is not play. The feature has not fired yet. |
+| "User said make this — I'll move on once it builds" | The user wants the feature to work, not to build. |
+| "It would take too long to play" | Playtest takes 60 seconds. Shipping a broken feature costs hours. |
+| "The unit test passes" | Unit tests cover code paths, not gameplay sequences. |
+| "I already played it in a previous session" | State changed. Press play in this session. |
+| "I'll let the user catch any issues" | That is the user's job description for a non-AI engineer. Yours is to ship working features. |
+| Skipping `summer_clear_console` before `summer_play` | You will chase last session's errors. |
+| Skipping `summer_get_console` because diagnostics looked fine | Silent warnings and signal misfires hide there. |
+
+## Rationalization Prevention
+
+| Excuse | Reality |
+|---|---|
+| "Static checks are enough for this feature" | If it has any runtime behavior, no. |
+| "The feature is too small to playtest" | Two lines of code can break a state machine. Play it. |
+| "I'll batch the playtest with the next feature" | Bugs compound. Play each feature individually. |
+| "User is in a hurry" | Shipping broken features is the slowest path. |
+| "The repro is hard to set up" | That is a sign the feature has insufficient instrumentation. Add it, then play. |
+
+## When the engine isn't running
+
+If `summer_play` returns "Summer Engine is not running":
+
+1. Tell the user: `summer run` to start it.
+2. Do not claim the feature is verified from static analysis alone. Say: "Code compiles and looks correct, but I cannot playtest until the engine is running."
+3. When the engine comes back, run the loop.
+
+## The Bottom Line
+
+A game feature is a promise to the player. Verifying it means seeing the promise kept on screen, not seeing the code that would, in theory, keep it.
+
+Press play. Walk the path. Probe the edges. Read the console. Then claim done.
+
+**Related skills:**
+- `summer:verification-before-completion` — the code-layer verification this skill builds on.
+- `summer:debug` — when the playtest surfaces a crash or error.
+- `summer:investigating-bugs` — when the playtest surfaces a reproducible logical bug.
+- `summer:debugging-game-feel` — when the feature works but feels wrong.

package/skills/{_meta → workflow}/skill-create/SKILL.md

@@ -3,7 +3,7 @@ name: skill-create
 description: Use when a contributor wants to add a new skill to the Summer library — bootstraps the canonical folder structure, frontmatter, and stub sections. Trigger on "create skill", "add skill", "new skill", "scaffold a skill".
 license: MIT
 compatibility: [Cursor, Claude Code, Windsurf, Codex]
-category: _meta
+category: workflow
 allowed-tools: Read Write Glob Grep
 ---
 
@@ -15,9 +15,9 @@ allowed-tools: Read Write Glob Grep
 
 Ask the user:
 - **Name** (kebab-case, ≤ 64 chars). Example: `state-machine-patterns`.
-- **Category** (one of the 20 in `catalog.yaml`). Example: `scripting-patterns`.
+- **Category** (one of the 20 in `SKILL_CATEGORIES` at `src/lib/skills-registry.ts`). Example: `scripting-patterns`.
 - **One-sentence description** for the frontmatter.
-- **Template-id** (optional). Lookup against `_shared/template-registry.md`.
+- **Template-id** (optional). Lookup against `references/template-registry.md`.
 
 ### 2. Create the folder
 
@@ -40,7 +40,7 @@ description: <one-sentence what + when. Lead with key trigger phrases.>
 license: MIT
 compatibility: [Cursor, Claude Code, Windsurf, Codex]
 category: <category>
-template-id: <optional template-id from _shared/template-registry.md>
+template-id: <optional template-id from references/template-registry.md>
 allowed-tools: Read Grep <summer_* tools this skill uses>
 paths: ["**/*.gd", "**/*.tscn"]
 ---
@@ -79,14 +79,14 @@ May I <action>?
 ## Want a working starter?
 
 → **template-id**: `<template-id>`
-→ **Repo**: <github URL from _shared/template-registry.md>
+→ **Repo**: <github URL from references/template-registry.md>
 → **Bootstrap**: `summer template clone <template-id> my-game`
 
 ## See also
 
-- `_shared/godot-version.md`
-- `_shared/mcp-tools-reference.md`
-- `_shared/gd-style.md`
+- `references/godot-version.md`
+- `references/mcp-tools-reference.md`
+- `references/gd-style.md`
 - (other relevant skills)
 ```
 
@@ -115,29 +115,39 @@ May I <action>?
 **Expected:** <how the skill should adapt>
 ```
 
-### 5. Register in catalog.yaml
+### 5. Register the skill
 
-Append:
+Two files to update, both required for the skill to load in Claude Code / Cursor / Codex AND to be installable via `summer skills install`:
 
-```yaml
-  - name: <name>
-    category: <category>
-    status: NEXT  # or HAVE if shipping immediately
-    template-id: <or omit>
-    public: true
-    recommended: false  # flip to true when status: HAVE and tested
+**5a. `.claude-plugin/plugin.json`** (and sibling manifests `.codex-plugin/plugin.json`, `.cursor-plugin/plugin.json`). Append to the `skills:` array:
+
+```json
+"./skills/<category>/<name>/",
+```
+
+**5b. `src/lib/skills-registry.ts`** `SKILL_REGISTRY` array. Append a typed entry:
+
+```ts
+{
+  name: "<name>",
+  category: "<category>",
+  public: true,
+  clients: ALL_CLIENTS,
+  recommended: false,
+  requiresMcpTools: ["summer_<tool>", ...],
+  testScenario: "<one-line scenario the skill should handle end-to-end>",
+},
 ```
 
 ### 6. Run /skill-test in static mode
 
-Confirm the new skill passes the 7 structural checks before commit.
+Confirm the new skill passes the structural checks before commit. The `plugin-manifests.test.ts` test will fail the build if 5a or 5b is missing.
 
 ## Collaborative protocol
 
-This skill writes files (the new skill folder + catalog update). Always ask before each write step.
+This skill writes files (the new skill folder + plugin manifest update + TS registry update). Always ask before each write step.
 
 ## See also
 
-- `_shared/collaborative-protocol.md`
-- `_meta/skill-test/SKILL.md`
-- `catalog.yaml`
+- `references/collaborative-protocol.md`
+- `workflow/skill-test/SKILL.md`

package/skills/{_meta → workflow}/skill-improve/SKILL.md

@@ -3,7 +3,7 @@ name: skill-improve
 description: Use when a contributor wants to upgrade a Summer skill that is underperforming or to fix a regression — runs the skill against a behavioral spec with and without proposed changes via parallel-eval harness and ships the version that wins. Trigger on "improve skill", "iterate on skill", "make this skill better".
 license: MIT
 compatibility: [Cursor, Claude Code, Windsurf, Codex]
-category: _meta
+category: workflow
 allowed-tools: Read Write Edit Task
 ---
 
@@ -24,7 +24,7 @@ Run this when `/skill-test spec` flags issues you can't fix by reading the skill
 
 Ask the user:
 - **Skill name.** Resolves to `skills/<category>/<name>/SKILL.md`.
-- **Test cases to focus on.** Default: all `## Case` blocks in `_tests/specs/<name>.md`.
+- **Test cases to focus on.** Default: all `## Case` blocks in `tests/specs/<name>.md`.
 
 ### 2. Establish a baseline
 
@@ -35,7 +35,7 @@ For each Case:
 3. Capture the tool calls it makes and the diff it produces.
 4. Score against the Case's Assertions.
 
-Save outputs to `_tests/runs/<skill-name>/baseline/case-<N>/`.
+Save outputs to `tests/runs/<skill-name>/baseline/case-<N>/`.
 
 ### 3. Propose changes
 
@@ -45,11 +45,11 @@ Read the failing Cases. Identify the gap between what the skill says and what th
 - Skill assumes a fixture detail the agent missed (add explicit step to confirm).
 - Skill's "May I" wording is too generic for the agent to infer the right ask.
 
-Draft a revised SKILL.md. May I write it to `_tests/runs/<skill-name>/proposed/SKILL.md`?
+Draft a revised SKILL.md. May I write it to `tests/runs/<skill-name>/proposed/SKILL.md`?
 
 ### 4. Run the proposed version
 
-Repeat step 2 with the proposed SKILL.md. Save to `_tests/runs/<skill-name>/proposed/case-<N>/`.
+Repeat step 2 with the proposed SKILL.md. Save to `tests/runs/<skill-name>/proposed/case-<N>/`.
 
 ### 5. Compare and decide
 
@@ -69,13 +69,12 @@ Case 3 (Edge):      baseline 3/3  proposed 3/3  = no change
 
 If proposed wins on net, prompt the user:
 
-> Proposed version wins 2 cases, ties 1, loses 0. May I overwrite `skills/<category>/<name>/SKILL.md` with the proposed version and update `last-tested:` in `catalog.yaml`?
+> Proposed version wins 2 cases, ties 1, loses 0. May I overwrite `skills/<category>/<name>/SKILL.md` with the proposed version?
 
 ### 6. Ship
 
 On user yes:
 - Overwrite `SKILL.md`.
-- Update `last-tested: <today>` in `catalog.yaml`.
 - Commit with message `feat(skill): improve <name> — <one-line summary of change>`.
 
 ## Collaborative protocol
@@ -84,6 +83,6 @@ This skill writes files at multiple steps. Always ask before each write.
 
 ## See also
 
-- `_meta/skill-test/SKILL.md`
-- `_tests/runner.md`
-- `_tests/specs/`
+- `workflow/skill-test/SKILL.md`
+- `tests/runner.md`
+- `tests/specs/`

package/skills/{_meta → workflow}/skill-test/SKILL.md

@@ -3,7 +3,7 @@ name: skill-test
 description: Use when a contributor wants to lint a Summer skill before commit, audit the whole library, or check a behavioral spec assertion — validates against static structural rules and per-skill behavioral specs. Trigger on "skill test", "lint skill", "validate skill".
 license: MIT
 compatibility: [Cursor, Claude Code, Windsurf, Codex]
-category: _meta
+category: workflow
 allowed-tools: Read Glob Grep
 ---
 
@@ -21,9 +21,9 @@ For a single skill at `skills/<category>/<name>/`, run these checks:
    - At least one `summer_*` MCP tool example.
    - At least one file-edit fallback block (e.g., raw `.tscn` snippet) OR an explicit "no fallback for this — Summer MCP required" note.
 4. **Collaborative protocol.** If the skill triggers user-visible writes, body must contain at least one of: `May I`, `I'm about to`, `Continue?`, `OK?`, `Proceed?`. Skills that only inspect/read are exempt.
-5. **Template-id resolved.** If the skill's frontmatter declares `template-id: <id>`, that id must exist in `_shared/template-registry.md`.
+5. **Template-id resolved.** If the skill's frontmatter declares `template-id: <id>`, that id must exist in `references/template-registry.md`.
 6. **Tests/spec.md present.** Every skill in a non-`_meta` category must have `tests/spec.md` with at least one `## Case` heading.
-7. **Relative links resolve.** Every `](../_shared/...)`, `](../../_shared/...)`, `](./references/...)`, and `](./examples/...)` link must point at an existing file (FAIL if broken). Forward references in `## See also` to other SKILL.md files (e.g., `[design-mechanic](../../gameplay-mechanics/design-mechanic/SKILL.md)`) are allowed to dangle and only WARN if the target is missing — the catalog evolves and skills should be free to point at planned skills.
+7. **Relative links resolve.** Every `](../references/...)`, `](../../references/...)`, `](./references/...)`, and `](./examples/...)` link must point at an existing file (FAIL if broken). Forward references in `## See also` to other SKILL.md files (e.g., `[design-mechanic](../../gameplay-mechanics/design-mechanic/SKILL.md)`) are allowed to dangle and only WARN if the target is missing — the catalog evolves and skills should be free to point at planned skills.
 
 Output:
 
@@ -42,7 +42,7 @@ skill: <category>/<name>
 
 ## Mode: `spec` — Behavioral spec runner
 
-For a single skill, read both `skills/<category>/<name>/SKILL.md` and `_tests/specs/<name>.md`. For each `## Case` in the spec:
+For a single skill, read both `skills/<category>/<name>/SKILL.md` and `tests/specs/<name>.md`. For each `## Case` in the spec:
 
 1. Lay out the **Fixture** (starting state, available tools).
 2. Read the **Input** (user prompt).
@@ -55,13 +55,13 @@ No code execution. Pure reasoning over text.
 
 ## Mode: `audit` — Whole library report
 
-Read `catalog.yaml`. For each skill with `status: HAVE`:
+Read the `skills:` array in `.claude-plugin/plugin.json`. For each registered skill:
 
 1. Run `static` mode on the skill.
-2. Note the skill's `last-tested:` date.
-3. Flag skills where `last-tested:` is missing or older than 30 days.
+2. Note any `last-tested:` field in the SKILL.md frontmatter (optional).
+3. Flag skills failing static checks.
 
-Output: a table with PASS / FAIL counts, last-tested ages, and a punch list of skills needing attention.
+Output: a table with PASS / FAIL counts and a punch list of skills needing attention.
 
 ## When to use which mode
 
@@ -80,7 +80,7 @@ This skill is **read-only**. It never writes. No "May I" needed.
 
 ## See also
 
-- `_shared/collaborative-protocol.md`
-- `_shared/template-registry.md`
-- `_tests/runner.md`
-- `_tests/specs/` — per-skill behavioral specs
+- `references/collaborative-protocol.md`
+- `references/template-registry.md`
+- `tests/runner.md`
+- `tests/specs/` — per-skill behavioral specs

package/skills/{_meta → workflow}/using-summer/SKILL.md

@@ -47,6 +47,8 @@ Scenes are always `.tscn`/`.scn`. Resources are always `.tres`/`.res`. Drive the
 
 The engine must be running for MCP tools that touch scenes or diagnostics. If it isn't, the tool returns an error pointing the user at `summer run`.
 
+`.summer/` is the project's durable memory. `summer_get_project_context` surfaces a lightweight `projectMemory` summary; use it to read only the relevant Markdown before creative, audio, dialogue, level, or character work. Facts marked `priority: locked` are stable project decisions and require explicit user confirmation before changing.
+
 ## How to Access Skills
 
 **Claude Code / Cursor / Codex / Copilot CLI:** Use the `Skill` tool. When you invoke a skill, its content loads — follow it directly. Never use `Read` on a skill file.
@@ -83,6 +85,7 @@ These thoughts mean STOP. Check skills first.
 | "The user just wants me to start" | Most "just build it" requests still benefit from the brainstorm-game skill. Offer it. |
 | "I can read the .tscn file directly" | `summer_get_scene_tree` and `summer_inspect_node` are authoritative. Files lag the editor's in-memory state. |
 | "I'll skip the soul file" | `.summer/GameSoul.md` is what every other skill reads. Honor it. |
+| "This voice or canon fact is probably fine to change" | Check `.summer/memory` first. `priority: locked` facts require explicit user confirmation. |
 | "I don't need to brainstorm — they said FPS" | Even with the genre named, brainstorm-game scopes mechanics, art direction, and the cut list. Skip only if explicitly told to. |
 | "I'll write the GDScript myself, no skill" | `gdscript-patterns` encodes idioms that Claude/Codex/Cursor regularly get wrong (signal connection, type hints, `_ready` vs `_process`). |
 | "The engine isn't running, I'll just edit files" | Editing scene files directly while the engine is running silently overwrites in-memory state. Check the skill. |
@@ -122,8 +125,8 @@ Do NOT fall back to editing `.tscn` files directly. The engine reads them on dis
 If skills aren't found or the MCP server fails to start:
 
 1. Check whether `summer` is on PATH: `which summer` / `where summer`.
-2. If not, point them at: `npm install -g summer-engine` then `summer setup <agent> --yes`.
-3. If `summer doctor` is available, run it: `summer doctor` reports auth, engine, port, and skill state.
+2. If not, point them at: `npx -y summer-engine@latest setup <agent> --yes --force`.
+3. If `summer doctor` is available, run it: `summer doctor` reports auth, engine, port, project memory, and skill state.
 
 ## User Instructions Trump Everything
 

package/skills/workflow/verification-before-completion/SKILL.md

@@ -0,0 +1,139 @@
+---
+name: verification-before-completion
+description: Use when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidence before assertions always
+---
+
+# Verification Before Completion
+
+## Overview
+
+Claiming work is complete without verification is dishonesty, not efficiency.
+
+**Core principle:** Evidence before claims, always.
+
+**Violating the letter of this rule is violating the spirit of this rule.**
+
+## The Iron Law
+
+```
+NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE
+```
+
+If you haven't run the verification command in this message, you cannot claim it passes.
+
+## The Gate Function
+
+```
+BEFORE claiming any status or expressing satisfaction:
+
+1. IDENTIFY: What command proves this claim?
+2. RUN: Execute the FULL command (fresh, complete)
+3. READ: Full output, check exit code, count failures
+4. VERIFY: Does output confirm the claim?
+   - If NO: State actual status with evidence
+   - If YES: State claim WITH evidence
+5. ONLY THEN: Make the claim
+
+Skip any step = lying, not verifying
+```
+
+## Common Failures
+
+| Claim | Requires | Not Sufficient |
+|-------|----------|----------------|
+| Tests pass | Test command output: 0 failures | Previous run, "should pass" |
+| Linter clean | Linter output: 0 errors | Partial check, extrapolation |
+| Build succeeds | Build command: exit 0 | Linter passing, logs look good |
+| Bug fixed | Test original symptom: passes | Code changed, assumed fixed |
+| Regression test works | Red-green cycle verified | Test passes once |
+| Agent completed | VCS diff shows changes | Agent reports "success" |
+| Requirements met | Line-by-line checklist | Tests passing |
+
+## Red Flags - STOP
+
+- Using "should", "probably", "seems to"
+- Expressing satisfaction before verification ("Great!", "Perfect!", "Done!", etc.)
+- About to commit/push/PR without verification
+- Trusting agent success reports
+- Relying on partial verification
+- Thinking "just this once"
+- Tired and wanting work over
+- **ANY wording implying success without having run verification**
+
+## Rationalization Prevention
+
+| Excuse | Reality |
+|--------|---------|
+| "Should work now" | RUN the verification |
+| "I'm confident" | Confidence ≠ evidence |
+| "Just this once" | No exceptions |
+| "Linter passed" | Linter ≠ compiler |
+| "Agent said success" | Verify independently |
+| "I'm tired" | Exhaustion ≠ excuse |
+| "Partial check is enough" | Partial proves nothing |
+| "Different words so rule doesn't apply" | Spirit over letter |
+
+## Key Patterns
+
+**Tests:**
+```
+✅ [Run test command] [See: 34/34 pass] "All tests pass"
+❌ "Should pass now" / "Looks correct"
+```
+
+**Regression tests (TDD Red-Green):**
+```
+✅ Write → Run (pass) → Revert fix → Run (MUST FAIL) → Restore → Run (pass)
+❌ "I've written a regression test" (without red-green verification)
+```
+
+**Build:**
+```
+✅ [Run build] [See: exit 0] "Build passes"
+❌ "Linter passed" (linter doesn't check compilation)
+```
+
+**Requirements:**
+```
+✅ Re-read plan → Create checklist → Verify each → Report gaps or completion
+❌ "Tests pass, phase complete"
+```
+
+**Agent delegation:**
+```
+✅ Agent reports success → Check VCS diff → Verify changes → Report actual state
+❌ Trust agent report
+```
+
+## Why This Matters
+
+From 24 failure memories:
+- the user said "I don't believe you" - trust broken
+- Undefined functions shipped - would crash
+- Missing requirements shipped - incomplete features
+- Time wasted on false completion → redirect → rework
+- Violates: "Honesty is a core value. If you lie, you'll be replaced."
+
+## When To Apply
+
+**ALWAYS before:**
+- ANY variation of success/completion claims
+- ANY expression of satisfaction
+- ANY positive statement about work state
+- Committing, PR creation, task completion
+- Moving to next task
+- Delegating to agents
+
+**Rule applies to:**
+- Exact phrases
+- Paraphrases and synonyms
+- Implications of success
+- ANY communication suggesting completion/correctness
+
+## The Bottom Line
+
+**No shortcuts for verification.**
+
+Run the command. Read the output. THEN claim the result.
+
+This is non-negotiable.