pmx-canvas 0.8.0 → 0.9.0

package/docs/product-vision-2026-09.md

@@ -1,29 +1,185 @@
 # Product Vision — September 2026
 
 **Status:** Direction accepted. Decisions are recorded where they were made (2026-09-06, 2026-09-23, 2026-09-24, 2026-09-26); a move not marked decided is still a proposal.
-**Date:** 2026-09-05; release scope updated 2026-09-29; ChatGPT plugin decision added 2026-10-03
+**Date:** 2026-09-05; release scope updated 2026-09-29; ChatGPT plugin decision added 2026-10-03; first hosted version direction added 2026-10-10; implementation progress updated 2026-10-13; architecture direction clarified 2026-10-15; post-0.9.0 sequence added 2026-10-19
 **Scope:** Where `pmx-canvas` should go, what must be fixed now, what to add, what to delete, and what is architecturally wrong. Written against `main` `e17776f6` (clean tree); revised against `561e6ec5` (v0.6.3).
 **Revisions:** 2026-09-23 (the [vision review](product-vision-review-2026-09.md) folded in; it keeps the reasoning and the full design sketch), 2026-09-24 (gate and reference-surface decisions; promise hardened; measurement split), 2026-09-26 (gate answers become attribution, not a lock; moved to 0.8). Details in git history.
 **Method:** My own position, drafted first, then stress-tested by a 54-agent panel: four fact-finders, six independent visions from different angles (context engineering, systems, product strategy, rendering, developer experience, minimalism), a merge into 14 moves, three adversarial refuters per move (evidence, feasibility, value), and a completeness critic. Where the panel refuted me, this document says so. Companion: [`product-review-2026-09.md`](product-review-2026-09.md) (the audit).
 
 ## Current plan
 
-*One page; the rest of this document is the reasoning and the detail. Updated 2026-09-28. The implementation status below is authoritative for current progress; historical diagnoses and release slots are retained as planning context, not descriptions of today's checkout.*
+*One page; the rest of this document is the reasoning and the detail. Updated 2026-10-19. The implementation status below is authoritative for current progress; historical diagnoses and release slots are retained as planning context, not descriptions of today's checkout.*
 
 **The promise.** One board is both the human's durable workspace and the agent's working memory. Agents write boards, humans shape them, boards last, link into a wiki, travel as files and links, and what the human curates is what the agent reads next.
 
-**The bet inside it.** The first half is proven by use: every real board was agent-written and human-kept. The second half, that the board changes what an agent does, has never been observed. The plan tests it early (0.7 measures, 0.8 checks) and says in advance what happens if it fails.
-
-**Decided:** the fleet layer and every node type stay (2026-09-06); boards are the wiki and the destination is "share this board" (2026-09-23); the workbench is built and checked for any size, from a narrow side pane to a full browser window, checked in Chromium at 600, 1024 and 1920 px, replacing the 2026-09-24 single 600 px reference (2026-10-05); gate answers are open to any writer and record who answered, replacing the 2026-09-24 human-only decision (2026-09-26). Home is a view listing boards, not a board; deleting a board needs an in-page confirm; backup is built in with its own schedule (2026-09-27). Board pins are the working set across boards (2026-10-05, move 0a). A hosted team server separates workspace and personal libraries (2026-10-05, Part 3). Folders are the one browsing hierarchy and links stay a graph for relations (2026-10-06, move 0). Undecided: generated surfaces (6b).
-
-**Design track, 2026-10-04:** [design.md](design.md) pairs each remaining move with the design that shows it, in waves: a foundation (one font, scale and meaning colours across all themes) first and alone, then context made visible with the curation evaluation, the board map and graph with the wiki work, the relations layer with moves 1 and 13, and the frame host with move 5. A wave is done only when function and design both pass.
+**The bet inside it.** The first half is proven by use: every real board was agent-written and human-kept. The second half, that the board changes what an agent does, has never been observed. Read instrumentation shipped early (0.7); the effect evaluation now comes at the very end of the plan (decided with the maintainer, 2026-10-19), and the plan still says in advance what happens if it fails.
+
+**Decided:** the fleet layer and every node type stay (2026-09-06); boards are the wiki and the destination is "share this board" (2026-09-23); the workbench is built and checked for any size, from a narrow side pane to a full browser window, checked in Chromium at 600, 1024 and 1920 px, replacing the 2026-09-24 single 600 px reference (2026-10-05); gate answers are open to any writer and record who answered, replacing the 2026-09-24 human-only decision (2026-09-26). Home is a view listing boards, not a board; deleting a board needs an in-page confirm; backup is built in with its own schedule (2026-09-27). Board pins are the working set across boards (2026-10-05, move 0a). A hosted team server separates workspace and personal libraries (2026-10-05; part of the hosted version, Part 4, since 2026-10-19). Folders are the one browsing hierarchy and links stay a graph for relations (2026-10-06, move 0). Undecided: generated surfaces (6b).
+
+**Knowledge direction, 2026-10-07:** The hosted version (Part 4, since 2026-10-19) extends the workspace/personal split to user-defined knowledge scopes (org → team → personal is one example template), with categories as a property of folders. Move 13 adopts evidence-backed context lifecycle from the context-decay framework. Local folder categories and card lifecycle are now implemented in Wave 3. Shared/private knowledge scopes remain future work; Jev-style classification is optional longer-term assistance. These later stages are not prerequisites for the model-independent local features or Wave 1.
+
+**Design track, 2026-10-04:** [design.md](design.md) pairs each remaining move with the design that shows it, in waves: a foundation (one font, scale and meaning colours across all themes) first and alone, then context made visible (its curation evaluation moved to plan 019 step 6 on 2026-10-19), the board map and graph with the wiki work, the relations layer with moves 1 and 13, and the frame host with move 5. A wave is done only when function and design both pass.
+
+**Wave 1 status, 2026-10-10 — context made visible: built on `main`, not released.** From the board alone a person can now see what is in the agent's context and whether its copy is current: read / not read / changed marks on pinned cards; near-a-pin (the brief carries neighbours, the dotted chip, tethers and the 600 px radius, the moment a card arrives or leaves); links that changed since a read, on the link and in the brief ("new, by codex"); board pins and Home as a library (folder tree, board cards, details, the in-context switch); the session receipt (what the agent did, per-edit descriptions with "See change", Tell <agent>, Undo per card via `snapshot.restore-node`) and the live session lens in the agent chip. Remaining: the curation evaluation, deferred to plan 019 step 6 (2026-10-19); building to the new [SeeChange](design/SeeChange.dc.html) drawing (2026-10-10); the pickup/drop pauses of a drag on large boards (per-frame cost fixed 2026-10-10). Handoff detail in plan 016. **Dropped 2026-10-10:** Suggested cards — the agent changes the canvas directly, and an ask or a suggestion already goes through the composer. Detail and deviations: [plan 016](plans/plan-016-context-made-visible-wave-1.md), [design.md](design.md).
+
+**Near cards correction (owner decision, 2026-10-14).** Spatial curation measures
+the gap between card edges, not centres: up to five nearest unpinned cards within
+600 canvas pixels of each pin. The boundary follows the whole pinned card, and
+the UI and agent context share that geometry. This fixes large-card proximity
+without increasing the distance limit or context cap; it is not a semantic
+relation or evidence of review. This supersedes the centre-based radius above.
+
+**Escape selection correction (owner decision, 2026-10-14).** Keyboard Escape
+cancels board selection and relation/review/retired filters, or Home selection
+without leaving its view or resetting the camera. The Review queue clears its
+local filters. Menus and the review drawer close first; editable fields retain
+their drafts. This is implemented in the current acceptance batch, not a release.
+Attached-agent popovers also accept immediate Escape and return focus to the initial
+button without changing the canvas scroll or underlying selection.
+
+**Implementation and stabilization, 2026-10-12 (supersedes the remaining-work list above):** See change now
+matches its drawing, and the measured page-wide pickup/drop style cost is removed; occasional
+long drag tasks remain. The maintainer's real-agent curation evaluation is still deferred.
+
+- **Wave 2 implemented scope:** saved wiki bindings, qualified cross-board card edges and graph
+  reads, plus live Home Map/force-directed Graph with counted filters, focus and navigation
+  preserved across agent board switches. Map keeps dragged positions and neutral folder regions.
+- **Wave 3 implemented scope:** richer relations with per-board vocabularies, source/use queries
+  and provenance; folder categories and inherited card lifecycle; source-driven review, the due
+  engine, evidence-backed review UI, retirement/restore and inert recipe handoff. Acceptance fixes
+  include navigation-first Home, safe unused-category deletion, simple Review, conditional nearby
+  rings, wrapped relation legends and smooth hover handoff.
+- **Delivered on `main`:** the [combined implementation](https://github.com/pskoett/pmx-canvas/commit/11dc311732d8c12acc86dda12b269539df8fa5b3)
+  and [stabilization follow-up](https://github.com/pskoett/pmx-canvas/commit/fd63c3c611e680864d444532ca3ef7bb79cd171e)
+  are pushed. Final local gates pass 1,444 unit, 306 client and 276 headed browser tests,
+  plus 20 repeated save-race cases, fresh headed CLI E2E, live human gestures and real CLI/stdio
+  MCP checks. Independent board vocabularies persist across switching/reload. All five
+  [CI jobs](https://github.com/pskoett/pmx-canvas/actions/runs/38218734543) pass, including macOS
+  and Windows; the startup-only WAL retry resolves their concurrent-open failures.
+
+**Acceptance follow-up, 2026-10-12:** card and relation authorship now lives in hints,
+without redundant violet stars; bare relation lines retain their author hints. Read-state
+marks, pins and the session lens remain independent. Direct HTTP portal polling now wakes
+on events instead of pausing two seconds between replies. Disposable two-client portal
+checks measured about 11 updates/s instead of 0.48/s; the exact authenticated Amp container
+remains a separate owner check. Hosted MCP-app polling remains at two seconds, and SSE is
+unchanged. The same batch fixes older same-tab camera echoes interrupting newer gestures,
+immediate Escape on the shortcut reference, and stale pin replay after Clear all, with
+canonical server reconciliation, retained attention history and board-switch isolation.
+Evidence and failed-run investigations are recorded in [plan 018](plans/plan-018-connected-memory-wave-2.md).
+Final combined local gates pass 1,445 unit, 307 client and 282 headed browser cases, plus
+fresh headed CLI/stdio MCP. Its [CI run](https://github.com/pskoett/pmx-canvas/actions/runs/38302301010)
+passed Linux, macOS, browser E2E and CLI E2E; Windows was cancelled, so this batch is not
+claimed fully cross-platform green. The earlier all-five-jobs CI verifies the preceding delivery.
+
+**Owner-selected review surfaces, 2026-10-14 (implemented; owner acceptance pending, not released):**
+C1 is the compact category inspector: a searchable neutral category list, Basics / Review policy /
+Usage tabs, templates behind disclosure, Save/Cancel and a dirty-leave guard. Folder inheritance,
+card lifecycle overrides and assigned-category deletion protections remain unchanged.
+R2 is choose-then-customize: read-only workspace preset preview before a separate editor;
+saving edits the template, and explicit Use on board copies the saved vocabulary to one board.
+Existing edges and other boards remain unchanged; there is no later auto-sync.
+H2 adds a dedicated Home Review tab of individual cards with authoritative card/board titles,
+reasons and last-checked times. Scope is folder plus descendants or whole library; nonretired
+due cards or cards with source warnings count once. Unknown policy alone stays neutral;
+explicit warnings still qualify. Opening a queue item never validates it.
+Owner-approved naming: **Review** in navigation, **Knowledge review** as the page title,
+and **Review card** in the drawer. This checks context reliability, not task completion.
+V2 keeps the real rendered card visible beside a docked review drawer (lower dock when narrow),
+with one check note, Checked, still correct / Not now, and secondary Settings and history.
+Stale content/source guards and dirty Markdown guards protect validation; dismissal writes
+nothing. Read, content, validation and relevance clocks remain separate, and retire/restore are
+audited rather than validation. Canonical drawings and decisions are in [design.md](design.md).
+This selection adds no delivery, release or acceptance-gate claim to the earlier results below.
+
+**Owner acceptance alignment, 2026-10-13:** the step-by-step rehearsal exposed toolbar
+crowding with multiple sessions, inert expanded wiki links, narrow Graph control overlap,
+missing Medium cadence validation and stale HTML/graph replacements. The follow-up corrects
+these contracts without treating a manual rehearsal as owner acceptance. Failed attempts and
+the final combined verification belong in [plan 018](plans/plan-018-connected-memory-wave-2.md).
+Relation presets are shared workspace templates in **Home → Relation presets**, alongside
+Categories, not per-board settings. Applying a saved preset copies meaning ink/direction to
+one explicitly chosen board; editing or deleting a template never silently rewrites boards
+or their connections. On a board, the dropdown is only **All relations + kinds actually
+present**, with counts; there is no Custom vocabulary status. Folder categories and card
+lifecycle remain separate from relation kinds. The acceptance guide follows this distinction
+and retains the owner's results and notes. At that checkpoint this was unreleased work
+based on 0.8.2; the current release authorization is recorded below.
+The shared-Home-presets delivery passed 1,446 unit, 307 client and all 289 headed
+browser cases, plus build/typecheck/lint, coverage and fresh headed CLI/stdio MCP.
+Its [exact-commit CI](https://github.com/pskoett/pmx-canvas/actions/runs/38408653667) passed all
+five jobs, including Windows. The fresh numbered rehearsal remains separate: it reproduced
+an expanded-document blur save racing missing-board link creation. That isolated follow-up
+waits for the save before capturing the source; stale-source protection is retained. Its
+verification and integration state are recorded in [plan 018](plans/plan-018-connected-memory-wave-2.md).
+The same rehearsal's extra 390 px check exposed wrapped Graph chrome blocking the filter
+toggle and an external-writer badge crowding the context summary. The follow-up measures
+the toolbar's actual extent and compacts writer text, keeping filtering, activity and context
+reachable without changing their meaning. This does not replace the three reference-width
+gate or establish native-host acceptance.
+
+**Still open:** the owner's acceptance of everything since 0.8.2. The real-agent curation
+evaluation moved to the end of the plan on 2026-10-19. Full Relations/Flows/Uses sketch parity is not implemented: inline edge editing,
+amber lineage strokes, pair/cycle/affected badges and lineage actions remain; see
+[the design contract](design.md#build-plan). Dense Fit labels still need selection/local focus
+for detail. The actual Amp embedded context-pill opening, native Copilot/WebKit, native Windows
+UI and registry-installed execution remain unverified. Frame-host consolidation, larger-library
+scaling, board-move/audit semantics and the journal/runtime boundaries remain staged maintenance
+checkpoints, not claims of a debt-free codebase. Evidence and deviations are recorded in
+[plan 017](plans/plan-017-knowledge-categories-and-lifecycle.md) and
+[plan 018](plans/plan-018-connected-memory-wave-2.md).
+
+**Relation-navigation direction, 2026-10-13:** prioritize focused relationship reads and
+the change → impact → evidence → review loop over additional presets or decorative graph
+features. Improve authored meaning alongside this work and reuse the same semantics for
+small-chain human navigation. See [the priorities and acceptance checks below](#relation-navigation-priorities).
+This extends moves 0, 1 and 13; it is future direction, not newly delivered functionality
+or a replacement for owner acceptance.
+
+**MCP work relative to this checkpoint (2026-10-12).** The improvements below are
+planned, not part of the delivered Waves 1–3 or new prerequisites for their acceptance.
+Keep owner acceptance as the current focus. After 0.9.0 and its cleanup release, MCP
+hardening is the next batch ([plan 019](plans/plan-019-post-0.9-roadmap.md)): structured results and accurate tool annotations first, then cancellation/progress
+and subscription-aware context delivery (moves 6a and 1). Reuse the existing board,
+revision and context-read contracts; a concrete delivery bug found during acceptance
+can be fixed narrowly without pulling the whole batch forward. ChatGPT native-composer
+validation and SDK v2 evaluation stay in Part 4, which now carries the team/access work;
+the optional PMX session connection stays a Part 5 decision. No release number is assigned.
+
+**Release status, 2026-10-22:** the owner authorized review, testing and release of
+0.9.0 with the acceptance fixes. The release gates still apply; green CI does not
+certify the remaining native-host checks or deferred vision work.
+
+**After 0.9.0 (decided with the maintainer, 2026-10-19).** The sequence is: a cleanup release
+(tour debt, large-board costs, the bounded due evaluator), MCP hardening (moves 6a and 1),
+the frame host with the Wave-0 design pass (moves 5 and 9), then Wave 5 with the remaining
+relations sketch parity (moves 3 and 0), then trust and the journal. **All account and team
+work belongs to the hosted version (Part 4):** the read-only share link, comments, a second
+writer, accounts, roles and knowledge scopes. Local PMX stays single-user, and static export is
+its sharing path. Build that work once in the shared product so it serves the ChatGPT Sites
+version first and the standalone Cloudflare version (Part 5) later.
+**Evaluations come at the very end for now:** the curation-effect benchmark and its
+per-release reruns no longer precede or gate any of this work. Read instrumentation and the
+release gates in [RELEASE.md](RELEASE.md) are unchanged. This supersedes every statement
+below that puts the curation evaluation first. **Accepted risk:** several releases will build
+on the curation claim before the effect is measured; the decision is to carry that risk rather
+than reinstate an earlier gate. Detail and acceptance checks:
+[plan 019](plans/plan-019-post-0.9-roadmap.md).
+
+**Architecture clarification, 2026-10-15:** the architecture reviews strengthen the existing
+shared-product/separate-runtime direction, not a microservice split. Moves 4, 6 and 7 now
+spell out commit guarantees, writer-policy parity and authenticated authority; the
+[runtime direction](#likely-repository-structure-shared-product-separate-runtimes) defines
+ownership and shared contracts. These are future requirements, not implemented guarantees.
+Owner acceptance remains first; fix demonstrated defects narrowly,
+then prove the boundaries through a complete slice before moving packages or porting broadly.
 
 **Document import, updated 2026-09-28:** the agent-assisted v1 is implemented and verified on `main` (move 15): attach an original, explicitly request agent processing, review the returned Markdown, then add it to the board. Simple PDF, PPTX and XLSX fixtures were verified with Amp's tools. Canvas bundles no converter or OCR, does not launch an agent automatically, and does not guarantee general format fidelity.
 
 | Release scope | Content | Acceptance target (not a completion claim) |
 |---|---|---|
 | 0.7.0 — persistent boards and connected memory | Many boards, nested folders, backups, static export, README/link cards, library search, shared card text, attribution/revisions, selective copies, bounded cross-board context, agent-assisted document import, trust fixes and the 600 px gate | Release checks, installed-package smoke, browser workflows and live board checks pass; document conversion limitations and migration are explicit |
-| Next batch — scope/version to be agreed | Remaining wiki/graph work and real-agent curation evaluation; cheap-tool surface and binary distribution remain candidates, not completed work | A focused plan with its own acceptance checks; no automatic carry-over of the old 0.8 bundle |
+| After 0.9.0: versions proposed in [plan 019](plans/plan-019-post-0.9-roadmap.md) | Cleanup, MCP hardening, frame host and Wave-0 design pass, Wave 5 with relations sketch parity, then trust and journal; the share link ships with the hosted version; the curation evaluation last | Each release ends on plan 019's checks and explicit release approval; no automatic carry-over of the old 0.8 bundle |
 
 **Release decision, 2026-09-29:** package the completed batch as **0.7.0**, not
 0.8. Static export and the connected-memory features move into this release;
@@ -46,6 +202,17 @@ and its fixes as groundwork; pause further full-plugin release work. This is a
 sequencing decision, not authorization to build or launch hosted PMX now, and it
 does not change local PMX Canvas's existing distribution.
 
+**Hosted direction, 2026-10-10 (revised 2026-10-19: accounts and team features are built in
+the hosted version, not before it):** the first hosted version targets ChatGPT Sites with OpenAI login and the MCP server hosted
+there too. This is the first product validation, with the ChatGPT plugin as its
+distribution channel. If it works and people adopt it for recurring work, the
+next ambition is a full PMX Canvas service hosted directly on Cloudflare
+(Part 5). Access by other agents through OAuth using their user's OpenAI login
+remains a target. Sites login and its ChatGPT/Codex MCP plugin are documented;
+arbitrary external-client OAuth remains a separate validation gate. See Part 4
+for the live probe's discovery/registration blockers, node compatibility
+assessment and acceptance targets.
+
 **Hold the line.** No host-compatibility work jumps the queue until 0.7 ships, with two exceptions: regressions the reference project catches, and a bug that blocks the maintainer's real work in the host they use daily (today the Copilot app, a WebKit pane the Chromium reference does not cover). The second exception is narrow on purpose: it covers a board that cannot be used, not a tile that paints late or a host the maintainer is only testing.
 
 ## The one-line vision
@@ -54,9 +221,9 @@ does not change local PMX Canvas's existing distribution.
 
 > **Think with your agents on boards that are still there next week.** Every session lands on a named board, the boards link into a wiki you can see as a map, the agent reads what you curated, and you can share or present a board with anyone.
 
-**Both halves, and which one is the bet.** The board being the human's durable workspace, written by agents, is proven: every real board was agent-written from the maintainer's prompts and then shaped, pinned, presented and returned to. The board being the agent's working memory, read and acted on, is a hypothesis: nothing yet shows an agent reading the board and behaving differently because of it, canvas steering has gone quiet, and the conversation lives in the host's chat. The vision holds both as one loop, so it has to prove the second half rather than let it ride on the first. Two things make that possible. Every node type needs a text form that carries its meaning, because a board that is rich for a human (decks, charts, drawings) is nearly opaque to an agent otherwise (move 1). And the loop is measured, with a rule decided in advance (Part 1, item 4).
+**Both halves, and which one is the bet.** The board being the human's durable workspace, written by agents, is proven: every real board was agent-written from the maintainer's prompts and then shaped, pinned, presented and returned to. The board being the agent's working memory, read and acted on, is a hypothesis: nothing yet shows an agent reading the board and behaving differently because of it, canvas steering has gone quiet, and the conversation lives in the host's chat. The vision holds both as one loop, so it has to prove the second half rather than let it ride on the first. Two things make that possible. Every node type needs a text form that carries its meaning, because a board that is rich for a human (decks, charts, drawings) is nearly opaque to an agent otherwise (move 1). And the loop is measured release by release, with a fixed benchmark (Part 1, item 4).
 
-Human attention helps select the agent's context; it does not define the whole product. Explicit steering directs agents; annotations, pins, connections, and grouping inform relevance, while spatial layout and human camera attention can contribute weaker cues. The server compiles one budgeted brief for every agent turn. Everything the agent has to say to the human is a card on the board, never a row in a side table. The board owns its own store and its own history, and reaches remote agents through its own authenticated network mode. One journal records every write by either side, so time on the board can be scrubbed like a video. In the long run a board is shared: first as an exported file, then as a link, then with comments and a second writer. That is the destination, not hosted multi-tenant multiplayer (Part 3).
+Human attention helps select the agent's context; it does not define the whole product. Explicit steering directs agents; annotations, pins, connections, and grouping inform relevance, while spatial layout and human camera attention can contribute weaker cues. The server compiles one brief for every agent turn, paged so it never floods a host. Everything the agent has to say to the human is a card on the board, never a row in a side table. The board owns its own store and its own history, and reaches remote agents through its own authenticated network mode. One journal records every write by either side, so time on the board can be scrubbed like a video. In the long run a board is shared: first as an exported file, then as a link, then with comments and a second writer. Export is local (Part 3); since 2026-10-19 the link, comments and a second writer are built in the hosted version (Part 4).
 
 **Purpose clarification:** pmx-canvas supports **knowledge work broadly**, including research, analysis, dashboards, planning, discovery, coordination, and orchestrating coding or other work. These are examples, not a closed list or a coding-only boundary. Its promise is to help humans and agents do the work, carry useful understanding into the next task, and see known changes and uncertainty in the context they use. The [companion vision](product-context-vision-2026-09.md#position) explored a separate memory graph and wiki; as of 2026-09-23 that role is played by the boards themselves (move 0), and its publication and audience guidance waits until sharing reaches a second writer. Contributing to memory does not automatically make every item a confirmed fact or shared organizational knowledge; attention does not grant approval or sharing permission.
 
@@ -74,7 +241,7 @@ This scope supersedes the original 0.7/0.7.x/0.8 split.
 | Connected boards (moves 0, 14) | README designation, text-only board-link cards, backlinks, library search, selective inactive board copies | Wiki syntax, board map, direct cross-board card edges, make-board/inline-board gestures remain planned |
 | Agent context (Part 1, move 1) | Shared per-type card text, persisted authorship/content revisions, bounded linked/same-folder context, opt-in durable consumer cursors, read instrumentation | Controlled retrieval checks are not the real-agent evaluation of whether curation improves outcomes; the full proposed ranker is not complete |
 | Trust (move 7) | Refused-write toasts, redirect filtering, workbench-token attribution and attributed ask answers including self-answers | Local attribution is not proof of human intent; per-writer remote authentication/sharing remains planned |
-| Sharing and presentation (moves 11, 12) | Static HTML export with explicit content choices; tours shipped in 0.6.5 | Read-only live share links remain planned; a colleague's use is a separate milestone from browser tests |
+| Sharing and presentation (moves 11, 12) | Static HTML export with explicit content choices; tours shipped in 0.6.5 | Read-only live share links ship with the hosted version (Part 4, decided 2026-10-19); a colleague's use is a separate milestone from browser tests |
 | Document context (move 15) | Original attachments, explicit processing consent, agent draft/review/commit, source-linked searchable Markdown, cancellation, retention and export privacy | Extraction depends on host tools; no bundled converter, OCR or general chart/formula fidelity guarantee |
 | Pane UX (moves 5, 9) | Chromium 600 px reference gate and Home folder polish | Unified frame host, frame budget and broader renderer consolidation remain planned |
 
@@ -137,14 +304,14 @@ What still holds from the test boards: steering is the most exercised human verb
 
 Move 0 comes first, so real boards stop being overwritten. Then three changes that everything in Part 2 stands on (items 1, 3 and 4), each worth shipping on its own, and one that waits (item 2).
 
-1. **One read.** `canvas://context?budget=N` is the only thing an agent reads per turn: pinned nodes first, then what changed since this consumer's last read (a stable seq cursor), then human-authored nodes, then open asks and undelivered steers for this consumer, then boards pinned on the board map and boards one link away (move 0), each as its README summary and pinned card titles. Finished work-item chatter, delivered steers and system notes never enter it; decisions and outcomes do, including those on past boards, because a completed decision can be the most important context a month later. Everything else stays reachable by explicit pull. It folds 10 of 14 resources into the one read and turns spatial analysis (clusters, neighborhoods, reading order) into an input to the ranker rather than a separate resource.
+1. **One read.** `canvas://context?budget=N` is the only thing an agent reads per turn, and since 2026-10-07 it is a map, not a dump: titles, short summaries and relations, the local neighbourhood of the relation graph (move 0), from which the agent pulls what it decides to read in full. It carries pinned nodes first, then what changed since this consumer's last read (a stable seq cursor), then human-authored nodes, then open asks and undelivered steers for this consumer, then boards pinned on the board map and boards one link away (move 0), each as its README summary and pinned card titles. Finished work-item chatter, delivered steers and system notes never enter it; decisions and outcomes do, including those on past boards, because a completed decision can be the most important context a month later. Everything else stays reachable by explicit pull. It folds 10 of 14 resources into the one read and turns spatial analysis (clusters, neighborhoods, reading order) into an input to the ranker rather than a separate resource. **The human sees a cost, not a budget (decided with the maintainer 2026-10-08):** the context summary shows what the brief costs in tokens, and the host's own count of the agent's whole context when an adapter reports it. There is no share, meter or clipped warning; `budget` is an internal page size, and a brief longer than one page continues on the next read.
 2. **The board fills itself (later, opt-in).** Scheduled after 1.0 and off by default: files, diffs and test output fit coding sessions, not PM boards, so a board opts in and the projection lands collapsed. Nobody on the panel proposed this and it is the cheapest radical move available: stop requiring the agent to remember to call `canvas_node`. A Claude Code hook, the Copilot extension and the Codex heartbeat project the session onto the board, meaning files touched, diffs, test output and the plan, into a session lane the human then curates from abundance. Today a node exists only when an agent decides to write one.
 3. **Author on every node.** The `nodes` table has no writer column. Source provenance is persisted in node data (`canvas-provenance.ts`: where the content came from and how it refreshes), but who wrote a node lives only in the in-memory mutation history, which dies on restart. Add `author`, human or agent id, beside the existing provenance rather than as a second provenance system. The compiler ranks human-written above agent-written, the board can show who wrote what, and a shared board needs it later anyway.
 4. **Measure the thesis.** Until this exists, "pins shape the agent's context" is a belief, not a finding. Two questions, measured separately because they fail for different reasons:
    - **Delivery: does the brief reach the agent?** Record which resources each agent session reads and whether the pinned nodes were in what it read, per host. A miss here is plumbing (the skill, an adapter's per-prompt injection, the MCP client), and the answer is to fix the adapter, not to doubt the thesis.
    - **Effect: when it arrives, does curation change the work?** One fixed eval under `docs/evals/`: the same task, with the brief delivered, on a curated and an uncurated board, scored on criteria written before the first run. With one real user, real sessions cannot carry statistical weight; the eval is the test, and real sessions only confirm or contradict it.
 
-   The decision rule, set now so the result cannot be argued away later: only a failure on effect changes course. If the curated board does not beat the uncurated one once delivery is confirmed, the vision says so, stops investing in attention ranking and the brief beyond what already ships, and puts that effort into the human side (the wiki, sharing, tours). If it does, the brief becomes the product's headline and the attention heat (the payoff section) moves forward.
+   **Continuous improvement, not a verdict (decided 2026-10-07; evaluation rule corrected with the maintainer 2026-10-10).** The eval ([curation-effect](evals/curation-effect.md)) is a benchmark rerun on every release that touches the brief, pins, budgets or adapters. Track absolute answer quality on both curated and uncurated boards, delivery reliability and retrieval cost. The curation gap (curated minus uncurated score) diagnoses the contribution of curation; it is not a target to maximise. Better uncurated answers can narrow the gap without regression, and worse uncurated answers can widen it without improvement. Investigate repeatable quality or cost regressions under comparable conditions and fix broken delivery; three runs per condition are diagnostic, not a statistical release gate. Each lost rubric line feeds the improvement backlog. This replaces the 2026-09 one-off decision rule and the later gap-growth requirement. **Moved to the end, 2026-10-19:** the effect eval and its reruns wait until the end of the plan; the delivery half (read instrumentation) stays.
 
 ## Part 2: The shape I believe in
 
@@ -160,30 +327,127 @@ The move the evidence demands before any other. A workspace holds many named boa
 - **Home and levels (superseded by the line above for the tree; links unchanged).** *Revised 2026-09-27: Home is not a board but the view shown when no board is open, listing your boards most recent first and filed in categories the human (or an agent) assigns ([plan 012](plans/plan-012-many-boards-stage-1.md)); boards no portal links to form the top level. Categories are the library's first human-made structure, so the cross-board brief (Part 1, item 1) should rank boards in the open board's category above the rest.* Originally: Home is the board a workspace opens on (level 0). A **portal**, a new `board` node type, is a card that stands for another board, and a board's level is its shortest distance from Home through portals. Levels are derived, never stored; there are no fixed tiers; a board may sit under several parents; cycles are allowed; boards no portal reaches appear in an "Unplaced" lane.
 - **Links.** Portals, plus `[[Board]]` and `[[Board#Card]]` in markdown cards, resolved to ids on save so renames do not break them. Unresolved links offer "Create board"; every board lists its backlinks. Portals render text only (title, README summary, last touched, pinned card titles), never a live board, so nesting cannot multiply iframes.
 - **The board map is a board.** A generated board of boards and links, built like the code graph (`boardmap-` auto-edges, out of history, debounced), with positions the human drags kept. Pinning a board on the map pulls it into the brief (Part 1, item 1). Map pins are workspace-level: they belong to the library, not to the map board, so they feed the brief whichever board is active. It is called the board map to avoid confusion with the `graph` chart node type.
+- **A changed connection is marked on the connection (decided with the maintainer 2026-10-08, option C of [LinksOptions](design/LinksOptions.dc.html)).** Text and links are tracked apart per card. A link a person adds or edits says "not seen by <agent>" on its pill until a brief carries either end; a link an agent drew says "by <agent>". The agent is whichever agent is attached (Claude, Codex, Copilot or any other), never a fixed name. Cards keep their read marks; only a text change is amber ("changed"), and the context panel lists "links changed" in neutral. A link change still reaches the next brief through the card's links revision.
+- **One relation graph, two readers (decided with the maintainer 2026-10-07).** The canvas is the agent's extended memory across cards and boards, so the relations are one projection with two readers. Its nodes are boards and cards; its edges are portals and `[[links]]`, card edges and cross-board card links, with folder membership for grouping. Home's Graph view ([HomeGraph](design/HomeGraph.dc.html)) draws it for the human, with what is in the agent's context marked and a "local graph, depth N" around the focus. The agent reads the same projection as `canvas://graph{?focus,depth}`: the local graph around a board, a card or the pins, each node with its title, short summary and in-context mark, and ids that `canvas_node`/`canvas_board` pull in full. The brief (Part 1, item 1) is this graph's depth-1 neighbourhood of the open board and its pins; the agent walks further through `canvas://graph` and decides what to read. One projection, built like the code graph, so what the human sees and what the agent navigates cannot drift. Ships with wave 2's Map and Graph.
+
+  **Shared settings, local filters (decided 2026-10-13).** Relation presets belong to the
+  workspace's Home library, like Categories. They are editable templates, not classifications
+  assigned to cards and not board filter options. Explicit application copies a template's
+  vocabulary onto a chosen board without changing existing relation kinds or reasons. Each
+  board's dropdown lists its actual relation kinds and only changes the view. Unclassified
+  lifecycle stays unknown; it does not create a Custom vocabulary category or badge.
 - **Growth by gesture.** "Make board" turns a group into a board and leaves a portal; "Inline board" reverses it. Group, board and board of boards are one scale.
+  **Wave 5 maintenance checkpoint (2026-10-11):** define how board-qualified relations,
+  provenance and review records move before implementing these gestures. Moving a card must
+  preserve its outside links and audit identity; copying a claim must not invent a validation.
 - **Search across boards.** The ⌘K palette searches the whole library, not just the open board: board names, README summaries, card titles and card text, with the board each hit lives on. A wiki a human cannot search is a pile; the agent's `canvas_query` search gains the same library scope.
 - **Backup.** Once boards are the wiki, `canvas.db` holds the whole library, its history and its snapshots in one file. `pmx-canvas backup` writes a consistent copy (`VACUUM INTO`, safe while the server runs) to a folder the human chooses, keeps the last N, and runs on a schedule the human sets; `pmx-canvas restore` brings one back. It is a local file, so the no-externals rule holds. The per-board folder export in move 4 is the human-readable companion, not a substitute.
-- **Agent surface.** `canvas://boards` (the library: README summary, folder, links, backlinks, last touched; levels dropped 2026-10-06), a `board` target on every operation with the MCP session bound to one board, and a `canvas_board` composite (22 → 23 tools, with the freeze test and all four transports updated together).
+- **Agent surface.** `canvas://boards` (the library: README summary, folder, links, backlinks, last touched; levels dropped 2026-10-06), `canvas://graph{?focus,depth}` (the relation graph above, local around a focus), a `board` target on every operation with the MCP session bound to one board, and a `canvas_board` composite (22 → 23 tools, with the freeze test and all four transports updated together).
 - **Data.** A `boards` table, `board_id` on nodes, edges, annotations, pins and snapshots, and a `board_links` projection rebuilt from portals and parsed links. The README summary is a flagged card, not a field.
 - **State, in two stages.** Stage 1 (M, not S: `board_id` on five tables, snapshots scoped per board, a `board` target on every transport): one active board per server; opening a board saves and loads; other boards are read straight from SQLite; agent writes to a non-active board are refused. Only the human changes the active board, so an agent never swaps the board the human is looking at: an agent may create a board, its session binds to whichever board is active when it starts, and a session that needs another board asks for the switch with an ask card. Stage 2 (L): state managers keyed by board, after the journal, so an agent can work on one board while the human looks at another. `CanvasStateManager` is a singleton with 400+ call sites, which is why stage 2 waits.
 
 Objection: none, the panel did not see it. Risk: the wiki sprawls. Mitigation: the Unplaced lane and staleness on the map (move 13) make neglect visible instead of silent.
 
+#### Relation-navigation priorities
+
+**Direction added at the maintainer's request, 2026-10-13, with Oracle review.** The
+numbered acceptance rehearsal found useful one/two-hop context, stable cross-board identity,
+Sources / Used by and source-driven review. These are foundations to improve, not absent
+capabilities. Dense Fit labels and manually reconstructing affected chains remain limits.
+The next investment is one working loop, not four new subsystems:
+
+1. **Focused relationship reads first.** Answer “What does this conclusion depend on?”
+   and “What uses this source?” with explanatory paths, recorded reasons, summaries and
+   review qualification, using board-qualified identities. Distinguish dependencies and
+   derivations from citations, wiki/portal navigation and board/folder membership. Include
+   recorded provenance sources as well as drawn relations, without inventing an authored
+   edge or reason. A custom label, colour or decorative arrow does not establish impact
+   semantics. State direction, scope, result bounds, omissions and how to continue; “no
+   recorded dependency” is different from “none found within this scope.” Summaries remain
+   discovery, not full reads or validation. Build on the existing graph and brief rather
+   than creating a parallel knowledge store.
+2. **Make change → impact → evidence → review the success scenario.** Show which
+   conclusions a changed source affects and why, open the relevant evidence, and record
+   deliberate per-card review or deferral. Reuse source-driven qualification and stale-review
+   guards, including existing contradiction/supersession triggers. Recomputing an inherited
+   warning is not a new validation; reviewing one card must not validate its neighbours
+   or the whole chain. Distinguish current source revisions from those recorded as checked.
+3. **Improve authored meaning alongside the read path.** Use existing board READMEs
+   to explain purpose, relationship reasons to explain the connection, and pin reasons to
+   explain attention. Explicit task requests ask for work. Pins, summaries and reasons are
+   not instructions, approval or authority. This is partly an authoring practice, not a new
+   taxonomy, schema or mandatory infrastructure layer.
+4. **Make local navigation readable for both readers.** Extend Sources / Used by into
+   small-chain exploration sharing the agent read's relationship semantics, reasons and
+   qualification. Bring the useful slice alongside the review loop, rather than waiting
+   for a complete new explorer. Preserve drafts and the human's navigation/camera; an agent
+   read must not move their view. Global Graph remains orientation, not the only way to
+   understand a dependency or inspect an affected conclusion.
+
+**Acceptance for that future improvement:**
+
+- A cross-board branching chain returns the intended upstream/downstream paths, qualified
+  identities, authored reasons and recorded provenance, with citations and membership
+  distinguishable. The human and agent agree for the same scope and observation.
+- Cycles and high-degree cards terminate within stated bounds. Partial results explain
+  omissions and continuation; continuation makes progress or explicitly requires a restart
+  after relevant changes, rather than silently mixing incompatible observations. Missing,
+  unavailable, cached, retired and unknown evidence is qualified, not presented as complete
+  or freshly validated. Existing access boundaries apply before exposing source details.
+- The rehearsal's source value 40 → 89 flags its derived conclusion but not its plain
+  citation. A genuine source change during review rejects stale evidence. Reviewing one
+  card creates no validation records for its neighbours, and summary delivery neither
+  clears full-content read state nor renews validation.
+- A person follows an affected chain, inspects evidence, records or defers review and
+  returns without losing a draft or their place. Check the actual interaction in narrow
+  panes as well as wider windows; dense Fit, sketch parity and native-host support are
+  separate checks, not inferred from Chromium rehearsal.
+
 ### 0a. Board pins: a working set across boards (S–M)
 
-**Decided with the maintainer, 2026-10-05.** Pinning works at two levels with one gesture and one look. Pin a card and its content goes to the agent; pin a board and the whole board joins the agent's working set, wherever it sits in the library. This replaces "pinning a board on the map" above and settles the review's open question of board-level pins versus map pins: there is one board pin, set from Home (folders, map or graph), the board switcher, a portal card or the open board's top bar.
+**Decided with the maintainer, 2026-10-05.** Pinning works at two levels with one gesture and one look. Pin a card and it goes first in the agent's map; pin a board and the whole board joins the agent's working set, wherever it sits in the library. This replaces "pinning a board on the map" above and settles the review's open question of board-level pins versus map pins: there is one board pin, set from Home (folders, map or graph), the board switcher, a portal card or the open board's top bar.
 
-- **What the agent gets.** The brief is tiered: the active board's pinned cards first; then each pinned board's README and its pinned cards, in full; then linked and same-folder boards as discovery only (README summary and pinned titles), as `context-brief.ts` does today. All tiers share the budget. When it runs out, a pinned board falls back to discovery and the context chip says so; nothing drops silently.
+- **What the agent gets.** The brief is a map, not a dump (decided with the maintainer 2026-10-07: "the canvas is an extended memory across cards and boards; the models are smart enough to decide"). It carries the open board's overview, then every card as title + short summary with why it was pinned and its relations, pinned cards first and the cards near them next; each pinned board as a map (README summary, folder, links and backlinks, its pinned cards as summaries); then linked and same-folder boards as discovery. The agent pulls whatever it decides to read in full; a summary is "seen", a full pull is "read".
 - **Lifetime.** Board pins belong to the workspace: they survive board switches and restarts and are removed only by a person or an agent, attributed like card pins.
 - **Read, not write.** A pinned board is context. Writes still target the active board (stage 1); a board pin never widens what an agent may change.
 - **Agent surface.** `canvas://pinned-context` gains a pinned-boards section; `canvas_board` gains `pin` and `unpin`, with the HTTP route, SDK method and CLI command kept in step. Read instrumentation (`context_reads`) already records the board of each read, so "read / not read yet" works per board.
 - **Data.** A `board_pins` table: board id, who pinned, when.
 - **Design.** Wave 1 of [design.md](design.md); drawn on the BoardPins and Home boards.
+- **Done 2026-10-10 (deferred from the 0.9.0 tech-debt sweep).** The context chip reads every pinned board's status in one request (`context-status?boards=…`), landed with the Home redesign.
 
 ### 1. One read, one brief (M)
 
 Above. **Every node type has a text form that carries its meaning.** The brief can only be as good as what each node says about itself. `summarizeNodeForAgentContext` (`src/server/agent-context.ts`) gives every type a text form today, but for the rich kinds it carries structure, not meaning: a graph passes its raw config JSON, an MCP app its tool input (nothing about what an Excalidraw drawing shows), an image its URL, an HTML deck whatever summary its author supplied. The requirement: each type states what it shows or claims in a few sentences, written by the agent that creates or updates the node and refreshed with it, with a mechanical fallback where none exists. A check per node type asserts the brief form of a sample node is non-empty prose, not a config dump. A board rich for the human must not be blank to the agent, or "one surface" is only true for markdown. Objection: ranking by "the human's camera" rests on a signal the product does not have; the server holds one global viewport that agents also write via `view.fit` and `view.focus`, so a camera ranker would rank the agent's own last focus. Accepted. The camera rides the per-tab human-presence heartbeat, viewport writes get an actor like every other write, and the camera is a weak tiebreak, never the primary axis. Primary axes: pins, delta since last read, author, recency.
 
+**Larger-library maintenance checkpoint (2026-10-11).** Wave 3's due evaluator still scans
+the library and loads each card's review history for a single-card read. Before expanding this
+path to larger shared libraries, bound narrow reads to the dependency closure, batch/index
+review summaries, and separate Home's folder aggregates from card detail. Measure long
+dependency chains and populated histories, not only empty-history fixtures. Reuse a captured
+qualification within a request, as the Wave 3 AX cleanup now does; a cross-request cache must
+account separately for source revisions, cadence boundaries, session use and retirement.
+The measured baseline and remaining costs are in
+[the Wave 3 debt review](plans/plan-009-tech-debt-backlog.md#wave-3-maintainability-review-2026-10-11).
+
+**MCP context delivery, staged after current acceptance (2026-10-12).** This is
+follow-up hardening of the implemented context/read-accounting path, not unfinished
+Wave 1 or Wave 3 functionality. Complete resource subscriptions for hosts that
+support them: advertise the capability, track subscribed URIs per connection
+and notify only the relevant subscribers. The current MCP server emits resource
+updates without that subscription bookkeeping. An update means context may be
+stale, not that the host reread it or the model used it. Preserve explicit context
+reads for hosts without subscriptions. Verify subscribe, unsubscribe and connection
+isolation; measure actual reads separately from notifications. This is available
+on SDK v1 and does not depend on the later SDK migration.
+
+**Live-library maintenance checkpoint (2026-10-11).** Map/Graph now preserve local navigation
+while agents change the server's active board. Before stage-2 concurrent board editing, replace
+that narrow browsing flag with explicit per-tab navigation and board-qualified editor ownership;
+do not broaden the singleton's write authority. Before targeting large libraries, measure graph
+fetch size, force settling and DOM paint with dense cross-board links. Keep the shared projection
+authoritative and the simulation view-local; add a worker or viewport culling only from those
+measurements, not a second relationship store.
+
 ### 2. The session projects itself onto the board (M)
 
 Above. Objection: none raised; the panel missed it. Risk: noise. Mitigation: the projection lands in its own lane at low rank; the compiler's tiers keep it out of the brief unless pinned or recent.
@@ -212,6 +476,34 @@ A folder export (one markdown file per note plus a board file in the product's o
 
 Objection (feasibility, refuted as written): "a log written by `executeOperation` and nothing else" does not describe this codebase (487 `canvasState.` references in 40 files; the SDK makes 87 direct calls). Accepted: the XL half (state as a fold of the journal) comes after move 6 collapses the SDK onto the registry.
 
+**Journal maintenance checkpoint (2026-10-11).** Establish one authoritative mutation path
+before treating state as a journal fold. Keep evidence validation and review/restore audit
+distinct from undoable content history: replay, Undo and snapshot restore must not renew
+validation or silently erase retirement. Preserve the separate read, content, validation and
+relevance clocks through the transition and test restart/replay against those invariants.
+
+**Commit and replay guarantees (2026-10-15).** The journal supports synchronization; it
+does not establish correctness on its own. Before second-writer or hosted write guarantees:
+
+- A successful committed write means its state change, change record and retry outcome are
+  durable together. Any earlier accepted/pending response is explicitly not that acknowledgment.
+  Publish committed changes, and recover missed notifications through authorized replay.
+- Check relevant revisions at commit, including layout and cross-board effects. Content
+  revisions keep their semantic meaning; do not reuse them as geometry versions. Conflicts
+  are rejected or deliberately resolved, not automatically merged by compare-and-set.
+- Retrying the same scoped request must not duplicate its effects, including a successful
+  prefix of a partial batch. Define each command's atomic scope and batch failure behavior;
+  a batch is not implicitly a transaction. Files and object storage need explicit recovery
+  across their separate commit boundaries.
+- Specify snapshot/cursor continuity and expired-cursor recovery, and recheck permissions
+  on replay. Record effects without rerunning external actions; Undo is a new checked write,
+  not permission to overwrite intervening edits or renew validation.
+
+Transactional state plus a change journal can deliver this before full event-sourced
+reconstruction. Today's polling cursor and snapshot fallback remain useful, but are not
+durable replay. This work does not block the curation evaluation or require completing
+the journal before a read-only share link.
+
 ### 5. Keep every node type; unify how they render (M)
 
 The maintainer's rule, and it is the right one: his own usage is not evidence that a node type is unused, and a node that renders any MCP app belongs in the product. So no node type is removed, and the generic `mcp-app` node stays generic. What changes is the machinery under the iframe-backed kinds (`html`, `mcp-app`, `json-render`, `graph`, `webpage`, `mermaid`), which today is spread over six components with three copies of the AX bridge and one 1,591-line frame component whose recovery ladder has produced ten rounds of black tiles (0.6.2 ships the latest as a known limitation).
@@ -220,21 +512,53 @@ One frame host for every iframe-backed kind: mounted lazily when the node is in
 
 A frame host is necessary but not sufficient while four hosts set the definition of "works". Name one **reference surface** where every node type must render, gate releases on it, and treat embedded panes as best-effort with the visible fallback. Otherwise field reports keep setting the roadmap, as they did for all of 0.5 and 0.6.
 
-**Decided with the maintainer, 2026-10-05, replacing the 2026-09-24 decision: the workbench has no single reference width.** It lives in narrow agent-host panes, the resizable side browser in the Claude desktop app, and full browser windows of any size. The gate checks three widths in Chromium: 600 px (the narrow end), 1024 px (the middle, between the layout breakpoints) and 1920 px (a full window). Every node type must paint at all three or the release does not ship. (The 2026-09-24 decision made 600 px the one reference surface.) It is nearly free and covers the Claude Code and Codex panes and full windows, and Chromium is also the engine a hosted version would target first. What it misses is WebKit, where the Copilot app pane (the maintainer's host) and most black-tile rounds live, and which every iPhone and Safari viewer of a shared link will use. Those stay best-effort behind the visible fallback and retry. Recommended trigger for adding a WebKit project to the gate: whichever comes first of Part 3 step 2 (the read-only link) or the next WebKit-only bug that reaches a release. The compiled-binary window is not an option today: headed `Bun.WebView` is not implemented ([`bun-webview-integration.md`](bun-webview-integration.md)).
+**Decided with the maintainer, 2026-10-05, replacing the 2026-09-24 decision: the workbench has no single reference width.** It lives in narrow agent-host panes, the resizable side browser in the Claude desktop app, and full browser windows of any size. The gate checks three widths in Chromium: 600 px (the narrow end), 1024 px (the middle, between the layout breakpoints) and 1920 px (a full window). Every node type must paint at all three or the release does not ship. (The 2026-09-24 decision made 600 px the one reference surface.) It is nearly free and covers the Claude Code and Codex panes and full windows, and Chromium is also the engine a hosted version would target first. What it misses is WebKit, where the Copilot app pane (the maintainer's host) and most black-tile rounds live, and which every iPhone and Safari viewer of a shared link will use. Those stay best-effort behind the visible fallback and retry. Recommended trigger for adding a WebKit project to the gate: whichever comes first of the hosted read-only link (Part 4) or the next WebKit-only bug that reaches a release. The compiled-binary window is not an option today: headed `Bun.WebView` is not implemented ([`bun-webview-integration.md`](bun-webview-integration.md)).
 
 Deletes: the `ExtAppFrame` recovery machinery, two of three AX-bridge copies, five per-type iframe implementations. Capabilities removed: none. Every deletion the earlier version of this move argued from "zero real uses" was withdrawn once the real boards surfaced; what remains is argued from cost and incident count only.
 
-### 6a. Make the tool surface cheap (S) — ready to ship
+**Wave 4 maintenance checkpoint (2026-10-11).** Consolidate frame budget, theme delivery,
+fallback and retry together rather than adding another recovery path. Reuse the existing
+shared AX bridge. Preserve authored drafts, input state, offscreen replacements and the
+painted-refresh handoff in the current browser cases. Chromium passes do not establish native
+Copilot/WebKit paint; keep that limitation explicit until separately exercised.
+
+### 6a. Make the tool surface cheap (S) — staged follow-up
+
+**Current status, 2026-10-12:** direction accepted, not implemented or a gate for
+Waves 1–3 acceptance. Scope the MCP hardening below as a separate follow-up before
+hosted work; the broader cheap-tool proposals remain candidates, not automatic
+batch scope. The schema-size figures and savings below are historical estimates;
+remeasure today's expanded operations before committing to a tool redesign.
 
 Measured on this tree, `tools/list` is 49,222 bytes across 22 tools, about 12,300 tokens that every agent pays on every session before it does anything. Two tools account for a fifth of it: one advertises 51 optional properties, another 49, because a composite flattens four actions' fields into one schema. Per-action requirements exist only in prose, so a call missing a required field passes validation and fails in the handler.
 
-Nothing structural is needed to fix most of that. Ship per-action schemas where hosts support them and a `canvas_help { op }` that returns one operation's schema on demand, so an agent loads what it uses instead of the whole surface. Add `session.start`, returning workspace, brief and inbox in one round trip, so a useful first session is about five calls. Fix the two live descriptions that are wrong today, and add the test that an action summary always equals its own action list. Put a token budget on every agent read, which is Part 1's one read.
+Nothing structural is needed to fix most of that. Ship per-action schemas where hosts support them and a `canvas_help { op }` that returns one operation's schema on demand, so an agent loads what it uses instead of the whole surface. Add `session.start`, returning workspace, brief and inbox in one round trip, so a useful first session is about five calls. Fix the two live descriptions that are wrong today, and add the test that an action summary always equals its own action list. Bound every agent read by a page size, which is Part 1's one read.
 
 This is the half the maintainer has already endorsed in direction. It removes no capability, renames nothing, and is worth roughly 10,000 tokens per session per agent.
 
+**MCP contract and request reliability (2026-10-12).** Extend the existing tool
+surface before changing SDK generations or undertaking 6b. General tools mostly
+return JSON encoded as text; the Apps profile already has structured summaries
+and safety annotations. These improvements are supported by the current SDK v1:
+
+- Add validated `outputSchema` and `structuredContent` for stable result contracts,
+  including IDs, revisions and mutation outcomes. Keep model-facing content compact;
+  retain full UI-only payloads in `_meta` where the Apps host supports it.
+- Advertise accurate read-only, destructive, idempotency and external-access hints.
+  A composite containing writes cannot be labelled read-only. Annotations inform
+  the host; permissions and revision checks remain server-enforced.
+- Carry request cancellation through the operation layer into waits and cancellable
+  I/O. Report progress for lengthy operations when the host supports it. Stopping
+  remaining work does not roll back completed edits; report partial outcomes honestly.
+
+**Acceptance:** validate representative read and mutation results against their
+advertised schemas, audit mixed-action annotations, and cancel an in-flight wait
+without leaving it subscribed until timeout. Keep local stdio behavior working.
+These are incremental contract improvements, not a new composer or session layer.
+
 ### 6b. Generate every surface from the registry (L, two releases) — pending the maintainer's decision
 
-**Status: undecided as of 2026-09-06.** The maintainer likes the simplification and the token saving, and wants more time on the restructuring. Nothing below should start before that decision.
+**Status: undecided as of 2026-09-06.** The maintainer likes the simplification and the token saving, and wants more time on the restructuring. The generated-surface redesign must not start before that decision. The shared-writer policy clarification below is independent of that redesign.
 
 The proposal: `listOperations()` becomes the single published vocabulary. Five MCP tools (`canvas_read`, `canvas_write` taking a list so batch is just a longer list, `canvas_ask`, `canvas_inbox`, `canvas_help`) replace the 22 (23 once `canvas_board` lands). The CLI becomes one generic dispatcher over operation names plus eight human commands, and the SDK becomes a typed facade over the same invoker. The API document is rendered from the registry, replacing 23,000 words of hand-written prose that has drifted at least seven times.
 
@@ -242,13 +566,23 @@ The case for it: four naming conventions for one operation (`set-focus`, `ax foc
 
 The case against, which is why it is worth thinking about: 22 named tools are self-documenting in a way that five generic ones are not, a host that renders tool names to the user shows something meaningful today, and a single write tool keyed on operation names needs a discriminated union to catch wrong-field arguments, which not every host supports yet. Generated CLI help is also usually worse than hand-written help.
 
-If the answer is no, 6a still stands on its own, and the one piece worth taking regardless is routing the SDK through the registry, since that is a trust fix rather than a surface change: the SDK makes 87 direct state calls today and 4 registry calls, so an SDK write skips the human edit lock, the scope fence and the activity feed.
+If the answer is no, 6a still stands on its own, and the piece worth taking regardless is one mutation policy and commit boundary for every supported writer. The original 87 direct SDK state calls versus 4 registry calls are historical counts, not a current inventory; the SDK now has fence and presence handling, but its direct node-update path still bypasses the registry's human edit lock.
+
+**SDK direction clarified, 2026-10-15.** Sharing policy does not require making every SDK
+method asynchronous: synchronous checks can protect both the local SDK and registry paths.
+This supersedes [plan 009's](plans/plan-009-tech-debt-backlog.md#decision-analysis-2026-07-08-maintainer-approved)
+conclusion that no further convergence is needed, not its decision to retain a synchronous
+local convenience API. All writers, including autonomous system writes, must share the
+relevant policy and commit guarantees. Cross-runtime operations with asynchronous storage
+need an explicit durable-completion contract; a Promise alone does not provide one.
+Any public API change needs its own scoped, versioned decision. This does not authorize
+compatibility shims, a second permanent command implementation or the undecided tool redesign.
 
 Objection (feasibility, refuted as bundled): the previous registry campaign took four pull requests plus a month of follow-up slices, so five refactors in six weeks will not land. Accepted: two releases, SDK first. Objection (evidence): "41 operations unreachable from MCP" is a field-count artifact; the real gap is about 14. Accepted.
 
 ### 7. Trust that is not a label (S, then M)
 
-The workbench marker is a plain header any agent with `curl` can set, so "human-only gate resolution keyed on the marker" is still theater. The server mints a secret at boot, serves it only in the workbench HTML, and human-only ops require it. Its limit, raised by the [context vision](product-context-vision-2026-09.md) and accepted: an agent running as the same user can fetch that HTML too, so the secret stops casual header-setting and makes self-approval a deliberate act of circumvention, not proof of human intent. On a local single-user board that is the honest ceiling and the docs should say so; on a shared board (Part 3 step 2 on) human-only ops key on the viewer's own token, which an agent in another person's session never holds.
+The workbench marker is a plain header any agent with `curl` can set, so "human-only gate resolution keyed on the marker" is still theater. The server mints a secret at boot, serves it only in the workbench HTML, and human-only ops require it. Its limit, raised by the [context vision](product-context-vision-2026-09.md) and accepted: an agent running as the same user can fetch that HTML too, so the secret stops casual header-setting and makes self-approval a deliberate act of circumvention, not proof of human intent. On a local single-user board that is the honest ceiling and the docs should say so; on a shared board (the hosted version, Part 4) human-only ops key on the viewer's own identity, which an agent in another person's session never holds.
 
 **Superseded 2026-09-26 (see below).** ~~Decided with the maintainer, 2026-09-24: the human answers, the requester can withdraw.~~ Approving, rejecting and answering (gates, elicitations, mode requests) are human-only. A new `withdraw` lets the agent that raised an ask close it while it is still open, with a distinct `withdrawn` status that never counts as approval, so an orchestrator can tidy up at the end of a run. Every agent-facing resolve path becomes withdraw: the `canvas_ax_gate` resolve action, the CLI resolve commands, and the Copilot extension's `resolve_approval` tool (which becomes `withdraw_approval`); the orchestration skill's "resolve gates" step becomes "withdraw open gates". This matches the orchestration skill, which already treats gates as human decisions, and removes the one tool that invited self-approval. In practice the tool matters more than the secret: an agent handed `resolve_approval` will use it. The approval flow sees little real use on the board today, so the change is cheap now.
 
@@ -256,7 +590,17 @@ The workbench marker is a plain header any agent with `curl` can set, so "human-
 
 Then: file nodes are confined by default to the workspace plus explicit allow-roots (persistence hygiene, since every host already gives the agent `cat`); the webpage fetcher follows redirects by hand and refuses any hop that moves a public fetch onto a loopback or private address, and refuses link-local (cloud metadata) addresses on every hop, while a URL the caller points at a local dev server on purpose still loads; the client bridge checks `res.ok` and shows the toast on a refused write. One reservation I am not settled on: the real boards carry file nodes for documents (weekly prioritization reports) that may live outside any repository, and default confinement would have refused them; the default should probably be a per-board allow-root list that includes the folders a PM board actually reads, not the workspace alone.
 
-The same mechanism gives the product its own remote story, without relying on anything external. A loopback-only server means Claude Code cloud, Codex cloud and the Copilot coding agent, the agents that run longest unattended, cannot reach the board at all. With per-writer tokens minted by the server (human tokens served only to the workbench, agent tokens issued per session), the server can bind beyond loopback deliberately (`--listen` plus a token), and a remote agent is just another authenticated writer. No relay, no sync service, no version-control detour. The same tokens carry the read-only share link, the second step of the sharing path in Part 3; the first step, static export (move 11), needs none of this.
+The same mechanism gives the product its own remote story, without relying on anything external. A loopback-only server means Claude Code cloud, Codex cloud and the Copilot coding agent, the agents that run longest unattended, cannot reach the board at all. With per-writer tokens minted by the server (human tokens served only to the workbench, agent tokens issued per session), the server can bind beyond loopback deliberately (`--listen` plus a token), and a remote agent is just another authenticated writer. No relay, no sync service, no version-control detour. The read-only share link no longer rides these local tokens: it ships with the hosted version (Part 4, decided 2026-10-19). Per-writer tokens and `--listen` serve the owner's remote agents; local PMX remains single-user. Static export (move 11) needs none of this.
+
+**Authority across editions (2026-10-15).** Shared and hosted access uses an authenticated
+principal (the caller and its grants), supplied by the edition's identity adapter, and one
+product permission model. Self-asserted workbench markers, `agentId` and `clientId` are
+cooperative signals, not authorization. Changing a label cannot change a caller's rights or
+assigned territory. Scope requests explicitly to workspace, board and caller independently
+of human navigation. Filter readable sources before computing titles, graph links, briefs,
+lifecycle reasons or exports; scope live events and replay to authorized subscribers too.
+This strengthens sharing, not a claim that the local boot token proves human intent, and
+does not change the decision that permitted writers may answer attributed approval gates.
 
 Correction to my own review: a human's write cannot hit the 403 fence or the 409 lock, both sit behind `if (!meta.fromWorkbench)`; the silent-failure defect is real but smaller than I wrote.
 
@@ -272,6 +616,12 @@ The workbench runs at any size: a 500 to 600 px panel inside Claude Code, Codex
 
 Both files stay, because different agents read different files (Claude Code reads CLAUDE.md; Codex, Copilot and Amp read AGENTS.md), and they stay byte-identical under the CI gate that already enforces it. Each becomes the same 120-line contract; the AX design reference moves to `docs/ax.md` and is linked from both; each "this shipped N times" paragraph becomes a test or a Biome rule where an oracle exists. Objection: the ten-time black-tile class has no executable oracle (Playwright is Chromium-only). True, and move 5 replaces the oracle ladder with a paint deadline and a visible fallback, which a test can assert; the WebKit Playwright project, when move 5's trigger adds it, covers the rest.
 
+**Maintenance with each wave (2026-10-11).** Sweep the changed subsystem for orphans,
+duplicate reads and stale public contracts. Split the large server/browser integration files
+by owning domain when those domains next change, retaining isolation and race coverage.
+Keep human browser gestures and real agent transports alongside unit tests. This is staged
+maintenance, not a broad rewrite or permission to replace behavioral checks with source matching.
+
 ### 11. Static export: the first step to sharing (M)
 
 A self-contained HTML file of one board: the renderer and the board's data in one file, read-only, with pan, zoom and card expand. It can be attached to an email or a chat message, or posted to a wiki page. No server and no authentication, and the app produces the file itself, so the no-externals rule holds. Iframe-backed nodes export their stored markup in sandboxed iframes, as they render today; a node whose content cannot be inlined (a live MCP app) exports as its last screenshot where capture is available (macOS today, see move 9) and otherwise as a labelled placeholder.
@@ -282,9 +632,50 @@ An export is a share, so Part 3's per-board rule applies to it. Portals export a
 
 Five of the real boards include agent-generated HTML slide decks, one with 15 slides, rebuilding as slides content that already existed as cards. A tour is an ordered path through a board's cards, seeded from the reading order `spatial-analysis.ts` already computes and editable by the human. Arrow keys move the camera card to card, and the current card fills the screen. Tours carry into exports and share links, so presenting and sharing are one feature. HTML decks stay as a capability; they stop being the only way to present.
 
-### 13. Recipe cards: boards that can be refreshed (M)
+**Deferred from the 0.9.0 tech-debt sweep (2026-10-08), to clean up together right after 0.9.0:** a tour's camera move saves every node's layout instead of only the viewport (`commitViewport` → `persistLayout` from the SSE camera handler) and re-reads the whole layout (`tour-control.ts`); `animateCameraPath` duplicates `animateViewport` (`canvas-store.ts`); the current-tour logic is repeated in `tour-control.ts`, `index.ts` and the viewport operation; and the SDK's `getTour()` does not return the tour position the HTTP and MCP surfaces do. They came with the tours work, not the context work, and are kept out of 0.9.0 so it does not also change tour behaviour.
+
+### 13. Context lifecycle and recipe cards (M, then later classification)
 
-The real boards are full of numbers from elsewhere: 13 metric charts, developer-experience metrics, an OKR mirror card on the live board. They go stale silently, and in a board wiki staleness is the rot. Provenance (`canvas-provenance.ts`) already records a source and refresh strategy for files, URLs, images, apps and artifacts; add one source kind, the **recipe**: the tool call and prompt that produced the card, recorded when an agent writes it. The canvas never fetches external data itself; it marks the card stale after a set age, "Refresh this board" hands the stale recipes to the attached agent, and the board map shows staleness beside last-touched time. A recipe is data, never instructions: a refresh runs only when a human asks, and the agent may decline it.
+**Direction revised with the maintainer, 2026-10-07.** Folder categories, card lifecycle,
+source-driven review and inert recipe handoff are implemented in Wave 3; see
+[plan 017](plans/plan-017-knowledge-categories-and-lifecycle.md) for scope and
+[plan 018](plans/plan-018-connected-memory-wave-2.md#remaining-wave-3-stabilization-2026-10-11)
+for verification. Claim-level review, classifier assistance and shared-audience access remain
+future work. This status does not authorize a release.
+
+Every knowledge document has a lifecycle, including Markdown cards derived from imported sources. Use the maintainer's [context-decay framework](https://github.com/pskoett/pskoett-ai-skills/tree/5a836dc7163da6799fe34ed4283da6d7f0358f14/skills/context-decay): context loses usefulness in different ways, not at one universal half-life. Its rates are qualitative planning judgments, not probabilities that a claim is true.
+
+- **What can decay.** Reality (facts change), decisions (superseded choices), dependencies (versions, owners or prerequisites change), and relevance (the task changes). A document can contain several claims with different authorities and review triggers; reviewing one never validates them all.
+- **When to check.** Fast means check at use; medium means source-appropriate cadence plus event triggers; slow means maintenance or resumed work; durable means no passive expiry. Contradictions, superseding decisions and dependency changes trigger review regardless of age. Each category can supply defaults, with explicit document or claim overrides; unclassified context stays visibly unknown rather than receiving an invented expiry date.
+  Medium requires an explicit positive cadence in days; a blank cadence or whitespace-only
+  revalidation method cannot save. Relation presets do not supply lifecycle or classify cards.
+- **Separate the clocks.** Last delivered/read by an agent, last content change, last evidence validation, and relevance to the current task are distinct signals. Reading, quoting, editing or running maintenance does not renew validation. Wave 1's read marks measure delivery and revision currency, not comprehension or truth.
+- **Record the evidence.** Keep stable document/claim identity, authority, owner, decay type/rate, revalidation method and triggers, last validated time and evidence, review outcome, and whether that outcome has been applied. Unavailable evidence leaves the review unresolved and preserves the previous validation record.
+- **Review outcomes.** Retain, revise, externalize to a maintained source, retire from active context, or leave unresolved. These are review dispositions, not an automatic age-driven state machine. Preserve sources and history; low use alone never retires a rare safeguard. Amber means “needs review,” not “false.” The brief carries that qualification rather than silently presenting stale context as validated.
+
+The real boards are full of numbers from elsewhere: 13 metric charts, developer-experience metrics, an OKR mirror card on the live board. Provenance (`canvas-provenance.ts`) already records a source and refresh strategy for files, URLs, images, apps and artifacts; add one source kind, the **recipe**: the tool call and prompt that produced the card, recorded when an agent writes it. The canvas flags review needs from the lifecycle policy and changed sources; the board map shows them separately from last-touched time. “Refresh this board” hands relevant recipes and review reasons to the attached agent. A recipe is data, never executable instructions: refresh runs only when a human asks, and the agent may decline it. Regenerating a card is not by itself evidence validation.
+
+**Decided model, 2026-10-07** (drawn in `Categories`, `CategoryEditor`, `Lifecycle`, `Lifecycle600`, `Restore` and `LifecycleVariants` in [design/](design/)):
+
+- **Category is a property of a folder,** not a second taxonomy or tag system. Folders stay the one hierarchy (move 0).
+- **It inherits down the tree.** A board filed under a "Decisions" folder gets that category and its lifecycle defaults without anyone tagging it; a subfolder may set its own.
+- **One category list per workspace,** edited by the workspace. The product ships editable defaults and starter templates (org · team · personal, solo research, product team, empty); none of those words is hard-coded.
+- **A card may override its lifecycle, never its category.** Category is set at folder (or board) level only.
+- **Categories carry no colour:** a glyph and a word, like node kinds.
+- **The board shows only "⧗ review due"** — on the card, with a short reason, only while a review is due (variant A). Rate, decay type, inheritance, the four clocks and review history live in the card's Lifecycle tab and in folder settings; "unknown" is reported per folder on Home, never per card. A healthy card shows no lifecycle line. "Review due" (outlined ⧗) and "changed since read" (filled △) are both amber and differ by glyph, word, fill and place.
+- **Retire is reversible.** Retiring removes a card from the brief only; the card stays dimmed on the board, searchable as retired, with its history. A person restores it from the Lifecycle tab; restore is recorded and is not a validation.
+
+**Dashboards and source lifecycles (decided with the maintainer, 2026-10-10).** A board can be a durable dashboard without everything it presents being durable or fresh. Classify the knowledge, not the dashboard format:
+
+- **Structure can be durable.** The dashboard's layout, navigation and selection of boards need no age-based expiry. A broken target or a change in purpose can still require maintenance; durable never means permanently correct.
+- **Sources keep their own lifecycle.** A portal to an operational-status board carries that source's review qualification, not the dashboard's durable default. Folder defaults apply to content filed there; they do not propagate across links. A locally authored metric card can override the dashboard folder's lifecycle independently.
+- **Refreshing is not validating.** Opening the dashboard, following a link or successfully fetching a source does not reset its last-validated time. Distinguish retrieval time from the source's observation/update time and evidence validation. Cached values retain their source revision or “as of” time; an unavailable source is not presented as freshly checked.
+- **Conclusions have dependencies.** “We are on track” is a separate conclusion, not just navigation. A relevant source change can flag that conclusion for review through an explicit derivation/dependency relation. A plain navigational link does not make every connected card stale, and the rest of the dashboard does not become due merely because one source changed.
+- **Expose the reason where it matters.** A portal or source-backed card surfaces “source needs review” when applicable, separately from its own lifecycle, and the agent's brief carries the same qualification. Any dashboard roll-up reports affected sources, not a blanket claim that the dashboard is false or fresh. Unreadable targets retain the locked/no-title boundary; lifecycle signals never disclose protected source information.
+
+**Model-independent first.** Categories, lifecycle metadata and review outcomes are ordinary app data, editable by people and through the existing agent interfaces. They need no classifier, particular model or external inference service. Routine private knowledge maintenance can happen during agent-assisted work, with attribution and reversible history; publishing to a wider audience remains a separate explicit action.
+
+**Optional later: typed decision assistance.** [Typesafe's Jev](https://typesafe.ai/) is a reference for bounded classification and scoring, not a required runtime or a folder model. A future replaceable classifier could suggest a category, decay type/rate or review priority from supplied evidence, returning typed choices or rubric scores with uncertainty where supported. Low-confidence or conflicting suggestions remain for review. Classification confidence is neither evidence that the content is true nor permission to publish it. No model integration is required to ship the structure or lifecycle; external inference would need explicit configuration and consent for the data sent.
 
 ### 14. New board from this board (S)
 
@@ -334,35 +725,683 @@ With one journal, a **time scrubber** replaces snapshots, the History drawer, an
 
 ## Part 3: Long term, share this board
 
-**Decided with the maintainer, 2026-09-23:** the destination is "share this board", not hosted multi-tenant multiplayer. Hosted multiplayer competes head-on with established whiteboard products that have teams, funding and their own MCP integrations. What they cannot easily be is local-first, host-agnostic, and inside the agent's pane in Claude Code, Codex, Copilot and Amp; that is where this product wins. A PM board is something its owner presents to colleagues, so sharing grows from that, one step at a time, and each step is justified only by someone using the one before it.
+**Re-scoped with the maintainer, 2026-10-19:** all account and team work moves to the hosted version (Part 4): the read-only link, comments, a second writer, accounts, roles and org/team/personal scopes. Local PMX stays single-user; its sharing is static export, and move 7's tokens and `--listen` serve remote agents, not other people. Steps 2–5 below and the team model after the table now describe hosted work. The dependencies still hold inside the hosted version (the journal before a second writer).
+
+**Decided with the maintainer, 2026-09-23; scope clarified 2026-10-10; sequencing superseded 2026-10-19 (above):** ~~this phase delivers "share this board" through local and self-hosted sharing. Part 4 adds the first managed hosted offering after the team features.~~ Hosted multiplayer competes head-on with established whiteboard products that have teams, funding and their own MCP integrations. What they cannot easily be is local-first, host-agnostic, and inside the agent's pane in Claude Code, Codex, Copilot and Amp; that is where this product wins. A PM board is something its owner presents to colleagues, so sharing grows from that, one step at a time, and each step is justified only by someone using the one before it.
 
 | Step | What it is | Needs first |
 |---|---|---|
 | 1. Export | A static HTML file of one board (move 11), carrying its tour once move 12 lands | nothing |
-| 2. Link | A read-only share link: `--listen` plus a board-scoped read token | move 7 in full |
-| 3. Comments | Viewers annotate and reply; comments are cards addressed to the owner | author on every node (Part 1) |
-| 4. Second writer | Another human writes to a shared board, with their own agent | the journal (move 4), concurrent boards (move 0, stage 2) |
-| 5. Accounts | Per-board roles (read, comment, write, answer asks), single-tenant; workspace and personal libraries | a team using step 4 |
+| 2. Link | **Moved to the hosted version (Part 4), 2026-10-19.** A local `--listen` link is only reachable on the owner's network or through a tunnel while the owner's machine is awake; hosting replaces its token model anyway. Static export stays the pre-hosted sharing path | hosted runtime (Part 4) with authenticated identity and per-board permissions |
+| 3. Comments | **Hosted version (2026-10-19).** Viewers annotate and reply; comments are cards addressed to the owner | author on every node (Part 1), the hosted link |
+| 4. Second writer | **Hosted version (2026-10-19).** Another human writes to a shared board, with their own agent | the journal (move 4), concurrent boards (move 0, stage 2) |
+| 5. Accounts | **Hosted version (2026-10-19).** Full account administration, per-board roles (read, comment, write, answer asks) beyond the minimum the link needs; org, team and personal knowledge scopes | hosted identity (Sites first, Cloudflare later) |
 
-**What Part 2 already buys.** The journal (move 4) is the sync model: an ordered log with sequence numbers, per-consumer cursors and inverse patches is exactly what multiple clients need, and node-granular edits with compare-and-set on the node version resolve concurrent human edits without operational transforms or CRDTs. Per-writer tokens (move 7) become per-user credentials; author on every node (Part 1) becomes attribution; presence is already multi-writer with identity colors; the ask node with an attributed answer becomes an ask addressed to a person or a role.
+**What Part 2 already buys.** The journal (move 4) provides ordered changes and replay for synchronization, subject to its commit, retry and authorization guarantees. Compare-and-set detects concurrent conflicts; the app must reject or deliberately resolve them, including layout and multi-card changes. Operational transforms or CRDTs are not prerequisites for this conflict-rejecting model. Per-writer tokens (move 7) become per-user credentials; author on every node (Part 1) becomes attribution; presence is already multi-writer with identity colors; the ask node with an attributed answer becomes an ask addressed to a person or a role. Existing presence labels alone do not establish authenticated users or isolated sessions.
 
 **Sharing is per board.** Sharing a board never shares what it links to. A portal to a board the viewer cannot see renders as a locked card with no title, and the viewer's brief never reaches past what they can see. This is where the [context vision's](product-context-vision-2026-09.md) publication and audience rules apply: an automatic derivative's audience cannot exceed its inputs', and publication is an explicit act, not a side effect of summarizing.
 
-**What is genuinely new at step 5.** Step 5 is a team server: the same binary run with `--listen` on a machine the team reaches, one store per team, not a multi-tenant service. Identity is the app's own (passkeys and email, federation optional later). If that server is not the owner's machine it has no workspace on disk, so file nodes become uploads with re-upload in place of the watcher. The brief is compiled from the attention of the people in an agent's session, not everyone's, so two people can work one board with different agents without steering each other's context.
+**What is genuinely new at step 5.** ~~Step 5 is a team server: the same binary run with `--listen` on a machine the team reaches, one store per team, not a multi-tenant service. Identity is the app's own (passkeys and email, federation optional later).~~ Superseded 2026-10-19: accounts live in the hosted editions, with identity from the edition (Sites login first, PMX-chosen providers on Cloudflare later). A hosted edition has no workspace on disk, so file nodes become uploads with re-upload in place of the watcher. The brief is compiled from the attention of the people in an agent's session, not everyone's, so two people can work one board with different agents without steering each other's context.
 
-**Workspace and personal libraries (decided with the maintainer, 2026-10-05).** Once a team server has users (step 5), the library splits into two scopes, shown as two roots on Home, in Map and in Graph:
+**User-defined knowledge scopes (revised with the maintainer, 2026-10-07).** This extends the 2026-10-05 workspace/personal decision. A workspace defines its own levels and categories; org → team → personal below is the example template, not a fixed structure, and nothing in the product hard-codes those words. Categories are folder properties with one list per workspace (move 13, decided model). The hierarchy organises Markdown knowledge on boards; SQLite remains authoritative and boards remain the wiki. A readable folder export represents that structure, not a second independently editable knowledge store.
 
-- **Workspace** — the meta level: the team's shared folders and boards (areas, OKRs, decisions, shared research). Members see it according to their roles.
-- **Personal** — each user's own folders and boards, private to that user by default. A user organises them freely without touching the workspace tree.
-- **Crossing the line is deliberate.** A personal board reaches other people only when its owner shares it (per-board roles) or moves it into a workspace folder. Neither happens as a side effect of a link, a pin, an agent's write or a summary — the [context vision's](product-context-vision-2026-09.md) audience rule: a derived item never reaches a wider audience than its sources.
-- **Links are safe in both directions.** A personal board can portal or `[[link]]` to workspace boards. A workspace board that links to a personal board shows a locked card, with no title, to everyone who cannot read it.
-- **Pins and the brief are per user.** Card pins and board pins (move 0a) become each user's own working set: on a shared board, my pins steer my agent, not yours. The board's README stays the shared default. A user's brief draws on their personal boards and the workspace boards they can read, never on another user's personal boards.
-- **Agents act as their user.** An agent session belongs to one user and has exactly that user's read and write rights in both scopes.
-- **Local stays one scope.** A local install has one user, so its library is the workspace and nothing changes before step 5. Step 5 adds an owner to boards and folders (none means workspace) and a user to pins.
+- **Org** — shared organisational context, such as strategy, principles and policies, filed in categories the organisation defines.
+- **Team** — team-owned context, such as objectives, decisions and research, with its own category set and links to relevant org knowledge.
+- **Personal** — each person's working knowledge, private by default, with categories they control. Personal interpretation can link to shared sources without duplicating or silently overwriting them.
+- **Categories are configurable, not inferred prerequisites.** The workspace defines one category list; folders at any level take a category, subfolders inherit it, and lifecycle defaults can be overridden per folder or card (move 13). People or connected agents can file context without a classification model. A board still has one folder; links remain many-to-many. Category names and folder ancestry do not grant access or establish truth. Authority depends on the claim: org policy, team decisions and personal experience have different sources; conflicts remain explicit.
+- **Crossing scopes is deliberate.** Sharing or moving private knowledge to a team or org audience is an explicit publication action, with the destination and sources reviewed. A link, pin, agent write or summary never widens access — the [context vision's](product-context-vision-2026-09.md) audience rule: a derived item never reaches a wider audience than its sources without an explicit authorised publication review.
+- **Links are safe in every direction.** A portal or `[[link]]` to unreadable knowledge shows a locked card with no title. A folder's place under org or team never makes personal descendants public; step 5 needs app-enforced membership and per-board roles, not folder-name permissions.
+- **Pins and the brief are per user.** Card pins and board pins (move 0a) become each user's own working set: on a shared board, my pins steer my agent, not yours. The board's README stays the shared default. A user's brief draws only on knowledge they can read across these scopes, never on another user's private boards.
+- **Agents act as their user.** An agent session belongs to one user and has exactly that user's read and write rights across scopes.
+- **Stage the delivery.** Local category folders and lifecycle metadata need neither accounts nor a model. Shared org/team membership, private personal libraries and publication enforcement arrive with the hosted version, not with Wave 1. Typed classification assistance is a separate longer-term option (move 13), never a prerequisite for either stage. Home, Map and Graph need updated drawings before these scope views are built; the existing two-root HomeTeam drawing is an earlier look ahead.
 
 **The vision it enables.** A quarterly OKR board with the PM, the team leads and each of their agents on it, every card attributed, every ask answered by the person it was addressed to, and the time scrubber showing how the plan changed and who changed it, reached from a link the PM sent after the workshop.
 
-**The constraints that hold.** No externals: history and sync are the journal, not a third-party service. Everything in move 7 is mandatory before step 2 opens a port, and MCP-app hosting of third-party apps needs a per-board allowlist once viewers are not all the owner. Multi-tenant hosting and team-wide knowledge governance are not planned; they come back only if a second team is pulling for them.
+**The constraints that hold.** Local and self-hosted PMX need no required externals: history and sync are the journal, not a third-party service. Self-hosted PMX is single-user; no supported self-hosted multi-user edition is planned. Everything in move 7 is mandatory before any server opens a port beyond loopback, and MCP-app hosting of third-party apps needs a per-board allowlist once viewers are not all the owner. Org/team/personal scopes do not themselves require an enterprise governance engine. Since 2026-10-19 they are built in the hosted version (Part 4), not before it.
+
+## Part 4: First hosted validation — ChatGPT Sites and plugin distribution
+
+**Direction decided with the maintainer, 2026-10-10.** Aim to deliver the first
+hosted version of PMX Canvas in **ChatGPT Sites**, with **OpenAI login**. The **MCP server is hosted there as well**, so
+users can reach their boards and context without running a local PMX process
+or a private tunnel.
+
+This hosted foundation enables full development and release of the **ChatGPT
+plugin**, the first distribution channel for reaching users and testing whether
+PMX becomes part of their work. Validate the ChatGPT experience and adoption
+before investing in the full standalone hosted service in Part 5.
+
+**Accounts and team work are built here, for both hosted editions (decided with the
+maintainer, 2026-10-19).** The read-only link, comments, a second writer, accounts, per-board
+roles and org/team/personal scopes moved from Part 3 into the hosted version. Build them once
+in the shared product (see [shared product, separate runtimes](#likely-repository-structure-shared-product-separate-runtimes)):
+roles, membership, scopes, publication and per-board read filtering are shared rules keyed on
+an edition-neutral principal, never on a Sites user ID. Each edition supplies runtime adapters,
+including identity, storage, lifecycle and external capabilities (ADR-002 decisions 2–3). The
+Sites version ships first; the standalone Cloudflare version (Part 5) reuses the domain rules,
+schemas and contracts without depending on Sites. Each edition owns independent records and
+storage, without automatic synchronization; memberships and role assignments never import as
+authority (board copies apply the destination's permissions), while historical attribution
+stays as provenance. Dependency checks establish source separation only: verify supported
+behavior and lifecycle guarantees on Sites, and on standalone Cloudflare when that edition is
+implemented. Cloudflare implementation is not a prerequisite for Sites.
+Prerequisites: move 7's authorization model and the extraction gate's complete slice; the
+journal (move 4) before the second writer. Authenticated identity and per-board permissions
+come before the first hosted link; full account administration and scopes can follow.
+
+**The read-only share link ships here.** It moved
+from Part 3 step 2: a local `--listen` link only reaches colleagues on the owner's network or
+through a tunnel while the owner's machine is awake, the same burden the plugin decision
+rejects for ChatGPT users. The hosted link uses the edition's identity and PMX per-board read
+rules: locked cards for unreadable boards, and briefs and exports that never reach past what
+the viewer may read. Move 7's authorization model is the shared prerequisite. A colleague
+following a link to a live board and seeing it change is a hosted acceptance check.
+
+**Native composer and board context (2026-10-12).** The plugin uses ChatGPT's
+native composer, not a second PMX chat box. PMX supplies board tools and context.
+This acceptance belongs to the hosted pilot (Part 4), not the current local
+Waves 1–3 checkpoint or renewed full-plugin work on the private tunnel preview.
+The existing Apps bridge already sends selection, pins and board context through
+capability-gated `updateModelContext`, with acknowledgment and retry; keep this
+separate from resource-update notifications. In the actual ChatGPT surface, change
+the selection, edit a pinned card and switch boards, then verify the next response
+uses the intended context and current revisions. A bridge acknowledgment alone is
+not proof of model use. If the host lacks the bridge capability, use explicit board
+reads and document the limitation rather than promising automatic context delivery.
+
+Other agents should eventually be able to connect directly to the same hosted
+MCP endpoint through **OAuth using the user's OpenAI login**. Both paths act
+as that user and respect the same board roles, knowledge scopes and personal
+privacy established by the hosted team features. External-client OAuth is a separate
+compatibility goal; its current blocker does not prevent validating the
+ChatGPT version and plugin distribution to an eligible audience first. Public
+distribution remains subject to the separate sharing and submission checks below.
+Validate browser-board sharing separately from plugin installation and connection, for
+each intended audience.
+
+**Technical validation:** a user signs in with OpenAI, creates a durable hosted
+board, and uses it through the ChatGPT plugin. Installation, account connection,
+rendering, context synchronisation and reconnect behavior work for the declared
+supported surfaces. Record node and integration limitations explicitly.
+
+**Product validation:** people beyond the maintainer install the plugin, use
+boards for real tasks and return to them across sessions. Gather evidence of
+which workflows they keep using and where the ChatGPT/Sites experience limits
+them. A successful deployment or a one-off demo alone does not justify Part 5.
+
+### Hosted product metrics
+
+**Decided with the maintainer, 2026-10-10:** the first hosted version needs
+product usage metadata and an owner/admin dashboard from the pilot onward.
+The maintainer must be able to see user numbers, overall usage, feature
+adoption and evidence of where PMX provides value. The metadata must also
+support continuous improvement of the whole project: product decisions, UX,
+reliability, performance, node capabilities and agent-context quality across
+local, ChatGPT and full hosted distributions. Carry the same metric
+definitions into the later full hosted version so results remain comparable.
+
+**Platform baseline:** Sites already supplies unique-visitor and page-view
+analytics over time, currently excluding Enterprise-owned Sites. These traffic
+counts do not establish PMX activation, retention or curation value; the product
+events below remain PMX implementation work.
+Source: [Sites analytics](https://learn.chatgpt.com/docs/sites#review-site-analytics).
+
+| Question | Product metrics |
+|---|---|
+| How many people use PMX? | Total registered users (first authenticated PMX use), new users, daily/weekly/monthly active users and active workspaces. Show selected periods and trends. |
+| Do new users reach useful work? | Activation funnel: first authenticated use → first board created or opened → first meaningful human action or successful agent operation → return to that board in a later session. Show conversion and time between steps. |
+| Do people keep using it? | Weekly retention by first-use cohort, returning users, boards revisited across sessions and retained active workspaces. Show cohort sizes and only evaluate return windows that have elapsed. |
+| What do people use? | Boards created and actively used; node creation/use by type; imports, edits, pins, links, searches and shares; MCP tool calls and context reads. Separate human activity from agent activity and break down by known client/surface. |
+| Does curation reach the agent? | Sessions with human curation followed by an agent context read; fraction of eligible read sessions that receive curated items; older-board context retrieved in later sessions. Keep delivery evidence separate from task outcomes. |
+| Where is the value? | Repeat use of curated boards, reuse of earlier knowledge and optional task-level helpfulness/outcome feedback. Pair these signals with Part 1's controlled curation-effect evaluation; activity or correlation alone does not prove improved work. |
+| What prevents useful work? | Failed operations, failed imports, reconnect failures and operation latency, grouped by feature and surface. Include stored bytes and uploaded bytes to understand usage and serving cost drivers. |
+
+**Count people and activity honestly.** Define an active user as an authenticated
+person with a meaningful product action in the period, such as an edit, pin,
+search or context retrieval. Track agent-only activity attributed to a user
+separately so autonomous loops do not appear as human engagement. Exclude
+heartbeats, background polling and retries from engagement counts; report
+anonymous visits separately. Distinguish the requesting person from the agent
+session executing a tool. Installation counts belong in the funnel only if the
+distribution platform supplies them; otherwise show first observed plugin use
+and label unavailable acquisition data explicitly.
+
+**Metadata contract.** Use a small versioned event vocabulary with an event ID,
+server timestamp, pseudonymous user/workspace IDs, session and board IDs,
+actor kind, known client/surface, operation or feature, node type where relevant,
+success/failure and duration. Include product/build version, runtime and
+structured error codes where relevant so regressions can be traced to releases
+and environments; do not collect raw error payloads that may contain user
+content. Link curation and context-read events through
+scoped IDs and revisions without copying their contents. Use server-confirmed
+events for completed operations and client events for visible interactions;
+deduplicate retries and keep the two event sources distinguishable. Mark
+maintainer, demo, test and automation traffic so it can be excluded. Unknown
+clients and unobserved outcomes stay unknown rather than being inferred.
+
+**Turn evidence into project improvements.** Make aggregated metadata available
+through an authorized query/export interface as well as the dashboard, so the
+maintainer and explicitly authorized development agents can investigate it.
+Use a repeatable loop: identify a pattern, form a hypothesis, reproduce it with
+synthetic or explicitly provided examples, make a targeted change, and compare
+the relevant measures after release. Record the evidence, expected improvement
+and verification in the issue or evaluation that drives the work.
+
+Examples include simplifying an onboarding step where users stop, fixing a node
+renderer with repeated failures, reducing latency on large boards, improving a
+context adapter that misses pinned material, and turning recurring defects into
+regression tests. Compare releases and cohorts with their sample sizes and
+instrumentation coverage; validate causal claims with controlled evaluations
+or experiments. Low use alone does not justify removing a node type, and hosted
+usage does not represent every local workflow. Improvements to shared code
+should benefit all distributions while keeping the local verification gates.
+Analytics informs prioritization and evaluation; it does not automatically
+change users' boards, rewrite the roadmap or grant agents access to raw content.
+
+**Dashboard and data boundaries.** Provide date ranges, cohort views and
+breakdowns by surface, feature and node type, with clear metric definitions,
+denominators and collection coverage. Restrict product-wide analytics to the
+service owner or explicitly authorized product admins; workspace admins see
+only their own scope. Collect behavioral metadata, not board text, prompts,
+file contents, titles, email addresses or credentials as analytics payloads.
+Document collection, access, retention and deletion behavior before the pilot.
+Local PMX keeps local SQLite and does not silently send usage to the hosted
+service; any future local telemetry is a separate explicit opt-in decision.
+
+**Acceptance:** known test journeys produce the expected user counts, funnel
+steps and retention cohorts without double-counting retries or agent loops.
+An authorized product admin can inspect real pilot usage and trace a metric to
+its definition and contributing metadata. Verify access isolation and absence
+of content/secrets in events. Report missing instrumentation as a coverage gap,
+not as zero use. Product analytics ships with the ChatGPT pilot and supplies
+the adoption evidence for the Part 5 decision. Demonstrate the improvement loop
+with a reproducible test journey: query a known friction or failure pattern,
+link it to a proposed fix and regression check, and compare versioned results.
+Use the same loop on real usage as evidence accumulates.
+
+The milestone includes the team features (since 2026-10-19) and retains local and
+single-user self-hosted distribution. The assessment below separates documented platform capabilities,
+source-level portability and deployed verification; none is interchangeable.
+
+### Platform evidence and OAuth validation
+
+**Checked 2026-10-10.** Sites provides browser sign-in and forwards the visitor's
+identity to server code. PMX must still enforce membership, board roles and
+personal-library access. Sites also offers D1 for durable records and R2 for
+uploaded files. These are documented platform building blocks, not proof that
+the current PMX server runs there unchanged.
+Sources: [Sites sign-in](https://learn.chatgpt.com/docs/sites#add-sign-in-with-chatgpt)
+and [supported site shapes](https://learn.chatgpt.com/docs/sites#choose-a-supported-site-shape).
+
+**Plugin hosting and distribution.** The public
+[Sites-hosted plugin guide](https://help.openai.com/en/articles/20001547-hosting-a-plugin-with-chatgpt-sites)
+documents MCP hosting, owner publication, installation, connection and tool
+updates. Business/Enterprise users can share within their workspace, subject to
+permissions; each recipient needs both Site and plugin access and their own
+connection. Pro/personal accounts currently cannot share a Site-hosted plugin
+directly through invitations or a share link. Sharing the Site does not share
+the plugin. Validate an eligible pilot audience and a supported distribution
+route before promising installations beyond the owner. Browser access to the Site is a
+separate path: the [Sites sharing docs](https://learn.chatgpt.com/codex/sites/publishing-and-sharing)
+(checked 2026-10-19) list external invitations rolling out to Plus, Pro, Business and
+Enterprise, and optional public publishing, both subject to admin controls. The plugin limit
+is a distribution risk, not an established limit on hosted board links; revalidate both on
+the live platform before relying on them. Public directory release
+is a separate goal, not an automatic consequence of publishing the Site.
+
+The installed **Sites plugin 1.0.1** documents a stateless JSON-RPC `POST /mcp`
+endpoint declared through `capabilities: ["mcp"]`. Sites authenticates callers,
+checks Site access and supplies a Site-scoped user ID. Publication provisions a
+private plugin for ChatGPT/Codex and refreshes its tools on republication.
+Its `get_site(include_mcp_connection: true)` contract exposes both `mcp_url` and
+`oauth_resource`, explicitly described for Codex connections. This establishes
+an OAuth resource mechanism, but does not establish registration, callbacks or
+token issuance for arbitrary third-party clients. Implementation evidence:
+the installed [MCP server reference](/Users/pepe/.codex/plugins/cache/openai-curated-remote/sites/1.0.1/skills/sites/references/site-mcp-server.md),
+[identity and secrets reference](/Users/pepe/.codex/plugins/cache/openai-curated-remote/sites/1.0.1/skills/sites/references/identity-and-secrets.md),
+[storage reference](/Users/pepe/.codex/plugins/cache/openai-curated-remote/sites/1.0.1/skills/sites/references/storage.md)
+and native Sites tool schema, inspected on the date above. These local paths
+identify the installed version on the maintainer's machine. Those installed
+references are implementation guidance; they are not a public compatibility
+guarantee. The automatic private plugin is also not a public-directory release;
+[public submission](https://developers.openai.com/plugins/deploy/submission)
+has its own connection and review requirements.
+The submission guide currently excludes packages containing `apps`/`.app.json`
+references and requires MCP URL configuration and connection setup instead.
+Therefore, the automatically created Site plugin is not evidence that its
+package or OAuth connection is ready for public submission.
+
+**OpenAI login and MCP authorization are separate steps.** The official
+[plugin sign-in guide](https://developers.openai.com/siwc/chatgpt-plugin)
+describes two OAuth transactions for a custom integration: signing a user into
+an application and authorizing the connector to act for that user. This is
+general integration guidance, not a specification of Sites' managed auth flow.
+The [website sign-in guide](https://developers.openai.com/siwc/website)
+limits that commercial integration to a partner trial, separate from Sites'
+built-in login.
+The [MCP authentication guide](https://developers.openai.com/plugins/build/auth)
+requires discovery, client identification/registration, PKCE and resource-bound
+tokens. A browser session, an OpenAI ID token or an API inference token is not
+evidence of a valid PMX MCP access token. Sites' service bypass credential also
+supplies no visitor identity and is not a substitute for per-user OAuth.
+
+**Live probe result, 2026-10-10: OAuth is present; plug-and-play access by a
+fresh external client did not pass.** A separate owner-private
+[PMX MCP OAuth validation Site](https://pmx-mcp-oauth-validation-20261010.skottpedersen.chatgpt.site)
+was deployed with one read-only identity-check tool and no PMX board data.
+TypeScript and the Sites production build passed; deployment reported
+`succeeded` and `has_mcp: true`. This tests the platform boundary, not PMX's
+full server, board isolation or renderers.
+
+| Check | Observed result |
+|---|---|
+| Sites connection metadata | Returned the published `/mcp` URL as both `mcp_url` and `oauth_resource`, plus a provisioned plugin ID. |
+| Unauthenticated MCP request | `401` with `WWW-Authenticate: Bearer`, a resource-discovery URL and scopes `openid resource.invoke email`. |
+| Protected-resource discovery | `200` JSON naming `https://auth.openai.com` as issuer, the exact Site `/mcp` resource and scopes including `resource.invoke` and `offline_access`. |
+| Authorization-server discovery | `https://auth.openai.com/.well-known/oauth-authorization-server` returned `200` HTML rather than JSON. PMX's installed MCP SDK 1.28.0 failed discovery with `Unexpected token '<'`; its discovery path did not continue to OpenID metadata after that parse failure. |
+| OpenID discovery, fetched separately | Valid JSON advertised authorization-code/refresh grants and `S256` PKCE, but no `registration_endpoint` or `client_id_metadata_document_supported`. |
+| Fresh-client registration preflight | Given that metadata, SDK 1.28.0 rejected registration with `Incompatible auth server: does not support dynamic client registration`. No registration request or token exchange was sent. |
+
+These results establish an advertised OpenAI OAuth path and two concrete
+interoperability blockers for the tested standard client path. They do not
+prove all external clients are forbidden: a supported pre-registered client
+and explicit endpoint configuration may differ. They also do not establish
+that the Site's own browser-login client ID can be reused by another agent;
+client registration, redirect URIs and resource permissions must be approved
+for that agent. Do not borrow Codex's client identity or reuse browser/service
+credentials as a workaround. No external client has yet completed consent,
+received a resource-bound token or called the probe as a user.
+
+Reproduce from the Site's challenge URL and the issuer's public metadata; retain
+the date and SDK version because platform discovery can change. The next
+dependency is a supported external-client registration/configuration from
+OpenAI or a platform change, followed by the end-to-end test below. The vision's
+“other agents simply use MCP through their OpenAI login” remains a target with
+an observed blocker, not a validated launch capability.
+
+**External-client acceptance gate.** Obtain the exact published MCP URL and
+OAuth resource from Sites; inspect its unauthenticated challenge and discovery
+metadata; establish a supported registration and callback path for a named
+external client. Complete browser consent and an authorization-code/PKCE
+exchange, then call a read-only identity tool through that client. Verify token
+refresh or reauthorization, revoked access and two users' isolation before
+claiming parity. A discovery document alone is only partial validation. If
+Sites does not support external clients directly, investigate a separately
+authorized MCP gateway; that is an architectural alternative requiring a new
+decision, not an implemented fallback or a reason to expose the Site publicly.
+
+### What must change in PMX's hosted runtime
+
+The installed [Sites runtime guidance](/Users/pepe/.codex/plugins/cache/openai-curated-remote/sites/1.0.1/skills/sites/SKILL.md)
+(plugin 1.0.1, checked 2026-10-10) specifies Cloudflare Workers, with 128 MB
+per isolate and HTTP-based external connections. PMX currently uses
+[`Bun.serve`](../src/server/server.ts), synchronous
+[`bun:sqlite`](../src/server/canvas-db.ts), a process-wide
+[`CanvasStateManager`](../src/server/canvas-state.ts), local files and in-memory
+SSE subscribers. Hosting therefore requires porting the server to the Sites
+runtime, not just uploading the browser bundle.
+
+- **Storage and identity:** use D1 for board/knowledge records and R2 for originals and generated assets, with authorization on every read and write. Scope board selection, pins, context cursors and agent sessions to users/workspaces. Sites identity establishes who called; PMX roles determine what they may do.
+- **Live state:** preserve one authoritative mutation path while replacing reliance on a long-lived process. Prove concurrent writes, event delivery, reconnect and persistence across Worker replacement. Presence, locks, approval expiry, flow advancement and MCP app sessions also need a hosted lifecycle; do not assume timers or module-level maps survive or coordinate isolates. Select the synchronization mechanism only after checking Sites' supported bindings and streaming behavior.
+- **Assets and builds:** prebuild the canvas and viewers; serve protected documents and uploaded objects by durable IDs. Local file watching, desktop open/reveal, subprocess MCP servers, Bun.WebView screenshots and runtime package builds do not transfer unchanged. A local bridge or external builder would be a separate integration.
+- **MCP and the plugin UI:** Sites' documented tool endpoint is the starting contract. Verify PMX's resources, resource templates, notifications and MCP Apps UI embedding separately; a successful tool call does not prove that `canvas://pinned-context`, the embedded workbench or nested app frames work. Existing `isHostedWorkbench()` means an MCP App host transport is installed, not that Sites deployment is supported ([transport source](../src/client/state/workbench-transport.ts)).
+
+**SDK v2 evaluation belongs to hosted-runtime work (2026-10-12).** SDK generation
+and MCP protocol revision are separate choices. The current lockfile resolves SDK
+1.28.0; [SDK v2.3.1](https://github.com/modelcontextprotocol/typescript-sdk/releases/tag/v2.3.1)
+offers split server/client packages and a fetch-native
+[`createMcpHandler`](https://github.com/modelcontextprotocol/typescript-sdk/blob/v2.3.1/docs/serving/http.md)
+suited to Workers and Bun. Evaluate it against Sites' actual endpoint contract;
+do not require it merely for the v1-capable improvements in moves 1 and 6a. Carry
+the evaluation into Part 5 if Sites does not need or support that serving model.
+
+Migration must cover SDK-consuming dependencies together: installed MCP Apps
+[1.3.1 declares an SDK v1 peer](https://github.com/modelcontextprotocol/ext-apps/blob/v1.3.1/package.json),
+so replacing core imports alone is not a compatibility plan. Verify local stdio,
+hosted tool calls and Apps rendering/context delivery with compatible dependencies
+and the target hosts before switching. A stateless MCP handler does not supply
+board persistence, authorization or user isolation; preserve those PMX contracts
+and make retried mutations safe. Do not add sampling or background-task machinery
+just to use SDK features. Adopt them only for a concrete workflow with verified host
+support; durable jobs would still need PMX-owned persistence and recovery.
+
+### Hosted pilot operating requirements
+
+**Documented platform limits, checked 2026-10-10:** D1 is limited to 10 GB per
+Site; R2 has no fixed storage limit stated. HTTP, HTTPS and WebSockets are
+supported, but raw TCP is not. Sites does not offer data residency at launch.
+Source: [Sites limits](https://learn.chatgpt.com/docs/sites#understand-limits-and-unsupported-uses).
+Separate plan-specific beta quotas apply across the account's Sites; reaching
+them can restrict storage growth or public availability. Read current allowances
+in ChatGPT. Source: [beta usage limits](https://help.openai.com/en/articles/20001339-creating-and-using-chatgpt-sites).
+The reviewed docs do not specify numerical request-rate, concurrency, CPU-time,
+upload-size or connection-duration limits for Sites. Do not substitute generic
+Cloudflare plan quotas or PMX's own 20 MiB attachment cap for platform limits.
+
+Use **D1 for boards and metadata, and R2 for attachments and generated assets**
+as the pilot storage architecture. Load individual boards as needed; do not
+keep every user's boards in server memory or rely on memory for durability.
+
+Set PMX's own upload-size and storage allowances and analytics retention before
+opening the pilot. Enforce those allowances and explain them to users; platform
+capacity is not an unlimited product allowance. Keep analytics retention bounded
+so usage metadata does not grow indefinitely alongside board data.
+
+**Live-state proof during hosted implementation.** Run this once a working
+hosted board and MCP path exist; it is not a prerequisite for agreeing on the
+vision or continuing local development. Have a browser and an agent edit the
+same board concurrently, then disconnect and reconnect both. Verify that
+accepted edits remain durable, conflicting edits are resolved or explicitly
+rejected without silent loss, and both clients converge on the authoritative
+board. Working storage alone does not establish this behavior.
+
+**Acceptance before expanding access:** after that proof passes, load-test
+concurrent editing, MCP traffic and live updates together against the deployed
+hosted runtime. Verify
+durable writes, user isolation, event delivery and reconnect behavior under
+load, and record latency, failures and resource usage. Use measured results and
+the account's actual Sites quotas to set the initial operating envelope and
+decide when access can expand.
+
+**Pilot recovery.** Ship board export/import and demonstrate restoring a board
+and its selected attachments from an export before users depend on hosted
+boards. Explain that recovery covers only the data included at export time;
+later changes require another export. Recheck Sites' recovery capabilities
+during implementation rather than assuming platform-managed storage provides
+a user-accessible backup.
+
+**Documentation checked 2026-10-10:** Sites documents saved deployment versions
+tied to source code, not a guarantee that restoring a version restores D1 records
+or R2 objects. Its public documentation provides no recovery guarantee or
+workflow for database backups, point-in-time recovery, attachment recovery or
+backup retention; this does not establish that internal backups are absent.
+Deleting a Site is explicitly permanent. Sources:
+[Site versions](https://learn.chatgpt.com/docs/sites#understand-projects-versions-and-deployments)
+and [Site deletion](https://help.openai.com/en/articles/20001339-creating-and-using-chatgpt-sites).
+The pilot needs a tested export-based recovery path and clear limitations;
+the full service's automated backup system belongs to Part 5.
+
+### Node compatibility for the first hosted version
+
+**Source audit, 2026-10-10; no deployed node certification.** The
+[`CanvasNodeState` union](../src/client/types.ts) has 18 types. “Portable” below
+means the renderer can plausibly be reused once the common hosted backend is
+in place. “Adapt” identifies a concrete current dependency to replace.
+“Conditional” requires a platform or upstream integration test. All node types
+remain in the product vision; local-only behavior is not promised as hosted
+parity.
+
+| Node type | Hosted assessment | What carries over and what must be proved or changed |
+|---|---|---|
+| `markdown` | Portable; adapt path-backed content | Inline text and editing can carry over. Local-file reads/saves need cloud document content or an explicit local bridge. Preserve links, source provenance and context text. |
+| `status` | Portable | Renders supplied status data. Live changes must use authenticated hosted writes. |
+| `context` | Portable; adapt local links | Cards, pins and AX actions can carry over. Open/reveal of a desktop path needs an uploaded resource or local bridge. |
+| `ledger` | Portable | Renders supplied entries; persist and authorize their updates in the hosted store. |
+| `trace` | Portable | Renders supplied trace data; a connected agent must deliver new events. Hosting does not create that telemetry. |
+| `file` | Adapt | Reuse text/code/table rendering. Replace `/api/file`, raw/PDF byte routes and local watchers with authorized stored objects and explicit updates. Local filesystem paths are not cloud file identities. |
+| `diff` | Portable | Displays supplied unified-diff text. Reading a local Git checkout to produce the diff remains an agent/source integration. |
+| `image` | Adapt assets | Data URLs and permitted HTTPS images can render. Local paths require uploaded objects; private image loading must work without exposing credentials. Remote sources retain their own access restrictions. |
+| `html` | Adapt surfaces | HTML and the existing primitives can use their browser renderer. Port surface documents, theme/assets and the nonce-tagged AX bridge; test sandbox/CSP and real interactions. `ax-board`/`ax-flow` additionally require hosted AX state and loop execution. |
+| `mermaid` | Adapt surfaces | The bundled browser renderer can carry over. Serve its sandboxed document and script/theme routes; verify visible output in both the Site and plugin. |
+| `mcp-app` | Conditional by mode | Remote URL frames depend on embedding policy. Prebuilt web artifacts need stored asset serving. External MCP Apps need a hosted session/credential/bridge implementation; local stdio servers cannot run unchanged. See modes below. |
+| `webpage` | Portable stored preview; conditional refresh/live frame | Stored preview data can render. Port the server fetcher while preserving SSRF/redirect restrictions; it currently uses Node DNS and pinned-IP HTTP/HTTPS. Live embedding depends on the target's CSP/X-Frame-Options, login and browser cookie policy. Keep preview/link fallback. |
+| `json-render` | Adapt viewer assets | Reuse the spec-driven browser viewer, ship its JS/CSS at deploy time, and port spec/state/action routes. Preserve `specVersion` changes so updates visibly reload. |
+| `graph` | Adapt viewer assets | Uses the json-render viewer path; apply the same asset, spec refresh and AX action checks. Supplying graph data is separate from scanning a local repository. |
+| `group` | Portable | Layout and membership follow hosted board state; preserve per-member mutation authorization. |
+| `board` | Portable with scoped queries | Port portals, navigation and backlinks. Linked boards require independent access checks; unreadable targets must reveal neither title nor context. |
+| `prompt` | Conditional execution | Existing prompt display can carry over. Submission needs authenticated delivery to an agent; Sites hosting and login do not provision an agent runtime. |
+| `response` | Portable history; conditional live stream | Stored answers can render. Live responses require a host adapter and durable delivery/reconnect behavior. |
+
+**File attachments are a mode, not a nineteenth type.**
+[`FileNode`](../src/client/nodes/FileNode.tsx) selects
+[`AttachmentNode`](../src/client/nodes/AttachmentNode.tsx) when `attachmentId`
+is present. Port originals to protected object storage and metadata/import
+state to D1. Preserve the 20 MiB limit, explicit processing request, agent draft,
+human review and source-linked commit. PDF/Office extraction remains dependent
+on an agent's tools; hosting supplies neither OCR nor a converter. Local code
+dependency discovery also needs content/virtual-path indexing in place of
+[`code-graph.ts`](../src/server/code-graph.ts)'s filesystem resolution.
+
+**The three `mcp-app` modes need separate promises.** Prebuilt web artifacts
+are a strong candidate, but [`web-artifacts.ts`](../src/server/web-artifacts.ts)
+currently builds packages and writes local files; build elsewhere and upload
+the result. Plain URL frames remain subject to the remote site's embed policy.
+External MCP Apps use PMX's own AppBridge and
+[`mcp-app-runtime.ts`](../src/server/mcp-app-runtime.ts), which supports HTTP
+or subprocess transports and stores sessions in a process map. Remote HTTP is
+the hosted candidate; upstream OAuth, credentials, resources and reconnect are
+separate work from the user's authentication to PMX. Transport headers/env can
+currently travel in node `transportConfig`; hosted/shared boards must use
+server-only credentials and safe references instead.
+
+The [Excalidraw preset](../src/server/diagram-presets.ts) already uses remote
+HTTP and is a useful integration pilot, but must pass create, interact,
+checkpoint and reload tests. Its live app shell is not a standalone Site.
+For iframe-backed nodes, test both direct Site browsing and the nested ChatGPT
+plugin surface: sandbox identity, protected asset loading, postMessage origin
+and nonce checks, theme propagation and user-visible refresh all matter.
+
+Source anchors for this assessment: [native renderers](../src/client/nodes/),
+[surface and asset routes](../src/server/server.ts),
+[viewer server](../src/json-render/server.ts),
+[webpage fetcher](../src/server/webpage-node.ts),
+[external app operations](../src/server/operations/ops/app.ts), and
+[document imports](../src/server/document-import.ts).
+
+**Hosted proof before claiming compatibility:** create one board containing all
+18 types plus attachment, primitive and web-artifact variants; verify visible
+content, edits and pinned context, not only stored node data. Repeat after
+reload/reconnect and Worker replacement, with two users whose private boards
+and credentials differ. Check the 600/1024/1920 px surfaces and nine themes from
+the design gate. Record unsupported integrations explicitly. External-client
+OAuth, full MCP resource/UI support and third-party app hosting each need their
+own passing evidence before the complete hosted promise is met.
+
+### Before standalone hosting: does PMX keep its session UI?
+
+**Conditional direction, 2026-10-12.** Explicit agent-session integration is
+not a requirement for the ChatGPT plugin: ChatGPT owns the conversation, and
+PMX connects the board through the supported MCP surface. Before the later
+standalone hosted version, decide whether the session part of the canvas stays.
+If sessions remain in the agent host rather than in PMX's UI, an authenticated
+MCP connection may be enough; do not build a second session layer by default.
+
+If PMX keeps its session UI, retain PMX's session experience and consider a
+clearer connection to the external harness:
+
+- Bind the PMX session explicitly to the host conversation, agent identity and
+  target board. Presence reports liveness, not session identity; browsing another
+  board must not silently retarget the agent.
+- Show actual adapter capabilities and delivery state: connected is not the
+  same as able to wake an agent, and queued steering is not yet acknowledged.
+- Let agents identify the cards or artifacts to reveal, while the human controls
+  whether the canvas follows. Keep durable results and receipts separate from
+  temporary cursors, activity and partial output; reconcile safely on reconnect.
+
+[OpenHands Agent Canvas's UI/runtime separation](https://github.com/OpenHands/OpenHands/blob/ed77be9cfa46bc5f44031d52b9830dbd1dff95fc/docs/architecture.md)
+and its small [result-reveal tool](https://github.com/OpenHands/OpenHands/blob/ed77be9cfa46bc5f44031d52b9830dbd1dff95fc/src/api/canvas-ui-client-tool.ts)
+are inspiration, not a dependency or a spatial-canvas design to copy. Agent
+execution and tool permissions stay with the harness. This is a later product
+decision, not approval to implement session integration or a blocker for the
+ChatGPT pilot.
+
+## Part 5: Further out — full PMX Canvas hosted on Cloudflare
+
+**Direction decided with the maintainer, 2026-10-10.** If the ChatGPT Sites
+version works and people use it, pursue a full standalone PMX Canvas service
+hosted directly on **Cloudflare**, with its own web experience and hosted MCP
+endpoint. PMX would manage the deployment, accounts, workspace access, storage
+and live collaboration as a product. The ChatGPT Sites edition and its plugin
+remain independently supported; plugin access to the standalone service can be
+an additional distribution channel. Agents connect to each edition through its
+supported, authenticated MCP access.
+
+This is a later product investment, even though Sites already uses Cloudflare
+infrastructure underneath. The first stage validates usefulness and distribution
+within ChatGPT; the later stage gives PMX control over the complete hosted
+experience. Carry forward the board model, permissions, renderers and lessons
+from Part 4. Choose Cloudflare services, authentication providers and operational
+architecture when planning that stage; OpenAI login for arbitrary external
+clients remains subject to the validation above.
+
+**Gate to start:** review evidence of recurring use by people beyond the
+maintainer, successful plugin distribution and concrete needs that justify a
+standalone service, using Part 4's product metrics alongside user feedback.
+Proceed when that evidence supports the investment; if it
+does not, improve the first version before expanding the hosting scope. There
+is no automatic launch date or adoption threshold invented in this vision.
+Local and single-user self-hosted PMX remain part of the product; this service is PMX-managed, not a customer-operated team server.
+
+**Full hosted backup and recovery.** Before users depend on the standalone
+Cloudflare service, establish automated backups of board data and attachments,
+define retention and recovery targets, and demonstrate restoring an accidentally
+deleted or damaged board with its assets. Keep user exports as an additional
+safeguard. Durable storage alone is not a backup, and a deployment rollback is
+not proof of data recovery.
+
+### Likely repository structure: shared product, separate runtimes
+
+**Architectural direction, 2026-10-10:** a monorepo is the likely fit for
+supporting three delivery surfaces: the working local PMX Canvas, the ChatGPT
+version validated and distributed through its plugin, and later the full
+standalone hosted version. Confirm the package
+boundaries during implementation; this is not a request to reorganise the
+repository before the ChatGPT validation needs it.
+
+The decision, tradeoffs and rejected alternatives are recorded in
+[ADR-002: Shared product core, separate runtime editions](adr-002-shared-product-separate-runtimes.md).
+
+- **Shared product:** the board model, mutation rules, context compilation, node renderers and canvas UI should be reused across distributions. Keep runtime dependencies out of this shared code.
+- **Local runtime:** retain the Bun server, local SQLite store, filesystem access/watchers, local MCP entry point and existing CLI/SDK workflows. Local PMX must remain usable without a cloud account, hosted service or network connection for its local features.
+- **ChatGPT version / Sites runtime:** adapt the shared product to Sites' identity, storage and MCP contracts for the first validation and plugin distribution. Keep this experience working as the product grows; it is a supported delivery surface, not a disposable prototype.
+- **Cloudflare runtime:** later compose the same product into the full hosted service, with deployment, identity, storage and live-state integrations under PMX's control. Reuse suitable Sites work without making the standalone service depend on Sites.
+
+**Runtime boundaries (2026-10-15).** Keep one modular product, with explicit construction
+and shutdown for each edition. Shared code does not acquire concrete storage, install global
+listeners or start local services merely by being imported. Enforce dependency direction:
+contracts and product rules do not depend on runtime entrypoints; remote clients do not
+import local execution machinery. The boundaries include:
+
+- **Identity and permissions:** edition-specific authentication supplies the principal;
+  shared rules enforce grants across reads, writes, derived metadata and event delivery.
+- **Durable and temporary state:** boards, work items, gate deadlines and audit records
+  outlive a process; presence, connections, waits and timers have explicit owners and recovery
+  behavior. A viewer's current board is not another caller's write target.
+- **External capabilities:** filesystem access, network fetches, subprocess MCP, builds and
+  WebView automation belong to runtime adapters. Document supported behavior per edition,
+  including expiry and live-session behavior; absent capabilities are explicit, not silent
+  substitutes. Reusing a renderer does not make its sandbox or host protocol interchangeable.
+
+Package boundaries are not service boundaries. Keep board, context and relation consistency
+together initially; extract a deployed service only for a concrete security, execution-lifetime,
+scaling or failure-isolation need. [ADR-001](adr-001-bun-only-runtime.md) remains the local
+Bun runtime/SDK decision, not a ban on runtime-neutral product code or the hosted editions.
+This does not introduce a Node dual-build or cloud dependency for local users.
+
+**Three shared contracts:** operation requests/results, the workbench's request/event/asset
+protocol, and the editable board archive. Define and test the supported portions of each
+across editions. MCP is a host adapter over those product operations; a common registration
+module does not prove that Sites supports every local resource, subscription or embedded app.
+
+**Extraction gate:** after the current acceptance checkpoint, establish these boundaries
+through one complete read/edit/commit/reconnect slice, not a broad folder move. Exercise a
+browser and agent conflict, lost-response retry, persistence failure, runtime restart,
+independent board navigation and an unreadable linked source. Preserve local offline behavior;
+a simulated async runtime does not validate Sites or Cloudflare. Recheck platform support
+and prove the slice there before expanding the port. Package names, interfaces, storage
+mechanisms and the extraction sequence belong in a scoped implementation plan.
+
+**Shared-runtime maintenance checkpoint (2026-10-11).** The current lifecycle evaluator
+acquires data from the local `canvasState` singleton. When a second runtime needs it, separate
+runtime acquisition from qualification so the same rules consume an authorized board snapshot.
+Apply access checks before computing source titles, summaries and lifecycle reasons, not only
+before returning content. Categories are not permissions. Verify unreadable-source behavior
+and the local offline path before claiming the shared boundary is ready; do not split packages
+ahead of that need.
+
+**Continuity for early local users.** Existing users keep their local canvas,
+boards, SQLite storage and local workflows as hosted versions arrive. Shared
+product improvements continue to reach the local version wherever the runtime
+supports them. Hosting is an additional way to use PMX, not a required migration,
+cloud account or upload of existing boards. Moving data to a hosted version is
+the user's explicit choice.
+
+**Board portability and independent editions.** Local PMX, ChatGPT Sites and
+the future Cloudflare service each own their boards and storage independently.
+Sharing core code does not imply shared live state or automatic synchronization;
+each edition remains useful on its own.
+
+Provide one shared, editable board export/import format across all three
+editions. Users deliberately transfer a board by exporting it from one edition
+and importing a copy into another; later edits remain independent. Preserve
+node content, layout, edges, groups, annotations, context pins, provenance and
+the attachments/assets the user chooses to include. Preserve the knowledge
+context too: relevant category definitions, folder/board assignments, the
+effective inherited lifecycle policy and its source, explicit overrides,
+validation status and evidence references, last-validated timestamps, retired
+state, and review/restore history. Include only the definitions and folder
+metadata needed for the selected boards, not the whole workspace taxonomy or
+private neighbouring boards. Export review shows what metadata and evidence
+will leave with the content. This portable archive is additional to today's
+read-only HTML export.
+
+**Archive version policy:** version the interchange format and decide the supported import
+versions and explicit upgrade path before users depend on it. Reject unsupported archives
+before changing destination data; never silently discard content to fit a newer format.
+This is a user-data contract, not automatic authorization for legacy API shims or indefinite
+format support. The implementation plan must resolve that policy explicitly alongside local
+data continuity rather than infer it from the repository's no-backwards-compatibility rule.
+
+**Identity and relations.** Import creates a new board by default, assigning
+destination IDs to copied boards, cards and assets while retaining their origin
+IDs as provenance. Use an explicit ID map to reconnect edges, groups, pins,
+portals and evidence references within the imported set; never match by title
+or accidentally reconnect a copied ID to an unrelated destination object.
+Linked boards are included only when explicitly selected and authorised.
+References to objects outside the archive remain marked external/unresolved,
+with only metadata authorised for export, until the user explicitly reconnects
+them. A missing target does not delete the relation or grant access to its source.
+
+**Lifecycle and authority.** Show category/policy conflicts before import;
+never overwrite a destination category merely because its name matches.
+Preserve the exported effective policy by default, even if the source folder
+ancestry is absent; mapping to a destination policy is an explicit choice with
+its effects shown and recorded. Import or recovery from an archive does not
+renew validation or reactivate cards retired in that archive; the deliberate
+Lifecycle-tab restore remains a separate action. Keep original review dates, evidence and historical
+attribution, recording the import separately. Missing or inaccessible evidence
+is flagged without erasing its historical validation record or claiming a fresh
+check. Historical actors are provenance, not destination identities or roles.
+
+Destination ownership and permissions apply; credentials and source access
+grants never travel with the archive. Local file references and live
+integrations may need reconnecting, with unavailable capabilities made explicit.
+
+**Portability acceptance:** round-trip a representative board between the
+local and ChatGPT editions for the pilot, and add Cloudflare to the same checks
+when that edition exists. Include two linked boards, an unexported target, a
+same-named destination category with different defaults, a card with a lifecycle
+override, a retired card and a review whose evidence is unavailable. Verify ID
+remapping, retained relationships and selected attachments, explicit unresolved
+references, category conflict handling, unchanged validation dates and retired
+state, preserved review history, destination permissions and independent edits
+after import. The recovery check states which history and assets the archive
+includes; preserving review history does not imply a complete mutation journal
+or all snapshots.
+
+Keep the local product as a maintained distribution, not a frozen predecessor
+or a thin client that requires the cloud. Keep the ChatGPT plugin and its user
+experience supported as its own edition when the full hosted version arrives.
+Runtime adapters should represent
+real platform differences, with explicit capability limits for features such
+as local file watching and subprocess MCP servers. Avoid separate copies of
+product logic or a broad abstraction framework built before it is needed.
+
+**Acceptance:** changes to shared code pass the local verification ladder as
+well as the relevant hosted checks. A clean installed local package can still
+start, create and persist boards, render nodes and serve its local MCP tools
+without hosted credentials. Test supported common behavior across runtimes and
+document the differences; hosted progress must not silently break local PMX.
 
 ## Architecture diagnosis at the original review
 
@@ -399,7 +1438,7 @@ Revised 2026-09-23 and 2026-09-24. The original 0.6 bundled five moves into 2–
 |---|---|---|
 | 0.7 | Many boards stage 1 with the nine real boards restored, and library backup (move 0); the S half of trust (move 7: `res.ok` toasts, redirect host filter); read instrumentation (Part 1, item 4); the Chromium 600 px reference project (5). | The nine boards open by name; a backup restores them on a clean machine; a refused write shows its reason; every node type paints at 600 px; agent reads are being recorded. |
 | 0.7.x | Static export with the per-board rule (11). | A colleague opens an exported board with no install. This is the second-user milestone. |
-| 0.8 | Portals, README card, `canvas://boards`, search across boards (0), a meaningful text form for every node type (1), document drop as Markdown context (15), new board from this board (14), author on every node and attributed ask answers with the boot secret (7), the one read with its cross-board tier (Part 1), the cheap tool surface (6a), the binary (8). | "What changed since the April OKRs?" is answered from a board linked to the April board, without the agent being told which board to read; imported documents are readable, source-linked and searchable; the per-type text-form check passes; the measurement from 0.7 is read against the Part 1 decision rule and the outcome is written into this document. |
+| 0.8 | Portals, README card, `canvas://boards`, search across boards (0), a meaningful text form for every node type (1), document drop as Markdown context (15), new board from this board (14), author on every node and attributed ask answers with the boot secret (7), the one read with its cross-board tier (Part 1), the cheap tool surface (6a), the binary (8). | "What changed since the April OKRs?" is answered from a board linked to the April board, without the agent being told which board to read; imported documents are readable, source-linked and searchable; the per-type text-form check passes; the curation benchmark (Part 1, item 4) is run and its gap recorded. |
 | 0.9 | Wiki links and the board map, make board and inline board (0), tours (12), recipe cards (13), the frame host (5). | A board with 20 portals mounts no more iframes than one without; a tour runs inside an exported file. |
 | 1.0 | The journal and bookmarks (4), the agent's output onto the board (3), the SDK through the registry, the M half of trust with the read-only share link (7, Part 3 step 2), time scrubber, culling and frame budget (9). | A colleague follows a shared link to a live board and sees it change. |
 | After 1.0 | Comments and a second writer (Part 3 steps 3–4), concurrent boards (0, stage 2), state as a fold of the journal, generated surfaces (6b, if decided), session projection (Part 1, item 2). | Each step starts only when the previous one is in use. |
@@ -410,7 +1449,7 @@ Revised 2026-09-23 and 2026-09-24. The original 0.6 bundled five moves into 2–
 - The minimalist deletes the registry. Refuted three to zero: the browser alone calls 55 API paths.
 - The rendering architect deletes the tool rail and top bar. Design for 600 px first; the rail is the good part of the chrome.
 - Every vision, and my own first draft, proposed cutting node types on the strength of the repo's test board. The real boards refute the chart cut outright, and the maintainer's rule closes the rest: usage on one machine is not evidence of non-use. No node type is cut; consolidation is confined to how nodes render.
-- Four of six visions leaned on Obsidian, and five on git, as the format, the snapshot system, or the remote transport. The maintainer's rule is that this is its own app with no reliance on externals, and I agree: the app owns its history (the journal), its store (SQLite), and its remote reach (tokens and a listen mode). What survives of the folder idea is an export.
+- Four of six visions leaned on Obsidian, and five on git, as the format, the snapshot system, or the remote transport. For local and self-hosted distribution, the maintainer's rule is that this is its own app with no reliance on externals, and I agree: the app owns its history (the journal), its store (SQLite), and its remote reach (tokens and a listen mode). What survives of the folder idea is an export.
 - Several visions invented constants (700 chars, six frames, 14k lines) with the same confidence they mocked the repo's. So did I. Every such number in this document is a starting value to tune in use, not a claim.
 
 ## Evidence