Design for letting the owner record off-repo work as a commits row
tagged source=manual, reusing every existing commit render path
(recent work, card history, activity/monthly aggregation) instead of
a parallel system, with a declared-hours figure added to the total
rather than session-clustered, and a small "Logged" tag distinguishing
it from a real commit everywhere it appears.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Added .superpowers directory to .gitignore to prevent tracking of specific Pocketbase data. Updated Next.js configuration to enable standalone output for optimized Docker image builds, reducing the need for the full node_modules tree.
Design for grouping projects by client on the home page and in a new
sidebar Kanban flyout tree, making the dashboard the project landing
page with the board one click away, and a prototype/project kind flag
so unsolicited client-facing prototypes can live alongside committed
projects with the same permissions, just tagged differently.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Two views rather than one chart, because the data forced it: measured on
the live database, 1 of 5 live cards has a target date and none has both
dates. target_date is client-owned and optional; start_date is only set on
Inbox acceptance. A conventional Gantt would render almost empty.
So Now/Next/Later is the default and works with zero dates, and the
timeline earns its place as clients set dates. From Dave's Gantt reference
it takes the quarter header, the Today marker, project grouping with the
client's colour, and the per-row completion percentage — which maps onto
checklist progress, the one honest source for it. The faint full-width
track is load-bearing rather than decorative: it makes a sparse chart read
as unscheduled instead of broken.
Drag-to-reschedule always writes an activity row naming the owner, because
target_date belongs to the client. A developer silently moving a date the
client chose is the failure the activity log exists to prevent.
Completes the plan set for phases 1 through 5.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
4a builds the stateless interview. Every constraint that matters is
enforced in code rather than requested in the prompt: the seven-question
cap, the answer length, and what fields a brief may contain. parseBrief is
a whitelist, not a parser — a brief asserting priority or accepted loses
those at the boundary and they never reach a caller that could act on them.
4b adds a separate intake route rather than extending Plan 1a's client
card route. That route's tests were written against a two-field body;
widening the shape it accepts would leave them passing while proving less.
Both routes set column, priority, accepted and created_by_role themselves,
and both are separately proven to.
The property both plans are written to: the worst a hostile brief can
achieve is a strangely-worded card in the Inbox.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
A guided interview that produces a written brief with sub-tasks, landing
in the Inbox as a draft through Plan 1c's existing accept flow.
Corrects an over-promise made during the Phase 1 discussion: the wizard
was described as grounding date proposals in measured per-card velocity,
and that data does not exist — Plan 2c deferred per-card effort because
session padding does not sum correctly across cards. This phase therefore
produces no time estimate at all, only a size band.
Names the intake as the highest-risk surface in the product: it is the
only place where text written by someone other than the developer enters
a prompt whose output creates records. The security property is that the
worst a hostile brief achieves is a strangely-worded Inbox card.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
One-liners per commit and a progress narrative per card, plus the
swappable provider layer both depend on, ported from the chat/ structure
in MEGAIFRASTRUCTURE.
Model and cost are measured rather than assumed: the full 779-commit
backfill costs about ninety cents on claude-opus-5, so model choice here
is a quality decision and not a cost one. Batch API considered and
rejected — it saves roughly forty cents and adds a job state machine.
Records the rules the non-editable preamble must guarantee, each tied to
a specific way a summary could mislead a paying client.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The neutral (gray) pill read as a status badge rather than an integral
annotation. The brand tone ties the indicator visually to the brand,
making it part of the figure rather than an overlay. The meaning is the
same — 'this number is not measured, it is computed' — and the methodology
panel still explains exactly how.
2b closes a gap between the spec and the schema: the spec's [#42] explicit
link had nothing to reference, because cards only had PocketBase ids. Adds
per-project card numbers, and sharpens two rules the spec left loose — a
scope rule is bounded by start_date OR created, and ties go to the card
with the latest bound rather than the most recently edited one.
2c builds the dashboard. The South African holiday table is verified
against the Hermes build log: 24 May to 8 Sep 2026 gives 108 calendar days
and 75 workdays, both exact, and that is now a regression test.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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>
