Unprompted Turns Have a Bound of One

Decision

Goldie may take at most one unprompted turn, on the Form surface only, and then must wait for the user. Owner ruling 2026-08-10, closing the agent-turn-policy plan's Open question 4 (R8.8, R8.7, R8.17).

In plain terms: after you fill in a field, Goldie may say "you may also want to consider X" once, and then it is your turn. She does not keep talking while you are still reading, and she never starts talking on her own in the Document view or in a block's own chat.

The rule, in three parts

1. Form only. An unprompted turn is possible on Form alone. Never on Document (settled 2026-08-01: user-led posture is taken literally, and accepting a proposal is not an exception — a user who wants a follow-up asks for one). Never in the block panel, whose chat is reactive without exception (R8.17). This is the whole surface rule, not a list to extend one case at a time.
2. One, then wait. An unprompted turn is refused when the thread's most recent message was itself agent-initiated. Goldie may not volunteer twice in a row.
3. Derived, never stored. The bound is answered by reading the thread — was the last message agent-initiated? — so it needs no counter, no turn-policy record and no schema. This is consistent with No Interview Event Log. The plan's turn-policy state (R8.2) therefore collapsed to derived-with-no-schema.

The two remaining refusals are also derived: no unprompted turn while a proposal is outstanding (read from the block's proposal state), and none for a Reader, who lacks use-agent and so has no agent surface at all.

Why one, and not a counted N

A counted bound ("at most N per session") was the one answer that would have forced a persisted turn-policy record, and it is rejected for that reason as much as any other. Within the already-small territory (Form only), one-then-wait is the smallest rule that still permits initiative, and it stays correct if a later trigger is added — where "no bound" would silently stop being safe the moment the trigger set grew. Loosening later is cheap; retrofitting a bound after users have learned Goldie's rhythm is not.

The ghost prompt (Open questions 1 and 2)

The ghost prompt is the composer's placeholder text — what tells the user what this surface is for right now. It is not a turn: it is text in the input, not a message under Goldie's name.

• Q1 — agent-generated or policy-generated? The tension is latency versus aliveness: an agent-generated prompt is genuinely specific to the block but puts a model call behind a placeholder that recomputes on every selection change (a hot path, R8.10), and a placeholder that arrives a second late is its own problem. A policy-generated prompt — a pure function of role and surface — is instant and cannot be wrong. What exists chose policy-generated by construction: agentComposerPlaceholder in src/entities/agent/lib/composer-placeholder.ts derives the block-panel placeholder from role and block family with no model call, and while it stays a pure function, selection changes do not spend a turn (R8.10) is satisfied for free. The "policy by default, agent once per panel open" middle position is not adopted; it would need an owner ruling.
• Q2 — does the ghost prompt ever go quiet? Open. An input whose placeholder changes on every turn is either helpful or restless, and there may be states where the right ghost prompt is the plain one. Nobody should answer this without the owner.

Current vs Target

Consequences

• No schema, table or column may be added to remember how many turns Goldie has taken; the thread is the record.
• No agent-generated placeholder may be introduced without an owner ruling on Q1's middle position.
• Interview Flow → 4c states the refusal list; this page is the ruling behind it.