Changeset 0.28.5 (#191)

This commit is contained in:
2026-03-14 22:51:50 +00:00
parent 85d5e3cc13
commit 6f0ad1355c
17 changed files with 2389 additions and 110 deletions

View File

@@ -27,14 +27,19 @@ v0.9.xv0.27.5 Foundation → Extensions → Surfaces → Auth ✅
├─ v0.28.2 ICD audit — all domains ✅
├─ v0.28.3 ICD close-out + FE decomp ✅
├─ v0.28.4 Security tier (red team) ✅
├─ v0.28.5 Infrastructure
│ (virtual scroll, KB auto-inject,
Helm chart, provider model prefs,
│ git credentials UI)
└─ v0.28.6 Frontend SDK
├─ v0.28.5 Frontend SDK + Pipes ✅
│ (switchboard-sdk.js, pipe/filter
pipeline, component mounting)
├─ v0.28.6 Infrastructure
│ (virtual scroll, Helm, task webhook
│ UI, system tasks, model prefs)
└─ v0.28.7 Unified Packaging + Task RBAC
(.pkg archive, manifest.type,
task permission gate pre-Starlark)
v0.29.0 Starlark Sandbox
(eval loop, permissions, admin UI)
(eval loop, permissions, admin UI
— adds starlark capability to .pkg)
v0.29.1 API Extensions
(Starlark route handlers,
@@ -44,13 +49,26 @@ v0.9.xv0.27.5 Foundation → Extensions → Surfaces → Auth ✅
(namespaced tables, scoped db module,
declarative schema in manifest)
v0.30.0 Surface Packages
(full-stack .surface archives:
UI + API + schema + settings)
v0.29.3 Workflow Forms
(form_template → real UI, LLM optional,
.star validation, structured data)
v0.31.0 Editor Surface Package
v0.30.0 Package Lifecycle
(schema versioning, migrations,
settings extension point,
export/import, marketplace)
v0.30.1 SDK Adoption
(sw.notes factory, core surface
migration, fix-once-fix-everywhere)
v0.30.2 Workflow Packages
(stage surfaces, custom UI per stage,
team admin workflow builder)
v0.31.0 Editor Package
(E2E proof: rebuild editor as
installable surface, zero
installable .pkg, zero
platform special-casing)
```
@@ -227,9 +245,61 @@ New `security` tier in ICD test runner. 58 tests, 529/531 pass.
- [x] `surfaces/` directory with `build.sh``dist/<n>.surface`
- [x] `hello-dashboard.surface` unpacked into `surfaces/hello-dashboard/`
### v0.28.5 — Infrastructure
### v0.28.5 — Frontend SDK + Pipes ✅
`switchboard-sdk.js` — composition layer over existing globals. Surface
authors consume a single coherent API instead of hunting through 15 JS files.
Pipe/filter pipeline formalizes the extension hook model into composable,
priority-ordered transform stages.
**SDK core:**
- [x] `Switchboard.init({ mount })` — idempotent boot: tokens, profile, theme, events, user menu
- [x] `sw.user`, `sw.isAdmin` — resolved identity
- [x] `sw.api.get()` / `sw.api.post()` — authenticated REST, no token/base-path management
- [x] `sw.on(event, fn)` — WebSocket subscription (no `Events` global knowledge)
- [x] `sw.chat(container, opts)` — drop-in ChatPane (wraps `ChatPane.create()`)
- [ ] `sw.notes(container, opts)` — stub shipped (warns); notes component
needs factory refactor before clean mounting (v0.30.1 SDK Adoption)
- [x] `sw.toast()`, `sw.confirm()` — UI primitives
- [x] `sw.theme.current`, `sw.theme.on('change', fn)` — theme queries
- [x] Absorbs cs15 UserMenu band-aid — universal hydration moves into `init()`
**Pipe/filter pipeline:**
Three stages, each a priority-ordered chain of transform functions.
Filters receive typed context, return (possibly modified) context.
Pipeline wires filters in priority order; any filter can halt the chain.
- [x] `sw.pipe.pre(priority, fn)`**pre-send**: transform user message
before LLM request. Context: `{ message, channel, attachments, metadata }`.
Runs on both `sendMessage()` and `regenerateMessage()` with `regenerate` flag.
- [x] `sw.pipe.stream(priority, fn)`**post-receive**: transform LLM
response stream chunks as they arrive (sync-only). Context: `{ chunk,
accumulated, channel, model }`.
- [x] `sw.pipe.render(priority, fn)`**post-render**: transform rendered
HTML/markdown after DOMPurify. Context: `{ element, message, channel }`.
Replaces `runExtensionPostRender()` with compat shim for existing
`ctx.renderers.register()` extensions.
- [x] Pipeline execution engine: ordered dispatch, error isolation (one
filter throws → skip it, continue chain), timing telemetry per filter
- [x] `sw.pipe.list()` — introspection: list registered filters by stage
with priority, source, scope, and timing stats
- [x] Filter scoping: `{ scope: { channelType: [...] } }` restricts
execution to specific channel types with zero-overhead skip
- [ ] Manifest `"pipes"` key: declarative filter registration — deferred
to v0.28.7 (unified packaging, where manifest keys are extended)
**Testing:**
- [x] ICD runner gains `sdk` test tier: 36 tests — boot, identity, REST,
events, theme, pipe registration, execution, scoping, halt, error
isolation, compat shim, introspection
- [x] Pipe filter tests: priority ordering, halt semantics, error isolation,
scoped/unscoped execution
### v0.28.6 — Infrastructure
- [ ] Virtual scroll for long conversations (prerequisite for heavy task output channels)
- [ ] KB auto-injection: top-K chunk prepend, context budget aware, per-channel toggle
- [ ] KB auto-injection: platform-registered pre-send pipe filter (`_kb-auto-inject`,
priority 5), top-K chunk prepend to `ctx.metadata.kb_context`, context budget aware,
per-channel toggle. First real validation of the v0.28.5 pipeline architecture.
- [ ] Helm chart (replaces raw k8s manifests, `helm install switchboard ./chart`)
- [ ] Per-provider model preferences — finalize: make `provider_config_id` required on
`PUT /models/preferences` (fixes NULL-in-UNIQUE dedup bug), migrate `/models/enabled`
@@ -240,23 +310,107 @@ New `security` tier in ICD test runner. 58 tests, 529/531 pass.
- [ ] `system.announcement` notification type: admin broadcast endpoint
(`POST /admin/notifications/broadcast`), fan-out to all active users via
`NotifyMany`, admin UI for composing announcements
- [ ] Task webhook trigger UI: schedule selector gains `webhook` option,
trigger URL displayed + copy button, outbound `webhook_url` + `webhook_secret`
fields in create/edit form, task-to-task chaining documentation in admin UI.
Backend fully implemented — this is pure admin UI work.
- [ ] System task type: `task_type: "system"` — built-in Go function registry
(`retention_sweep`, `memory_compact`, `session_cleanup`, `staleness_check`).
Admin creates task, picks function from dropdown, sets cron schedule. Executor
calls registered Go function instead of LLM completion. Replaces the current
goroutine-based background jobs with visible, configurable, auditable tasks.
Existing goroutines kept as fallback until system tasks are validated.
**Permanent track** — Go registry is not replaced by Starlark (v0.29.0).
Core platform ops must not break from bad user code. Admin-only by design
(no RBAC needed — hardcoded to admin role).
### v0.28.6Frontend SDK
`switchboard-sdk.js` — composition layer over existing globals. Surface
authors consume a single coherent API instead of hunting through 15 JS files.
### v0.28.7Unified Packaging + Task RBAC
Single `.pkg` archive format for both surfaces and extensions. Manifest
`"type"` field (`surface`, `extension`, `full`) drives install behavior.
Format first, capabilities later — v0.29.x adds Starlark/DB/API capabilities
into packages that already install cleanly.
- [ ] `Switchboard.init({ mount })` — idempotent boot: tokens, profile, theme, events, user menu
- [ ] `sw.user`, `sw.isAdmin` — resolved identity
- [ ] `sw.api.get()` / `sw.api.post()` — authenticated REST, no token/base-path management
- [ ] `sw.on(event, fn)` — WebSocket subscription (no `Events` global knowledge)
- [ ] `sw.chat(container, opts)` — drop-in ChatPane (wraps `ChatPane.create()`)
- [ ] `sw.notes(container, opts)` — drop-in notes component
- [ ] `sw.toast()`, `sw.confirm()` — UI primitives
- [ ] `sw.theme.current`, `sw.theme.on('change', fn)` — theme queries
- [ ] ICD runner gains `sdk` test tier: validates init, component mounting, event hooks
- [ ] Absorbs cs15 UserMenu band-aid — universal hydration moves into `init()`
Task permission model gates task creation by type and scope. Retroactively
locks down `action` tasks (webhook relay = data exfiltration risk) and
pre-positions for `starlark` tasks in v0.29.0.
Depends on: v0.28.5 (SDK — pipe/filter registration is part of manifest contract).
**Archive format:**
- [ ] `.pkg` archive: zip containing `manifest.json` + assets (JS, CSS,
templates, icons). Same structure as `.surface` archives, extended
manifest schema
- [ ] `manifest.type` field: `surface` (routes + templates + data loader),
`extension` (hooks + tools + pipes, no own route), `full` (both).
Absent `type` defaults to `surface` for backward compat
- [ ] `manifest.pipes` key: declarative pipe filter registration (pre-send,
post-receive, post-render) with priority and entry function reference.
Wired by SDK on extension load
- [ ] `manifest.tools` key: LLM-callable tool declarations (existing schema,
now part of unified manifest)
- [ ] `manifest.hooks` key: EventBus subscriptions (existing schema from
EXTENSIONS.md, carried forward)
**Install infrastructure:**
- [ ] `POST /admin/packages/install` — unified install endpoint. Reads
`manifest.type`, validates type-specific requirements, wires subsystems.
Replaces `POST /admin/surfaces/install` (old route kept as alias)
- [ ] Validation branches by type: `surface` requires `routes`/`template`,
`extension` requires at least one of `hooks`/`tools`/`pipes`, `full`
requires both sets
- [ ] Admin UI: merge Surfaces + Extensions into single "Packages" section.
Type badge on each entry. Filter by type. Enable/disable granular
for `full` packages (disable hooks independently of routes)
- [ ] `packages` table (or rename `surfaces``packages` with migration):
adds `type` column, retains all existing surface columns
**Migration:**
- [ ] Existing `.surface` archives install unchanged (type defaults to
`surface`). No re-install required
- [ ] Existing `extensions` table rows (loose-JS browser extensions) get
synthetic package wrappers: migration generates `manifest.json` from
existing DB fields, archives JS entry file into `.pkg` format
- [ ] `build.sh` in `surfaces/` updated to produce `.pkg` files. Directory
optionally renamed to `packages/`
- [ ] ICD runner surface install tests updated to use new endpoint (or alias)
**Task RBAC:**
Permission gate on task creation by `task_type` and `scope`. Must ship
before Starlark (v0.29.0) — cannot allow server-side code execution
without a permission model. Also retroactively locks down `action` tasks.
- [ ] `task_permissions` table (or extend `extension_permissions` pattern):
maps `(user_id | team_id | role) → task_type → allowed`. Default
permissions seeded on migration:
- Admin: all types, all scopes
- Team admin: `prompt`, `workflow` (team scope). `action` denied by default
- User: `prompt`, `workflow` (personal scope). `action` denied by default
- `system` always admin-only (hardcoded, not in permissions table)
- [ ] Create/update task handlers check permission before accepting
`task_type`. Existing `action` tasks grandfathered (can run, cannot
be cloned or created without permission). Migration adds warning
notification to owners of existing `action` tasks
- [ ] Admin UI: task permission management — per-user and per-team overrides.
"Allow action tasks for Team X" toggle. Pre-positions `starlark`
permission type (hidden until v0.29.0 enables it)
- [ ] `POST /api/v1/tasks` and `PATCH /api/v1/tasks/:id` validate
`task_type` against caller's permissions. 403 on denied type
- [ ] ICD tests: permission-denied task creation, team admin boundaries,
admin override
**ICD + docs:**
- [ ] `packages.md` ICD: install, list, enable/disable, delete, type filtering
- [ ] `EXTENSIONS.md` updated: packaging section references `.pkg` format,
loose-JS model documented as legacy
- [ ] `tasks.md` ICD updated: permission model, per-type RBAC
- [ ] ICD runner gains `packaging` test tier: install surface-type, install
extension-type, install full-type, type validation, backward compat
**Tier 2 — Medium value (pull into any v0.28.x):**
- [ ] User-installable extension packages: RBAC-gated `POST /packages/install`
(non-admin), team-scoped or personal scope, permission review flow.
Depends on v0.28.7 packaging.
- [ ] Memory compaction: summarize old memories, confidence decay, prune low-confidence
- [ ] `capability_match` routing policy ("cheapest model with tool_calling")
- [ ] New provider types registrable via config file (OpenAI-compatible + custom schema)
@@ -268,7 +422,8 @@ authors consume a single coherent API instead of hunting through 15 JS files.
Server-side extension runtime. Prove the eval loop, permission pipeline,
and admin UI before adding capabilities.
Depends on: v0.28.0 (platform polish), extension infrastructure (v0.11.0).
Depends on: v0.28.0 (platform polish — specifically v0.28.7 unified packaging),
extension infrastructure (v0.11.0).
- [ ] `go.starlark.net` integration (eval loop, timeout, memory ceiling)
- [ ] Permission model: manifest declarations, admin grant/revoke, DB schema
@@ -282,6 +437,21 @@ Depends on: v0.28.0 (platform polish), extension infrastructure (v0.11.0).
(emit to users)
- [ ] Migration: `extension_permissions` table
- [ ] ICD: update `extensions.md` with Starlark-specific endpoints
- [ ] `task_type: "starlark"`: task executor gains Starlark code path.
Task references a `.star` script (inline or from a `.pkg`), executor
runs it in the sandbox with task context (trigger payload, schedule
info, previous run data). No LLM, no webhook relay — actual computation.
RBAC gate from v0.28.7 enforced: `task.starlark` permission enabled
in `task_permissions` (hidden until this version). Admin-grantable
to team admins on a per-team basis.
**Two-track execution model (permanent):**
- `system` (v0.28.6): Go function registry — core platform ops
(`retention_sweep`, `memory_compact`, etc.). Cannot break from
bad user code. Admin-only, not editable, not versionable.
- `starlark`: custom admin/team admin tasks — nightly reports,
data quality checks, integration sync, cleanup scripts. Editable,
versionable, sandbox-isolated, permission-gated.
---
@@ -325,33 +495,192 @@ Depends on: v0.29.1 (API extensions — handlers need somewhere to persist).
---
## v0.30.0 — Surface Packages
## v0.29.3 — Workflow Forms
The `.surface` archive becomes the full-stack packaging unit.
`form_template` renders as real UI. The LLM moves to the corner —
present if configured, but not required for data collection. Workflows
become structured processes, not guided conversations.
Depends on: v0.29.2 (DB extensions).
Depends on: v0.29.2 (DB extensions — structured form data persists in
`ext_workflow_*` tables, not just `stage_data` JSON blob), v0.29.0
(Starlark — `.star` validators run on form submission).
- [ ] Install creates schema + mounts routes + serves assets in one operation
- [ ] Schema versioning: `"schema_version": N` in manifest
- [ ] Schema migrations: `"migrations": [{"from": 1, "to": 2, "sql": "..."}]`
- [ ] Settings extension point: surfaces declare settings sections in manifest,
platform settings surface renders them alongside core sections
- [ ] Export/import format for sharing surfaces across instances
- [ ] Surface marketplace (discovery, not hosting — instances pull from URLs)
**Form rendering:**
- [ ] `form_template` schema: typed field definitions (`text`, `email`,
`select`, `number`, `date`, `textarea`, `checkbox`, `file`).
Validation rules per field (`required`, `pattern`, `min`/`max`).
Current freeform JSON → structured schema with backward compat
(old JSON treated as `textarea` field prompts for the LLM)
- [ ] Stage renders as form when `form_template` has typed fields.
HTML form generation from schema, client-side validation,
styled with platform CSS custom properties
- [ ] Form submission → `stage_data` merge (same `MergeWorkflowStageData`
path as chat-based data collection, but from structured fields
instead of LLM extraction)
- [ ] Stage advance on form submit: if `auto_transition: true` and all
required fields pass validation, advance without human operator
or LLM involvement
**LLM-optional stages:**
- [ ] Stage without `persona_id` renders form only — no chat pane, no
completion endpoint, pure data collection
- [ ] Stage with `persona_id` + `form_template` renders form + chat
side-by-side: user fills form, LLM assists (auto-fill suggestions,
field explanations, validation help)
- [ ] Stage with `persona_id` + no `form_template` — current behavior
(pure chat-based collection, no change)
**Starlark validation:**
- [ ] `validate` Starlark hook: manifest declares `.star` validator per
stage. Runs on form submit before advance. Returns field errors
or approval. Uses `db` module for cross-reference validation
(e.g., "is this email already in the system?")
- [ ] `on_submit` Starlark hook: post-validation side effects (create
records, send notifications, call APIs via `http` module)
**Visitor form entry:**
- [ ] Visitor entry point renders form for non-chat stages (branded
page with form, no chat widget). Session-scoped same as current
visitor auth model
- [ ] Progressive: visitor sees form → submits → next stage (may be
form or chat or operator review)
**Team admin UX:**
- [ ] Form builder: visual field editor in workflow admin (drag fields,
set types/validation, preview). Replaces raw JSON textarea for
`form_template`. Admin-only initially, team admin in v0.30.2.
---
## v0.31.0 — Editor Surface Package
## v0.30.0 — Package Lifecycle
Rebuild the editor as an installable surface package. Zero platform
special-casing — same `POST /admin/surfaces/install`, same manifest,
same `/s/:slug` route as any third-party surface. If `pages.go` or
Lifecycle sophistication for the `.pkg` format established in v0.28.7.
Schema management, settings integration, and ecosystem features.
Depends on: v0.29.2 (DB extensions — schema declarations must exist before
versioning and migrations make sense).
- [ ] Install creates schema + mounts routes + serves assets in one operation
(extends v0.28.7 install with v0.29.2 schema support)
- [ ] Schema versioning: `"schema_version": N` in manifest
- [ ] Schema migrations: `"migrations": [{"from": 1, "to": 2, "sql": "..."}]`
- [ ] Settings extension point: packages declare settings sections in manifest,
platform settings surface renders them alongside core sections
- [ ] Export/import format for sharing packages across instances
- [ ] Package marketplace (discovery, not hosting — instances pull from URLs)
---
## v0.30.1 — SDK Adoption
Migrate core surfaces to consume the SDK instead of raw globals.
Prerequisite for the Editor Package — if the platform's own surfaces
don't use `sw.*`, the SDK isn't validated for real.
The goal: a bug fix in `sw.notes()` or `sw.chat()` propagates to every
surface automatically. No more duplicated wiring, no more "fixed on
chat but broken on editor" class of bugs.
Depends on: v0.28.5 (SDK exists), v0.30.0 (package lifecycle — settings
extension point needed for surface-specific config).
**Component factories:**
- [ ] `sw.notes(container, opts)` — real factory: creates NoteEditor,
note list, graph panel. Extracted from `notes.js` monolith into
self-contained mountable component. `opts: { projectId, channelId,
onLink, standalone }`. Returns instance with `destroy()`.
- [ ] `sw.chat(container, opts)` — extend existing wrapper with pipe
integration (stream/render filters auto-wired), model selector
binding, file upload, typing indicator. Currently thin wrapper
around `ChatPane.create()` — needs to become the canonical path.
- [ ] `sw.panels(container, opts)` — PaneContainer composition via SDK.
Resize, tab management, drag handles. Fixes the "scaling bug lives
in two places" problem — one implementation, one fix.
**Core surface migration:**
- [ ] Chat surface (`app.js`, `chat.js`): boot via `sw = Switchboard.init()`,
replace direct `API.*` / `Events.*` / `UI.*` calls with `sw.*` in
new code paths. Existing code keeps working (globals still exist).
Progressive — not a rewrite, just new code uses the SDK.
- [ ] Editor surface (`editor-surface.js`): mount chat pane via `sw.chat()`,
mount notes via `sw.notes()`, consume `sw.theme.on('change')` for
CM6 theme sync. Removes duplicated panel resize/scale wiring.
- [ ] Notes surface: mount via `sw.notes()`, share implementation with
chat sidebar notes panel.
- [ ] Settings surface: consume `sw.api.*` and `sw.theme.*`.
**Validation:**
- [ ] Existing ICD runner tests still pass (surfaces behave identically)
- [ ] ICD runner `sdk` tier extended with component mount/destroy tests
- [ ] Manual: chat, editor, notes surfaces all function after migration
- [ ] Bug fix propagation test: fix applied to `sw.notes()` visible on
both chat sidebar and notes surface simultaneously
---
## v0.30.2 — Workflow Packages
Workflows become packageable. Each stage can serve its own surface —
form, dashboard, chat, or custom UI. Team admins build and manage
workflows through a visual builder, not JSON editing.
Depends on: v0.29.3 (workflow forms — form rendering exists),
v0.30.0 (package lifecycle — schema versioning, settings extension point),
v0.30.1 (SDK adoption — stage surfaces consume `sw.*`).
**Stage surfaces:**
- [ ] A workflow stage can reference a surface (built-in or from a `.pkg`).
Stage config gains `surface_id` field — platform mounts that surface
when the stage is active, with stage data injected as context
- [ ] Built-in stage surfaces: `form` (v0.29.3 form renderer), `chat`
(current behavior), `review` (operator sees collected data + approve/reject)
- [ ] Custom stage surfaces: a `.pkg` with `type: "workflow-stage"` provides
a surface that receives stage data and emits advance/reject signals
via `sw.workflow.advance(data)` / `sw.workflow.reject(reason)` SDK calls
- [ ] Stage transitions respect surface completion — surface signals "done"
with structured data, workflow engine merges and advances
**Workflow-as-package:**
- [ ] `.pkg` with `type: "workflow"`: bundles workflow definition, stage
surfaces, Starlark handlers, and assets in one installable archive.
`POST /admin/packages/install` creates the workflow + stages + surfaces
- [ ] Manifest `"workflow"` key: stages, transitions, form schemas, surface
refs, on_complete hooks. Replaces manual workflow creation via admin API
- [ ] Version pinning: installed workflow package tracks its package version.
Upgrade re-publishes with new version number
**Team admin workflow builder:**
- [ ] Visual stage editor: drag-to-reorder stages, per-stage config panel
(surface type, persona, form fields, transition rules, assignment)
- [ ] Form builder integrated per stage (extends v0.29.3 admin form builder)
- [ ] Preview: team admin can walk through the workflow as a visitor would,
seeing each stage surface in sequence
- [ ] Publish/version from the builder UI — no JSON, no API calls
- [ ] Team admin permission: `workflow.manage` — team admins can create,
edit, publish workflows for their team. Global admin can create
global workflows. Regular users can only enter workflows, not build them
**SDK extensions:**
- [ ] `sw.workflow` namespace: `advance(data)`, `reject(reason)`,
`getData()`, `getStage()`, `onTransition(fn)` — stage surfaces
interact with the workflow engine through the SDK, not raw API calls
---
## v0.31.0 — Editor Package
Rebuild the editor as an installable `.pkg` package. Zero platform
special-casing — same `POST /admin/packages/install`, same manifest,
same `/s/:slug` route as any third-party package. If `pages.go` or
`main.go` need changes to support it, the platform abstraction is
wrong, not the editor.
Validates the full v0.29.xv0.30.0 stack E2E.
Validates the full v0.28.7v0.30.2 stack E2E: unified packaging, Starlark
handlers, DB extensions, package lifecycle, SDK adoption, and workflow
packages all exercised by one real-world package.
Depends on: v0.30.0 (surface packages with settings extension point).
Depends on: v0.30.2 (workflow packages — editor validates the full stack
including workflow stage surfaces).
**Platform primitives consumed (not owned):**
- CM6 (core UI primitive — chat input, notes, code blocks all use it)
@@ -359,15 +688,15 @@ Depends on: v0.30.0 (surface packages with settings extension point).
- Git tools + credentials (v0.28.0 — core settings, vault-encrypted)
- Provider resolution via `requires_provider` (v0.29.1)
**Surface package delivers:**
- [ ] Editor `.surface` archive: manifest, JS, CSS, Starlark handlers
**Package delivers:**
- [ ] Editor `.pkg` archive (type: `full`): manifest, JS, CSS, Starlark handlers
- [ ] Built separately, installed via admin API — follows exact same
patterns as any other surface
patterns as any other package
- [ ] Editor settings section (via v0.30.0 settings extension point):
keybindings (vim/emacs/standard), font size, editor theme
- [ ] Editor state persistence via `ext_editor_*` tables: open tabs,
cursor positions, split layout, per-workspace config
- [ ] File tree, tab bar, multi-pane layout — all via surface JS,
- [ ] File tree, tab bar, multi-pane layout — all via package JS,
consuming platform CSS custom properties
- [ ] Markdown preview (improved renderer, shared with notes surface)
- [ ] Remove editor from core: delete `surface-editor` template,