[kcarnold]

Closes #583. Chat becomes a coach that can also propose edits to the document, under the My Words rule: it may only place the writer's own words, and every edit needs the writer's approval. The My Words text prototype (Walkthrough/Propose) is removed; Voice stays as a prototype on the shared code.

Design write-up: docs/chat-document-tools.md.

What changed

Shared code. The My Words tool logic moved to frontend/src/docTools/ (ops, the word-bank check, apply and report, plus the new edit note, preview and undo). EditorAPI.applyEdit is now optional; canEdit(editor) decides whether edit tools are offered. Google Docs omits it (#590); Word and the standalone editor have it.

Chat context (supersedes #249). The transcript is the model's own ModelMessage[], tool calls included. Each writer turn carries a <document_context> block:

• the whole document, numbered, on the first turn;
• after that, a paragraph diff of what the writer changed since the model last looked;
• the text around the cursor.

The writer never sees this block. view re-reads the document on demand.

Proposals. str_replace, insert and move are gated in toolApproval. Each must dry-run cleanly against the current document and pass the word-bank check; otherwise it's denied with a reason the model can act on. A proposal that passes gets an approval card (summary, a trimmed preview of the change, Accept or Decline). Undo can then revert any applied edit, in any order, and refuses if the text has changed since.

Word bank:

• the live document, plus every paragraph the model has seen this conversation (so deleted words can be reinstated);
• what the writer typed;
• the brief.

Runs of content words may be stitched together from pieces that overlap by two or more words. as was dropped from the glue words because it can mean "because".

Logging. New chatLog.edit events for the proposal lifecycle (schema version 6). Content goes in proposal and offending, which are document-level in the consent gate.

Departures from #583's plan

• The app writes every answer to a proposal itself: the approval response plus the tool result. On Accept it applies the edit first, then calls the model. The SDK resolves approvals only when they're the last message, and it skips approvals that already have a result. Writing both parts ourselves keeps the history valid whatever follows: a new writer message ("set aside") or a failed model call. I checked this against the installed ai@7 source; the tests run the real SDK.
• Edits are on wherever applyEdit exists, including Word, rather than standalone only. Word may still pick the wrong text to edit (Send hosts ranges, not needles: one text-matching implementation across editors #589).
• Overlap rule instead of whole-run matching.
• Seen paragraphs count as the writer's words, so deleted text can be reinstated.
• Undo reverts any applied edit, not only the latest.

Testing

• npm run typecheck, npx vitest run (270 passing), eslint.
• New tests cover:
  • the end-to-end proposal loop through the SDK with a scripted model: word-bank denial, a no-match denial, a pending card, Accept applying exactly once without the model's edit leaking into the next edit note, and a set-aside proposal leaving a valid history;
  • the edit-note diff;
  • preview trimming;
  • undo planning, including relocation and refusal;
  • the overlap rule and its denial messages.
• Tested live in the standalone editor, including a word-bank denial and a stitched edit.

Follow-ups: #699.

🤖 Generated with Claude Code