aarbitandClaude Sonnet 5 2f1b83e0a9 Add multi-diagram management
- DiagramRepository interface redesigned around multiple diagrams:
  list()/loadById()/deleteById() replace the old single-diagram
  load()/clear(). Both implementations updated to match.
- SupabaseDiagramRepository.save() now does an explicit update-or-insert
  instead of a blind upsert, so owner_id is only ever set at creation --
  an upsert would resend it on every save and let whoever saves last
  silently reassign ownership. Not reachable yet (no collaborator UI),
  but a real landmine once diagram sharing (organized-ideas.md §8) lands,
  and cheap to avoid now.
- LocalStorageDiagramRepository now stores diagrams keyed by id (was a
  single fixed key), keeping it a genuine working fallback rather than
  a stale reference implementing an old interface.
- Store: loadInitialDiagram (renamed from loadFromStorage) opens the
  last diagram you had open (tracked in localStorage -- a UI
  preference, not app data), falling back to the most recently updated
  one, falling back to a fresh empty diagram. New actions:
  refreshDiagramList, switchToDiagram, deleteDiagram. newProject and
  importProject now persist immediately (not just via the debounced
  autosave) so a new/imported diagram shows up in the list right away;
  importProject also assigns a fresh id so it can't collide with an
  existing diagram.
- New DiagramManagerModal (list/open/delete/+New), opened from a
  "Diagrams" button in TopBar that replaces the old single-diagram
  "New" button and its now-unnecessary confirmation dialog -- nothing
  is lost by creating a new diagram anymore, since the old one stays
  saved and reachable from the list.

Verified insert/list/update(-preserves-owner)/loadById/delete against
the real local stack; RLS test suite still 23/23 after a fresh reset.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017DUU6CnxECCDeqDNYJgr5x
2026-09-07 21:19:24 -05:00
2026-09-07 21:19:24 -05:00
2026-09-06 23:28:25 -05:00
2026-09-06 23:28:25 -05:00

AV Planner

Plan out AV/network installs: define devices and their ports, wire them together on a canvas, and get a bill of materials (devices + cables, with lengths) for what you'll need to buy.

Stack

  • React 19 + TypeScript + Vite
  • @xyflow/react (React Flow) for the device/wiring canvas
  • Zustand for app state
  • Tailwind CSS v4 for styling

Architecture

src/
  domain/       Framework-agnostic types + logic (compatibility rules, BOM math,
                the built-in connector/cable/device library). No React, no
                React Flow — safe to unit test or reuse from a future backend.
  data/         Storage abstraction. `ProjectRepository` is the interface the
                rest of the app codes against; `LocalStorageProjectRepository`
                is the only implementation today. Swapping in a real backend
                later (REST/GraphQL) means adding one new implementation of
                that interface, not touching state/UI code.
  state/        Zustand store (`projectStore`) — the single source of truth for
                the current project. Auto-saves to the repository (debounced)
                on every change.
  components/
    canvas/     React Flow wiring surface: custom device node, custom cable
                edge, connection validation.
    palette/    Device library sidebar + the "new custom device" editor.
    inspector/  Right-panel editors for the selected device or cable.
    bom/        Bill-of-materials view.
    layout/     App shell, top bar, panels.

Data model

  • PortType — a connector kind (HDMI, XLR, Cat5e/6, ...). Two ports can be wired together only if their PortTypes share a compatibility family.
  • DeviceTemplate — a reusable device shape (its ports), shown in the palette. Built-ins live in domain/library.ts; custom ones are saved on the project.
  • Device — an instance placed on the canvas, with its own copy of ports (editing an instance never mutates its template).
  • CableType — a physical cable spec, scoped to a PortType family.
  • Connection — a wire between two ports, referencing a CableType and an optional user-entered distance (there's no floor plan / scale model, so length is a manual estimate per connection).
  • Project — devices + connections + any custom library entries. This is the one object persisted (auto-saved to localStorage, or explicitly exported/imported as JSON).

Development

npm install
npm run dev      # start the dev server
npm run build    # typecheck + production build
npm run lint      # oxlint
S
Description
Visual AV planner
Readme
694 KiB
Languages
TypeScript 79.7%
PLpgSQL 16.3%
HTML 1.6%
JavaScript 1.3%
CSS 1.1%