dea26f7ee8b05a0283fdbb9185e09d5c53782401
Per organized-ideas.md §8. Backend tables/RLS (diagrams, diagram_collaborators, diagram_snapshots) already existed from an earlier phase — this is the frontend for them, plus two small backend additions. Backend (supabase/migrations/20260913000000_diagram_sharing.sql): - find_user_id_by_username(text): lets any authenticated user resolve a username to an id for "share with @username" — unlike general profile browsing (blocked by profiles_select_self_or_super_admin), a username is meant to be a shareable handle, so this is deliberately not gated. - diagram_collaborator_usernames / diagram_snapshot_saved_by_usernames: same pattern as the admin-review-queue phase's submitter-username lookup — batched per diagram, gated to "can you see this diagram at all" (reusing diagrams_select's own helper functions). - prune_diagram_snapshots trigger: keeps the 50 most recent snapshots per diagram, enforced at write time rather than a scheduled job (diagram_ snapshots has no update/delete policy for regular users at all). - 14 new pgTAP tests (52/52 total). Frontend: - DiagramCollaboratorRepository/store + DiagramSharingModal: add/remove collaborators by username, per-person view/edit permission, owner-only controls. - DiagramSnapshotRepository/store + VersionHistoryModal (its own top-bar button, not nested under Share — moved there after review): periodic checkpoints (one per 5 min of active editing) written as a side effect of normal saves, list + restore. - Restore's duplicate-snapshot problem: repeatedly jumping between old versions without editing in between was writing a near-duplicate safety snapshot on every jump. Fixed by having projectStore track which snapshot the diagram was last restored from and its updatedAt at that moment (touch() always advances updatedAt on a genuine edit) — a restore skips the safety snapshot when nothing has changed since the last one, and the tracking clears on any real edit so in-progress work stays protected. - DiagramRepository gains getAccess() (owner id + your own permission for the open diagram) — surfaced in projectStore as `access`. - View-only enforcement: FlowCanvas disables drag/connect/drop (nodesDraggable/nodesConnectable + guarded handlers), DeviceInspector/ ConnectionInspector wrap their controls in a disabled <fieldset>, DevicePalette disables adding devices to the canvas, TopBar disables the rename field, and a ViewOnlyBanner makes the restriction visible instead of leaving a collaborator to discover it as controls that just don't work. Autosave itself also refuses to write for a view-only user, as a backstop behind the UI-level lockdown. Verified: tsc -b and oxlint clean; supabase db reset + 52/52 pgTAP tests pass; confirmed find_user_id_by_username works through the real REST API via a live curl call (signup, confirm, resolve). Manually tested two- account sharing (view vs. edit), restoring history, and the duplicate- snapshot fix.
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
Languages
TypeScript
79.7%
PLpgSQL
16.3%
HTML
1.6%
JavaScript
1.3%
CSS
1.1%