Files
pad/web
xarmian b253a2be6f test(attachments): cover the wiring the unit suites structurally cannot
Final review round 3, on the test suite as a deliverable.

The panel had no producer-to-host test: the strip's tests mock the event
bus, the panel host's tests emit on it directly, and between them a
broken hostToken thread through ItemDetail would have passed everything.
Verified by breaking that thread — the new browser test fails, the whole
unit suite stays green.

It is also the only place DR-12's "activates exactly once per key press"
can be demonstrated at all: jsdom does not synthesise a button's
activation click, so the unit test could only ever prove the narrower
"no hand-rolled handler races the UA click". That test is renamed to
claim exactly that, with a pointer to where the real one lives.

Also folds the workspace into the host-address reader. It was captured
once in the Tiptap options while the URL builder stayed live, so a
mounted chip surviving a pane workspace switch would probe under the
PREVIOUS workspace's key — a cross-workspace answer, cached under the
wrong key. Same staleness class as the item id, one axis over. This
incidentally makes the image extension's `address` option load-bearing
rather than the dead plumbing the review flagged: its probes read the
live workspace through it now.

isAddressable deliberately takes only the two ROUTING fields — the
workspace rides along for cache keying and says nothing about whether an
event can find its host.
2026-08-04 19:50:22 +00:00
..
2026-03-26 01:52:36 +00:00
2026-03-26 01:52:36 +00:00
2026-03-26 01:52:36 +00:00
2026-03-26 01:52:36 +00:00
2026-03-26 01:52:36 +00:00

Pad Web UI

SvelteKit 2 + Svelte 5 frontend for Pad, compiled to static files and embedded into the Go binary.

Development

npm install
npm run dev          # Dev server at localhost:5173 (proxies API to localhost:7777)
npm run build        # Production build to build/
npm run check        # Type checking with svelte-check

When developing, run the Go backend separately with make dev from the project root.

Building for Production

Do not build in isolation. Always use make build from the project root — this builds the web frontend, then compiles the Go binary with the build output embedded via //go:embed.

Stack

  • Svelte 5 with runes ($state, $derived, $effect)
  • SvelteKit 2 with adapter-static (SPA mode)
  • Tiptap block editor with markdown round-trip
  • svelte-dnd-action for drag-and-drop in board/list views
  • SSE for real-time updates
  • TypeScript throughout

Structure

src/
  routes/                    SvelteKit pages
    +layout.svelte           App shell (sidebar + main)
    +page.svelte             Landing/redirect
    [workspace]/
      +page.svelte           Dashboard (collections, phases, activity)
      +layout.svelte         SSE connection per workspace
      [collection]/
        +page.svelte         Collection view (board/list)
      [collection]/[item]/
        +page.svelte         Item detail + editor
      conventions/            Purpose-built conventions page
      playbooks/              Purpose-built playbooks page
      settings/               Workspace settings
  lib/
    api/client.ts            HTTP API client
    components/
      layout/                Sidebar, navigation
      editor/                Tiptap editor, raw markdown editor
      fields/                FieldEditor, relation picker
      items/                 ItemCard, ItemDetail
      collections/           BoardView, ListView
      common/                StatusBadge, badges, modals
      search/                CommandPalette
      activity/              ActivityFeed
    stores/                  Svelte 5 reactive stores
      workspace.svelte.ts    Workspace state
      collections.svelte.ts  Collection + item state
      ui.svelte.ts           Sidebar, mobile state
    types/index.ts           TypeScript types and constants
  app.css                    Global styles and design tokens