Two dependency problems, and only one of them was real.
── Real: two majors of the same library ──
The root asked for `react-resizable-panels@^4.0.15` (4.6.5) while
`src/workspaces/components` asked for `^2.1.7` (2.1.9). The workspace code targets 2.x,
whose API differs — v4 has no `PanelGroup` export, no `order` prop and no `ref` on
`Panel` — so a file that resolved the root's copy failed to typecheck in a way that
read like a broken extraction.
Nothing imported the root's version. It was vestigial, and removing it collapses the
repository to one: every importer now resolves 2.1.9 and the lockfile has zero v4
entries.
── Not real: the second React ──
Declaring react/react-dom in the package created
`src/workspaces/workspaces/node_modules/react`, which looks exactly like the
duplicate-instance bug that silently breaks hooks. It is not one. Both locations resolve
to the SAME file in bun's store — the local entry is a symlink — which I established by
resolving the specifier from each place instead of reading directory names, having
already reported it as a hazard on the strength of an `ls`.
Declared as optional peers regardless: that is the right metadata for a consumer, and it
stops bun installing peers it does not need to.
Notes corrected to match, since the wrong version of that story was written down.
tsgo clean, package 114/114, full suite 950 pass / 7 fail unchanged, frontend builds.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Phase 1: the Workspace/Panel system is `src/workspaces/workspaces`, and it no longer
knows Officer exists.
The proof is its test suite. 114 tests mount `WorkspaceView` under a BARE React tree —
no react-query provider, no router, no Officer hook — which is only possible because
the host now supplies everything: a registry mapping `appType` to a component, and a
layout with a way to change it.
Officer is untouched. All 24 `WorkspaceView` sites and 8 `WorkspaceLayout` sites call
exactly what they called before; `Workspace/index.ts` became an adapter that adds back
the three things that are genuinely ours — the app registry, fullscreen persistence in
sessionStorage, and the handshake that stands the nav header down for a fullscreen
panel.
── The shape, and why it is this shape ──
`core/` is the tree and every operation on it: pure, no dependencies, no React. `react/`
is one renderer. That split is phase 2's whole cost saving — a second renderer reuses
`splitPanel`, `movePanel`, `normalizeLayout` and the rest untouched, and what will not
port is the resize INTERACTION rather than the layout engine.
It was already half done: `layout-utils.ts` imported only `./types`, and `WorkspaceView`
already received `{ key, value, setValue, isLoaded }` as a prop and always wrote through
an updater. The real coupling was the registry, fullscreen, and four UI imports.
Also deleted ~175 lines of dead code — `DragOverlay`, `LayoutEditor`, `WorkspaceHeader`
— referenced by nothing.
── Two dependency traps ──
**A second React.** Declaring react/react-dom in the package produced a second copy
under its own node_modules. Two React instances break hooks at runtime and are invisible
until something renders. The package now declares almost nothing while it lives here.
**Two versions of react-resizable-panels.** The root asks ^4.0.15 (4.6.5),
`src/workspaces/components` asks ^2.1.7 (2.1.9), and this code targets 2.x — v4 has no
`PanelGroup`, no `order`, no `ref` on Panel. Inheriting the root resolution produced a
screenful of type errors that read like a broken extraction and were a version
mismatch. Pinned; the duplication itself is worth fixing one day.
── Verified ──
tsgo clean. Package suite 114/114. Full suite 950 pass / 7 fail, unchanged. Frontend
builds, and the running app was screenshotted against the pre-extraction baseline: 9 of
16 byte-identical, the rest live data and the rotating wallpaper. Panel chrome, headers,
splitters and the grid all render as before.
Docs written as part of the work: the package README is the contract, and
WORKSPACES-NOTES.md carries the open items — panel-to-panel channels, the theme
classes the package still assumes, and phase 2.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
pastilhasandClaude Opus 5