Use Gemini's extended reasoning to solve a real multi-constraint scheduling problem

PROBLEM
building a two-week on-call rotation for an 8-person engineering team

HARD CONSTRAINTS (a violated one makes the whole schedule invalid)
no one is on-call two weekends in a row; nobody is scheduled during their stated vacation dates; every shift needs exactly one primary and one secondary

SOFT PREFERENCES (optimize for these on a best-effort basis, but never at the expense of a hard constraint)
try to balance total on-call hours roughly evenly across the 8 people over the two weeks, and avoid putting the same two people on together twice if it can be avoided

PEOPLE AND DATA
the 8 names, each with their specific vacation dates and any standing preference already noted (e.g., Priya prefers not to be primary on weekends)

INSTRUCTIONS
1. Think through this as a genuine constraint-satisfaction problem, not a single confident pass — generate a candidate schedule, then actively try to find a way it fails before presenting it.
2. After producing a candidate schedule, explicitly check it against every hard constraint listed above, one by one, and only present it as final if all of them pass — if one fails, revise and recheck rather than presenting a schedule you haven't actually verified.
3. If you find a hard constraint violation during verification, don't patch just the one broken slot in isolation — re-check whether your fix creates a new violation elsewhere, since a schedule this constrained often has fixes that ripple.
4. If a genuinely impossible combination of hard constraints exists, — for example, everyone who could cover a specific weekend is on vacation that same weekend — say so explicitly rather than silently violating one constraint to produce a schedule that looks complete. Naming the actual conflict is more useful than a schedule I'd have to re-verify myself before trusting it.
5. Once you have a schedule that passes every hard constraint, note how well it satisfies the soft preferences and where it fell short, so I know what a human might want to adjust by hand.

IF THE FIRST CANDIDATE SCHEDULE FAILS VERIFICATION
Don't discard the whole candidate and start over from scratch by default — first check whether a small, targeted adjustment to the specific slot that failed resolves it without touching anything else, since a full restart risks losing soft-preference balance you'd already achieved elsewhere in the schedule. Only rebuild from scratch if a targeted fix genuinely isn't possible given the constraints.

EXPLAINING TRADE-OFFS, NOT JUST STATING THE RESULT
Where you had to choose between two soft preferences that couldn't both be fully satisfied (balancing hours evenly versus avoiding a repeated pairing), say which one you prioritized and why, so a human reviewing the schedule understands the trade-off that was made rather than just seeing the outcome without the reasoning behind it.

IF THE PROBLEM IS UNDERSPECIFIED
If the data provided leaves a genuine gap that affects the schedule (a ninth person mentioned in passing with no stated vacation dates), ask for the missing detail before proceeding rather than silently assuming a default that could be wrong.

OUTPUT FORMAT
The final schedule as a clear table. Below it: a section titled "Verification" showing each hard constraint from above and a one-line confirmation of how the final schedule satisfies it, a "Trade-offs" section explaining any soft-preference conflicts and how they were resolved, plus a short note on any soft preference it didn't fully achieve and why.