voidmachine 0.0.0 → 4.0.0

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

@@ -0,0 +1,294 @@
+---
+name: void-typescript-strict
+description: TS strict baseline. Zero any budget, branded types for domain primitives, discriminated unions over enums, exhaustive switches via never, satisfies over as. Use when editing TypeScript code.
+---
+
+# 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.
+
+**Attribution**: see `.source` in this directory.
+
+---
+
+## tsconfig baseline (mandatory)
+
+Every consumer's `tsconfig.json` extends the void-machine strict baseline, shipped as `tsconfig.strict.json` inside the `@voidcorp/pack-monorepo` pack. The `@voidcorp/*` packs are workspace packages, not yet published to npm — the `extends` below resolves once the pack is installed in the workspace (do not assume a bare npm install resolves it):
+
+```json
+{
+  "compilerOptions": {
+    "strict": true,
+    "noUncheckedIndexedAccess": true,
+    "exactOptionalPropertyTypes": true,
+    "noImplicitOverride": true,
+    "noFallthroughCasesInSwitch": true,
+    "useUnknownInCatchVariables": true,
+    "verbatimModuleSyntax": true
+  }
+}
+```
+
+If a consumer disables any flag, they record the reason through the `void-decide` skill - that is a deliberate ADR, not a casual config tweak.
+
+---
+
+## Zero `any` budget
+
+`any` is forbidden in committed code. There is no "just this once."
+
+When you need an escape valve, use `unknown` and narrow:
+
+```typescript
+function parsePayload(raw: unknown): UserCommand {
+  return userCommandSchema.parse(raw); // Zod narrows + returns the typed value
+}
+```
+
+`unknown` forces narrowing before use. `any` silently propagates everywhere.
+
+The companion hook `no-any-grep` blocks commits that introduce `: any` or `as any` outside whitelisted paths (`**/__fixtures__/**`, `**/__tests__/**`). See `../../hooks/no-any-grep.sh`.
+
+---
+
+## `as` cast — rejected by default
+
+The `as` cast tells the compiler to trust you. Trust is the bug.
+
+Allowed forms (the only ones):
+
+- **`as const`** — pin a literal type. Always allowed.
+- **`as unknown`** as a stepping stone to a deliberate narrowing chain. Use sparingly.
+- **`as <Type>` after Zod schema validation** — preferred form: do not need `as` because `schema.parse()` returns the typed value. Use `parse`, not `as`.
+
+Banned forms:
+
+- `as <Type>` to "fix" a type error
+- `as any` to escape narrowing
+- Chained `as unknown as <Type>` to bypass exhaustive checks
+
+The companion hook `no-as-cast-grep` warns (not blocks) on `as <Type>` outside the allowed set — false positives are common, the user confirms.
+
+---
+
+## Prefer `satisfies` over annotation, prefer `parse` over `as`
+
+```typescript
+// preferred: satisfies preserves the literal type AND checks against the constraint
+const config = {
+  retries: 3,
+  backoffMs: 100,
+} satisfies RetryConfig;
+
+// acceptable: annotation widens to the constraint type
+const config: RetryConfig = { retries: 3, backoffMs: 100 };
+
+// rejected: as lies if the structure is wrong
+const config = { retries: 3 } as RetryConfig; // BAD — missing field, compiler silent
+```
+
+For validated input, use the schema:
+
+```typescript
+// preferred
+const cmd = userCommandSchema.parse(req.body);
+
+// rejected
+const cmd = req.body as UserCommand; // BAD — no runtime guarantee
+```
+
+---
+
+## Discriminated unions over enums + boolean flags
+
+State with N values = discriminated union. Not a flag bag.
+
+<Good>
+```typescript
+type FetchState<T> =
+  | { kind: 'idle' }
+  | { kind: 'loading' }
+  | { kind: 'success'; data: T }
+  | { kind: 'error'; error: Error };
+```
+</Good>
+
+<Bad>
+```typescript
+type FetchState<T> = {
+  status: 'idle' | 'loading' | 'success' | 'error';
+  data?: T;
+  error?: Error;
+}; // BAD — every consumer must check status AND handle optional fields, invariants invisible
+```
+</Bad>
+
+The discriminated form makes invalid states unrepresentable. The compiler narrows automatically inside `if (state.kind === 'success')` blocks.
+
+### No `enum` keyword
+
+TypeScript `enum` has known footguns: numeric enums are loose, declaration order matters, runtime emit unlike type aliases. Use `as const` objects + derived union type:
+
+```typescript
+const Status = {
+  Pending: 'pending',
+  Approved: 'approved',
+  Rejected: 'rejected',
+} as const;
+type Status = (typeof Status)[keyof typeof Status];
+```
+
+ESLint rule `@typescript-eslint/no-enum` (configured in `pack-monorepo`) blocks `enum` usage.
+
+---
+
+## Exhaustive switches via `never`
+
+Every `switch` over a discriminated union has a `default` branch that proves exhaustiveness:
+
+```typescript
+function render(state: FetchState<User>): JSX.Element {
+  switch (state.kind) {
+    case 'idle': return <Idle />;
+    case 'loading': return <Spinner />;
+    case 'success': return <UserCard user={state.data} />;
+    case 'error': return <ErrorView error={state.error} />;
+    default: {
+      const _exhaustive: never = state;
+      throw new Error(`Unhandled state: ${JSON.stringify(_exhaustive)}`);
+    }
+  }
+}
+```
+
+If you later add `{ kind: 'cancelled' }`, the compiler flags the switch — no production drift.
+
+ESLint rule `@typescript-eslint/switch-exhaustiveness-check` (configured in `pack-monorepo`) enforces this.
+
+---
+
+## Branded types for domain primitives
+
+Raw `string` for things with semantics is the #1 source of "passed the wrong ID" bugs. Brand it.
+
+```typescript
+// in @voidcorp/core/branded
+export type Brand<T, B extends string> = T & { readonly __brand: B };
+
+// in your domain
+type UserId = Brand<string, 'UserId'>;
+type OrgId = Brand<string, 'OrgId'>;
+type Email = Brand<string, 'Email'>;
+
+// smart constructor
+function createUserId(raw: string): UserId {
+  if (!raw.startsWith('usr_')) throw new ValidationError('invalid UserId');
+  return raw as UserId; // <-- only allowed `as`: post-validation in the constructor
+}
+```
+
+A function taking `UserId` cannot accept a raw `string`. The compiler refuses. Same shape, different identity.
+
+Apply to:
+
+- IDs (`UserId`, `OrgId`, `OrderId`, ...)
+- Email, PhoneNumber, IsoDate, IsoDuration
+- Money (`{ amount: number; currency: CurrencyCode }`, with `CurrencyCode` itself branded)
+- Anything that "looks like a string but is not interchangeable"
+
+Composes with `void-domain-driven-design` (value objects in DDD terms) and `void-functional` (smart constructors return `Result<UserId, ValidationError>`).
+
+---
+
+## Optional vs undefined — pick the right tool
+
+With `exactOptionalPropertyTypes: true`:
+
+- `{ name?: string }` means the property may be **absent**, but if present, it is a `string` (not `string | undefined`).
+- `{ name: string | undefined }` means the property is **always present**, possibly `undefined`.
+
+These are different. For domain models, prefer present-but-nullable (`name: string | null`) — explicit, no ambiguity between "missing" and "present-but-empty." For DTOs and external schemas, optional is fine.
+
+Banned: spreading `{ ...maybeObj }` where `maybeObj` has `undefined` values — `exactOptionalPropertyTypes` complains. Build the object literal explicitly.
+
+---
+
+## `Result<T, E>` for error-as-value (composes with `void-functional`)
+
+The `void-functional` skill owns the full rationale. From a types perspective:
+
+```typescript
+type Result<T, E> =
+  | { ok: true; value: T }
+  | { ok: false; error: E };
+```
+
+This is a discriminated union. The compiler narrows inside `if (result.ok)`. Errors are values, not exceptions for expected failure modes. Exceptions remain for truly unexpected bugs.
+
+A function signature `parse(raw: unknown): Result<UserCommand, ValidationError>` tells the caller everything: input is untrusted, output is either a typed command or a typed error. No try/catch hidden semantics.
+
+---
+
+## Hard rules summary
+
+- `tsconfig.json` extends `@voidcorp/pack-monorepo/tsconfig.strict.json`
+- Zero `any` in committed code. Use `unknown` and narrow.
+- No `as <Type>` outside the allowed set (`as const`, post-Zod, smart constructors)
+- No `enum` keyword. Use `as const` objects + derived union.
+- Every switch over a union has a `default: never` exhaustiveness check
+- Branded types for IDs / Email / Money / IsoDate / any semantic primitive
+- Prefer `satisfies` over annotation; prefer `schema.parse()` over `as`
+- Respect `exactOptionalPropertyTypes` semantics
+
+---
+
+## Companion hooks
+
+- **`tsc-noemit-precommit`** — `tsc --noEmit` must pass before commit. Composed with `pre-commit typecheck+test`.
+- **`no-any-grep`** — blocks `: any` and `as any` in staged diff outside fixtures/tests whitelist.
+- **`no-as-cast-grep`** — warns (not blocks) on `as <Type>` outside the allowed set.
+
+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-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`.
+
+---
+
+## Anti-rules
+
+- MUST NOT decide business logic. Types describe; behavior is elsewhere.
+- MUST NOT decide test strategy. `void-testing` and `void-tdd` own that.
+- MUST NOT decide architecture boundaries. `void-hexagonal-architecture` owns that.
+- MUST NOT decide style. Biome / Prettier owns that.
+- MUST NOT silently allow `any` "just this once."
+
+---
+
+## When you are stuck
+
+| Problem | Solution |
+|---|---|
+| Cannot express the type | Use `unknown` + narrow. If still stuck, the design is leaking. |
+| Library has wrong types | Wrap with a typed adapter at the boundary (do not patch with `as`). |
+| Generic too complex | Split. Type-level computation > 3 nesting levels is a smell. |
+| `exactOptionalPropertyTypes` complains on spread | Build the literal explicitly without `undefined` properties. |
+| Need to bypass for a fixture | Use the `**/__fixtures__/**` whitelist + explain in fixture file header. |
+
+---
+
+## Final rule
+
+```
+Every TypeScript file → no any, no rogue as, exhaustive switches, branded domain primitives.
+Otherwise            → this is not voidcorp typescript-strict.
+```
+
+The compiler is the first reviewer. If it does not flag a category of bug, this skill exists to make sure you do.

package/core-assets/skills/void-typescript-strict/harness.yaml

@@ -0,0 +1,17 @@
+# Harness metadata for this skill. Not part of the Agent Skills
+# specification, and never copied into a consumer project: the SKILL.md
+# beside it stays portable and validates against the official six fields.
+# Read by this repository's graph, and by the installer for `runtimes`.
+kind: standard
+activation: always
+triggers:
+  extensions: ["ts", "tsx"]
+owner: folpe
+runtimes: [claude, codex]
+enforcement:
+  floor: ci
+  inline:
+    claude: pretooluse
+    codex: pretooluse
+    hermes: ci-only
+eval_targets: [claude/anthropic/opus]

package/core-assets/skills/void-ui-review/.source

@@ -0,0 +1,12 @@
+Sources for `void-ui-review` skill (see `docs/plans/skill-audits/void-ui-review.md` for the full distribution matrix):
+
+- impeccable (standalone skill, ~/.claude/skills/impeccable/, v3.8.0) — VENDORED (DEV-389): the audit/critique/refine methodology (the AI-slop two-altitude category-reflex test, the register split brand-vs-product, the refine-mode menu polish/bolder/quieter/distill/harden/clarify/layout/typeset). Per Folpe's directive "tout dans le harnais", impeccable's prose value is internalised so the harness does not depend on an external skill. Rejected: its browser-driven command runtime (scripts/, reference/*.md command files, `live` mode, comparison board) — deferred to Vague 4.
+- gstack /design-review (1953 LOC) — VENDORED: the designer's-eye QA (first-impression, squint/blur test, interaction-state coverage, emotional arc). Its live-screenshot driver + atomic-fix loop are deferred to Vague 4; its 80-item audit rubric + A-F slop scoring + slop blacklist went to forge:critique / SLOP-REGISTRY (issues).
+- gstack /design-consultation (1188 LOC) — the DESIGN.md file contract is KEPT (already a harness contract, consumed by frontend-design + pack-nextjs; produced by `impeccable document`/`init` or by hand); its consultation runtime + design-vocabulary rosters went to forge:design-prompt (issues). No consultation skill needed.
+- gstack /design-shotgun (1331 LOC) — the multi-variant + anti-convergence method went to forge:design-prompt (issues); its comparison board is Vague 4.
+- Steve Krug "Don't Make Me Think" — the reading model (scan/satisfice/muddle) went to frontend-design; cited, not pasted.
+
+Strategy: distill + split. Build-time craft → frontend-design (enriched, DEV-389); audit-time methodology → this new skill (the ceiling). Mirrors security-guidance/security-audit and plan/plan-review. Browser capture is composed through `void-qa`; the comparison board and .void/SLOP-REGISTRY remain outside this skill.
+
+DEV-444 adaptation: the rubric now feeds a fresh-context Visual Craft Director with a six-dimension
+8/10 floor. Browser/current-diff evidence stays owned by qa; LLM-only certification is rejected.

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

@@ -0,0 +1,97 @@
+---
+name: void-ui-review
+description: "Audit and polish an EXISTING UI: the AI-slop test, heuristic critique, technical audit (contrast/a11y/responsive/perf), refine modes. The audit ceiling to frontend-design's build floor."
+---
+
+# ui-review — voidcorp craftsman edition
+
+`void-frontend-design` is the build-time floor: the discipline applied while writing UI. This skill is the audit-time ceiling: a deliberate pass over an *existing* interface to find what makes it read as generated, score it, and drive a refine. Invoke it to critique, audit, or polish a UI that already renders.
+
+It proposes findings and edits at the component level; it does not rewrite the brand (`DESIGN.md` owns that) and it does not re-teach the build rules (`void-frontend-design` owns those — this skill assumes them and checks against them).
+
+**Attribution**: see `.source`. Vendored from `impeccable` (the audit/critique/refine methodology) + gstack `/design-review` (designer's-eye QA) + gstack `/design-consultation`/`/design-shotgun` (the pieces that stayed here; recon/design-prompt went to `forge`). Live browser operation is delegated to `void-qa`.
+
+---
+
+## Classify the register first
+
+Judgment differs by register — apply the matching bar:
+
+- **Brand** — marketing, landing, campaign, portfolio: *design IS the product*. Boldness, distinctiveness, and a memorable moment are the bar.
+- **Product** — app UI, admin, dashboard, tool: *design SERVES the product*. Clarity, density, and low cognitive load are the bar.
+
+Pick by task cue first ("landing page" vs "dashboard"), then the surface in focus, then the `register` field in `PRODUCT.md`/`DESIGN.md`.
+
+## The AI-slop test (the core pass)
+
+If someone could look at this and say "AI made that" without doubt, it has failed. Run the **category-reflex check at two altitudes** — the second catches what the first misses:
+
+- **First-order** — could someone guess the theme + palette from the *category alone*? (SaaS → blue/violet; fintech → navy/gold; AI tool → cream/sand.) If yes, it is the first training-data reflex. Rework the color strategy and the physical-scene sentence until the answer is not obvious from the domain.
+- **Second-order** — could someone guess the aesthetic family from *category-plus-anti-reference*? ("AI tool that's not SaaS-cream → editorial-typographic"; "fintech that's not navy → terminal dark".) The first reflex was dodged; the second wasn't. Rework until neither answer is obvious.
+
+Cross-register slop (the absolute bans — side-stripe, gradient text, glassmorphism, hero-metric, eyebrow-on-every-section, cream/sand body, text overflow) is owned by `void-frontend-design`; flag any that survived into the shipped UI as findings here.
+
+## Critique pass (designer's eye, heuristic)
+
+- **First impression** — look for 3 seconds, then look away. What did you retain? Run the **squint test**: blur the screen — does the hierarchy still read, does the primary action still dominate? If everything is equally loud, there is no hierarchy.
+- **Information architecture** — is the primary action singular and the most prominent? Is supporting context recessed, and noise cut?
+- **Interaction-state coverage** — every state the user hits, described as what they *see*: loading, empty, error, success, partial. A missing state is a finding, not a detail.
+- **Emotional arc** — the 5-second / 5-minute / 5-year read: does the first glance earn the second, and does it hold up on the hundredth visit?
+- Score each dimension `N/10 → target`, write the fix, and re-rate. "Design-complete" when every dimension clears the bar for its register.
+
+## Technical audit pass
+
+- **Contrast** — body ≥ 4.5:1, large text ≥ 3:1, placeholders held to 4.5:1 (not the muted-gray default). The commonest failure: muted gray on tinted near-white.
+- **Accessibility** — keyboard path, focus order, ARIA, 44px targets (composes with `void-accessibility`).
+- **Responsive** — per-viewport intent; test heading copy at every breakpoint for overflow; mobile-first dual-quality (composes with `void-frontend-design`).
+- **Performance** — LCP budget, no layout-thrash animation, image sizing (composes with the perf tooling).
+
+## Independent post-build verdict
+
+For a changed UI, `void-qa` supplies current-diff screenshots and behavioral proof, then
+`core:visual-craft-director` reviews them in a fresh context distinct from the builder and pre-build
+designer. It scores hierarchy, information architecture, interaction states, responsive intent,
+distinctiveness, and accessibility; every dimension must reach 8/10. Missing browser access,
+mobile/desktop or applicable-state captures, current-diff binding, or test proof blocks approval.
+Model judgment alone is never visual certification.
+
+## Refine modes
+
+Once findings exist, drive a focused refine rather than a vague "make it better":
+
+- `polish` — final pre-ship quality pass · `harden` — errors, i18n, edge/empty states · `distill` — strip to essence.
+- `bolder` — amplify a bland/safe design (brand register) · `quieter` — tone down an overstimulating one · `colorize` — strategic color into a flat UI.
+- `clarify` — UX copy, labels, error messages · `layout` — spacing, rhythm, hierarchy · `typeset` — type hierarchy and fonts.
+
+Each is a scoped edit driven by the critique/audit findings, not a rewrite.
+
+## Live browser audit — via `void-qa`
+
+The live layer — screenshotting the running UI, driving interactions, checking states in a real browser — is not in this prose skill; the browser home for it is `void-qa` (the claude-in-chrome MCP re-point, DEV-390). When a check needs a running browser, compose `void-qa` (its visual pass invokes this skill's methodology against the live screenshots) rather than reviewing from code alone. The multi-variant comparison board remains out of scope (forge).
+
+## Composition & boundaries
+
+- **With `void-frontend-design`** — the build-time floor to this audit ceiling; the bans and build specifics live there, this skill checks against them and does not restate them (no > 30% overlap).
+- **With `core:visual-craft-director`** — this skill supplies the rubric; the specialist supplies the independent post-build verdict over evidence captured by `void-qa`.
+- **With `void-accessibility`** — the a11y audit dimension composes with it.
+- **Not `void-plan-review`'s Design lens** — that judges a *written plan* before any code exists (does the plan name the states, the responsive intent?); this judges the *shipped UI*. Different artifact, different lifecycle stage.
+- **Not `void-devex-audit`** — that audits a shipped dev-facing surface (the API/CLI/SDK/docs journey: naming, errors, TTHW); this audits the visual/interaction UI. Sibling audit skills, different subject.
+- **With `forge`** (voidcorp plugin) — market recon, the 12-dimension scored critique, multi-variant design prompts, and the slop-registry live there; bridged by the `docs/specs/` `source: forge` artifact contract.
+- **Supersedes** the external `impeccable` skill's prose methodology (now harness-native) and gstack `/design-review`/`/design-consultation`/`/design-shotgun`.
+
+## Anti-rules
+
+- MUST NOT decide brand identity — `DESIGN.md` owns palette/type/motion.
+- MUST NOT restate `void-frontend-design`'s build rules — assume and check against them.
+- MUST NOT drive a browser or make live requests — compose `void-qa` and review its current-diff evidence.
+- MUST NOT rewrite a UI wholesale under a refine mode — a refine is a scoped, finding-driven edit.
+- MUST NOT vendor the gstack/impeccable runtime (scripts, reference command files, comparison board).
+
+## Final rule
+
+```
+Existing UI → classify register → AI-slop test → critique (squint + states) → technical audit → scoped refine.
+Otherwise → it is not voidcorp ui-review.
+```
+
+Anyone can generate a UI. This skill is what makes ours stop looking generated after it already shipped.

package/core-assets/skills/void-ui-review/harness.yaml

@@ -0,0 +1,15 @@
+# Harness metadata for this skill. Not part of the Agent Skills
+# specification, and never copied into a consumer project: the SKILL.md
+# beside it stays portable and validates against the official six fields.
+# Read by this repository's graph, and by the installer for `runtimes`.
+kind: action
+activation: on-demand
+owner: folpe
+runtimes: [claude, codex]
+enforcement:
+  floor: ci
+  inline:
+    claude: active
+    codex: active
+    hermes: ci-only
+eval_targets: [claude/anthropic/opus]

package/core-assets/skills/void-verify/.source

@@ -0,0 +1,12 @@
+Sources for `void-verify` skill (see `docs/plans/skill-audits/void-verify.md` for full audit):
+
+- superpowers/verify — primary (checklist + observation discipline).
+- citypaul/.dotfiles completion checklists — TS-strict checklist items.
+- Atul Gawande "The Checklist Manifesto" — principle that checklists prevent omissions even for experts.
+- NASA Power of Ten (informal "if it cannot fail, document why").
+
+- gstack /ship — VENDORED (DEV-388): the Plan-Completion Audit (item-by-item DONE/PARTIAL/NOT-DONE/CHANGED/UNVERIFIABLE, the honesty rule "handling a deliverable is not the deliverable", per-item confirmation for UNVERIFIABLE, scope-drift) + the named-excuse rationalization list. The 12-item checklist verifies the build; this verifies you built what was specified.
+
+Strategy: distill. Slim skill. Adapted for void-machine's specific signal set (12 items, each mapped to a skill or hook).
+
+No new hooks (composes with all existing).

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

@@ -0,0 +1,184 @@
+---
+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.
+---
+
+# 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.
+
+**Attribution**: see `.source`. Primary source: superpowers/verify + citypaul completion checklists.
+
+---
+
+## 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.
+
+---
+
+## 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.
+
+## Bounded review evidence
+
+Use the review receipt from `void-implement`: exact commit and base, acceptance criteria,
+independent reviewer, conclusions, proofs and blocking-defect resolutions. A mutable worktree
+alone is insufficient. Reuse unaffected evidence after correction and verify the affected
+behavior only; do not trigger another general panel. Native runtime identity absence or refusal
+is an explicit provenance limitation, not an extra certification gate. Actual independence and
+valid evidence remain required. An unresolved blocking defect prevents completion.

package/core-assets/skills/void-verify/harness.yaml

@@ -0,0 +1,15 @@
+# Harness metadata for this skill. Not part of the Agent Skills
+# specification, and never copied into a consumer project: the SKILL.md
+# beside it stays portable and validates against the official six fields.
+# Read by this repository's graph, and by the installer for `runtimes`.
+kind: action
+activation: always
+owner: folpe
+runtimes: [claude, codex]
+enforcement:
+  floor: ci
+  inline:
+    claude: active
+    codex: active
+    hermes: ci-only
+eval_targets: [claude/anthropic/opus]

package/core-assets/specialists/accessibility-specialist.source

@@ -0,0 +1,11 @@
+Sources:
+- WCAG 2.2: https://www.w3.org/TR/WCAG22/
+- WAI-ARIA Authoring Practices Guide: https://www.w3.org/WAI/ARIA/apg/
+- void-machine accessibility doctrine: packages/core/skills/accessibility/SKILL.md
+
+Adapted:
+- Kept WCAG 2.2 AA as the floor plus semantic, keyboard, focus, name, contrast, target, error, motion, and assistive evidence.
+- Requires human-observable interaction evidence where static analysis cannot prove behavior.
+
+Rejected:
+- Static-tool-only certification, visual-taste review, product-flow ownership, and implementation authority.