claude-toolkit 0.16.0 → 0.17.0

package/docs/skills/systematic-debugging.md

@@ -1,70 +0,0 @@
-# Systematic Debugging
-
-> Four-phase methodology for diagnosing and fixing bugs efficiently without guesswork. Use when investigating a bug, test failure, or unexpected behavior before proposing a fix
-
-**Type:** Core Skill (always included)
-**Source:** [`core/skills/ct-systematic-debugging/SKILL.md`](../core/skills/ct-systematic-debugging/SKILL.md)
-
-## Overview
-
-A disciplined approach to debugging that replaces trial-and-error with structured investigation. Apply the four phases in order -- skipping phases leads to wasted time and incomplete fixes.
-
-## Phases
-
-### Phase 1: Observe
-
-Reproduce the issue and gather evidence before forming any theories.
-
-- **Reproduce reliably** -- find the minimal steps to trigger the bug
-- **Read the actual error** -- full stack trace, error message, and relevant logs
-- **Check recent changes** -- use `git log` and `git diff` to identify what changed
-- **Gather context** -- note the environment, input data, user actions, and timing
-- **Record observations** -- write down what you see, not what you think is happening
-
-### Phase 2: Hypothesize
-
-Form theories based on evidence, not intuition.
-
-- **List possible causes** -- generate at least 2-3 hypotheses before investigating any
-- **Rank by likelihood** -- what changed recently? What is the simplest explanation?
-- **Consider the data flow** -- trace the path from input to error
-- **Check assumptions** -- the bug is often in the code you trust most
-
-### Phase 3: Test
-
-Isolate variables and verify one hypothesis at a time.
-
-- **Test one thing at a time** -- change a single variable per experiment
-- **Use the smallest possible test** -- write a minimal reproduction
-- **Add logging at boundaries** -- log inputs and outputs at function boundaries
-- **Disprove hypotheses** -- design tests that would show the hypothesis is wrong
-- **Binary search large spaces** -- bisect systematically when the problem could be anywhere
-
-### Phase 4: Fix
-
-Apply the minimal correct fix, then verify thoroughly.
-
-- **Fix the root cause, not the symptom** -- if a null check prevents a crash but the value should never be null, fix the source
-- **Make the smallest change possible** -- large fixes introduce new bugs
-- **Verify the fix** -- run the reproduction case and confirm the bug is gone
-- **Check for regressions** -- run the full test suite
-- **Add a test for the bug** -- prevent the same class of bug from recurring
-- **Document the fix** -- explain what caused the bug and why the fix is correct in the commit message
-
-## Anti-patterns
-
-| Anti-pattern | Description |
-|---|---|
-| **Shotgun debugging** | Making random changes hoping something works. Every change should be driven by a hypothesis. |
-| **Fixing symptoms** | Adding null checks, try/catch blocks, or default values without understanding why the unexpected state occurs. |
-| **Debugging by rewriting** | Rewriting a module because you cannot find the bug. The bug may survive the rewrite. |
-| **Ignoring intermittent failures** | "It works now" is not a fix. Intermittent bugs are usually race conditions, state leaks, or environment dependencies. |
-| **Assuming the bug is elsewhere** | Check your own code first. The framework or library is almost never the problem. |
-
-## Trigger Conditions
-
-This skill is automatically suggested when Claude detects:
-
-- **Keywords:** `bug`, `debug`, `fix`, `error`, `issue`, `broken`, `crash`
-- **Intent patterns:** "fix/debug/resolve the bug/error/issue"
-- **Excludes:** "fix typo", "fix formatting", "fix lint"

package/docs/skills/testing-patterns.md

@@ -1,140 +0,0 @@
-# Testing Patterns
-
-> Generic test-driven development practices and patterns applicable to any language or test framework. Use when writing tests, setting up a test suite, or deciding what to test at which layer
-
-**Type:** Core Skill (always included)
-**Source:** [`core/skills/ct-testing-patterns/SKILL.md`](../core/skills/ct-testing-patterns/SKILL.md)
-
-## Overview
-
-Principles and patterns for writing tests that catch bugs, enable refactoring, and serve as documentation. These are framework-agnostic -- adapt the syntax to your project's test runner.
-
-## TDD Cycle: Red, Green, Refactor
-
-1. **Red** -- Write a failing test for the desired behavior. Confirm it fails for the right reason.
-2. **Green** -- Write the minimal code to make it pass. No optimization yet.
-3. **Refactor** -- Clean up while keeping tests green.
-
-Commit at each stage. The cycle keeps scope small and provides a safety net for every change.
-
-## 3-Layer Testing Strategy
-
-```
-          /  E2E  \           Real browsers, full user flows
-         /----------\
-        / Interaction \       Component sandbox, behavior, a11y
-       /----------------\
-      /      Unit        \    Pure logic, signals, utilities
-     /--------------------\
-```
-
-| Layer       | Target Ratio | What to Cover                                                                |
-| ----------- | ------------ | ---------------------------------------------------------------------------- |
-| Unit        | ~70%         | Business logic, utilities, data transforms, reactive primitives, error paths |
-| Interaction | ~20%         | Component variants, user interactions, accessibility, visual regression      |
-| E2E         | ~10%         | Critical user journeys, authentication flows, cross-page workflows           |
-
-> **Scope:** This core skill owns the layering decision below, the unit and interaction layers, and the cross-cutting E2E principles. Runner-specific E2E setup and execution live in the stack skills (e.g. `ct-playwright-patterns`) when a matching stack is installed.
-
-### When to Use Which Layer
-
-| Question                                          | Layer                                  |
-| ------------------------------------------------- | -------------------------------------- |
-| Does this logic need a DOM?                       | **Unit** if no, **Interaction** if yes |
-| Does it involve multiple pages or navigation?     | **E2E**                                |
-| Am I testing a single component's visual states?  | **Interaction**                        |
-| Am I testing a reactive primitive (signal, memo)? | **Unit**                               |
-| Does it require authentication or real network?   | **E2E**                                |
-| Am I testing component accessibility?             | **Interaction** (axe-core)             |
-| Does it need the full server running?             | **E2E**                                |
-
-## Test Behavior, Not Implementation
-
-Test _what_ code does (public interface, observable outputs), not _how_ (internal state, call counts). Implementation-coupled tests break on every refactor.
-
-## Factory Pattern
-
-```
-function getMockUser(overrides = {}) {
-  return { id: "user-1", email: "test@example.com", name: "Test User", role: "member", ...overrides };
-}
-const admin = getMockUser({ role: "admin" });
-```
-
-New required fields update the factory once, not every test.
-
-## Organization
-
-- Co-locate tests or mirror source structure. One test file per module (`module.test.ext`).
-- Group with `describe`, name as sentences: `it("rejects expired tokens")`.
-
-## Shared Principles
-
-- **Prefer role-based queries.** Use `getByRole`, `getByLabel`, `getByText` over test IDs or CSS selectors.
-- **Never sleep.** Use framework-provided waiting mechanisms (`waitFor`, `findBy*`, web-first assertions).
-- **One assertion focus per test.** Multiple assertions are fine if they verify facets of the same behavior.
-- **Isolate tests.** No test should depend on another test's side effects. Reset state between tests.
-
-## Mocking Rules
-
-- Prefer real dependencies (in-memory DB, local server) when feasible.
-- Mock at boundaries only (external APIs, email, payments), not internal modules.
-- Keep mocks minimal -- only methods your code calls. Reset between tests.
-- Verify mocks match the real API. Update when APIs change.
-
-## Property-Based Testing
-
-When a function has a contract ("for all valid inputs X, property Y holds"), use property-based tests to verify it across generated inputs instead of hand-picked examples:
-
-```typescript
-// Instead of testing 3-4 specific inputs:
-test("sort is idempotent", () => {
-  fc.assert(
-    fc.property(fc.array(fc.integer()), (arr) => {
-      const sorted = mySort(arr);
-      expect(mySort(sorted)).toEqual(sorted);
-    }),
-  );
-});
-```
-
-Good candidates: serialization round-trips, math properties, parsers, encoding/decoding, sorting invariants.
-
-## Bun Test Runner
-
-Bun includes a built-in test runner. Use `bun test` for projects on the Bun runtime:
-
-```bash
-bun test                       # run all *.test.ts files
-bun test --watch               # re-run on changes
-bun test --coverage            # with code coverage
-bun test path/to/file.test.ts  # single file
-```
-
-Bun supports `describe`, `it`/`test`, `expect`, lifecycle hooks, and snapshot testing out of the box with no additional dependencies.
-
-## Test Speed
-
-Three levers recur across common runners (Vitest, Playwright, Storybook browser mode). Stated once here; each stack skill carries the framework-specific syntax.
-
-- **Parallelism sized to the runner.** Enable file-level parallelism (Vitest `fileParallelism`, Playwright `fullyParallel`), but cap workers to the runner's _real_ vCPUs (`"50%"` or a measured count). GitHub standard runners are 2 vCPU (private) / 4 (public); oversubscribing thrashes.
-- **Shard across CI jobs, then merge the blob reports.** Sharding splits at the _file_ level (`--shard=i/n`), so wall-clock is gated by the slowest shard -- balance file sizes. Always emit a blob report per shard (`--reporter=blob`) and merge it (`merge-reports` / `--merge-reports`) in a dependent job, or results and coverage are fragmented and incomplete.
-- **Skip isolation where state is clean.** Per-file environment isolation is the safe default but the biggest run-speed cost. Disable it (Vitest `isolate: false`, `pool: 'threads'`) only for side-effect-free logic suites; keep it where tests mutate globals/env/timers.
-
-Profile before tuning, and never `sleep` to mask timing -- use the framework's auto-waiting (see Shared Principles).
-
-Per-runner config (if the stack is installed): `ct-vite-vitest-patterns`, `ct-playwright-patterns`, `ct-storybook-patterns`.
-
-## Anti-Patterns
-
-1. **Testing implementation** -- Asserting internal state or call counts breaks on refactors.
-2. **Overmocking** -- If most of the test is mock setup, you're testing mocks.
-3. **Copy-paste tests** -- Use factories and parameterized tests.
-4. **No assertions** -- Worse than no test. False confidence.
-5. **Ignoring flaky tests** -- Fix or delete; never skip indefinitely.
-6. **Happy path only** -- Error cases and boundary conditions are where bugs live.
-
-## Trigger Conditions
-
-- **Keywords:** `test`, `spec`, `tdd`, `mock`, `factory`
-- **File patterns:** `**/*.test.ts`, `**/*.spec.ts`

package/docs/skills/typescript-conventions.md

@@ -1,283 +0,0 @@
-# TypeScript Conventions
-
-> Strict TypeScript patterns and compiler selection — prefer the TypeScript 7 native compiler when a project ships it. Use when writing or reviewing TypeScript, running a typecheck, adding or tightening types, or deciding between type and interface
-
-**Type:** Core Skill (always included)
-**Source:** [`core/skills/ct-typescript-conventions/SKILL.md`](../core/skills/ct-typescript-conventions/SKILL.md)
-
-## Overview
-
-Rules for writing TypeScript that leverages the type system fully. These assume strict mode is enabled and prioritize catching errors at compile time over runtime.
-
-The skill also covers **which compiler to run**. TypeScript 7 — the Go-native port — reached GA on 2026-07-08 as `typescript@7.0.2`, with Microsoft reporting 8x–12x faster full builds. The guidance is availability-aware in the same spirit as [ct-esnext-idioms](../stacks/esnext-idioms.md): prefer TS7 where a project already has it, fall back cleanly where it doesn't, and never upgrade a project unprompted.
-
-## Compiler Selection
-
-### Detect before you assume
-
-Read the **installed** version, resolved from the directory being edited (monorepo workspaces can pin different majors):
-
-```bash
-node -p "require('typescript/package.json').version"   # major >= 7 -> TS7
-```
-
-`typescript@7.0.2` whitelists `./package.json` in its `exports` map, and 5.x/6.x have no `exports` map at all, so this subpath resolves on every major.
-
-Three detection traps:
-
-| Trap | Why it misleads |
-|---|---|
-| Looking for a `tsgo` binary | TS7's only CLI binary is `tsc`. `tsgo` belonged to the pre-GA `@typescript/native-preview` package, which is frozen at a `7.0.0-dev` nightly. |
-| Reading the `package.json` semver range | `overrides`, `resolutions`, pnpm/bun catalogs and stale lockfiles all override it — and `*`, `latest`, `>=5` all resolve to 7.x today. |
-| Probing the API (`ts.createProgram`) | On TS7 `require("typescript")` exposes only `version` and `versionMajorMinor`, so an API probe reports a false negative. |
-
-### When TS7 is available
-
-Flags are unchanged from 6.x — `tsc --noEmit`, `tsc -p <path>`, `tsc -b`, `tsc --watch`. New in TS7:
-
-| Flag | Meaning |
-|---|---|
-| `--checkers <n>` | Type-checking workers per project (default 4). Microsoft warns that varying it "may surface order-dependent results" — pin it in CI. |
-| `--builders <n>` | Projects built concurrently in build mode (default 4). |
-| `--singleThreaded` | Most deterministic setting. |
-| `--lsp` | Language server over LSP (there is no `tsserver` binary). |
-
-Note that watch mode is labelled a prototype at the GA tag: it rebuilds but does not incrementally recheck.
-
-### When a tool embeds the compiler — do not switch
-
-TypeScript 7.0 ships **no stable programmatic API**; Microsoft targets 7.1 for "a new (and different) API" with no committed date. Anything that embeds the compiler is blocked:
-
-| Tool | Status on TS7 |
-|---|---|
-| `typescript-eslint` | Peer range `<6.1.0`; install fails `ERESOLVE`, and a forced install crashes during lint |
-| `vue-tsc`, `svelte-check`, `@astrojs/check` | Crash on `ERR_PACKAGE_PATH_NOT_EXPORTED` — TS7 has no `./lib/*` export |
-| `ts-node` | Crashes in config load |
-| `ts-jest` | Peer range `>=4.3 <7` |
-| `@angular/compiler-cli` | Peer range `>=6.0 <6.1` (Microsoft suggests a hybrid: TS7 at the CLI, TS6 for editor support) |
-
-Unaffected — these carry no `typescript` dependency at all: Vite, Bun, `tsx`, Vitest, Jest, Biome.
-
-**A type-check smoke test will not catch these failures.** typescript-eslint's breakage surfaces at `npm ci` and at lint time while `tsc --noEmit` still passes. When a blocked tool is present, install both compilers side by side rather than downgrading — this is Microsoft's documented escape hatch:
-
-```json
-{
-  "devDependencies": {
-    "@typescript/native": "npm:typescript@^7.0.2",
-    "typescript": "npm:@typescript/typescript6@^6.0.2"
-  }
-}
-```
-
-The `typescript` key must stay pointed at the 6.0 compatibility package, because blocked tools import from `typescript` by peer dependency.
-
-### When TS7 is absent
-
-The floor is `typescript@6.0.3` — the last 6.x release, and the bridge Microsoft designates between 5.9 and 7.0. It also sits inside every current ecosystem peer range. The readiness gate before moving a project to 7 is a clean 6.0 build with `"stableTypeOrdering": true` and no `ignoreDeprecations` set. That flag is a diagnostic aid only — Microsoft notes it can add up to 25% to type-checking time and is not meant to be left on.
-
-### `tsconfig.json` under TS7
-
-These are rejected outright, and `ignoreDeprecations` no longer silences them (in 6.0 they were silenceable errors; in 7.0 there is no escape hatch):
-
-| Rejected | Replacement |
-|---|---|
-| `baseUrl` | project-root-relative `paths` |
-| `outFile`, `downlevelIteration` | remove |
-| `target: "es5"` | `"es2015"` or later |
-| `module: "amd" \| "umd" \| "system" \| "none" \| "systemjs"` | `"esnext"`, `"preserve"`, or `"nodenext"` |
-| `moduleResolution: "node" \| "node10" \| "classic"` | `"bundler"`, `"node16"`, or `"nodenext"` |
-| `esModuleInterop` / `allowSyntheticDefaultImports` / `alwaysStrict` set to `false` | drop the override |
-
-These are gone entirely — `TS5023: Unknown compiler option`: `out`, `charset`, `keyofStringsOnly`, `suppressImplicitAnyIndexErrors`, `noImplicitUseStrict`, `importsNotUsedAsValues`, `preserveValueImports`, `suppressExcessPropertyErrors`, `noStrictGenericChecks`.
-
-Two changed defaults account for most real-world breakage:
-
-- **`types` defaults to `[]`.** Ambient globals like `process` vanish with `TS2591`. Set it explicitly: `"types": ["node"]`, or `["bun"]` for Bun projects.
-- **`rootDir` defaults to `./`.** With sources under `src/` and an `outDir`, emit fails `TS5011`. Set `"rootDir": "./src"`. This fires **only when the program emits** — `tsc --noEmit` stays silent, so a type-check-only CI job can stay green while the build breaks.
-
-`strict` defaults to `true`, and `stableTypeOrdering` is on and cannot be turned off. `experimentalDecorators` and `emitDecoratorMetadata` both survive.
-
-Project references, `--build` mode, incremental builds, declaration emit, and CommonJS emit all work.
-
-> Reference note: `typescriptlang.org/tsconfig` has not been updated for TS7 and still documents removed options, and there is no TS 7.0 handbook release-notes page. The [GA announcement](https://devblogs.microsoft.com/typescript/announcing-typescript-7-0/) is the authoritative what's-new source.
-
-## Key Patterns
-
-### Strict Mode
-
-Enable all strict checks in `tsconfig.json`:
-
-```json
-{
-  "compilerOptions": {
-    "strict": true,
-    "noUncheckedIndexedAccess": true,
-    "noUnusedLocals": true,
-    "noUnusedParameters": true
-  }
-}
-```
-
-Never disable strict checks for convenience.
-
-### No `any`
-
-Never use `any`. It disables type checking entirely.
-
-- Use `unknown` when the type is genuinely not known, then narrow before use
-- Use generics when the type varies but has a consistent shape
-- Use specific types when you know the data shape
-
-### Type vs Interface
-
-- **Default to `type`.** It covers object shapes, unions, intersections, mapped types, and utility types.
-- **Use `interface` only when you need `extends`** (an inheritance hierarchy or declaration merging).
-
-```typescript
-// Default: use type for object shapes
-type User = {
-  id: string;
-  email: string;
-  role: UserRole;
-};
-
-// Unions, intersections, utilities: type
-type UserRole = "admin" | "member" | "guest";
-
-// interface only when you need extends
-interface Animal {
-  name: string;
-}
-interface Dog extends Animal {
-  breed: string;
-}
-```
-
-### `as const` for Literal Types
-
-Use `as const` to narrow literal values and create readonly tuples:
-
-```typescript
-const ROLES = ["admin", "member", "guest"] as const;
-type Role = (typeof ROLES)[number]; // "admin" | "member" | "guest"
-```
-
-### Exhaustive Switch with `never`
-
-Handle every case in a switch and use `never` to catch missing branches at compile time:
-
-```typescript
-function getPermissions(role: UserRole): string[] {
-  switch (role) {
-    case "admin":
-      return ["read", "write", "delete"];
-    case "member":
-      return ["read", "write"];
-    case "guest":
-      return ["read"];
-    default: {
-      const _exhaustive: never = role;
-      throw new Error(`Unhandled role: ${_exhaustive}`);
-    }
-  }
-}
-```
-
-### Discriminated Unions for State Modeling
-
-Model states with different associated data as discriminated unions to make illegal states unrepresentable:
-
-```typescript
-type AsyncState<T> =
-  | { status: "loading" }
-  | { status: "success"; data: T }
-  | { status: "error"; error: Error };
-```
-
-### `satisfies` Operator
-
-Validate a value conforms to a type while keeping the value's own narrower inferred type instead of collapsing to the annotation. Here it preserves the exact key set (`home`, `user`) rather than the index signature `Record<string, Route>`:
-
-```typescript
-type Route = { path: string; children?: Route[] };
-
-const routes = {
-  home: { path: "/" },
-  user: { path: "/user/:id", children: [{ path: "settings" }] },
-} satisfies Record<string, Route>;
-
-// routes.home and routes.user are known keys -- not `Route | undefined` from the index signature.
-// Note: routes.home.path is `string`, NOT the literal "/", because `Route` declares `path: string`,
-// which widens the literal. To keep a literal, target a narrower type (e.g. a union) or add `as const`.
-```
-
-### `const` Type Parameters
-
-Infer literal types from arguments without requiring callers to write `as const`:
-
-```typescript
-function createConfig<const T extends readonly string[]>(names: T): Record<T[number], boolean> {
-  // `Object.fromEntries` is typed to return a wide `Record<string, boolean>`, so a single
-  // localized `as` at a generic helper's return boundary is acceptable here -- it keeps the
-  // public signature precise. This is the narrow exception to the "no `as` casts" anti-pattern.
-  return Object.fromEntries(names.map(n => [n, false])) as Record<T[number], boolean>;
-}
-
-// result: Record<"debug" | "verbose", boolean>
-const flags = createConfig(["debug", "verbose"]);
-```
-
-### Template Literal Types
-
-Build precise string types from unions:
-
-```typescript
-type EventName = "click" | "focus" | "blur";
-type Handler = `on${Capitalize<EventName>}`; // "onClick" | "onFocus" | "onBlur"
-
-type Locale = "en" | "fr" | "ja";
-type Currency = "USD" | "EUR" | "JPY";
-type PriceKey = `price:${Locale}:${Currency}`; // 9 valid combinations
-```
-
-### Generic Constraints
-
-Use `extends` to constrain generics, documenting expectations and catching misuse:
-
-```typescript
-function findById<T extends { id: string }>(items: T[], id: string): T | undefined {
-  return items.find((item) => item.id === id);
-}
-```
-
-## Anti-patterns
-
-| Anti-pattern | Description |
-|---|---|
-| **Type assertions (`as`)** | Tells the compiler "trust me" -- use type guards and narrowing instead. |
-| **Non-null assertion (`!`)** | Suppresses null checks. Handle the null case explicitly. |
-| **Enum overuse** | Prefer string literal unions. Enums generate runtime code and have surprising behavior. |
-| **`Object`, `Function`, `{}`** | Almost never what you want. Use specific interfaces or function signatures. |
-| **`@ts-ignore`** | Suppressing errors without tracking means the error will be forgotten. |
-
-## Best Practices Reference
-
-For deeper guidance on the patterns referenced above (sourced from Matt Pocock / Total TypeScript):
-
-| Topic | Guide |
-|---|---|
-| Default to `type`, use `interface` for `extends` | [Type vs Interface](../best-practices/typescript/type-vs-interface.md) |
-| Why enums are problematic, `as const` alternative | [Enums & Alternatives](../best-practices/typescript/enums-alternatives.md) |
-| When `any` is acceptable (two exceptions) | [any & unknown](../best-practices/typescript/any-and-unknown.md) |
-| State modeling with discriminated unions | [Discriminated Unions](../best-practices/typescript/discriminated-unions.md) |
-| Three patterns for generics | [Generics Patterns](../best-practices/typescript/generics-patterns.md) |
-| Recommended `tsconfig.json` settings | [TSConfig Cheat Sheet](../best-practices/typescript/tsconfig-cheat-sheet.md) |
-| Branded types, assertion functions, type predicates | [Essential Patterns](../best-practices/typescript/essential-patterns.md) |
-
-See the full collection: [TypeScript Best Practices](../best-practices/typescript/README.md)
-
-## Trigger Conditions
-
-- **Keywords:** `typescript`, `type`, `interface`, `generic`
-- **File patterns:** `**/*.d.ts`, `**/types/**`
-- **Intent patterns:** "define/create type/interface"

package/docs/skills/verification-before-completion.md

@@ -1,103 +0,0 @@
-# Verification Before Completion
-
-> Evidence-based completion claims -- never say "done" without proof that the work is correct. Use when about to claim a task is done, fixed, or passing, or before committing or opening a PR
-
-**Type:** Core Skill (always included)
-**Source:** [`core/skills/ct-verification-before-completion/SKILL.md`](../core/skills/ct-verification-before-completion/SKILL.md)
-
-## Overview
-
-The most common source of rework is claiming completion without verification. Every "done" claim must be backed by evidence that the code works correctly. "I wrote the code" is not evidence. "The tests pass, the types check, and here is the output" is evidence.
-
-## Verification Checklist
-
-### 1. Tests Pass
-
-Run the full test suite (or related tests) and show the output. If any test fails, fix it before claiming complete.
-
-### 2. Type Checks Pass
-
-Run the type checker with no errors (`tsc --noEmit` or equivalent). Zero errors, zero warnings on changed files.
-
-### 3. Linting Passes
-
-Run the project's linter on changed files. Fix any violations introduced by your changes.
-
-### 4. The Feature Actually Works
-
-For user-facing changes, demonstrate the feature works with actual output -- API responses, rendered UI, CLI output:
-
-```
-$ curl -s localhost:3000/api/users/1 | jq .
-{
-  "id": "1",
-  "name": "Alice",
-  "email": "alice@example.com"
-}
-```
-
-### 5. Edge Cases Verified
-
-Test boundaries and unusual inputs explicitly:
-
-- **Empty inputs** -- empty strings, empty arrays, null, undefined
-- **Boundary values** -- zero, negative numbers, maximum values, off-by-one
-- **Invalid inputs** -- wrong types, malformed data, missing required fields
-- **Concurrent access** -- simultaneous requests or operations
-- **Error paths** -- network failures, database errors, permission denied
-
-### 6. Security Check
-
-Before completing work that touches dependencies, inputs, or external data:
-
-- **Dependency audit** -- Run `bun audit` or `npm audit` and resolve critical/high vulnerabilities
-- **Input validation** -- Verify user-facing inputs are validated at system boundaries (no SQL injection, XSS, command injection)
-- **Secret exposure** -- Confirm no secrets, API keys, or credentials in committed code or logs
-
-### 7. Regression Check
-
-- Run related tests, not just the tests you wrote
-- Check integration points if you changed a shared utility, API contract, or database schema
-- Smoke test the application if it has a running instance
-
-## Evidence Format
-
-When reporting completion, include concrete evidence:
-
-```markdown
-## Completed: User authentication endpoint
-
-### Tests
-- 12 tests passing (3 new, 9 existing)
-- `npm test -- --grep "auth"` output: all green
-
-### Type check
-- `tsc --noEmit`: 0 errors
-
-### Security
-- `bun audit`: 0 vulnerabilities
-- No secrets in committed files
-
-### Manual verification
-- POST /api/auth/login with valid credentials: 200 + JWT token
-- POST /api/auth/login with wrong password: 401 + error message
-- POST /api/auth/login with locked account: 423 + lockout message
-
-### Edge cases verified
-- Empty email: 400 validation error
-- SQL injection attempt in email: properly escaped, no error
-- Expired token refresh: 401 with clear message
-```
-
-## What This Prevents
-
-- **"It works on my machine" failures** -- evidence shows it works in a verifiable way
-- **Phantom completions** -- tasks marked done that are actually broken
-- **Regression blindness** -- catching breakage before it reaches review or production
-- **Incomplete implementations** -- edge cases and error handling are verified, not assumed
-
-## Trigger Conditions
-
-- **Keywords:** `verify`, `check`, `confirm`, `done`, `complete`
-- **Intent patterns:** "is it done", "verify it works"
-- **Context patterns:** "before claiming", "make sure"