feat(GRO-2319): dev→uat — portal waitlist surfacing + seed (api) (#205)

AGENTS.md

@@ -1,54 +0,0 @@
-# AGENTS.md
-
-This repository (`groombook/api`) is part of the GroomBook application stack. The
-authoritative process, quality bar, and safety rules live in the shared
-[`groombook/org`](https://git.farh.net/groombook/org) skills repository. Read
-those first; this file is only a pointer.
-
-## Authoritative skills
-
-- **SDLC (branching, PRs, phases, handoffs):**
-  [`groombook/org/skills/sdlc/SKILL.md`](https://git.farh.net/groombook/org/src/branch/main/skills/sdlc/SKILL.md)
-- **Coding standards (priority ordering, PR discipline, tests, no-hardcoded-values, CalVer):**
-  [`groombook/org/skills/coding-standards/SKILL.md`](https://git.farh.net/groombook/org/src/branch/main/skills/coding-standards/SKILL.md)
-- **Safety (no plaintext secrets, no direct `kubectl apply` to `groombook`, no self-merge, board approval for destructive actions):**
-  [`groombook/org/skills/safety/SKILL.md`](https://git.farh.net/groombook/org/src/branch/main/skills/safety/SKILL.md)
-
-For human contributors and humans reviewing agent work, see
-[`CONTRIBUTING.md`](./CONTRIBUTING.md) in this repo for the phase-by-phase PR
-flow and the `uat→main` merge-gate policy summary.
-
-## Non-negotiable operational rules
-
-These mirror the org skills; they are restated here so any agent landing in
-this repo sees them without a cross-repo fetch.
-
-- **All changes go through a PR.** Never push directly to `dev`, `uat`, or `main`.
-- **Branch strategy:** `feature/<name>` → `dev` → `uat` → `main`. Engineers
-  always target `dev` first.
-- **No self-merge contract.** The engineer who opened a PR clicks merge only
-  after the named reviewer (CI / QA / UAT / Security / CTO per phase)
-  approves. Issue-thread QA / UAT / security approvals do **not** clear the
-  Gitea `required_approvals` gate on `uat→main` — only a Gitea **Approve**
-  click from a member of the `approvals_whitelist_username` does. On this
-  repo that whitelist is `["gb_flea", "gb_dogfather"]` (engineer team).
-  Board-level accounts cannot give the Approve click by policy.
-- **Always include `cc @cpfarhood`** at the bottom of every PR body for
-  board visibility (not as a reviewer).
-- **Secrets in code are forbidden.** Use Bitnami Sealed Secrets; never commit
-  plaintext. See the `safety` skill.
-- **Production (`groombook` namespace) is Flux-managed.** Never
-  `kubectl apply` directly. Infrastructure changes go through PRs in
-  `groombook/infra`.
-
-## Local development
-
-See the repo's own README, package scripts, and CI workflow. The
-authoritative pipeline (Gitea Actions, image build, deploy hooks) is the
-shared `groombook/infra` overlay; do not reimplement it here.
-
-## When uncertain
-
-If a task conflicts with the org skills, **the org skills win**. Open an
-issue in `groombook/org` to propose a change rather than encoding a local
-exception.

CONTRIBUTING.md

@@ -1,117 +0,0 @@
-# Contributing to `groombook/api`
-
-Thanks for contributing. This document is the human-facing companion to
-[`AGENTS.md`](./AGENTS.md) and the authoritative
-[`groombook/org`](https://git.farh.net/groombook/org) skills. The org skills
-govern; this file is a quick-reference for the human/agent PR flow in this
-repo.
-
-## Branch strategy
-
-Three long-lived branches; one PR per promotion step.
-
-| Branch  | Environment | Who merges | Prerequisites for merge |
-|---------|-------------|-----------|-------------------------|
-| `dev`   | Dev         | Engineer  | CI passes               |
-| `uat`   | UAT         | Engineer  | QA code review approval |
-| `main`  | Production  | Engineer  | UAT validation + CTO Gitea Approve when the `uat→main` merge-gate policy applies (see below) |
-
-Engineers always target `dev` first. Feature branches: `<agent-name>/<short-description>`.
-
-## Phase-by-phase PR flow
-
-### Phase 1 — Dev
-
-1. Branch from `dev`: `git checkout -b <name>/<short-description> origin/dev`.
-2. Write code + tests. Run unit tests, type check, and lint locally (or rely on CI).
-3. Open a PR against `dev`:
-   ```bash
-   tea pr create --base dev --title "..." --body "..."
-   ```
-   Include `cc @cpfarhood` at the bottom of the body for board visibility.
-4. CI must pass. CI green → engineer self-merges.
-5. CI builds and deploys to Dev automatically.
-
-### Phase 2 — UAT promotion
-
-1. Open a PR from `dev` to `uat`.
-2. CI must pass.
-3. **QA (Lint Roller)** reviews and approves on the Gitea PR.
-4. QA approved → engineer self-merges.
-5. CI builds and deploys to UAT automatically.
-
-### Phase 3 — UAT regression + Security review
-
-1. **UAT (Shedward Scissorhands)** runs full regression against UAT — every
-   feature, old and new, no exceptions.
-2. **Security (Barkley Trimsworth)** reviews the changes.
-3. Failures in either gate bounce back to Phase 1.
-
-### Phase 4 — Production promotion (`uat → main`)
-
-This is the gate the org PR
-[`groombook/org#13`](https://git.farh.net/groombook/org/pulls/13) defines.
-The full rule is in
-[`groombook/org/skills/sdlc/SKILL.md`](https://git.farh.net/groombook/org/src/branch/main/skills/sdlc/SKILL.md)
-and
-[`groombook/org/skills/coding-standards/SKILL.md`](https://git.farh.net/groombook/org/src/branch/main/skills/coding-standards/SKILL.md);
-the summary is below.
-
-**The CTO Gitea Approve click is NOT the default gate.** Once the four
-pre-gates (QA, UAT deploy, UAT regression, security) are green, the engineer
-self-merges.
-
-**A CTO Gitea Approve click IS required** only for PRs in one of three
-categories:
-
-1. **Novel auth / session paths** — login, OIDC, OOBE, session middleware,
-   token issuance, password reset, MFA, new auth provider integrations.
-   Routine auth-gated UI (button styling, error messages, form layout) is
-   **not** in this category.
-2. **Infra / prod-affecting merges** — deploys, infra manifests, secrets,
-   GitOps overlays, CI/CD, `main` branch protection, production
-   routing/ingress, prod state mutations. All Phase 5 infra overlay PRs in
-   `groombook/infra` require CTO Gitea Approve without exception.
-3. **Risk-flagged merges** — `risk:cto-approve` label, or explicit CTO/CEO
-   sign-off request in the PR or issue thread.
-
-The engineer opens the `uat→main` PR, classifies it against the three
-categories above, and adds `cc @cpfarhood`. If the PR is in scope, the CTO
-clicks Approve; once approved (and the four pre-gates are green), the
-engineer merges.
-
-### Phase 5 — Production deployment
-
-A separate PR in `groombook/infra` bumps the overlay image tag for prod.
-Handed to QA (Lint Roller) for review, then self-merged by the engineer.
-
-## The four pre-gates (uat→main)
-
-A `uat→main` PR is mergeable when **all four** are green:
-
-1. **QA code review** — done on the dev→uat promotion PR.
-2. **UAT deploy** — the UAT image built from the uat tip is live in UAT.
-3. **UAT regression** — Shedward's full-feature UAT pass is green (no
-   pre-existing defects, no new defects).
-4. **Security review** — Barkley's security code review is green.
-
-Issue-thread QA / UAT / security approvals do **not** clear the Gitea
-`required_approvals` gate. Only a Gitea **Approve** click from a member of
-the `approvals_whitelist_username` for `main` clears it. In this repo that
-whitelist is the engineer team (`gb_flea`, `gb_dogfather`).
-
-## Style, tests, and quality bar
-
-See
-[`groombook/org/skills/coding-standards/SKILL.md`](https://git.farh.net/groombook/org/src/branch/main/skills/coding-standards/SKILL.md)
-for the engineering priority ordering, test requirements, no-hardcoded-values
-rules, CalVer versioning policy, and the `git.farh.net` container registry
-policy.
-
-## Safety
-
-See
-[`groombook/org/skills/safety/SKILL.md`](https://git.farh.net/groombook/org/src/branch/main/skills/safety/SKILL.md)
-for the non-negotiable rules: no plaintext secrets, no `kubectl apply` to
-`groombook`, no self-merge, no direct `tofu` runs, board approval for
-destructive actions, escalation protocol.

UAT_PLAYBOOK.md

@@ -288,7 +288,6 @@ This means:
 | TC-API-8.17 | SSO portal session slides on activity (GRO-2234) | Establish a portal session (TC-API-8.8). Note the returned `sessionId`. Make any authenticated portal call (e.g. `GET /api/portal/me`) several times spaced over ≥1 minute, each with `X-Impersonation-Session-Id: {sessionId}`. | Every call returns 200; the session's `expiresAt` is extended (slid forward to ~30 min from each request) so the session stays valid during continuous use — it does NOT lapse mid-session. SSO-bridge sessions mint with a 30-min idle TTL bounded by an 8h absolute cap from `startedAt`. |
 | TC-API-8.18 | Slow-wizard Book New submit succeeds (GRO-2234) | Establish a portal session (TC-API-8.8). Wait >2 minutes while making at least one intervening authenticated portal call (mimicking the multi-step Book New wizard: pet/service/groomer/date GETs). Then `POST /api/portal/waitlist` with a valid pet+service payload and the same `X-Impersonation-Session-Id`. | 201 Created — the deliberately-paced wizard no longer 401s on submit because activity slid the session forward. (Regression guard for the GRO-2234 "session TTL too short → 401" defect.) |
 | TC-API-8.19 | Portal appointments surface active waitlist entries (GRO-2319) | As `uat-customer@groombook.dev`, establish a portal session, then `GET /api/portal/appointments`. | 200 OK. In addition to the customer's appointments, the response includes the seeded ACTIVE waitlist entry as a synthetic card: `status: "waitlisted"`, `id` prefixed `waitlist:`, `confirmationStatus: null`, a non-null derived `startTime` (from the entry's preferred date/time), and the entry's `pet`. Cancelled/notified/expired waitlist entries are NOT surfaced. |
-| TC-API-8.20 | Portal waitlist card populates service {id, name} (GRO-2342) | As `uat-customer@groombook.dev`, establish a portal session, then `GET /api/portal/appointments`. | 200 OK. The synthetic `waitlisted` card returned for the active waitlist entry has `service: {id: "<serviceId>", name: "<serviceName>"}` (full service record, not just `{id}`), matching the shape the appointments join returns. The portal Upcoming list therefore renders the actual service name in place of the fallback "Service" label. |
 
 ### 4.9 Waitlist
 

src/__tests__/portal.test.ts

@@ -42,7 +42,6 @@ let selectAppointmentRow: Record<string, unknown> | null = null;
 let selectWaitlistRows: Record<string, unknown>[] = [];
 let selectPetRows: Record<string, unknown>[] = [];
 let selectStaffRows: Record<string, unknown>[] = [];
-let selectServiceRows: Record<string, unknown>[] = [];
 let updatedValues: Record<string, unknown>[] = [];
 
 function resetMock() {
@@ -51,7 +50,6 @@ function resetMock() {
   selectWaitlistRows = [];
   selectPetRows = [];
   selectStaffRows = [];
-  selectServiceRows = [];
   updatedValues = [];
 }
 
@@ -85,7 +83,6 @@ vi.mock("@groombook/db", () => {
   const waitlistEntries = mkTable("waitlistEntries");
   const pets = mkTable("pets");
   const staff = mkTable("staff");
-  const services = mkTable("services");
 
   return {
     getDb: () => ({
@@ -106,9 +103,6 @@ vi.mock("@groombook/db", () => {
           if (table._name === "staff") {
             return makeChainable(selectStaffRows);
           }
-          if (table._name === "services") {
-            return makeChainable(selectServiceRows);
-          }
           return makeChainable([]);
         },
       }),
@@ -132,7 +126,6 @@ vi.mock("@groombook/db", () => {
     waitlistEntries,
     pets,
     staff,
-    services,
     eq: vi.fn(),
     and: vi.fn(),
     inArray: vi.fn(),
@@ -205,56 +198,6 @@ describe("GET /portal/appointments (waitlist surfacing — GRO-2319)", () => {
   });
 });
 
-// GRO-2342: GET /portal/appointments must populate the synthetic waitlist
-// card's `service` object with the full service record (id + name) — same
-// shape the appointments join returns — so the portal renders the real
-// service name in place of the fallback "Service" label.
-describe("GET /portal/appointments (waitlist service name — GRO-2342)", () => {
-  it("returns service {id, name} on the synthetic waitlist card", async () => {
-    selectSessionRow = ACTIVE_SESSION;
-    selectAppointmentRow = { ...APPOINTMENT };
-    selectWaitlistRows = [
-      {
-        id: "22222222-2222-2222-2222-222222222222",
-        petId: "pet-1",
-        serviceId: "svc-1",
-        preferredDate: "2099-01-01",
-        preferredTime: "13:00:00",
-      },
-    ];
-    selectPetRows = [{ id: "pet-1", name: "Rex", photoKey: null }];
-    selectServiceRows = [{ id: "svc-1", name: "Full Groom" }];
-
-    const res = await app.request("/portal/appointments", {
-      headers: { "X-Impersonation-Session-Id": SESSION_ID },
-    });
-    expect(res.status).toBe(200);
-    const body = await res.json();
-    const waitlistCard = body.appointments.find(
-      (a: { status: string }) => a.status === "waitlisted",
-    );
-    expect(waitlistCard).toBeTruthy();
-    expect(waitlistCard.service).toEqual({ id: "svc-1", name: "Full Groom" });
-  });
-
-  it("returns service {id, name} on the appointment card (same shape)", async () => {
-    selectSessionRow = ACTIVE_SESSION;
-    selectAppointmentRow = { ...APPOINTMENT, serviceId: "svc-appt" };
-    selectServiceRows = [{ id: "svc-appt", name: "Bath & Brush" }];
-
-    const res = await app.request("/portal/appointments", {
-      headers: { "X-Impersonation-Session-Id": SESSION_ID },
-    });
-    expect(res.status).toBe(200);
-    const body = await res.json();
-    const apptCard = body.appointments.find(
-      (a: { status: string }) => a.status === "scheduled",
-    );
-    expect(apptCard).toBeTruthy();
-    expect(apptCard.service).toEqual({ id: "svc-appt", name: "Bath & Brush" });
-  });
-});
-
 describe("PATCH /portal/appointments/:id/notes", () => {
   it("returns updated appointment with safe fields only", async () => {
     selectSessionRow = ACTIVE_SESSION;

src/routes/portal.ts

@@ -219,22 +219,12 @@ portalRouter.get("/appointments", async (c) => {
     ...waitlistRows.map(w => w.petId),
   ];
   const staffIds = allAppts.map(a => a.staffId).filter((id): id is string => id !== null);
-  // GRO-2342: services must be looked up for both appointment and waitlist cards
-  // so the portal can render `service.name` in place of the fallback "Service"
-  // label (CMPO sign-off on the GRO-2319 waitlist card explicitly excluded the
-  // service name; this follow-up closes the cosmetic gap).
-  const serviceIds = [
-    ...allAppts.map(a => a.serviceId).filter((id): id is string => id !== null),
-    ...waitlistRows.map(w => w.serviceId).filter((id): id is string => id !== null),
-  ];
 
   const petRows = petIds.length ? await db.select().from(pets).where(inArray(pets.id, petIds)) : [];
   const staffRows = staffIds.length ? await db.select().from(staff).where(inArray(staff.id, staffIds)) : [];
-  const serviceRows = serviceIds.length ? await db.select().from(services).where(inArray(services.id, serviceIds)) : [];
 
   const petMap = Object.fromEntries(petRows.map(p => [p.id, p]));
   const staffMap = Object.fromEntries(staffRows.map(s => [s.id, s]));
-  const serviceMap = Object.fromEntries(serviceRows.map(s => [s.id, s]));
 
   const appts = allAppts.map(a => ({
     id: a.id,
@@ -245,17 +235,13 @@ portalRouter.get("/appointments", async (c) => {
     customerNotes: a.customerNotes,
     notes: a.notes,
     pet: a.petId ? { id: petMap[a.petId]?.id, name: petMap[a.petId]?.name, photo: petMap[a.petId]?.photoKey } : null,
-    service: a.serviceId ? { id: a.serviceId, name: serviceMap[a.serviceId]?.name } : null,
+    service: a.serviceId ? { id: a.serviceId } : null,
     staff: a.staffId ? { id: staffMap[a.staffId]?.id, name: staffMap[a.staffId]?.name } : null,
   }));
 
   // Derive a display `startTime` from the entry's preferred date/time so the
   // portal can sort/classify the synthetic card (an invalid combination simply
-  // yields a null startTime, which the portal tolerates). GRO-2342: also
-  // populate the synthetic card's `service` object with the full service
-  // record (id + name) — same shape the appointments join returns — so the
-  // portal renders the real service name in place of the fallback "Service"
-  // label.
+  // yields a null startTime, which the portal tolerates).
   const waitlistAppts = waitlistRows.map(w => {
     const parsed = new Date(`${w.preferredDate}T${w.preferredTime}`);
     const startTime = Number.isNaN(parsed.getTime()) ? null : parsed;
@@ -268,7 +254,7 @@ portalRouter.get("/appointments", async (c) => {
       customerNotes: null,
       notes: null,
       pet: { id: petMap[w.petId]?.id, name: petMap[w.petId]?.name, photo: petMap[w.petId]?.photoKey },
-      service: w.serviceId ? { id: w.serviceId, name: serviceMap[w.serviceId]?.name } : null,
+      service: { id: w.serviceId },
       staff: null,
     };
   });