Container Screens Share One Anatomy

Decision

Owner ruling, 2026-09-14, superseding the separate-screen composition decision of 2026-09-13. Document, Project and Workspace share neutral compound screen parts. The parent Folio owns the portal containing its immediate children.

In plain terms: the drawer and the matter file are the same screen — a file, with the files inside it listed underneath. Only the words change. The document is the one that genuinely reads differently, because it is a document and not a list.

This does not reverse The Folio Tiers Share Parts, Not a Recipe: entity adapters still compose Stack parts and own their domain wiring, and there is still no shell a tier configures with flags.

The screen

The shared CanvasFrame, CanvasSection and CanvasLabel own width, section spacing and persistent small labels. Callers supply content; there is no tier flag. Parent cards and Workspace/Project listings retain only responsive horizontal page insets, without paper padding, border or shadow. Only the Document content sheet is paper.

Spine thickness follows the kind on both listing and parent cards, as governed by the spine hierarchy. The screen's vertical rhythm — the space between painted cards, above location labels, and between a parent's paint and its child section label — is a token schedule, and the Stack's own page states it. src/app/app.css governs where the two disagree; figures were restated here until 2026-09-14 and drifted, which is the reason they no longer are.

The tiers are one screen

Workspace and Project are the same screen and the same page component. Which tier is being looked at supplies words, never structure, and the words come from the shared kind tables rather than from a ternary in the screen:

• the child kind a container files, and every tier beneath it, are read from FOLIO_SCHEMA_CONTAINMENT;
• a tier's own word, singular or plural, comes from the Contains row's table.

A tier joins by adding a row to those tables. A screen that asks "is this a workspace?" has stopped reading them, and that is the defect to look for.

What the screens do

Document, Project and Workspace keep the same collapsible Goldie sidebar on the right. The common InspectorPanel belongs to CanvasShell; pages supply conversation content. Container screens show an empty state directing the user to open a document for chat, because container conversations are not yet connected. On narrow screens a Work Bar trigger opens the container panel; Document retains its existing mobile conversation drawer.

Workspace and Project list newest-created first, with Add before the cards. Document retains authored order and Add Module after the contents. A new Project stays where it was made, because its own screen is empty until it holds a Document; a new blank Document opens on its own Document surface (GB-50.1, 2026-08-17), because there is nothing to see on the listing.

Child cards edit name and Guide in place; contents are edited on their own screen. Clicking the painted child card opens its screen. Nested controls retain their own actions: a click belongs to the control it lands on, and the screen decides that by asking whether the thing clicked is itself a control — focusable, or carrying an interactive role — never by keeping a list of the controls the app happens to have built today. The explicit Open action remains keyboard accessible, and appears in both the left mark menu and the bottom operations row, calling one handler. Child menus offer Open and Delete, not Add or manual ordering.

Container counts are read-only context, with no disclosure or filter action. Manual tag-entry forms are removed from every Stack. Goldie applying tags is a later feature; existing tag display and removal remain available. Existing typed vocabulary and version tag references continue to support tag display and removal. This does not add Library membership operations.

Renames and deletion

Pending Workspace and Project renames update the shared query cache so cards, section labels and cached parent links agree while offline. Server settlement replaces the optimistic name; rejected renames restore the server value.

Delete requires a confirmation naming the Folio and warning that its contents are also deleted. The warning counts what the Folio actually holds and names the tiers beneath it, both read from the containment table, so it agrees in number and never names a tier the deleted kind cannot contain. A container holding nothing says only that it will be deleted.

Deletion marks the container and its owned descendants; saved editions remain stored. Restoring a parent restores descendants deleted in that same operation, while previously deleted descendants stay deleted. A Workspace offers no Delete: it is the browser's one home, and there is nowhere to stand after deleting it.

How the screen arrives

Current since 2026-09-15 (owner ruling). A container's own card arrives open, with Goldie's panel open beside it, so its About declarations show the moment the screen loads. The same ruling that opens the Document Work canvas — see Document Work Screen → Open and scroll defaults; one arrival rule, applied at both tiers.

Only the container's own card. The children below it are a listing, and a listing whose every row arrived open would bury the list it exists to show. A child card opens when the reader opens it.

In plain terms: opening a project shows you the matter file itself — its label, guide and tags — with the documents listed beneath, still folded. You open a document when you want it.

Looking-at state, not container state: the screen says it (defaultOpen, defaultPanelOpen) and the card takes the answer. Nothing is persisted — a reader who folds the card away gets it open again next visit.

Where a refusal is shown

A write that has a place to show its own refusal shows it there: a rename and a tag edit are refused in the editor the user is typing in, and a delete in the menu it was asked from, which turns its own item red. A write with no such place — a Guide save, a duplicate, a creation — reports to the screen's alert region. No write raises a browser alert box.

A failed visit record is not a refusal: it is bookkeeping that moves a folio up the recent list, and it is logged rather than shown beside a failed rename.

In plain terms

The screens share the same frame and controls, while a list of files and an ordered document still behave differently where it matters.

---

Implementation is tracked by GB-261 and its successors; verification history for each belongs in those tasks, not here.