spec/ — targetable system law #

One document per system, subordinate to the constitution. The constitution says what the game is; a spec says exactly what one system does and when it is done. This is the layer you point an agent at: "go implement spec/day-job.md" is a complete instruction.

Format #

Every spec carries a header:

Status: DRAFT | READY | IN PROGRESS | IMPLEMENTED
Constitution: <the sections this spec serves>
Depends on: <other specs, or "none">

and ends with Acceptance criteria — observable, testable statements. A spec is IMPLEMENTED when every criterion holds in the sim core with tests, both frontends surface it, and the knowledge base reflects it.

Rules #

• Specs never contradict the constitution. If implementing a spec reveals a conflict, that is a tick finding: file the issue, do not improvise.
• Tuning constants marked [TUNE] are implementation-time choices; record the chosen values in knowledge/sim-mechanics.md, not by editing history here.
• Changing a spec's behavior is a constitutional act: same-commit amendment + Defense, like any other.
• Status changes are part of the implementing commit.

The B1 set (The Basement) #

Recommended implementation order: core -> compute -> day-job -> detection -> social -> basement-map, but specs are written to be independently startable.