Status: Direction / north star (Jon's product frame, 2026-06-04). Not an implementation contract — this is the canonical "what we are building" that every repo points at.

Thesis

The separate repos are not separate products. They are one product, modularized by feature, converging. jwc-global is the convergence home / product seed — it carries the momentum (records/governance, the docs shell, the ProseMirror/Tiptap direction).

The product = jwc-global with its jwc-specific tenant primitives extracted out. The agentic collaborative work environment (the shell + work surface) is built in jwc-global now; a later, optional clone/split would remove the jwc-specific layer (its docs content, its enums) and inherit the already-built environment — but the product is being stood up here first, not after a split.

What the product is

• The agentic app shell — an OpenHands / Claude-desktop / VS Code-agent 3-pane frame: side rail · center · right multifunctional workspace. Floating containerized columns (gap-separated rounded panel cards, not edge-to-edge hard splits), roughly 25% tighter than OpenHands. Full-width, resizable.
• The ProseMirror / Tiptap all-format collaborative diff/editor — the core work surface for reviewable, tracked-change collaborative work across formats (MDX, code, LaTeX, data, design). ProseMirror is foundational (schema nodes/marks, transactions/steps, decorations, changesets, collaboration/history); Tiptap is the ergonomic React wrapper.

The pillars that converge in

Side infrastructure: pydantic-logfire (logging), OpenTelemetry (traces), Redis (state / queue / cache).

Pillar → shell mapping

 side rail            center                      right workspace
 ----------           ----------                  -----------------
 K registries +       PM/Tiptap all-format        editor · diff ·
 loadout · projects   collaborative editor        terminal · browser ·
 · agents             (fed by records             Blockdata workflow-
                      Phase B node projection)    graph

 chat surface  = Chattr multi-agent runtime + Letta identity
 underneath    = logfire · OTel · Redis

Locks

1. The jwc-specific ↔ generic-product seam is the extraction line. "Clone jwc-global, extract the jwc-specific primitives" is literal product strategy, so that boundary must stay clean from the next commit onward. Everything built on the shell and in the records system keeps generic product vs jwc tenant content/config cleanly separable.
2. One canonical shell, never forked. The shell is built once in jwc-global now as the canonical shared primitive; kai-chattr already has the OpenHands shell extraction mapped, and a later optional clone/split inherits this same shell rather than forking or porting it twice.
3. Records Phase B (the ProseMirror content-node projection) is a core product primitive, not a deferrable records feature. Its consumer is the product's all-format collaborative editor; the records node-architecture is the editor's substrate.
4. K runs on the records registry engine. The ~15 capability registries are the same type-first registry + normalizer engine the records system built, generalized from doc-records to capability-records.

Build spine

1. App shell (the frame) — the agentic 3-pane UX built in jwc-global now (side rail · center · right multifunctional workspace; floating containerized rounded resizable panel cards ~25% tighter than OpenHands; full-width, resizable via react-resizable-panels/Allotment), built extractable as the convergence-correct shared primitive.
2. ProseMirror / Tiptap all-format editor — the core collaborative work surface (fed by records Phase B).
3. Pillars as panels/views — K registries (rail), Chattr runtime + Letta identity (chat), Blockdata parse/blocks/workflow-graph (a workspace tab).

The governance/records pillar is already built (Phase A). The next concrete brick is the shell — built here in jwc-global now; keep the extraction seam clean and the shell unforked, and the rest slots in. Any clone/split is a later, optional extraction that inherits the already-built shell.

Sequencing — the build order

The agent UX — the Claude-desktop / VS-Code-agent look-and-feel (floating containers, the full multi-panel resizable shell) — is built in jwc-global now as part of the foundation, not deferred to a clone/split. The first frontend step is the bounded removal of the Fumadocs frontend (layout) components (JWC owns the docs shell + custom rail; Fumadocs keeps MDX/content/routing), and the agentic shell is built on that owned docs shell as the foundation.

Locked order:

1. Remove the Fumadocs frontend components — own the docs shell + rail, fix the layout, replace Notebook. (current step — finish)
2. Records Phase B — the ProseMirror content-node projection.
3. Hindsight + Postgres — the memory integration.
4. Tiptap (or alternative) — the rich editor.
5. Monaco — the code editor / diff surface.
6. (Optional, later) Clone + split from jwc — extraction inherits the already-built agentic shell and product convergence from jwc-global; nothing new lands here, the split just carries forward what was built in jwc-global.

This repo also has obstacles to clear first to keep the extraction seam clean. So jwc-global gets a clean owned docs shell now and the Claude-desktop agent UX is built on it now in jwc-global — build the shell here → prove it → optionally split later (the split inherits the shell, it is not where the shell is first built).