The UAT seed creates the uat-groomer@groombook.dev Better Auth account
(staffId 00000000-0000-0000-0000-000000000004) but no appointments, so
GET /api/pets?groomer=me returns [] and GET /api/pets/{anyId}/profile-summary
returns 404. This makes GRO-1987 TC-UAT-2/3 (RBAC tests for the
profile-summary endpoint) un-runnable.
This is the seed-side counterpart of GRO-1983 (stale password hashes):
that was the credential row, this is the linkage row.
Fix: add seedUatGroomerLinkage() called from seedUatStaffAccounts(), so
both the full seed() path and the seedKnownUsers() path (prod reset
CronJob with SEED_KNOWN_USERS_ONLY=true) produce a deterministic
completed appointment linking the UAT groomer to UAT Pup Alpha
(c0000001-0000-0000-0000-000000000002). UAT Pup Beta is intentionally
left UNLINKED so TC-UAT-3 can verify the 403 forbidden response.
The deterministic appointment id (a0000001-0000-0000-0000-000000000001)
makes the function idempotent: re-running the seed (hourly via the
reset-demo-data CronJob) is a no-op once the row exists.
Verification (after the next 17:00 reset):
- GET /api/pets/{c0000001-0000-0000-0000-000000000002}/profile-summary
as uat-groomer → 200 with recentGroomingHistory/visitCount/upcomingAppointment
- GET /api/pets/{c0000001-0000-0000-0000-000000000003}/profile-summary
as uat-groomer → 403
If the unlinked-pet case returns 404 instead of 403, that is a
separate RBAC defect — file against the api repo, not the seed.
Co-Authored-By: Paperclip <noreply@paperclip.ing>
The seed Job `seed-test-data-b5943fb` failed three times on prod with
`duplicate key value violates unique constraint "services_pkey"` after
migrations 0039/0040 landed. Two interlocking bugs in
`packages/db/src/seed.ts` (and the parallel `apps/api/src/db/seed.ts`
tree — both kept in sync per the GRO-2052/2013/2014 lesson):
1. The reset `TRUNCATE` excluded `services`, so a prior
`seedKnownUsers` run that wrote `id=b0000001-…-004, name="Nail Trim"`
survived every reset. The next full `seed()` then tried to insert
`id=b0000001-…-004, name="Full Groom — Large"` and PostgreSQL
raised `services_pkey` (id collision) — the name-targeted
`ON CONFLICT` couldn't fire because the conflict was on a different
column.
2. The `demoSvcs` (used by `seedKnownUsers`) had `id=…-004, name="Nail Trim"`
while `servicesDef` (used by the full `seed()`) has `id=…-004,
name="Full Groom — Large"`. `Nail Trim` was supposed to be
`id=…-005` in the demo subset.
Fix:
* `TRUNCATE services, …` so each reset rebuilds the catalogue from
`servicesDef` (CASCADE handles appointments/invoices FKs).
* Key both services upserts on `schema.services.id` (not `name`) so
deterministic ids always win — defense-in-depth if a future change
drops `services` from the TRUNCATE list again.
* Reconcile the id↔name map: `demoSvcs[3]` is now
`id=…-005, name="Nail Trim"` to match `servicesDef[4]`.
* Update `UAT_PLAYBOOK.md §4.5.1` with regression coverage
(TC-SEED-1..4).
Required for the GRO-2033 close-out: infra PR #605 must repoint to the
new image tag (NOT 2a6242d) and `apps/overlays/prod/reset-cronjob.yaml`
must stay suspended until a one-shot seed Job runs 1/1 against prod.
Co-Authored-By: Paperclip <noreply@paperclip.ing>
Paperclip