Last-Light Relay

Вернуться к Superbench 2.0 · Тестовый контракт и критерии оценки. Опубликована одна записанная оценка для этого краткого описания; откройте страницу краткого описания для артефакта и записи сессии для её пределов. Одно сообщение пользователя, один HTML-ответ; без инструментов или корректировок. Не добавляйте руководство оператора версии 1.x.

# 19. Last-Light Relay

Build a complete planning-and-execution instrument for restoring a fictional island relay station before nightfall, in one self-contained HTML file: compute an optimal resource-feasible schedule, play through its consequences, then replan around a crane closure without rewriting work already started.

This is a tool-free, single-response build. Do not browse, execute code, call tools, ask questions or request approval. Reason privately, inspect your source and return only the finished HTML document. Do not claim browser validation; a reviewer runs the checklist afterward.

## Required features

### 1. Precisely defined work

Time is integer ticks, with a horizon from 0 to 16. There are two identical crew units and one crane. Tasks are nonpreemptive. A task starting at s with duration d occupies resources on [s,s+d); it releases resources exactly at s+d. Every predecessor must finish no later than the task's start. All eight tasks are mandatory:

ID | Task | Duration | Crew | Crane | Predecessors
A | Survey | 2 | 1 | 0 | none
B | Clear dock | 3 | 1 | 1 | A
C | Drain vault | 2 | 1 | 0 | A
D | Lay cable | 2 | 1 | 0 | B
E | Raise mast | 2 | 1 | 1 | B,C
F | Calibrate | 1 | 2 | 0 | D,E
G | Light beacon | 1 | 1 | 0 | F,H
H | Fit battery | 2 | 1 | 0 | C

Allow editing each duration to integers 1–3 and a single crane-unavailable interval [u,v), with integer endpoints 0≤u≤v≤16; u=v means no closure. Default is no closure. Other task properties remain fixed. A crane task cannot overlap the closure at all. Invalid edits must not change the accepted configuration. Valid edits invalidate any old schedule and reset execution to t=0; prohibit these edits while playing or while a frozen-history replan is pending.

### 2. An exact, inspectable planner

Find a schedule that finishes every task by tick 16 and minimizes the finish time of G. Any equally optimal schedule is acceptable. Search the complete finite domain with sound pruning, not a greedy answer labeled optimal. If none exists, say “No feasible schedule within 16 ticks”; do not claim impossibility beyond the horizon.

Show every task's start/end, a Gantt chart, per-tick crew/crane occupancy, predecessor checks and the final completion time. An explanation must identify the binding constraints, with an honest statement of the exact search method. Include a selectable JSON export of configuration, schedule, execution time and frozen tasks. All displays and execution must use the same accepted schedule.

Offer a manual start-time editor and Validate action for all eight tasks. Validate reports every precedence, resource, closure, domain and horizon violation without silently moving tasks. A valid manual schedule may be simulated but must be labeled “manual; optimality not established” until independently solved. Do not use the validation label as a substitute for optimization.

### 3. Execute, freeze and recover

Provide Play/Pause, one-tick Step and Reset execution. Play advances one tick per second to completion; reduced motion changes visuals only. At time t, tasks ending at t are complete, tasks with start≤t<end are running, and the rest are pending. The diagram must reflect actual task status, with an unlit beacon until G completes.

Provide a preset demonstration: restore default durations, solve with no closure, then execute to exactly t=4 and pause. A “Crane closure [5,7)” action freezes every task whose start is strictly less than 4 at its original start/end, introduces that closure, and replans pending tasks from t≥4. A task scheduled to start exactly at 4 is not frozen. Preserve the execution time and completed/running history. This action is available only in that paused default demonstration at t=4. If a frozen crane task overlapped a newly introduced closure, the general validation logic would report infeasibility rather than moving it, although this preset has no such conflict.

The frozen-history solver minimizes G's finish time under the new restrictions and the same horizon. Display before/after schedules and the frozen set. Playback after recovery follows the new pending schedule. A Reset scenario action restores default durations, no closure, no schedule and t=0. Reset execution only rewinds the currently selected schedule; after a recovery, it also clears the comparison/frozen-history mode and treats that schedule and closure as a normal scenario.

### 4. Visual clarity

Show a code-drawn island station with distinct dock, vault, cable, mast, battery and beacon states, linked to selected Gantt tasks. The time grid and resource strips must be numerical as well as color-coded. Explain constraints in plain English; no fake “AI analysis” panel. Support every control by keyboard, visible focus, 390px responsive stacking, reduced motion and light/dark preference.

## Output constraints

Return only one raw index.html document with inline CSS and JavaScript. No Markdown fences or extra prose. No libraries, external assets, fonts, imports, network requests, server or build step. Native HTML/SVG/Canvas only, opening over file://, with lang="en". No precomputed-only solver or fixed scripted schedule. Keep the interface responsive during search by yielding work or equivalent scheduling; stale searches must never overwrite newer accepted inputs. Export is selectable text within the page.

## Loop / validation rule

Do not stop drafting until the complete implementation satisfies source-level review of these checks. Use no tools and do not claim to have executed them. The reviewer will:

1. Open offline and inspect the full task table, instructions, island and empty schedule. Use all controls with keyboard, mobile layout, reduced motion and both color schemes.
2. Solve defaults: the optimum finish is 10. One valid witness is A[0,2), B[2,5), C[2,4), H[4,6), D[5,7), E[6,8), F[8,9), G[9,10). Verify every per-tick resource strip and predecessor against the chart/export.
3. Check why 9 cannot work: B cannot finish before 5, so D and E cannot finish before 7. Finishing G by 9 forces F[7,8) and both D,E[5,7). H cannot start before 4, cannot share [5,7) with D and E, and cannot overlap the two-crew F; thus H cannot finish by G's latest start at 8. An equivalent correct lower-bound argument is acceptable; do not merely print “optimal”.
4. Manually place D and E both at 5 and H at 4 with the other witness times unchanged: report crew over-allocation during [5,6). Set a predecessor-dependent task before its predecessor finishes and report it. Negative/noninteger starts and ends beyond 16 must also fail validation. Correct the schedule and simulate it.
5. Run the default t=4 demonstration, then apply closure [5,7). A,B,C must retain their executed start/end. The new optimum is 11. A witness is A[0,2), B[2,5), C[2,4), D[5,7), E[7,9), H[7,9), F[9,10), G[10,11). B finishing at closure start 5 is legal; E beginning at closure end 7 is legal. E cannot finish earlier than 9, so F then G cannot finish before 11.
6. Resume after recovery. The beacon lights only at G's actual end. Pause, Step and Reset execution must not duplicate completion or preserve an incompatible old status. Inspect before/after exports and frozen set.
7. Reset scenario and set closure [0,16): no schedule fits because mandatory crane tasks cannot run. Restore no closure, change durations within 1–3 and verify the solver uses them. Try an invalid duration/closure and preserve the last accepted configuration. Start a new solve/reset while earlier search is pending; stale results must not replace current state.

If any check fails during source review, fix it and mentally repeat all checks before returning the single artifact. A later browser failure counts against this attempt; no repair turn is provided.