voidmachine 0.0.0 → 4.0.0

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

@@ -0,0 +1,301 @@
+---
+name: void-testing
+description: How to write a good test. Behavior over implementation, real code over mocks, factories over beforeEach, pyramid respected, pristine output, no snapshot creep. Use when writing or modifying tests.
+---
+
+# testing — voidcorp craftsman edition
+
+`void-tdd` provides the cycle (when to write the test). This skill provides the technique (how to write a good one). Mocking is the last resort. Behavior, not implementation. Factories, not `beforeEach`. Pristine output is a passing condition.
+
+**Attribution**: see `.source` in this directory.
+
+---
+
+## Core principles
+
+### 1. Test the behavior, not the implementation
+
+Assertions describe what the user / consumer of the code observes. They do not describe which private method ran, which collaborator was invoked, which exact internal sequence happened.
+
+<Good>
+```typescript
+test('retries failed operations 3 times before giving up', async () => {
+  let attempts = 0;
+  const op = () => {
+    attempts++;
+    if (attempts < 3) throw new Error('transient');
+    return 'success';
+  };
+  expect(await retryOperation(op)).toBe('success');
+  expect(attempts).toBe(3); // observable: how many times the operation ran
+});
+```
+</Good>
+
+<Bad>
+```typescript
+test('retry', () => {
+  const spy = vi.fn().mockRejectedValueOnce(...).mockResolvedValueOnce(...);
+  retryOperation(spy);
+  expect(spy).toHaveBeenCalledTimes(3); // tests the spy, not the behavior
+  expect(retryOperation['_internalDelay']).toBeDefined(); // tests internals
+});
+```
+</Bad>
+
+For UI: query by accessible role / label, not by class or `data-testid`. `data-testid` is the escape hatch when no semantic query works, not the default.
+
+For interactive UI, pair the accessible query with the user input that proves the contract:
+`userEvent.keyboard` for keyboard paths, pointer input only for pointer behavior, and visible output
+for state transitions. Test loading, empty, error, success, and partial states only when applicable,
+but make that applicability explicit. Component, hook, and store tests stay at their observable
+boundaries; a broad E2E test does not substitute for the focused regression that identifies which
+contract broke.
+
+### 2. Sociable tests over solitary tests
+
+Let collaborators run inside the test by default. Only mock at infrastructure boundaries:
+
+- HTTP → MSW (Mock Service Worker)
+- DB → pglite (in-memory Postgres) or Neon dev branch
+- Filesystem → `memfs` or a temp directory
+- Time → `vi.useFakeTimers()`
+- Randomness → seeded RNG
+
+Mocking a collaborator that does pure computation is a code smell. If you find yourself mocking `formatCurrency()` to test `renderInvoice()`, the design is too coupled — or your test should run `formatCurrency` for real.
+
+### 3. Nullable infrastructure pattern (Shore)
+
+For the infrastructure that DOES need a test double, the wrapper exposes a `createNull()` variant that returns deterministic / empty results. No mocking library invocation; the constructor handles it.
+
+```typescript
+class StripeClient {
+  static create(apiKey: string): StripeClient { /* real */ }
+  static createNull(opts?: { charges?: ChargeFixture[] }): StripeClient { /* in-memory */ }
+}
+
+// in tests:
+const stripe = StripeClient.createNull({ charges: [makeCharge({ amount_cents: 1000 })] });
+```
+
+The nullable variant is production-typed. Tests do not reach into a mocking framework. The boundary is owned by the domain.
+
+### 4. Pristine output
+
+After a test passes, the output is clean:
+
+- No `console.log` from production code
+- No warnings (React act warnings, deprecation warnings, etc.)
+- No leaked unhandled rejections
+- No leaked timers / open handles
+
+Pristine output is a passing condition, not a nice-to-have. Vitest config: `onConsoleLog: 'fail'`.
+
+### 5. Release E2E proves the shipped artifact
+
+Release proof exercises the immutable deployable artifact, not a development compiler. Keep build
+readiness (the process started and became healthy) separate from application assertions, so a slow
+compile cannot consume the assertion budget or hide a failed startup.
+
+Fixtures use the lowest faithful boundary that preserves the behavior under test. Establishing an
+authenticated precondition may use a server/API boundary; the authentication UI remains an E2E
+subject when authentication itself is the behavior being proved.
+
+External state is namespaced per run/worker and cleanup is idempotent and bounded, including after
+interruption. Browser storage state is sensitive ephemeral output and belongs under the test output
+directory, never in source control.
+
+Test-only security overrides are typed, bounded, and paired with independent proof of production
+defaults and denial behavior. A malformed or out-of-range override falls back to safe production
+defaults. No retry-on-failure, quarantine, skip, or assertion-timeout inflation is a flake fix.
+
+---
+
+## Naming
+
+Describe the behavior. Imperative. Specific.
+
+<Good>
+- `retries failed operations 3 times before giving up`
+- `rejects payment when card balance is below total`
+- `emits user-created event after first successful login`
+</Good>
+
+<Bad>
+- `test retry` (vacuous)
+- `should work` (says nothing)
+- `retryOperation` (function name, not behavior)
+- `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).
+
+---
+
+## Fixtures and factories
+
+### Factories over `beforeEach`
+
+`beforeEach` for environment setup (mount DOM, reset DB, install fake timers). NOT for test data.
+
+<Good>
+```typescript
+function makeUser(overrides: Partial<User> = {}): User {
+  return {
+    id: createUserId('usr_test_001'),
+    email: 'user@example.com',
+    createdAt: new Date('2026-01-01'),
+    ...overrides,
+  };
+}
+
+test('rejects suspended users', () => {
+  const user = makeUser({ suspended: true });
+  expect(authorize(user)).toEqual({ ok: false, error: 'suspended' });
+});
+```
+</Good>
+
+<Bad>
+```typescript
+let user: User;
+beforeEach(() => {
+  user = { id: '...', email: '...', /* shared mutable state */ };
+});
+test('rejects suspended users', () => {
+  user.suspended = true; // mutates shared state, leaks between tests
+  expect(authorize(user)).toEqual({ ok: false, error: 'suspended' });
+});
+```
+</Bad>
+
+### Externalize > 5-line fixtures
+
+Inline fixtures are fine when small (< 5 lines). Larger fixtures go to `tests/fixtures/<name>.ts`. Each fixture exposes a factory function with overrides.
+
+Heavy data (multi-KB JSON, sample images): load from disk, never inline.
+
+---
+
+## Test pyramid
+
+Heuristic ratios for a TS/web project:
+
+- **~70% unit tests**: pure functions, business logic, schema validation. Run in < 100ms each.
+- **~20% integration tests**: real infrastructure via pglite / MSW / temp filesystem. Run in < 1s each typically.
+- **~10% E2E tests**: Playwright on critical user paths. Run in seconds.
+
+Numbers are a heuristic, not a quota. A solopreneur with strong types may run closer to 50/40/10 because integration tests buy more confidence per unit of effort. Adjust by data, not by tradition.
+
+**Inverted pyramid is a smell**: if your E2E suite carries the proof and your unit suite is sparse, your design is probably testing badly (too coupled to make unit tests cheap). Fix the design.
+
+---
+
+## Mocking strategy
+
+### When to use what
+
+| Test target | Boundary technique |
+|---|---|
+| Pure business logic | No mock. Real code. |
+| HTTP client → external API | MSW handlers in `tests/msw/handlers.ts` (or pglite for inbound HTTP if testing a Next.js route handler) |
+| ORM → Postgres | pglite (in-memory) for unit-of-work. Neon dev branch for E2E-like integration |
+| Date / Time | `vi.useFakeTimers()`, advance explicitly |
+| `Math.random` / UUID | seeded RNG passed via parameter (composes with `void-hexagonal-architecture` port pattern) |
+| File system | `memfs` or temp directory |
+| Server Actions | invoke directly; the sandbox is light |
+
+### What NOT to mock
+
+- A pure function (run it)
+- A business service (compose, do not mock)
+- The framework router (use the framework's testing utilities)
+- The ORM at the unit level (use pglite — see `void-tdd` anti-pattern)
+
+The companion hook `no-business-mock` warns on `vi.mock('@/services/...')` patterns.
+
+---
+
+## Banned practices
+
+### Snapshot testing — banned by default
+
+Snapshots devolve into "update on green" — the test passes regardless of correctness. Allowed only for:
+
+- **UI visual regression**: in `**/__visual__/**` directory with documented review process
+- **Compiler output sanity** (`__generated__/` snapshots): same constraint
+
+Each snapshot has a reason. No `.toMatchSnapshot()` outside the whitelist without explicit code-review approval.
+
+### `.only` / `.skip` / `fdescribe` / `xit`
+
+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).
+
+### Implementation spies as primary assertion
+
+`expect(spy).toHaveBeenCalledWith(...)` is for "did the side effect at this boundary happen" — only at infrastructure boundaries. It is not the assertion for business behavior.
+
+### `describe.each` for unrelated scenarios
+
+`describe.each([...])` is for genuinely parametric tests (boundary values, equivalence classes). It is NOT for grouping 5 different scenarios that share scaffolding — that hides the differences.
+
+### Inline DB mocks for business-layer tests
+
+Use pglite or dev branch. Mocking Drizzle breaks at every schema change while protecting nothing real.
+
+---
+
+## Composition with other skills
+
+- **With `void-tdd`**: `void-tdd` is the cycle (when), `void-testing` is the technique (how). RED step delegates the *how* here.
+- **With the mutation gate** (strict TDD, when the project declares a mutation runner): a high survivor rate is a `void-testing` signal — the tests are not asserting on the right things. KILL step iterates back here.
+- **With `void-typescript-strict`**: tests use branded types from production. A test needing `as any` is signaling a missing factory or brittle type.
+- **With `void-hexagonal-architecture`**: ports tested with nullable infrastructure. In-memory adapters owned by the domain.
+- **With `void-migrations`**: DB migrations have their own discipline; this skill's pyramid does not apply to migration tests.
+
+---
+
+## 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-business-mock`** — warn on `vi.mock\('@/(services|domain)/...'\)` patterns
+- **`no-snapshot-default`** — warn on new `.toMatchSnapshot()` outside `**/__visual__/**` whitelist
+
+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 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.
+
+---
+
+## When you are stuck
+
+| Problem | Solution |
+|---|---|
+| Test feels brittle, breaks on refactor | Coupled to implementation. Test the behavior at the boundary instead. |
+| Need to mock 5 things to test 1 thing | Coupling smell. Inject dependencies via parameters. Compose with `void-hexagonal-architecture`. |
+| Fixture is huge | Externalize to `tests/fixtures/`. Use a factory with overrides. |
+| Test name is weak | Describe the behavior, not the function. Imperative. |
+| Snapshot wants to update on every change | Snapshot is wrong. Replace with explicit assertions. |
+| Pyramid feels wrong | Adjust by data after 50+ tests. The 70/20/10 is a heuristic. |
+
+---
+
+## Final rule
+
+```
+A test → asserts behavior, uses real code where possible, runs deterministically, produces pristine output.
+Otherwise → it is not a voidcorp testing test.
+```
+
+Tests prove behavior. They are a specification, not a record.

package/core-assets/skills/void-testing/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:
+  globs: ["**/*.test.ts", "**/*.spec.ts"]
+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-ticket/.source

@@ -0,0 +1,18 @@
+Sources for `void-ticket` skill (see `docs/plans/skill-audits/void-ticket.md` for full audit):
+
+- loomcrafthq/ticket-craft — reference for the platform-agnostic tracker template
+  (Context / Scope / Technical Specs / AC / DoD / Edge Cases) and T-shirt sizing.
+  KEEP EXTERNAL as a generic fallback; this skill is the doctrine-aware,
+  harness-composing version. Distilled, not vendored.
+- Composes upstream: brainstorm, plan (the thinking
+  this skill captures). Downstream: implement (consumes the ticket and
+  its declared passes).
+
+Strategy: author + distill. Three deliberate additions over ticket-craft:
+1. INGEST-first: the ticket records decisions already made (spec, plan, ADR,
+   conversation), it never invents scope.
+2. Estimate + labels + parent are REQUIRED native fields, not optional metadata.
+   This is the observed baseline failure (tickets shipped without them).
+3. Two new slots tie it to the harness: a TDD-mode-per-ticket and a
+   "runner passes that apply" declaration, so implement does not
+   re-derive the conditional passes. Plus an all-angles sweep before saving.

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

@@ -0,0 +1,239 @@
+---
+name: void-ticket
+description: Use when turning a finished brainstorm, plan, or design decision into a tracker ticket. Triggers on creating a ticket or issue, logging work, or breaking an approved spec into tickets.
+---
+
+# ticket
+
+A ticket an implementation agent can execute with zero follow-up questions. It does NOT invent scope: it ingests what was already decided (the brainstorm, the plan, this conversation, the relevant ADR) and renders it as a complete, estimated, labeled work item in the tracker. Downstream, `void-implement` executes it.
+
+**Core principle:** the ticket is the contract between the thinking and the building. Every required slot is filled or the ticket is not ready. Estimate and labels are not optional metadata, they are how the backlog stays pilotable.
+
+**Attribution**: see `.source`.
+
+---
+
+## When to invoke
+
+- After `void-brainstorm` or `void-plan` produced a decision or spec, to capture it as trackable work.
+- When the user says create a ticket, log this, or break this into tickets.
+- 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`).
+
+---
+
+## Ingest first, do not invent
+
+Pull from what already exists, in order: the approved spec/plan, the brainstorm decisions, this conversation's decisions, the applicable ADR(s), the code conventions. The ticket RECORDS decisions already made. If a load-bearing decision is missing, go get it or flag it. Do not guess scope into existence.
+
+A `docs/specs/*.md` spec with `source: forge` in its frontmatter (the forge→harness artifact contract) is a first-class source: its 18 recon variables, winning design, and critique verdict already answer scope, persona, and constraints — ingest them, do not re-ask. A partial forge spec (missing critique, or an older `forge_version` field) is ingested for what it has, with the gaps listed as the ticket's open questions.
+
+---
+
+## Admission: a finding earns its place or it is dropped
+
+Most of what reaches this skill is not a decision someone made, it is a defect someone
+*noticed*. Those arrive without end, because reading code always finds another inconsistency,
+and each one is defensible on its own. A backlog that admits them all stops being pilotable, and
+the objective recedes while every individual step looks correct.
+
+So a noticed defect is not admitted on its merits. It is compared against **the unit being built
+right now**, judged against the program's stated objective, and there are three outcomes and one
+slot:
+
+1. **It blocks the current unit** — it is fixed inside that unit. No ticket.
+2. **It beats the current unit** — it becomes the next unit, and nothing else starts until it is
+   disposed of.
+3. **It loses** — it is dropped. Not filed, not deferred, not "kept for later".
+
+Dropped means lost, and that is the point. A genuine defect is rediscoverable by construction:
+a skill that lies will lie to the next reader, and a run will trip on it again. The only thing
+ever written down is **evidence that cannot be reconstructed** — a failure observed once, a
+measurement — as one line carrying the command that replays it. Never the opinion, never the
+proposed fix, because describing the fix is how a finding smuggles in a design.
+
+Two things are not admissible at all:
+
+- **A reading nobody asked for.** What you noticed in a file you were not convened on does not
+  become work. If it matters, it will be found again by someone who was asked.
+- **An ambition claim.** "This would be tenfold better" belongs to `void-brainstorm`, on a named
+  subject, deliberately. During execution it is an escape hatch, and it is the one that grows
+  plans.
+
+State the comparison out loud when you drop something: what you found, and what it lost to. One
+line. An arbitration nobody can see did not happen.
+
+**Prose incoherence is a first-class defect**, in four forms: inside one skill, between two
+skills, between the user's stated demand and a skill, and between a skill and the code it
+describes. The last is this repository's repeat offender. It still goes through the comparison
+above like anything else.
+
+See the decision on a finding entering only by beating the work in progress.
+
+---
+
+## Search the tracker before you write
+
+The backlog already answered part of this. Query it on the **subject**, never on
+the title you are about to write: DEV-591 was called "unstable test suite" and
+DEV-561 "test contention" — no shared word, same question, three days apart.
+Search several phrasings of the thing itself, and include **closed** tickets: one
+closed because the approach was wrong is exactly the one not to reopen unchanged.
+
+An overlap means reading that ticket **in full** before deciding, not its title.
+What costs a day is not the duplicate, it is the reasoning that was in the first
+one: DEV-561 had established that an intermittent test is a question nobody has
+answered rather than noise to isolate, and DEV-591 recommended what it forbade.
+
+Then exactly one of two things, and creating in silence is neither:
+
+- **enrich the existing ticket**, when the subject is the same;
+- **create, linked, naming the difference** in one sentence, when the scope is
+  deliberately disjoint.
+
+Never merge two tickets on your own: a resemblance is not an identity, and that
+call is the human's. Say what you searched and what came back — a search nobody
+can see did not happen. If the tracker is unreachable, say so and keep writing;
+a handoff blocked on a lookup is worse than a duplicate.
+
+Thirty results means the terms were too broad, not the backlog too large.
+
+---
+
+## The ticket: required slots
+
+Render into the tracker description. Every slot is REQUIRED unless marked optional. A missing required slot means the ticket is not ready.
+
+- **Title**: `[Verb] [Subject]`, imperative.
+- **Context**: why it exists; link to the broader goal / spec / ADR.
+- **Scope**: in scope / out of scope.
+- **Technical specs**: files and packages touched, applicable ADR, conventions and patterns to follow, third-party docs to ground in. Exhaustive enough that no unknown remains.
+- **Acceptance criteria**: objectively verifiable checkboxes.
+- **Definition of Done**: tests written and green, 0 lint / type errors, 0 regressions, plus ticket-specific items.
+- **Edge cases and gotchas**: boundary behaviors, error / empty / loading states, failure modes. This is the all-angles slot; an empty one means angles were missed.
+- **TDD mode**: defer to `void-tdd`'s path-based auto-selection; note an explicit override to strict only for a business-critical surface (auth, payments, security, money).
+- **Runner passes that apply**: which `void-implement` conditional passes you expect to fire (architecture? migration safety? async/idempotency? E2E? UX/UI? deep security?). This is an accelerator HINT, not authoritative: the runner still evaluates every predicate itself and may add passes you did not list.
+
+### Close the link, both ways
+
+A ticket that cites its spec is half a link. Do both, in the same change:
+
+1. The ticket body opens with the paths of the spec and the plan it comes from.
+2. The `ticket:` field in each of those two files' frontmatter is filled with the
+   tracker id just created.
+
+Neither direction is optional, because each answers a question the other cannot.
+From the ticket, the reasoning: why this shape, what was rejected, which
+trade-off was taken. From the spec, whether the thinking was ever executed and
+where it landed. A spec with no ticket is a decision nobody carried out, and
+nothing says so today.
+
+The asymmetry is deliberate and worth keeping in mind: the spec and the plan
+live in the repository because they belong to the project and must survive the
+tracker, while the ticket is execution state and is mutable by nature. Copying
+the reasoning into the tracker would put it where a workspace change can lose
+it; copying the status into the repository would give it two owners. Only the
+link crosses.
+
+If the project has no tracker, say so and stop: there is no ticket to write, and
+the spec plus the plan already hold what would have gone in it.
+
+Native tracker fields (REQUIRED, set the real field, not prose):
+
+- **Estimate** (points / size). Never leave empty.
+- **Labels** (at least one; reuse existing, create if genuinely new).
+- **Parent epic / project** link.
+- **Dependencies** (`blockedBy`) in the native field, not just text.
+- **Priority**.
+
+---
+
+## Multi-ticket programme handoff
+
+After creating a complete pool of two or more tickets intended to run across sessions, create
+`.void/program.md` in the same change. Do this only after the plan and ticket pool are
+human-approved and every native dependency is saved. A single standalone ticket does not need a
+programme descriptor.
+
+Use tracker-agnostic routing frontmatter:
+
+```yaml
+---
+schemaVersion: 1
+status: executing
+program: <stable-program-slug>
+plan: <repository-relative-plan-path>
+spec: <repository-relative-spec-path>
+progress:
+  provider: <adapter capability id>
+  scope: <native workspace/project/repository query>
+  order: [<ordered immutable work-unit identifiers>]
+  states:
+    ready: [<native ready states>]
+    started: [<native started states>]
+    review: [<native review states>]
+    done: [<native completed states>]
+humanGates: [<ticket identifiers requiring explicit approval>]
+autopilot:
+  schemaVersion: 1
+  enabled: <true | false>
+  mergeGate: human
+---
+```
+
+The body states that the plan supplies global intent, the complete provider-native record is the
+executable unit, native blocker relations decide readiness, and `void-implement` owns the per-unit
+lifecycle. `progress.order` is the deterministic tie-break among simultaneously ready units; it is
+scope, not mutable progress. Never store a current or next unit, copied status, assignee, or
+completion checklist in the program or checkpoint.
+
+The `void-autopilot` block is required, because consent to autonomous execution is never inferred from silence: a program that does not want it declares `enabled: false`. `mergeGate` takes `human`, or `union-reviewed` with a `deployBranch` naming the branch that ships — that pair IS the consent to a machine merge, and there is no flag for it. Add `clusterSize` (1..4), `base`, `verifyCommands` (argv arrays, run with `shell:false`) and `ownership.sequential` / `ownership.reconcileOnly` only when the program enables autopilot.
+
+Do not replace an unrelated executing programme. Stop and surface the collision. When the same
+programme already has a descriptor, preserve its routing unless the user explicitly changes
+programme scope. Automatic selection requires a provider adapter that can read and update status,
+relations, assignee, comments, and review evidence; if those capabilities are unavailable, do not
+claim automatic continuity.
+
+---
+
+## All-angles sweep before saving
+
+Run a quick expert sweep so nothing is missed, then fold what surfaces into Edge cases or the applicable-passes slot:
+
+- **Architecture**: boundaries, data model, public types.
+- **Data / migrations**: schema change, backfill, zero-downtime (flags the runner's migration-safety pass).
+- **Security**: trust boundary, untrusted input, tenancy.
+- **Async / idempotency**: email, webhook, job, single-use token, replay (flags the runner's async pass).
+- **QA**: edge / error / empty states, the end-to-end path.
+- **UX**: if a UI surface is involved.
+- **Perf / observability / docs**: cost, logging, doc updates owed in the same change.
+
+This is the cheap insurance an expert team would not skip. It is what makes a ticket cover the angles the author would not have thought of alone.
+
+---
+
+## Sizing
+
+Map T-shirt to the tracker's native scale: XS (<1h, trivial), S (1-3h), M (3-8h, minor unknowns), L (1-2d, real complexity), XL (>2d, split unless truly indivisible).
+
+---
+
+## Red flags: STOP, the ticket is not ready
+
+| Rationalization | Reality |
+|-----------------|---------|
+| "I will add the estimate later" | Estimate is a required field. An unestimated backlog cannot be planned. |
+| "Labels do not matter for now" | At least one label, always. Filtering and routing depend on it. |
+| "The agent will figure out the edges" | The edge-cases slot is where all-angles coverage lives. Empty = angles missed. |
+| "Scope is obvious from the title" | The implementation agent has none of this conversation. Spell it out. |
+| "No parent, it is standalone" | Orphan tickets rot. Link the epic or project. |
+
+A ticket missing a required slot or field is not done, however clear it feels.
+
+---
+
+## Composition
+
+Upstream: `void-brainstorm` and `void-plan` produced the thinking (or a `source: forge` spec did — see "Ingest first"); this skill captures it. Downstream: `void-implement` consumes the ticket and the passes it declares. On a project, follow that project's tracker doctrine (team, project, label and estimate conventions) rather than re-deciding them here; this skill stays the harness-doctrine layer (ingest, required slots, runner handoff).

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

@@ -0,0 +1,14 @@
+# 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
+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-typescript-strict/.source

@@ -0,0 +1,10 @@
+Sources for `void-typescript-strict` skill (see `docs/plans/skill-audits/void-typescript-strict.md` for full audit):
+
+- citypaul/.dotfiles tsconfig stance — strict + noUncheckedIndexedAccess + exactOptionalPropertyTypes baseline
+- Anders Hejlsberg + TypeScript handbook — https://www.typescriptlang.org/docs/handbook/ — type system semantics
+- Matt Pocock "Total TypeScript" — https://www.totaltypescript.com — branded types, satisfies operator, generic helpers
+- tkdodo (Dominik Dorfmeister) "TypeScript Tag of Doom" + narrowing series — https://tkdodo.eu/blog/type-script-tag-of-doom — discriminated unions, as const, no-as discipline
+- type-fest — https://github.com/sindresorhus/type-fest — utility library referenced, NOT vendored as default dep
+- Zod — https://zod.dev — boundary validation library composed with this skill
+
+Strategy: distill. Author from first principles; rules are common knowledge, discipline is in enforcement (hooks: tsc-noemit-precommit, no-any-grep, no-as-cast-grep).