Goldie on the List Screens Edits Label and Guide in Place First

Superseded in part (owner, 2026-10-01)

Rule 2 is withdrawn. On the Workspace, Project and Library pages Goldie's label and guide changes are now proposals: each is filed in the one proposals table (convex/goldie/listProposals.ts) — a proposal on a folio is a proposal, whatever its kind —, drawn on the row's card as a redline with a tick and cross, and written only when the Builder ticks — through the same About-card mutation (rule 3 stands).

In plain terms: Goldie now suggests a new name or cover note, marked up on the card, and nothing changes until you tick it.

Decision

Owner ruling, 2026-09-17, given after GB-287 landed the selected row and its one Goldie drawer on the container screens: "Focus on local in stack edits first before proposals. So agent can edit label and guide."

1. Scope first: the row's own About. On a Workspace or Project page, Goldie's conversation on a selected row may change that row's label and guide, and nothing else. No new folios, no moves, no edits to a row's children.
2. In place, not by proposal. These two edits are written directly, the way the human edit on the About card is written — an edit the reader asked for in the row's own drawer, applied to the row they are looking at. The proposal grammar (One Goldie Per Folio, GB-133) is for changes that reach beyond the folio in hand; it is not withdrawn, it is later.
3. One write path. Goldie's label write and guide write go through the same mutation the About card's editor calls. There is no second writer (one source of truth). A refusal the human path would meet, Goldie meets.

In plain terms: on the file-drawer pages, Goldie starts as the clerk who can retitle a file and rewrite the note on its cover when you ask her to, and does it straight away. Drafting changes to the papers inside, for you to approve, is the next job, not this one.

Context

The front half exists. Since GB-287 one row at a time is selected on the container screens, Goldie's drawer opens only on that row, and the drawer is the shared WorkPanel with its prompt box disabled and a "not connected yet" starter line. The page knows the folio key the drawer is for.

The back half does not fit a container yet:

• Goldie's thread is anchored to a document. folioAgentThreads stores a documentKey beside the folioKey, and opening a thread resolves the folio through the document read-authority chain, which refuses when no document is in the ancestry. A Workspace or Project key has no document behind it.
• Her briefing is the document map, the document guide and the folio's text, rebuilt every turn; her tools read that map, read a folio in it, and file a proposal against it. None of that names a container.
• The container screens identify the reader by browser client (requireBrowserFolio), not by the auth session Goldie's turn requires.

Two write paths already exist for exactly these two fields: the container rename and guide mutations in convex/folio/home.ts for a Workspace or Project, and the renameFolio and writeDocumentGuide folio operations for a document row. The ruling reuses them rather than adding a Goldie-only writer.

The binding, settled (GB-288, 2026-09-17)

Grilled against the tree before code. Two shapes were weighed: widening folioAgentThreads so documentKey becomes optional and a container thread binds by browser client, or minting an auth session for a container as the canvas has. Neither fits: the canvas table and every read through it assume a document under a session, and a container has no session because nothing on the container screens needs one.

A list-screen thread is its own binding. folioListThreads holds the browser client, the row's folio key and kind, the thread, and — for a document row only — the document's own auth session, resolved once at opening the way the About card's editor resolves it. The identity is the same one every write on these screens already uses: a Workspace or Project row is written against the browser, a document row against its session (use-folio-list-actions.ts). No new authority, no new writer.

Her two tools call the About card's mutations by reference. Set label runs the container rename or the document renameFolio; set guide runs the container guide or the document writeDocumentGuide. The tool reads the thread's binding for the identity and calls the same public mutation the editor calls, so a refusal the human meets, she meets in the same words.

A row briefing, not a document briefing. The turn is briefed with the row's kind, name, guide and what it contains, and where it sits (GB-289's placement, reused one tier up), with the scope stated: the label and the guide, nothing else. The canvas tools are not on this turn; the two in-place tools are, and only here.

Consequences

• This is a stated carve-out from the operating model in convex/goldie/instructions/ASSEMBLY.md (tools for reading, structured output for writing, proposals for structure): two write tools that mutate a row directly, for two fields, on the list screens only. The model line records the carve-out beside the rule so the two never drift.
• Goldie gains two in-place tools, set label and set guide, enabled only when her scope parameter is a row on a container screen, and both call the existing write for that row's kind.
• A container needs a session identity Goldie can bind a thread to. That is the structural piece of the work and is designed before it is built.
• The drawer on a list row is the same WorkPanel with its prompt enabled; the About card beside it re-reads the row after her write, so the reader sees the new label or guide where they always did.
• GB-133 (Guide edits by proposal on the canvas) is unchanged and still later. The two are not in tension: one is the folio in hand on a listing, the other is a change filed for approval on the document canvas.