Frame Rulings, August 2026

In plain terms: during a run of sittings in late August the owner answered several questions on the spot rather than leaving them on the list. This page keeps those answers so nobody asks them again from scratch. Each is final unless new evidence from real use arrives.

The grain of the unit — resolved as designed (2026-08-28)

The worry was that everything addressable stops at the block boundary and re-graining after the library fills would be expensive. Resolved, not open:

• The module is the reuse grain: a clause set — an entire termination or confidentiality package (for cause, for convenience, consequences), each a block within it. A lawyer reaches for the set, never a bare clause stripped of its companions, so the thing that travels is the thing that is safe to travel.
• The block is the single clause — the unit a lawyer points at ("strike 7.2") — and is the addressable, conditional unit.
• Sub-clause needs are served by promoting a limb to blockhood. The boundary rule: a limb becomes its own block when it needs a condition, a tag, or a cross-reference; otherwise it stays prose. The one open cost of promotion — whether the print stays one clause with (a), (b), (c) — is a numbering-preset question filed separately.

Do not re-raise the grain question without new evidence from real library use.

Two edit authorities over one envelope (2026-08-29)

The paper is the human's surface; the About record card is Goldie's ledger. A Builder writes content, adds fields and edits labels through the regular interface without ever reading YAML; Goldie typically makes the About changes. The standing rules:

• Envelope facts a human rules — lock, hide-from, numbering, versioning — live in the glyph menu.
• Envelope facts Goldie maintains — tags autonomously under the ruled AI-edit rule, the rest by propose-and-review — are reached through her panel. The work bar is Goldie's bar and her ledger sits on her desk; the glyph menu's About item stays as the human peek path.
• The About face displays all of it: one projection, two edit authorities, each with a designed home.

Load-bearing consequence: with Goldie as the record card's ordinary editor, the change-disclosure machinery (About ●n, per-value dots, old → new, accept/reject) is the audit trail, not polish — it ships with the face or the face does not ship.

The glyph menu is the card's registry office (2026-08-29)

Versioning lives in the glyph menu, and lock moves there too, beside hide-from. The menu acts on the folio as a filed thing and the work bar sheds its non-Goldie tenant. The menu spans four registers — arrange (move, duplicate, remove), display (numbering, hide-from), record (versions, About), access (lock) — so it gets grouped sections with separators; Remove is quarantined at the bottom; move-up/down is the grip's deliberate precision and keyboard twin, not an accidental duplicate. The grouping's final shape is a compound-Stack design item, not a re-decision.

Locks operate top-down and are inherited (2026-08-29)

Locking a document or module locks everything beneath it — seal the folder and everything filed in it is sealed — consistent with numbering presets' Document → Module → Block inheritance. Three consequences:

1. A lock denies structure and prose, never value-filling. The lock maps onto the existing write-structure / write-data capability split: a locked stack cannot be rearranged, reworded, or have fields added, removed or relabelled, but a declared fillable field still collects its answer. A fully locked will kit keeps its interview alive, and "lock the document, hand it to the Maker" is the normal one-click publishing act. A per-child unlock override is rejected: a lock above always binds. No new machinery.
2. Inherited lock is derived, never stamped — stored once on the locked folio, computed down the parent chain. Unlocking never hunts for stamps.
3. The at-rest mark distinguishes own lock from inherited lock — a solid padlock on the locked ancestor, a quieter inherited mark below, so "why can't I edit this?" is answered by looking up the column. The state must read without opening anything; only the mark's placement (header versus spine) remains a design choice.

Schema note: lock is live envelope state, not a version fact — locking does not mint a save point. The later ruling that a Maker only fills fields (maker-fills-builder-builds) removed the per-block lock; the inheritance and derivation rules above still govern whatever lock remains.

Build-method rulings, September 2026

• The build order on a disposable database (2026-09-02): walking skeleton — unified seed, read-only canvas, one vertical operation at a time, save lifecycle before content writes, then proposals and Goldie, then legacy deletion; the data is disposable, mid-migration breakage is acceptable, and the compiler is the shut-off.
• The sentenced backend (2026-09-02): the legacy backend, its six tables, the interview machinery and the migration shim are deleted in the first stages, not held to a final phase; the interview tasks are parked with the interview.
• The gate the AI could not run (discharged 2026-09-04): a deployment-scoped deploy key in the cloud environment lets bunx convex dev --once and codegen run in-session; hand-patching and the owner's turn in the loop are retired (see Repository Operations, "The Convex push gate in a cloud sandbox").
• Records outrun code (2026-09-02, part a): a finished boundary is one line in the plan, the commit carries the story, contract facts go to the durable docs; one home per ruling and one gate list remain docs-syncer work.