Goldie Blocks

Goldie Finds a Clause and Stages It

Owner rulings 2026-09-30 (GB-245) — Goldie searches the Libraries by index card, never by reading clause text, and lands her one best pick on the canvas through the same staged copy the search card makes; a clause the conversation staged stays within her reach; search ranks by the current block and document but filters by typed text only; the older "several candidates in place, with Replace" contract is superseded for Goldie.

In plain terms: when you ask Goldie for a clause, she looks through the precedent banks' index cards, picks the best one, and has the clerk lay an exact copy on your desk on approval, drawn with the dotted edge every on-approval copy has. She never retypes the clause. Tick it and it is in the matter; then she may offer to reword it, and that offer is an ordinary proposal on the block you just accepted.

Decision

Owner rulings, 2026-09-30, grilled against the tree. They settle how Goldie uses the Libraries and supersede, for Goldie, part of Library Search Is a Conversation.

  1. She identifies; she does not read. Goldie's search tool returns index cards only: label, guide, kind, version and what the entry holds. She chooses by key. The clause text never enters her context and she never rewrites it as the way of inserting it. In plain terms: she reads the spines, not the pages, and the copy is the bank's exact filed edition.
  2. One mechanism, and one review flow (revised later the same day). Her insertion is the same copy the Builder's search card makes: the exact sealed edition, fresh keys, lineage recorded, landed staged (folios.stagedAt) with the dashed edge. A Library pick is a proposal that carries its staged copy: filing stages the copy and files one proposal whose step is insert … source: "library", naming the copy, the entry it came from, and the alternatives passed over. Accept clears the staged mark; reject removes the copy's rows, so a rejection cannot be undone and Goldie is told to ask again. The proposal row records the outcome, so her briefing reports it like any memo, the tray settles it before her next turn, and the one-open-memo rule holds. The search card files the same proposal, under the document's conversation when one is open (else search-card), so a person and Goldie land in one state. The separate tick and cross of convex/library/stagedWrites.ts no longer draw on the canvas; the copy's card carries the proposal's.
  3. Her best pick only, with the others named. When more than one entry fits she stages one and records, in structured form, why it fits and up to two entries she passed over with why — "just right", "too narrow", "too broad" (owner, later the same day). The chat draws that choice with the proposal chip: the pick with its reason, then each alternative, pressable to stage it beside the pick through the ordinary insert. Nothing new is stored to draw it: on the canvas the choice is the proposal's own rationale and the step's alternatives; on a list row, whose copies land at once, it sits on the copy (folios.stagedChoice). The older rule that several candidates render in place with Insert, Replace and Dismiss on each (S2, S3a) is superseded for Goldie. Replace is not hers: the Builder deletes what the copy replaces.
  4. What the conversation staged is hers. Every turn is anchored to the selection at send time (Builder Goldie Lives in the Side Panel). A copy this document's conversation staged stays within her proposal reach after acceptance, whatever is selected when the Builder says "yes, reword it", mirroring the existing rule that a folio a proposal creates is hers wherever it lands. Where she may stage (owner, later the same day): a child, a sibling, or one up. From a block, a block beside it or a module after the block's module; from a module, a block at its end or a module beside it; from the document, a module at its end. Never a Document from inside one. A Document into a Project (built the same day) is the list-screen row's Goldie's: from a Project row she searches the Libraries' Documents, ranked by the Project's name and tags, and the pick lands in the Project at once, unstaged, as that Goldie's edits land (edits in place first). Her choice is recorded on the copy all the same and the row's drawer draws it with the same chip, reading "Added". One tool factory (convex/goldie/libraryTools.ts), one copy helper, one marker function serve both Goldies.
  5. Search ranks by context and filters by text. One server search serves the Builder's card and Goldie alike. Typed text (for Goldie, the request distilled) decides what shows, matched on label first, then tags, then guide. The selected folio's label, guide and tags and the document's tags lift matching entries; they never hide any. Kind is the hard rule from containment: a module sees blocks, a document sees modules. The saved Library chips bound both doors, and when the Workspace has none selected she says so rather than searching nothing silently.
  6. Nothing found offers to draft. She says nothing fits and offers to draft; she drafts only when asked (S6 kept; consistent with "ask one clear question rather than guessing"). Search comes first: when a request could be met by an existing entry she searches before she drafts, and her reply says which she did.
  7. Builder only. Staging is write-structure (S4 kept). A Maker may ask what exists and get an answer in words; nothing lands.
  8. Identity through the thread. Her tool passes no identity. The server resolves the session from the thread binding, as file-proposal does, so the account-based insert gains one internal door beside the browser door.

Where it lives (built 2026-09-30)

  • The ranking rule: packages/domain/src/library/search-rank.ts, pure, one function for both doors. The server search (convex/library/search.ts) ranks for Goldie; the search card ranks in the browser with the same rule, handed in by the feature (src/features/search-libraries/model/library-item-rank.ts) because shared UI may not import the domain.
  • Goldie's doors: convex/goldie/libraryEntries.ts (searchByThread, useFromThread, listLandedByRow for list rows), the filing shared with the search card in convex/library/proposeWrites.ts, the keep-and-return arms in convex/folio/proposalDecisionWrites.ts, her two tools in convex/goldie/tools.ts, their instruction files under convex/goldie/instructions/tools/, and the "Find before you draft" rule in builder-agent.md.
  • One copy rule: copyLibraryEntry in convex/library/insertWrites.ts, shared by the card's mutation and Goldie's door.
  • Reach: staged on the proposal scope facts, read off folios.stagedByThreadId by the filing gate.
  • The chat: withStagedMarkers in src/entities/agent/lib/staged-marker.ts, wired by the document page.
  • Proof: convex/goldie/libraryEntries.convex.test.ts and the node tests beside each pure module.

Consequences

  • S1, S4, S5's asymmetry and S6 stand. S2 and S3a no longer describe Goldie's path; the search card's tick-and-insert already replaced them for the Builder on 2026-09-28.
  • The search card's label-only match retires when the server search lands; both doors must return the same ranking for the same text and context.
  • No one may add a second insertion mechanism for Goldie, or a way for her to write clause text she took from a Library entry.

On this page