Views
Agent-generated side panels derived from the document — built-in kinds plus fully custom HTML views in a sandboxed iframe.
Views are Layer 3 of the review API: agent-generated panels rendered next to the document in the Views pane. A view is derived from the document — the agent reads the doc, computes a payload, and pushes it. When the document changes, the view goes stale and the human can click Refresh, which emits an event the agent long-polls for.
Built-in kinds
| Kind | What it shows |
|---|---|
gantt | Timeline of tasks extracted from the document (dependencies, owners), with click-through to the source text. |
coverage | Spec coverage matrix: requirements × verdict/owner/section, derived from Layer-1 annotations. |
prompts | Prompt handoff cards — per-task copy-paste prompts generated from the spec. |
digest | Stakeholder digest: TL;DR of changes, open questions, decisions, conflicts outstanding. |
custom | Your own HTML/JS UI, rendered in a sandboxed iframe. See Dynamic views. |
The kind registry is an open set — any string is accepted, but only the kinds above have built-in renderers.
Upsert semantics
POST /api/docs/:id/views upserts by kind by default ("replace": true): pushing a second gantt replaces the first. Pass "replace": false to keep several views of the same kind.
The refresh loop
Views don’t auto-regenerate (cost and surprise control). Instead:
- Human edits the document; the view shows a stale indicator.
- Human clicks Refresh on the view → the app calls
POST /api/docs/:id/views/:viewId/refresh-request. - Your agent is blocked on
GET /api/docs/:id/view-events?since=<seq>&timeoutMs=25000(long-poll) and receives arefresh-requestedevent. - The agent re-reads the document, regenerates the payload, and
POSTs the view again.
Event types delivered on the long-poll: view-updated, view-deleted, refresh-requested.
See the Views API reference for full contracts and the Dynamic views guide for authoring custom HTML views, the sandbox rules, and the postMessage bridge.