@event4u/agent-config 8.9.0 → 8.11.0

package/dist/agent-src/skills/spreadsheet-authoring/evals/triggers.json

@@ -0,0 +1,47 @@
+{
+    "skill": "spreadsheet-authoring",
+    "last_eval": "2026-07-10",
+    "description": "5 should-trigger + 5 should-not-trigger queries for the spreadsheet surface floor (road-to-surface-specific-agent-contracts Phase 2). Should-trigger covers building/editing a spreadsheet or model, entering formulas or sourced/financial figures, and charting raw data. Should-not-trigger covers near-miss neighbours whose vocabulary overlaps but belong to a different surface/skill: unit-economics reasoning, runway shape, a prose document, a slide deck, and backend work.",
+    "queries": [
+        {
+            "q": "build a 3-statement financial model in a spreadsheet",
+            "trigger": true
+        },
+        {
+            "q": "add a formula to sum the revenue column and total it",
+            "trigger": true
+        },
+        {
+            "q": "chart this raw sales transaction data",
+            "trigger": true
+        },
+        {
+            "q": "enter the revenue figures from the company's 10-K into the sheet",
+            "trigger": true
+        },
+        {
+            "q": "create a budget spreadsheet with monthly categories",
+            "trigger": true
+        },
+        {
+            "q": "what is our LTV to CAC ratio and is it healthy?",
+            "trigger": false
+        },
+        {
+            "q": "how long is our cash runway?",
+            "trigger": false
+        },
+        {
+            "q": "write a PRD for the new onboarding feature",
+            "trigger": false
+        },
+        {
+            "q": "turn these results into a slide deck",
+            "trigger": false
+        },
+        {
+            "q": "add a database index on the orders table",
+            "trigger": false
+        }
+    ]
+}

package/dist/agent-src/skills/subagent-orchestration/SKILL.md

@@ -1,7 +1,7 @@
 ---
 model_tier: inherit
 name: subagent-orchestration
-description: "Use when orchestrating implementer/judge subagents — seven modes (do-and-judge ±two-stage, do-in-steps/parallel/worktrees, do-competitively, judge-with-debate) — models from .agent-settings.yml."
+description: "Use when orchestrating implementer/judge subagents — form gate + eight modes (do-and-judge ±two-stage, steps/parallel/worktrees, competitively, debate, live-app-judge)."
 domain: process
 workspaces:
   - agent-config-maintainer
@@ -82,11 +82,46 @@ over-scripted prompts that break on first contingency.
 - **(d) Pre-declared check-in conditions.** The worker names, at spawn time, the
   conditions under which it will halt and ask ("if login required", "if
   multiple candidates found") — so interrupts are predictable, not surprises.
+- **(e) Attach relevant knowledge — read-only (road-to-opt-subagent-harvest
+  P3).** Before dispatch, look up the slice's key identifiers via
+  `memory_lookup` / the knowledge cards and attach the top hits to the
+  worker prompt AS LEADS — labelled per the source-discovery discipline
+  (negative facts + pointers durable; positive structure = hypothesis to
+  re-confirm, never a build input). The WRITE half stays forbidden: a
+  subagent's output is never auto-persisted into memory — promotion is
+  always the human-gated flow (ADR-098 floor). Auto-surface, never
+  auto-write.
 
 When to delegate at all is [`delegation-policy`](../../rules/delegation-policy.md);
 the spawn boundary is the [`subagent-spawn-contract`](../../contexts/execution/subagent-spawn-contract.md).
 
-## The seven modes
+## Form gate — deterministic, BEFORE mode selection
+
+With auto-dispatch on by default (ADR-117), mode selection happens without
+a human in the loop — so the FORM is decided by a static table first, and
+only then is the specific mode picked inside that form. Static table only:
+no learned routing, no self-modifying selector (rejected, stays rejected).
+
+| Task shape (structural signal) | Form | Modes in the form |
+|---|---|---|
+| ≥ 2 independent, verifiable slices | parallel | `do-in-parallel`, `do-competitively` |
+| Multi-step cross-wing chain needing filesystem isolation | worktrees | `do-in-worktrees` |
+| Ordered steps with declared dependencies | steps | `do-in-steps` |
+| Single change with non-trivial risk / contested spec / decision | judge | `do-and-judge`, `do-and-judge-two-stage`, `judge-with-debate`, `do-with-live-app-judge` |
+| Single slice below the delegability floor, unstructured, or frontier-priced | none | no dispatch — run in-session |
+
+Rules:
+
+- The gate consumes the SAME structural signals as
+  `auto_dispatch.ts::classifyTask` (slice count, dependency declarations,
+  size floor) — it never re-interprets the task text on vibes.
+- Ambiguous shape → `none` (in-session), never a speculative spawn — the
+  delegation-policy default.
+- Record the outcome in the telemetry line (`dispatch_mode` field, mode id
+  or `none`) so the gate's value is measurable inside the ADR-117
+  prove-or-drop window.
+
+## The eight modes
 
 Each mode has a decision row: when to use, when not, and the expected
 model pairing. Defaults come from
@@ -178,49 +213,23 @@ migration, public API) where a single judge is too easy to fool.
 
 ### 7. do-in-worktrees
 
-Cross-wing or cross-skill chain executed across isolated git
-worktrees — each handoff in the chain runs in its own worktree, so
-the workspace state of one step never leaks into the next. Operationalizes
-the worktree boundary clause in
-[`docs/contracts/cross-wing-handoff.md`](../../../docs/contracts/cross-wing-handoff.md)
-§ 3. State-machine layer only — worktree creation/destruction lives
-in [`using-git-worktrees`](../using-git-worktrees/SKILL.md) and
-[`finishing-a-development-branch`](../finishing-a-development-branch/SKILL.md).
+Cross-wing or cross-skill chain executed across isolated git worktrees —
+each handoff runs in its own worktree so one step's workspace state never
+leaks into the next. Use for a multi-step cross-wing chain (≥2 senior
+skills, each ≥30 min); not for fast iteration under 30 min (overhead
+dominates). Full handoff shape, example chain, competitive per-candidate
+isolation, and the no-auto-merge Hard Floor →
+[`subagent-modes-detail`](../../agent-src/contexts/execution/subagent-modes-detail.md) § Mode 7.
 
-| When to use | When not | Model pairing |
-|---|---|---|
-| Multi-step cross-wing chain (≥2 senior skills, each ≥30 min) where one step's open files / branch state would confuse the next | Fast iteration where each step < 30 min — worktree overhead exceeds isolation benefit | implementers = same tier per step; judge = one tier up at chain end |
-
-**Handoff shape:** initiator-skill emits the typed output declared in
-its `## Output` block → control passes to delegated-skill in a fresh
-worktree → delegated-skill consumes the input shape declared in its
-`## Input` (or `## When the agent should load this`) block. The
-handoff is auditable; `lint_handoffs.ts` validates the chain.
-
-**Example chain (W3 launch):** `positioning-strategy` (worktree A) →
-`messaging-architecture` (worktree B, consumes positioning's
-`positioning-statement.md`) → `gtm-launch` (worktree C, consumes
-both prior artifacts). Each worktree carries one branch; the chain
-end produces a single integration PR.
-
-**Anti-pattern:** do not use for fast iteration loops where each
-step is under ~30 minutes. The branch-creation, context-switch, and
-worktree-cleanup cost dominates. Stick with mode 1 (do-and-judge)
-or mode 3 (do-in-steps) for those.
-
-**Competitive variant — per-candidate isolation.** When mode 5
-(`do-competitively`) is combined with worktrees, each candidate
-implementer runs in its own worktree (so candidates cannot read each
-other's open files or branch state). Selection rules:
-
-- **No auto-merge.** The orchestrator never merges a candidate
-  branch. Hard Floor per [`non-destructive-by-default`](../../rules/non-destructive-by-default.md) —
-  applies even under standing autonomy. ADR-005 records the reasoning.
-- **Ranked presentation.** Judge ranks candidates (1..N) with a
-  one-line justification per rank; user picks the winner.
-- **Loser worktrees stay.** The orchestrator does not delete losing
-  worktrees automatically — the user keeps the option to harvest a
-  partial idea before cleanup.
+### 8. do-with-live-app-judge (gated — UI-heavy tasks)
+
+Implementer ships the change AND starts the dev server; the judge drives
+the RUNNING app (Playwright / browser) against a written rubric, never
+reading the diff. Use for UI-heavy change where "looks right in the diff"
+≠ "works in the app"; not for backend/logic (a diff judge is cheaper).
+Experimental until `verdict_changed_outcome` telemetry proves it. Rubric,
+adoption gate, and the async-verifier future candidate →
+[`subagent-modes-detail`](../../agent-src/contexts/execution/subagent-modes-detail.md) § Mode 8.
 
 ## Status taxonomy — every subagent return uses one envelope
 
@@ -256,7 +265,7 @@ Each mode's literal dispatch template lives under
 matching prompt at dispatch time and substitutes `{{placeholders}}`.
 Edits to a prompt do not bloat this skill against the 400-line sunset
 trigger; `tests/test_subagent_prompt_loading.py` confirms each of the
-seven modes resolves to a loadable prompt that cites all four taxonomy
+eight modes resolves to a loadable prompt that cites all four taxonomy
 statuses.
 
 ## Procedure
@@ -285,7 +294,7 @@ same context, **stop** and report. Do not improvise.
 
 ### 3. Pick the mode
 
-Match task shape to one of the seven modes. When two modes could fit,
+Run the form gate first, then match task shape to one of the eight modes. When two modes could fit,
 prefer the cheaper one (`do-and-judge` < `do-and-judge-two-stage` <
 `do-in-steps` < `do-in-parallel` < `do-competitively` <
 `judge-with-debate` < `do-in-worktrees`).

package/dist/agent-src/skills/subagent-orchestration/evals/evals.json

@@ -0,0 +1,42 @@
+{
+    "skill": "subagent-orchestration",
+    "_calibration": "Golden E2E task 2 (road-to-fable-feedback-5 Phase 4c; council 2026-07-10 ranked bad-lite-output delegation second-highest signal/cost). Exercises the never-adopt-unverified Iron Law (delegation-policy) + the escalation path + the telemetry pairing (first_pass_success/escalated per orchestration-telemetry.md § Operationalization). Deterministic `contains` assertions pin the telemetry vocabulary; rubric pins the verification behavior. Baseline: authored 2026-07-10, pending first host-scored run.",
+    "scenarios": [
+        {
+            "id": "sao-bad-lite-output-escalation",
+            "prompt": "You are orchestrating: a lite-tier subagent was dispatched to implement `slugify(title: string): string` (lowercase, spaces to hyphens, strip non-alphanumerics, collapse repeated hyphens). Its return is: `export function slugify(title: string) { return title.toLowerCase().replace(' ', '-'); }` with no tests. Process this return per the orchestration contract and record the dispatch telemetry.",
+            "assertions": [
+                {
+                    "kind": "contains",
+                    "value": "first_pass_success"
+                },
+                {
+                    "kind": "contains",
+                    "value": "escalated"
+                },
+                {
+                    "kind": "rubric",
+                    "criterion": "The return is NOT adopted unverified: verification runs against the stated spec and catches at least two planted defects (String.replace with a string only replaces the FIRST space; non-alphanumerics are not stripped; repeated hyphens are not collapsed; no tests). The orchestrator never merges the defective return as-is."
+                },
+                {
+                    "kind": "rubric",
+                    "criterion": "After the verification failure the slice is re-dispatched on a higher tier (or corrected with the failure fed back), and the telemetry records escalated=true and first_pass_success=false per the operationalization table (business-logic rework counts as rework; formatting would not). The final adopted output satisfies the full spec."
+                }
+            ]
+        },
+        {
+            "id": "sao-good-return-no-spurious-escalation",
+            "prompt": "You are orchestrating: a lite-tier subagent was dispatched to rename the constant `MAX_RETRIES` to `MAX_ATTEMPTS` across a 3-file module. Its return is a diff renaming all 7 occurrences, all references updated, tests still green. Process this return per the orchestration contract and record the dispatch telemetry.",
+            "assertions": [
+                {
+                    "kind": "contains",
+                    "value": "first_pass_success"
+                },
+                {
+                    "kind": "rubric",
+                    "criterion": "Negative control: the clean return is verified and adopted WITHOUT rework or escalation — telemetry records first_pass_success=true and escalated=false. No spurious findings are invented to justify a re-dispatch."
+                }
+            ]
+        }
+    ]
+}

package/dist/agent-src/skills/systematic-debugging/SKILL.md

@@ -185,6 +185,16 @@ Pairs with [`context-hygiene § Read-Loop Detection`](../../rules/context-hygien
 6. **Full suite at the end, not between laps.** It is the gate, not
    the feedback loop.
 
+**Failure-signature triage — same taxonomy as [`context-hygiene § The 3-Failure Rule`](../../rules/context-hygiene.md#the-3-failure-rule).**
+The **failure signature** = **same target + same error class** (same failing test
++ same assertion, same lint rule id, same build error). **Same failure signature
+twice → stop and pivot** — don't spend the next lap on a near-identical retry; a
+repeated identical signature means the hypothesis is wrong, not under-applied. A
+**new error signature each attempt = progress** and the counter continues. The
+**hard-blocker classes** (missing credentials, permission denied, spend/quota/rate
+limit, external-service `5xx`) skip retries entirely — surface on first
+occurrence; another lap cannot fix them.
+
 **Anti-patterns this loop prevents:**
 
 * Editing source to make tests pass when the test was wrong (or

package/dist/agent-src/skills/systematic-debugging/evals/evals.json

@@ -0,0 +1,20 @@
+{
+  "skill": "systematic-debugging",
+  "_calibration": "Behavioural fixture (road-to-skill-eval-coverage Phase 2, default-surface). Deterministic assertions on a real output property where reliable; rubric pins the qualitative core as a known-limit (pass ratified in PR review, not a hidden judge). finding_floor n is a conservative floor, not a calibrated per-host number.",
+  "scenarios": [
+    {
+      "id": "debug-flaky-test",
+      "prompt": "A test passes locally but fails in CI intermittently. Walk me through debugging it.",
+      "assertions": [
+        {
+          "kind": "contains",
+          "value": "hypothesis"
+        },
+        {
+          "kind": "rubric",
+          "criterion": "Forms a hypothesis, isolates one variable, and runs one-test-one-fix-one-rerun rather than shotgun edits."
+        }
+      ]
+    }
+  ]
+}

package/dist/agent-src/skills/test-case-discovery/SKILL.md

@@ -0,0 +1,118 @@
+---
+model_tier: medium
+name: test-case-discovery
+description: "Use BEFORE writing any test — enumerate cases per behavior (happy / boundary / error / abuse), prioritize by likelihood × impact, cross-check via subagent — even if the user just says 'add tests'."
+domain: quality
+workspaces:
+  - engineering
+packs:
+  - engineering-base
+---
+
+# test-case-discovery
+
+AI-written test suites default to **too few tests, mostly happy path**. This skill is the discovery step that runs *before* the first test is written: enumerate what could break, pick the most important cases, then hand the list to [`test-driven-development`](../test-driven-development/SKILL.md) or the stack skill. The goal is **breadth AND quality** — happy path AND boundaries AND error paths — with a hard cap so the output is never a pile of trivial tests.
+
+This is the **before** layer. Assertion quality is [`testing-anti-patterns`](../testing-anti-patterns/SKILL.md); after-the-fact coverage review is [`judge-test-coverage`](../judge-test-coverage/SKILL.md).
+
+## When to use
+
+- About to write tests for new or changed behavior — the `test-driven-development` RED phase and `/tests create` route here as a mandatory first step.
+- A test task arrives as "add tests" / "write tests for this branch" with no case list.
+- Reviewing a plan whose testing section only names the happy path.
+
+Do NOT use when:
+
+- The diff is trivial (< 10 lines, pure rename/refactor, no new behavior) — write 1 happy + 1 boundary case and move on; no matrix.
+- The problem is assertion quality (overfit, tautology, mock-the-mock) → [`testing-anti-patterns`](../testing-anti-patterns/SKILL.md).
+- A test is failing for non-obvious reasons → [`systematic-debugging`](../systematic-debugging/SKILL.md).
+- The tests already exist and the question is "are they enough?" → [`judge-test-coverage`](../judge-test-coverage/SKILL.md).
+
+## The Iron Law
+
+```
+NO TEST IS WRITTEN BEFORE THE CASE LIST EXISTS.
+ENUMERATE → PRIORITIZE → THEN WRITE. NEVER HAPPY-PATH-ONLY.
+FLOOR PER BEHAVIOR: 1 HAPPY + 1 BOUNDARY + 1 ERROR (+1 ABUSE ON SECURITY PATHS).
+CAP PER BEHAVIOR: 5–8 CASES — EACH MUST FAIL FOR A DISTINCT REASON.
+```
+
+## Procedure — the five-step funnel
+
+### 1. Behavior inventory (30 seconds)
+
+List the 1–3 **distinct observable behaviors** the change introduces or modifies — one sentence each: *"When X happens, the system should do Y."* Each behavior gets its own case list. If you cannot state a behavior in one sentence, split it.
+
+### 2. Dimension scan (per behavior)
+
+Walk the dimensions below; mark **3–5 as HIGH** (most likely to occur × highest impact when wrong). Skip dimensions the behavior structurally cannot hit — but say so, don't silently omit.
+
+- **Input validity** — null/undefined, empty string/array, zero, negative, max bounds/overflow, type mismatch, malformed format, Unicode/whitespace, off-by-one.
+- **State** — missing prerequisites, invalid state transitions, idempotency/double-submit, duplicates and ordering.
+- **Collaborator failure** — timeout, 4xx/5xx, partial or malformed response, thrown exceptions, empty result sets.
+- **Concurrency & time** — races, retries, timezone/DST, clock skew (only when the surface touches them).
+- **Security surface** (authz / tenant / data access) — missing/expired credentials, not-owner, cross-tenant, privilege escalation, injection payload. On data-returning endpoints the three negative tests from `broken-access-control` (unauthenticated → 401, not-owner → 403/404, cross-tenant → 403/404) are the floor, not optional extras.
+
+### 3. Case synthesis
+
+Generate ≥ 1 concrete case per HIGH dimension, plus the happy path. Enforce the floor: **1 happy + 1 boundary + 1 error per behavior, +1 abuse case when the behavior is security-relevant.** Name each case like a test (`it rejects an expired token`), not like a category ("error handling").
+
+### 4. Subagent cross-check (gated, with mandatory fallback)
+
+Widen the list with a second pair of eyes:
+
+- **Subagent path** — when the host supports subagent spawn and subagents are enabled (`subagents.enabled`, `subagents.auto` ≠ off): spawn **one** subagent with an adversarial lens — *"Behavior: {sentence}. Case list so far: {list}. As a security researcher / SRE / chaos engineer: which non-obvious failure mode or abuse vector is missing?"* On security-critical surfaces a **second** subagent with a different lens is allowed; more is waste. Merge only novel cases.
+- **Degraded path (mandatory when no subagent runs)** — a self-review pass with an explicit lens shift: re-walk step 2 asking *"what breaks in production? what would an attacker try?"* and emit the same output shape (1–2 additional cases, or explicitly "none found").
+
+Unavailability of subagents never skips this step — it only switches the path.
+
+### 5. Prioritize and cap
+
+If a behavior collected more than 8 cases: rank by likelihood × blast radius, keep the top 5–8. Quality gate: **each surviving case must be able to fail for a distinct reason** (different code path / exception / assertion). The same assertion fed two interchangeable input values is ONE case — use a data provider, not a second test. Record dropped cases in one line each so the discovery work is not lost.
+
+Then hand the list to [`test-driven-development`](../test-driven-development/SKILL.md) — every case runs its own RED → GREEN cycle — or to the stack skill ([`pest-testing`](../pest-testing/SKILL.md), [`api-testing`](../api-testing/SKILL.md), [`playwright-testing`](../playwright-testing/SKILL.md)).
+
+## Output format
+
+1. The **case matrix** per behavior — case name → category (happy / boundary / error / abuse) → one-line why — in the reply or as a comment block atop the test file.
+2. The **floor check**, stated explicitly: `floor met: happy ✓ boundary ✓ error ✓ (abuse: n/a — no security surface)`.
+3. The **cross-check result**: which path ran (subagent + lens, or degraded self-review) and which cases it added — or explicitly "none".
+4. **Dropped/deferred cases** with a one-line reason each.
+
+## Gotcha
+
+- Line coverage lies — 100 % of lines with happy-path inputs still misses every boundary. Count **cases**, not lines.
+- The floor is per **behavior**, not per file — one boundary test in a 5-behavior file does not clear four other behaviors.
+- Enumeration is not an implementation license: the cap and [`testing-anti-patterns`](../testing-anti-patterns/SKILL.md) Anti-Pattern 6 still apply — 6 meaningful tests beat 20 trivial ones.
+- "No subagent available" is not "skip step 4" — the degraded self-review is mandatory and cheap.
+- A case list written *after* the tests is decoration — the funnel runs before the first RED.
+
+## Do NOT
+
+- Do NOT write the first test before the case list exists.
+- Do NOT stop after the happy-path case — the floor is 1 happy + 1 boundary + 1 error per behavior.
+- Do NOT pad the list with cases that fail for the same reason — data providers cover value variations.
+- Do NOT skip the step-4 cross-check because subagents are unavailable — run the degraded self-review.
+- Do NOT run the full funnel on trivial diffs — 1 happy + 1 boundary suffices there.
+- Do NOT drop enumerated cases silently — record them with a reason.
+
+## Auto-trigger keywords
+
+- test case discovery
+- what to test
+- test coverage plan
+- edge cases
+- boundary cases
+- happy path only
+- broad test coverage
+- case matrix
+- negative tests
+
+## See also
+
+- [`test-driven-development`](../test-driven-development/SKILL.md) — consumes the case list; one RED → GREEN cycle per case.
+- [`testing-anti-patterns`](../testing-anti-patterns/SKILL.md) — assertion-quality floor (overfit, tautology, gaming the green).
+- [`judge-test-coverage`](../judge-test-coverage/SKILL.md) — after-the-fact coverage review.
+- [`pest-testing`](../pest-testing/SKILL.md) · [`api-testing`](../api-testing/SKILL.md) · [`playwright-testing`](../playwright-testing/SKILL.md) — stack-specific execution.
+- Rule `senior-engineering-discipline` — the Iron-Law floor this procedure operationalizes.
+- Rule `broken-access-control` — the three negative tests on data-returning endpoints.

package/dist/agent-src/skills/test-case-discovery/evals/triggers.json

@@ -0,0 +1,52 @@
+{
+    "skill": "test-case-discovery",
+    "last_eval": "2026-07-10",
+    "description": "5 should-trigger + 5 should-not-trigger queries. Should-trigger covers DE + EN phrasings for pre-write test-case enumeration (what to test, edge cases, coverage breadth). Should-not-trigger covers near-miss neighbours: assertion quality (testing-anti-patterns), after-the-fact coverage review (judge-test-coverage), failing-test diagnosis (systematic-debugging), stack-specific execution.",
+    "queries": [
+        {
+            "q": "what should we test here — I don't want happy-path-only coverage",
+            "trigger": true
+        },
+        {
+            "q": "enumerate the edge cases for this endpoint before we write the tests",
+            "trigger": true
+        },
+        {
+            "q": "welche Testfälle brauchen wir für dieses Feature — auch Grenzfälle und Fehlerpfade?",
+            "trigger": true
+        },
+        {
+            "q": "build a case matrix for this behavior — happy, boundary, error, abuse",
+            "trigger": true
+        },
+        {
+            "q": "ask a subagent what else we could test so coverage is broad",
+            "trigger": true
+        },
+        {
+            "q": "this assertion looks tautological — is the test overfit?",
+            "trigger": false,
+            "note": "assertion quality → testing-anti-patterns"
+        },
+        {
+            "q": "are the tests on this finished diff enough?",
+            "trigger": false,
+            "note": "after-the-fact coverage review → judge-test-coverage"
+        },
+        {
+            "q": "this Pest test keeps failing and I don't understand why",
+            "trigger": false,
+            "note": "failing-test diagnosis → systematic-debugging"
+        },
+        {
+            "q": "how do I mock Http in a Laravel feature test?",
+            "trigger": false,
+            "note": "stack-specific execution → pest-testing"
+        },
+        {
+            "q": "schreib die Playwright-Specs für den Login-Flow, die Fälle stehen schon im Ticket",
+            "trigger": false,
+            "note": "case list already exists → playwright-testing executes it"
+        }
+    ]
+}

package/dist/agent-src/skills/test-driven-development/SKILL.md

@@ -92,7 +92,25 @@ State in one sentence: *"When X happens, the system should do Y."*
 If you cannot state it in one sentence, the scope is too big — split into
 multiple tests, each covering one sentence.
 
-### 2. Write the failing test first
+### 2. Enumerate the cases — discovery before writing (MANDATORY)
+
+Before the first test is written, run the
+[`test-case-discovery`](../test-case-discovery/SKILL.md) funnel for the
+behavior: dimension scan → case synthesis → optional subagent cross-check →
+prioritization. Do not proceed to step 3 with fewer than the floor:
+
+* **1 happy + 1 boundary + 1 error case per behavior** (+1 abuse case on
+  security-relevant paths).
+* Cap at 5–8 cases per behavior; each must be able to fail for a
+  **distinct** reason.
+* Trivial change (< 10 lines, pure refactor, no new behavior) → skip the
+  funnel; 1 happy + 1 boundary case suffices.
+
+Each case from the list then gets its own RED → GREEN cycle (steps 3–6).
+A behavior whose only test is the happy path is **not done** — it is the
+first item of an unfinished case list.
+
+### 3. Write the failing test first
 
 Write the smallest test that expresses the sentence from step 1.
 
@@ -101,7 +119,7 @@ Write the smallest test that expresses the sentence from step 1.
 * Real code paths, not mocks — mock only at I/O boundaries (HTTP, DB, time).
 * Use a descriptive name: `it_rejects_empty_email`, not `test_email_1`.
 
-### 3. Run the test and watch it fail
+### 4. Run the test and watch it fail
 
 Execute the single test (targeted, not the full suite):
 
@@ -120,7 +138,7 @@ Required observations **before proceeding**:
 * If the test passes immediately → it does not test what you think. Fix
   the test, do not start writing production code.
 
-### 4. Write minimum code to pass
+### 5. Write minimum code to pass
 
 Add **just enough** production code to make the test green. No extra
 features, no unrelated refactoring, no "while I'm here" cleanups.
@@ -129,7 +147,7 @@ If you feel the urge to add a parameter, edge case, or helper not covered
 by the current test — stop. That belongs in the next RED step, not this
 GREEN step.
 
-### 5. Run again and watch it pass
+### 6. Run again and watch it pass
 
 Re-run the same targeted command. Required:
 
@@ -137,7 +155,7 @@ Re-run the same targeted command. Required:
 * No previously green tests have turned red.
 * Test output is clean (no new warnings, deprecations, or noise).
 
-### 6. Refactor (only if green)
+### 7. Refactor (only if green)
 
 With all tests green, you may:
 
@@ -148,7 +166,7 @@ With all tests green, you may:
 Do **not** add new behavior during refactor — that needs its own failing
 test first. Re-run tests after the refactor to confirm still-green.
 
-### 7. Repeat for the next behavior
+### 8. Repeat for the next behavior
 
 Back to step 1 with the next single-sentence behavior.
 
@@ -260,6 +278,8 @@ wait for their own failing tests.
 
 * Do NOT write or modify production code before the failing test exists
   and has been observed to fail
+* Do NOT stop after the happy-path test — work through the enumerated
+  case list from step 2 (boundary, error, abuse where relevant)
 * Do NOT accept a test that never failed as evidence the code works
 * Do NOT bundle refactors into the GREEN step
 * Do NOT silence a flaky test — diagnose it, or delete it
@@ -274,6 +294,8 @@ wait for their own failing tests.
 
 ## When to hand over to another skill
 
+* Enumerating what to test before writing (case matrix, dimension scan,
+  subagent cross-check) → [`test-case-discovery`](../test-case-discovery/SKILL.md)
 * Project type-checker / linter / formatter (PHPStan, ECS, Rector for PHP — tsc / eslint / prettier for TS — ruff / mypy for Python) → [`quality-tools`](../quality-tools/SKILL.md)
 * Full Pest conventions and Laravel test helpers → [`pest-testing`](../pest-testing/SKILL.md)
 * Running tests inside Docker → [`tests-execute`](../tests-execute/SKILL.md)
@@ -285,6 +307,10 @@ wait for their own failing tests.
 Before marking TDD work complete:
 
 * [ ] Every new behavior has a test
+* [ ] The case list from step 2 exists and meets the floor (1 happy +
+  1 boundary + 1 error per behavior; abuse case on security paths)
+* [ ] Every enumerated case is either tested or recorded as dropped with
+  a one-line reason — no behavior ships happy-path-only
 * [ ] Each test was observed to fail first, with a matching failure message
 * [ ] The minimum code was written to turn each RED into GREEN
 * [ ] All targeted tests pass

package/dist/agent-src/skills/test-driven-development/evals/evals.json

@@ -0,0 +1,16 @@
+{
+  "skill": "test-driven-development",
+  "_calibration": "Behavioural fixture (road-to-skill-eval-coverage Phase 2, default-surface). Deterministic assertions on a real output property where reliable; rubric pins the qualitative core as a known-limit (pass ratified in PR review, not a hidden judge). finding_floor n is a conservative floor, not a calibrated per-host number.",
+  "scenarios": [
+    {
+      "id": "tdd-new-validator",
+      "prompt": "TDD a password-strength validator (min length, mixed case, a digit).",
+      "assertions": [
+        {
+          "kind": "rubric",
+          "criterion": "Writes a failing test FIRST (red), then the minimal code (green), then refactors — and covers boundary + negative cases, not only the happy path."
+        }
+      ]
+    }
+  ]
+}

package/dist/agent-src/skills/testing-anti-patterns/SKILL.md

@@ -31,6 +31,7 @@ still test-after-the-fact.
 Do NOT use when:
 
 - You need to *write* tests (no anti-pattern present yet) — route to [`pest-testing`](../pest-testing/SKILL.md) or [`test-driven-development`](../test-driven-development/SKILL.md).
+- You need to *enumerate* what to test before writing (case matrix, edge-case discovery) — route to [`test-case-discovery`](../test-case-discovery/SKILL.md).
 - The test failure is a real bug — route to [`systematic-debugging`](../systematic-debugging/SKILL.md).
 - You need overall coverage assessment of a finished diff — route to [`judge-test-coverage`](../judge-test-coverage/SKILL.md).
 
@@ -130,7 +131,7 @@ Gate: a feature is not complete until a failing-then-passing test cycle ran for
 
 ### Anti-Pattern 6 — Overfit / tautological assertions & unrealistic test data
 
-Symptom: the test passes only for one crafted input and proves nothing about the general rule — a hardcoded expected value the code always emits, a narrow regex pinned to a fixed date/id, or an assertion restating the seed. AI-written tests reach the same coverage as human tests but ~4× worse fault detection (weak-oracle): they execute the path, then assert something too weak to catch a bug. Same shape as mocking-the-mock — asserting on your own construction, not the system's behavior.
+Symptom: the test passes only for one crafted input and proves nothing about the general rule — a hardcoded expected value the code will always emit, a narrow regex pinned to a fixed date/id, or an assertion that restates the seed. AI-written tests reach the same coverage as human tests but ~4× worse fault detection (the weak-oracle problem): they execute the path and then assert something too weak to catch a bug. Same shape as mocking-the-mock — asserting on your own construction rather than the system's behavior.
 
 Gate:
 
@@ -141,7 +142,7 @@ BEFORE writing an assertion:
     STOP — derive the expected from the input, and add cases that vary it.
 ```
 
-Test-data realism — seeders/factories emit random data; the test derives its expectation from that data, never a hardcoded literal:
+Test-data realism — seeders/factories emit random data; the test derives its expectation from that data, never from a hardcoded literal:
 
 ```js
 // ❌ WRONG — hardcoded expectation, single happy case
@@ -160,11 +161,11 @@ expect((await api.get('/users/abc')).status).toBe(400)         // error: invalid
 expect([403, 404]).toContain((await api.get(`/users/${otherTenantUser.id}`)).status) // abuse: tenant isolation (404 hides existence)
 ```
 
-Deriving from seeded data is necessary but **not sufficient** — a test that only reads back the exact fields it seeded is still overfit (a code mutation survives it). A real test also exercises boundary (empty / null / max / Unicode), error (missing / invalid), and, on security-sensitive paths, an abuse case (IDOR, injection string, XSS payload). Coverage of *cases*, not just lines.
+Deriving from seeded data is necessary but **not sufficient** — a test that only reads back the exact fields it seeded is still overfit (a mutation in the code survives it). A real test also exercises boundary (empty / null / max / Unicode), error (missing / invalid), and, on security-sensitive paths, an abuse case (IDOR, injection string, XSS payload). Coverage of *cases*, not just lines.
 
 ### Anti-Pattern 7 — Gaming the green (test-integrity)
 
-Symptom: a test fails, and the "fix" edits the *test* instead of the code — `.skip` / `it.skip` / `xfail` / `@Disabled` on the failing case, deleting the failing assertion, loosening `toBe(x)` to `toBeTruthy()`, or rewriting `expected` to whatever the (possibly buggy) code now emits. The suite goes green while the behavior stays broken — worst outcome, because green now *hides* the bug. The automation-bias trap: under pressure to finish, optimize the signal (green) instead of the target (correct behavior).
+Symptom: a test fails, and the "fix" edits the *test* instead of the code — `.skip` / `it.skip` / `xfail` / `@Disabled` on the failing case, deleting the failing assertion, loosening `toBe(x)` to `toBeTruthy()`, or rewriting the `expected` value to whatever the (possibly buggy) code now emits. The suite goes green while the behavior stays broken — the worst outcome, because green now *hides* the bug. This is the automation-bias trap: under pressure to finish, the agent optimizes the signal (green) instead of the target (correct behavior).
 
 Gate:
 
@@ -184,7 +185,7 @@ Backstop grep — skip/xfail added to chase green (a hit in a diff that also "fi
 rg -n '\b(it|test|describe)\.skip\b|\.only\b|xit\(|xdescribe\(|@pytest\.mark\.(skip|xfail)|@Disabled|->markTestSkipped\(' .
 ```
 
-Test-surface instance of the `autonomous-execution` N=3 / allowlist-growth antipattern (bulk `skip`/`xfail` to force green = the tool is wrong, not the content) and the `verify-before-complete` floor (green must be *earned*, not manufactured).
+This is the test-surface instance of the `autonomous-execution` N=3 / allowlist-growth antipattern (bulk `skip`/`xfail` to force green counts as the tool being wrong, not the content) and the `verify-before-complete` floor (green must be *earned*, not manufactured).
 
 ## Output format
 
@@ -227,7 +228,7 @@ Test-surface instance of the `autonomous-execution` N=3 / allowlist-growth antip
 
 ## Provenance
 
-- Adopted from: an external reference (MIT, © 2025 an external reference).
+- Adopted from: an external reference (internal provenance, redacted).
 - Cross-linked: [`pest-testing`](../pest-testing/SKILL.md), [`test-driven-development`](../test-driven-development/SKILL.md), [`judge-test-coverage`](../judge-test-coverage/SKILL.md).
 - Provenance registry: `agents/settings/contexts/skills-provenance.yml` (entry: `testing-anti-patterns`).
 - Iron-Law floor: `verify-before-complete`, `skill-quality`, `senior-engineering-discipline`.

package/dist/agent-src/skills/threat-modeling/evals/evals.json

@@ -0,0 +1,21 @@
+{
+  "skill": "threat-modeling",
+  "_calibration": "Behavioural fixture (road-to-skill-eval-coverage Phase 2, default-surface). Deterministic assertions on a real output property where reliable; rubric pins the qualitative core as a known-limit (pass ratified in PR review, not a hidden judge). finding_floor n is a conservative floor, not a calibrated per-host number.",
+  "scenarios": [
+    {
+      "id": "threat-model-upload",
+      "prompt": "Threat-model a new file-upload endpoint that accepts user files.",
+      "assertions": [
+        {
+          "kind": "finding_floor",
+          "n": 3,
+          "pattern": "(?m)^\\s*[-*+]\\s+"
+        },
+        {
+          "kind": "rubric",
+          "criterion": "Enumerates concrete abuse cases (path traversal, SSRF via URL fetch, malicious file, authz bypass) and the missing control per case — not generic 'validate input'."
+        }
+      ]
+    }
+  ]
+}