Tinted Chrome, White Paper

Current refinement — 2026-10-05: a data block wears the module's header row

GB-348 (owner, 2026-10-04) supersedes part 3 below for the data block only. Its label is the address every content block reaches a field by (key terms › party details), so the row is the module's: medium rank, the kind line with a field count above the name, and the same chrome wash the module card carries, stepped by hover and selection. It is still Builder chrome and still never prints; the wash and the braces mark are what keep it from reading as a heading block, which does print. Renaming from the row goes through the handle-rename door the About face already uses, so every reference follows. A content block still has no header row, and every row beneath the data block's header stays white.

In plain terms: the data block now gets the same grey label strip the module card has. It shows in the builder only, never in the printed document.

Same day, the corners: a data block is a closed card, its header the lid and its last field row the base, both rounded, always. Two data blocks in a row then read as two containers and not one strip inside another. Inside a module this is a lid under a lid for the moment; the owner accepted that because the module tier retires with GB-346.1, and a conditional corner rule would die with it. A content block keeps the run's rule: square until it is the last in its module.

Current refinement — 2026-09-14: spacious metadata without paper

The owner removed the white cover paper, border and shadow from Document metadata too. Its existing responsive padding and outer separation remain, and Workspace and Project retain that same generous spacing on transparent surfaces. Only the Document body remains a paper sheet. This supersedes the cover paint and hover-label rules below, not the Folio card's tint or behavior. The Document card retains the folio chrome wash on its own screen, including the existing hover/selection shades; the transparent page inset surrounds that card (one chrome since 2026-09-16).

The shared CanvasLabel uses the existing 12px caption and muted token. Parent context (In Project: Smith Estate Plan, with the parent name linked) and contents labels (Document Canvas, Projects, Documents) remain visible at rest. Parent context replaces Document Meta; the current item is already named on its card. Labels remain outside the content surface and hidden from print/export.

Amendment — 2026-09-10: the document's card sits on a white cover sheet

The document's metadata is the cover sheet of the document, not a card floating above it (owner ruling 2026-09-10, in Work Bar Shows Where You Stand ruling 7). The cover sheet is white paper — the body's border, radius, shadow and page padding — and the document's tinted card sits on it, with no spine, inset by the page padding exactly as a module's tinted card sits on the body page (owner: "the card keeps its tint. the card is still sitting on the paper but without a spine"). Part 2 below stands: the card is chrome, tinted; the sheets are paper, white. The cover sheet does not print or export.

In plain terms: a white backsheet with the coloured file card pasted on it, on top of the white pages. Still not the instrument, so still never printed.

Sheet labels — 2026-09-11

The working two-sheet view labels the cover Document Meta and the body Document Canvas. Each label sits outside and above its sheet, aligned with the inner stack’s left edge, with an 8px gap. The shared responsive horizontal page inset and border allowance keep that alignment even when the sheet surface is transparent (owner ruling 2026-09-12). Both use the shared SectionLabel atom, which owns the 12px caption size (text-xs) and the existing --color-editor-muted-2 colour token so their presentation cannot drift. A label appears only while its own sheet is hovered or contains keyboard focus. Each surface sets --section-label-opacity; the shared atom owns the opacity treatment. Hidden labels reserve their space, preventing layout shifts. Hovering the body does not reveal the cover label. The labels follow the cover sheet’s visibility and do not print or export.

Decision

Every folio kind fills the shared Stack Header; chrome is tinted and paper is white; and Builder capability gates the chrome. Owner ruling 2026-08-21, from the BuilderContentHeaderProto story (GB-125), adopted verbatim in four parts:

1. A header appears on the content stack, just like other stacks. Every folio kind — document, module, data block, content block — fills the shared Header: kind glyph and EditableName, uniform anatomy. The content block was the last kind without one, and its header carries the rename affordance GB-123 asked for as a consequence.
2. The all-chrome kinds are tinted; anything that prints is white — header row included. Module and document cards are all chrome, and since the second sitting of 2026-08-21 they carry two tints, one hue: a flat light body wash over the full card, and the darker header band above it, stepped by state — so the band reads as the label strip on a tinted sleeve. (As first ruled they carried one flat full-surface tint; the owner deepened this after the Stack Tint Proof.)
3. A data block's header row is white, like the rows beneath it; a content block has no header row at all; everything on a block is white (owner ruling 2026-09-15, restoring the 2026-08-24 correction). A data block's field rows each need the gutter for their type mark, so the block's glyph and name get a row of their own (GB-268, 2026-09-14). For one day that row carried a 6% band of the data cyan; on sight the owner withdrew it — a tinted strip over white rows said "chrome" and "paper" at once, and an unselected data block read as a fragment — so the row is white and the module's tint does the grouping alone. The row is still chrome: it does not print (print:hidden), and its glyph, G and code-face name are the only signs of it. A content block's prose row is the only row it has, so the glyph and the Goldie badge ride that row's gutter and trailing cell and no header renders. A block's spine steps through rest, hover and selection; no proposal recolours a block's header. The seam on a block is the spine and the role gate, never colour.
4. Maker and Reader roles see no headers at all, and no module cards at all. Their canvas is the content blocks and data blocks minus their headers. Builder capability — write-structure, read as canReachStructure on the cards — is the header gate. Amended 2026-09-11 (Maker Fills, Builder Builds): a Maker does see the document's card — it is their door to Export — with its name and guide read-only and its mark offering Save Version, Export and, when it arrives, Share; a Reader still sees no card of any kind.

In plain terms: a card that is pure machinery — a module, the document itself — gets a light wash. Anything that will appear on the printed page stays on white paper, and a block is a printed thing, so a block is white all the way up including its header strip. A Builder sees the machinery; a person filling in or reading the document sees only the paper.

Where the law lives

The tint law is data in the shared palette, never a per-card decision:

• stack-palette.ts (shared/ui/molecules/stack/v3) holds stackChromePalette — the card wash, one cell per tone (content | data | structural | outer) × state (rest | hover | active), every cell pinned in stack-palette.node.test.ts. Keyed by tone, never entity — the palette's own contract. The all-chrome tones step through the wash tokens; content and data are white paper in every state. Amended 2026-09-30 (GB-162.1): the table used to carry a surface axis (header | card). The chrome tiers painted their whole card from the header column while the flat card column and the printing tones' accent header ladder had no caller; once the header band got its own table (stackHeaderBand, 2026-09-08) the word named two surfaces, so the axis went and the unread cells with it. The classes any card renders are unchanged.
• The shell paints the band, and declining a tone is how a kind stays white. Stack takes headerTone and headerState and paints the Stack Header row from the palette itself, so a caller states a tone and a rung rather than a background class and no per-kind bg- ternary can grow at a call site. headerTone is optional, and omitting it paints nothing. module-card passes structural, document-folio passes outer, and block-card passes none — its data header is a white row (2026-09-15), and a content block mounts no header row to pass anything to. The all-chrome kinds additionally tint their card from the card wash, through their palette adapter files.
• One gate on the block card. canReachStructure in block-card.tsx gates the data header, the kind mark, the drag grip and the Goldie trigger together, with a chromeless canvas keeping them only while the block is selected — the module header's own arrangement. A content block never mounts a header: its kind mark rides its prose row's gutter, as it always did.
• Ordering survives the missing chrome. A Maker's flat run of blocks still renders through the module Substack Portals, so document order is the arrangement's order; structural selection and drag simply have no target, and capabilities already gate the operations.

What marks a selected document is its black spine together with its header band's selected rung (A Selected Document Paints a Black Spine — rulings 3 and 6 stand, amended so the black spine is the outer ladder's own top rung).

Context

The seam question this settles was raised at the 2026-08-20 close: with the content block gaining a header (GB-123), what separates a block's chrome from its prose — a hairline divider, nothing, or colour? The owner judged three proto variants and kept variant 2: glyph in the header gutter plus the quiet tint band a module header already wears.

That answer did not survive contact with the canvas. On 2026-08-24 the owner corrected it: a block prints, and it prints without its header row, so tinting that row put a wash on a printed thing to mark a seam inside it. The answer for a block is nothing — the third of the three original options. The separation a block needs is already carried by the spine and by the role gate (a Maker never sees the row at all), so the two-channel rule holds without the band: spine says structure, background says state (ruling C), and a block's background says paper. Colour remains the seam on module and document cards, where every surface is chrome and none of it prints.

The role half generalises ruling 8 (2026-08-17, the document card is Builder-only chrome) into a family-wide presentation rule, stated for the screens in Document Work Screen and Canvas Frame.

Guards

• stack-palette.node.test.ts pins every chrome cell.
• Step2bTheHeaderBand (stack-anatomy.stories.tsx) pins both shell behaviours side by side: a stated tone paints a band, and no tone stated paints none. It is the neutral anatomy, so it demonstrates the mechanism rather than asserting which kind uses which — a block takes the second.
• BuilderContentHeader (block-card.stories.tsx) pins the content fill, the rename round trip, and the Maker's headerless block.
• HeaderFoldsGuideAndTagsAbovePaper (block-card.stories.tsx) pins that the block's strip stays white at rest now that it carries a door (GB-220, 2026-09-10): the door folds Guide and Tags above the paper, and the paper and the white strip are untouched by it.
• MakerEditingOn and MakerWithTheContentBlockLocked (editing-access.stories.tsx) pin the Maker's headerless data block against the locked Builder's read-only header.
• SlotFillByKind (folio-slots.stories.tsx) is the Live slot-fill contract: it draws a module, a data block and a content block and asserts that the first two fill the Stack Header while the content block declines it and carries its glyph on the prose row (tightened 2026-09-14 after the September deletion slipped past the earlier content-only version).
• The CapabilitiesBuilder / CapabilitiesMaker / CapabilitiesReader stories (drafting-editor.stories.tsx) pin the canvas-tier rule with one stack-header query.
• AllStates (document-stack.stories.tsx) leads with the document card at rest, the scene its tinted surface is judged in.