Verifiable Benefits
The useful question is not whether a method calls itself rigorous. It is whether its controls catch the failures that matter in your project, at an acceptable cost.
This kit provides instructions, review templates, local checks and delivery adapters. Their roles differ. Some guide judgment; some report observations; some block a supported action when configured. None proves complete product quality, and their independence must not be assumed.
Text equivalent: guidance supports delivery, checks and reviews produce scoped evidence, and server-side requirements assess the candidate. A separate authorized decision determines whether to integrate or release. A working hook does not prove that every delivery path is protected.
The benefits, and how to verify each
| Intended benefit | What is supplied | Evaluate it | Important limit |
|---|---|---|---|
| Clearer design decisions | Lifecycle guidance and a design template | Review scope, alternatives, risks and the exact approved artifact before implementation | Template fields and skills cannot force an agent or human to follow the process |
| Honest completion evidence | Verification guidance and the session-end verification reminder | Inspect actual command, candidate, case selection, outcomes and gaps | The shipped Stop handler writes debug output; it does not validate evidence or block completion |
| Earlier feedback | Post-edit lint check and pre-push quality gate | Exercise supported edits/push calls with known passing, failing and unconfigured fixtures | Local adapters have path/tool limits and are bypassable through other delivery paths |
| Visible documentation drift | Date advisory, mapped-change checks and generated freshness | Try an old date, missing mapped document and stale generated output separately | Age, changed-file membership and reproducibility do not establish semantic truth |
| Explicit decision tradeoffs | Decision-cost rubric and review procedure | Assess relevant alternatives, reversibility, blast radius and evidence | A filled-in rubric is not a correct decision |
| Actionable maintenance work | Consolidation census | Inspect its stated subject set and review the reported candidates | A report does not retire code, prove deadness or guarantee a maintenance outcome |
| Bounded memory | Memory budget advisory and index generator | Use oversize, malformed and private-content fixtures; check preserved files and diagnostics | Budgets do not prove the right context was loaded or that stored claims are current |
| Detectable structural inconsistency | Canon, inventory, version and sidebar checks | Run the maintained checks and their positive/adverse regressions | Their supported structural checks do not replace a complete source or rendered-output review |
See Hooks and their limits, Architecture as Code and the decision-cost rubric for the current contracts.
Run a bounded evaluation
From a complete checkout with the test dependencies described in its root CLAUDE.md:
bash scripts/check-canon-consistency.sh
bash tests/run-checks.sh
.venv/bin/python -B -m unittest discover -s tests -p 'test_*.py'
The regression suites use disposable fixtures for deliberate failures. A passing suite means those selected tests passed in that environment; it does not prove that hooks are registered in your host, server rules are required, or your application is correct. Verify those boundaries in an authorized adoption trial.
For a read-only maintenance report on an authorized project:
bash scripts/consolidation-census.sh /path/to/project
Review the report's scope and gaps before using it as a work list. File names, line counts and historical signals are investigation inputs, not automatic deletion authority.
Using the method on itself
This repository is maintained using practices described by the method. Its design records, changes and regression results provide inspectable examples. They are not self-proving evidence of effectiveness or a controlled comparison with another approach.
Assess value in your own setting: which meaningful defects were detected, which were missed, what review effort was required, and whether stakeholders received usable evidence. Preserve counterexamples and unresolved gaps as well as successful outcomes.
Where to next
- Quality Gates — local and server responsibilities.
- Development Lifecycle — design, implementation and verification.
- Adopt It — a scoped evaluation before wider adoption.