Goldie Blocks

Owner rulings 2026-09-07 — one canvas screen shows any folio and its children; a child with a route is a card and a child without one opens in place; the canvas reads a listing rather than a folio so a Library can use it; Home is the canvas of the session's binding, and several bindings are listed; a Maker is invited to a folio and sees only its subtree; Open is offered where a card's children are not in view; a proposed container is decided whole or item by item.

Decision

Owner rulings, 2026-09-07, in a session that began by asking whether the next tasks introduce a higher-level concept. They do: the Drafting Editor is one instance of a screen every folio kind needs. This record settles that screen's rules before the code is generalised, so the generalisation is a refactor and not a redesign.

In plain terms: today the office has one room built for reading a contract. From now on the room is built for reading any file. The file decides what appears on the desk; the room does not change.

One canvas, one list

One Folio Canvas screen shows any folio and its children. Its own card sits on top and its children are the substack beneath. The Document Work screen is the Document instance; a Project canvas is the same screen handed a Project; a Workspace canvas the same screen handed a Workspace. Which card draws which kind is one keyed table in an Entity door, never an if kind in the screen. Each kind keeps its own card in its own Entity slice; the composer rejection (The Folio Tiers Share Parts, Not a Recipe) stands unchanged.
A Folio List is the canvas with no self card. Document Home today is the document instance. A list of Projects, of bound folios, or of a Library's contents is the same screen fed a different listing (rule 5).

Built 2026-09-07, by the owner's approval of the proposal. Mechanically the canvas is two things stacked: a listing part that lays a listing's rows out through the kind-keyed card table, and the editing machinery the Document canvas layers over its modules and blocks. The Folio List is the first alone — FolioList in the Folio Entity, fed rows and a card table — and Document Home renders both its lists through it. It is not the editor with its self card switched off: the editor assumes an owning document at seventeen sites (selection, the sealed gate, the add-module row, drag, keyboard, panels), and a "no self card" branch at each is the flag envelope this repository rejects.
Depth is decided by a fact, not a kind. A child that has a route key is addressable, opens in its own canvas, and is therefore shown as a single card. A child with no route key has no canvas of its own and is opened in place, with its own children beneath it, by the same rule recursively. The worked cases, which the owner stated as the rule:
- a Workspace canvas shows its Projects as cards;
- a Project canvas shows its Documents as cards;
- a Document canvas shows its Modules opened, and their Blocks beneath, because neither a Module nor a Block answers a URL.
Giving a kind a route is what makes its children fold; nothing else changes when Project and Workspace arrive.
Containment stays the one table. FOLIO_SCHEMA_CONTAINMENT in the domain says a workspace holds projects, a project holds documents, a document holds modules and a module holds blocks. Data blocks inside a Project (a client-details block reused by the project's documents) are post-MVP by owner ruling; when switched on they are one entry in that table and rule 3 already draws them in place.

The canvas reads a listing

The canvas's input is a listing, not a folio snapshot. A listing is a self card plus an ordered set of child cards, each drawn at an exact edition and each carrying whether that edition is sealed. A folio snapshot produces one, with children at live heads or chosen editions. A Library produces one, with children at the sealed editions its pins name. The canvas never learns which it was handed; the read-only gate a card already applies at a sealed edition (Sealed Versions Are Immutable) is what makes a Library's contents read-only on the same screen. Storage is unchanged: a Library stays a shelf and never a folios kind (A Library Is a Shelf, Not a Folio).

Container and list interaction amendment — 2026-09-14

Workspace is Home governs the current container work (GB-49). Workspace lists Projects. Documents remain filed in their Projects; Home does not display a recent-Documents section. Organisation is not a Folio tier.

Every list card remains usable in place: Label editing and the Goldie panel's About information use the shared Stack parts. Clicking or editing the card never navigates. Only the explicit Open action below it opens the full page. Agent conversations remain unconnected where their backend is not yet built.

Home and invitation

A session is bound to a folio, and its scope is that subtree. The authority walk already in force — the bound folio, or any card beneath it — is the whole rule. Inviting a Maker to a Project binds the session one level higher than today's Document binding and changes nothing else. A Maker sees only what is beneath the binding: no Workspace, no other Project, no Library.
Home is the canvas of the session's binding. A Builder is bound to their Workspace, so Home is the Workspace canvas listing its Projects; the development seed carries one Workspace holding one Project. A Maker invited to a Project lands on that Project's canvas; one invited to a single Document lands on the Document canvas, as today. No role switch in the screen: the binding decides.
Several bindings are listed. A Maker invited to two Projects at the same level sees a Folio List of the folios they are bound to and opens one. This is rule 2 fed by bindings, so a Maker who loses an invitation link still finds their work.

Open, and deciding a proposed container

Open is offered where a card's children are not in view (owner ruling, 2026-09-07). Open exists to take the reader to a card's children, so it is the same fact as rule 3 read the other way: a container drawn as one card (a document on a project canvas, a project on the workspace, a module on a library shelf) offers Open; a container opened in place (a module on the document canvas, whose substack is already drawn) offers none; a block has no children to read and never offers it; and no card offers Open when it is the page the reader is standing on. One function beside folioListingPresentation states it. On a proposal the verb reads View.
A proposed container is decided whole or item by item (owner ruling, 2026-09-07; a Stage E rule recorded here so the proposal machinery is built against it). A proposed module is one proposal with a schedule beneath it. Accept on the module accepts every item in its substack; Reject on the module rejects them all; or the reviewer decides each item on its own, and the module resolves when its last item does. The header prototype (folio-header-rows.stories.tsx, retired by GB-220 once the live cards carried it) showed both routes.

Where an item is decided — owner, 2026-09-15 (GB-282). On the thing the item changes, never in a list beside the pair: a provisional card's own review bar, Reject / Accept beside a marked-up clause, a tinted field row on a data block, an About row for a name or a guide. The Steps dropdown that listed every change is retired. The full rule, with the wording each surface uses, is in the proposals schema.

Sequencing

Generalise the widget on the three kinds that exist — document, module and block — which proves the abstraction with no new Entity. Project is the first new caller, Workspace the second. Order among the neighbouring work, ruled 2026-09-07: GB-168 (card behaviour into Stack parts) first, then the canvas, then the header subrows prototyped in GB-197 as Stack parts, then Stage E of the unification plan. Stage E is built against rule 5, so a proposal previews on the same screen whatever kind it addresses.

Consequences

widgets/drafting-editor is renamed to the folio canvas when it is generalised; the meaning changes from "edits a document" to "shows any folio and its children", so this is not an accidental rename.
DraftingEditorModule and DraftingEditorBlock become one recursive canvas node; the Document Work page adapter stops flattening the snapshot into modules-with-blocks.
The standing Steiger bet on widgets/drafting-editor (one consumer) is discharged by the Project canvas; GB-151's Feature layer is earned by the same change, since list and canvas both offer open, rename, duplicate and delete on one folio.
Provisioning a Builder's Workspace and personal Library at sign-up is a criterion of sign-in (GB-10), not built ahead of it.

A Library Is a Shelf, Not a Folio — the 2026-09-07 addendum records the two doors to one insert operation.
Content Writes Receive One Server-Constructed Authority — the binding rule 6 extends upward.
The Stack — the parts every card is written from.

Workspace and Project use the shared screen anatomy. Their listings still read the parent's schedule for membership, then order by creation time newest first. Document keeps authored schedule order. Name, Guide and Tags edit in place; both Open affordances navigate explicitly.

The Folio Canvas Shows a Listing