The toolkit

A practice not gated by CI is a wish (Law 13). The whole method rests on that line. Anything machine-checkable is wired to fail the build; anything that needs judgment lives on the pull-request checklist; nothing critical is left in prose, because prose enforces nothing. DYSTO's enforcement map is honest about the difference — it marks each gate wired or specified-but-not-yet-wired, and a specified-but-not-wired gate is explicitly still a wish until its CI exists.

For this engine — the ssr-monolith archetype — the wired gates are real files you can run.

The render/database boundary. scripts/check-render-imports.js (npm run boundary:check) walks src/render and src/skins and fails if any file imports @libsql, ../db, ../admin, ../platform, or ../services. Law 18 normally means separate repos; here it becomes an internal boundary enforced by a grep, so the render layer physically cannot reach into the database.

The dependency budget. scripts/check-deps.js (npm run deps:check) counts production dependencies and fails above fifteen. The cap is a control, not a guideline.

Page weight. The home page's rendered size is asserted under 60,000 bytes in test/render.test.js, run by npm test in CI.

Zero client JavaScript. Guaranteed structurally — the render layer emits no <script> — and backed by the no-script render assertion, so it is a fact about the output, not a target you aim at.

Tenant isolation. test/isolation.test.js is a standing cross-tenant attack suite — cookie replay across tenants, media IDOR, host spoofing via X-Forwarded-Host, existence uniformity, cross-plane session replay, seed zip-slip and symlink escape. It runs on every push, and a gap in that suite is treated as a security defect, not a missing test (Law 19 names tenant isolation a privileged domain).

Style. One house style enforced by the linter (npm run lint), not argued in review (Law 24).

Those are the machine gates. The rest of the standard — the trust and operational laws a grep cannot prove — moves to the pull-request checklist: fail closed (Law 4), least privilege (Law 5), defense in depth (Law 6), don't leak existence (Law 7), never trust the client (Law 8), smallest reversible change (Law 10), private by default (Law 12), the adversarial review passes (Law 19), separate admin identity (Law 21), ship the failure modes (Law 22), and rebuild-from-zero (Law 23). The reviewer ticks each, and Law 19 requires a separate signed line for auth, payments, RLS, service keys, and env vars — or a written, documented exception.

The point of the toolkit is that the guarantees in this guide are checkable by anyone. You do not take the lightweight claim on faith: you run npm run deps:check, npm run boundary:check, and npm test, and the build tells you whether the method held. A standard whose lessons live only in a document drifts; a standard whose lessons live in CI fails the build the day someone forgets one. That is the difference between a style guide and an enforced one — and it is the whole reason the earlier chapters can promise what they promise.