Fleet Maintenance: Service Intervals, Work Orders and Forecasts

Fleet Maintenance: Service Intervals, Work Orders and Forecasts

You've joined the depot-systems team at a delivery company. Their fleet maintenance tracker decides when each van is due for service, tracks the shop's work orders and parts, and tells dispatch which vans may go out. Last week two vans went out with lapsed services and a parts count drifted from the shelf. You'll fix what ops reported, finish the work-order and dispatch rules, and then absorb a requirements change from the fleet manager.

Codebase

How your code is run

run(operations: list[list]) -> list executes the operations in order against a fresh depot and returns one result per operation. Every operation is [name, date, ...args]. date is the day the operation happens, a "YYYY-MM-DD" string, and never decreases from one operation to the next. Errors are returned as strings ("error: <code>"), never raised.

• An unknown operation name returns "error: unknown operation". A date that is not a real calendar date in YYYY-MM-DD form, or a wrong number of arguments, returns "error: invalid arguments".
• Vehicle ids, part names and work-order ids are case-sensitive strings.
• A *reading* is a whole number of miles >= 0 (true/false are not numbers).
• Dates in results are YYYY-MM-DD strings.

Part 1 operations (all but due return the value shown)

Part 1: Fix the "due" report (INC-4417)

Goal: make due (and the readings behind it) follow the rules below. Ops reported: a van was flagged merely "due soon" when its oil change was a day late; a van with a swapped odometer showed nonsense mileage; the 6-month interval from a Jan 31 service landed on the wrong day; and a driver's second reading of the same mileage was rejected.

Rules

1. Service types and intervals live in fleet/config.py (oil_change 5000 mi / 6 mo, tire_rotation 7500 / 12, brake_service 30000 / 24, safety_inspection 12000 / 12). A service is due when either limit is reached, whichever comes first: interval_miles driven or interval_months elapsed since it was last performed.
2. A new vehicle counts as having had every service type performed on its registration date at its registration reading.
3. Lifetime miles never go backwards. odometer accepts a reading >= the current one (an equal reading is fine) and rejects a lower one with odometer decreased. replace_odometer records a gauge swap: the new gauge starts at the given reading, which may be lower or higher, and lifetime miles carry on unchanged (a gauge that read 80,000 and is replaced by one reading 50 means lifetime miles are still 80,000, then 80,001 at a reading of 51). After a swap, odometer readings are compared against the new gauge. Everything that measures miles (miles since a service, miles left) uses lifetime miles, never the raw gauge.
4. miles_left = interval_miles - (lifetime miles now - lifetime miles at the last service). It is negative once the limit is passed.
5. due_date is the last service date plus interval_months calendar months: same day of the month, clamped to the last day of the target month if it is shorter (Jan 31 + 1 month is Feb 28, or Feb 29 in a leap year; Feb 29 2028 + 12 months is Feb 28 2029).
6. days_left = due_date - today in days. For each of the two measures, an amount < 0 is overdue, <= 500 miles (or <= 14 days) is due soon, anything else is ok (so exactly 0 left is *due soon*, not overdue). The service's status is the more severe of the two (overdue > due_soon > ok).
7. due returns one row per service type, sorted by service name (plain string order).

Example

[["add_vehicle", "2027-08-31", "van-1", 50000],
 ["odometer", "2027-12-01", "van-1", 54620],
 ["due", "2028-03-01", "van-1"]]

returns

[true, 54620,
 [["brake_service", "ok", 25380, "2029-08-31"],
  ["oil_change", "overdue", 380, "2028-02-29"],
  ["safety_inspection", "ok", 7380, "2028-08-31"],
  ["tire_rotation", "ok", 2880, "2028-08-31"]]]

Oil change is 380 miles from its limit but its 6 months ended on 2028-02-29, so it is overdue today.

Part 2: Work orders, parts and grounding (OPS-912)

Goal: the shop opens a work order for a service, reserves the parts it needs, then closes it (parts fitted, service recorded) or cancels it (parts go back on the shelf). Parts counts must always match the shelf. Dispatch must refuse vans whose safety inspection has lapsed.

Rules

1. available = on_hand - reserved. stock adds to on_hand. A part never stocked reports [0, 0, 0].
2. parts is a list of [part, quantity] lines (it may be empty); a line that isn't a 2-item list of a non-empty string and an int > 0 makes the whole list invalid parts. Lines naming the same part are summed before anything else happens.
3. Opening reserves every part, all or nothing: if any part's total exceeds its available (a part never stocked has 0), return insufficient stock and change nothing, including the id counter.
4. Work-order ids are WO-1, WO-2, ... in the order orders are opened successfully.
5. A vehicle can have only one open work order per service type (service already open); other vehicles, or a service whose earlier order is closed or cancelled, are unaffected.
6. close_wo fitting the parts: each reserved unit leaves both reserved and on_hand. It also records the service as performed on the close date at the vehicle's current lifetime miles, exactly like service (so it resets that interval). The order is then closed.
7. cancel_wo releases every reservation (reserved drops, on_hand is unchanged); no service is recorded. Only an open order can be closed or cancelled.
8. A vehicle is grounded when its safety_inspection (the type named by GROUNDING_SERVICE) status is overdue on the dispatch date. A grounded vehicle gets vehicle grounded; any other vehicle, including one that is only due_soon, is dispatched. Dispatching changes nothing.

Example

[["add_vehicle", "2026-01-10", "van-1", 1000],
 ["stock", "2026-01-10", "oil-filter", 3],
 ["open_wo", "2026-02-01", "van-1", "oil_change", [["oil-filter", 2]]],
 ["stock_report", "2026-02-01", "oil-filter"],
 ["cancel_wo", "2026-02-02", "WO-1"],
 ["stock_report", "2026-02-02", "oil-filter"],
 ["dispatch", "2027-01-10", "van-1"],
 ["dispatch", "2027-01-11", "van-1"]]

returns

[true, 3, "WO-1", [3, 2, 1], true, [3, 0, 3], true, "error: vehicle grounded"]

(Registered 2026-01-10, the 12-month inspection is due on 2027-01-10: still only "due soon" that day, overdue the day after.)

Part 3: Requirements change: bundles and projected due dates (FLEET-77)

The fleet manager wants shop packages and a planning view. Two things change.

3a. Service bundles

A bundle performs several service types at once. fleet/config.py gets:

1. service and open_wo accept a bundle name wherever they take a service name. Performing a bundle records every component as performed on that day at the current lifetime miles (each interval resets). A name that is neither a service nor a bundle is unknown service.
2. A bundle work order, when closed, records all its components. When cancelled it records nothing. The parts on a bundle order are just the parts list given, reserved and consumed once.
3. This replaces Part 2 rule 5. A vehicle can no longer have two open work orders that share a component service type: opening A while oil_change is open (or annual while A is open, or tire_rotation while A is open) returns service already open. brake_service alongside A is fine.
4. Everything from Parts 1 and 2 still applies to bundles' components: closing an annual order on a grounded van un-grounds it.

3b. Forecasts

1. Reading history. Every reading is logged with its date in lifetime miles: the registration reading (on its date), every accepted odometer reading, and every day of a drive. replace_odometer logs nothing (lifetime miles don't change).
2. drive logs one reading per day for days consecutive days starting on date, where the gauge increases each day by the next number of pattern, repeating the pattern from the start if days is longer. days must be an int >= 1 and pattern a non-empty list of ints >= 0 (otherwise invalid arguments). Operations after a drive are dated on or after its last day.
3. Average daily miles on date D: look at the logged readings dated from D - 30 days through D (inclusive both ends). If there are fewer than 2 of them, or the first and last of them are on the same date, the average is 0. Otherwise average = (last_miles - first_miles) // (days between their dates), integer floor, where *first* is the earliest-logged reading in the window and *last* the most recent reading dated <= D.
4. Estimated due date for one service on date D: let left be miles_left from Part 1 and due_date the month-based due date. If left <= 0 the mileage estimate is D itself. Else if average > 0 it is D + ceil(left / average) days (integer math: (left + average - 1) // average). If average is 0 there is no mileage estimate. The estimate is the earlier of due_date and the mileage estimate (a due_date already in the past is reported as is).
5. forecast lists every service type (not bundles). next_due considers every vehicle and service type, sorts by (estimated_due_date, vehicle_id, service) and returns the first count (all of them if fewer exist).
6. Hidden tests drive dozens of vans for tens of thousands of days each and call next_due hundreds of times in one run; the whole suite gets a few seconds. Rescanning a vehicle's whole history for each call is too slow.

Example

[["add_vehicle", "2028-01-01", "van-1", 0],
 ["drive", "2028-01-01", "van-1", 5, [100, 200]],
 ["forecast", "2028-01-05", "van-1"],
 ["service", "2028-01-05", "van-1", "A"],
 ["due", "2028-01-05", "van-1"]]

returns

[true, 700,
 [["brake_service", "2028-06-21"], ["oil_change", "2028-01-30"],
  ["safety_inspection", "2028-03-10"], ["tire_rotation", "2028-02-13"]],
 true,
 [["brake_service", "ok", 29300, "2030-01-01"], ["oil_change", "ok", 5000, "2028-07-05"],
  ["safety_inspection", "ok", 11300, "2029-01-01"], ["tire_rotation", "ok", 7500, "2029-01-05"]]]

The average is (700 - 0) // 4 = 175 miles/day (registration reading 0 on Jan 1, 700 on Jan 5), so the oil change (4300 miles left) is ceil(4300 / 175) = 25 days out. After bundle A, oil change and tire rotation have reset; brake service and the inspection have not.

Notes

• dates.py and config.py are the only places that know about calendars and intervals; keep it that way.
• You may use the AI assistant freely; you are expected to verify what it produces.
• Later parts must not break earlier ones; hidden tests re-check earlier behavior after later changes.