@event4u/agent-config 1.34.0 → 1.35.0

package/docs/contracts/context-spine.md

@@ -0,0 +1,133 @@
+---
+stability: stable
+---
+
+
+# Context-Spine Contract
+
+> **Status:** active · **Stability:** stable · **Owner:** unified-senior-roles Block K1
+> · **Lint gate:** `task lint-skills` (frontmatter shape only — slot semantics are author-side)
+
+Senior skills repeatedly need three slabs of context that the user
+already supplied earlier in the project: **what the product is**,
+**who the team is**, **what the repo looks like**. The context-spine
+mechanic captures those slabs once per project and lets every senior
+skill cite the slot it needs — without re-asking the user, without
+re-reading the manifest tree on every entry.
+
+## § 1 — Purpose
+
+Three failure modes the spine prevents:
+
+1. **Repeat-the-context tax** — every senior skill restates "what is
+   this project / what does the team do / where does the code live"
+   to the user. The spine factors that into shared slots.
+2. **Implicit-read drift** — a skill silently reads `composer.json` /
+   `README.md` / `package.json` to infer context, gets stale
+   information, and bakes it into the artifact. Spine reads are
+   **opt-in via frontmatter**, never implicit.
+3. **Cross-role bikeshed** — Wave-2 personas (Block N) and Wing-3 / 4
+   senior skills argue over whose context-doc is canonical. The spine
+   names three slots and freezes the count.
+
+## § 2 — Slot definitions
+
+The spine has **exactly three slots**. Council Q1 verdict (2026-05-05,
+KEEP-3): slot count is locked; extensions require an ADR (§ 5).
+
+| Slot | Path under `agents/context-spine/` | Owner | Typical content |
+|---|---|---|---|
+| `product` | `product.md` | Product / discovery wing | What the product **is**, who it serves, the problem it solves, the JTBD framing, the bounded scope. Read by Block-L senior PO / discovery skills. |
+| `team` | `team.md` | RevOps / maintainer wing | Who **maintains** this codebase, how decisions are made, review-routing conventions, cadence (release rhythm, planning ritual). Read by review-routing, finishing-a-development-branch, persona overrides. |
+| `repo` | `repo.md` | Engineering wing | What the codebase **is** at the file-tree level: stack one-liner, primary languages, top-level module map, deploy target. Read by analysis skills, blast-radius-analyzer, project-analysis-* skills. |
+
+Slots are markdown files. Each is **≤ 200 lines**; longer means the
+slot is doing two jobs and the author should split or trim. Empty /
+missing slot is allowed — the citing skill MUST handle absence
+gracefully and fall back to its existing read paths.
+
+## § 3 — Frontmatter opt-in
+
+A senior skill declares which slots it reads via the `context_spine`
+frontmatter array:
+
+```yaml
+---
+name: customer-research
+tier: senior
+context_spine: [product, team]
+...
+---
+```
+
+Rules:
+
+- The key is **optional**. Senior skills MAY ship without it; the
+  default (`[]`) means the skill does not read the spine.
+- Values are restricted to the literal slot names: `product`, `team`,
+  `repo`. Unknown values fail `task lint-skills` with
+  `unknown_context_spine_slot`.
+- Reads MUST be opt-in and explicit. A skill body that says *"reads
+  `agents/context-spine/product.md` if present"* without declaring
+  the slot in frontmatter is **incorrect** — it bypasses the lint
+  gate and the user's expectation that the spine read is visible.
+- The frontmatter value is the **contract**. The skill body cites
+  `agents/context-spine/<slot>.md` once near the top and lets the
+  reader follow the link if they care.
+
+## § 4 — No implicit reads
+
+The spine is a **discipline**, not a runtime. There is no Python
+loader that injects spine content into a skill's prompt. The agent
+loading a senior skill reads the skill body, sees the
+`context_spine: [...]` declaration, and — if the slot files exist
+— quotes them inline before executing the skill's procedure. The
+skill body MUST NOT state a behavior that depends on the spine being
+read; absence is recoverable, presence is a bonus.
+
+This keeps the spine cheap (no orchestration plumbing), explicit
+(every read is in frontmatter), and reversible (deleting the slot
+file does not break the skill).
+
+## § 5 — Slot-add policy
+
+Adding a fourth slot is **structurally allowed but procedurally
+expensive**. Two preconditions:
+
+1. **Citation evidence.** ≥ 2 shipped senior skills declare the new
+   slot in their frontmatter and cite it in the body, with PRs
+   merged to `main`. Drafts and roadmap items do not count.
+2. **ADR.** A new ADR under `docs/contracts/` named
+   `adr-context-spine-slot-<name>.md` documents the cognition gap
+   the existing three slots cannot fill, the slot's owner wing, and
+   the migration plan for the existing senior catalog (do they
+   declare the new slot, do they ignore it, do they get retrofitted).
+
+The ADR ships with the schema bump (`scripts/schemas/skill.schema.json`
+extends the `context_spine` enum) and a CHANGELOG entry under
+`### Breaking` if the new enum value tightens an existing skill's
+declaration.
+
+This policy mitigates the slot-sprawl failure mode: "tri-slot locked
+at 3 + ADR-gated growth" is the brake. The ADR is the single growth
+lever; no consumer-side override exists.
+
+## § 6 — Author checklist
+
+Before shipping a senior skill that opts into the spine:
+
+- [ ] Frontmatter declares `context_spine:` with values from
+      `{product, team, repo}`.
+- [ ] Skill body cites `agents/context-spine/<slot>.md` near the top
+      (one link per declared slot).
+- [ ] Procedure handles missing-slot gracefully — falls back to the
+      skill's existing read path, never errors out.
+- [ ] `task lint-skills` passes with no `unknown_context_spine_slot`.
+
+## See also
+
+- `.agent-src.uncompressed/rules/skill-quality.md` § Senior-Tier
+  Required Structure — the four blocks every `tier: senior` skill
+  ships independently of spine opt-in.
+- `docs/contracts/cross-wing-handoff.md` — typed handoffs between
+  senior skills; orthogonal to the spine (composition vs context).

package/docs/contracts/file-ownership-matrix.json

@@ -1452,6 +1452,12 @@
       "load_context": [],
       "load_context_eager": []
     },
+    ".agent-src.uncompressed/skills/customer-research/SKILL.md": {
+      "kind": "skill",
+      "rule_type": null,
+      "load_context": [],
+      "load_context_eager": []
+    },
     ".agent-src.uncompressed/skills/dashboard-design/SKILL.md": {
       "kind": "skill",
       "rule_type": null,
@@ -2022,6 +2028,12 @@
       "load_context": [],
       "load_context_eager": []
     },
+    ".agent-src.uncompressed/skills/release-comms/SKILL.md": {
+      "kind": "skill",
+      "rule_type": null,
+      "load_context": [],
+      "load_context_eager": []
+    },
     ".agent-src.uncompressed/skills/repomix-packer/SKILL.md": {
       "kind": "skill",
       "rule_type": null,
@@ -4822,6 +4834,20 @@
       "via": "self",
       "depth": 0
     },
+    {
+      "source": ".agent-src.uncompressed/personas/product-owner.md",
+      "target": ".agent-src.uncompressed/skills/customer-research/SKILL.md",
+      "type": "READ_ONLY",
+      "via": "body_link",
+      "depth": 1
+    },
+    {
+      "source": ".agent-src.uncompressed/personas/product-owner.md",
+      "target": ".agent-src.uncompressed/skills/release-comms/SKILL.md",
+      "type": "READ_ONLY",
+      "via": "body_link",
+      "depth": 1
+    },
     {
       "source": ".agent-src.uncompressed/personas/qa.md",
       "target": ".agent-src.uncompressed/personas/qa.md",
@@ -6488,6 +6514,48 @@
       "via": "self",
       "depth": 0
     },
+    {
+      "source": ".agent-src.uncompressed/skills/customer-research/SKILL.md",
+      "target": ".agent-src.uncompressed/personas/product-owner.md",
+      "type": "READ_ONLY",
+      "via": "body_link",
+      "depth": 1
+    },
+    {
+      "source": ".agent-src.uncompressed/skills/customer-research/SKILL.md",
+      "target": ".agent-src.uncompressed/skills/customer-research/SKILL.md",
+      "type": "WRITE",
+      "via": "self",
+      "depth": 0
+    },
+    {
+      "source": ".agent-src.uncompressed/skills/customer-research/SKILL.md",
+      "target": ".agent-src.uncompressed/skills/funnel-analysis/SKILL.md",
+      "type": "READ_ONLY",
+      "via": "body_link",
+      "depth": 1
+    },
+    {
+      "source": ".agent-src.uncompressed/skills/customer-research/SKILL.md",
+      "target": ".agent-src.uncompressed/skills/po-discovery/SKILL.md",
+      "type": "READ_ONLY",
+      "via": "body_link",
+      "depth": 1
+    },
+    {
+      "source": ".agent-src.uncompressed/skills/customer-research/SKILL.md",
+      "target": ".agent-src.uncompressed/skills/refine-ticket/SKILL.md",
+      "type": "READ_ONLY",
+      "via": "body_link",
+      "depth": 1
+    },
+    {
+      "source": ".agent-src.uncompressed/skills/customer-research/SKILL.md",
+      "target": ".agent-src.uncompressed/skills/rice-prioritization/SKILL.md",
+      "type": "READ_ONLY",
+      "via": "body_link",
+      "depth": 1
+    },
     {
       "source": ".agent-src.uncompressed/skills/dashboard-design/SKILL.md",
       "target": ".agent-src.uncompressed/skills/dashboard-design/SKILL.md",
@@ -8056,6 +8124,48 @@
       "via": "body_link",
       "depth": 1
     },
+    {
+      "source": ".agent-src.uncompressed/skills/release-comms/SKILL.md",
+      "target": ".agent-src.uncompressed/personas/product-owner.md",
+      "type": "READ_ONLY",
+      "via": "body_link",
+      "depth": 1
+    },
+    {
+      "source": ".agent-src.uncompressed/skills/release-comms/SKILL.md",
+      "target": ".agent-src.uncompressed/skills/customer-research/SKILL.md",
+      "type": "READ_ONLY",
+      "via": "body_link",
+      "depth": 1
+    },
+    {
+      "source": ".agent-src.uncompressed/skills/release-comms/SKILL.md",
+      "target": ".agent-src.uncompressed/skills/funnel-analysis/SKILL.md",
+      "type": "READ_ONLY",
+      "via": "body_link",
+      "depth": 1
+    },
+    {
+      "source": ".agent-src.uncompressed/skills/release-comms/SKILL.md",
+      "target": ".agent-src.uncompressed/skills/incident-commander/SKILL.md",
+      "type": "READ_ONLY",
+      "via": "body_link",
+      "depth": 1
+    },
+    {
+      "source": ".agent-src.uncompressed/skills/release-comms/SKILL.md",
+      "target": ".agent-src.uncompressed/skills/release-comms/SKILL.md",
+      "type": "WRITE",
+      "via": "self",
+      "depth": 0
+    },
+    {
+      "source": ".agent-src.uncompressed/skills/release-comms/SKILL.md",
+      "target": ".agent-src.uncompressed/skills/rice-prioritization/SKILL.md",
+      "type": "READ_ONLY",
+      "via": "body_link",
+      "depth": 1
+    },
     {
       "source": ".agent-src.uncompressed/skills/repomix-packer/SKILL.md",
       "target": ".agent-src.uncompressed/commands/analyze-reference-repo.md",

package/docs/contracts/mental-models.md

@@ -0,0 +1,336 @@
+---
+stability: stable
+---
+
+
+# Mental Models — Top-30 Cross-Role Reference
+
+> **Status:** active · **Stability:** stable · **Owner:** unified-senior-roles Block K4
+> · **Hard cap:** 30 models · **R23 mitigation:** additions require removing one (zero-sum)
+
+A ranked, citation-only reference. Senior skills cite a model by
+its number when the cognition step it triggers needs framing prose
+the skill would otherwise re-invent. The doc is not auto-loaded
+and never appears in a prompt unless a skill names a row.
+
+## How this list was built
+
+Council iter-1 (Anthropic `claude-sonnet-4-5` + OpenAI `gpt-4o`,
+2026-05-05) Q2 verdict: **Ranked Top-30**, cross-role bias.
+Channel-specific (CAC/LTV-as-model, ad-auction, SEO keyword),
+C-suite strategy (Blue Ocean, Porter's Five Forces), and sales
+pipeline (BANT, MEDDIC) **explicitly cut** — they are domain
+heuristics, not cross-role cognition tools. Additions require
+removing one.
+
+Each entry: title · domain · ≤ 8-line summary · one citation example
+from a shipped skill (path is the proof of provenance, not a load
+instruction).
+
+## The 30 models
+
+### 1. First-principles thinking
+
+Strip the problem to assumptions you can defend from physics, contract,
+or hard data. Re-derive the answer from those, not by analogy to past
+decisions. The expensive part is identifying which "principle" is
+actually load-bearing vs. inherited belief; the cheap part is the
+re-derivation. Use when an inherited approach feels stale and you
+suspect the real constraint moved.
+*Cited by:* `.agent-src.uncompressed/skills/improve-before-implement/`
+(challenges weak requirements before code is written).
+
+### 2. Jobs-to-be-Done (JTBD)
+
+A user "hires" a product to make progress in a specific situation;
+the job is the situation × motivation × expected outcome, not the
+demographic. The unit of analysis is the **switch event** — what
+caused them to fire the previous solution. JTBD reframes feature
+requests as evidence of an unmet job, not feature gaps.
+*Cited by:* `.agent-src.uncompressed/skills/po-discovery/`
+(reframes fuzzy product asks via job-shape).
+
+### 3. Pareto principle (80/20)
+
+Roughly 80% of effects come from 20% of causes. The lift is in
+**identifying** the 20% — which user segment, which test failure,
+which N+1 query — not in re-stating the ratio. Anti-pattern: using
+80/20 as permission to ignore the long tail without measuring it.
+*Cited by:* `.agent-src.uncompressed/skills/performance-analysis/`
+(N+1 detection prioritizes the 20% of queries causing 80% of latency).
+
+### 4. Second-order thinking
+
+Ask "and then what?" until the chain breaks down. First-order picks
+what looks best now; second-order weighs the consequences of the
+consequences. Most "obvious" decisions die at second-order — the
+optimization that ships now creates the maintenance debt that kills
+velocity in 6 months.
+*Cited by:* `.agent-src.uncompressed/skills/adversarial-review/`
+(stress-tests a plan by walking past the immediate verdict).
+
+### 5. Opportunity cost
+
+The real cost of any choice is the **next-best alternative you did
+not pick**, not the dollar / time spent. A 2-week feature is not
+"2 weeks expensive" — it is the highest-value 2-week feature you
+chose not to ship instead. Naming the alternative makes the cost
+legible; pretending there isn't one is the failure mode.
+*Cited by:* `.agent-src.uncompressed/skills/rice-prioritization/`
+(scores compete for capacity; non-shipped items are the cost basis).
+
+### 6. Theory of constraints
+
+System throughput is bounded by exactly one constraint at a time.
+Improving any non-constraint resource is local optimization with
+zero system effect — usually negative, since it loads the actual
+constraint harder. The discipline: identify, exploit, subordinate,
+elevate, then find the next constraint.
+*Cited by:* `.agent-src.uncompressed/skills/funnel-analysis/`
+(identifies the single funnel stage that bounds conversion throughput).
+
+### 7. MVP (Minimum Viable Product)
+
+The smallest thing that produces real evidence about whether the
+hypothesis holds. MVP is a **measurement instrument**, not a
+junior-grade product. The trap is shipping an MVP that cannot
+distinguish "user behavior validates the hypothesis" from "user
+behavior was driven by something else"; that is just a small
+product.
+*Cited by:* `.agent-src.uncompressed/skills/po-discovery/`
+(scopes a discovery slice that produces a learning, not a feature).
+
+### 8. Build-Measure-Learn
+
+A loop: build the smallest test, measure the actual signal, decide
+to persevere or pivot. The skill is in **shortening the loop** —
+weeks beat months because months let teams rationalize a failed
+hypothesis. The loop is the artefact; any individual cycle is just
+one iteration.
+*Cited by:* `.agent-src.uncompressed/skills/test-driven-development/`
+(the build-measure-learn loop applied to one function at a time).
+
+### 9. Hypothesis-driven development
+
+State the hypothesis as a falsifiable sentence with a metric and a
+threshold **before** writing the code. "If we do X, metric Y will
+move by Z." Without the threshold, the team will declare any
+movement victory. With it, the team learns from the misses.
+*Cited by:* `.agent-src.uncompressed/skills/project-analysis-hypothesis-driven/`
+(competing hypotheses + validation loops + evidence-based conclusions).
+
+### 10. Reversible vs. irreversible decisions
+
+One-way doors deserve a high bar; two-way doors deserve a low bar
+plus speed. The bias under uncertainty: shipping a reversible
+decision early is almost always cheaper than the meeting required
+to decide. The skill is recognizing irreversibility — usually data
+shape, public API surface, or hiring.
+*Cited by:* `.agent-src.uncompressed/skills/decision-record/`
+(records the reversal-criteria so the irreversibility verdict is auditable).
+
+### 11. DX as first-class concern
+
+Developer experience is a leading indicator of throughput; it is not
+a polish task. Slow tests, fragile local setup, and surprising tool
+output compound — every developer pays the tax every day. Treat DX
+issues like user-facing bugs, with severity and SLA. The compounding
+math makes "fix it later" almost always wrong.
+*Cited by:* `.agent-src.uncompressed/skills/test-performance/`
+(test-suite latency is a developer-facing metric, optimized as such).
+
+### 12. Conway's Law
+
+The systems an organization builds mirror its communication structure.
+Re-orgs propagate to architecture; architecture changes that fight the
+org chart fail. The lever is bidirectional: pick the architecture you
+want, then engineer the communication paths that produce it.
+*Cited by:* `.agent-src.uncompressed/skills/api-design/`
+(bounded-context choices follow team boundaries, not the other way around).
+
+### 13. Occam's Razor
+
+Among hypotheses that fit the evidence equally well, prefer the one
+that introduces the fewest new entities. In debugging, the boring
+explanation (typo, off-by-one, stale cache) is usually correct. The
+trap is **assuming** instead of **falsifying** — Occam suggests
+order of investigation, not a verdict.
+*Cited by:* `.agent-src.uncompressed/skills/systematic-debugging/`
+(reproduce → isolate → hypothesize, simplest hypothesis first).
+
+### 14. Meadows leverage points
+
+Donella Meadows' ranking: the highest-leverage interventions in a
+system are paradigm shifts, then goals, then rules — far above
+parameter tweaks. Most "improvement" effort fights parameters
+(numbers, delays) at the bottom of the ranking. Climb the ranking
+before optimizing.
+*Cited by:* `.agent-src.uncompressed/skills/architecture-review-lens/`
+(boundary / dependency-direction issues are higher-leverage than tweaks).
+
+### 15. Signal vs. noise
+
+Every metric is a sum of underlying signal and measurement noise.
+A change of size N is meaningful only if N exceeds the noise floor
+for that metric × that horizon. The discipline: estimate the noise
+band first, then evaluate the change. Without the noise band, every
+movement looks like a trend.
+*Cited by:* `.agent-src.uncompressed/skills/funnel-analysis/`
+(stage-to-stage drop is read against the typical week-on-week noise).
+
+### 16. Leading vs. lagging indicators
+
+Lagging indicators (revenue, churn, retention) are accurate and
+late. Leading indicators (activation events, repeat-use, support
+volume) are noisy and early. Operating on lagging alone means the
+team learns about problems after they cost money. Pair them: lagging
+is the score, leading is the steering wheel.
+*Cited by:* `.agent-src.uncompressed/skills/dashboard-design/`
+(RED / USE / Golden Signals split leading from lagging explicitly).
+
+### 17. Churn as health metric
+
+Retention curves expose what acquisition cannot: whether the product
+delivers ongoing value. A flat retention tail means the product
+works for the survivors; a sliding tail means the underlying job is
+not getting done. Churn is upstream of CAC payback — fix it first,
+then scale.
+*Cited by:* `.agent-src.uncompressed/skills/funnel-analysis/`
+(retention bend distinguishes activation problems from product-fit).
+
+### 18. Pull vs. push systems
+
+Pull systems start work when downstream capacity opens; push systems
+start work when upstream capacity is free. Push optimizes individual
+utilization, pull optimizes flow. Most software teams claim pull and
+operate push (queues filling up, sprints overcommitted, WIP
+unmanaged). The fix is WIP limits, not motivation.
+*Cited by:* `.agent-src.uncompressed/skills/laravel-horizon/`
+(queue-balance strategies are pull-vs-push policy in concrete form).
+
+### 19. Shift-left
+
+Move quality / security / accessibility checks earlier in the
+lifecycle — to the developer's machine, the PR, the design — where
+the cost of fixing is order-of-magnitude lower. The trade-off:
+shift-left adds friction at the front; the math holds when defect
+escape rate drops faster than the friction cost.
+*Cited by:* `.agent-src.uncompressed/skills/threat-modeling/`
+(threats enumerated before implementation, not after pen-test).
+
+### 20. Latency vs. throughput
+
+Optimizing one usually hurts the other; the trade-off is structural,
+not implementation-detail. Batch processing trades latency for
+throughput; real-time pipelines trade throughput for latency. The
+mistake is optimizing without naming which one matters for the user
+job at hand.
+*Cited by:* `.agent-src.uncompressed/skills/database/`
+(index strategy and query batching surface the trade-off explicitly).
+
+### 21. Trust boundaries
+
+Every system has explicit lines across which inputs cannot be
+trusted: client → server, tenant A → tenant B, free tier → paid
+tier, public endpoint → internal service. Threats enter at boundary
+crossings; defense lives at the crossing, not deeper. Drawing the
+boundary correctly is half the security work.
+*Cited by:* `.agent-src.uncompressed/skills/threat-modeling/`
+(produces trust boundaries + abuse cases mapped to files).
+
+### 22. Defense in depth
+
+No single control is sufficient; layer entry validation, business
+rules, environment hardening, and instrumentation so a bypass at
+one layer is caught at the next. The trap is mistaking redundancy
+for security theatre — each layer must have an independent failure
+mode, not a copy of the previous one.
+*Cited by:* `.agent-src.uncompressed/skills/defense-in-depth/`
+(turns local fix into structural one across four guard layers).
+
+### 23. Blast radius
+
+Before changing shared code, enumerate every call site, event
+consumer, queue worker, API client, migration, and test that the
+change touches. The radius is the work; the diff is the artefact.
+Underestimating radius is the failure mode that breaks production
+when the change "looked small".
+*Cited by:* `.agent-src.uncompressed/skills/blast-radius-analyzer/`
+(file:line citation per dependency, BEFORE the edit).
+
+### 24. Iron triangle (scope / time / quality)
+
+Scope, time, and quality are coupled — fix two, the third moves.
+Pretending to fix all three is how teams ship at low quality and
+call it on-time. The honest move is naming which two are fixed and
+which one absorbs the variance, BEFORE the work starts.
+*Cited by:* `.agent-src.uncompressed/skills/refine-ticket/`
+(AC sharpening forces explicit scope decisions before estimation).
+
+### 25. Definition of Done
+
+A shared, auditable description of what "done" means for a unit of
+work — tests, docs, deployment, comms. Without one, every team
+member ships their personal threshold and disputes downstream. The
+discipline is making it visible, agreed, and consistently applied —
+not the specific items on it.
+*Cited by:* `.agent-src.uncompressed/skills/verify-completion-evidence/`
+(fresh evidence is required before any "done" claim).
+
+### 26. Postmortem-driven learning
+
+Incidents are signal-rich; the team that captures the signal beats
+the team that hides the incident. Blameless postmortems separate
+contribution from blame, surface systemic causes, and produce
+mitigations that reduce future incident rate — not just the count
+of one-off fixes.
+*Cited by:* `.agent-src.uncompressed/skills/incident-commander/`
+(severity framing + comms cadence + post-mortem skeleton).
+
+### 27. Tech debt as interest
+
+Tech debt has a principal (the shortcut taken) and an interest
+payment (the ongoing tax on velocity). Carrying the debt is the
+right call when the principal is repayable and the interest is
+small; the failure is treating ongoing high-interest debt as a
+fixed cost. Track it like a balance sheet.
+*Cited by:* `.agent-src.uncompressed/skills/tech-debt-tracker/`
+(interest-vs-principal framing, prioritisation by carrying cost).
+
+### 28. Mise en place
+
+Prepare every input — data, fixtures, dependencies, decisions —
+before the cooking step starts. Switching between prep and cook is
+where errors enter. In software, the analogue is staged commits,
+prepared test fixtures, and decisions locked before implementation.
+The discipline is the savings, not the metaphor.
+*Cited by:* `.agent-src.uncompressed/skills/existing-ui-audit/`
+(inventory before any non-trivial UI edit, hard gate).
+
+### 29. Premortem
+
+Before kickoff, assume the project failed and ask why — names the
+risks the team already knows but has not voiced. The trick is the
+past-tense framing; "what could go wrong" surfaces less than "it
+failed, what happened". Cheap; high signal-to-noise; the residual
+output is a risk register the team actually defends.
+*Cited by:* `.agent-src.uncompressed/skills/risk-officer/`
+(blast-radius framing, mitigations, residual-risk verdict pre-commit).
+
+### 30. Inversion
+
+Instead of asking "how do I succeed at X?", ask "how would I
+guarantee failure at X?" — then avoid that. Inversion exposes the
+non-obvious failure modes that direct planning misses, especially
+in security, ops, and people problems where the failure surface is
+larger than the success surface.
+*Cited by:* `.agent-src.uncompressed/skills/adversarial-review/`
+(devil's-advocate stress-test poking holes in a plan).
+
+## Adding or removing a model
+
+Hard cap is 30. Adding a 31st requires removing one and naming the
+swap in the PR description — the council verdict (R23) is that the
+list earns its weight only if every entry is load-bearing. Removal
+criteria: ≤ 1 citation across the catalog after one minor release,
+or superseded by a more general entry.