Open plans and HTML artifacts in a local browser canvas where the human annotates elements, chats, and approves or requests changes without leaving the page. Use when presenting a plan for review, or when feedback like "move this, change that" is easier pointed at than typed.

Plan Canvas Review loop for plans and visual artifacts: you write the artifact, the human reviews it in the browser — annotating the exact element they mean, chatting, and delivering an Approve plan / Request changes verdict — while you block on a single CLI call that returns their feedback as JSON. Inspired by [lavish axi](https://github.com/kunchenguid/lavish axi); rebuilt ECC native around the /plan confirmation gate, with zero dependencies. When to Use You just wrote a plan artifact ( .claude/plans/ .plan.md from /plan ) and need the CONFIRM/approve decision — the canvas verdict replaces a typed "yes/proceed". The user should point at what to change: reviewing designs, comparisons, reports, or any local .md / .html artifact. The user asks for /plan canvas , a visual review, or "open it in the browser". Do NOT use for: code review of diffs ( /code review ), running web apps, or remote URLs. The canvas serves local artifact files only. How It Works Invoke the CLI as ecc plan canvas — the bin shipped by the ecc universal package (on PATH after a global/plugin install; node "$CLAUDE PLUGIN ROOT/scripts/plan canvas.js" also works for plugin installs). Run it from the project you are reviewing in; it works from any working directory. It manages a detached loopback server ( 127.0.0.1:4517 ) shared by all sessions, keyed by artifact path — no session ids to track. The workflow is a plain CLI plus JSON loop, so it is model and harness agnostic: any agent that can run a shell command and read stdout drives it the same way (Claude Code, Codex, Cursor, Gemini, OpenCode, Copilot). Trigger it however your harness surfaces skills — e.g. /plan canvas in Claude Code, $plan canvas in Codex — or just run the ecc plan canvas commands directly. Stay listening, or the human talks to an empty chair Feedback only reaches you while an await is actually parked on the session. If your turn ends with nothing listening, the message sits in the queue and, from the human's side of the glass, sending appears to do nothing at all. So run await as a background task when your harness supports one (in Claude Code, a Bash call with run in background: true ). It exits the moment feedback arrives and the harness hands you the JSON, which keeps the loop alive across turns instead of dying with the foreground call. A foreground await works too, but only until the harness time limits it. Two backstops exist, and neither is an excuse to skip the above: ecc plan canvas pending lists feedback queued with no listener. Check it whenever you are unsure whether you missed something. The stop:plan canvas pending hook blocks your turn from ending while canvas feedback is undelivered, and hands you the messages. If you are reading feedback from that hook, you stopped listening too early. await prints JSON when the human acts: kind: "chat" — freeform message; answer in the canvas, not the terminal. kind: "annotation" — feedback anchored to an element ( anchor.selector , anchor.snippet show what they pointed at; anchor.textRange.text when they highlighted a passage). kind: "verdict" — approve means the plan is CONFIRMED: stop polling, end the session, and start implementing. request changes means revise the artifact (the canvas live reloads it) and keep the loop going. 3. Always respond in the canvas , then keep listening. One command does both: Every human message gets a reply in the canvas, even a one liner like "On it, rewriting the risk table now." Silence in the chat panel is indistinguishable from a broken canvas, which is exactly the failure this loop exists to prevent. Answer there, not only in the terminal. While you work, keep the chat honest with the activity indicator: await sets thinking for you the moment it hands you a batch, and reply clears it. Both states self expire, so a crashed agent decays to an honest "queued" instead of leaving the human watching dots forever. Refresh thinking if a revision takes more than a minute. 4. End when review concludes: ecc plan canvas end <file . Diagrams (Mermaid) When part of the plan is a flow, architecture, sequence, state machine, ER model, or dependency graph, author it as a fenced markdown bash ecc plan canvas open .claude/plans/notifications.plan.md ecc plan canvas await .claude/plans/notifications.plan.md → {"status":"feedback","items":[{"kind":"verdict","verdict":"approve"}]} ecc plan canvas end .claude/plans/notifications.plan.md plan is confirmed — begin implementation bash await returned annotations → edit the .plan.md (canvas live reloads) ecc plan canvas await <file reply "Reworked the risk table." → blocks again until the next response Anti Patterns Polling with timeout ms in a loop. It exists for tests. Leave the plain await running instead. Ending your turn with no await listening while the review is still open. That is the one failure the human experiences as "I sent a message and nothing happened". Reading the feedback but answering only in the terminal. The human is looking at the canvas. Reopening after a user initiated end "just to show" something. Pasting the whole plan into chat and opening a canvas — pick the canvas and keep the terminal summary to one line. Parsing the canvas chat from state files — everything you need arrives via await . Design notes and origin: [docs/design/plan canvas.md](../../docs/design/plan canvas.md).

plan-canvas