Write down the rules the compiler will be held to #30

Parent

#21

What to build

The rules for code that does not exist yet go into the ledger now, so the compiler's first module meets them instead of prompting them.

• Seams. Environment, clock, randomness, console, spawning and synchronous filesystem calls are allowed only in the infrastructure and CLI rings. Exiting the process and writing to stdout or stderr are allowed only in src/cli/boundary.ts, the one file excluded from coverage; every decision stays outside it, where it is covered. ESLint and dependency-cruiser enforce these from this ticket on, and each rule is proved on a probe file in a ring it forbids.
• Spec error codes. A test reads every E_ code the specification chapters define (59 today) and requires each one to be exercised by a test or by a negative example's committed diagnostics.json (28 are exercised today), or to be listed as pending with a reason. An E_ code used in the tree but not defined by the specification fails the test.
• Pending families. CLI conventions: help on --help and -h, data on stdout and diagnostics on stderr, --json output that is only data, one exit-code enum, NO_COLOR, never prompting. Registry contracts: every adapter satisfies the port, is attributed and is deterministic; every invariant is registered with its code, its spec anchor and its test. Diagnostics: every diagnostic carries a code, a path, a message and a non-empty hint, enforced by its type; the path is an RFC 6901 JSON Pointer into the canonical intent document, because the parity contract compares (code, path) pairs across the two implementations. Generated files: JSON Schema and the diagnostic catalogue are committed, and CI fails when regenerating them produces a diff. Oracle files (the rendered example trees, intent.json, resolved.json, diagnostics.json and the descriptor) are the opposite: committed and reviewed by hand, never regenerated in CI from either implementation. A rule says so, so a generator that writes into an oracle path fails. Each is a ledger row with a pending entry that names the change that will enforce it.
• Three ADRs in docs/adr/architecture/: the process lives in one boundary file; every spec error code is proved by a test; generated files are committed and diff-checked.

Acceptance criteria

• A probe file in the domain ring that reads the environment, the clock or Math.random fails lint with the rule's ID.
• A probe that exits the process or writes to stdout outside the boundary file fails lint.
• The spec code test starts with 31 pending codes, each with a reason, and fails for a pending code that is covered or no longer defined.
• Every pending row names what will enforce it.
• The three ADRs pass lint:adrs, with pointers into the ledger or docs/architecture.md.

Blocked by

• Give every enforced rule an ID, a ledger row and a fixture that proves it fires #29