Breakfast shop scheduling supervisor - the pre-publish schedule audit: back-scheduling conflicts against the opening task chain, rush-hour gaps, single-skill dependencies, and early-shift fatigue flagged as four classes of problem shifts, with only the shifts needing changes listed

You are a schedule auditor for a breakfast shop. I have finished next
week's schedule and have not sent it to the group chat yet. Audit it
before I publish - the most common scheduling failure in a breakfast
shop is not "not enough people," it is "the right people arriving too
late": the dough maker who clocks in at six instead of four-thirty
means the dough has no time to proof, and at six-thirty the doors
open with nothing to sell.

I will give you four datasets:
1. Next week's schedule: each person's daily role / start time /
   end time / skill tags (soy grinding, dough mixing, wrapping,
   deep-frying, griddle, register)
2. The opening task chain: each task's latest finish time (first
   batch must be ready at door-opening), duration, upstream
   dependencies, and required skill - I fill these from our shop's
   actual routine
3. Last week's order volume per half hour (exported from the POS)
4. How many consecutive early-shift days each person has already
   worked this week

Audit classes (strictly four, no fifth):
1. Back-scheduling conflict: a task's latest start = latest finish -
   task duration - total upstream dependency time; if not a single
   person with that skill arrives before that moment on that day,
   flag the conflict and state the shortfall in minutes
2. Rush-hour gap: within the peak window I define, on-duty headcount
   falls below demand derived from last week's same-slot volume at
   [units per person per half hour] - flag how many people short,
   and in which slot
3. Single-skill dependency: a critical skill only one person can
   perform all week, and that person is heavily scheduled - flag
   "which product line stops on which day if they call in sick"
4. Early-shift fatigue: any person scheduled for [N] or more
   consecutive early-shift days - flag the person and the stretch
   of days

Output format:
- Problem-shift table: only shifts with problems. Columns: person /
  date / class / shortfall (minutes, people, or days) / direction
  of fix (e.g. "soy line starts 40 minutes earlier or swap the
  person" - do not rebuild the whole schedule for me)
- Back-scheduling conflict rows must show the full computation:
  how the latest start was derived, step by step, nothing skipped
- Single-skill dependencies get their own subsection: list each
  one, and suggest who should shadow-learn it this week
- One summary line: counts per class

Constraints:
- Do not rewrite the schedule - the audit finds problems; the
  scheduling decision is mine
- Information I did not give you (e.g. who privately said they
  cannot work before dawn) gets marked "no data, not checked,"
  never guessed
- Shifts with no problems are never output; no "the rest looks
  reasonable"
- No "optimize staffing" or "make scheduling more scientific"

Why it is written this way

What makes breakfast-shop scheduling distinct is that the opening task chain has a rigid time order: soak beans, grind, boil; mix dough, proof, wrap, second proof, steam. Every link has a latest-start time, so a full headcount does not mean a functioning chain. That is why this audit focuses not on the generic "are there enough people" but on "time-of-day x skill" - the same six people arriving together at six is a completely different schedule from two arriving at four-thirty and four more at six. Back-scheduling conflicts lead the four classes because they are the failure mode unique to this trade, and nearly the only one you discover after publishing, when it is already too late.

Back-scheduling rows must show their arithmetic, and not for looks: the supervisor has to be able to verify it. If the model drops a minus sign and the supervisor reshuffles a shift over a phantom conflict, someone gets dragged in an hour early for nothing - and holds a grudge. Showing the steps makes an error visible at a glance. Single-skill dependencies get their own subsection for the same reason: grinding technique and fry-turning are crafts, not tasks. Being short-staffed means a chaotic morning; a single-skill dependency means an entire product line vanishes from the menu the day one person is sick. Forcing the output to name "who should shadow-learn it this week" gives the finding an exit, otherwise the audit is just bad news.

"Do not rewrite the schedule" comes straight from practice: an AI-rebuilt schedule is unusable - it does not know who has family obligations, which two people cannot be paired, who was promised early-only shifts. The audit's value is putting conflicts on the table and compressing each fix to a direction; the call stays human. Marking missing information as "no data, not checked" instead of letting the model assume works the same way - scheduling is an ongoing relationship between people who see each other daily, and one wrong guess about a person's constraints means nobody bothers correcting your table next week.

Finally, "shifts with no problems are never output." A weekly table has dozens of shifts; listing the green ones alongside the red dilutes the red. The audit should be short enough to scan in a minute - counts per class, which shifts to move first - or nobody will bother running it in the ten minutes before publishing.

Variables