Skip to main content

​
What We Learned

Naming failure modes before writing code changes the entire implementation trajectory. The STRATT TAD defines 8 failure modes (FM-01 through FM-08) with explicit triggers, detection points, and recovery steps. When the dependency graph package was implemented, each failure mode mapped directly to a CI check function, a test case, and a row in the blast radius report. This is the opposite of “add error handling later.” The failure modes are the specification.

​
Why Naming Matters

An unnamed failure is a surprise. A named failure is a gate. The difference:
  • FM-03 (circular dependency) produces a Kahn’s algorithm check, prints the exact cycle path as strat:// URIs, and blocks the PR. Without a name, this would be “import resolution hangs” or “stack overflow in production.”
  • FM-05 (gate removed without major bump) compares the current chain’s composition against the previous version. Without an explicit mode, gate removal would be invisible until an autonomous agent skips a human checkpoint in production.
  • FM-04 (protected agent absent) enforces that compliance-critical reviewers cannot be silently removed from chains. Without it, a single edit to a chain file removes the guardrail.

​
The Blast Radius Report

Every PR that touches a prompt unit gets a Markdown comment showing: which checks passed, which failed, the failure mode ID, and a per-unit blast radius table with depth and classification (gate dependency, protected dependency, standard). Reviewers see the impact surface before reading the diff.

​
Business Implication

The prompt library is now self-governing at the merge boundary. Shared fragments, protected agents, and gate checkpoints are architectural constraints enforced by the CI system rather than review conventions. This means the library can scale to multiple authors and domains without governance overhead scaling linearly.