# Cleaning Supervisor (Mobile) — Cross-Role Handoffs

> The cross-role touchpoints this role fires into / receives from. **Identical to the anchor's** producer/receiver model — the Cleaning Supervisor is a **producer of submissions** (into the approval cascade) and a **receiver of send-backs**. It never approves (`PROJECT_PLAN §3`). Cascade mechanics live in `FOUNDATION_SPEC §4`. The only difference vs the anchor is the *content* (cleaning/hygiene templates), not the *mechanics*.

---

## Upstream input (what arrives at the Cleaning Supervisor)

| From | Trigger | What the CS receives | Surfaces on |
|---|---|---|---|
| **Store Manager / Team Leader** | Roster **published** (`SM-ROSTER-PUBLISH` / `TL-ROSTER`) | Auto-assign fires → `ChecklistInstance`s for Suresh's roster entry (**cleaning/hygiene** templates by role + cleaning area + shift; e.g. Cleaning / Hygiene — Daily, Washroom Hygiene Round) | `CS-DASH`, `CS-CHK-TODAY` + a `ROSTER_PUBLISHED` notification |
| **Team Leader / Store Manager / Operation Head** | **Send-back** at any approval step (`TL-CHK-VERIFY` / `SM-CHK-APPROVE` / `OH-CHK-APPROVE`) | Instance state → `SENT_BACK`, with the reject reason. Returns to **Suresh, the original filler** (§9 #3) — not the previous approver | `CS-CHK-STATUS` (red banner + Re-fill) + a `SENT_BACK` notification (FCM + in-app) |

## Downstream output (what the Cleaning Supervisor fires)

| To | Trigger | What fires | Lands on |
|---|---|---|---|
| **Team Leader (Priya)** | Suresh **submits** a checklist (`CS-CHK-SUBMIT` → `POST …/submit`) | Instance state → `SUBMITTED`; `ApprovalStep` rows (TL/SM/OH) created; **TL notified** (FCM + in-app). The TL's verify queue gains this instance | `TL-CHK-VERIFY` / `TL-CHK-OVERVIEW` + a notification to Priya |
| **Up the chain (derived)** | submission climbs the cascade | While not yet OH-approved, the instance reads **Pending** to TL/SM/OH per their level (derived, L8); the CS still sees the real sub-state | `OH-DASH` / `*-CHK-OVERVIEW` Pending counts |
| **Reports (roll-up)** | items recorded | Suresh's **G** items feed the Positive report; **A** items + their issue photos feed the Negative report (per area/shift/day/Game Zone) | `*-REP-POSITIVE`, `*-REP-NEGATIVE` (TL/SM/OH packs) |
| **Cleaning staff (own team)** *(CL-5)* | Suresh **saves an allocation** (`CS-ASSIGN` → `POST /me/cleaning-assignments`) | Each staff member's area/zone for the shift is set (staff→area map); an `AuditLog` row is written. **Task-routing only** — it does not create checklist instances, change the roster, or alter the approval cascade (the CS still fills + submits the cleaning checklist himself) | cleaning staff's own view / day-of allocation; CS's `CS-DASH` allocation summary |
| **Overdue escalation** | `now() > dueAt` and not submitted | Instance → `OVERDUE`; escalates up the chain | `*-REP-OVERDUE`, dashboards |

## The closed loop (end-to-end)

```
SM publishes roster ──auto-assign──▶ CS-CHK-TODAY (Suresh: Cleaning / Hygiene — Daily)
        ▲                                    │ fill G/A + completion photo + per-A photo
        │ send-back (to Suresh)              ▼ submit  ──notify──▶  TL verify queue (Priya)
   CS-CHK-STATUS  ◀────────────── (any approver rejects)              │ approve
   (red banner, Re-fill)                                              ▼
                                                          SM approve ─▶ OH approve = DONE
                                            (until OH approves, everyone above sees PENDING)
```

## Contract notes for the BE dev
- The **submit** handler is the **same single producer-side touchpoint** as the anchor: on success it (1) transitions state, (2) creates the 3 `ApprovalStep`s, (3) enqueues the TL notification (FCM fan-out to Priya's `DeviceToken`s + an in-app `Notification`). Implement once (Wave 0); both MON and CS use it unchanged. The TL pack consumes the queue.
- The **send-back** handler (TL/SM/OH packs) must set `state=SENT_BACK` and notify the **original `fillerId`**, not the previous approver — the CS pack only *reads* this outcome via `/me/notifications` + `/me/submissions`.
- Do **not** expose any approve/sendback endpoint to CS — the resolver denies it (403). This pack consumes none of them.
- **Auto-assign delta:** the producer/cascade touchpoints are identical; only the *upstream* auto-assign branch differs (cleaning/hygiene category vs ride-cert). See the gap flagged in `api-contract.md` — confirm the cleaning auto-assign rule at the client demo before building the CS branch.