Show HN: A TypeScript repo where AI agents can't break the architecture A developer released a TypeScript reference codebase designed to enforce architectural rules through tooling, preventing AI agents from introducing code degradation. The repo uses dependency-cruiser, mutation testing, and commit hooks to block violations, aiming to solve the problem of AI-generated codebases accumulating duplicated logic and broken tests. A reference TypeScript codebase engineered so AI agents produce good code in it — architecture as guardrails, not as documentation. Most AI-assisted codebases degrade the same way: productivity jumps, and three months later there's duplicated logic in three files, tests that assert nothing, and an agent that breaks the code it wrote when asked to change it. That's not a model problem — it's a workflow problem. Prose conventions don't survive contact with agents or with tired humans . Rules that are machines do. This repo is a small but real invoicing API draft → send → pay, money as integer cents, a proper state machine built to demonstrate one thesis: Every rule that matters must be enforced by a tool the agent cannot argue with. - The dependency rule is a build failure, not a diagram. dependency-cruiser fails verify , the commit hook and CI on any illegal import. src/domain imports nothing — not even node builtins. The agent doesn't need to remember the architecture; violating it is impossible to merge. - Mutation testing catches tests that don't test. Coverage says a line ran. Stryker https://stryker-mutator.io says the tests would notice if the line broke . CI breaks below 75% mutation score; the application layer currently scores 100%. - Tests and specs are protected from the agent. A Claude Code PreToolUse hook blocks agent edits to tests/ and specs/ unless a human explicitly grants an override. "Make the tests pass" can no longer be satisfied by deleting the tests ADR 0004 . - Commits are gated on the full verify suite. A hook runs typecheck + lint + deps + test on every git commit and feeds failures back to the agent — feedback loop, not just a wall. - Spec-driven development is a build gate, not a suggestion. One markdown spec per use case with Given/When/Then acceptance criteria; tests mirror them one it per criterion — and npm run specs inside verify , the commit hook and CI fails on any use case without a spec, any orphan spec, and any criterion without its mirrored test. The golden path is npm run new --