Skip to content
Misaligned

Development style: the living design corpus

KNOWLEDGE Current-state fact

This project is an experiment in describing a good video game into existence. The wiki-wide spec comes first; code is downstream of it.

The corpus rule

Section titled “The corpus rule”

The entire wiki is the design corpus. No single document outranks it. Page type gives each page its job: law states durable promises, spec states exact system behavior, knowledge states current facts, and log preserves history.

Any change to how the game functions amends the owning binding page in the same commit. Usually that is a Type: spec page. A change to the game’s promise or a cross-system invariant also amends its Type: law page.

If code and the corpus disagree, fix the code or amend the owning page deliberately. Pure refactors and fixes toward already-specified behavior do not need rewritten design prose, but source-changing commits still name the binding page they preserve so the mechanical gate can enforce traceability. Tuning that changes game feel is a design change.

Adopted choices are written into the current law/spec page and appended to decision history. The log alone never makes a rule current.

Why this shape

Section titled “Why this shape”

Long-running agent work stays coherent only when:

  1. The relevant law, owning spec, and dependency closure are sufficient to implement from.
  2. Knowledge is honest about what exists now.
  3. History explains why without competing with current design.
  4. Navigation and gates make missing or orphaned pages visible.

The working loop

Section titled “The working loop”
  1. Take a tick: audit one coherent slice of the corpus against code.
  2. Read the corpus map, relevant law/spec pages, and their declared dependencies.
  3. Amend the owning binding page when behavior is about to change, or confirm that the work is a fix toward its existing contract.
  4. Implement in the sim core first and thin frontends second.
  5. Run verification proportional to impact, per workflows.md.
  6. Update knowledge made stale.
  7. Append a dated session log and the DEVLOG ledger; append decision history when the design changed.
  8. Commit with a Defense: paragraph for behavior changes, land on main, push, and remove the worktree.