[{"_1":2,"_3":-5,"_4":-5},"loaderData",{"_5":6,"_7":8,"_9":10,"_11":12},"actionData","errors","root",{"_228":-5,"_231":232,"_233":234},"routes/shell",{"_40":41,"_227":-5,"_228":-5,"_229":230},"routes/repo",{"_33":-7,"_34":35,"_36":37,"_38":39,"_40":41,"_42":31,"_43":31,"_44":31,"_45":31,"_46":31,"_47":31,"_48":49,"_50":49,"_51":31,"_52":-7,"_53":-7,"_54":55,"_56":57,"_58":59,"_60":-5,"_61":62,"_63":64,"_65":66,"_67":68},"routes/repo.blob",{"_13":14,"_15":16,"_17":18,"_19":20,"_21":14,"_22":23,"_24":-5,"_25":26,"_27":28,"_28":29,"_30":31,"_32":14},"ref","3c052d73d885df4a739c79d5b3cdfc83868fe17b","path","docs/architecture.md","oid","36856791a5acb62e941a44f4ac96fb1f50ee7717","size",27969,"commit","mounts",[],"source","plain",{"_13":14,"_15":16},"kind","text","# Architecture\n\nChopin is one Bun application, one browser client, and one PostgreSQL database.\nThe application serves the built client, HTTP API, Streamable HTTP MCP endpoint,\nand WebSocket from the same origin. GitHub supplies identity and repository\nauthorization; the selected harness (GitHub Copilot by default, or Pi) supplies\nthe hosted document agent runtime, currently named Planner.\n\nThis document describes the system boundaries and collaborative document model.\nSee [Repository channels](channels.md) for channel creation and access,\n[Authentication](authentication.md) for identity, [Storage](storage.md) for the\ndurable model, [Background jobs](background-jobs.md) for isolated durable work,\nand [Self-hosting](self-hosting.md) for deployment.\n\n## Vocabulary\n\n- A **document** is the collaboratively authored, repository-connected artifact\n represented as restricted MDX, Lexical, and Yjs.\n- A **channel** is the durable collaboration container for one document, its\n Chat, decisions, repository identity, and sidecar state.\n- An **MCP document** is the public API projection of a channel and document,\n including its ID, title, source, revision, optional generated description, and\n optional creation brief.\n- A **plan** is a document being used for planning. It is not the product noun\n for every document.\n- A **room** is the server's live in-memory representation of an open channel.\n- A **research request** is durable work attached to one parent document. While\n pending, it is represented by an inline card rather than a channel, document,\n Chat, decision set, navigation row, or browser route.\n- A **child document** is an ordinary channel attached to one top-level parent\n for navigation and context. It owns its document, Chat, and Decisions.\n The V1 product surface offers neither child research nor grandchildren. The UI\n blocks starting research from a child; the API may accept the request, but\n publication validation rejects linking a grandchild.\n- The **Planner** is the current name of Chopin's hosted document agent, backed\n by GitHub Copilot by default, by Pi under `HARNESS=pi`, or by an in-process\n Atomic session under `HARNESS=atomic`.\n- A **coding agent** is an external MCP client that creates, revises, or implements a\n document from its own local workspace.\n\nThe current UI, protocol, and server grew from a planning workflow and retain\nliteral names such as **Plan**, `plan:*`, `read_plan`, and `planRevision`. This\ndocumentation uses **document** for the product artifact and **plan** only for a\nplanning-specific workflow or one of those implementation names.\n\nThe hosted agent's product role is document co-authoring, while its current\nprompt remains optimized for planning.\n\n## System context\n\n```mermaid\nflowchart LR\n\tB[Browser] -->|HTTP and WebSocket| S[Bun application]\n\tC[Local coding agent] -->|Bearer-authenticated MCP| S\n\tS --> P[(PostgreSQL)]\n\tS --> G[GitHub API]\n\tS --> A[Harness model provider: Copilot, Pi, or Atomic]\n\tS --> W[Built web client]\n```\n\nThe browser uses a process-local GitHub App user session. Browser HTTP routes\nand the WebSocket intersect that identity's repository role with repositories\nselected in a GitHub App installation. The external MCP endpoint instead checks\nits caller-supplied GitHub bearer token directly. Both paths apply the instance\nadmission policy.\n\nThe application holds an exclusive database-wide writer lease. It refuses to\nstart beside another active Chopin process and stops if it can no longer renew\nthe lease. This is a single-writer design, not an application cluster.\n\n## Workspace packages\n\n| Area | Responsibility | Internal dependencies |\n| ------------------- | ------------------------------------------------------------------------------------------ | ---------------------------------------------------- |\n| `packages/dialect` | Restricted MDX dialect, parsing, serialization, and Lexical schema | none |\n| `packages/protocol` | WebSocket types and shared addressing helper | none |\n| `packages/question` | Questionnaire definitions, shared drafts, and answer derivation | `protocol` |\n| `packages/draft` | Bounded collaborative plain-text draft codec | none |\n| `packages/viewport` | Browser viewport geometry and subscriptions | none |\n| `packages/editor` | Collaborative editor, cursors, decisions, comments, and widgets | `dialect`, `question`, `protocol`, `viewport` |\n| `apps/server` | Authentication, channels, rooms, storage, Planner, jobs, MCP, and implementation lifecycle | `dialect`, `draft`, `question`, `protocol` |\n| `apps/web` | Repository picker, channel navigation, Chat, and workspace shell | `dialect`, `draft`, `editor`, `protocol`, `viewport` |\n\nRuntime workspace packages do not depend on either application. The E2E suite\nand skill contract tests deliberately import server internals as test harnesses;\nthey are not runtime dependency boundaries.\n\n## Trust boundaries\n\n### Document content\n\nThe MDX dialect is an allowlist. Imports, exports, expressions, raw HTML, and\nunknown JSX are rejected. Document content is parsed and rendered; it is never\nevaluated. Every accepted document state must serialize through the registered\ndialect and pass server-side validation.\n\n### Browser and WebSocket\n\nA browser request needs a valid process-local session, current instance\nadmission, a matching GitHub App installation, and the required repository role.\nOpen sockets periodically recheck those conditions. Pull access is read-only;\npush or administration access permits mutation.\n\n### Local MCP\n\n`/mcp` authenticates a GitHub bearer supplied by the coding agent. It applies\ninstance admission and checks that token's current repository role without\nrequiring the GitHub App for Chopin installation. Pull access permits reads;\npush or administration access permits document creation, document updates, and\nimplementation lifecycle mutations.\n\n### Hosted agent\n\nChopin runs the Planner through `@ai-sdk/harness`. `HARNESS` selects one\nadapter from a code-owned map (default `copilot-sdk`); `harnessFor` refuses an\nunknown name and refuses a `HARNESS_AUTH` mode that falls back to a\nhost-logged-in subscription unless the server binds only to loopback. The\nfirst eligible editor to invoke the Planner or start a model-backed research\nrequest becomes that channel's Planner owner for the lifetime of the process\nsession.\nPermission callbacks recheck admission, session identity, credential revision,\nownership generation, repository role, and App installation before execution.\nUnder `copilot-sdk` and `pi` the Planner has bounded, repository-fixed read tools\nand no ambient checkout, shell, or host filesystem; no harness built-in is active.\nUnder `atomic` every Planner session is a\n[full Atomic session](hosted-agent.md#full-atomic-planner) with shell and\nfilesystem access as the server process's user. Model-backed\n`active-planner` workers use the same owner credential but fresh isolated\nharness sessions; see [Background jobs](background-jobs.md).\n\n## State ownership\n\n### Durable PostgreSQL state\n\n- user identity records and token-free process-session registry rows;\n- channel metadata and repository identity, including an optional generated\n description with source and job provenance;\n- complete Yjs checkpoints and the accepted update journal after each\n checkpoint;\n- background-job requests, normalized inputs, lifecycle and progress state, and\n immutable completed artifacts;\n- parent-scoped research request staging records, their internal initial turns,\n links to immutable background-job artifacts, and an optional published child\n channel link;\n- canonical MDX and a versioned sidecar containing questions, shared drafts,\n comments, decisions, transcript, relationships, creation metadata,\n MCP document rewrites, implementation graphs, active execution, and run history;\n- reserved Planner summary and transcript cursor fields, plus the ownership\n reference and generation; and\n- migrations and the database writer lease.\n\n### Process-local state\n\n- browser cookie verifiers and GitHub access and refresh tokens;\n- open rooms, pending update batches, and persistence coordinators;\n- disposable harness sessions and copied credentials; and\n- repository and admission caches.\n\nStartup deliberately clears every process-session registry row and Planner\nowner reference. Transcripts, document state, reserved context fields, generated\ndescriptions, and implementation runs remain. The current runtime does not\ngenerate the reserved Planner transcript summary or advance its transcript\ncursor; `document-summary@1` artifacts and their catalogue projection are a\nseparate feature.\n\n### Ephemeral state\n\nYjs Awareness carries browser cursors and selections. It is relayed but never\nstored. The live Planner cursor also uses presence state. Planner change marks\nare broadcast decoration: a browser retains at most 50 unseen marks until they\nenter the viewport, the editor is cleared, or the epoch changes. The server does\nnot persist or replay them after a reconnect.\n\n## Browser content swaps\n\nThe host that owns a changing surface also owns its motion contract and keyed\nretention. The shared `ContentSwapLayer` owns presence timing: it makes an\ninactive layer `inert` and `aria-hidden` immediately, then hides it and notifies\nthe host after its visual exit. Pointer input follows the host's transition\ncontract; keyboard input and reduced-motion preferences settle the transition\nimmediately.\n\nThe editor's questionnaire host renders the current question and retains at most\none outgoing question until that layer closes. Document navigation similarly\nkeeps the active route, at most one outgoing route, and an optional pending\nroute. A pending document load stays mounted but hidden and inert until it is\nready, so the existing document remains interactive. Navigation publishes only\nthe active ready channel; readiness reported later by an outgoing route cannot\nreplace it.\n\n## Counters and identities\n\nSeveral independent counters prevent different classes of stale write. They are\nnot interchangeable:\n\n| Value | Scope and purpose |\n| -------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| Yjs epoch | Identifies one collaborative history. Rebuild or replacement creates a new epoch so clients discard incompatible updates. |\n| Document sequence | Advances for accepted document updates and server-authored document mutations. It is the `seq` used by `plan:update` and `plan:ack`. |\n| Plan revision | Plan-named optimistic-concurrency token for document reads and Planner block operations. One accepted document batch or server-authored mutation advances it. |\n| Storage channel revision | Advances for every durable channel commit, including sidecar-only transcript, graph, draft, or relationship changes. It fences adapter writes. |\n| Storage sequence | Orders committed updates and events. Sidecar-only commits can create gaps in the Yjs update journal because they still consume a sequence. |\n| Description revision | Orders generated catalogue-description projections. It advances independently and does not change collaboration counters or channel activity time. |\n| Graph version and revision | Identify one implementation graph generation and the edits within its current draft. A claim also binds the exact plan revision. |\n| Research revision | Orders durable request, job-link, and internal staging changes independently from the parent document, background-job channel revision, and job revisions. |\n\nChannel IDs, update IDs, operation IDs, component IDs, and lifecycle idempotency\nkeys solve separate identity problems. See [Repository channels](channels.md) for\nchannel ID construction and [Experimental implementation lifecycle](implementation-lifecycle.md)\nfor graph counters.\n\nA channel UUID is the stable internal document identity used by storage, UUID\nAPI routes, WebSocket rooms, and MCP lifecycle mutations. A top-level browser\ndocument uses `/documents/:owner/:repository/:slug`; a child uses\n`/documents/:owner/:repository/:parentSlug/children/:childSlug`. Direct child\nentry loads both channels and rejects a repository or recorded-parent mismatch.\nSlugs retain Unicode letters, numbers, and marks, add numeric suffixes for\ncollisions, and keep every former canonical slug as an alias. Renaming changes\nthe canonical route without changing the UUID or plan revision.\n\nBrowser creation `Location` headers and MCP `create_document.url` expose the\nreadable route. MCP `read_document`, `update_document`, and `read_implementation`\nbridge the two identities by accepting either the canonical URL or UUID and\nreturning the UUID; lifecycle calls continue to use that returned UUID. Legacy\nrepository and UUID\nbrowser paths resolve through the existing internal routes before the browser\nreplaces them with the canonical readable location.\n\n## Research requests and child publication\n\nTyping `/research` inserts a local composer into the parent document. Submitting\nit persists the exact brief and starts work immediately. The resulting\n`` block is only a reference: authoritative request state,\njob links, progress, sources, errors, and publication identity live in durable\nparent-scoped records. The parent WebSocket announces `research:changed`; the\nbrowser then refreshes that request over HTTP.\n\nThe public worker receives only the submitted brief, with no private document\ncontext. It calls a host `web_search` tool reached through GitHub MCP and may\nderive or refine the queries it sends; its result is validated against a\nstructured `output` schema. After its\nevidence artifact validates, one isolated private worker analyses the parent\ndocument from the brief and document snapshot. A second isolated private worker\nreceives the brief, normalized public evidence, and private findings, then\nsynthesizes the complete report. Neither private worker has web access. No\npartial report prose is published. Failure and cancellation create no child; an\nexplicit retry keeps the request identity and immutable brief while replacing\nonly its terminal job links.\n\nSuccessful reconciliation validates and converts the report to canonical MDX.\nOne fenced storage transaction then creates a revision-zero child channel with\ncomplete Yjs and sidecar state and links that channel to the request. Until both\nwrites commit, the card has no child URL and repository navigation has no child\nrow. Reconciliation and publication are idempotent, so a restart or repeated\nread cannot publish a duplicate.\n\nThe browser nests published children beneath their parent. Opening a ready card\nor nested row keeps the parent mounted but inert behind an anchored child\nsurface. The child opens through its ordinary channel stack with its own\nChat and Decisions; closing, Escape, and browser Back restore the\nparent's history, scroll, selection, and opener focus. Compact layouts occupy\nthe viewport, and reduced motion uses a crossfade.\n\n## Collaborative document\n\nChopin represents one document in three forms: Lexical for rich editing, Yjs for\nlive collaboration, and canonical MDX for a readable durable projection. These\nare not competing sources of truth. While a room is open, the server's Yjs\ndocument and its headless Lexical mirror are authoritative.\n\n```mermaid\nflowchart LR\n\tMDX[MDXEditor] --> BL[Browser Lexical]\n\tBL <--> BY[Browser Y.Doc]\n\tBL -. selections .-> BA[Yjs Awareness]\n\tBY <--> WP[WebSocket provider]\n\tBA <--> WP\n\tWP <--> SY[Server Y.Doc]\n\tSY <--> SL[Headless Lexical]\n\tSL --> CM[Canonical MDX projection]\n```\n\nThe browser mounts MDXEditor and binds its Lexical editor to a browser Y.Doc\nwith `@lexical/yjs`. The server owns the authoritative Y.Doc for each open room.\nA headless Lexical editor bound to it lets the server interpret CRDT updates,\nvalidate the resulting tree, and project canonical MDX without trusting a\nconnected browser to serialize the document.\n\nThe room also holds counters, question and comment records, transcript, Planner\ncontext, implementation state, pending client batches, and its persistence\ncoordinator.\n\n## Human edit flow\n\n1. A browser edit updates Lexical and `@lexical/yjs` produces a Yjs update.\n2. The provider retains that update until acknowledgement and replays it after a\n reconnect when necessary.\n3. The server groups client updates for 5 ms and applies the batch to its Y.Doc.\n4. The headless mirror catches up and projects canonical MDX.\n5. The merged update and current sidecar commit under the writer fence.\n6. Only after that commit does the server acknowledge the sender and relay the\n accepted state.\n7. The accepted state becomes the latest known-good rebuild point and schedules\n a complete checkpoint.\n\nYjs cannot roll back a transaction. If a batch leaves the document invalid, the\nroom rebuilds its last known-good state under a fresh epoch and every client\nreopens. Awareness uses a separate ephemeral path.\n\n```mermaid\nsequenceDiagram\n\tparticipant U as User\n\tparticipant B as Browser Lexical/Y.Doc\n\tparticipant S as Plan service\n\tparticipant D as Server Y.Doc/Lexical\n\tparticipant ST as PostgreSQL\n\tparticipant P as Peers\n\n\tU->>B: Edit rich document\n\tB->>S: plan:update(epoch, id, update)\n\tNote over S: Group updates for 5 ms\n\tS->>D: Apply and validate batch\n\talt valid\n\t\tS->>ST: Fenced update and sidecar commit\n\t\tST-->>S: Durable storage revision and sequence\n\t\tS-->>B: plan:ack(document seq)\n\t\tS-->>P: plan:update(document seq)\n\telse invalid\n\t\tS->>D: Rebuild known-good state under a fresh epoch\n\t\tS-->>B: plan:reset\n\t\tS-->>P: plan:reset\n\tend\n```\n\n## Hosted agent edit flow\n\nThe hosted agent, currently named Planner, reads canonical MDX, a plan revision,\nand an outline of addressable top-level document blocks. `edit_plan` accepts\nstructural block operations against that revision rather than a text patch.\n\n1. Operations stage against parsed MDAST without touching the live room.\n2. New fragments are parsed, restricted components are refused, and missing\n component IDs are minted by the server.\n3. The assembled document is serialized, parsed again, dialect-validated, and\n checked through a Lexical import/export round trip.\n4. Existing MDAST objects identify untouched or moved blocks. Their live Lexical\n nodes are reused; genuinely new blocks receive new nodes.\n5. Lexical produces a Yjs delta. The server finalizes records, reviews\n relationships, and attributes accepted-comment results.\n6. The delta and sidecar commit before broadcast.\n7. The server derives added, moved, and removed marks and places the Planner\n cursor at the end of the final changed block.\n\nThe update is broadcast before its change description, so clients possess every\nnode a mark names before trying to draw it. Explicit operations also preserve\nunaffected selections, cursors, undo history, and provenance that a structural\ndiff could only guess.\n\n## Chat addressing\n\nThe web composer uses the shared `addressed()` helper to translate an `@chopin`\nmention into `Chat.Send.to = \"planner\"`; other messages use `to = \"room\"`. The\nwire destination is authoritative on the server. A custom write-authorized\nclient can therefore address the Planner explicitly without including the\nmention in its text. `instruction()` removes a mention before model input.\n\nChannel messages remain durable transcript entries. A bounded recent window\nenters the next Planner turn, and a separately bounded transcript bootstrap is\nused when a disposable Copilot session is recreated. The full transcript is not\nsent to every turn.\n\n## Decisions and anchors\n\n### Conversation research offers\n\nWith conversation analysis enabled, saved human messages also enter an independent\nresearch classifier. Research opportunities may exist before any decision thread\nor candidate options. The versioned conversation sidecar stores its queue,\ndiagnostics, offers, source references, and collaborative brief checkpoints.\n\nAn isolated `research-brief@1` worker synthesizes a grounded brief. People share a\njson-joy text draft; human editing stops automatic replacement. Start atomically\ncaptures the latest accepted draft and its durable delivery intent. An immutable\noffer key identifies execution independently of the card's changing Chat position.\nThe existing research service creates the request and publishes its completed\nchild. See [Research offers from Chat](conversation-research.md).\n\n### Decision records\n\nQuestion answers and accepted comment threads belong to durable records outside\nthe document. Their `` and `` nodes are readable MDX\nprojections. Domain operations and Planner block tools update or protect the\nrecord and projection together. Browser Yjs validation checks the dialect and\ncompares protected projections before and after the batch. Unchanged projections\nmay move; creating, removing or altering a Questionnaire or Decision is rejected.\nResearch references may be added or removed only with durable request authority,\nrechecked at the fenced commit. This preserves the starting projections rather\nthan independently rebuilding every projection from its record on each edit;\nrecords remain authoritative.\n\nA relationship points from one of those records to top-level document blocks.\nEach anchor combines a Yjs relative position with a digest of the canonical block.\nThe position survives surrounding edits; the digest can recover one unique\nmatch after a move or epoch change. Ambiguous or missing matches are orphaned\nrather than guessed.\n\nThe browser sends block indices, a bounded quote locator, a selection length,\nand an offset hint. The server resolves that locator against canonical MDX and\nmints Yjs relative positions for the durable passage. Those positions let the\nrange move with normal edits; the quote is a fallback when they no longer\nresolve, and two equally plausible matches recover neither. The server does not\nyet enforce every browser-side size and ordering bound on a custom wire request.\n\n## Persistence and recovery\n\nAccepted document updates and normal domain mutations commit before\nacknowledgement or broadcast.\nCheckpointing later folds the update journal into a complete Yjs state and\ndeletes journal entries through the checkpoint sequence. Recovery uses a\nrepeatable-read snapshot, validates that checkpoint bytes project to the stored\nMDX, replays ordered updates, restores sidecar state, and preserves the epoch.\n\nCheckpointing prunes only the Yjs update journal. Operation idempotency and event\ntables have separate retention behavior. See [Storage](storage.md) for the table\nmodel and adapter contract.\n\n## Generated document descriptions\n\nChopin can derive optional catalogue metadata from canonical document source.\nThe durable job remains `document-summary@1`; `document-summary@2` does not\nexist. New V1 requests carry `output:\"description\"` and use\n`description-v1::` as their idempotency key. This\nlets an unchanged document with only a legacy markerless summary regenerate\nlazily when it next follows an open, edit, restore, or MCP creation/replay\nscheduling path and an active Planner owner is available. There is no unattended\nall-document backfill.\n\nThe private worker returns one physical line identifying document type, purpose,\nand subject, such as a PRD, RFC, or Plan. Blank source yields `Empty document`.\nMarkerless V1 summary artifacts remain readable background results but are not\nprojected. Marked completions are idempotently stored in channel metadata with\nsource plan revision and hash, generator version, job ID, projection time, and\nan independent description revision. Existing metadata remains in place while\nnewer work is pending or failed, and projection changes neither collaboration\nrevision nor channel `updatedAt`.\n\nBrowser lists, document and reference pickers, and title-or-description search\nshow the optional value. MCP document reads, lists, and common document summaries\nalso expose it. A description is untrusted model output, not authoritative\ndocument content. The structured MCP creation `brief` and reserved Planner\ntranscript `summary` remain separate fields with separate purposes.\n\n## Implementation graphs\n\nThe hosted Planner's graph tools can technically draft a versioned task graph\nagainst one plan revision in any channel. The child browser surface does not\nexpose implementation or tasks, so child implementation is not a supported\nproduct workflow. The supported MCP read-before-claim flow exposes graphs only\nwhen the document has MCP creation metadata. An approved graph can then be\nclaimed for one logical run, after which task, pull-request, blocker, and\nverification transitions are persisted before publication. An active run locks\nplan changes that would invalidate the graph.\n\nThe backend lifecycle is implemented, but there is currently no production UI\nor route for a person to approve the draft. See\n[Experimental implementation lifecycle](implementation-lifecycle.md).\n\n## Known implementation gaps\n\nThe prototype still has several places where implementation falls short of the\nintended boundaries above:\n\n- Custom comment locators do not receive all browser-side bounds on the server.\n- Implementation run authorization is repository-based rather than bound to the\n original claimant; any admitted repository writer with the run ID can report\n its lifecycle.\n- `start_implementation` does not independently require MCP creation metadata,\n even though `read_implementation` does. A caller that somehow knows the exact\n graph counters can bypass the supported provenance-gated read path.\n\nTreat these as implementation work, not guarantees to build new behavior upon.\n\n## Main implementation points\n\n- Browser collaboration: `packages/editor/src/collaboration.tsx` and\n `packages/editor/src/provider.ts`\n- Protocol declarations: `packages/protocol/*.d.ts`\n- Server document: `apps/server/src/plan/room.ts`\n- Plan service and persistence coordinator: `apps/server/src/plan/service.ts`\n- Planner tools and block operations: `apps/server/src/agent/tools.ts` and\n `apps/server/src/plan/edit.ts`\n- Harness selection, agents, sessions, and GitHub tools:\n `apps/server/src/harness/harnesses.ts`, `apps/server/src/harness/agents.ts`,\n `apps/server/src/harness/session.ts`, and\n `apps/server/src/harness/github-tools.ts`\n- Copilot SDK adapter: `apps/server/src/harness/copilot-sdk/adapter.ts`\n- Atomic SDK adapter: `apps/server/src/harness/atomic/adapter.ts`\n- Channel routes and IDs: `apps/server/src/channels/`\n- Research requests and child publication: `apps/server/src/research/service.ts`\n- Inline request state and anchored children: `apps/web/src/research-requests.ts`\n and `apps/web/src/anchored-child-surface.tsx`\n- Storage contract: `apps/server/src/storage/port.ts`\n- PostgreSQL adapter and migrations: `apps/server/src/storage/postgres/`\n- Implementation graphs and lifecycle: `apps/server/src/tasks/`\n","editable",false,"branch","documentNavigation","repo","githubnext/chopin","repoId","7d1a8ac3-35b0-4dea-85d4-06a980f3bada","ownerId","org:89615882","site","nexthub","private","admin","settings","maintainer","triage","starred","stars",0,"watchers","watching","pinned","notify","views",[183,184,185,186,187,188,189,190,191,192,193,194,195],"navigation",{"_54":55,"_139":140,"_141":142,"_143":144,"_145":146,"_147":148,"_149":150},"sources",[],"viewer","meta",{"_131":132,"_133":134,"_135":136,"_42":31,"_137":126,"_138":31,"_48":49,"_50":49},"branches",[73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122,123,124,125,126,127,128,129,130],"tags",[69,70,71,72],"cloneUrl","https://git.nexthub.sh/githubnext/chopin.git","color-controls-slice-1","color-controls-slice-2","color-controls-slice-3","color-controls-slice-4","Krzysztof-Cieslak-patch-1","Krzysztof-Cieslak-patch-2","Maggie/app-preview-toolkit","Maggie/ci-playwright-install-timeout","Maggie/collaborative-visual-decision","Maggie/design-audit","Maggie/generic-visual-decision-runtime","Maggie/impeccable-chopin-metadata","Maggie/jev-chat-product","Maggie/jev-composed-assessment","Maggie/native-document-layouts","Maggie/openui-composition-product","Maggie/openui-composition-trial","Maggie/planner-visual-authoring","Maggie/planner-visual-requests","Maggie/visual-selection-eval","artifacts/pr-419-live-preview-20261009","automation/pr-maintenance-state","automation/use-effect/callout-disabled-picker-8cf9e49ba5c09471","automation/use-effect/collaboration-options-ref-4e3a5a08a879a5ae","automation/use-effect/room-workspace-effective-access-a57d40866c71bed0","chore/bun-1.4.2","color-controls","color-controls-plan","comments","design-pr-assets","design/archived-decisions-badge","design/channel-route-remount","design/chat-decision-entry","design/conversation-analysis-markers","design/decision-evidence","design/settled-line-icon","dev/integration","diagram-step-controls","feat/liveapp-frontend-pilot","feat/local-experiments","feat/local-launcher-tracer","fix/autolink-mdx-crash","github-pills/2-pills","github-pills/3-hover-card","maggie/app-preview-toolkit","maggie/ci-playwright-install-timeout","maggie/collaborative-visual-decision","maggie/design-audit","maggie/generic-visual-decision-runtime","maggie/impeccable-chopin-metadata","maggie/jev-composed-assessment","maggie/native-document-layouts","maggie/openui-composition-product","maggie/openui-composition-trial","maggie/planner-visual-authoring","maggie/planner-visual-requests","maggie/visual-selection-eval","main","plain-text-fence-chrome","tokens/09-copy","wireframes/2-renderer","wireframes/3-planner","description","Let's compose rich plans together","owner","githubnext","section","","head","empty","pins",[165,166,167],"documents",{"_160":161,"_162":163},"code",{"_156":157,"_158":159},"automations",{"_153":154,"_155":-5},"delivery",{"_151":49,"_152":-5},"tag","04zvKQ8QOrDUF8TO1Ovz0Zy8_TT","releases","applications","workflows",3,"deployments","commits",1000,"changes",13,"counts",{"_164":163},"total",11,"issue",{"_168":158,"_170":181,"_15":158,"_172":182,"_52":174,"_175":31,"_176":174,"_177":159},{"_168":178,"_170":179,"_15":178,"_172":180,"_52":174,"_175":31,"_176":174,"_177":49},{"_168":169,"_170":171,"_15":169,"_172":173,"_52":174,"_175":31,"_176":174,"_177":163},"id","issues","name","Issues","filters",{},true,"saved","pinnable","count","tasks","Tasks",{},"Changes",{},{"_168":158,"_170":181,"_15":158,"_172":226,"_52":174,"_175":31,"_176":174},{"_168":178,"_170":179,"_15":178,"_172":225,"_52":174,"_175":31,"_176":174},{"_168":169,"_170":171,"_15":169,"_172":224,"_52":174,"_175":31,"_176":174},{"_168":221,"_170":222,"_15":221,"_172":223,"_52":31,"_175":31,"_176":174},{"_168":218,"_170":219,"_15":218,"_172":220,"_52":31,"_175":31,"_176":174},{"_168":153,"_170":216,"_15":145,"_172":217,"_52":31,"_175":31,"_176":174},{"_168":155,"_170":213,"_15":214,"_172":215,"_52":31,"_175":31,"_176":174},{"_168":151,"_170":211,"_15":151,"_172":212,"_52":31,"_175":31,"_176":174},{"_168":207,"_170":208,"_15":209,"_172":210,"_52":31,"_175":31,"_176":174},{"_168":141,"_170":205,"_15":141,"_172":206,"_52":31,"_175":31,"_176":31},{"_168":202,"_170":203,"_15":202,"_172":204,"_52":31,"_175":31,"_176":31},{"_168":199,"_170":200,"_15":199,"_172":201,"_52":31,"_175":31,"_176":31},{"_168":196,"_170":197,"_15":196,"_172":198,"_52":31,"_175":31,"_176":31},"decisions","Decisions",{},"changelog","Changelog",{},"roadmap","Roadmap",{},"Documents",{},"activity","Activity","insights",{},"Releases",{},"Deployments","automations/deployments",{},"Workflows",{},"discussions","Discussions",{},"goals","Goals",{},{},{},{},"groups","user","agents",[],"now",1794438370265,"sidebar","expanded"]