Verifiable Benefits
Most methodologies ask you to trust an outcome: "teams that adopt this ship faster / with fewer bugs." Those numbers are real for the team that measured them and unfalsifiable for everyone else.
This page takes the opposite approach. Every benefit below is enforced by a mechanism that ships in this repository, and every mechanism comes with a way to see it work for yourself. "Verifiable" here does not mean "trust our metrics" — it means run this and watch it happen.
The methodology's core bet is quality as architecture: quality is not maintained by discipline (which fails under deadline pressure, and which an AI collaborator has no intrinsic motivation to uphold) but built into the development infrastructure as automated structural constraints. A quality violation has to defeat four independent layers to reach the codebase.
These layers are independent and redundant — the defense-in-depth principle borrowed from security engineering: no single control is the sole protection against any category of failure.
The benefits, and how to verify each
| The promise | The mechanism that enforces it | Verify it yourself |
|---|---|---|
| AI cannot skip design on non-trivial work | The Brainstorm Gate: a proposal that fires any trigger cannot proceed until a Pre-Mortem Block is emitted, ending in two non-skippable lines | Open templates/spec-template.md — the block structurally requires "Strongest risk I see" and "What would change my mind". A block missing them is visibly incomplete. |
| No unverified "it should work now" | The verify-before-stop hook + the verification-before-completion skill: completion claims must be backed by fresh test output | Read templates/hooks/verify-before-stop.sh. Wired into Stop, it intercepts a completion claim and asks for the evidence. |
| Quality survives deadline pressure | The pre-push-gate hook: a blocking gate before code reaches the remote — tests must pass and coverage thresholds must be met | Read templates/hooks/pre-push-gate.sh. The decision to enforce was made once, when the hook was installed; it applies to every push without anyone remembering it. |
| Lint never silently rots | The lint-on-edit hook runs the linter automatically after every file edit | Read templates/hooks/lint-on-edit.sh. Immediate feedback at edit time, not at review time. |
| Documentation cannot silently drift | Architecture-as-code: a staleness check blocks when a touched file's doc page has last_verified older than 30 days | See Architecture as Code §"Sync Enforcement" — the staleness check is blocking, not advisory. |
| Decisions are multi-dimensional, not single-axis | The six-axis Decision-Cost Rubric (latency, dependency surface, debuggability, reversibility, blast radius, alternative considered) embedded in the Pre-Mortem Block | Read The Decision-Cost Rubric — a one-axis "this improves consistency" proposal is incomplete, not "lighter weight". |
| Complexity gets subtracted, not just added | The monthly consolidation census + a standing retirement mandate (retire ≥2 flags or merge one duplicated lane per cycle, or record why not) | Run it on any repo: bash scripts/consolidation-census.sh <project-root> — it emits the feature-flag census with born-dates, oversized modules, and ADR-register integrity. |
| Project memory stays within budget | The memory-budget-check hook enforces a hard byte budget on memory files | Read templates/hooks/memory-budget-check.sh. Memory that exceeds the budget is flagged, forcing durable-first curation. |
| The methodology itself stays internally consistent | check-canon-consistency.sh + check-version-header.sh — mechanical greps that pin the canon's own invariants | Run bash scripts/check-canon-consistency.sh against the canon. The methodology holds itself to its own evidence-over-claims rule. |
Run it yourself: three at the command line
The most direct way to see "quality as architecture" is to run the mechanisms. From a clone of the methodology repository:
1. The subtraction mechanism — the consolidation census.
bash scripts/consolidation-census.sh /path/to/any/git/repo
It generates a feature-flag census (with the git born-date of each flag), flags modules over 3,000 lines, and checks ADR-register integrity. The census is the work-list for the monthly review; a run that produces no retirement and no written justification is an unfinished review.
2. The deadline-proof quality gate — the pre-push hook.
cat templates/hooks/pre-push-gate.sh
This is the gate that makes cutting corners harder than not cutting them. It runs before code reaches the remote: tests must pass and coverage must clear the threshold, or the push is blocked. No one has to remember to enforce it.
3. The anti-premature-victory gate — the stop verification hook.
cat templates/hooks/verify-before-stop.sh
Wired into the assistant's Stop event, it catches the "it should work now"
failure mode at the moment it happens, asking for the test output before a task
can be called complete.
The self-demonstrating proof
The strongest evidence is structural, not numeric: this methodology's own specification was produced using the lifecycle it describes — brainstormed, specified, planned, implemented, verified, and reviewed. The documentation site you are reading was itself built through the brainstorm → design → plan → execute cycle, with a committed design artifact and a Pre-Mortem Block before any code was written. The artifact is its own proof.
An honesty note
Mechanisms enforce floors, not ceilings. A pre-push gate guarantees tests pass; it does not guarantee the tests are good. A staleness check guarantees a doc was re-verified within 30 days; it does not guarantee the verification was thorough. The methodology's claim is narrow and therefore defensible: it makes the low-quality path require more effort than the high-quality path, and it replaces "did we remember to do the right thing?" with "did the gate fire?" — a checkable condition rather than a feeling.
Want to go deeper? The mechanisms above are specified in Quality Gates and the Development Lifecycle; the reasoning behind each lives in Philosophy. Every claim on this page is something you can run — clone the repo and try it.