Eleven tasks covering conventional-commit parsing, HMAC webhook
verification, the Forgejo client, a shared idempotent ingest core, the
webhook and reconciliation endpoints, and the backfill admin panel.
The Forgejo API shape, pagination headers and merge counts are measured
against the live instance rather than recalled, and the plan says so, so
the implementer builds against facts.
Surfaces one unresolved issue for decision: projects.webhook_secret is
readable by a client manager straight from PocketBase, because rules are
record-level and cannot hide a field.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Builds on the Hermes build log Dave produced by hand from WFDASH-WEBAPP,
adopting its metric set, activity calendar and workdays-not-calendar-days
framing, and correcting three things: the "6 contributors" who were one
person plus AI agents, two undocumented hour methodologies, and monetary
framing that suited an internal audience but not a client-facing page.
Settles the effort methodology with named constants shown on the page,
excludes merge commits (verified: 787 total, 779 non-merge, 8 merges), and
requires HMAC verification on the webhook endpoint.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Fourteen tasks covering clients, projects, manager accounts, column
management and the archive, so the owner can run the product without the
PocketBase console or the seed script.
Records why account creation must use a superuser connection: the users
write rules are locked because role is an ordinary field there, and both
the signup and self-promotion paths were verified exploitable. Adds a
verification step that re-runs the escalation guard, since this is the
phase most likely to reopen it.
Corrects Plan 1c's deferred list: the AI settings screen belongs to
Phase 3 per spec section 5.3, not here.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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>
- 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>
