@event4u/agent-config 9.8.0 → 9.9.0

package/dist/agent-src/skills/react-shadcn-ui/SKILL.md

@@ -100,8 +100,8 @@ Do NOT use when:
   [`docs/guidelines/design-antipatterns.md`](../../../docs/guidelines/design-antipatterns.md)
   before the polish step (Visual V1–V7, Layout L1–L8 are the React-component
   slop tells); the objective quality floors (WCAG contrast, focus-visible,
-  reduced-motion) are CI-enforced by
-  [`lint_design_quality`](../../../src/scripts/lint_design_quality.ts).
+  reduced-motion) are validated via `accessibility-auditor`'s checklist —
+  cite its verdict rather than eyeballing.
 
 ## Covered primitives
 

package/dist/agent-src/skills/recursive-verification/SKILL.md

@@ -41,6 +41,12 @@ Land a verified result by running a depth-bounded
 the only compute knob, every level budgeted, and the loop default-off
 until a benchmark gate authorises it per host.
 
+> **Disposition (2026-07-28, honest null — TERMINAL).** Recursive-verification
+> benchmark resolved as published null (no measured lift over single-pass
+> verification; see `docs/benchmark.md`). `verification.recursive` stays
+> default-off bound to that null; removal at next major unless external
+> evidence appears first. NOT sold as a quality-lift mechanism.
+
 ## The Iron Law
 
 ```

package/dist/agent-src/skills/refine-ticket/SKILL.md

@@ -182,9 +182,9 @@ naming (e.g. `feat/` vs `fix/` vs `refactor/` prefix), and
 risks instead of inventing terms.
 
 The match lists and `require_count` thresholds are owned by
-`detection-map.yml` — edit the map, not this skill. Tests:
-[`tests/scripts/refine_ticket_detect.test.ts`](../../../tests/scripts/refine_ticket_detect.test.ts)
-(DE + EN fixtures, repo-aware + graceful-degrade coverage).
+`detection-map.yml` — edit the map, not this skill (DE + EN fixtures,
+repo-aware + graceful-degrade coverage are regression-locked in this
+package's own test suite).
 
 ### 3. Orchestrate
 

package/dist/agent-src/skills/roadmap-writing/SKILL.md

@@ -301,6 +301,10 @@ to every roadmap you author.
    behind the scope? `## Provenance` block with `ENC1:` link? inlined
    council convergence? anti-dump acceptance criterion? (Internally
    originated → these must be **absent**, not empty.)
+8. *Inbox-sourced only:* roadmap consumed an `agents/tmp/` file as input →
+   file moved to `agents/tmp.old/<name>` in the SAME reply, Source line
+   pointing at the `tmp.old/` path? (Per `agents-layout § User Inbox
+   Workflow`. Move only the named input file(s); never sweep the inbox.)
 
 ## Do NOT
 

package/dist/agent-src/skills/rtk-output-filtering/SKILL.md

@@ -1,7 +1,7 @@
 ---
 model_tier: medium
 name: rtk-output-filtering
-description: "Use when running verbose CLI commands — wraps them with rtk (Rust Token Killer) for 60-90% token savings. Covers installation, configuration, and usage patterns."
+description: "Use when running verbose CLI commands — wraps them with rtk (Rust Token Killer, third-party Apache-2.0; upstream reports 60-90% token savings). Covers installation, configuration, and usage patterns."
 domain: process
 execution:
   type: assisted
@@ -23,9 +23,17 @@ packs:
 
 ## What
 
-High-performance CLI proxy that reduces LLM token consumption by 60-90%
-on common dev commands through intelligent output filtering (whitespace, boilerplate,
+High-performance CLI proxy that reduces LLM token consumption on common dev
+commands through intelligent output filtering (whitespace, boilerplate,
 comments, duplicate log messages). Single Rust binary, <10ms startup overhead.
+**Third-party Apache-2.0 tool** (rtk-ai upstream — an external project, not part of this package).
+
+**Savings, honestly stated:** upstream reports 60-90% (their estimate —
+"actual savings vary"). agent-config's own scoped spot-measurement
+(2026-07-28, one repo, one macOS machine, 8-command corpus) landed at
+**33% overall, 0-57% per command** — verbose commands (`git status`,
+`git log`, `ls -la`) save ~55%, already-compact output (`--oneline`,
+`--stat`) passes through at ~0%. See `internal/bench/rtk-savings/RESULTS.md`.
 
 **Docs:** https://www.mintlify.com/rtk-ai/rtk
 **Repo:** https://github.com/rtk-ai/rtk
@@ -34,9 +42,9 @@ comments, duplicate log messages). Single Rust binary, <10ms startup overhead.
 
 Wrap any CLI command with `rtk`:
 ```bash
-rtk git status        # 80-92% savings
-rtk git log           # compact log output
-rtk cargo test        # 90% savings — only failures shown
+rtk git status        # verbose status → compact (measured ~55% here)
+rtk git log           # compact log output (measured ~55% here)
+rtk cargo test        # upstream: only failures shown
 rtk npm test          # same for JS/TS
 rtk docker compose ps # compact container status
 ```
@@ -70,12 +78,23 @@ outside onboarding, follow the Installation section below and set
 
 ## Installation (on-demand)
 
-Invoked by `/onboard` when rtk is not on `PATH`, or on explicit user
-request. Never fire unsolicited.
-
-1. Ask which installer to use (macOS → Homebrew; otherwise Cargo).
-2. Run the installer. On success:
-   1. `rtk --version` to verify.
+Invoked when rtk is not on `PATH` and the user explicitly asks to install
+it. Never fire unsolicited.
+
+1. Offer the verified per-OS install path (same map as
+   `src/install/rtkDetection.ts` / `docs/contracts/rtk-detection.md`):
+   - macOS → `brew install rtk` (official homebrew-core formula)
+   - Linux → `curl -fsSL https://raw.githubusercontent.com/rtk-ai/rtk/master/install.sh | sh`
+     (installs to `~/.local/bin`)
+   - Windows → `winget install rtk-ai.rtk` (plus the documented ripgrep
+     dependency: `winget install BurntSushi.ripgrep.MSVC`); winget-less
+     images use the upstream `rtk-x86_64-pc-windows-msvc.zip` release.
+   **NEVER `cargo install rtk`** — the bare crates.io `rtk` crate is the
+   unrelated Rust Type Kit, not Rust Token Killer.
+2. Run the installer only on explicit confirmation. On success:
+   1. `rtk gain` to verify IDENTITY (the savings dashboard prints "RTK
+      Token Savings" only on Rust Token Killer — `rtk --version` cannot
+      distinguish the two same-name tools).
    2. `rtk init --global` to enable auto-rewrite hooks.
    3. Apply **Post-Install Setup** below (telemetry, tee, audit logging).
    4. Generate project-local filters (see Post-Install Setup).

package/dist/agent-src/skills/rule-refactor/SKILL.md

@@ -80,13 +80,13 @@ For each approved verdict:
 
 * **merge** → rewrite the surviving rule to cover both domains;
   delete the absorbed one; update any `routes_to:` references.
-* **delete** → remove the file from `.agent-src.uncondensed/rules/`
+* **delete** → remove the file from `src/rules/`
   and the corresponding `dist/agent-src/rules/` projection.
 * **move-to-context** → extract the body into
-  `.agent-src.uncondensed/contexts/<area>/<name>.md`, replace the
+  `src/agent-src/contexts/<area>/<name>.md`, replace the
   rule body with the obligation + a `load_context:` pointer.
 * **promote-to-skill** → create
-  `.agent-src.uncondensed/skills/<name>/SKILL.md`, replace the rule
+  `src/skills/<name>/SKILL.md`, replace the rule
   with an auto-trigger stub that routes to it (or delete the rule
   entirely if the skill's own trigger suffices).
 

package/dist/agent-src/skills/schema-review/SKILL.md

@@ -0,0 +1,92 @@
+---
+model_tier: medium
+name: schema-review
+description: "Use when reviewing a migration diff or schema change for scale hazards — indexes, unsafe migrations, unbounded growth, N+1. Triggers on 'review this migration', 'will this scale'."
+domain: engineering
+workspaces:
+  - engineering
+packs:
+  - scale-discipline
+trust:
+  level: professional
+install:
+  default: false
+  removable: true
+---
+
+# schema-review
+
+## When to use
+
+- A migration diff, new migration file, or schema change is under review
+  and the question is scale-shaped: indexes, reversibility, growth,
+  query patterns against the new columns.
+- The user asks "will this scale", "review this migration", "check the
+  schema", or a PR touches `migrations/`, `schema.prisma`, or raw `.sql`
+  migration files.
+- NOT for runtime performance analysis of live traffic (no APM here —
+  route to `performance-analysis`) and NOT for authoring a new migration
+  from scratch (route to `laravel-migration` or the stack-native tool,
+  then come back with the diff).
+
+## Procedure
+
+1. **Detect the stack surface** in the diff: Laravel migrations
+   (`database/migrations/*.php`), Prisma (`schema.prisma` +
+   `prisma/migrations/**/migration.sql`), raw SQL (`*.sql`). One diff can
+   carry several.
+2. **Run the deterministic linter** on the touched files plus the query
+   surface that references the changed tables:
+
+   ```bash
+   npx tsx node_modules/@event4u/agent-config/src/scripts/lint_persistence.ts -- --dir <path> [--stack eloquent|prisma|raw-sql] --format json
+   ```
+
+   The linter emits `gate` findings (pattern-detected: F1 N+1, F2
+   index-parity, F3 unbounded reads, F6 migration-safety, F7
+   growth-budget, F8 audit-coverage, F9 sync-in-handler, F11 non-durable
+   async) and `advice` findings (heuristics — never treat as blockers).
+3. **Walk the gap table** — for every `gate` finding decide: fix, or
+   waiver with a reason (`// no-index: <reason>`, `// sync-required:
+   <reason>`, `-- no-retention: <reason>`, …). An empty waiver reason is
+   itself a finding.
+4. **Check the R-A6/R-A7 invariants by hand** where the linter is blind:
+   reversibility of data transformations, retention policy for any new
+   append-only table (the `-- retention: <policy>` line), backfill plan
+   for new NOT NULL columns on large tables.
+5. **Report waiver density neutrally** — count waivers per rule; state
+   both readings (informed exceptions vs rule misfit) and let the human
+   decide. Density alone is never a verdict.
+
+## Output
+
+The review MUST contain:
+
+1. **Gap table** — one row per finding: `rule · file:line · finding ·
+   proposed action (fix | waiver | accepted)`, gate findings first,
+   advice findings clearly marked as advice.
+2. **Waiver-density line** — `N waivers across M findings` with the
+   two-reading note (informed exceptions vs rule misfit).
+3. A one-line verdict: ready / needs fixes / needs human schema decision
+   — never a bare "looks good" without the table.
+
+## Gotcha
+
+- The linter proves **pattern presence**, not instance-level correctness
+  — a flagged `Http::` call in a controller may be legitimately sync
+  (then it gets a `// sync-required:` waiver with a reason), and a clean
+  run does not prove the schema scales. Say what was checked, not more.
+- Prisma's `@relation` fields are indexed implicitly on some connectors
+  and not on others — when the linter reports a missing FK index on a
+  Prisma model, verify the connector before calling it a defect.
+
+## Do NOT
+
+- Do NOT gate a review on `advice`-tier findings (F4 denormalization,
+  F10 event-decoupling heuristics) — they are review inputs, not
+  blockers.
+- Do NOT strip or rewrite existing waivers — surface stale-looking ones
+  and ask.
+- Do NOT invent index recommendations for columns the query surface
+  never filters or orders by — index parity cuts both ways; unused
+  indexes cost write throughput.

package/dist/agent-src/skills/schema-review/evals/triggers.json

@@ -0,0 +1,17 @@
+{
+    "skill": "schema-review",
+    "last_eval": "2026-07-27",
+    "description": "5 should-trigger + 5 should-not-trigger. Should-trigger covers DE+EN phrasings for reviewing a migration/schema diff for scale hazards. Should-not-trigger covers near-miss neighbours: authoring a migration (laravel-migration), live-traffic performance (performance-analysis), audit-tier selection (history-design), generic code review.",
+    "queries": [
+        { "q": "review this migration for missing indexes before I merge", "trigger": true },
+        { "q": "will this schema change scale to 100k rows?", "trigger": true },
+        { "q": "prüfe meine Migration auf Skalierungsprobleme", "trigger": true },
+        { "q": "check the new schema.prisma diff for unsafe changes", "trigger": true },
+        { "q": "does this ALTER TABLE need CONCURRENTLY and a default?", "trigger": true },
+        { "q": "create a migration that adds a status column to orders", "trigger": false },
+        { "q": "the dashboard endpoint is slow in production, profile it", "trigger": false },
+        { "q": "which audit log mechanism should we use for tenants?", "trigger": false },
+        { "q": "review my pull request for code quality", "trigger": false },
+        { "q": "wie lege ich einen Index in MySQL an?", "trigger": false }
+    ]
+}

package/dist/agent-src/skills/secrets-management/SKILL.md

@@ -104,14 +104,13 @@ Telemetry / APM     → strip from request/response captures; allowlist headers.
 The scanning gates (Step 4) are the CI/pre-commit nets. The **earliest** gate is
 the agent itself: before it writes a credential into a tracked file or stages a
 commit, the [`secret-vcs-guard`](../../rules/secret-vcs-guard.md) rule runs the
-`secret_detector` library (`src/scripts/_lib/secret_detector.ts`) and, on a hit,
+`secret_detector` library and, on a hit,
 STOPS → shows the match (`file:line` · kind · masked · why) → asks via numbered
 options → offers the tiered alternative below. It never silently commits and
 never silently strips. VCS-agnostic: the same detector runs against the diff for
 git, SVN, and Mercurial (SVN/hg native hooks are server-side, a stronger but
-later net). The deterministic CI backstop is `check_secret_leak`
-(`src/scripts/check_secret_leak.ts`) — the agent gate is one layer, not the whole
-defense.
+later net). The deterministic CI backstop is `check_secret_leak` — the agent
+gate is one layer, not the whole defense.
 
 **False positives — audited allowlist, never a global mute.** Suppress a
 confirmed non-secret with an inline `# secret-allow` marker on the line, or a

package/dist/agent-src/skills/security-audit/SKILL.md

@@ -148,7 +148,7 @@ After findings, add **Rejected candidates** section: one line per look-dangerous
 ## Gotcha
 
 - Don't report theoretical vulnerabilities without a concrete attack vector — false positives erode trust.
-- The model tends to flag framework-handled security as issues (e.g., Laravel's CSRF is already handled).
+- The model tends to flag framework-handled security as issues (e.g., Laravel's CSRF or Rails' `protect_from_forgery` is already handled).
 - Always check if a finding is already mitigated by middleware or configuration before reporting it.
 
 ## Do NOT

package/dist/agent-src/skills/security-maturity-assessment/SKILL.md

@@ -55,7 +55,7 @@ Do NOT use when:
 
 1. **Scope** — name the module/paths under assessment; list entry points (routes, jobs, commands, webhooks). Scorecard without stated scope is not reproducible.
 2. **Assess each category** — inspect the code the category names. Every rating cites evidence:
-   - Positive evidence: `file:line` of the control (`app/Http/Requests/…:12`).
+   - Positive evidence: `file:line` of the control (`app/Http/Requests/…:12`, `src/guards/auth.guard.ts:12`).
    - Absence evidence: the searches run that came back empty (name the grep patterns) — "not found" beats "probably missing".
    - Multi-tenant N/A: single-tenant systems rate category 8 `N/A`; drops out of the roll-up.
 3. **Roll up deterministically** — overall rating is computed, not vibed:

package/dist/agent-src/skills/skill-improvement-pipeline/SKILL.md

@@ -115,8 +115,8 @@ Decide what to create:
 > the exact wording is recoverable, and verify against it rather than trusting
 > the summary.
 
-- **New rule** → create in `.agent-src.uncondensed/rules/`, follow rule conventions
-- **New skill** → use `skill-writing` skill, create in `.agent-src.uncondensed/skills/`
+- **New rule** → create in `src/rules/`, follow rule conventions
+- **New skill** → use `skill-writing` skill, create in `src/skills/`
 - **Update existing** → use `skill-management` skill
 
 After creation:
@@ -175,7 +175,7 @@ Ask the user:
 - Do NOT skip the promotion gate — it prevents skill/rule bloat
 - Do NOT create both a rule AND a skill for the same learning
 - Do NOT auto-push without user permission
-- Do NOT create project-specific content in `.agent-src.uncondensed/`
+- Do NOT create project-specific content in `src/`
 - Do NOT run this pipeline for trivial learnings
 
 ## References

package/dist/agent-src/skills/skill-writing/SKILL.md

@@ -189,7 +189,7 @@ approval-gated propose / pick loop with at most two rounds.
 ### 1c. Propose a trigger-eval stub (new skills only)
 
 When creating a new skill, propose a stub
-`.agent-src.uncondensed/skills/{name}/evals/triggers.json` before writing
+`src/skills/{name}/evals/triggers.json` before writing
 the body. Draw the queries from Phase A of the drafting protocol (the
 user's "should trigger" and "must not trigger" answers).
 
@@ -531,7 +531,7 @@ content).
 
 ## Do NOT
 
-* Write documentation-style, pointer-only, or too-broad skills ("Laravel skill")
+* Write documentation-style, pointer-only, or too-broad skills ("Laravel skill", "Django skill")
 * Skip Procedure or use vague validation
 * Exceed size limits (see `docs/guidelines/agent-infra/size-and-scope.md`)
 * Duplicate rules

package/dist/agent-src/skills/source-discovery/SKILL.md

@@ -38,9 +38,9 @@ discover the real source  →  Evidence Report (Verified / Assumed / Gaps)  →
 Scaffold the report cheaply so it never gets skipped:
 
 ```bash
-./scripts-run src/scripts/evidence_report git-state            # fail-fast: abort if a rebase/merge/cherry-pick is in progress
-./scripts-run src/scripts/evidence_report init --task "<task>" # writes the gitignored session report
-./scripts-run src/scripts/evidence_report add --bucket verified --claim "users.email is unique" --source "db/schema/users.sql:23"
+npx tsx node_modules/@event4u/agent-config/src/scripts/evidence_report.ts git-state            # fail-fast: abort if a rebase/merge/cherry-pick is in progress
+npx tsx node_modules/@event4u/agent-config/src/scripts/evidence_report.ts init --task "<task>" # writes the gitignored session report
+npx tsx node_modules/@event4u/agent-config/src/scripts/evidence_report.ts add --bucket verified --claim "users.email is unique" --source "db/schema/users.sql:23"
 ```
 
 **Provenance on every item** (`observed_at` / `source` / `version`). Within a
@@ -175,10 +175,10 @@ the per-session Evidence Report above. Append to the knowledge intake —
 never write a tracked page mid-task:
 
 ```bash
-./scripts-run src/scripts/emit_knowledge_event --type api_shape_learned \
+npx tsx node_modules/@event4u/agent-config/src/scripts/emit_knowledge_event.ts --type api_shape_learned \
     --endpoint "<path>" --method "<verb>" --request-schema '<json>' --response-schema '<json>'
 
-./scripts-run src/scripts/emit_knowledge_event --type convention_detected \
+npx tsx node_modules/@event4u/agent-config/src/scripts/emit_knowledge_event.ts --type convention_detected \
     --pattern "<pattern>" --evidence "file:line" --sample-size <N> --scope project
 ```
 

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

@@ -111,6 +111,15 @@ Rules:
   or `none`) so the gate's value is measurable inside the ADR-117
   prove-or-drop window.
 
+## Severity-conditioned team composition — conditions pattern
+
+Incident-style severity tiers (Critical / High / Medium / Low) refine
+composition and activation **within** the form the static gate already
+picked — severity never overrides the form gate, the Iron Law, or any
+safety floor. Guidance, not a new object class (persona-catalog
+disposition). Severity→composition table + escalation rule →
+[`subagent-modes-detail` § Severity-conditioned team composition](../../agent-src/contexts/execution/subagent-modes-detail.md).
+
 ## The nine modes
 
 Each mode has a decision row: when to use, when not, and the expected
@@ -124,42 +133,23 @@ glossary) lives in
 [`subagent-topologies`](../../agent-src/contexts/execution/subagent-topologies.md) —
 pull it for capacity planning; it is metadata, not runtime-enforced.
 
+Per-mode decision rows (when to use / when not / model pairing) and the
+mode-2 stage-routing contract live in
+[`subagent-modes-detail` § Modes 1–6](../../agent-src/contexts/execution/subagent-modes-detail.md) —
+pull them at dispatch time.
+
 ### 1. do-and-judge
 
 Implementer produces a diff; judge reviews; loop applies, revises, or
 hands off. Hard ceiling: **two revision cycles**, then stop and hand
 back to the user.
 
-| When to use | When not | Model pairing |
-|---|---|---|
-| Single-change task with non-trivial risk | Tiny fix, or spike/exploration | implementer = session; judge = one tier up |
-
 ### 2. do-and-judge-two-stage
 
-Implementer produces a diff; **two judges run sequentially** — first a
-spec-compliance reviewer (does the diff satisfy the stated spec /
-acceptance criteria?), then a code-quality reviewer (is the diff well-
-written for the codebase it lands in?). The orchestrator only proceeds
-to stage two if stage one returns `DONE` or `DONE_WITH_CONCERNS`. A
-stage-one `BLOCKED` shortcuts the loop — there is no point quality-
-reviewing a diff that does not satisfy the spec.
-
-| When to use | When not | Model pairing |
-|---|---|---|
-| Spec is contested or AC are detailed; diff size makes one judge prone to missing one axis (correctness vs craft) | Spec is one sentence, or the diff is one line (collapse to mode 1) | implementer = session; spec-judge = one tier up; quality-judge = same tier as spec-judge, fresh context |
-
-**Why two stages, not one judge with both rubrics:** combining the
-rubrics in one prompt reliably regresses one of them — the judge "spends
-attention" on whichever rubric appears last. Splitting the prompts
-forces each judge to commit fully to its rubric.
-
-**Stage-routing rule:**
-- Stage-1 returns `DONE` → run stage-2.
-- Stage-1 returns `DONE_WITH_CONCERNS` → run stage-2; concerns carry
-  forward to the final envelope.
-- Stage-1 returns `NEEDS_CONTEXT` → pause; stage-2 does not run.
-- Stage-1 returns `BLOCKED` → final verdict is `BLOCKED`; stage-2
-  does not run (saves cost).
+Implementer produces a diff; **two judges run sequentially** — spec
+compliance first, code quality second. Stage-one `BLOCKED` shortcuts the
+loop (no point quality-reviewing a diff that misses the spec). Stage
+routing + why-two-stages rationale → modes-detail § Mode 2.
 
 ### 3. do-in-steps
 
@@ -167,40 +157,24 @@ Plan is split into N steps; judge runs **between** steps. A step that
 fails judgment is revised before the next step starts. Used for
 multi-file changes where a mid-plan mistake would cascade.
 
-| When to use | When not | Model pairing |
-|---|---|---|
-| Multi-step plan with ordered dependencies | Single-step change, or when steps are independent (use `do-in-parallel`) | implementer = session; judge = one tier up |
-
 ### 4. do-in-parallel
 
 Independent slices run concurrently. No judge per slice — judge runs
 once on the aggregated result. Parallelism capped by
 `subagents.max_parallel` in `.agent-settings.yml`.
 
-| When to use | When not | Model pairing |
-|---|---|---|
-| Independent slices (different files, non-overlapping) | Any slice touches shared state | implementer = session; judge = one tier up, run once |
-
 ### 5. do-competitively
 
 Multiple implementers produce candidate diffs for the **same** slice.
 Judge picks the winner and rejects the losers. Expensive — use only
 when the solution space is genuinely broad.
 
-| When to use | When not | Model pairing |
-|---|---|---|
-| Broad solution space (algorithm choice, API shape) | Well-defined problem with one good answer | implementers = same tier (≥2 instances); judge = one tier up |
-
 ### 6. judge-with-debate
 
 Two judges each produce a verdict; a meta-judge reconciles
 disagreements. Used for high-stakes changes (security, data
 migration, public API) where a single judge is too easy to fool.
 
-| When to use | When not | Model pairing |
-|---|---|---|
-| Security, data integrity, public API change | Routine internal refactor | judges = same tier (2x); meta-judge = one tier up |
-
 Mode 6 = **go/no-go** (strict-er verdict wins); for defect-FINDING coverage (the
 *union* of what diverse models catch) use Mode 9.
 
@@ -238,34 +212,25 @@ opt-in high-risk changes only; registered claim + high-risk tier need
 cross-*vendor* skeptics. Invariants, skeptic prompt, reconciliation, prove-or-drop
 gate → [`subagent-modes-detail`](../../agent-src/contexts/execution/subagent-modes-detail.md) § Mode 9
 + [`prompts/adversarial-verification-council.md`](prompts/adversarial-verification-council.md)
+
+> **Disposition (2026-07-28, honest null).** Adversarial-council
+> finding-coverage benchmark resolved as published null (`docs/benchmark.md`)
+> — mode NOT sold as defect-detection capability. Stays default-off bound to
+> that null; removal at next major unless external evidence (consumer-filed
+> case where the panel surfaced a real defect the single verifier missed)
+> appears first. Remaining honest value: perspective diversity + decision
+> documentation, nothing more.
 (ADR-122).
 
 ## Status taxonomy — every subagent return uses one envelope
 
 Every implementer or judge return must conform to
-[`schemas/subagent-status.json`](schemas/subagent-status.json). Four
-statuses, no free-form alternatives:
-
-| Status | Meaning | Required keys (beyond `status`, `summary`) |
-|---|---|---|
-| `DONE` | Work shipped, all gates green. | `evidence[]` |
-| `DONE_WITH_CONCERNS` | Work shipped but caller must act on concerns. | `evidence[]`, `concerns[]` |
-| `NEEDS_CONTEXT` | Paused; caller can unblock by answering. | `blocking_question` |
-| `BLOCKED` | No path forward exists. | `blocking_reason` |
-
-**Why a fixed taxonomy:** orchestrators (`/do-and-judge`, `/do-in-steps`)
-route on status. Free-form "kind of done" returns force the orchestrator
-to interpret prose, which silently regresses the two-revision ceiling and
-the judge-rejected-do-not-apply rule. The schema makes routing mechanical.
-
-**Tests:** `tests/test_subagent_status_schema.py` exercises all four
-statuses plus rejection cases (missing required keys, unknown status,
-extra fields, conditional-key violations).
-
-**Distinguishing `NEEDS_CONTEXT` from `BLOCKED`:** `NEEDS_CONTEXT` means
-*"you, the caller, can fix this by telling me X"*. `BLOCKED` means
-*"no input from you unblocks this — escalate or rescope"*. If a subagent
-is unsure, it picks `BLOCKED` and the caller can downgrade.
+[`schemas/subagent-status.json`](schemas/subagent-status.json). Exactly
+four statuses — `DONE` · `DONE_WITH_CONCERNS` · `NEEDS_CONTEXT` ·
+`BLOCKED` — no free-form alternatives; orchestrators route on status
+mechanically. Meaning/required-keys table, why-fixed rationale, and the
+`NEEDS_CONTEXT`-vs-`BLOCKED` distinction →
+[`subagent-modes-detail` § Status taxonomy](../../agent-src/contexts/execution/subagent-modes-detail.md).
 
 ## Dispatch prompts — externalized
 
@@ -273,9 +238,12 @@ Each mode's literal dispatch template lives under
 [`prompts/{mode}.md`](prompts/README.md). The orchestrator loads the
 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
-nine modes resolves to a loadable prompt that cites all four taxonomy
-statuses.
+trigger. Eight prompt files cover modes 1–7 and 9 (the standalone judge
+reuses [`prompts/do-and-judge.md`](prompts/do-and-judge.md); mode 8's
+live-app rubric lives in
+[`subagent-modes-detail` § Mode 8](../../agent-src/contexts/execution/subagent-modes-detail.md));
+each prompt cites all four taxonomy statuses — see
+[`prompts/README.md`](prompts/README.md).
 
 ## Procedure
 
@@ -339,21 +307,13 @@ the judge verdict.
 
 ### 6. Emit telemetry
 
-After every auto-dispatched run, write one telemetry line to
-`agents/runtime/state/audit/YYYY-MM.jsonl` (current UTC month — use
-`new Date().toISOString().slice(0, 7)` to compute the filename).
-The line is a standard audit-log-v1 object with `input_kind:
-"orchestration"` and an `orchestration` sub-object per
-[`orchestration-telemetry.md`](../../agent-src/contexts/execution/orchestration-telemetry.md).
-
-Minimal emit (fill what is observable; `token_delta_provenance: "estimated"` if
-host usage metadata is unavailable):
-
-```json
-{"schema_version":1,"id":"<ulid>","ts":"<iso>","work_id":"<work_id>","phase":"implement","outcome":"success","confidence_band":"high","risk_class":"low","input_kind":"orchestration","type":"phase","orchestration":{"task_size_estimate":<int>,"spawn_count":<int>,"tiers":[...],"token_delta":<int>,"token_delta_provenance":"estimated","wall_clock_ms":<int>,"outcome":"DONE","verify_mode":"deterministic"}}
-```
-
-Skip emit when `subagents.enabled: false` or `spawn_count == 0` (in-session run).
+After every auto-dispatched run, write one audit-log-v1 line
+(`input_kind: "orchestration"`) via the `orchestration_record` recorder —
+never hand-author the JSON. Line shape, field semantics, recorder
+invocation, and `token_delta` sourcing priority →
+[`orchestration-telemetry` § Emit procedure](../../agent-src/contexts/execution/orchestration-telemetry.md).
+Skip emit when `subagents.enabled: false` or `spawn_count == 0`
+(in-session run).
 
 ## Gotcha
 

package/dist/agent-src/skills/subagent-orchestration/prompts/README.md

@@ -21,7 +21,7 @@ skill above the 400-line sunset trigger.
 Every prompt cites the status taxonomy in
 [`../schemas/subagent-status.json`](../schemas/subagent-status.json) and
 ends with the **return-envelope** instruction so the subagent's reply
-validates against `tests/test_subagent_status_schema.py`.
+validates against that schema.
 
 ## Prompt-cache discipline
 
@@ -47,6 +47,7 @@ dispatch. Verify a cohort is actually reading, not re-writing, by checking
 
 ## Loading
 
-`tests/test_subagent_prompt_loading.py` asserts that every mode named
-in `SKILL.md` § *The nine modes* has a loadable prompt file under this
-directory and that each prompt mentions all four status enum values.
+Every dispatchable mode named in `SKILL.md` § *The nine modes* maps to a
+prompt file in the table above (mode 8 is gated/experimental — its
+live-app rubric lives in the `subagent-modes-detail` context, not here);
+each prompt mentions all four status enum values.

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

@@ -275,7 +275,7 @@ knowledge intake — never rewrite the page mid-task (see
 [`knowledge-pages`](../../templates/contexts/knowledge-pages.md)):
 
 ```bash
-./scripts-run src/scripts/emit_knowledge_event \
+npx tsx node_modules/@event4u/agent-config/src/scripts/emit_knowledge_event.ts \
     --type mistake_made \
     --error-category "<one or two words>" \
     --context-source "<agents/knowledge/... path, or 'null' if no page was followed>" \
@@ -292,7 +292,7 @@ right now (observed ≠ documented, not a one-off) → hybrid immediate-fix
 case instead — surface the correction, ask before continuing (see
 [`knowledge-pages`](../../templates/contexts/knowledge-pages.md) §
 Contested entries). Approved → isolated fix commit. Declined →
-`./scripts-run src/scripts/append_contested` on that page, then still
+`npx tsx node_modules/@event4u/agent-config/src/scripts/append_contested.ts` on that page, then still
 emit the `context_stale` event above for the consolidation pass.
 
 ## Gotchas

package/dist/agent-src/skills/tailwind-engineer/SKILL.md

@@ -134,9 +134,8 @@ Risks:          <arbitrary values, !important, dark-mode gaps>
   [`docs/guidelines/design-antipatterns.md`](../../../docs/guidelines/design-antipatterns.md)
   (C1 gradients, T7 fonts, L1/L2 layout, V1 side-stripe). Pull the catalog
   for the full list; the objective subset (contrast, font-size floor,
-  reduced-motion) is CI-enforced by
-  [`lint_design_quality`](../../../src/scripts/lint_design_quality.ts) for
-  consumer projects.
+  reduced-motion) is validated via `accessibility-auditor`'s checklist —
+  cite its verdict rather than eyeballing.
 - **Anti-AI-slop: gradients.** Unless audit-pinned or brief-explicit,
   avoid the default purple-to-blue / cyan-to-pink gradients on white —
   they read as auto-generated (catalog C1/C2). Reach for a single accent