bulwark

bulwark

!checklist init ${CLAUDE_SKILL_DIR} --force

A bulwark is the wall that holds a defended thing against constant pressure — it does its job by standing, not by being remembered. bulwark is the seventh and last skill of the surface suite, the 1-to-N lens for a frontend that is already alive, and its enemy has changed: the earlier stages built the thing; this one fights entropy. Its product is an architecture that enforces itself — boundaries fossilized into lint rules, a living design system, abstractions pruned not just stacked — so the system stays cheap to change as people and features multiply. There is no exit: 1-to-N is a steady state, so health criteria replace exit criteria. It runs across gated stages and will not advance past a GATE until the checklist tool clears it — order enforced, substance yours.

The one move that governs everything: make the architecture self-enforcing. A living system rots along two lines — boundary erosion (the state classification and module isolation you drew get punctured by one "just this once" cross-import at a time) and two-graph drift (features pile on, the component tree and the data-dependency graph slowly diverge, state migrates into the wrong bucket, derived values get stored). The master's core move is not vigilance — it's to make the architecture enforce itself, because at scale no one remembers the rules. A boundary that lives only in someone's head, or a wiki, will be violated; a boundary the machine rejects at merge time holds. Everything here is a way to move a rule out of human memory and into a gate.

This is where the agent era bites:

• The agent's default is "add," never "remove." It will add a feature, an abstraction, a flag, a store slice — and never delete, never reclassify, never prune the dead. So the global store grows, abstractions accrete, dead flags linger, and the two graphs drift — all invisibly, because adding turns green and pruning earns nothing. Entropy is the agent's natural output.
• The agent crosses boundaries for convenience. A direct import into another feature's internals is the shortest path to working code, and the agent feels no cost to the architecture — so unless the machine rejects it, the boundary you designed quietly dissolves into "whoever was in a hurry."
• The agent reaches for a rewrite and over-abstracts. It will rebuild rather than refactor, and pile speculative structure that the next session must read through — so the discipline of delete the wrong abstraction, extract only on the rule of three must be enforced, not trusted.

Read references/the-membrane.md first — the heart; for bulwark, lean on the scope axis (boundaries and isolation — the same "spooky action at a distance" CSS/scope problem, now at the module level) and the two-graphs axis (the drift you are fighting), plus the meta-principle optimize for change, not for the first version. Load at the start, re-check at every gate.

Speak the user's language. The calls here are the user's — which boundary is load-bearing, is this abstraction earning its keep, should team structure change to fit the architecture. Read their fluency and gloss a term on first use (a fitness function, dependency-cruiser / import rules, a public-API module, Conway's law and inverse Conway, an ADR, dead-code / unused-export pruning, a stale feature flag). An enforcement rule the user can't evaluate is a constraint imposed, not a shared decision.