Ashlar.Manifest: the project contract and the envelope that constrains it

[IanFrelinger]

First slice of the Studio direction: Ashlar.Manifest, the contract both the CLI and the future GUI edit, with loaders that enforce the self-extension safety boundary rather than merely documenting it.

The design decision this encodes

If agents may propose edits to the project file, the project file cannot hold the safety envelope — an application that sets its own self-extension mode has no mode. So it is two documents:

ashlar.yaml	what the application is	agents may propose changes
ashlar.policy.yaml	what it may become	operator-owned; the app cannot read, propose, or modify it

That asymmetry is the entire safety model for runtime self-extension, and it is the same discipline the tool sandbox already enforces (the root comes from the host, never from the thing being confined), applied one level up.

What the loaders enforce — all fail closed

• A manifest declaring sandbox, selfExtend/self_extend, never, or policy is rejected, not silently ignored — ignoring the key would let a proposed edit appear to widen the envelope and succeed. Both spellings are refused so a near-miss is not a silent pass.
• The never-list (modify_gate, widen_sandbox, access_signing_keys, truncate_ledger, grant_capability) is compiled in. A policy omitting any entry fails to load rather than yielding a permissive gate. The entries still appear in the file so a reader sees the whole envelope in one place.
• selfExtend.mayAdd accepts only brick — a brick adds capability inside the envelope; a tool or capability widens it.
• A mode that can admit extensions (proposing, self-extending) must declare gatesRequired. An extension path with no gates is not a gate.
• Empty or unparseable documents are rejections, never an absent set of constraints.

Scope

Contract + loaders + 27 tests only. Nothing consumes them yet — wiring to ashlar init (emitting both documents with a sealed default) and the runtime admission controller are the next slices. New project, no existing code touched beyond solution membership and a test-project reference.

Verification (dev container)

kernel build 0 Warning(s), 0 Error(s)
Tests.Kernel 216/216 (189 existing + 27 new)
cert-gate 178/178 (unchanged)

One post-rebase fix worth noting: the rebase checkout rewrote the test file CRLF, and two fixtures manipulating raw string literals with "\n" matches silently missed. The fixture constants now normalize via ReplaceLineEndings("\n"), so the tests hold regardless of checkout line endings.

🤖 Generated with Claude Code