One Goldie Per Folio, One Agent Definition

Thread amendment — 2026-09-28

Builder Goldie Lives in the Side Panel replaces the thread per folio with one thread per document: each turn names the folio it is anchored to, chosen by the selection at send time. The anchor's scope, the whole-document briefing and the filing gate below are unchanged.

Decision

Owner ruling, 2026-09-15, settling decision-17 (filed 2026-09-12), the companion to The Side-Panel Goldie Is Maker Only.

1. Product shape: one Goldie per folio. Every folio has its own conversation thread and its own authority. Opening clause B's Goldie opens a transcript about clause B. Her memos are scoped by the GB-145 rule: propose edits to this folio and its children, propose new folios (content blocks, data blocks, modules) below. All agent edits are proposals first; nothing moves until a Builder accepts — and moving on is accepting (owner ruling 2026-09-15, Proposals → Accept and reject): the memo applies when the Builder turns to the next thing, and Reject is the one deliberate act.
2. Engineering: one agent definition, instantiated per folio. One persona, one Markdown brief, one agent class — not a different agent for modules and blocks. The folio she is anchored to is a parameter that decides her scope and which tools are enabled.
3. Context of the whole document, rebuilt every turn. Before she reads the user's message she receives a fresh briefing assembled server-side from the live tables:
   • the document map — every folio in the tree with kind, name and position;
   • the document's guide and her parent module's guide;
   • the full text of her own folio and its children (her proposal scope);
   • the neighbours' text, read-only;
   • read tools to open any other folio in the document mid-turn.
4. Reading never widens proposing. The briefing is rebuilt from the live tables each turn, so she never holds a stale picture; and scope is enforced at the filing gate on the server, never by the prompt.

In plain terms: one job description, many juniors, each assigned a clause. Each is handed the whole file to read before drafting a memo, but may only write a memo about their own clause and the clauses beneath it.

Alternatives refused

• One document-wide agent with a scope parameter and a single thread. A single transcript mixes conversations about unrelated clauses, and the thread binding the schema already carries is per folio.
• Per-folio agents with different briefs per kind. Three briefs drift; the kind-specific differences are scope and enabled tools, which the anchor parameter already expresses.
• Per-folio agents blinkered to their own folio. Drafting clause B without clauses A and C in view produces edits that do not fit the document; the briefing and read tools close this at no cost to scope.

Consequences

• Stage E (GB-248) registers one agent against Folios with the anchor folio as its scope parameter; the dormant thread binding is re-addressed to the folio key.
• GB-145's scope guard enforces self-and-children and propose-below at the filing gate, with an out-of-scope proposal refused and tested. "Below" is ruled (owner, 2026-09-15): a block's Goldie may propose sibling blocks within its parent module, and also new modules after the parent. Placement is one semantic destination: immediately after the parent module, as its sibling. She never proposes a module further down, inside another module, or above; the Builder moves an accepted module with the ordinary reorder. The same holds for a proposed sibling block: immediately after her own block. In plain terms: the junior on clause 3(b) may put up a memo for a new 3(c), and also for a new clause 4, but never for a new clause 7.
• GB-100 (read tools live on every ordinary turn) is a dependency of this model, not an optimisation.
• The Builder-role brief is authored once in convex/goldie/instructions/, replacing the legacy block-agent and document-agent briefs.

Current versus Target

• Current (2026-09-15, GB-277). One agent definition (convex/goldie/agent.ts, GPT-5.6 Luna at reasoning effort none), the Builder brief in convex/goldie/instructions/builder-agent.md, threads keyed by folio (folioAgentThreads, convex/goldie/threads.ts), a per-turn briefing rendered from the live tree (briefingText.ts), two read tools and one file-proposal tool that resolve their authority from the thread (tools.ts), and the scope guard at the filing gate. Every card's Goldie — document, module and block — is wired to the turn action by its folio key through one panel hook (src/widgets/drafting-editor/model/use-folio-agent-panel.ts, GB-201), and each panel reads its own stored thread. The canvas review controller (GB-201, src/features/review-folio-proposal) shows the filed proposal on the card it is anchored to and records the Builder's Accept or Reject there.
• Current (2026-09-15, GB-278 and GB-176). The filing gate admits a block's Goldie inserting a sibling right after herself or a module right after the module she sits in, and a module's Goldie a module right after herself, refusing every other destination; the brief and the file tool say so. A proposed insertion is drawn as a provisional card where it would land, with the whole-Folio review bar's insertion wording, and a filed text change is marked up word by word on the block's reading face.
• Current (2026-09-17, GB-289). The briefing opens with where the document sits: the Workspace and the Project it is filed in, outermost first, each with its label and the guide on its cover, read from the live rows every turn (owner: "the agent must hold the full context of where a document sits in a Workspace in a project"). She reads them and does not propose on them.
• Target. A filed fields change as tinted rows on the data block.