Goldie Blocks

The Workspace Is Home; the Project Is the Sharing Grain

Owner ruling 2026-09-13 — one workspace is minted for every person and is their home screen; the Project is stored beneath it and is what gets shared; the organisation is the access record and capability rules, never a Folio kind; and no read may infer the current workspace or project from the person. Amended 2026-10-04 — the app calls that screen Home, one landing screen at /app

Decision

Every person gets one workspace, minted for them, and its canvas is their home screen: the list of their projects. Projects are stored beneath it, and the project — not the workspace — is what a person shares with someone else. The organisation is not a Folio tier at all: it is the access record and the capability rules, and it waits for a paying firm. Owner ruling 2026-09-13, on the question "should I create projects, workspaces and organisations for MVP?".

In plain terms: each lawyer gets their own desk, and the desk is what they see when they log in — their matters spread across it. A matter is what you bring a colleague into. Nobody builds the firm yet.

Home is the Workspace's screen — 2026-10-04

The app calls the person's Workspace screen Home, and there is one landing screen, not two. Owner ruling 2026-10-04 (GB-345). A separate Home page (src/pages/home, at /app) had drifted in beside the Workspace page (src/pages/folio-container, at /app/my-workspace), each listing a different slice of the same desk. They are merged: sign-in lands on the Workspace at /app, titled Home; /app/my-workspace and the bare /app/canvas redirect there; the sidebar's My Workspace entry is gone, the G at its head being the way Home.

In plain terms: the reception desk and the lawyer's own desk were two rooms with the same things on them. Now there is one desk, and the sign on the door says Home.

Home's layout, one column on the container page's own chrome (page frame, Work Bar, side panel), without the Workspace's header card:

  1. Projects first: four cards one row of cards in the person's kept drag order (the listOrders table, GB-325), still draggable, and Show more (was Show all until 2026-10-05) unfolding the rest in place. The four-card lead was reversed on 2026-10-05 by the wide canvas ruling below: the lead is one row, whatever the row holds. A Project card opens the Project page and its Documents.
  2. Recent Documents: the row the former Home computed from this browser's visits (folio/homeRecents), the shortcut straight into a document. This supersedes the 2026-09-14 correction below that kept them off Home.
  3. One line naming the person's Libraries, each a link to its page, and All Libraries to the Libraries page.

The workspace Folio kind stays in the schema and the code: a premium account may later hold a second Workspace, and Home then grows a switcher, never a new page. No read infers the Workspace from the person: Home still takes the key the account's provisioning returns and addresses the Folio explicitly, as the invariant below requires.

Nothing hides for a one-Library account. The task first asked that the search card's Library chooser and the join-a-Library flow hide while an account held one Library; the owner withdrew that the same day (2026-10-04): the app offers more than one Library from day one, so a person has their own Library and others to reach from the start, and should get into that flow early. The chooser and the join flow show whatever the count.

The former Home screen's story survives tagged deprecated as reference for the marketing page, per the story lifecycle rule; no route mounts it and no barrel exports it.

Home's wide canvas — 2026-10-05

The card column is 960 wide, the cards fill it three to a row, and Home leads each list with one row whose last cell is a Show more card. Owner ruling 2026-10-05 (GB-353), settled against the Proto study Wide Canvas (now the Live stories of the same name under Pages/FolioContainer and Pages/DocumentWork), measured at a 1088-wide window with Goldie's panel shut (a 1040 canvas) and open (a 680 canvas).

In plain terms: the desk got wider. Three matter files sit across it instead of two, each row of files ends with a small "Show more" card, and the precedent shelf below follows the same shape.

  1. The column. CanvasFrame and the page frame's lid and base rows are 960 wide (--canvas-column in src/app/app.css) when the canvas has room, 40 clear each side at 1040, and fall back to the canvas's own padding when it has not: 632 beside Goldie's open panel. Listed cards, the header card and Home's header row run the column's full width with no side inset (paperContentInsetClassName is off them), so three 304 cards fill 960 and two fill 632. Projects, Recent Documents and the Library card share one left edge and one card width.
  2. One row leads, then Show more. Reverses the 2026-10-04 ruling above that four Projects lead. Projects and Recent Documents each show columns minus one cards (never fewer than one), then a Show more card in the row's last cell, at every column count; the count is read from the grid the cards sit in, not from a number. Opened, Show less is the cell after the last card. Dragging among the leading cards keeps the folded cards' places.
  3. The Show more card is a card-sized tile in a very light wash of the card's gold (--gc-wash, a step deeper on hover), no outline, with "Show more +N ›" on one line where a card's title sits (12 from the left and the foot, 18px semibold), N muted and equal to the cards held back. Rejected the same day: an Add card in the grid, a dashed Show more tile (dashes mean staged proposals here), a solid gold tile, and the count on its own line.
  4. Libraries follow the pattern: the person's own Library card at the small cards' width, then a lightly washed indigo card "All Libraries +N ›" to the Libraries page, N the Libraries past the one shown.
  5. Headings. Projects, Recent documents and Libraries are 12px caps at the top of a 36px row that sits directly on its cards, 36 below what precedes it (HomeRowHeading), so the cards keep to the 24 grid.
  6. Filter sits on the Projects heading row, heading left and Filter right, as a split button (the reui c-button-group-17 composition from the existing ButtonGroup, Button and DropdownMenu atoms). Its left button says the status in words (All, Mine, Shared with me) and toggles the last chosen filter off and on, with aria-pressed; before anything has been chosen a press opens the menu, never a press that does nothing. Its right button is the filter icon, named "Filter Projects", and opens the choices with their counts. The chips row ("Show: Mine, Shared with me") is gone from Home; Project and Document pages keep their Filter and chips.
  7. Add stays a button on the toolbar's row, alone on the band, filled with the card's gold (--gc-tint, --gc-chip on hover); never a card.

Goldie's inbox is on the work bar — 2026-10-05

What Goldie has to say that has not been read lives in an inbox on the work bar, the top frame, at the right of the Builder / Maker switch: an inbox icon with a dot on its corner while something is unread. The first item is her welcome, the "Meet Goldie" dialog Home opens on its own the first time. The "Meet Goldie" button leaves Home's header row. Owner ruling 2026-10-05, settled against the Proto study Widgets/CanvasShell/ Goldie Inbox. It moves the 2026-10-04 "Meet Goldie" button (top right of Home's header row, carrying an unread count) to the frame every screen shares, so Goldie's inbox is one place on every page rather than a button on one page. The chip stays when nothing is unread, as the door back to her welcome and later announcements; only the dot comes and goes. Closing the welcome marks it read, as before.

In plain terms: Goldie's messages have one tray, on the shelf at the top of every page, with a dot when there is something new. The first thing in the tray is her hello.

Landed 2026-10-07 (GB-354). The inbox lives in features/goldie-inbox and the shared work bar draws it on every screen; a signed-out screen shows none. Settled in the build: the chip is the tab tray's height, 32, with the bar's own 8 gap beside it rather than a 48 slot, and wears a card button's face in the Workspace gold. The study Widgets/CanvasShell/Goldie Inbox is now Live against the real chip.

Implementation clarification — 2026-09-14

Workspace is Home and lists Projects. Recent Documents were omitted from Home by the owner's 2026-09-14 correction; the 2026-10-04 ruling above restores them beneath the Projects. Every list card uses the existing Stack parts for Label, About and the Goldie panel. Only its bottom Open action navigates; interacting with the card stays in the list. Unconnected agent conversations remain an explicit gap, independent of the working About panel.

Provisioning uses the interim browser door now, not first sign-in. That door returns the initial Workspace key; all subsequent reads and routes address a Folio explicitly. One initial Workspace is provisioned, without teaching the read layer to infer a current Workspace from an owner. Workspace has no parent crumb; Project links to Workspace and Document to Project.

The optional folios.browserClientId binds an anonymous Workspace root until sign-in replaces that seam. This is not membership and adds no Workspace table. folioVisits records browser-scoped opening times independently of containment; these records remain available as metadata but are not displayed on Home. Document operations retain their existing Document sessions. Container reads and metadata writes check the Workspace binding server-side. Container catalogue operations remain refused until their domain targets ship; provisioning and metadata edits are explicitly scoped interim entry points. No preservation migration is required for the existing dummy data.

The three rulings

  1. One workspace is minted for every person, and it is their home screen. Stored through the interim browser door now; sign-in later replaces the binding. The listing contract already makes this nearly free — "a Project canvas is the same listing with a project on top; a list screen is a listing with no top card" (packages/domain/src/folio/listing.ts). A workspace canvas is that same listing with a workspace on top, so the home screen costs a row and a route, not a screen. FOLIO_SCHEMA_KINDS already holds the word and the containment table already says a workspace holds projects; nothing is added to the ladder.
  2. The Project is stored, and it is the sharing grain. Before GB-49, Project Home at /app/canvas drew a project card reading "Smith Estate Plan" from a hard-coded constant (src/entities/project/model/project-identity.ts) above a flat list of whichever documents this browser made. Every screen, story, breadcrumb and Work Bar crumb built on that constant is work to unpick later, so the placeholder is retired by storing the thing it stands for. The Project is also the unit the buyer thinks in — advice, an engagement letter, a will and an enduring power of attorney belong to one client matter — and therefore the natural thing to share: a colleague is brought into the Smith estate, never into somebody's whole desk. The workspace stays personal, which keeps membership on one tier instead of two.
  3. The organisation is a membership question, not a kind. Who else may see this, in which role, and who pays for the seat is the access record (GB-14), server-side capability enforcement (GB-11) and pricing (GB-193, parked until the Builder-first MVP is proven). None of that becomes easier by adding a seventh Folio kind, and building it now means invitations, roles, seats and an admin surface before one lawyer has drafted one document alone. Builder First, Before Sharing already sequences it: "Do not add Maker/Reader sharing until the existing identity, access, capability, and protected-structure authorities are verified."

Where identity sits in the order — amended 2026-09-13

The container tiers do not wait for sign-in. This page first put the claim step ahead of them, on the ground that a workspace minted for the seed user is a desk with no name on it. That is true of security and false of the screens, which is the distinction that matters for sequencing: nothing in the workspace or project canvas gets harder, or gets built twice, because the person behind it is still anonymous.

Both tiers therefore land behind the door documents already use — minted server-side against the browser's session, never against an identity the client names — recorded at Root Documents Are Created Through an Interim Browser Door and held to by Content Writes Receive One Server-Constructed Authority. Extending that stated-temporary seam one tier up adds no new kind of debt.

A stored workspace makes the claim step smaller, not larger. The claim stamps a userId onto every prior authSession carrying this browserClientId, and the documents behind those sessions become portable (Auth Flow, step 5). With a workspace root, the anonymous work is adopted by re-owning one row and everything beneath it comes with it; without one, adoption walks every document the browser made.

What genuinely waits for identity is anything that turns on who a person is: sharing and membership, any claim that a project is private, and deleting the interim door itself (GB-10's own acceptance criterion). So the order is the two container tiers now (GB-49), the claim step before anyone outside the owner's own browser uses the product (GB-10), then the access record (GB-14) and capability enforcement (GB-11) before anything is shared.

The invariant this ruling protects

No read infers the current workspace or project from the person. Every query, route and component that needs one takes its key explicitly, even while a person has exactly one workspace and the answer would always be the same.

Keeping this is what makes the workspace shareable later at ordinary cost. Because the Folio store is one table keyed by kind and parentFolioKey, opening a workspace to a second person is a membership change, not a structural one. That property survives only while nothing has quietly learned that one owner means one workspace. The moment a query answers "the workspace" from the session instead of from a key, the assumption spreads into components and stories, and a membership change becomes a migration.

What sharing costs, whenever you do it

Storing an unshared workspace now adds nothing to this bill. Each line is owed at the moment anything is shared, and is the same size whether the workspace row exists today or arrives in a year:

What changesWhyWhere it lands
A membership recordfolios.owner is one string — one person. Sharing means many people to one folio, each with a role. A new table, not a change to folios.GB-14
Reads become reachability, not ownershipby_owner_and_kind answers "mine" in one index lookup. Shared means "mine, plus shared with me, plus everything beneath those" — a walk through the tree. The genuinely hard part.New work
A read authority not bound to one DocumentauthSessions carries a documentKey and folio/folioRead.ts resolves {session, document, folio} against it; listRecent is a stated exemption taking a browserClientId and no folio address (readAuthorityGuard.test.ts).Owed by GB-49 regardless — any stored parent screen needs it, so both tiers at once pays it once
Per-role capability enforcementRoles are enforced where writes land, never in the UIGB-11

Alternatives refused

  • Hard-code a placeholder workspace. Refused, and this is the ruling's centre of gravity: the project placeholder is the worked example of what it costs. A fiction on the home screen is not neutral, because navigation, stories and breadcrumbs accumulate against it every week, and the unpicking bill rises with each one. A stored row costs less on the day it is written and nothing thereafter.
  • No workspace row at all: a list screen with no top card. Genuinely available — rule 2 of The Folio Canvas Shows a Listing allows a listing with no self card, scoped by owner — and it answers the strongest objection to the tier, that a container holding one occupant is ceremony every query must step through. Refused because that objection prices the container and not the screen: a listing screen is a Folio's canvas here, so the row buys the home screen rather than a wrapper. Refused also because the owner wants a named parent on screen, and because the workspace is the thing a firm would later share; a screen with nothing behind it can be given a name but not a member.
  • Share the workspace rather than the project. Refused: it would put every matter a person holds behind one grant, which is not how a colleague is brought into a file, and it would spread membership across two tiers instead of one. The workspace may become shareable later; the project is the grain now.
  • Model the organisation as a seventh Folio kind. Refused: an organisation contains people and entitlements, not documents. Putting it in the containment ladder would make every folio read cross a tier that answers a question the ladder was not built to ask.
  • Add a nullable organisationId column now, "just in case". Refused: a column nothing writes and nothing reads is a claim the system makes about a capability it does not have, and it saves no later work — under the one-table Folio store the tier is rows.

Current versus Target

ConcernCurrentTarget
PersonOne hard-coded seed user; documents separated by a browser id on the sessionA signed-in identity owns its folios (GB-10)
WorkspaceOne stored Folio per account; its canvas is Home at /app — Projects, recent Documents, Libraries (GB-49, GB-345)A second Workspace for a premium account grows a switcher on Home; Workspace sharing can come later
ProjectA stored Folio beneath Workspace, with its own route, Label/About and pinned Documents; catalogue operation target remains undefined and refusedConcrete operation invariants and Project sharing land with their own authority
OrganisationNothingThe access record and capability rules (GB-14, GB-11), never a Folio kind

Consequences for work in flight

  • The home route changes hands. /app/canvas provisions and opens the Workspace canvas, and each Project has a routeKey of its own under /app/canvas/$routeKey. The route layer needs no new shape for this: folios.routeKey is already an optional column on any folio with a by_route_key index, and the listing contract already calls it "the route this folio answers to, on the kinds that are addressable".
  • The Work Bar crumb gains its top step. Under Work Bar Shows Where You Stand, a document's crumb names its project and a project's names the workspace; the workspace's own page has no crumb above it.
  • GB-234's frame work serves both screens. The shared canvas frame, section labels and Add-child geometry that GB-234 and the GB-236 children are settling for Project Home are what the workspace home screen will render, because both are the same listing with a different card on top.
  • Note that src/widgets/canvas-shell/ (workspace-shell until GB-260) is not the workspace tier and this ruling does not touch it: it is the page chrome — account sidebar, work bar, inspector — that every canvas screen sits inside.

On this page