Why: The product needs a session mode and a place to show tool arguments on a confirmation card without inventing a second card type.
Evidence: GOWORK=off go test . passed. New fields use omitempty, so existing golden JSON stays the same.
Impact: Empty permission mode still means the profile policy. Clients that ignore unknown fields keep working.
Refs: feature/permission-hooks
Co-authored-by: Cursor <cursoragent@cursor.com>
Why: The final reply is composed after the work loop, and the automatic end check needs its own part and event so the timeline can show it without mixing it into the user-facing text.
Evidence: go test ./...
Impact: New RunPhase finalizing, PartType check, and run.check. Existing payloads are unchanged.
Refs: feature/final-reply-compose
Co-authored-by: Cursor <cursoragent@cursor.com>
Why: The chat timeline needs a persisted thinking duration, and tool duration already lives on the tool call, so the thinking part had nowhere to put it.
Evidence: go test ./... passes; the message golden now includes durationMs on the thinking part.
Impact: Additive JSON field with omitempty. Existing clients ignore unknown fields.
Refs: feature/chat-timeline-preview
Co-authored-by: Cursor <cursoragent@cursor.com>
Why: cross-session transcript reading needs per-conversation outbound
(allowCrossRead, default true) and inbound (crossPrivate, default false)
flags alongside the project-level gate; see the approved proposal.
Evidence: go test ./... passes with golden conversation.json regenerated
to exercise both wire fields.
Impact: additive contract fields (omitempty), wire-compatible for
existing clients that ignore unknown fields.
Refs: Agent-System-Documents proposals/2026-09-30-cross-session-reading.md
(Dev task feature/cross-session-reading).
Why: the approved task-centric sidebar (proposal 2026-09-30, option A) needs
server-authoritative pin and archive state on conversations; client-side
storage would be fake state against the event-sourced model.
Evidence: go test ./... passes; omitempty keeps wire format and golden
samples byte-identical for zero values (backward compatible).
Impact: additive optional fields; consumers ignoring unknown fields are
unaffected (forward-compat principle). Backend consumes via submodule bump.
Refs: Agent-System-Documents docs/proposals/2026-09-30-ui-redesign-and-auth.md (P6/P8, R1)
weichenandCursor