vouchington-tooling 0.20.0 → 0.22.0

package/skills/stacked-prs/SKILL.md

@@ -5,64 +5,33 @@ description: Recognize a native GitHub stacked pull request and drain it from th
 
 # Stacked pull requests
 
-Use whenever a change is submitted as a chain of native GitHub stacked pull requests instead of a
-single PR. Read local `AGENTS.md` and `CLAUDE.md` first: they own whether this repository adopts
-stacking at all, the tooling used to create, rebase, and merge a stack, and who may authorize a
-merge.
-
-A stack is a sequence of branches, each submitted as its own pull request, where every PR but the
-bottom-most one targets the PR below it as its base branch instead of targeting the default branch
-directly. GitHub tracks a chain like this as a single stack, and its own documentation on merging
-stacked pull requests is explicit about what a merge then does: "the selected pull request and all
-unmerged pull requests below it land on the base branch together as a single operation, ordered
-from the bottom up," and merging one is only possible once everything below it already satisfies
-whatever this repository requires to merge — you cannot merge an isolated middle layer on its own.
-That is dedicated stack-merge behavior, not the ordinary single-branch merge semantics a generic
-"merge this PR" action assumes, and it comes with its own restrictions: GitHub does not support
-auto-merge for stacked pull requests at all, and a plain, non-stack-aware merge mechanism is not
-guaranteed to reproduce this cascade correctly. A mid-stack PR's base ref being an unmerged branch,
-not the default branch, is the sign to slow down and confirm the merge path in use actually
-understands stacks before treating it as routine.
-
-Treat the forge's own view of a stack — its layers, their order, and each one's base — as the only
-reliable source for that structure, and re-read it immediately before acting rather than trusting a
-stacking tool's local record. Local metadata about a stack can go stale after a rebase, an
-out-of-band relink, or a manual recovery in ways nothing in the working tree reveals, so re-derive
-the current topology from the forge before rebasing, merging, or reporting on a stack, not once at
-the start of a session and not from memory of how it looked earlier.
-
-A stack is only as recoverable as its own foundation. If the bottom-most layer's base is not the
-default branch, the whole stack is built on unmerged work, and nothing above it can fully drain
-until that foundation either merges or the stack is re-rooted onto the default branch — confirm the
-root before treating any stack as one that can simply be worked down layer by layer.
-
-Drain a stack from the bottom, one layer at a time, merging each bottom-most layer as soon as it
-becomes ready rather than waiting for every layer above it to be ready first. A stack should stay as
-short as it can be: every layer that remains unmerged keeps accumulating rebase surface, CI cost,
-and drift against the default branch, and that cost compounds for every layer still stacked above
-it. Because stacked pull requests do not auto-merge, draining only happens through a deliberate
-merge action taken each time a layer becomes ready — nothing lands on its own just because it is
-ready.
-
-Merging a given layer lands that layer and every unmerged layer below it in the same operation, so
-whatever merge target is used must name the bottom-most unmerged layer specifically, not a higher
-one, to land exactly the increment intended for that drain step: naming a higher layer either merges
-more than intended, when everything below also happens to be ready, or is simply unavailable, when
-it is not. Once a layer merges, GitHub retargets the next unmerged layer onto the default branch
-directly, so it becomes the new bottom — treat it the same way on the next drain step.
-
-When a drain stalls — something on the stack needs human attention, or a layer closes without
-merging — but the bottom-most layer is otherwise ready to merge, stop before yielding: report the
-stack's current state layer by layer, and ask whether to merge that ready bottom layer before
-continuing. Do not leave a ready bottom layer sitting under a blocked or stalled upper layer without
-saying so.
-
-A stall belongs to the layer it happened on, not to the stack as a whole: keep readying every other
-layer whose progress does not depend on the blocked one, and pause the drain entirely only once
-nothing further can be readied without it. The same scoping applies to ownership — shepherd only the
-layers actually assigned to you, and treat any other layer in the same stack as something to report
-on, not to act on.
-
-Do not invent a default branch, a stacking tool or its command catalog, an exact merge-selector
-syntax, or a merge-authorization policy. A consumer wrapper or local instruction file owns those
-choices for this repository.
+Use when a change is a chain of native GitHub stacked pull requests. Read local `AGENTS.md` and
+`AGENTS.md` first. They own whether this repository stacks, which tool creates, rebases, and merges
+a stack, and who may authorize a merge.
+
+- Each pull request except the bottom one targets the pull request below it. The bottom pull
+  request targets the default branch.
+- GitHub merges the selected pull request and every unmerged pull request below it, bottom-up, as
+  one operation. That merge is available only when everything below already meets this repository's
+  merge requirements. An isolated middle layer cannot merge.
+- Auto-merge is unsupported. A non-stack merge is not a substitute.
+- When a mid-stack pull request's base is an unmerged branch, confirm the merge path understands
+  stacks before merging.
+- Re-read the forge's layers, order, and bases immediately before a rebase, merge, or status
+  report. Local stack metadata is stale after a rebase, relink, or manual recovery.
+- The bottom layer's base must be the default branch. Otherwise merge that base or re-root the
+  stack onto the default branch before draining.
+- Merge the bottom-most ready layer as soon as it is ready. Do not wait for layers above it.
+  Nothing in the stack merges on its own.
+- Name that bottom-most unmerged layer as the merge target. Naming a higher layer merges more than
+  this step when everything below is also ready, and is unavailable when it is not.
+- After a merge, GitHub retargets the next unmerged layer onto the default branch. That layer is
+  the new bottom.
+- On a stall, or when a layer closes without merging, stop if the bottom layer is otherwise ready.
+  Report every layer and ask before merging that bottom layer.
+- A stall blocks only layers that depend on it. Ready the others. Pause the whole drain only when
+  nothing further can be readied without the blocked layer.
+- Act only on layers assigned to you. Report the other layers; do not change them.
+
+Consumer wrapper owns: default branch, stacking tool and commands, merge-selector syntax, and
+merge authorization.

package/skills/static-analysis-checklist/SKILL.md

@@ -5,14 +5,16 @@ description: Use when adding, changing, replacing, or removing static-analysis r
 
 # Static analysis checklist
 
-Use when changing a static-analysis invariant. Read local `AGENTS.md`, `CLAUDE.md`, analyzer
+Use when changing a static-analysis invariant. Read local `AGENTS.md`, analyzer
 documentation, rule inventory, and fixture conventions before selecting an implementation.
 
 1. State the invariant and search for an existing analyzer, rule, or guard that owns it. Prefer the
    narrowest established owner over a parallel scanner.
-2. For workflow or action policy, parse YAML instead of text matching and inspect only intended tracked
-   configuration files. A persistent-workspace guard must reject sparse-checkout inputs and unsafe
-   writable workspace mounts while allowing unrelated YAML keys and ordinary read-only mounts.
+2. For workflow or action policy, parse YAML instead of text matching. Inspect only intended
+   tracked configuration files. A persistent-workspace guard enforces
+   [github-actions-checklist](../github-actions-checklist/SKILL.md): reject sparse-checkout inputs
+   and unsafe writable workspace mounts, and allow unrelated YAML keys and ordinary read-only
+   mounts.
 3. Add meaningful accepted and rejected fixtures before the rule. Cover path routing, parser
    boundaries, equivalent YAML forms, and every allowed exception.
 4. Keep discovery limited to tracked, intended files. Make suppressions and allowlists narrow,

package/skills/storybook-authoring/SKILL.md

@@ -5,14 +5,14 @@ description: Add maintainable Storybook stories and browser-mode component cover
 
 # Storybook authoring
 
-Create stories that show meaningful supported states with realistic args and fixtures. Keep story
-data local and deterministic, expose important visual or interaction variants, and add browser-mode
-coverage where it catches behavior unavailable to unit tests. Do not use stories as a substitute for
-end-to-end setup or production data handling.
+Apply [test-authoring](../test-authoring/SKILL.md).
 
-Consumer wrappers own Storybook configuration, exclusions, visual baselines, and commands.
+- Show a meaningful supported state with realistic args and fixtures.
+- Keep story data local and deterministic.
+- Expose an important visual or interaction variant.
+- Add browser-mode coverage where it catches behavior a unit test cannot see.
+- Do not use a story as end-to-end setup or as production data handling.
+- Read [component coverage](references/component-coverage.md) for direct stories and browser
+  isolation.
 
-Read [component coverage](references/component-coverage.md) for direct stories and browser isolation.
-
-Read [tautological tests](../test-authoring/references/tautological-tests.md) before finishing any
-interaction assertion that is not obviously falsifiable by a defect in the component under test.
+Consumer wrapper owns: Storybook configuration, exclusions, visual baselines, and commands.

package/skills/swift-test-authoring/SKILL.md

@@ -5,14 +5,15 @@ description: Add Swift and SwiftUI tests with deterministic state, networking, a
 
 # Swift test authoring
 
-Test public behavior with deterministic inputs and injected dependencies. For SwiftUI, inspect or
-interact through the project's supported test approach; for networking, use a protocol-level test
-double and keep request/response synchronization explicit. Avoid sleeps and global state, and keep
-fixtures small enough to make failures readable.
+Apply [test-authoring](../test-authoring/SKILL.md).
 
-Consumer wrappers own test targets, coverage thresholds, view-inspection libraries, and fixture APIs.
+- Test public behavior with deterministic inputs and injected dependencies.
+- For SwiftUI, inspect or interact through the project's supported test approach.
+- For networking, use a protocol-level test double. Keep request and response synchronization
+  explicit.
+- Avoid sleeps and global state. Keep fixtures small enough that a failure is readable.
+- Read [network test doubles](references/network-test-doubles.md) for cancellation and shared-state
+  safety.
 
-Read [network test doubles](references/network-test-doubles.md) for cancellation and shared-state safety.
-
-Read [tautological tests](../test-authoring/references/tautological-tests.md) before finishing any
-assertion that is not obviously falsifiable by a defect in the code under test.
+Consumer wrapper owns: test targets, coverage thresholds, view-inspection libraries, and fixture
+APIs.

package/skills/test-authoring/SKILL.md

@@ -5,19 +5,19 @@ description: Write focused, maintainable tests and test fixtures for application
 
 # Test authoring
 
-Use the repository's test conventions and runner skill. Test observable behavior, boundary failures,
-and regressions rather than implementation details. Build fixtures through public constructors or
-documented helpers; keep data minimal, explicit, and representative. Add a focused failing test
-before a behavior change when practical, then run the narrowest relevant test and required checks.
+Use the repository's test conventions and the matching runner skill.
 
-Do not invent project test commands, coverage targets, mock libraries, or integration environments.
-A consumer wrapper owns those choices.
+- Test observable behavior, boundary failures, and regressions. Do not test implementation details.
+- Build fixtures through public constructors or documented helpers. Keep data minimal, explicit, and
+  representative.
+- Add a focused failing test before a behavior change when that behavior can be tested. Then run the
+  narrowest relevant test and the required checks.
+- Read [core practice](references/core-practice.md) before choosing a runner-specific approach.
+- Read [tautological tests](references/tautological-tests.md) before finishing a test whose
+  assertion
+  is not obviously falsifiable by a defect in the code under test.
+- Read [dependency boundaries](references/dependency-boundaries.md) before asserting on anything a
+  dependency produces, and whenever a dependency upgrade breaks a test.
 
-Read [core practice](references/core-practice.md) for the shared boundary, completion, and evidence
-rules before choosing a runner-specific approach.
-
-Read [tautological tests](references/tautological-tests.md) before finishing any test whose
-assertion is not obviously falsifiable by a defect in the code under test.
-
-Read [dependency boundaries](references/dependency-boundaries.md) before asserting on anything a
-dependency produces, and whenever a dependency upgrade breaks a test.
+Consumer wrapper owns: project test commands, coverage targets, mock libraries, and integration
+environments.

package/skills/test-authoring/references/core-practice.md

@@ -1,13 +1,14 @@
 # Core test practice
 
-Choose the lowest realistic boundary that can observe the contract. Mock external systems and
-uncontrolled infrastructure; exercise internal module composition where practical. Test behavior,
-failure paths, authorization, and security-relevant validation rather than private calls, and
-assert what this repository owns rather than what its [dependencies](dependency-boundaries.md)
-produce.
-
-Start with a failing test when the behavior is testable. Finish only when the production path, its
-public contract, documentation, and generated artifacts move together. Do not leave placeholders or
-test-only production branches. For every acceptance criterion, retain evidence from a focused test,
-review, or explicitly justified manual check — evidence only counts if it is falsifiable, so confirm
-the assertion is not [tautological](tautological-tests.md) before treating it as coverage.
+- Choose the lowest realistic boundary that can observe the contract.
+- Mock an external system or uncontrolled infrastructure. Exercise internal module composition where
+  that is practical.
+- Test behavior, failure paths, authorization, and security-relevant validation. Do not reach it
+  through a private call. Assert what this repository owns, not what its
+  [dependencies](dependency-boundaries.md) produce.
+- Start with a failing test when the behavior is testable.
+- Finish only when the production path, its public contract, documentation, and generated artifacts
+  move together. Do not leave a placeholder or a test-only production branch.
+- For every acceptance criterion, keep evidence from a focused test, a review, or an explicitly
+  justified manual check. Evidence counts only when it is falsifiable. Confirm the assertion is not
+  [tautological](tautological-tests.md) before treating it as coverage.

package/skills/test-authoring/references/dependency-boundaries.md

@@ -1,37 +1,38 @@
 # Dependency boundaries
 
-Test the code this repository owns. A dependency's behavior — its algorithms, error messages, output
-formats, internal file layout, exit codes, the URLs and query strings it builds, its pagination and
-retry strategy, and the order or number of calls it makes — belongs to that dependency's own tests.
-An assertion that pins any of it fails when the dependency ships a release rather than when this
-repository regresses, so every upgrade arrives as a red build that no change here caused.
-
-Apply the [tautological tests](tautological-tests.md) falsifiability check with ownership added: for
-every assertion, name a defect in this repository's code that would make it fail. If only a
-dependency release could fail it, delete it. If it covers owned logic but also pins incidental
-dependency detail, rewrite it to assert the owned outcome. What the repository chooses or promises
-is owned even when a dependency carries it out — the rules it enables, its thresholds and scopes,
-the arguments, endpoints, and parameters it passes, how it handles a dependency's exit codes and
-errors, and any call count or order its own logic requires — so test it, but through the
-dependency's public API rather than its internals.
-
-Watch for these shapes. A version-drift guard deep-imports a package's private files or calls its
-internal functions so the suite notices when upstream behavior changes; it couples the suite to a
-layout the package never promised, so delete it, and when documentation relies on dependency
-behavior, link to the dependency's own documentation instead of restating and pinning it. A
-dependency re-test runs a dependency with fabricated input and asserts what it returns; a wrapper
-that only forwards configuration needs one test proving the configuration arrives, not a second copy
-of the dependency's suite. An upstream-output pin asserts exact dependency-owned messages, markdown,
-JSON envelopes, or renderer markup when the owned contract is narrower; assert the rule identifier,
-status, or owned field instead. A sequence-bound fake answers by call order — chained one-shot mock
-responses, or a queue of canned replies consumed in turn — when the code under test does not own
-that order, so a dependency that adds a request, paginates differently, or reorders its calls hands
-the wrong reply to the wrong call; route the fake by request meaning, such as method and pathname,
-and assert the owned result rather than dependency-incidental URL, query-string, or call-count
-details.
-
-When a dependency upgrade breaks a test, first ask whether the test pinned dependency behavior. If
-it did, fix the test by deleting or rewriting it rather than re-pinning the new upstream value, and
-do not add a guard that fails on the next release. If the failure traces to owned code or owned
-configuration — the dependency now rejects arguments this repository passes, or returns a result
-this repository's logic mishandles — it is a real regression, so fix the owned code instead.
+Test the code this repository owns. The dependency's own tests own its algorithms, error messages,
+output formats, internal file layout, exit codes, the URLs and query strings it builds, its
+pagination and retry strategy, and the order or number of calls it makes. An assertion that pins
+any of that fails on a dependency release, not on a regression here.
+
+Apply the [tautological tests](tautological-tests.md) check with ownership added. Name a defect in
+this repository that would fail the assertion.
+
+- If only a dependency release could fail it, delete it.
+- If it covers owned logic and also pins incidental dependency detail, rewrite it to the owned
+  outcome.
+
+Owned even when a dependency carries it out: enabled rules, thresholds, scopes, arguments,
+endpoints, parameters, handling of the dependency's exit codes and errors, and any call count or
+order this repository's logic requires. Test those through the dependency's public API.
+
+Shapes:
+
+- Version-drift guard: a deep import of private files, or a call to internal functions, so the
+  suite notices an upstream change. Delete it. When docs rely on dependency behavior, link to the
+  dependency's docs.
+- Dependency re-test: fabricated input asserted against what the dependency returns. A wrapper that
+  only forwards configuration needs one test that the configuration arrives.
+- Upstream-output pin: an exact dependency-owned message, markdown blob, JSON envelope, or renderer
+  markup when the owned contract is narrower. Assert the rule identifier, status, or owned field.
+- Sequence-bound fake: one-shot responses, or a queue consumed in call order, when this repository
+  does not own that order. An added request, a pagination change, or a reorder then hands the wrong
+  reply to the wrong call. Route the fake by request meaning, such as method and pathname. Assert
+  the owned result, not an incidental URL, query string, or call count.
+
+When a dependency upgrade breaks a test:
+
+- If the test pinned dependency behavior, delete or rewrite it. Do not re-pin the new value. Do not
+  add a guard that fails on the next release.
+- If owned code or configuration failed — the dependency rejects arguments this repository passes,
+  or returns a result this repository mishandles — fix the owned code.

package/skills/test-authoring/references/tautological-tests.md

@@ -1,46 +1,47 @@
 # Tautological tests
 
-A test is tautological when no defect in the code under test could make its assertion fail. Before
-trusting an assertion, name a concrete defect it would catch; if none exists, the assertion proves
-nothing regardless of how many lines it exercises. A test name is part of the assertion: `it('returns
-200')` that never reads the status is itself the defect, since reviewers trust the name and skim the
-body instead of checking that it matches what is asserted.
-
-Watch for these shapes, most consequential first. A forced-value tautology transforms the result
-before asserting on the transformed constant, as in `expect(x.then(() => undefined))
-.resolves.toBeUndefined()`: the `.then` still depends on `x` fulfilling rather than rejecting, but
-every fulfillment value collapses to the same `undefined`, so the assertion no longer depends on what
-the code actually returned — ask whether the assertion still depends on the code's output, not merely
-on whether it threw; a test named after the data it claims to return is asserting nothing about that
-data. A literal tautology asserts a literal against itself, `expect(true).toBe(true)`, with
-equivalents in other runners (`XCTAssertTrue(true)`, `Assert.True(true)`). A self-comparison,
-`expect(x).toBe(x)`, and a literal echo that asserts on a value the test itself just wrote fail the
-same way: the input and the expectation are the same value with no code path in between. A mock echo
-asserts that a mock returns what it was configured to return, exercising the mock's configuration
-rather than the code under test. A re-implementation recomputes the production algorithm inside the
-test and compares the two computations, so a bug shared by both cancels out invisibly. A vacuous
-range or shape check — `expect(x.length).toBeGreaterThanOrEqual(0)`, or a `toBeDefined()`/`typeof`
-check on a static import or a value the test just constructed — holds for every possible output. A
-no-assert test awaits a call and asserts nothing afterward: it fails if the call throws, but nothing
-distinguishes a correct return value from an incorrect one, and an `expect-expect` lint rule will
-flag the missing assertion regardless.
-
-Coverage pressure is the usual root cause: a line must be covered and no assertion is obvious. Before
-reaching for a weak assertion, check whether the code takes a null- or error-swallowing path for the
-case under test — a repository-lookup helper that returns `null` instead of throwing for a not-found
-condition, for example — and assert the exact expected outcome for the case under test, such as
-`.toBeNull()` for the not-found path or a definite non-null shape for the found path, rather than a
-looser definedness check that would still pass if a regression collapsed the two. Otherwise assert
-the shape of the returned payload. Only when neither is available, fall back to an assertion that
-depends on nothing but successful completion, such as `await expect(run())
-.resolves.not.toBeInstanceOf(Error)`, paired with a test name that says "resolves" rather than
-"succeeds" or "returns 200" — a legitimately weak assertion, honestly labeled as weak. Satisfying a
-coverage percentage while asserting nothing is never acceptable; a 403 executes the same lines as a
-200, and coverage tooling cannot tell them apart.
-
-Delete a tautological test if removing it does not reduce coverage; if it does, that test was the sole
-owner of that coverage and must be strengthened in place, not deleted, since a steady coverage number
-is not evidence the remaining tests check anything real. Consumer repositories may enforce the
-mechanical shapes above with ast-grep rules and an `expect-expect` lint rule; this document is the
-judgment layer for shapes those tools cannot express, such as a definedness check that needs dataflow
-analysis, a mock echo, or a re-implementation — tooling and this guidance should agree, not diverge.
+A test is tautological when no defect in the code under test could make its assertion fail. Name a
+concrete defect the assertion would catch. If none exists, the assertion proves nothing.
+
+A test name is part of the assertion. `it('returns 200')` that never reads the status is the
+defect: reviewers trust the name and skim the body.
+
+Shapes, most consequential first:
+
+- Forced-value: the test transforms the result, then asserts the transformed constant.
+  `expect(x.then(() => undefined)).resolves.toBeUndefined()` still depends on `x` fulfilling, but
+  every fulfillment value collapses to `undefined`. The assertion must depend on the code's output,
+  not only on whether it threw. A test named for returned data that never reads that data asserts
+  nothing about it.
+- Literal: `expect(true).toBe(true)`, and the same shape in other runners (`XCTAssertTrue(true)`,
+  `Assert.True(true)`).
+- Self-comparison: `expect(x).toBe(x)`.
+- Literal echo: the test asserts a value it just wrote. Input and expectation are the same value,
+  with no code path between them.
+- Mock echo: the assertion checks that a mock returns the value the test configured.
+- Re-implementation: the test recomputes the production algorithm and compares the two results, so
+  a shared bug cancels out.
+- Vacuous range or shape: `expect(x.length).toBeGreaterThanOrEqual(0)`, or `toBeDefined()` /
+  `typeof` on a static import or a value the test just constructed. It holds for every output.
+- No-assert: the test awaits a call and asserts nothing afterward. It fails only when the call
+  throws. An `expect-expect` lint rule flags the missing assertion.
+
+Coverage pressure is the usual cause: a line must be covered and no assertion is obvious.
+
+- When the code returns null or swallows an error for the case under test, assert that exact
+  outcome, such as `.toBeNull()` for not-found or a definite non-null shape for found. A
+  definedness check still passes if a regression collapses the two paths.
+- Otherwise assert the shape of the returned payload.
+- Only when neither is available, assert completion alone, such as
+  `await expect(run()).resolves.not.toBeInstanceOf(Error)`, and name the test for resolving rather
+  than for success or a status code.
+- A 403 can execute the same lines as a 200. Do not satisfy a coverage percentage with an
+  assertion that cannot fail.
+
+Delete a tautological test when removing it does not reduce coverage. When removal drops coverage,
+that test owns those lines: strengthen it in place. A steady coverage number does not show that the
+remaining tests check anything.
+
+Consumer repositories may enforce the mechanical shapes above with ast-grep and an `expect-expect`
+rule. This document judges the shapes those tools cannot express: a definedness check that needs
+dataflow analysis, a mock echo, or a re-implementation. Do not contradict the mechanical rules.

package/skills/vitest-test-authoring/SKILL.md

@@ -5,11 +5,14 @@ description: Apply Vitest-specific patterns when adding or changing Vitest tests
 
 # Vitest test authoring
 
-Apply [test-authoring](../test-authoring/SKILL.md) first. Keep tests isolated with Vitest lifecycle
-hooks, restore spies and globals after each test, and prefer deterministic async assertions over
-timing waits. Mock external boundaries rather than modules under test, and use typed factories when
-the project supplies them. Run the selected file or project before broader validation.
+Apply [test-authoring](../test-authoring/SKILL.md) first.
 
-Consumer wrappers own project selection, mock boundaries, fixture names, and coverage policy.
+- Isolate tests with Vitest lifecycle hooks. Restore spies and globals after each test.
+- Prefer a deterministic async assertion over a timing wait.
+- Mock an external boundary. Do not mock the module under test.
+- Use a typed factory when the project supplies one.
+- Run the selected file or project before broader validation.
+- Read [mock boundaries](references/mock-boundaries.md) when adding a module mock or changing an
+  export.
 
-Read [mock boundaries](references/mock-boundaries.md) when adding module mocks or changing exports.
+Consumer wrapper owns: project selection, mock boundaries, fixture names, and coverage policy.