# Staff Court Monitor (Mobile) — Developer Handoff

> Handoff pack for **dev-mode v1.0 slot 5 — the ANCHOR**. Built 2026-06-18 from the locked design (`docs/design/SCREEN_LIST.md` MON block, `docs/design/DESIGN_SYSTEM.md`, `docs/dev-mode-v1.0/FOUNDATION_SPEC.md`).
> Persona: **Ramesh Kumar** · Staff Court Monitor · Game Zone Ahmedabad-1 · Trampoline-certified · reports to Priya Nair (TL).
> Surface: **Mobile (Flutter), portrait ~390px.** This pack is the TEMPLATE the other 6 role packs mirror (Step 3b).

---

## Who consumes which file

| Role | Primary file | Why |
|---|---|---|
| **Mobile (Flutter) Developer** | `tasks.md` Mobile-FE column → filter `Priority=P0`, sort by Dependencies. Build queue. Pixel target = `screens/*.html` at 390px. | Builds the fill→submit→status flow from the Flutter design-system; photo-gate + G/A toggle + offline-retry. |
| **Backend Developer** | `tasks.md` Backend column + `api-contract.md` + `FOUNDATION_SPEC §3/§4`. | The endpoints in `api-contract.md`; submit-gate + cascade producer touchpoint (TL notify). |
| **Tester** | `spec.md` acceptance summary + the two `flows/`. | Mobile `integration_test`: photo-gate, send-back-to-filler, status timeline, Game-Zone scope. |
| **Web Frontend Developer** | **N/A for this slot** (this is the mobile-primary surface). The thin web read-only fallback is a P2 secondary surface, not built here. | — |

---

## Definition of Done for slot-5 (anchor) implementation

The slot ships when all P0 behaviours in `spec.md` pass in a UAT build, evidenced by:

1. **Login → role-resolve:** login routes to Monitor Home via `GET /me`; nav (5 bottom-nav slots) + permissions come from the server — **no hardcoded role logic** in the app.
2. **Today's list integrity:** `MON-CHK-TODAY` shows exactly the auto-assigned instances for Ramesh's published roster entry, scoped to his Game Zone + own assignments; status chips render the correct sub-state.
3. **G/A toggle (DESIGN_SYSTEM §6.13):** G = green / A = red-orange, by color+icon+label; selecting **A** opens the note+photo sheet and flags the item photo-required; an untouched item blocks submit.
4. **Photo evidence (§4a, L7):** completion photo + per-A-item issue photo capture via the photo-capture sheet; each is a multipart upload to **local-disk storage**; thumbnails + remove work.
5. **Submit gate (UI + server):** submit is blocked client-side AND rejected server-side (422) unless every item is answered, ≥1 completion photo exists, and every A item has its issue photo.
6. **Submit transition + handoff:** on success the instance → `SUBMITTED`, `ApprovalStep`s created, **TL (Priya) notified** (FCM + in-app), and the app routes to status.
7. **Status timeline (DESIGN_SYSTEM §6.14):** `MON-CHK-STATUS` renders the cascade stepper; the Monitor sees the **real sub-state** of own instances (never "Pending").
8. **Send-back to filler (§9 #3):** a send-back from any approver surfaces a red banner + reason + Re-fill on `MON-CHK-STATUS`, returning to Ramesh (not the previous approver); Re-fill reopens fill.
9. **Read-only roster + profile:** `MON-ROSTER-OWN` shows own shifts with no create/edit affordance; `SH-PROFILE` shows role/reports-to/certified rides + logout.
10. **States:** loading (skeleton), empty (nothing-assigned), error+retry, **offline-retry preserving the in-memory draft**, locked (login), 403 (out-of-scope) all render and are reachable.
11. **Chrome + scope:** navy top app bar + Game-Zone scope strip + 5-slot bottom nav + orange FAB on fill screens, matching `DESIGN_SYSTEM §8.2`; no cross-Game-Zone data leak; CI Dart-model drift gate green.

P1 items are nice-to-have for the slot; out-of-slot items (approve/verify, roster build, reports, templates) are explicitly not here.

---

## Slot scope at a glance

- **8 screen mockups** (login, dashboard, today's checklists, fill, submit, status, profile, roster) · **6 state variants** · **3 bottom-sheets** = **17 HTML artifacts** (PNG render is a later step).
- Endpoints consumed: auth (login/refresh/logout/forgot/reset), `/me`, my roster, today's checklists, instance detail, save/submit responses, photo upload, my submissions + timeline, notifications, device register.
- **The anchor sets the template:** Senior Court Monitor + Cleaning Supervisor packs (Step 3b) are clones — same screens/flow, different auto-assigned templates (CS = cleaning/hygiene, slot-2 label "Cleaning").

## Blocking questions / decisions before fan-out (Step 3b)

- [ ] **Ride↔template auto-assign map** (`PROJECT_PLAN §9 #2`, `DEV_EXECUTION_PLAN` D4): confirm at the client demo exactly which templates land for Trampoline/Toddler/ZipZag and which shift role is the "opener" for the 114-pt. The engine is generic; only the seed rows are blocked.
- [ ] **Completion photo count:** is exactly 1 completion photo required, or a minimum per section/area? Spec assumes ≥1 per instance.
- [ ] **Time-stamp source:** is the per-item `recordedAt` the device time or server time? Spec assumes device-captured, editable, server-validated against the shift window.
- [ ] **Re-fill after send-back:** on re-submit, does the cascade restart from TL (assumed), or resume at the rejecting level? Spec assumes restart from TL (§4b).
- [ ] **Initials:** free-text initials per response, or derived from the logged-in user? Spec captures free-text but defaults to the user's initials.
- [ ] **FCM on iOS:** confirm APNs cert/key provisioning for the unified app before the notification touchpoint is testable end-to-end.
- [ ] **Tester model** (`DEV_EXECUTION_PLAN` D3): dedicated tester per triad vs pooled — affects who owns the photo-gate + send-back integration suite.

---

## File references
- Pack root: `docs/design/dev-mode-v1.0/staff-court-monitor-mobile/`
- Screens: `screens/*.html` · States: `states/*.html` · Sheets: `bottom-sheets/*.html`
- Spec: `spec.md` · API: `api-contract.md` · Handoffs: `HANDOFFS.md` · Flows: `flows/*.md`
- Foundation: `docs/dev-mode-v1.0/FOUNDATION_SPEC.md` · Dev plan: `docs/dev-mode-v1.0/DEV_EXECUTION_PLAN.md`
- Project plan: `docs/PROJECT_PLAN.md` · Design system: `docs/design/DESIGN_SYSTEM.md` · Workflow: `docs/WORKFLOW_GUIDE.md`
