# Live App → Backend Agent Requests

This is the **Live app's local working copy** of pending coordination requests. The canonical destination is `../buyerkiosk-web/docs/api/live-agent-requests.md` per the protocol in `CLAUDE.md` (see "Inter-Agent Communication"). A future Live-app or backend agent should sync entries from this file into the backend repo's tracking file.

This local copy exists so the Live-flutter repo can record its own outstanding asks without depending on the backend repo being checked out alongside.

## Pending Requests

### REQ-20260522-01: Dedicated 2-Week Schedule + Bulk-Delete Endpoints (Spec 003 Phase 3 Round 3)

**Status**: `pending`
**Requested**: 2026-05-22
**Live App Feature**: Spec 003-schedule-visibility — Manager Full Schedule (Live `FullScheduleScreen`)
**Priority**: `medium`

#### Context

Round 3 of Phase 3 ships the Live (manager) `FullScheduleScreen` with a default 2-Week view and a destructive Clear Week action. With Phase 1 backend endpoints, the Live repo currently approximates both with N+1 fan-out:

- `SchedulingRepositoryImpl.getTwoWeekSchedule()` fetches **2 weekly-summary calls + 14 daily-schedule calls** for every 2-Week render (and the default Live screen starts in 2-Week mode).
- `SchedulingRepositoryImpl.clearWeek()` loops `deleteShift` per shift (up to ~50 per week per PRD assumptions). Partial failures are reported per-shift on the client side via `ClearWeekResult.failedShiftIds`.

These workarounds are functionally correct (the reducer is tested) but they're chatty under poor connectivity and the bulk-delete loop doesn't carry transactional semantics — a long pause in the middle leaves the week half-cleared.

#### Questions

1. **2-week endpoint** — Are you open to adding a `GET /api/mobile/scheduling/:typeNum/manager/schedule/two-weeks?weekStart=YYYY-MM-DD` that returns `{weekA: WeeklySummary, weekB: WeeklySummary, shifts: Shift[]}` in one round-trip? Same payload shape we currently merge client-side; just consolidated. Phase 1's per-day endpoint already returns the same Shift rows so DB cost is identical to today.

2. **Bulk-delete endpoint** — Are you open to adding `POST /api/mobile/scheduling/:typeNum/manager/schedule/clear-week` with body `{weekStart, shiftIds: int[], reason}` returning `{deleted: int[], failed: {shiftId: int, reason: string}[]}`? Transactional-best-effort is fine (loop server-side and report per-shift), but a single HTTP request eliminates the partial-failure-due-to-app-backgrounded class of bug.

3. **`selfEmployeeId` plumbing** — The Live LWW reducer (`reduceWeeklyScheduleEvent`) accepts an optional `selfEmployeeId` to skip override toasts when the event's actor IS the current user. Today the client passes `null` (so every foreign-looking actor triggers the toast — false-positive risk if the same employee is logged in on two devices). Could the verify/auth response carry the per-store employee ID alongside the employee link map? Spec'd in SDD §"Runtime View — LWW arbitration flow"; non-blocking for v1 but a quality improvement.

#### Backend Response
*Awaiting response*