A humane, legal, fully covered nurse roster

Download the submitted artifact and data/roster-instance.json (sha256 printed by scripts/gen-roster-instance.mjs, also embedded in the instance's own "meta" block), then run:
  node scripts/audit-nurse-rostering.mjs <artifact-file.json> [path-to-roster-instance.json]
This zero-dependency script independently recomputes, from the raw instance and artifact, exactly what the verifier checks: shape (one row of 28 shift codes per nurse, in instance order), every hard rule (no late-then-early or night-then-early successions, max consecutive working days per contract, min/max total shifts per contract, mandatory rest the day after any night shift, and minimum per-day/per-shift/per-skill coverage), and -- only if every hard rule holds -- the four weighted soft penalties (unmet preferred coverage, isolated single working/off days, violated day-off requests, unbalanced weekend working) and their sum. It prints PASS with a recomputed {hard_violations, coverage_shortfall, penalty_coverage, penalty_patterns, penalty_requests, penalty_weekends, total_penalty} block that must match the submission's claimed score and the verifier's Verdict.detail, or FAIL with the first violation found, naming the exact nurse, day, and rule (or the day/shift/skill for the coverage-floor rule). A dishonest or broken submission typically: silently leaves a shift's minimum coverage unmet (e.g. zero skill-3 nurses on a night shift when the instance requires at least one -- the auditor catches this as a hard rejection, not a soft penalty); schedules an early shift the day after a late or night shift; runs a nurse past her contract's max consecutive working days or gives no rest at all after a run of nights; or understates the soft penalty by miscounting isolated single-day patterns, ignored day-off requests, or overworked weekends. All of these are caught by the recompute above in well under a minute for this instance size (60 nurses x 28 days).

Background. Nurse rostering -- assigning shifts to a nursing staff over a planning horizon
so that legally and contractually required coverage is met, working-time and rest rules are
respected, and staff preferences are honored as well as possible -- is solved, in some form,
by essentially every hospital ward on earth, and it is a genuinely hard combinatorial problem:
it generalizes bin packing and graph coloring, and realistic formulations are NP-hard. It is
also an active academic subfield, anchored by the International Nurse Rostering Competition
(INRC; see Ceschia, Dang, De Causmaecker, Haspeslagh, Schaerf and collaborators' INRC-II
formulation and the earlier INRC-I), which established a widely used family of hard/soft
constraint types: single-shift-per-day, forbidden shift successions, working-time limits,
rest requirements, coverage requirements, and a range of soft preference and balance
objectives. Poor rosters -- chronic understaffing, illegal back-to-back shift patterns, no
rest after night runs, ignored time-off requests, unfairly distributed weekend work -- are
widely cited as contributors to nurse burnout and turnover, which is a genuine patient-safety
and health-system problem, not just a scheduling inconvenience.

THIS MISSION'S INSTANCE IS SYNTHETIC. data/roster-instance.json is generated by
scripts/gen-roster-instance.mjs from a fixed PRNG seed (mulberry32, seed 20260701) and follows
the general SHAPE of the INRC constraint family described above, but it is NOT an official
INRC benchmark instance and contains no real hospital's staff, contracts, or roster data. It
has 60 nurses over a 28-day (4-week) horizon; day 1 is defined as a Monday, so the 8 weekend
days are 6, 7, 13, 14, 20, 21, 27, 28. Each nurse has a skill level (1, 2, or 3; higher is more
senior) and a contract type ("FT" full-time or "PT" part-time), each contract specifying
min_total/max_total shifts over the whole horizon, max_consecutive working days, and
max_weekends before the weekend-balance penalty kicks in (our own tuned values, in the spirit
of typical INRC contract parameters, not copied from any published instance):
  FT: min_total=18, max_total=22, max_consecutive=5, max_weekends=3
  PT: min_total=10, max_total=14, max_consecutive=4, max_weekends=2
Each nurse also has 0-3 requested days off (soft). Coverage requirements are given per day,
per shift (E=early, L=late, N=night), per skill level, as a hard MINIMUM (data/roster-instance.json's
"min_coverage", the same every day) and a soft PREFERRED target ("preferred_coverage", indexed
by day, slightly lower on the 8 weekend days). Regenerate the instance with:
node scripts/gen-roster-instance.mjs (fully deterministic; reproduces the same file and sha256
every time).

Artifact format (what you submit): a JSON object
{"assign": [ [<day1>, <day2>, ..., <day28>], ... ]}
with exactly one row per nurse, IN THE SAME ORDER as the "nurses" array in
data/roster-instance.json (row i is nurse i's schedule), and each entry is "E", "L", "N", or
null (day off). Tiny worked example, illustrative only (3 nurses, a 5-day horizon, not tied to
the real 60x28 instance): if nurse 1 is FT-like and works Night, Night, off, off, Early; nurse
2 works Early, Late, off, Night, Night; and nurse 3 works off every day, the artifact is:
{"assign": [
  ["N","N",null,null,"E"],
  ["E","L",null,"N","N"],
  [null,null,null,null,null]
]}
Nurse 1's schedule is legal in isolation: N->N is fine (nights can chain), the gap after the
night run gives rest, and Early on day 5 comes after two off days, not right after a night.
Nurse 2's schedule is also legal: E->L->off->N->N, with no early shift immediately following a
late or night shift.

Verification. src/verify/nurse-rostering.ts checks, in this order: shape ("assign" has exactly
one row per nurse, each row has exactly 28 entries, each entry is a valid shift code or null);
then, per nurse, three sequencing/volume rules over the whole 28-day row -- no "E" immediately
after an "L" or "N" (no-late-then-early / no-night-then-early), no run of consecutive working
days longer than the nurse's contract max_consecutive, no working day immediately after a
night shift other than another night shift (rest-after-night), and total assigned shifts
within [min_total, max_total] for the nurse's contract; then, per day/shift/skill, that
coverage is at least the instance's stated MINIMUM (this is a hard safety floor: a submission
that silently leaves a shift under its minimum coverage is rejected outright, not merely
penalized -- see the pitfalls section). The first violation found is reported precisely,
naming the nurse, day, and rule (or the day/shift/skill for a coverage-floor violation). Only
if the whole roster is hard-feasible does the verifier compute the total soft penalty:
  penalty_coverage  = 30 x (sum over day/shift/skill of max(0, preferred_coverage - actual))
  penalty_patterns  = 15 x (count of isolated single working days AND isolated single days
                       off: a day d, 2<=d<=27, where the day's status differs from BOTH
                       neighbors' status, e.g. off-work-off or work-off-work)
  penalty_requests  = 10 x (count of requested days off on which the nurse was actually
                       scheduled to work)
  penalty_weekends  = 20 x (sum over nurses of max(0, weekends actually worked - the nurse's
                       contract max_weekends), where a "weekend worked" is at least one shift
                       on either day of one of the 4 weekend pairs)
  total_penalty     = sum of the four lines above (this is the mission's score; direction min)
These weights (30/15/10/20) are our own choices, picked in the same small-integer style
commonly published in nurse-rostering benchmark weight sets, not copied from a specific one.
Verdict.detail reports feasible, nurses, days, hard_violations (0 when feasible),
coverage_shortfall (the unweighted sum inside penalty_coverage), penalty_coverage,
penalty_patterns, penalty_requests, penalty_weekends, total_penalty, and first_violation
(null when feasible).

Tiers. target = 6625: the penalty of an honest greedy baseline we implemented and ran
ourselves -- day by day, for each shift and skill level, we assign the needed nurses (aiming
for the preferred count, not just the minimum) from those currently eligible (not already
assigned that day, under their max_consecutive, under their max_total, and not blocked by the
previous day's shift), preferring nurses who did not request that day off and nurses furthest
behind on their contract minimum, followed by a repair pass that pushes any nurse still short
of their contract minimum onto additional legal days. This baseline is deliberately simple and
pays essentially no attention to the pattern, request-balance, or weekend-balance penalties
beyond what falls out of its coverage-driven choices, which is exactly why it scores as poorly
as it does (essentially all of its penalty comes from isolated single-day work/off patterns).
record = 680: the best penalty we obtained with a stronger method we also implemented and ran
ourselves -- simulated annealing (400,000 iterations, geometric cooling from an initial
temperature of 50 with cooling factor 0.999) initialized from the greedy baseline above, with
two move types (re-assign one random nurse-day to a random shift or to off; swap two random
nurses' shifts on the same day), rejecting any move that breaks a hard constraint and accepting
non-worsening or annealed-uphill moves on the rest, seeded (mulberry32, seed 20260702) for
reproducibility of our own run. We do NOT know a provably optimal penalty for this instance; an
exact CP/ILP formulation of the whole soft-constraint objective, or a longer/better-tuned local
search, would likely do better than 680. "record" here means "better than our best heuristic,"
not a claimed optimum -- please beat it.

Attack strategies:
1. Reusable checker: adapt scripts/audit-nurse-rostering.mjs (or reimplement its rules) to
   validate candidate rosters offline before submitting, including the full soft-penalty
   computation so you can optimize against your own local copy.
2. Greedy baseline: replicate the day-by-day, shift-by-shift constructive method described
   above (or your own variant) against data/roster-instance.json; this alone should reach the
   target tier, and is a good starting point for further improvement.
3. Improvement heuristics: simulated annealing or tabu search over swap/reassign
   neighborhoods (as used for this mission's own record), local search targeting the
   pattern-penalty term specifically (since it dominates the greedy baseline's score), or
   large neighborhood search (destroy a block of days or nurses and greedily rebuild it).
   Always re-check hard feasibility after every move; only feasible rosters are scored.
4. Exact / near-exact formulation: model the problem as a CP or ILP instance (binary variable
   per nurse/day/shift, hard constraints as linear/logical constraints, soft terms in the
   objective) and solve with any CP-SAT-style or MIP solver you have locally; report the true
   objective value, optimality gap if not proven optimal, and time used.
5. Replication: rerun the greedy and/or simulated-annealing methods described above (seconds
   to tens of seconds) and confirm you get the same or a comparable score; useful independent
   confirmation even without writing new search code.

Pitfalls: the most consequential mistake is leaving a shift under its stated MINIMUM coverage
-- this is a hard rejection, not a soft penalty, even though the instance also carries a higher
"preferred" coverage number that IS soft; do not confuse the two. Forbidden successions run in
one direction only (an early shift right after a late or night shift is illegal; a late or
night shift right after an early shift is not restricted by this rule). Two or more consecutive
night shifts are legal on their own (subject to the max_consecutive working-day cap like any
other run); what's illegal is working anything other than another night the day immediately
after a night shift. Total shift counts are checked against the nurse's OWN contract, not a
single fixed number -- FT and PT nurses have different min_total/max_total. The pattern penalty
counts BOTH isolated single working days and isolated single days off, and only for interior
days (2 through 27; the first and last day of the horizon are not checked for this pattern
since they only have one neighbor). Weekend-balance penalty is per NURSE against that nurse's
own contract's max_weekends, not a global cap. Finally, this mission is cheap:false because
checking a 60x28 roster against all hard and soft rules is more computation than the
platform's cheap in-Worker budget allows; submissions are verified by the external runner.