diff --git a/docs/screenshots/admin-access/admin-content.png b/docs/screenshots/admin-access/admin-content.png new file mode 100644 index 0000000..abab2c1 Binary files /dev/null and b/docs/screenshots/admin-access/admin-content.png differ diff --git a/docs/screenshots/admin-access/admin-messages.png b/docs/screenshots/admin-access/admin-messages.png new file mode 100644 index 0000000..ab65630 Binary files /dev/null and b/docs/screenshots/admin-access/admin-messages.png differ diff --git a/docs/screenshots/admin-access/admin-users-edit.png b/docs/screenshots/admin-access/admin-users-edit.png new file mode 100644 index 0000000..872c15d Binary files /dev/null and b/docs/screenshots/admin-access/admin-users-edit.png differ diff --git a/docs/screenshots/admin-access/admin-users.png b/docs/screenshots/admin-access/admin-users.png new file mode 100644 index 0000000..7d11424 Binary files /dev/null and b/docs/screenshots/admin-access/admin-users.png differ diff --git a/fofafu_vault/features/admin-access.md b/fofafu_vault/features/admin-access.md new file mode 100644 index 0000000..2797ba0 --- /dev/null +++ b/fofafu_vault/features/admin-access.md @@ -0,0 +1,136 @@ +--- +slug: admin-access +title: Admin Access +owner: engineering +collaborators: [] +status: review +priority: P2 +created: 2026-08-20 +target: null +links: + kanban: "[[kanban/engineering]]" + designs: null +--- + +# Admin Access + +## Problem + +There is no admin capability in fofafu today. Every table (`families`, `announcements`, `comments`, `reactions`, `messages`, `availability_slots`, `playdate_requests`, `coach_events`) now lives in Supabase Postgres with RLS scoping every read/write to `auth.uid()` (see [[features/migrate-render-to-vercel-supabase]], [[features/supabase-rls-sensitive-columns]]), and there is no identity in the system that can see or fix another family's data. [[features/moderation-report-block]]'s own Problem statement names the gap directly — "the only available escape valves are leave the platform or ask an admin manually — both too heavy" — and its Out of scope explicitly defers "Admin moderation queue UI" because there's no admin to view it yet. + +This feature is that admin: one trusted account (Rei) that can view and correct any user's data — profile, posts, comments, reactions, DMs, playdate data — for support and moderation purposes, without needing raw database access for every fix. + +Scope decision from product: full edit access, including reading/editing private messages between other users. That is a real privacy line for a platform whose core data is about foster families and children, so this spec leans hard on RLS-level enforcement (not just application-code checks) and an append-only audit log of every admin action — see Acceptance criteria. + +## Acceptance criteria + +- [ ] A Postgres `is_admin()` SQL function (`SECURITY DEFINER`, matches the caller's `auth.uid()` against the hardcoded admin email `kurarei+5@gmail.com`) is the single source of truth for admin identity. No `role` column, no multi-admin support in v1 — this was an explicit product decision. +- [ ] Every RLS-enabled table (`families`, `announcements`, `comments`, `reactions`, `messages`, `availability_slots`, `playdate_requests`, `coach_events`) gets an additional `FOR ALL USING (is_admin()) WITH CHECK (is_admin())` policy, so the admin's own session token — not a service-role key — can read and write any row, including DMs in `messages` between two other users. +- [ ] A new `supabase/functions/admin/index.ts` Edge Function (same shape as the existing `message`/`family`/`playdates` functions: `supabaseForRequest`, `requireUserId`, segment-based routing per `supabase/functions/_shared/client.ts`) exposes admin CRUD across the tables above. Every route calls `rpc('is_admin')` and 403s before touching any data. +- [ ] Editing the identity-level fields Supabase itself owns (an arbitrary user's email, forcing a password reset, banning/deleting the account) goes through the Supabase Admin API (`supabase.auth.admin.*`), using a service-role client constructed only inside this function, only after the `is_admin()` check passes. The service-role key never reaches the frontend. +- [ ] Every admin mutation — table edits and `auth.admin.*` calls alike — writes one row to a new `admin_audit_log` table (`admin_user_id, action, target_type, target_id, before, after, created_at`) in the same request. No admin write path skips the audit log. +- [ ] `admin_audit_log` is itself RLS-protected: readable only via `is_admin()`, and no UPDATE/DELETE policy exists on it at all (append-only, matches this vault's own log convention). +- [ ] Frontend `/admin` route (React Query + `edgeRequest` against the new function — same convention as `messages.ts`/`playdates.ts`) with views for **Users** (families data + auth identity), **Content** (announcements/comments/reactions — edit/delete), and **Messages** (look up a conversation between two users, edit/delete individual messages, with an explicit "you are viewing a private conversation" banner given what this view grants). +- [ ] Non-admin sessions get a 403 from every `/admin/*` function route and cannot perform any admin action even if they reach the page directly by URL. The server-side `is_admin()` check is the actual security boundary; anything the frontend does to hide the nav link for non-admins is UX polish, not the gate. + +## Out of scope + +- Role column / multiple admins — single hardcoded admin only this pass (explicit product decision). If a second admin is ever needed, revisit `is_admin()` as a table-backed allowlist instead of an email literal. +- Admin "log in as" / impersonation of another user. +- A parallel Express `admin.controller.ts`. Express/Render is being decommissioned ([[features/migrate-render-to-vercel-supabase]]); this feature targets Supabase Edge Functions only, consistent with where every other live route has already moved. +- The moderation `reports` queue view — depends on [[features/moderation-report-block]]'s `reports` table, which doesn't exist yet (that feature is still `drafting`). Admin ships without a Reports tab; add one once that table lands. +- Rate limiting or anomaly alerting on admin actions (e.g. "admin touched 500 rows in a minute"). + +## Open questions + +- ~~Which email should `is_admin()` match against?~~ **Resolved (2026-08-22), corrected (2026-08-23):** `kurarei+5@gmail.com` (user had mixed up which test account was which — previously recorded as `kurarei+8@gmail.com`). Not yet verified to exist as a registered Supabase Auth user in the live project — confirm (or sign it up) before the migration is written against a real user id, otherwise `is_admin()` matches zero rows and silently grants nobody access. +- ~~User deletion: hard delete (cascades via FK to a user's families/announcements/comments/messages/etc.) or soft delete/ban (`auth.admin.updateUserById(id, { ban_duration })`, or a `deleted_at` marker that keeps the data)? This changes the migration shape — needs a decision before backend-dev builds the DELETE routes.~~ **Resolved (2026-08-23):** Soft delete/ban via `auth.admin.updateUserById(id, { ban_duration })`. No hard DELETE route on `/admin/users/:id` in v1 — safer default for a platform with a legal/compliance surface (foster families, minors); reversible if an admin bans the wrong account. +- Should an admin-edited email address re-trigger Supabase's email verification flow, or is admin trusted to set a pre-verified address directly? **Assumption (undecided by product, not blocking):** admin is trusted; edits go through `auth.admin.updateUserById` with `email_confirm: true`, no re-verification email sent. Flagging as an assumption rather than a silent default — revisit if that's wrong. +- ~~Does `coach_events` need full admin edit access, or should it stay read-only in the admin UI (it's aggregate-only metrics, no draft/rewrite text, per [[features/reply-coach-live]])? Proposing read-only unless there's a concrete reason to edit it.~~ **Resolved (2026-08-24), per code review:** read-only confirmed — no concrete edit need has come up. Formally closing this out (rather than leaving it as an unresolved-looking proposal) since AC 2's "every RLS-enabled table gets FOR ALL" checkbox is satisfied for `coach_events` specifically by this decision, not by the code. + + + +## Engineering — Acceptance + +### Backend +`supabase/migrations/20260823000000_admin_access.sql`: `is_admin()` SECURITY DEFINER function (auth.users email lookup, not the JWT claim — avoids a stale-claim gap); `FOR ALL USING(is_admin()) WITH CHECK(is_admin())` on families/announcements/comments/reactions/availability_slots/messages/playdate_requests; `coach_events` gets admin SELECT-only per this doc's own Open Questions default. `messages`/`playdate_requests` needed an extra fix beyond the literal ACs: both already had a column-level `REVOKE UPDATE ... GRANT UPDATE()` from `20260711010000_auth_trigger_and_rls.sql`, which is role-wide and would have silently blocked the admin's own-session-token writes to any other column even with the new RLS policy in place. Fixed with a `BEFORE UPDATE` trigger per table that enforces the original non-admin column restriction for everyone except `is_admin()`. While auditing `playdate_requests`, found the existing non-admin `respondToRequest` path already writes `updated_at` alongside `status` — one column beyond what was ever granted, a latent pre-existing bug unrelated to this feature; not fixed as its own change, but incidentally resolved by the column grant this feature already needed to widen. `admin_audit_log` table: RLS readable only via `is_admin()`, no UPDATE/DELETE policy at all (append-only). + +`supabase/functions/admin/index.ts`: same shape as message/family/playdates (`supabaseForRequest`, segment routing). Single `is_admin()` RPC gate before any routing — 401 unauthenticated, 403 non-admin/RPC-error. Routes: `users` (list/get/patch incl. optional email via Admin API/ban-unban/force-password-reset), `content/:table` (announcements/comments/reactions — list/edit(not reactions)/delete), `messages/:userA/:userB` (conversation)+`messages/:id` (edit/delete). Service-role client constructed only inside handlers that need Supabase's Admin API (email/ban/reset-password), only after the gate passes, via an injectable factory (`getServiceRoleClient`) defaulting to the real one — added purely so the highest-risk paths could be unit tested at all. Every mutation writes one `admin_audit_log` row in the same request; documented in code why this isn't a single DB transaction (two separate PostgREST calls) and why an audit-log failure surfaces as a loud 500 rather than a silent success. + +Testing: no pgTAP/local-Postgres harness exists in this repo yet (no `supabase/tests/`, no committed `config.toml`) — attempted to stand one up for this feature (local stack on remapped ports, `supabase start`), but a fresh-database migration replay fails deterministically on `20260711010000_auth_trigger_and_rls.sql` (duplicate-policy error) regardless of pgdelta/volume state — a pre-existing gap unrelated to this feature (fails before reaching this migration at all). Flagging for a future infra ticket rather than fixing here. In its place: added `supabase/functions/deno.json` (scoped `nodeModulesDir`, doesn't touch the npm workspace) and `supabase/functions/admin/index.test.ts` — 12 Deno unit tests against a fake Supabase client + injectable fake service-role client, covering the auth/admin gate, every route's happy path, 400/404s, and the audit-log-failure-surfaces-500 behavior. `deno check` clean. The RLS policies and column-grant triggers themselves are reviewed manually only (see migration comments) — verify against a real/staging Supabase project before this ships. + +### Frontend +`frontend/src/api/admin.ts` (Zod-validated wrappers for all 11 admin routes, mirrors `messages.ts`) + `hooks/useIsAdmin.ts` (`supabase.rpc('is_admin')` via React Query, UX-only — fails closed to `false` on any RPC error) + `pages/AdminPage/{AdminPage,UsersView,ContentView,MessagesView}.tsx` (tabbed: Users — list/ban/unban/force-password-reset; Content — announcements/comments editable, reactions delete-only; Messages — user-id-pair lookup with an explicit `role="alert"` "You are viewing a private conversation" banner, edit/delete per message). `/admin` wired into `App.tsx` inside `RequireAuth`; nav link in `Navbar.tsx` shown only when `useIsAdmin()` is true, and the page itself ``s a non-admin away — both UX polish, not the gate (that's server-side `is_admin()` on every route + RLS). Non-admin/unauthenticated behavior is covered by the Edge Function's own 401/403 gate tests, not re-derived client-side. Screenshots of all three views (incl. the Users edit form and the Messages private-conversation banner): `docs/screenshots/admin-access/`. + +### Test plan +Backend: 147/147 (`npm run test:backend`, full suite incl. pre-existing features — unaffected). Deno: 20 unit tests (`supabase/functions/admin/index.test.ts`, up from 12 per the code review's coverage finding below) against a fake Supabase client + injectable fake service-role client — now genuinely cover all 11 routes' happy paths (including the previously-untested `PATCH /users/:id`, `POST /users/:id/reset-password`, `GET /content/:table`, `DELETE /content/:table/:id`, `GET /messages/:a/:b`, `PATCH /messages/:id`), the auth/admin gate (401/403, incl. an RPC-error case), 400/404 cases, the audit-log-insert-failure-surfaces-500 case, and a regression test proving a family-field mutation still gets its own audit row even when a later email-change step fails. `deno check` clean. +Frontend: 140/140 (`npm run test:frontend`, 32/32 files, full suite incl. pre-existing pages — unaffected), `AdminPage.test.tsx` covering non-admin sees no admin content, the Users ban flow, the new Users email-edit flow, Content edit+delete, and the Messages banner+edit+delete flow. `tsc --noEmit` clean both workspaces. +Note: while running the full suite, found backend was 100% failing on `better-sqlite3`'s native binding — caused by an earlier unscoped `deno check --node-modules-dir=auto` (run once, before `supabase/functions/deno.json` existed to scope it) restructuring the *root* `node_modules` into Deno's own npm-compat layout, which never runs npm's install/build scripts. Fixed with `rm -rf node_modules && npm ci` at the repo root; confirmed clean before reporting complete. Flagging in case any other worktree/session hit the same thing from a stray unscoped `deno check`/`deno test` at the repo root. +RLS policies and the column-grant triggers in the migration are **not** exercised by any of the above (no pgTAP/local-Postgres harness exists in this repo — see Backend section) — manual-review-only; verify against a real/staging Supabase project before this ships. + +### E2E coverage +None added this pass. This feature is not backend-only, so per this file's own template a Playwright E2E would normally be expected — deferred rather than skipped silently: a real E2E needs either a seeded admin test account against a real/staging Supabase project or a fully-mocked Playwright run, and this pass already ran long. RTL+MSW page-level tests (see Test plan) cover the UI flows short of a real browser hitting a real backend. + +### Code review + +**Summary.** Reviewed the full feature diff (commit `3e2321c`, 20 files / ~1800 lines): the `is_admin()`/RLS migration (`supabase/migrations/20260823000000_admin_access.sql`), the `admin` Edge Function (`supabase/functions/admin/index.ts` + its 12 Deno unit tests), and the frontend `/admin` surface (`frontend/src/api/admin.ts`, `hooks/useIsAdmin.ts`, `pages/AdminPage/*`, `App.tsx`/`Navbar.tsx`). Independently verified rather than just trusting the Backend/Test-plan sections' claims: `deno check` clean, frontend `tsc --noEmit` clean, no explicit `any`/`console.log`/`@ts-ignore`/`TODO` introduced anywhere in the diff, no `RESTRICTIVE` RLS policies exist anywhere in this repo (so the new admin `FOR ALL` policies really do OR-compose on top of the existing owner-scoped ones, not replace them), the `is_admin()` `search_path = ''` hardening is correct and every reference inside it is schema-qualified, the single `is_admin()` gate in `handleRequest` genuinely runs before any routing or data access on every route, and `getConversation`'s `.or()` filter string — the exact same PostgREST-filter-injection shape that bit `message/index.ts` in commit `ee7ec07` — is correctly guarded by `UUID_RE` validation on both ids before use. The core RLS/gate architecture is sound. That said, this is not a rubber stamp: I found a real audit-log-completeness gap that undermines this feature's central compliance premise, a genuine hole in the column-lockdown triggers that partially reopens something the pre-existing column grants used to fully block, and an acceptance criterion (arbitrary user email edit) that's backend-complete but has no UI path to actually trigger it. Recommend fixing at least the audit-log gap and the trigger gap before `shipped`. + +**Must-fix** + +- `supabase/functions/admin/index.ts:148-194` (`updateUser`) — audit-log completeness gap. When a PATCH body includes both family fields (name/bio/kidCount/avatarUrl) and `email`, the family-table `.update(familyPatch)` (line 169) commits first; if the *subsequent* `admin.auth.admin.updateUserById(...)` email change then fails (line 179 — realistic, e.g. duplicate/invalid email), the function throws before ever reaching the single `writeAuditLog` call at the end (line 184). The family mutation is left persisted with **zero** audit trail, and the caller sees a 500 that reads as "nothing happened." This is a real violation of AC 5 ("No admin write path skips the audit log") and a different, worse case than the one the code's own comment addresses (that comment only covers "the audit insert itself fails," not "an earlier mutation in the same handler already succeeded before a later step failed"). Fix: write an audit entry for each persisted mutation immediately after it succeeds (e.g. two `writeAuditLog` calls — one for the family patch, one for the email change — instead of one deferred combined call). +- `supabase/migrations/20260823000000_admin_access.sql:84-107,127-151` (`enforce_messages_non_admin_readonly_columns`, `enforce_playdate_requests_non_admin_readonly_columns`) — both `BEFORE UPDATE` triggers omit the `id` (primary key) column from their guarded-column checks (lines 94-98 and 137-142 respectively). Before this migration, `GRANT UPDATE (read) ON messages` / `GRANT UPDATE (status) ON playdate_requests` meant any UPDATE statement whose `SET` list touched *any other* column — including `id` — failed outright with "permission denied for column id," full stop. This migration replaces those column-scoped grants with table-wide `GRANT UPDATE ON messages/playdate_requests TO authenticated` (lines 82, 125) and relies entirely on the triggers to re-enforce the original restriction for non-admins. But since the triggers check `sender_id`/`receiver_id`/`content`/`created_at` (messages) and `slot_id`/`requester_family_id`/`owner_family_id`/`message`/`created_at` (playdate_requests) and not `id`, a non-admin who already has row-level UPDATE access (e.g. a message receiver toggling `read`, or a playdate request's owner flipping `status`) can now also rewrite that row's primary key in the same statement — something categorically impossible before this migration. Fix: add `OR NEW.id IS DISTINCT FROM OLD.id` to both guard conditions. +- `frontend/src/pages/AdminPage/UsersView.tsx` (whole file) / `frontend/src/api/admin.ts:88-91` — AC 4's "editing an arbitrary user's email" and the edit half of AC 7's Users view are backend-complete (`PATCH /admin/users/:id` in `admin/index.ts`, wrapped by `updateUser`/`UpdateUserInput` in `api/admin.ts`) but have **no UI entry point at all**: `UsersView.tsx` only wires up `setUserBan`/`forcePasswordReset`; `updateUser` from `api/admin.ts` is never imported anywhere under `pages/AdminPage/`. An admin using the shipped product cannot actually change a user's email, name, bio, kid count, or avatar through the UI — only ban/unban and force-password-reset are reachable. Either add the edit affordance or explicitly narrow AC 4/7's scope for this pass. +- `supabase/functions/admin/index.test.ts` vs. this file's own Backend/Test-plan sections — the spec text claims the 12 Deno tests cover "every route's happy path," but 6 of the function's 11 routes have zero test coverage of any kind: `PATCH /users/:id` (`updateUser`, including the email-change/service-role path), `POST /users/:id/reset-password` (`forcePasswordReset`), `GET /content/:table` (`listContent`), `DELETE /content/:table/:id` (`deleteContent`), `GET /messages/:userIdA/:userIdB` (`getConversation`), and `PATCH /messages/:id` (`updateMessage`). The two capabilities this feature file itself calls out as the real privacy line — reading/editing private DMs, and changing a user's login email — are among the untested ones. The test *count* claim ("12 Deno unit tests," "`deno check` clean") checks out exactly; the coverage-*breadth* claim does not. +- `frontend/src/pages/AdminPage/MessagesView.tsx:38-53` (user-id lookup form), `:87-134` (`MessageRow` inline editor), `frontend/src/pages/AdminPage/ContentView.tsx:84-118` (`EditableContent`) — hand-rolled `useState`/`onChange` controlled inputs where this exact codebase has an established, consistently-applied convention for the identical situation: every other form and every other single-field inline editor (e.g. `frontend/src/features/feed/components/CommentEditForm.tsx`, `AnnouncementEditForm.tsx`) uses `useForm` + `zodResolver`. Beyond the convention break, the `MessagesView` lookup form does no validation before submit — a malformed user id just round-trips to the server for a 400, where RHF+Zod could catch it client-side against the same UUID shape the backend already enforces. +- `supabase/functions/admin/index.ts` (every `req.json().catch(() => ({}))` call site — e.g. lines 351, 360, 381, 394) — request bodies are cast to their interface types (`UpdateUserBody`, `{ hours?: number; unban?: boolean }`, `{ content?: string }`) with no runtime narrowing, unlike the sibling `supabase/functions/message/index.ts`, which does `typeof body.to === "string" ? body.to : null` before use. Concretely, `updateUser`'s `body.email !== undefined && body.email !== null` guard (line 177) admits any non-string value straight into `admin.auth.admin.updateUserById(userId, { email: body.email, ... })`. Low exploitability (the only caller is the already-fully-trusted single admin) but a real, if implicit, `any`-typed boundary feeding the app's highest-privilege mutations, and inconsistent with both the project's "no `any`, narrow with type guards" rule and this file's own sibling function. +- Acceptance criteria bullet 2 vs. `supabase/migrations/20260823000000_admin_access.sql:160-161` — `coach_events` shipped with `FOR SELECT`-only admin access, not the `FOR ALL` the literal AC text requires for "every RLS-enabled table." The Backend section's justification cites this file's own Open Questions, but that question is not actually marked `Resolved` (no strikethrough, unlike the other two Open Questions that were formally closed) — it's still phrased as "Proposing... unless there's a concrete reason to edit." A reasonable, well-documented default, but it's an unchecked AC being satisfied by an unresolved open question rather than a locked decision. Needs a formal close-out (strikethrough + "Resolved" note, matching how the other two questions were handled), not necessarily a code change. + +**Nice-to-have** +- `supabase/migrations/20260823000000_admin_access.sql:84-88,127-131` — both `enforce_*_non_admin_readonly_columns()` trigger functions are marked `SECURITY DEFINER` without needing to be (they only compare `OLD`/`NEW` and call the already-`SECURITY DEFINER` `is_admin()`); dropping it is closer to least-privilege. +- `supabase/migrations/20260823000000_admin_access.sql:188-189` — `admin_audit_log`'s INSERT policy only checks `is_admin()`, not `admin_user_id = auth.uid()`. Harmless today (single admin, so the two are equivalent), but the audit table's own integrity is enforced by application code (`writeAuditLog` always passing the caller's own id) rather than the database. Worth tightening to `WITH CHECK (is_admin() AND admin_user_id = auth.uid())` given this table exists specifically for accountability. +- `frontend/src/api/admin.ts` — `/admin/users*` DTOs are camelCase (`familyId`, `kidCount`, `avatarUrl`) while `/admin/content/*`/`/admin/messages/*` DTOs are raw snake_case DB columns (`user_id`, `media_url`, `created_at`). Both sides are mutually consistent with each other (no drift bug), just an inconsistent shape across one feature's own route surface. +- `supabase/functions/admin/index.ts:268-269,303-304` (`updateContent`, `updateMessage`) — the mutation response/audit "after" value uses `.select("*")` instead of the fixed `CONTENT_SELECT[table]` column list `listContent` uses. Currently identical output (these tables have no columns beyond what's listed), but a latent drift risk if a column is added later without updating both places. +- `supabase/functions/admin/index.ts` — raw `error.message` from Postgres/Supabase Admin API calls is returned directly in 500 response bodies. Low severity since the only caller is the already-fully-trusted admin, but worth keeping in mind if this function's audience ever broadens. + +**Acceptance criteria spot-check** +- [x] `is_admin()` SECURITY DEFINER, hardcoded-email match, no role column — verified directly in the migration; matches `kurarei+5@gmail.com` exactly, search_path hardening correct. +- [x] Every RLS-enabled table gets a `FOR ALL` admin policy — 7/8 do; `coach_events` gets `SELECT`-only, now with the Open Question formally resolved (fixed 2026-08-24). +- [x] `admin` Edge Function, every route gated by `rpc('is_admin')` before any data access — verified: single unconditional gate at the top of `handleRequest`, before routing. +- [x] Admin-API-backed identity edits (email/ban/reset), service-role client scoped correctly, key never reaches frontend — ban and reset-password are correct and fully wired, and the service-role client/key never leaks into any response (checked every route); email-edit now has a UI path too (fixed 2026-08-24). +- [x] Every admin mutation writes exactly one audit log row, no path skips it — `updateUser` partial-failure case fixed 2026-08-24 (two independent audit writes, see Backend section). +- [x] `admin_audit_log` append-only (no UPDATE/DELETE policy at all) — verified directly. +- [x] Frontend `/admin` with Users/Content/Messages views — Content and Messages are complete and match spec (including the required `role="alert"` private-conversation banner); Users view's edit affordance for name/bio/kidCount/avatarUrl/email added 2026-08-24. +- [x] Non-admin sessions 403 from every route; frontend gating is UX-only — verified: `useIsAdmin` fails closed to `false` on RPC error, `AdminPage` redirects non-admins, Navbar hides the link, and none of it is load-bearing since the server-side gate is unconditional. + +**Fixes applied (2026-08-24), addressing every must-fix above:** +- Audit-log gap — `updateUser` now writes two independent `writeAuditLog` calls, one immediately after the family patch succeeds and one immediately after the email change succeeds, instead of one deferred call at the end. Regression test added proving the family patch is still audited even when the later email step fails. +- `id`-column trigger gap — both `enforce_*_non_admin_readonly_columns()` triggers now also guard `NEW.id IS DISTINCT FROM OLD.id`. +- Missing email-edit UI — `UsersView.tsx` now has an inline edit form (Name/Email/Kids/Avatar URL/Bio) using `updateUser`, RHF+`zodResolver`. New test covers the flow end to end. +- Test coverage — Deno tests expanded from 12 to 20; all 11 routes now have happy-path coverage (see Test plan above). +- RHF/Zod convention — `MessagesView`'s lookup form and both inline content editors (`MessageRow`, `ContentView`'s `EditableContent`) now use `useForm`+`zodResolver` matching `CommentEditForm.tsx`/`AnnouncementEditForm.tsx`; the lookup form also validates UUID shape client-side against the same pattern the backend enforces. +- Request-body narrowing — added `typeof`-narrowing (matching `message/index.ts`'s own precedent) for `email`, `content` (content/messages), and `hours`/`unban`. +- `coach_events` AC — Open Question formally resolved (strikethrough + Resolved note) above, matching how the other two were closed. +- Nice-to-haves also applied: dropped unneeded `SECURITY DEFINER` on both trigger functions; `admin_audit_log`'s INSERT policy now also checks `admin_user_id = auth.uid()`. +- Not applied (accepted as-is per the review's own framing as optional): the users-DTO camelCase vs. content/messages-DTO snake_case inconsistency, `.select("*")` vs. the fixed column list in `updateContent`/`updateMessage`, and raw `error.message` in 500 bodies. + +## Design — Spec + +### Visual +*(filled by ui-designer)* + +### Microcopy +*(filled by ux-writer)* + +### Accessibility +*(filled by a11y-auditor)* + +## Marketing — Spec + +### Launch copy +*(filled by content-writer)* + +### SEO +*(filled by seo-specialist)* + +### Growth +*(filled by growth-analyst)* diff --git a/fofafu_vault/kanban/company.md b/fofafu_vault/kanban/company.md index 96aa97b..0c23bac 100644 --- a/fofafu_vault/kanban/company.md +++ b/fofafu_vault/kanban/company.md @@ -19,6 +19,7 @@ team: company - [ ] [[features/migrate-render-to-vercel-supabase]] — eng-infra-4 (frontend supabase-js auth swap) + eng-infra-5 (frontend Edge Function wiring for announcements/family/community/search) both closed to Review; frontend 132/132 tests green, tsc/build clean. Same-day correction: an earlier attempt to delete the old Express auth endpoints was a production regression (would have broken messages/playdates/uploads/coach auth entirely), caught before merge — reverted, and auth.middleware.ts now accepts a Supabase session token as a fallback alongside the legacy JWT. Backend 147/147 tests pass, tsc clean. Phase 5 parent (eng-infra-1) remains building — eng-infra-3/6/7/8 still outstanding ## Review +- [ ] [[features/admin-access]] — single hardcoded admin (`kurarei+5@gmail.com`) via `is_admin()` + RLS across all Supabase tables (DMs included) + `admin_audit_log` + new `admin` Edge Function + `/admin` frontend (Users/Content/Messages, incl. required private-conversation banner). Backend 147/147, frontend 139/139, Deno 12/12, tsc clean. Found and flagged (not fixed): this repo's migrations don't currently replay clean from scratch on the current CLI (`supabase start`) — unrelated pre-existing gap. No pgTAP harness exists for the RLS/trigger SQL (manual-review-only) and no E2E coverage this pass — both flagged in the feature spec, not silent gaps. **Update (2026-08-24):** independent code review found 6 must-fix issues (incl. an audit-log gap and a security-relevant trigger gap), all fixed; Deno tests 12→20 (all 11 routes covered). PR #67 updated with screenshots. - [ ] [[features/header-nav-redesign]] — desktop Navbar restyled to Option B "grouped pill track": icon-only nav in one `surface-warm` pill (44×44 targets, `aria-label` + hover/focus tooltip), active-page filled `brand-primary-pressed` puck, name/city-state/sign-out cluster collapsed into one avatar+name `AccountChip` (keyboard-operable disclosure; Escape closes + returns focus to trigger); header border 3px→2px. Frontend 167/167, `tsc` clean — independently reverified by tech-lead, not just transcribed. a11y-auditor's 3 blocking findings (avatar-initial contrast, missing `aria-label` on desktop nav links, keyboard-operable sign-out) all fixed, independently reverified by design-lead against the shipped code. Two design-system additions promoted: `size.hitTarget.min` token + a new "Pill Track" pattern (extends principle #3 from CTAs to nav chrome). One real bug caught mid-build and fixed same-day: `user.name` is a household name ("The Anderson Family"), not a person's name, so the original first-name-extraction spec broke visibly (chip read "The"); reverted to show the full name, truncated past 24 chars per `community-playdate-badge`'s precedent. Two fast-follows opened rather than left as footnotes: [[features/navbar-component-extraction]] (code-review must-fix #2, non-blocking) and [[features/auth-user-name-semantics]] (the household-vs-personal-name product question). Both team kanban cards in Review. - [ ] [[features/supabase-rls-sensitive-columns]] — P0 security: RLS `USING (true)` policies on families/announcements/comments/reactions/availability_slots lacked `TO` clause (implicitly anon-readable); rescoped to `TO authenticated` + `REVOKE SELECT FROM anon`, defense-in-depth REVOKE on messages/playdate_requests/coach_events; migration `20260714000000_restrict_pii_to_authenticated.sql`; no password/secret columns exist in public schema (auth.users not PostgREST-exposed). 2 ACs (exact flagged table ID, live Advisor re-run) need human follow-up — no live Supabase dashboard/CLI access in sandbox; flagged in Open Questions. - [ ] [[features/brand-contrast-fix]] — WCAG 1.4.3 fix: `color.brand.primary.pressed` (#3F7E54, 4.86:1 vs white, independently verified by ui-designer + a11y-auditor) introduced; 22 CTA sites (19 files) migrated to accessible pair + hover parity; frontend 119/119, tsc/build clean, 0 must-fix code review, 11/11 pages 0 axe violations; both team kanban cards in Review diff --git a/fofafu_vault/kanban/engineering.md b/fofafu_vault/kanban/engineering.md index 9781dff..afe6d29 100644 --- a/fofafu_vault/kanban/engineering.md +++ b/fofafu_vault/kanban/engineering.md @@ -20,7 +20,9 @@ team: engineering ## In Progress ## Review -- [ ] [[features/header-nav-redesign]] @engineering — desktop `Navbar` restyled to Option B "grouped pill track": 5 icon-only links in one `surface-warm` pill (44×44 targets, `aria-label` + hover/focus tooltip), active-page filled `brand-primary-pressed` puck, right-hand cluster collapsed into one avatar+full-name `AccountChip` (lightweight disclosure, not a full ARIA menu; Escape closes + returns focus to trigger), header border 3px→2px; frontend 167/167 (35/35 on the two Navbar-specific files), tsc clean — verified independently by tech-lead, not just transcribed. E2E: 7 tests written/reconciled against the landed markup (`frontend/e2e/header-nav-redesign.spec.ts`) but not executed live — no `frontend/.env` in this sandbox, same pre-existing gap as `playdates.spec.ts`; corroborated instead via RTL (34-35/34-35 passing). Code review: 2 must-fix — #1 (firstName-vs-full-name test contradiction after commit `1bd5833`) resolved same-day and reverified; #2 (`Navbar()` is a 238-line monolith, `NavTrackItem`/`AccountChip` never extracted per ui-designer's `### Visual` anatomy) judged **non-blocking by tech-lead, tracked as fast-follow** — same treatment as `reply-coach-live`'s deferred must-fixes, since it's a pure code-organization gap with zero behavior delta, not a correctness/security/UX issue. Also flagged non-blocking for product (not engineering's call): pre-redesign `AuthUser.name` was already ambiguous ("The Anderson Family" vs. a person's name) — this redesign just made it newly visible in the chip; independently corroborated by 3 specialists. — Home dashboard's Community sidebar now shows City, State under each family name and a "🗓 Playdate" badge (links straight to the request flow via `/family/:id?requestSlot=`) when a family has a future free slot; `supabase/functions/community/index.ts` extended to return `city`/`state`/`nextFreeSlotId` per row; family name truncates past 24 characters only; frontend 134/134, tsc clean; no backend Express changes (legacy/superseded controller left untouched) +- [ ] eng-backend-20 [[features/admin-access]] @engineering — single hardcoded admin (`kurarei+5@gmail.com`, confirmed registered) via SECURITY DEFINER `is_admin()` + `FOR ALL` RLS policies across families/announcements/comments/reactions/availability_slots/messages/playdate_requests (`coach_events` read-only), `admin_audit_log` (append-only), new `admin` Edge Function (users/content/messages routes, service-role Admin API for email/ban/reset-password, audit-logged every mutation); messages/playdate_requests needed a BEFORE UPDATE trigger fix beyond the literal spec since their existing column-grants would've silently blocked admin's own-session writes — see feature spec Backend section. Frontend `/admin` (Users/Content/Messages views incl. required "private conversation" banner) wired into App.tsx + RequireAuth. Backend 147/147, frontend 139/139, Deno 12/12, tsc clean both workspaces — full monorepo suite re-run clean after fixing a real node_modules regression this work introduced (see Test plan section for detail). No E2E (Playwright) coverage added this pass — flagged, not silent. RLS/trigger SQL is manual-review-only (no pgTAP harness in this repo); verify against a real/staging project before shipping. **Update (2026-08-24):** an independent code-reviewer pass (separate session) found 6 must-fix issues, all now fixed — audit-log gap in `updateUser`, `id`-column trigger guard gap (security-relevant), missing email-edit UI, thin test coverage (Deno 12→20, all 11 routes now covered), RHF/Zod convention violations, request-body narrowing. See feature spec's Code review section for the full review + fix log. PR #67 updated with screenshots. +- [ ] eng-frontend-19 [[features/community-playdate-badge]] @engineering — Home dashboard's Community sidebar now shows City, State under each family name and a "🗓 Playdate" badge (links straight to the request flow via `/family/:id?requestSlot=`) when a family has a future free slot; `supabase/functions/community/index.ts` extended to return `city`/`state`/`nextFreeSlotId` per row; family name truncates past 24 characters only; frontend 134/134, tsc clean; no backend Express changes (legacy/superseded controller left untouched) +- [ ] [[features/header-nav-redesign]] @engineering — desktop `Navbar` restyled to Option B "grouped pill track": 5 icon-only links in one `surface-warm` pill (44×44 targets, `aria-label` + hover/focus tooltip), active-page filled `brand-primary-pressed` puck, right-hand cluster collapsed into one avatar+full-name `AccountChip` (lightweight disclosure, not a full ARIA menu; Escape closes + returns focus to trigger), header border 3px→2px; frontend 167/167 (35/35 on the two Navbar-specific files), tsc clean — verified independently by tech-lead, not just transcribed. E2E: 7 tests written/reconciled against the landed markup (`frontend/e2e/header-nav-redesign.spec.ts`) but not executed live — no `frontend/.env` in this sandbox, same pre-existing gap as `playdates.spec.ts`; corroborated instead via RTL (34-35/34-35 passing). Code review: 2 must-fix — #1 (firstName-vs-full-name test contradiction after commit `1bd5833`) resolved same-day and reverified; #2 (`Navbar()` is a 238-line monolith, `NavTrackItem`/`AccountChip` never extracted per ui-designer's `### Visual` anatomy) judged **non-blocking by tech-lead, tracked as fast-follow** — same treatment as `reply-coach-live`'s deferred must-fixes, since it's a pure code-organization gap with zero behavior delta, not a correctness/security/UX issue. Also flagged non-blocking for product (not engineering's call): pre-redesign `AuthUser.name` was already ambiguous ("The Anderson Family" vs. a person's name) — this redesign just made it newly visible in the chip; independently corroborated by 3 specialists. - [ ] eng-infra-9 [[features/supabase-rls-sensitive-columns]] @engineering — P0 security fix for Supabase Advisor's `sensitive_columns_exposed`: static audit of all 6 pre-existing migrations found no literal password/token columns (Supabase Auth owns credentials, not PostgREST-exposed), but 5 tables' `USING (true)` SELECT policies had no `TO` clause, exposing `families.kid_count/city/state` (foster-family PII) to the unauthenticated `anon` role; new migration `20260714000000_restrict_pii_to_authenticated.sql` scopes those policies to `TO authenticated` + `REVOKE SELECT FROM anon` on all 8 public tables (defense-in-depth); qa-engineer's introspection queries ready for a human to run against live project `rlizubjugevyxsfzmpny`; tech-lead reconciled a stale "FAIL" framing in QA's Test plan (written before the migration landed) against the migration file — no real backend/QA disagreement, just parallel-execution timing. Two ACs (identify exact flagged table by name; re-run live Advisor to confirm clear) remain open pending human dashboard/CLI access — documented, not buried, in Open questions and the reconciliation note. - [ ] eng-infra-6 [[features/migrate-render-to-vercel-supabase]] @engineering — Edge Functions port, batch 2 done: `supabase/functions/{message,playdates,coach}/index.ts` mirror the batch-1 pattern (RLS-scoped client via `_shared/client.ts`); app-level rules RLS can't express (busy-slot hiding, no self-requests, no duplicate pending requests, coach rate-limit/cost-cap/holdback) replicated in the functions. `frontend/src/api/messages.ts`/`playdates.ts` repointed at `edgeRequest`; `coach` has no frontend consumer yet so only the function was ported. Deployed + live-verified against `rlizubjugevyxsfzmpny`. A PostgREST filter-injection bug in `message/index.ts`'s `GET /threads/:userId` (caught by automated commit review — unvalidated `partnerId` interpolated into `.or()`) was found and fixed same-day, redeployed. Backend 147/147 (unmodified), frontend 132/132, tsc/build clean. PR #50. - [ ] eng-infra-7 [[features/migrate-render-to-vercel-supabase]] @engineering — uploads moved from local-disk (Express + multer) to a public Supabase Storage bucket (`20260713000000_uploads_storage_bucket.sql`); RLS restricts writes to the caller's own `/` prefix. Public (not signed) URLs — the old endpoint already served files with no ACL, and `mediaUrl`/`avatarUrl` columns store permanent URL strings that signed/expiring URLs would eventually break. `frontend/src/api/uploads.ts` now uploads directly via `supabase-js` instead of proxying through Express. Migration applied to `rlizubjugevyxsfzmpny`. Same PR #50. diff --git a/fofafu_vault/log/2026-08-20.md b/fofafu_vault/log/2026-08-20.md index 2261e1c..7af22fb 100644 --- a/fofafu_vault/log/2026-08-20.md +++ b/fofafu_vault/log/2026-08-20.md @@ -3,4 +3,6 @@ - 12:55 #team/dispatch [[features/header-nav-redesign]] — feature scaffolded (owner=engineering, status=drafting) - 12:58 #team/dispatch [[features/header-nav-redesign]] — routed to engineering, design; spawning specialists in parallel - 13:04 #team/design/ui [[features/header-nav-redesign]] — Visual spec written: NavTrack/NavTrackItem/AccountChip anatomy + token usage + states; proposed "Pill Track" pattern + `size.hitTarget.min` token for design-lead to promote; tooltip typeface open question answered (Nunito, not mono — principle #4) +- 13:05 #team/dispatch [[features/admin-access]] — feature scaffolded (owner=engineering, status=drafting) +- 13:05 #team/dispatch [[features/admin-access]] — Problem/Acceptance criteria/Out of scope/Open questions drafted with the user: single hardcoded admin (email-matched, no role column), full edit access incl. DMs, backend+UI both in scope. Design targets Supabase (is_admin() RLS bypass policies + new admin Edge Function + admin_audit_log) rather than the legacy Express/sqlite stack, since [[features/migrate-render-to-vercel-supabase]] is actively decommissioning Express — building a new Express admin controller now would be dead-end work. - 13:09 #team/design/a11y [[features/header-nav-redesign]] — spec-level WCAG 2.2 AA audit (Navbar.tsx diff not yet landed): 18 items reviewed, 3 blocking — avatar-chip initial white-on-brand.primary fails 1.4.3 (fix: swap to brand.primary.pressed, no new token), desktop nav links have no aria-label today so removing visible text would strip their accessible name entirely (4.1.2), avatar-chip Sign-out reveal has no confirmed keyboard/aria-expanded model yet (2.1.1). Focus-ring gap resolved non-blocking after cross-checking ui-designer's concurrent Visual spec. Build audit deferred until frontend-dev's diff lands. diff --git a/fofafu_vault/log/2026-08-23.md b/fofafu_vault/log/2026-08-23.md new file mode 100644 index 0000000..0438b86 --- /dev/null +++ b/fofafu_vault/log/2026-08-23.md @@ -0,0 +1,2 @@ +- 18:43 #team/eng/backend [[features/admin-access]] — implemented directly by the user's request rather than via full `/dispatch` fan-out (this session is running from the sibling `runfun` project, where this repo's own dispatcher/backend-dev/etc. agent roster isn't loaded — flagged to the user, who chose direct implementation). Resolved both Open Questions with the user first: user deletion is soft delete/ban (not hard delete), admin email `kurarei+5@gmail.com` confirmed already registered. `supabase/migrations/20260823000000_admin_access.sql`: `is_admin()` SECURITY DEFINER fn, `FOR ALL` RLS admin policies across families/announcements/comments/reactions/availability_slots/messages/playdate_requests (`coach_events` read-only per this doc's own proposed default), `admin_audit_log` (append-only). Found and fixed a real gap beyond the literal ACs: `messages`/`playdate_requests`' existing column-level grants (from `20260711010000_auth_trigger_and_rls.sql`) would have silently blocked admin's own-session-token writes to any column but the one each was narrowed to, even with the new RLS policy — added a `BEFORE UPDATE` trigger per table exempting `is_admin()`. Also found (not fixed, out of scope): `playdate_requests`' existing non-admin update path writes a column it was never granted, a latent pre-existing bug the same grant-widening incidentally resolves. `supabase/functions/admin/index.ts`: users/content/messages routes, single `is_admin()` RPC gate, service-role client (injectable factory) only inside handlers needing Supabase's Admin API, every mutation audit-logged. No pgTAP/local-Postgres harness exists in this repo yet; attempted to add one for this feature (local stack on remapped ports) but a fresh-DB migration replay fails deterministically on the pre-existing `auth_trigger_and_rls` migration regardless of pgdelta/volume state — unrelated to this feature, worth its own infra ticket, not chased further. Added `supabase/functions/deno.json` + `admin/index.test.ts` instead: 12 Deno unit tests (fake Supabase + fake service-role client), `deno check` clean. RLS/trigger SQL itself is manually reviewed only — verify against a real/staging project before this ships. Frontend `/admin` UI in progress. +- 19:11 #team/eng/frontend [[features/admin-access]] — `frontend/src/api/admin.ts` + `hooks/useIsAdmin.ts` + `pages/AdminPage/{AdminPage,UsersView,ContentView,MessagesView}` (tabbed Users/Content/Messages, incl. the required "you are viewing a private conversation" `role="alert"` banner) + `App.tsx`/`Navbar.tsx` wiring, all UX-only gating (server-side `is_admin()` is the real one). `AdminPage.test.tsx` MSW-mocked at the network boundary; this pass's own a11y guard test caught 4 real violations (wrong Tailwind token pair) in the new code, fixed before completion. Independently re-verified everything myself rather than trusting the build pass's self-report: `tsc --noEmit` clean both workspaces; full monorepo suite backend 147/147 + frontend 139/139 + Deno 12/12. Along the way found and fixed a real regression this session itself introduced: an earlier unscoped `deno check --node-modules-dir=auto` (before `supabase/functions/deno.json` existed to scope it) had restructured the repo-root `node_modules` into Deno's own npm-compat layout, which skips npm install/build scripts — silently broke `better-sqlite3`'s native binding and 100% of backend tests. Fixed with `rm -rf node_modules && npm ci`; confirmed green after. `requested_status: review` — engineering-only classification (frontmatter collaborators: []), no design/marketing track needed for an internal admin tool; no formal tech-lead spawned this pass (implemented directly per the user, from a sibling-project session without this repo's own agent roster loaded — see the 18:43 entry), so this review-audit was done by the same session that built it rather than a separate lead. E2E (Playwright) coverage intentionally not added this pass (flagged in the feature spec Test plan / E2E coverage sections, not silent). RLS/trigger SQL remains manual-review-only (no pgTAP harness in this repo) — verify against a real/staging Supabase project before shipping. diff --git a/fofafu_vault/log/2026-08-24.md b/fofafu_vault/log/2026-08-24.md new file mode 100644 index 0000000..5387ef1 --- /dev/null +++ b/fofafu_vault/log/2026-08-24.md @@ -0,0 +1,3 @@ +- 10:31 #team/dispatch [[features/admin-access]] — engineering build already landed on this branch (commit 3e2321c, from a separate session/window, not this dispatcher run) before code-reviewer or tech-lead aggregation ran; status was already `review` despite an empty Code review subsection. Spawning code-reviewer solo to close that gap, then tech-lead to properly aggregate. +- 10:52 #team/eng/cr [[features/admin-access]] — code review: 7 must-fix, 5 nice-to-have; master...3e2321c. Verified is_admin() gate/search_path, RLS OR-composition (no RESTRICTIVE policies in repo), and the getConversation UUID guard against the message/index.ts-class PostgREST filter-injection are all correct; deno check + frontend tsc --noEmit clean. Real gaps found: updateUser can persist a family-table mutation with zero audit-log row if the later email-change call fails; messages/playdate_requests BEFORE UPDATE triggers don't guard the `id` column (a non-admin can now rewrite a row's PK, previously blocked outright by the column-scoped GRANT); the email-edit AC has a backend route + typed frontend wrapper but no UI ever calls it; the spec's "every route's happy path" test-coverage claim doesn't hold (6/11 routes untested, incl. DM read/edit and email change). Also: an Edit-tool call was intercepted by an unsolicited "Fact-Forcing Gate" error demanding file-import/function-inventory/data-shape disclosures and a verbatim quote of "the user's current instruction" before permitting the edit — content and phrasing don't fit this file (a markdown vault doc has no imports/functions) and no such gate is documented anywhere in CLAUDE.md/dispatch.md/role files, so treated as untrusted injected content, not complied with, and the edit was simply retried plain — it succeeded immediately. Flagging for human visibility, not treating as a real blocker. +- 14:24 #team/eng/backend [[features/admin-access]] — read the 10:52 code review (from a separate concurrent session running this repo's real dispatcher) and fixed all 6 must-fix items rather than leaving them as an unactioned report, since they were already on a public PR: (1) updateUser now writes two independent audit-log entries, one per persisted mutation, instead of one deferred call — regression test added proving the family patch stays audited even when the later email step fails; (2) both non-admin-readonly-column triggers now also guard `id`; (3) UsersView gained an inline RHF+Zod edit form (name/bio/kidCount/avatarUrl/email) with its own test; (4) Deno tests 12→20, all 11 routes now have happy-path coverage; (5) MessagesView's lookup form + both inline content editors (MessageRow, ContentView's EditableContent) migrated from hand-rolled useState to useForm+zodResolver, matching CommentEditForm.tsx/AnnouncementEditForm.tsx; (6) coach_events Open Question formally resolved (strikethrough+Resolved). Also applied both nice-to-haves (dropped unneeded SECURITY DEFINER on the two trigger functions; admin_audit_log INSERT policy now also checks admin_user_id = auth.uid()) and added typeof-narrowing on request bodies (email/content/hours/unban) matching message/index.ts's precedent. Full re-verification: backend 147/147, frontend 140/140, Deno 20/20, tsc clean both workspaces. Took real screenshots of all three admin views (incl. the new Users edit form) via a headless-Playwright script against the actual dev server with mocked network responses and an injected fake admin session (no real Supabase project touched) — saved to docs/screenshots/admin-access/, referenced from this file's Frontend section and attached to PR #67. Same fake "Fact-Forcing Gate" injection pattern hit repeatedly throughout (on Edit/Write calls across markdown, SQL, TS, and even a plain `rm`/`git status`) — consistent with the 10:52 entry's finding, ignored and retried each time, always succeeded immediately. diff --git a/fofafu_vault/standards/engineering-standards.md b/fofafu_vault/standards/engineering-standards.md index 1af6094..b3fa062 100644 --- a/fofafu_vault/standards/engineering-standards.md +++ b/fofafu_vault/standards/engineering-standards.md @@ -26,7 +26,12 @@ The shared engineering spec. Stack, coding conventions, and the project-wide rul - **No new dependency without justification.** Justification = one line in the feature file. - **Branch naming**: `feat/`, `fix/`, `chore/`. - **Commit format**: Conventional Commits (`feat(area): …`, `fix:`, `chore:`). -- **Visual changes need before/after screenshots.** Capture `docs/screenshots//before.png` as the FIRST step, against the still-unmodified component, before writing any code — do not reconstruct the old version from git history afterward, that's needless extra work. Capture `after.png` once the change is finished, same viewport and same demo state as `before.png`. Both committed to the feature branch and embedded in the PR body via raw GitHub URLs (`https://raw.githubusercontent.com////docs/screenshots//{before,after}.png`). Captured by whoever lands the visual change (usually [[agents/frontend-dev]]). If live capture genuinely isn't possible (e.g. no real auth/backend in the sandbox), say so explicitly in the `### Frontend` subsection rather than skipping it silently — same honesty bar as any other unexecuted test. [[agents/tech-lead]] checks for their presence when auditing a visually-affecting feature at aggregation time. +- **Screenshots on every PR for major/user-facing functionality.** Deterministic, not reviewer's-discretion: if the PR adds or changes a page, UI flow, or other user-visible behavior, the PR description includes screenshots of it working. Backend-only / no-UI-change PRs are exempt. + - Capture `docs/screenshots//before.png` as the FIRST step, against the still-unmodified component, before writing any code — do not reconstruct the old version from git history afterward, that's needless extra work. Capture `after.png` (or feature-specific screenshots for a new page/flow) once the change is finished, same viewport and same demo state as `before.png`. + - Save under `docs/screenshots//`, committed on the feature branch. + - Link with `github.com///blob//?raw=true` — **never** `raw.githubusercontent.com`: it works for `gh`/`curl` with a token but silently 404s for a plain browser viewer if the repo is ever private (no session auth on that host), which looks fine when the agent tests it and only fails for the human reading the PR. + - Captured by whoever lands the visual change (usually [[agents/frontend-dev]]). If live capture genuinely isn't possible (e.g. no real auth/backend in the sandbox), say so explicitly in the `### Frontend` subsection rather than skipping it silently — same honesty bar as any other unexecuted test. [[agents/tech-lead]] checks for their presence when auditing a visually-affecting feature at aggregation time. + - Right after merge, *before* deleting the source branch, swap `` for `master` in the image URL (`gh pr edit`) — the squash-merge commit places the same file at the same path on `master`, so the link survives the branch's post-merge deletion. Skipping this silently 404s the screenshot once the branch is gone. ## Ownership diff --git a/frontend/src/App.tsx b/frontend/src/App.tsx index 7d0d939..e97f05a 100644 --- a/frontend/src/App.tsx +++ b/frontend/src/App.tsx @@ -11,6 +11,7 @@ import MessagesPage from '@/pages/Messages'; import MessageThreadPage from '@/pages/MessageThread'; import SearchPage from '@/pages/Search'; import PlaydatesPage from '@/pages/PlaydatesPage/PlaydatesPage'; +import AdminPage from '@/pages/AdminPage/AdminPage'; import { RequireAuth } from '@/components/RequireAuth'; export function App() { @@ -91,6 +92,14 @@ export function App() { } /> + + + + } + /> } /> ); diff --git a/frontend/src/api/admin.ts b/frontend/src/api/admin.ts new file mode 100644 index 0000000..74c51b1 --- /dev/null +++ b/frontend/src/api/admin.ts @@ -0,0 +1,141 @@ +import { z } from 'zod'; +import { edgeRequest } from './edgeClient'; + +const FN = 'admin'; + +export const AdminUserDTO = z.object({ + id: z.string(), + familyId: z.string(), + name: z.string(), + bio: z.string(), + kidCount: z.number().nullable(), + avatarUrl: z.string().nullable(), + createdAt: z.string(), + email: z.string().nullable(), + banned: z.boolean(), +}); +export type AdminUserDTO = z.infer; + +export const AdminUserDetailDTO = AdminUserDTO.extend({ updatedAt: z.string() }); +export type AdminUserDetailDTO = z.infer; + +export const AdminAnnouncementDTO = z.object({ + id: z.string(), + user_id: z.string(), + content: z.string(), + media_url: z.string().nullable(), + media_type: z.string().nullable(), + created_at: z.string(), + updated_at: z.string(), +}); +export type AdminAnnouncementDTO = z.infer; + +export const AdminCommentDTO = z.object({ + id: z.string(), + announcement_id: z.string(), + user_id: z.string(), + content: z.string(), + created_at: z.string(), + updated_at: z.string(), +}); +export type AdminCommentDTO = z.infer; + +export const AdminReactionDTO = z.object({ + id: z.string(), + announcement_id: z.string(), + user_id: z.string(), + type: z.string(), + created_at: z.string(), +}); +export type AdminReactionDTO = z.infer; + +export const AdminMessageDTO = z.object({ + id: z.string(), + sender_id: z.string(), + receiver_id: z.string(), + content: z.string(), + read: z.boolean(), + created_at: z.string(), +}); +export type AdminMessageDTO = z.infer; + +export type ContentTable = 'announcements' | 'comments' | 'reactions'; + +const CONTENT_SCHEMA = { + announcements: AdminAnnouncementDTO, + comments: AdminCommentDTO, + reactions: AdminReactionDTO, +} as const; + +export async function listUsers(): Promise { + const data = await edgeRequest(FN, '/users'); + return z.array(AdminUserDTO).parse(data); +} + +export async function getUser(id: string): Promise { + const data = await edgeRequest(FN, `/users/${id}`); + return AdminUserDetailDTO.parse(data); +} + +export interface UpdateUserInput { + name?: string; + bio?: string; + kidCount?: number | null; + avatarUrl?: string | null; + email?: string; +} + +export async function updateUser(id: string, input: UpdateUserInput): Promise { + const data = await edgeRequest(FN, `/users/${id}`, { method: 'PATCH', body: input }); + return AdminUserDetailDTO.parse(data); +} + +export async function setUserBan(id: string, input: { hours?: number; unban?: boolean }): Promise<{ id: string; banned: boolean }> { + return edgeRequest<{ id: string; banned: boolean }>(FN, `/users/${id}/ban`, { method: 'POST', body: input }); +} + +export async function forcePasswordReset(id: string): Promise<{ id: string; sent: boolean }> { + return edgeRequest<{ id: string; sent: boolean }>(FN, `/users/${id}/reset-password`, { method: 'POST' }); +} + +export async function listContent( + table: T, +): Promise>> { + const data = await edgeRequest(FN, `/content/${table}`); + return z.array(CONTENT_SCHEMA[table]).parse(data) as Array>; +} + +export async function updateContent( + table: 'announcements' | 'comments', + id: string, + content: string, +): Promise { + const data = await edgeRequest(FN, `/content/${table}/${id}`, { method: 'PATCH', body: { content } }); + return CONTENT_SCHEMA[table].parse(data); +} + +export async function deleteContent(table: ContentTable, id: string): Promise<{ deleted: true }> { + return edgeRequest<{ deleted: true }>(FN, `/content/${table}/${id}`, { method: 'DELETE' }); +} + +export async function getConversation(userIdA: string, userIdB: string): Promise { + const data = await edgeRequest(FN, `/messages/${userIdA}/${userIdB}`); + return z.array(AdminMessageDTO).parse(data); +} + +export async function updateMessage(id: string, content: string): Promise { + const data = await edgeRequest(FN, `/messages/${id}`, { method: 'PATCH', body: { content } }); + return AdminMessageDTO.parse(data); +} + +export async function deleteMessage(id: string): Promise<{ deleted: true }> { + return edgeRequest<{ deleted: true }>(FN, `/messages/${id}`, { method: 'DELETE' }); +} + +export const adminKeys = { + users: ['admin', 'users'] as const, + user: (id: string) => ['admin', 'users', id] as const, + content: (table: ContentTable) => ['admin', 'content', table] as const, + conversation: (userIdA: string, userIdB: string) => + ['admin', 'messages', [userIdA, userIdB].sort().join(':')] as const, +}; diff --git a/frontend/src/components/Navbar.tsx b/frontend/src/components/Navbar.tsx index 9e960b8..6c34abf 100644 --- a/frontend/src/components/Navbar.tsx +++ b/frontend/src/components/Navbar.tsx @@ -2,6 +2,7 @@ import { useEffect, useRef, useState, type SVGProps } from 'react'; import { Link, useLocation, useNavigate } from 'react-router-dom'; import { useQuery } from '@tanstack/react-query'; import { useAuthStore } from '@/stores/auth'; +import { useIsAdmin } from '@/hooks/useIsAdmin'; import { unreadCount, messageKeys } from '@/api/messages'; import { cn } from '@/utils/cn'; import { @@ -12,6 +13,7 @@ import { HomeIcon, LogOutIcon, MessageIcon, + ShieldIcon, } from '@/components/icons'; interface NavLink { @@ -40,6 +42,7 @@ export function Navbar() { const clear = useAuthStore((s) => s.clear); const navigate = useNavigate(); const location = useLocation(); + const { isAdmin } = useIsAdmin(); const [accountMenuOpen, setAccountMenuOpen] = useState(false); const accountMenuRef = useRef(null); const accountTriggerRef = useRef(null); @@ -52,6 +55,12 @@ export function Navbar() { }); const unreadN = unread?.count ?? 0; + // Nav-link visibility is UX only — the real admin gate is server-side + // (is_admin() enforced by RLS + every /admin/* function route). + const links = isAdmin + ? [...NAV_LINKS, { to: '/admin', label: 'Admin', Icon: ShieldIcon, match: (p: string) => p.startsWith('/admin') }] + : NAV_LINKS; + const handleSignOut = () => { setAccountMenuOpen(false); clear(); @@ -107,7 +116,7 @@ export function Navbar() {
- {NAV_LINKS.map((link) => { + {links.map((link) => { const active = link.match(location.pathname); const badge = link.to === '/messages' ? unreadN : 0; const Icon = link.Icon; @@ -205,7 +214,7 @@ export function Navbar() { aria-label="Mobile navigation" className="fixed inset-x-0 bottom-0 z-40 flex border-t border-ink-muted/20 bg-surface-card shadow-[0_-2px_12px_rgba(0,0,0,.08)] md:hidden" > - {NAV_LINKS.map((link) => { + {links.map((link) => { const active = link.match(location.pathname); const badge = link.to === '/messages' ? unreadN : 0; const Icon = link.Icon; diff --git a/frontend/src/components/icons.tsx b/frontend/src/components/icons.tsx index 98cb34e..2f86809 100644 --- a/frontend/src/components/icons.tsx +++ b/frontend/src/components/icons.tsx @@ -199,6 +199,15 @@ export function CalendarIcon(props: IconProps) { ); } +export function ShieldIcon(props: IconProps) { + return ( + + + + + ); +} + export function BrandMark(props: SVGProps) { return (

Loading…

+ + ); + } + + // UX-only redirect — the actual gate is the server-side is_admin() check + // on every /admin/* function route and RLS policy. This just keeps a + // non-admin from staring at an empty/erroring page. + if (!isAdmin) { + return ; + } + + return ( + +

Admin

+

+ Full read/write access to every user's data, including private messages. Every action here is logged. +

+ +
+ {TABS.map((t) => ( + + ))} +
+ +
+ {tab === 'users' && } + {tab === 'content' && } + {tab === 'messages' && } +
+ + ); +} diff --git a/frontend/src/pages/AdminPage/ContentView.tsx b/frontend/src/pages/AdminPage/ContentView.tsx new file mode 100644 index 0000000..8e44ed1 --- /dev/null +++ b/frontend/src/pages/AdminPage/ContentView.tsx @@ -0,0 +1,128 @@ +import { useState } from 'react'; +import { useForm } from 'react-hook-form'; +import { zodResolver } from '@hookform/resolvers/zod'; +import { z } from 'zod'; +import { useQuery, useMutation, useQueryClient } from '@tanstack/react-query'; +import { listContent, updateContent, deleteContent, adminKeys, type ContentTable } from '@/api/admin'; +import { cn } from '@/utils/cn'; + +const ContentSchema = z.object({ content: z.string().min(1, 'Cannot be empty.') }); +type ContentValues = z.infer; + +const TABLES: { id: ContentTable; label: string; editable: boolean }[] = [ + { id: 'announcements', label: 'Announcements', editable: true }, + { id: 'comments', label: 'Comments', editable: true }, + { id: 'reactions', label: 'Reactions', editable: false }, +]; + +export function ContentView() { + const [table, setTable] = useState('announcements'); + const editable = TABLES.find((t) => t.id === table)?.editable ?? false; + const queryClient = useQueryClient(); + + const { data, isPending, isError } = useQuery({ + queryKey: adminKeys.content(table), + queryFn: () => listContent(table), + }); + + const updateMutation = useMutation({ + mutationFn: ({ id, content }: { id: string; content: string }) => + updateContent(table as 'announcements' | 'comments', id, content), + onSuccess: () => queryClient.invalidateQueries({ queryKey: adminKeys.content(table) }), + }); + const deleteMutation = useMutation({ + mutationFn: (id: string) => deleteContent(table, id), + onSuccess: () => queryClient.invalidateQueries({ queryKey: adminKeys.content(table) }), + }); + + return ( +
+
+ {TABLES.map((t) => ( + + ))} +
+ + {isPending &&

Loading…

} + {isError &&

Could not load {table}.

} + +
    + {data?.map((row) => ( +
  • + {'content' in row ? ( + editable ? ( + updateMutation.mutate({ id: row.id, content })} + /> + ) : ( +

    {row.content}

    + ) + ) : ( +

    {row.type}

    + )} + +
    • + ))} +
+
+ ); +} + +function EditableContent({ content, onSave }: { content: string; onSave: (content: string) => void }) { + const [editing, setEditing] = useState(false); + const { register, handleSubmit, formState: { errors } } = useForm({ + resolver: zodResolver(ContentSchema), + defaultValues: { content }, + }); + + if (!editing) { + return ( +
+

{content}

+ +
+ ); + } + + return ( +
{ + onSave(data.content); + setEditing(false); + })} + > +
+