voidmachine 5.0.8 → 6.0.0

package/core-assets/hooks/outcome-meter.sh

@@ -1,5 +1,6 @@
 #!/usr/bin/env bash
-# Non-blocking adapter for PostToolUse and Stop canonical events.
+# PostToolUse outcomes and repeated-read advice share this non-blocking process.
+# PostToolUseFailure resets advice only; Stop retains its canonical event.
 set -uo pipefail
 
 ROOT="${CLAUDE_PROJECT_DIR:-$(git rev-parse --show-toplevel 2>/dev/null || pwd)}"

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

@@ -18,7 +18,7 @@ reviewed pull request instead. Promotion to the branch that deploys stays human.
 ## What this skill does NOT do
 
 It owns no ticket cycle. Every worker runs the canonical `void-implement` skill, whole, once per
-ticket, specialist panel included. If you find yourself writing "then the worker runs the tests,
+ticket, with applicability owned there. If you find yourself writing "then the worker runs the tests,
 then reviews..." inside autopilot, stop: that behaviour has one owner, and two copies drift until
 a ticket gets a different standard depending on how it was started.
 
@@ -31,9 +31,9 @@ names none. When the person says they merge themselves, run `void-machine autopi
 Promotion from the integration branch to the one that deploys stays human.
 
 It never merges a change to the machinery that judges merges. A pull request touching
-`.github/**`, `scripts/independent-review-check.mjs`, `.void/program.md`, `packages/core/hooks/**`,
+`.github/**`, `.void/program.md`, `packages/core/hooks/**`,
 what a judging workflow runs from outside `.github`
-(`scripts/promotion-authority.mjs`, `scripts/auto-merge-contract.mjs`, `scripts/verify.mjs`,
+(`scripts/auto-merge-contract.mjs`, `scripts/verify.mjs`,
 `packages/core/enforce/**`), what judges a publication (`scripts/prepare-release-artifact.mjs`,
 `scripts/verify-release-publication.mjs` and the two release contracts they read), the loop code that believes a verdict and merges (`loop.ts`,
 `loop-observe.ts`, `branch-identity.ts`, `commands/autopilot-loop.ts`), the local chain of judgment

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

@@ -1,11 +1,11 @@
 ---
 name: void-brainstorm
-description: "Engage on a raw idea, or the moment an exchange settles a behaviour, boundary or trade-off: pressure-test, one question at a time, 2-3 approaches, spec written and approved before any code."
+description: "Resolve a raw idea or consequential design ambiguity: inspect context, compare alternatives and record approved choices. Clear authorized implementation requests go directly to void-implement."
 ---
 
 # brainstorm — voidcorp craftsman edition
 
-Start by understanding the project context. Then ask questions one at a time to refine the idea. Once you understand what is being built, present the design in sections, get approval, write the spec to `docs/specs/`, and transition to `void-plan`. **No implementation skill, no code, no scaffolding until the spec is written and approved.**
+Use this skill when intent, behavior or a consequential boundary remains undecided. Inspect the existing context, resolve the decisions that change the outcome, and record the approved design. `void-implement` owns applicability: a clear implementation request does not need a design interview.
 
 **Attribution**: see `.source`. Primary source: superpowers/brainstorm; the upstream idea-pressure-test mode is the distilled `gstack:/office-hours` diagnostic, vendored for void-machine.
 
@@ -53,23 +53,22 @@ everyone to skip Step 0 when it matters.
 
 ---
 
-## HARD GATE
+## Decision gate
 
-Do NOT invoke any implementation skill, write any code, scaffold any project, or take any implementation action until:
+Do not implement an unresolved choice that materially changes scope, safety, external effects
+or a lasting contract. Present the decision and its trade-offs together, then obtain the needed
+approval. Work that does not depend on it may continue.
 
-1. The spec is written to `docs/specs/YYYY-MM-DD-<topic>.md`
-2. The spec has passed self-review
-3. The user has explicitly approved the written spec
-
-**This applies to EVERY project, regardless of perceived simplicity.**
-
-The anti-pattern is "this is too simple to need a design." Every project goes through this process. Simple projects' specs are short (a few sentences for truly trivial ones), but they MUST be written and approved.
+For already authorized scope, do not request approval again merely because it has been written
+into a spec or plan. The user's explicit request and accepted decisions are valid inputs.
+A durable spec is useful for a structural or multi-step change; a mechanical fix or bounded
+request may go directly to `void-implement` with its acceptance criteria.
 
 ---
 
 ## Ingesting a forge spec
 
-If `docs/specs/` holds a spec with `source: forge` in its frontmatter (the forge→harness artifact contract), the up-front thinking is already done. **Verify and fill the gaps — do not re-ask what the spec already answers.** The 18 recon variables cover persona, pain, positioning, competition, pricing, and the visual identity; the winning design and critique verdict are attached. Read them, confirm they still hold, and ask only about what is missing (a partial spec — recon without critique, or a field absent in an older `forge_version` — is ingested for what it has, with the holes listed as the only open questions). Then go straight to writing/approving the spec. Do not restart the interview from scratch.
+If `docs/specs/` holds a spec with `source: forge` in its frontmatter (the forge→harness artifact contract), the up-front thinking is already done. **Verify and fill the gaps — do not re-ask what the spec already answers.** The 18 recon variables cover persona, pain, positioning, competition, pricing, and the visual identity; the winning design and critique verdict are attached. Read them, confirm they still hold, and ask only about what is missing (a partial spec — recon without critique, or a field absent in an older `forge_version` — is ingested for what it has, with the holes listed as the only open questions). Record the accepted scope and resolve only remaining choices. Do not restart the interview or approval from scratch.
 
 ## Pressure-testing a raw idea (upstream mode)
 
@@ -86,7 +85,9 @@ Runs ONLY when the input is a raw *product idea* ("I want to build X"), not an a
 5. **Observation & surprise.** Have you watched someone use it without helping — what did they do that surprised you? Red flag: surveys and demo calls (surveys lie, demos are theater).
 6. **Future-fit.** If the world looks meaningfully different in 3 years, does this become more essential or less? Red flag: "the market grows 20%/yr" — every competitor cites the same tailwind.
 
-**Escape hatch.** If the user says "just do it": ask the 2 most critical remaining questions for their stage, then move on. If they push back a second time, respect it and proceed. Only a fully-formed plan with real evidence (named users, revenue) earns a full skip — and even then, still confirm the premises and generate alternatives.
+**Respect the mandate.** If the user says to proceed, reuse known answers and make routine
+reversible implementation choices. Ask only about a missing decision that materially changes
+the outcome or requires separate authority; do not make the user repeat the instruction.
 
 ## Process
 
@@ -119,7 +120,7 @@ Wait for the user's response. If they decline, proceed in text-only.
 
 ### Step 4 — Ask clarifying questions
 
-- One question at a time. Never batch.
+- Ask only unresolved consequential questions; group closely related questions when it reduces interruptions.
 - Multi-choice preferred when applicable (2–4 distinct mutually-exclusive options with brief descriptions and a recommended option labeled).
 - Open-ended fine when no obvious options exist.
 - Focus on: purpose, constraints, success criteria.
@@ -135,7 +136,10 @@ Wait for the user's response. If they decline, proceed in text-only.
 
 Runs on **every brainstorm, whatever the subject** — a product idea, a guard, a contract, a migration. Demand pressure-testing above belongs to a raw product idea, because a merge gate has no market to interrogate; ambition is not scoped that way, since timidity is not a property of product ideas. This pass lived inside the product-idea mode and therefore never fired on a technical subject, which is most of what gets designed here.
 
-Before settling, deliberately drop the self-imposed constraints: what does this look like at 10x — no resource limit, no "we can't because"? What is the *coolest* version the user has not considered? Carry that into Step 5: always include one "ideal / most ambitious" path and one "creative-lateral" reframing, not just the safe increment. YAGNI still prunes the *final* scope — but prune down from an ambitious set; do not start timid.
+Before settling an unresolved design, consider whether a simpler or materially better approach
+changes the outcome. Include an ambitious or lateral option only when it answers that question.
+Do not expand an already accepted scope or reopen a completed decision to manufacture alternatives.
+YAGNI prunes the options before asking the user to evaluate them.
 
 ### Step 5 — Propose 2–3 approaches
 
@@ -153,7 +157,7 @@ Once the intent is clear, present the design in sections:
 - Rollout / phases (if non-trivial)
 - TDD mode per implementation phase (strict / souple / exploratory — composes with `void-tdd` skill)
 
-Get approval AFTER each section before moving on. Scale each section to its complexity: a few sentences for simple projects, 200–300 words for nuanced ones.
+Present related decisions together and obtain approval for the unresolved consequential choices. Do not request approval section by section for explanatory prose.
 
 ### Step 7 — Write the spec
 
@@ -188,17 +192,15 @@ Read the spec with fresh eyes:
 
 Fix issues inline. No need to re-review — just fix and move on.
 
-### Step 9 — User reviews the written spec
-
-Ask the user to review the spec file before proceeding:
-
-> "Spec written and committed to `docs/specs/<file>.md`. Please review and let me know if you want changes before we start the implementation plan."
+### Step 9 — Confirm unresolved choices
 
-Wait for the user's response. If they request changes, make them and re-run self-review. Only proceed once the user approves.
+Link the written spec and identify any decision not yet authorized. Ask only about those
+remaining choices. If it records decisions already approved in this conversation, proceed.
 
-### Step 10 — Transition to `void-plan`
+### Step 10 — Transition to execution
 
-The ONLY post-brainstorming transition. Invoke plan. Do not invoke any other skill (frontend-design, mcp-builder, etc.).
+Use `void-plan` when dependencies, multiple units or later-session continuity need a durable
+sequence. A bounded single unit with clear acceptance criteria goes to `void-implement`.
 
 ---
 
@@ -221,58 +223,35 @@ Smaller, well-bounded units are easier to work with — easier for the agent to
 
 ---
 
-## Red Flags — thoughts that mean STOP
-
-| Thought | Reality |
-|---|---|
-| "This is too simple to need a design" | The gate applies to every project. Write the short version. |
-| "I need more context first" | Skill check comes BEFORE clarifying questions. |
-| "Let me explore the codebase first" | Sure, but the design discipline still applies. |
-| "I can check git/files quickly" | Files lack conversation context. Stay in the process. |
-| "Let me gather information first" | Process telling you HOW to gather information. |
-| "This doesn't need a formal skill" | If a skill exists, use it. |
-| "I'll just do this one thing first" | Check BEFORE doing anything. |
-| "This feels productive" | Undisciplined action wastes time. |
-
----
-
 ## Key principles
 
-- **One question at a time.** Never overwhelm with multiple.
-- **Multi-choice preferred.** Easier to answer than open-ended.
-- **YAGNI ruthlessly.** Remove unnecessary features from all designs.
-- **Explore alternatives.** Always propose 2–3 approaches before settling.
-- **Incremental validation.** Present design, get approval before moving on.
-- **Be flexible.** Go back and clarify when something doesn't make sense.
+- Read the actual contract before asking what it says.
+- Resolve a material ambiguity once; retain the answer through implementation.
+- Keep KISS, useful boundaries and the smallest sufficient scope.
+- Compare credible alternatives when they change the result, not for a fixed option count.
+- Document lasting structural decisions through `void-decide`.
+- Optional improvements do not reopen accepted scope or cause another review cycle.
 
 ---
 
 ## Composition with other skills
 
 - **Raw product idea** ("I have an idea..."): pressure-test it first via the upstream mode above (the vendored `/office-hours` diagnostic), then design. Broader product *roadmap / strategy* routes to `void-plan-review` (CEO lens — challenges a written plan's premise and ambition).
-- **Downstream — `void-plan`**: the ONLY post-brainstorming transition.
+- **Downstream**: `void-plan` for dependent work; `void-implement` for a bounded approved unit.
 - **With `void-tdd`**: the spec declares the TDD mode for each major implementation step. Plans then uses this.
 - **With `void-hexagonal-architecture` + `void-domain-driven-design`**: these skills inform the design's structure (bounded contexts, ports, aggregates). Brainstorming consumes their vocabulary; does not duplicate their decisions.
-- **With `void-code-review`**: a PR that introduces features without a linked spec gets flagged.
+- **With `void-code-review`**: review against the accepted behavior and constraints; an absent spec alone is not a defect.
 
 ---
 
 ## Anti-rules
 
-- MUST NOT skip the hard gate.
-- MUST NOT batch multiple questions in one message.
-- MUST NOT decide implementation details (those go to plans).
-- MUST NOT decide product roadmap / strategy (routes to `void-plan-review` CEO lens). It DOES pressure-test a raw idea's demand (the upstream mode) and push ambition on any subject (Step 4b) — both in scope, not delegated.
-- MUST NOT skip the spec-write step "because the conversation is clear."
-- MUST NOT transition to any skill other than `void-plan` post-approval.
-
----
+- Do not implement a consequential unresolved decision or infer external authorization.
+- Do not restart discovery or approvals already resolved by the user's request.
+- Do not widen product scope during implementation under the guise of ambition.
+- Do not hide material uncertainty behind a complete-looking template.
 
 ## Final rule
 
-```
-Idea → questions → 2–3 approaches → design in sections → spec written → self-review → user approves → plan.
-Otherwise → it is not voidcorp brainstorm.
-```
-
-The hard gate exists because LLM agents write very fast code for very wrong problems. The discipline pays for itself in the first project that does not have to be rewritten.
+Unresolved design → inspect → compare useful options → resolve consequential decisions →
+record → plan only as needed → implement the accepted scope.

package/core-assets/skills/void-code-review/SKILL.md

@@ -5,7 +5,7 @@ description: Pre-PR critical pass. Six dimensions (correctness, tests, security,
 
 # code-review — voidcorp craftsman edition
 
-A review without a framework is "the first ten things I noticed." This skill provides the framework: six dimensions in order, blocker vs nit, evidence block in the PR body, two modes, explicit composition with Claude Code's native `/void-code-review` and specialized agents. The skill orchestrates; it does not duplicate the deep-pass agents.
+A review examines the accepted behavior and the consequences of shipping the change. This skill provides the framework: six dimensions in order, blocker vs nit, evidence block in the PR body, two modes, explicit composition with Claude Code's native `/void-code-review` and specialized agents. The skill orchestrates; it does not duplicate the deep-pass agents.
 
 **Attribution**: see `.source` in this directory.
 
@@ -41,9 +41,9 @@ Every comment is explicitly prefixed:
 - **`QUESTION:`** — clarification request. May escalate to BLOCKER if answer reveals a defect.
 - **`PRAISE:`** — explicit acknowledgement of good code (rare, but valued).
 
-Style / naming / minor structure: `NIT:`. Correctness / missing test / security / boundary violation: `BLOCKER:`.
+Style, naming and optional refactoring are advisory. Correctness, security or a broken boundary blocks only with a concrete consequence. A missing test blocks when a demonstrated behavior or regression risk lacks an adequate proof, not because a checklist asks for another test.
 
-A review that does not use the prefixes is incomplete. The companion hook `blocker-prefix-grep` produces the BLOCKER/NIT count for the evidence block.
+Use these prefixes to make decisions legible; formatting alone never creates a blocking defect. The companion hook `blocker-prefix-grep` produces the BLOCKER/NIT count for the evidence block.
 
 ---
 
@@ -57,7 +57,7 @@ Every PR in strict mode includes a Review Evidence block:
 - **Mode**: strict
 - **Reviewer runtime**: native independent reviewer or codex CLI (one general pass)
 - **Dimensions covered**:
-  - [x] Correctness — tdd evidence verified (RED commit c925187, GREEN 5e0055b)
+  - [x] Correctness — actual RED command/result before implementation, then GREEN on candidate
   - [x] Tests — 4/4 passing, mutation score 94%, no business mocks
   - [x] Security — trust boundary validated via Zod at /api/checkout
   - [x] Structure — services do not touch DB (repository pattern verified)
@@ -117,9 +117,20 @@ The skill is the orchestration. Specialized agents and the native `/void-code-re
 
 - The PR's HEAD has been built and tested locally / in CI. No build errors or failing required tests. Lint findings block only for a demonstrated consequence.
 - Inspect output for leaked data and actionable errors; advisory diagnostics do not reopen review.
-- The PR description includes a clear "what" and "why."
+- Recover the accepted behavior and rationale from the task, request or PR; ask only if a missing decision changes correctness or scope.
 
-If any pre-condition fails, the review pauses — fix the pre-condition first.
+A failing required proof or invalid subject prevents acceptance. Missing prose or advisory output does not prevent the reviewer from inspecting the candidate.
+
+### Reviewer runtime
+
+Prefer an available supported runtime different from the writer for the one independent general
+review. Verify its real invocation and read-only permissions; never relabel a same-runtime session.
+A canonical mission's authenticated envelope remains authoritative: current canonical dispatch
+binds its runtime to the coordinator. This preference does not add cross-runtime routing or allow
+foreign receipts into that journal. Use the supported independent path and state the limitation;
+no repeated probe or extra general review is required merely to obtain a different brand.
+Retain the actual reviewer for targeted corrections. Runtime diversity complements independence
+and consequence-based findings; it is not proof of correctness by itself.
 
 ### Pass
 
@@ -139,6 +150,8 @@ If any pre-condition fails, the review pauses — fix the pre-condition first.
 5. Follow `void-implement`'s maximum two correction batches. Incomplete review, resumption and
    transport repair do not consume or reset that budget. Advisory findings never request a
    correction cycle. At the limit, report unresolved defects with cause and next action.
+Advisory findings never start a correction cycle; stop after acceptance, required proofs and independent review hold.
+
 6. The orchestrator may request one independent opinion on a disputed point and retain it
    as evidence for targeted verification, without reopening general review or resetting the
    budget. No separate automatic arbitration command is provided. Escalate beyond-mandate
@@ -149,7 +162,7 @@ If any pre-condition fails, the review pauses — fix the pre-condition first.
 ### Author response (Google practices)
 
 - Address every BLOCKER (fix or reasoned pushback).
-- Read every NIT. Address those you agree with; ignore the rest.
+- Read NITs as optional advice. Once acceptance and proofs hold, leave them out; they never reopen the completed work or trigger another cycle.
 - Treat QUESTION as a thinking prompt — answer or escalate.
 - Push back when you disagree. Reviewer may hold ground with a clear "why."
 
@@ -159,7 +172,7 @@ If any pre-condition fails, the review pauses — fix the pre-condition first.
 
 ### "LGTM" reviews
 
-A review that does not list the dimensions checked is not a review. Even "everything looks fine" requires the evidence block in strict mode.
+A bare verdict with no examined subject or evidence is insufficient. State the dimensions actually checked and concrete findings briefly; repeated checklist prose adds no proof.
 
 ### File-by-file linear walk
 
@@ -214,11 +227,11 @@ See `../../hooks/`.
 | Problem | Solution |
 |---|---|
 | Review feels shallow | You skipped a dimension. Walk all six in order. |
-| Cannot tell BLOCKER from NIT | Correctness / security / missing test / boundary violation = BLOCKER. Everything else = NIT. |
+| Cannot tell BLOCKER from NIT | A demonstrated defect or missing proof of a concrete risk blocks; optional improvement is advisory. |
 | Diff is too large to review | Ask the author to split, or invoke `large-cl-justification:` if truly atomic. |
 | Found a structural rot beyond the diff | `QUESTION:` + suggest follow-up issue. Do not block this PR on it. |
 | Claude and Codex disagree | Surface the delta. Let the author/user decide. |
-| Cannot reach pristine output | Pre-condition failed. Pause the review until fixed. |
+| Diagnostics remain | Resolve actionable defects; name unrelated warnings without restarting review. |
 
 ---
 

package/core-assets/skills/void-commit-discipline/SKILL.md

@@ -159,14 +159,13 @@ Commits produced in pair with an AI agent include `Co-Authored-By`. Authorship t
 
 ---
 
-## Bug fix commit pairs (composes with void-debug)
+## Bug fix evidence (composes with void-debug)
 
-A bug fix is TWO commits:
-
-1. `test: reproduce <bug summary>` — the failing test that demonstrates the bug
-2. `fix: <root cause description>` — the implementation that resolves it
-
-Combined into one commit = rejected. The pair makes the regression-prevention explicit in `git log`.
+Separate `test:` and `fix:` commits are optional. A regression test and its fix may share one
+logical, bisectable commit; unrelated changes still belong in separate commits.
+The proof is the observed RED result before the production fix, followed by GREEN on the
+candidate, as required by `void-tdd` and `void-debug`. A pair of commit messages alone cannot
+prove that chronology. Retain the actual test commands/results and explain the root cause.
 
 ---
 
@@ -182,7 +181,7 @@ Combined into one commit = rejected. The pair makes the regression-prevention ex
 ## Composition with other skills
 
 - **Runs AFTER `void-verify`** — the completion handoff produces the "what done"; this skill frames it for git.
-- **With `void-debug`** — bug fix commit pairs (`test:` then `fix:`).
+- **With `void-debug`** — observed RED/GREEN proof and root cause; phase commits are optional.
 - **With `void-refactor`** — Two-Hat principle, named Fowler refactors in subjects.
 - **With `void-brainstorm` + `void-plan`** — substantive commits link to their spec / plan in the body.
 - **With `void-code-review`** — review comments respect the commit boundaries (do not request mixing intent).
@@ -195,7 +194,7 @@ Combined into one commit = rejected. The pair makes the regression-prevention ex
 - MUST NOT permit vacuous subjects.
 - MUST NOT permit em dash / emoji / non-ASCII.
 - MUST NOT permit `feat:` / `fix:` / `refactor:` without a body why.
-- MUST NOT combine bug-fix `test:` and `fix:` commits.
+- MUST NOT substitute phase commit messages for observed RED/GREEN evidence.
 - MUST NOT silently allow invented commit types.
 
 ---

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

@@ -1,6 +1,6 @@
 ---
 name: void-debug
-description: "Four phases (investigate, analyze, hypothesize, implement). Iron Law: no fix without a failing test reproducing the bug AND a root cause. Bug fix commit pairs. Use on bug or test failure."
+description: "Four phases (investigate, analyze, hypothesize, implement). Iron Law: no fix without a failing test reproducing the bug AND a root cause. Observed RED/GREEN evidence. Use on bug or test failure."
 ---
 
 # debug — voidcorp craftsman edition
@@ -67,16 +67,15 @@ If the hypothesis does not predict a falsifiable behavior change, it is a guess.
 
 In this order:
 
-1. **Write the reproducing test** (in `strict` mode per `void-tdd`). It must fail on `main`.
-2. **Commit**: `test: reproduce <bug summary>`.
-3. **Implement the fix**. The test now passes; other tests still pass.
-4. **Commit**: `fix: <root cause description>`. Composes with `void-commit-discipline` (the "why" is the root cause).
-5. **Verify pristine output** — no warnings, no leaked logs.
-6. **Root-cause section in PR body** — see template below.
-
+1. **Write and run the reproducing test** (strict per `void-tdd`) against the unchanged base. Observe failure for the root cause, not an environment error.
+2. **Retain RED evidence**: command, relevant failure and tested source state, before implementation.
+3. **Implement the fix**, then observe the focused regression and affected tests passing.
+4. **Commit a logical, bisectable change** with its root cause; separate failing-test commits are optional.
+5. **Verify output** for actionable errors, leaks and unexplained warnings.
+6. **Explain the root cause briefly** in the PR, linking the actual RED/GREEN proof.
 ### Banned
 
-- Combining the reproducing test and the fix in one commit. Bug fix commit pairs are non-negotiable.
+- Treating a commit message or test file as proof that the regression actually failed before the fix.
 - Adding the test "later" after the fix.
 - Marking the bug closed without an explanation that survives scrutiny.
 
@@ -170,7 +169,7 @@ Retry-until-green is rejected.
 
 **3-strike rule.** Three failed hypotheses → stop treating it as a simple bug. It is likely architectural: instrument-and-wait, or escalate to a structural review (see "When the root cause is structural").
 
-**Blast-radius gate.** If the fix touches > 5 files, stop and ask: proceed / split / rethink. A wide fix for a narrow bug is usually the wrong layer.
+**Blast-radius check.** If the fix touches > 5 files, verify that every change is necessary to the root cause. Ask only when the required scope exceeds the mandate; file count alone does not require approval.
 
 **Recurring bug = architectural smell.** `git log` the affected files for prior fixes. The same file fixed three times is not coincidence — the root is structural, not the latest symptom.
 

package/core-assets/skills/void-domain-driven-design/SKILL.md

@@ -140,7 +140,7 @@ export function createEmail(raw: string): Result<Email, ValidationError> {
 }
 ```
 
-Apply to every domain primitive: `UserId`, `OrgId`, `OrderId`, `Email`, `PhoneNumber`, `IsoDate`, `Money` (`{ amount: number; currency: CurrencyCode }`, with `CurrencyCode` itself branded).
+Use a branded type when it prevents a concrete mix-up or enforces an invariant: for example distinct `UserId`/`OrgId`, validated `Email`, or monetary units. Preserve existing meaningful brands. A local primitive with no distinct invariant needs no wrapper merely to satisfy a pattern.
 
 Composes with `void-typescript-strict` (branded type mechanics) and `void-functional` (smart constructors return `Result`).
 

package/core-assets/skills/void-frontend-design/SKILL.md

@@ -259,7 +259,7 @@ See `../../hooks/`.
 | Hero feels weak | Singular primary action. Recess everything else. Cut decorative gradient if generic. |
 | Too many font sizes | Reduce to the 3-token system. Vary by weight and color. |
 | Motion feels excessive | Cut decorative animations. Keep only state-change communication. |
-| Mobile screenshot fails | Layout was desktop-first. Restart at 360–390px. |
+| Mobile screenshot fails | Diagnose and repair the affected layout at 360–390px; retain unaffected proofs and verify desktop parity. |
 | Cannot reach AA contrast | Design system token failure. Adjust palette tokens, not per-component overrides. |
 
 ---