voidmachine 5.0.8 → 7.0.0

package/core-assets/skills/void-tdd/SKILL.md

@@ -22,12 +22,12 @@ test evidence, and never use exploratory mode to mean "tested elsewhere".
 
 ## Modes
 
-Three postures, chosen by context. If unsure of the mode, ask explicitly before coding.
+Three postures, chosen from the actual behavior and project configuration. Resolve routine mode selection from those facts; ask only when a material trade-off needs the user.
 
 | Mode | When | Posture |
 |---|---|---|
-| **strict** | New behavior on production code, hotfix on paying surface, refactor that changes observable behavior, DB integration that affects business invariants | Iron Law (zero line of production code without a failing test that requested it) + mutation testing when the project has a mutation runner + 100% coverage + commit/PR evidence trail |
-| **souple** | Integration glue tested at a higher level (E2E + handler covers the chain), framework wiring, config | RED-GREEN-REFACTOR without mutation gate, ≥ 80% coverage on business code, no commit-by-phase ritual |
+| **strict** | New behavior on production code, hotfix on paying surface, refactor that changes observable behavior, DB integration that affects business invariants | Iron Law (zero line of production code without a failing test that requested it) + mutation testing when the project has a mutation runner + behavior/risk coverage + observed RED/GREEN evidence |
+| **souple** | Integration glue tested at a higher level (E2E + handler covers the chain), framework wiring, config | RED-GREEN-REFACTOR without mutation gate, project coverage thresholds, no commit-by-phase ritual |
 | **exploratory** | Documented spike, throwaway POC, scripts marked as such, draft work | No TDD obligation. The file MUST declare throwaway status + deletion date in a header comment. If the code survives the spike, it transitions to strict before merging to prod. |
 
 ### Auto-detection heuristic
@@ -37,9 +37,9 @@ If no explicit `Mode:` marker is in the task or a file header comment, apply:
 - Path matches `<config.paths.business>` and not in `<config.paths.spikes>` nor in `docs/` → **strict**
 - Path matches `<config.paths.spikes>`, draft folder, or scaffolds → **exploratory**
 - Path matches `<config.paths.serverActions>` (boundary HTTP / Server Action) AND the pure logic is in `services/` with strict tests → **souple** on the handler, **strict** on the service
-- Otherwise → **souple** + ask confirmation if in doubt
+- Otherwise → **souple** for wiring; **strict** for new behavior
 
-Paths come from `voidcorp.config.json`. Defaults are documented in `packages/core/claude/skills/void-tdd/defaults.md`.
+Paths and commands come from `.void/config.json`. Explicit project requirements take precedence.
 
 ### Override
 
@@ -61,14 +61,10 @@ ZERO LINE OF PRODUCTION CODE WITHOUT A FAILING TEST THAT REQUESTED IT.
 
 ### If you wrote code before the test (strict)
 
-- You **delete** it. Delete means delete.
-- Do not keep anything "as reference"
-- Do not "adapt" existing code while writing the tests
-- Do not look at the deleted code while re-implementing
-- Implement fresh from the tests
-
-Sunk-cost fallacy: the time is already lost. Keeping unverified code is technical debt, not an asset.
-
+Stop and report the missing RED evidence honestly. Reproduce the intended behavior against the
+unchanged base before continuing; preserve unrelated work. Never fabricate test chronology or
+claim a test that first passed on the implementation proved the missing behavior. The reviewer
+must be able to inspect the actual failing test before the production behavior change.
 ---
 
 ## Cycle
@@ -165,24 +161,15 @@ All tests must pass after fix.
 
 ### REFACTOR
 
-After GREEN (and after MUTATE/KILL in strict), assess the improvements.
-
-| Priority | Action | Examples |
-|---|---|---|
-| Critical | Now | Knowledge duplication, > 3 nesting levels, critical surviving mutations |
-| High | This session | Magic numbers, unclear names, functions > 30 lines |
-| Nice | Later | Minor renames, single-use helpers |
-| Skip | Do not touch | Already clean code |
-
-Tests must stay green at every step.
-
-Load the `void-refactor` skill for the detailed methodology (RED-GREEN-REFACTOR strict commit boundaries).
-
+After GREEN, make only the refactor needed to keep the changed code clear, correctly bounded
+and free of relevant duplication. KISS and SOLID guide that judgment. Stop once the behavior,
+applicable proofs and design contract hold; optional naming or extraction preferences do not
+start an improvement loop. Keep tests green. `void-refactor` owns behavior-preserving changes.
 ---
 
 ## Stack glue
 
-### Commands (read from `voidcorp.config.json`)
+### Commands (read from `.void/config.json`)
 
 - Unit: `<config.commands.testUnit>` (e.g. `bunx vitest run`, `pnpm vitest`, `npm test`)
 - E2E: `<config.commands.testE2e>` (e.g. `bunx playwright test`)
@@ -226,61 +213,23 @@ directly. Full anti-mock-business rationale: the `void-testing` skill.
 
 ## Coverage (strict)
 
-100% by default on the business layer (services + domain). Verification before PR approval:
-
-```bash
-<config.commands.testUnit> --coverage
-```
-
-Target reading:
-
-```
-All files | % Stmts | % Branch | % Funcs | % Lines | Uncovered Line #s
-----------|---------|----------|---------|---------|---
-All files |   100   |   100    |   100   |   100   |
-```
-
-### Exception
-
-If 100% is impossible (e.g. a Sentry wrapper whose init branch is not testable without an HTTP cassette):
-
-1. Document in the package README: why + where the missing coverage is compensated (integration/E2E)
-2. Explicit Folpe approval
-3. List in repo CLAUDE.md under "Test coverage exceptions"
-
-Burden of proof on the requester. 100% remains the default.
-
----
+The project's configured coverage thresholds remain binding; never lower them to obtain green.
+Cover the changed invariants, error paths and boundaries, including meaningful counterexamples.
+Use coverage to find missing behavior, not to create assertions that only mirror implementation.
+No universal percentage overrides the project's policy. If a branch is covered at a higher
+level, cite that real proof rather than duplicate it. A safety-critical gap still blocks.
 
 ## TDD Evidence (strict)
 
-The commit history must show the RED → GREEN → [MUTATE → KILL] → REFACTOR progression.
-
-```
-abc123  test: add failing test for retryOperation backoff
-def456  feat: implement retryOperation exponential backoff
-ghi789  test: strengthen boundary tests post-mutation (kills 3 survivors)
-jkl012  refactor: extract backoff helper for clarity
-```
-
-### Documented exceptions
-
-If evidence is not linear (multi-session, grouped refactor, context resume), document in the PR:
-
-```markdown
-## TDD Evidence
-
-RED phase: commit c925187
-GREEN phase: commits 5e0055b, 9a246d0
-MUTATE + KILL: commit 7b8c9d0
-REFACTOR: commit 11dbd1a
-
-Test Evidence:
-- 4/4 tests passing (vitest run, 7.7s)
-- Mutation score: 94% (3/52 documented survivors)
-```
+Observe a failing test before changing production behavior. Keep the RED command and result
+from before the implementation, why it failed, then the GREEN command and result after it.
+Bind results to the tested source state and scope so later changes invalidate affected proofs.
+Separate RED and GREEN commits are not required; keep final commits logical and bisectable.
+A test file's existence, a skill read, or an arbitrary failed command is not RED evidence.
 
-Exception on the evidence presentation, **never on the process**.
+Record the actual runner result and relevant assertion, not a ritual checklist. Existing
+project evidence storage is enough; no extra telemetry service or transcript export is required.
+Missing evidence is unknown, never reconstructed from memory as an observed run.
 
 ---
 
@@ -317,7 +266,7 @@ Source: superpowers/test-driven-development. Keep the full list — this is the
 - "TDD is dogmatic, I am pragmatic"
 - "This case is different because..."
 
-→ **All these phrases mean: delete, start over in strict.**
+→ **Stop, identify the missing proof, and restore the test-first discipline without destroying unrelated work.**
 
 ---
 
@@ -352,11 +301,11 @@ Before marking the work complete:
 - [ ] Tests use real code (mocks only where unavoidable)
 - [ ] Edge cases and errors covered
 - [ ] Mutation testing run + survivors handled (strict, when `commands.mutation` exists)
-- [ ] Coverage verified 100% or exception documented (strict)
-- [ ] Commit history shows TDD evidence or documented exception (strict)
-- [ ] Refactor evaluated and applied where it has value (all Critical/High priorities addressed)
+- [ ] Relevant behavior covered and configured coverage thresholds satisfied
+- [ ] Actual RED-before-implementation and GREEN evidence retained (strict)
+- [ ] Necessary refactoring complete; optional improvements do not reopen the cycle
 
-Cannot check every box in strict? You skipped TDD. Restart.
+A missing required proof must be resolved or reported; do not restart already-proven work.
 
 ---
 
@@ -368,7 +317,7 @@ Cannot check every box in strict? You skipped TDD. Restart.
 | Test too complex | Design too complex. Simplify the API. |
 | Must mock everything | Code too coupled. Use parameter injection (see `void-hexagonal-architecture` skill). |
 | Huge test setup | Extract helpers. Still complex? Rethink the design. |
-| Mode not obvious | Ask the user. Default to souple > strict when in doubt. |
+| Mode not obvious | Inspect the changed behavior and project policy; ask only about a material trade-off. |
 
 ---
 

package/core-assets/skills/void-testing/SKILL.md

@@ -128,7 +128,7 @@ Describe the behavior. Imperative. Specific.
 - `it should retry` (the "should" is fluff)
 </Bad>
 
-The companion hook `test-name-lint` warns on weak patterns (`test`, `works`, `should` as the entire name).
+The `test-name-lint` write hook blocks detected generic names: exactly `test`, or names starting with `should `, `work` or `works`. The owning rule defines the lexical scope.
 
 ---
 
@@ -231,7 +231,7 @@ Each snapshot has a reason. No `.toMatchSnapshot()` outside the whitelist withou
 
 Banned in committed code. They mean "I will not run this." If you mean "this case is intentionally not yet tested," write a `it.todo('description')` — the test runner reports todos.
 
-The companion hook `no-only-no-skip` blocks commits with `.only` / `fdescribe` / `xit` in the staged diff (allowed in `**/__skip-on-purpose__/**` whitelist with justifying comment).
+The `no-only-no-skip` write hook rejects focused and skipped calls in proposed test files, including `fit`, `fdescribe`, `xit`, `xdescribe` and suite `.skip`. There is no path whitelist; use an explicit `todo` for pending coverage.
 
 ### Implementation spies as primary assertion
 
@@ -259,8 +259,8 @@ Use pglite or dev branch. Mocking Drizzle breaks at every schema change while pr
 
 ## Companion hooks
 
-- **`no-only-no-skip`** — block on `.only` / `fdescribe` / `xit` / `.skip` in staged diff (whitelist: `**/__skip-on-purpose__/**`)
-- **`test-name-lint`** — warn on weak test names matching `/^\s*(test|works|should)\s*$/i`
+- **`no-only-no-skip`** — blocks focused/skipped calls on supported test writes; no path exemption
+- **`test-name-lint`** — blocks the generic test-name patterns described above
 - **`no-business-mock`** — warn on `vi.mock\('@/(services|domain)/...'\)` patterns
 - **`no-snapshot-default`** — warn on new `.toMatchSnapshot()` outside `**/__visual__/**` whitelist
 
@@ -271,7 +271,7 @@ See `../../hooks/`.
 ## Anti-rules
 
 - MUST NOT decide WHETHER a test exists. That is `void-tdd`'s Iron Law.
-- MUST NOT decide coverage thresholds. That is `void-tdd`'s 100%-on-business-layer default + documented exceptions.
+- MUST NOT decide coverage thresholds. That is the project's configured policy, applied by `void-tdd` alongside behavior/risk coverage.
 - MUST NOT decide architecture (what is a port, what is an adapter). Hexagonal owns that.
 - MUST NOT decide framework specifics (which Vitest reporter, Playwright trace mode). Pack-level config.
 - MUST NOT silently allow snapshot creep.

package/core-assets/skills/void-ticket/SKILL.md

@@ -20,6 +20,8 @@ A ticket an implementation agent can execute with zero follow-up questions. It d
 - Always writes to the project's tracker (Linear / Jira / GitHub / ...). On a project with a fixed tracker, team, and label conventions, use them and do not re-ask.
 
 Do NOT use this to execute a ticket (`void-implement`) or to sequence many steps (`void-plan`).
+This skill is not a prerequisite for an explicit user request with clear acceptance criteria;
+create tracker work only when requested or required by the declared programme.
 
 ---
 

package/core-assets/skills/void-typescript-strict/SKILL.md

@@ -5,7 +5,7 @@ description: TS strict baseline. Zero any budget, branded types for domain primi
 
 # typescript-strict — voidcorp craftsman edition
 
-Types describe truth. The compiler runs first. `any` is banned. `as` is rejected outside narrow exceptions. Domain primitives wear branded types. Discriminated unions model state. Exhaustive switches are verified by `never`. This skill is the language baseline — every other skill composes on top of it.
+Types describe truth. The compiler runs first. `any` is banned. `as` is rejected outside narrow exceptions. Non-interchangeable domain primitives use branded types. Discriminated unions model state. Exhaustive switches are verified by `never`. This skill is the language baseline — every other skill composes on top of it.
 
 **Attribution**: see `.source` in this directory.
 
@@ -169,7 +169,7 @@ ESLint rule `@typescript-eslint/switch-exhaustiveness-check` (configured in `pac
 
 ## Branded types for domain primitives
 
-Raw `string` for things with semantics is the #1 source of "passed the wrong ID" bugs. Brand it.
+Brand a primitive when accidental substitution or invalid construction violates a real domain contract. Preserve existing meaningful brands; avoid wrappers for local values with no distinct invariant.
 
 ```typescript
 // in @voidcorp/core/branded
@@ -189,7 +189,7 @@ function createUserId(raw: string): UserId {
 
 A function taking `UserId` cannot accept a raw `string`. The compiler refuses. Same shape, different identity.
 
-Apply to:
+Typical candidates, when the contract requires non-interchangeability:
 
 - IDs (`UserId`, `OrgId`, `OrderId`, ...)
 - Email, PhoneNumber, IsoDate, IsoDuration
@@ -255,7 +255,7 @@ See `../../hooks/`.
 ## Composition with other skills
 
 - **With `void-functional`**: this skill provides the type machinery (discriminated unions, `Result`, branded primitives); `void-functional` decides WHEN to model with sum types vs records, when to return `Result` vs throw.
-- **With `void-domain-driven-design`**: this skill enforces branded types for domain primitives; DDD decides which entities are aggregates and which are value objects.
+- **With `void-domain-driven-design`**: this skill enforces meaningful non-interchangeable domain types; DDD decides which entities are aggregates and which are value objects.
 - **With `void-hexagonal-architecture`**: ports are typed interfaces; types travel across boundaries via Zod schemas.
 - **With `void-tdd`**: a RED test using a branded type forces the production code to surface a smart constructor.
 - **With `void-code-review`**: review skill flags untyped IDs, `any` slips, missing `satisfies`.
@@ -287,7 +287,7 @@ See `../../hooks/`.
 ## Final rule
 
 ```
-Every TypeScript file → no any, no rogue as, exhaustive switches, branded domain primitives.
+Every TypeScript file → no any, no rogue as, exhaustive switches, brands where domain contracts require them.
 Otherwise            → this is not voidcorp typescript-strict.
 ```
 

package/core-assets/skills/void-verify/SKILL.md

@@ -1,11 +1,11 @@
 ---
 name: void-verify
-description: Final pre-flight checklist. Twelve items observed (not assumed) — typecheck, tests, hooks, mobile+desktop, commit why, review evidence. Skipping requires reason. Use at end of every task.
+description: Verify acceptance with applicable tests, types, hooks and independent review; reuse unaffected proofs and report concrete limits. Use before claiming completion.
 ---
 
 # verify — voidcorp craftsman edition
 
-"Task complete" claims diverge from reality when they are based on belief, not observation. Tests "passed earlier." Lint "should be clean." The mobile view "is probably fine." This skill is the final pre-flight: a twelve-item checklist, read at the end, each item OBSERVED, skipping documented.
+Completion rests on observed acceptance and applicable proofs. This skill checks evidence and communicates limits; `void-implement` owns which passes the change needs.
 
 **Attribution**: see `.source`. Primary source: superpowers/verify + citypaul completion checklists.
 
@@ -13,9 +13,7 @@ description: Final pre-flight checklist. Twelve items observed (not assumed) —
 
 ## When to run
 
-At the end of EVERY task before reporting "done." Even tasks that feel trivial. The checklist for a one-line fix is short; the discipline is the same.
-
-If you find yourself wanting to skip the checklist "because it's a small change," that is the signal: run it anyway, the small ones are where it pays the most.
+Before claiming a deliverable complete. Scale verification to the affected behavior and project requirements; a small change still needs the proof of its result.
 
 ---
 
@@ -38,160 +36,60 @@ They defer draft validation with an explicit non-success outcome, rerun on readi
 and preserve merge queue checks. Never install them or change remote protection merely
 because this skill was invoked.
 
-## The checklist
-
-Read item by item. Do not run from memory. Each item is OBSERVED, not assumed.
-
-| # | Item | Composed with |
-|---|---|---|
-| 1 | Typecheck passes (`tsc --noEmit`) | `void-typescript-strict` + `tsc-noemit-precommit` hook |
-| 2 | Tests pass — **observed after last code change** | `void-tdd` + `void-testing` |
-| 3 | Lint passes (Biome) | `pack-monorepo` config |
-| 4 | Coverage acceptable (per `void-tdd` mode strict / souple / exploratory) | `void-tdd` |
-| 5 | Hooks pass (pre-commit dry-run on staged set) | All hooks (`tdd-guard`, `tigerstyle-check`, `no-any-grep`, ...) |
-| 6 | UI changes verified in BOTH mobile and desktop viewports | `void-frontend-design` + `void-accessibility` (mobile-first dual-quality) |
-| 7 | Observability hooks present for new business logic | `void-observability` |
-| 8 | Security review check for any boundary / auth / secret change | `void-security-guidance` + `void-security-audit` |
-| 9 | Documentation updated if any convention changed | `void-commit-discipline` "always say why" |
-| 10 | Commit message includes the why (not just what) | `void-commit-discipline` |
-| 11 | Independent review ran on the final change with no demonstrated blocking defect left open; review evidence block present in PR body (strict mode). A missing citation or explanation alone never fails this item | `void-code-review` |
-| 12 | Spec / plan linked if work derives from one; plan resume point updated | `void-brainstorm` + `void-plan` |
-
-Items 6, 7, 8 only fire when the change touches their domain.
-
----
-
-## Observed, not assumed
-
-| Sign | What it means |
-|---|---|
-| "Tests should pass" | NOT observed. Run them again, then check. |
-| "Linting was fine earlier" | Not observed since last change. Re-run. |
-| "Mobile is probably the same" | NOT observed. Screenshot via `void-qa` (claude-in-chrome) on a phone viewport. |
-| "Sentry is set up, so observability is handled" | NOT for this code path. Did you add the breadcrumb? The log? |
-| "The hook ran before, why check" | Did you edit since? If yes, run again. |
-
-"Should" and "probably" are the words this skill exists to eliminate. The named excuses (vendored from gstack `/ship`): "should work now" → run it; "I'm confident" → confidence is not evidence; "trivial change" → trivial changes break prod. If code changed since the last run, the last run is stale.
-
----
-
-## Plan completion audit (vendored from gstack `/ship`)
-
-The 12-item checklist verifies *the build works*. This verifies *you built what was specified*. When the work derives from a plan or ticket, classify **every actionable item** against the diff:
-
-- `DONE` / `PARTIAL` / `NOT DONE` / `CHANGED` (deliberately deviated) / `UNVERIFIABLE` (cannot be proven from the diff — cross-repo, external state, runtime-only).
-- **Honesty rule**: code that *handles* a deliverable is not the deliverable. "Added the webhook handler" ≠ "the webhook fires end-to-end."
-- **Per-item confirmation for `UNVERIFIABLE`**: surface each one individually and ask — never a single blanket "all done?" over a list you cannot actually verify.
-- **Scope drift**: did you build exactly what was asked? Name every piece of creep ("while I was in there…") and every missing requirement. **Creep is removed, or it carries one line in the commit saying why the change would be wrong without it.** This check was informational for its whole life and caught nothing: naming a creep and shipping it anyway satisfied it. Measured on 2026-08-31, in the session that hardened this very skill — a marker scaffold no gate had asked for, defensible, and nothing would have made anyone say so. Stop when the requirement is satisfied; the smallest sufficient change is the deliverable, not the floor.
-
----
-
-## Skipping items
-
-Items can be skipped, but ONLY with an explicit stated reason in the completion report.
-
-```markdown
-- [x] Item 1: Typecheck passes (observed)
-- [x] Item 2: Tests pass (observed, vitest run, 4/4 passing)
-- [-] Item 6: UI viewports SKIPPED — no UI change in this diff
-- [-] Item 7: Observability SKIPPED — pure refactor (no new business logic)
-- [x] Item 9: Documentation N/A — no convention changed
-- [x] Item 10: Commit message includes why (linked to spec)
-- [x] Item 11: Review evidence block written
-- [x] Item 12: Plan resume point updated (next step: 5)
-```
-
-Silent skipping is the bug class this skill exists to prevent. Explicit skip with reason is fine; explicit skip without reason is not.
-
----
-
-## Output format
-
-When reporting "done," include the checklist with check / skip status and the reason for any skip. The user sees the signals.
-
-For multi-step plans (composes with `void-plan`): update the plan's "Resume point" section with the completed step.
-
-For PRs (composes with `void-code-review`): the checklist feeds the Review Evidence block — they are not separate work.
-
----
-
-## Examples
-
-### Small fix
-
-```markdown
-Done. Verification:
-
-1. ✅ Typecheck (observed)
-2. ✅ Tests pass (vitest run, 1 new test for the bug, all green)
-3. ✅ Lint passes
-4. ✅ Coverage holds (line + branch unchanged)
-5. ✅ Pre-commit hooks (tdd-guard allowed test+fix pair, others green)
-6. — N/A (no UI)
-7. — N/A (no new business logic)
-8. — N/A (no boundary change)
-9. — N/A (no convention change)
-10. ✅ Commit messages: `test: reproduce X` + `fix: <root cause>`
-11. ✅ Review evidence block written (single-blocker resolved, 0 nits)
-12. ✅ Spec linked (plan N/A — bug fix, no plan)
-```
-
-### Plan step
-
-```markdown
-Step 4 of plan `2026-06-01-checkout-flow-plan.md` complete. Verification:
-
-1. ✅ Typecheck (observed)
-2. ✅ Tests pass (vitest run --filter checkoutCart, 6/6 passing, mutation 96%)
-3. ✅ Lint passes
-4. ✅ Coverage 100% on services/checkout (strict mode)
-5. ✅ Pre-commit hooks all pass
-6. — N/A (use-case layer, not UI)
-7. ✅ Observability: structured logs added at use-case entry/exit
-8. ✅ Security: zod validation at boundary, no secret in commit
-9. ✅ docs/DOMAIN.md updated with "checkout intent" term
-10. ✅ Commits: test:reproduce / feat:implement / refactor:extract per Two-Hat
-11. ✅ Review evidence block prepared (waiting for code-review run)
-12. ✅ Plan resume point updated to Step 5
-
-Next: invoke `void-code-review` for the Step 4 commits.
-```
-
----
-
-## Composition with other skills
-
-- **Runs LAST**, after every other skill.
-- **With `void-tdd`**: items 2, 4 are tdd-mode-aware.
-- **With `void-testing`**: item 2 includes "pristine output."
-- **With `void-typescript-strict`**: item 1.
-- **With `void-code-review`**: item 11 feeds the Review Evidence block.
-- **With `void-commit-discipline`**: items 9, 10.
-- **With `void-plan`**: item 12 — completion updates the plan resume point.
-- **With `void-frontend-design` + `void-accessibility`**: item 6.
-- **With `void-observability`**: item 7.
-- **With `void-security-guidance`**: item 8.
-
----
-
-## Anti-rules
-
-- MUST NOT define what "complete" means functionally — the task defines that.
-- MUST NOT skip items silently.
-- MUST NOT report completion in the middle of work (e.g., "Step 1 done, moving to Step 2" without verifying Step 1).
-- MUST NOT substitute "looks fine" for observed signals.
-- MUST NOT take the user out of the loop — the user sees the signals.
-
----
-
-## Final rule
-
-```
-Task → all 12 items observed (or skip with stated reason) → user sees the signals → THEN report "done."
-Otherwise → it is not voidcorp completion.
-```
-
-Checklists prevent omissions even for experts. The discipline pays for itself the first time it catches the test that "should have" been run.
+## Applicable evidence
+
+Inspect the accepted scope and actual diff. Reuse current unaffected proofs when their declared
+inputs are unchanged; rerun affected checks and required candidate/merge-group checks. A changed
+comment does not invalidate an unrelated behavior proof, but uncertainty about dependencies
+must stay explicit. Never reuse a stale subject or downgrade a project's required CI.
+
+| Concern | Evidence when applicable |
+| --- | --- |
+| Behavior | Actual RED before production behavior, then relevant tests GREEN; `void-tdd` + `void-testing` |
+| Types and static checks | Configured typecheck/lint for affected packages; no invented commands |
+| Coverage | Changed invariants, boundaries and errors; configured thresholds remain binding |
+| Hooks | Actual required hook result for the edit or staged set, not merely installed configuration |
+| UI | Affected controls/states verified on mobile and desktop, including keyboard and touch |
+| Security | Affected trust boundaries inspected during implementation and final review |
+| Observability | New failure/side-effect paths have useful diagnostics without secrets |
+| Documentation | Changed public behavior or convention documented; no template-only requirement |
+| Review | Exact candidate/base, independent reviewer, original findings and evidenced resolutions |
+| Delivery | Accepted criteria met; required CI/merge/deployment states observed separately |
+
+Installed, applicable, invoked and passed are different claims. An unknown result is never
+reported as passed. A skill read does not prove its instructions were applied; a hook's presence
+does not prove it ran; a test file does not prove a RED/GREEN cycle. Show available evidence and
+name unobservable parts without manufacturing a new blocking gate for telemetry alone.
+
+## Scope and completion
+
+For each acceptance criterion determine whether it is done, partial, changed or unverified.
+Code that handles a deliverable is not proof of that deliverable: a webhook handler is not proof
+that the provider delivered its event. Resolve the actual missing proof or permission. Ask only
+for a decision beyond the mandate, not approval of a routine verification step.
+
+Stop when the accepted outcome, applicable proofs and independent review hold. Fix concrete
+blocking defects; optional improvements never request another general review or correction.
+Remove unrelated scope unless the requested behavior requires it.
+
+## Reporting
+
+Give the result, relevant commands/results, independent review outcome and material limits.
+Do not print a twelve-item checklist with irrelevant N/A rows. Keep applicability reasoning in
+the existing task/review evidence; summarize it when it explains a real omission or decision.
+For a standalone sequential plan, update its existing resume point. For a programme, the declared tracker alone owns mutable progress; do not add a current/next unit to the plan.
+The PR evidence and final report reuse the same observed results rather than duplicate work.
+
+Once at ticket end, the coordinator closes each explicitly bound source with
+`void-machine mission usage-unbind --id <mission> --source <session-journal>`; this remains possible
+after mission closure. Close is final for that source/mission pair and retries never reopen it.
+Never recreate a mission to bypass a verdict or reopen proof. Then, if a mission ID exists,
+include the informational recap from
+`void-machine mission inspect --id <mission> --usage` (`--json` for structured output).
+Reuse that recap in the final report; do not run it per edit or chain its exit status as a new
+completion gate. Its exit status remains the mission verdict, not telemetry coverage. Missing
+mission linkage or telemetry is explicitly unknown. Codex skill reads are not invocation hits.
+For the complete catalogue and triggers, use `void-machine cheatsheet --format markdown`.
 
 ## Bounded review evidence