@event4u/agent-config 8.9.0 → 8.10.0

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

@@ -0,0 +1,20 @@
+{
+  "skill": "scenario-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": "base-upside-downside",
+      "prompt": "Model base / upside / downside for our annual plan off a $6.3M commit.",
+      "assertions": [
+        {
+          "kind": "contains",
+          "value": "downside"
+        },
+        {
+          "kind": "rubric",
+          "criterion": "Downside names a concrete HEADWIND (not base×0.8), upside names a tailwind, and reads optionality — not just ±20% on base."
+        }
+      ]
+    }
+  ]
+}

package/dist/agent-src/skills/spreadsheet-authoring/SKILL.md

@@ -0,0 +1,98 @@
+---
+model_tier: high
+name: spreadsheet-authoring
+description: "Use when building or editing a spreadsheet or model — formulas over hardcoded values, read-back after writes, official-source data, pivot-first charts. Triggers on 'spreadsheet', 'build a model'."
+domain: process
+workspaces:
+  - finance
+packs:
+  - finance-basic
+trust:
+  level: professional
+install:
+  removable: true
+execution:
+  type: manual
+---
+
+# spreadsheet-authoring
+
+> The spreadsheet surface's correctness floor (per
+> [`surface-agent-contracts`](../../../docs/contracts/surface-agent-contracts.md)):
+> a spreadsheet's **truth source is the formula read-back**, not a plausible
+> table of numbers. A cell that holds a hardcoded computed value is a latent
+> lie — it silently goes stale the moment an input changes.
+
+## When to use
+
+- Building or editing a spreadsheet / financial model (SaaS, ops, budget, forecast).
+- Charting raw tabular data.
+- Entering web-sourced or financial figures into cells.
+
+Do NOT use for: per-customer unit-economics *reasoning* (route to
+`unit-economics-modeling`), runway *shape* (route to `runway-cognition`), or a
+prose document/table (that is the document surface, `doc-coauthoring`).
+
+## Procedure
+
+1. **Detect the surface + capability.** Confirm a spreadsheet is the right
+   surface (not a prose table). Confirm native spreadsheet tooling is available;
+   if not, see § Capability-aware degradation.
+2. **Formulas over hardcoded values.** Any computed cell holds a **formula**
+   (`=SUM(...)`, `=B2*C2`), never the typed-in result. Hardcoding a computed
+   value is the cardinal spreadsheet defect — it does not recalculate.
+3. **Read back after every write.** After writing a formula, read the cell back
+   and confirm no formula error (`#REF!`, `#DIV/0!`, `#VALUE!`). The read-back is
+   the spreadsheet's verification truth source.
+4. **Source-comment web-sourced cells.** Any figure taken from the web carries a
+   cell comment with its source. Financial figures follow the
+   [`spreadsheet-source-quality`](../../rules/spreadsheet-source-quality.md) rule
+   (official sources first; aggregators need permission + unofficial marking).
+5. **Expand ranges on structural edits.** After inserting a row/column inside a
+   formula's range, expand the range (or use a whole-column / table reference) so
+   the new data is included — verified by read-back.
+6. **Pivot-first charting.** Chart from a pivot/aggregate of raw data, not
+   directly from hundreds of raw transactional rows.
+7. **Bulk range operations over manual cell loops.** Prefer a single range
+   formula / fill over hand-editing cells one by one.
+
+## Capability-aware degradation
+
+- **Native tooling present** → write + read back formulas directly.
+- **Only exported files + a parser present** → operate on the exported file;
+  state that formulas were written into the export, and what the target app will
+  recompute on open.
+- **Neither** → do NOT pretend formulas were written or read back. Say plainly
+  what cannot be verified on this host, and deliver the formula definitions +
+  the layout as a durable plan the user applies in their spreadsheet app.
+
+## Output format
+
+1. **The spreadsheet / model** — cells carrying formulas (not baked values),
+   source comments on sourced cells, pivots feeding charts.
+2. **`assumptions.md`** — every input value, sourced or marked `assumption`;
+   the official-vs-unofficial status of each financial figure.
+3. **`verification-note.md`** — which cells were read back, any formula errors
+   found + fixed, and — on a degraded host — exactly what could not be verified.
+
+## Gotcha
+
+- Hardcoding a computed value instead of a formula is the #1 spreadsheet defect:
+  it looks right today and is silently wrong after the next input change.
+- A formula range not expanded after a row insert silently drops the new row
+  from every downstream total.
+- Charting straight off a raw transactional table (no pivot) produces an
+  unreadable chart and hides the data's real shape.
+- An aggregator/news figure entered as if it were official financial data is a
+  sourcing defect even when the number happens to be right — see
+  `spreadsheet-source-quality`.
+- On a host without spreadsheet tooling, claiming "formulas written + verified"
+  is a fabricated verification (never do it — degrade honestly).
+
+## Do NOT
+
+- Do NOT write a computed value where a formula belongs.
+- Do NOT enter a financial figure from an aggregator/news/social source as
+  official without the user's explicit permission + a cell-level unofficial mark.
+- Do NOT claim a formula was read back / verified on a host that cannot open the
+  spreadsheet — say what could not be verified instead.

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/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'."
+        }
+      ]
+    }
+  ]
+}

package/dist/agent-src/skills/typography-system/evals/evals.json

@@ -0,0 +1,14 @@
+{
+  "skill": "typography-system",
+  "_calibration": "Behavioural fixtures (road-to-skill-eval-coverage Phase 2, rich set). Deterministic `contains` asserts the line-height output the skill produces; the rubric checks the scale is a computed modular scale (from the given ratio), not arbitrary px — the whole point of the skill.",
+  "scenarios": [
+    {
+      "id": "modular-scale-from-ratio",
+      "prompt": "Build a type scale from a 16px base and a 1.25 modular ratio: give the step sizes, line-heights, and weights for body, h3, h2, h1.",
+      "assertions": [
+        { "kind": "contains", "value": "line-height" },
+        { "kind": "rubric", "criterion": "The step sizes are the 1.25 modular scale off 16px (≈16/20/25/31px), i.e. computed from the ratio, not arbitrary round numbers; each step carries a line-height and weight." }
+      ]
+    }
+  ]
+}

package/dist/agent-src/skills/unit-economics-modeling/evals/evals.json

@@ -0,0 +1,24 @@
+{
+  "skill": "unit-economics-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": "saas-unit-economics",
+      "prompt": "SaaS: ARPA $500/mo, gross margin 80%, monthly churn 2%, fully-loaded CAC $2000. Are we unit-economic?",
+      "assertions": [
+        {
+          "kind": "contains",
+          "value": "LTV"
+        },
+        {
+          "kind": "contains",
+          "value": "CAC"
+        },
+        {
+          "kind": "rubric",
+          "criterion": "Computes LTV=ARPA·GM/churn (=20000), CAC payback=CAC/(ARPA·GM) (=5mo), and LTV:CAC (=10) with the SaaS formulas; states the payback + ratio, not one number."
+        }
+      ]
+    }
+  ]
+}

package/dist/agent-src/skills/verify-completion-evidence/evals/evals.json

@@ -0,0 +1,16 @@
+{
+  "skill": "verify-completion-evidence",
+  "_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": "is-this-done",
+      "prompt": "I think the feature is done — the code looks right. Can we close it?",
+      "assertions": [
+        {
+          "kind": "rubric",
+          "criterion": "Refuses to claim done without fresh verification evidence (a run/test), not an eyeball of the code — names the exact command that would prove it."
+        }
+      ]
+    }
+  ]
+}

package/dist/agent-src/skills/vision-articulation/evals/evals.json

@@ -0,0 +1,16 @@
+{
+  "skill": "vision-articulation",
+  "_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": "articulate-vision",
+      "prompt": "Articulate our product vision.",
+      "assertions": [
+        {
+          "kind": "rubric",
+          "criterion": "States the bet in one sentence, why-now/why-us with evidence, and a counter-case — not an unopposed aspiration."
+        }
+      ]
+    }
+  ]
+}