Fourteen tasks covering the card detail page, checklists, comments, a
readable activity timeline, card creation for both roles, and the accept
flow that stamps start_date.
Owner mutations are Server Actions on the caller's own token; client
mutations keep going through the whitelisted /api/client routes. Records
the constraint that activity.createRule is superuser-only, so audit rows
need a dedicated helper even for the owner.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
activeId clears the instant the pointer is released, so gating the
focus-refresh on it alone left a window between drop and server
confirmation where a refresh could overwrite the optimistic position with
stale state and the card would appear to snap back. Tracks a separate
saving flag, and reverts on a thrown fetch as well as a non-ok response.
Also corrects a comment: sensors are created unconditionally; what keeps a
client manager from dragging is that they never render DndContext.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The login page was still on Plan 1a's dark-only palette, so in light theme
it rendered a near-black card on a light page with the heading black-on-black
and effectively invisible. This is the first screen a client ever sees.
Plan 1b Task 13 required the hardcoded-colour grep to return nothing; it was
not run.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
There is one PocketBase instance and it is hosted. Removes the `npm run pb`
script, which started a local server nothing used.
The schema had two apparent sources of truth. scripts/setup-remote.ts is the
one that actually runs; pb_migrations/ only executes on PocketBase server
start, which never happens here. Both now say so, so nobody edits a migration
and believes the schema changed.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
- migrations/ documented in pocketbase/pb_migrations/ for local PB
- scripts/setup-remote.ts applies them via admin API to remote PB
- collections: clients, projects, columns, cards, subtasks, comments, activity, settings
- user extension: role (owner|client_manager), client (relation)
- writes: owner only for app collections, superuser-only for activity and settings
Eighteen tasks, 86 steps, covering the PocketBase schema, auth, the
field-level whitelist that PocketBase rules cannot express, the three
client routes, and all five acceptance tests from the spec.
Board UI is deferred to Plan 1b so the security boundary can be reviewed
on its own rather than inside a large UI diff.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Covers the data model, the field-level permission model, card ordering,
pages, and acceptance criteria for the board spine. Records the decisions
carried into Phases 2-5 (commit linking, ingestion, effort inference, AI
publishing policy) so later specs do not relitigate them.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
