mirror of
https://github.com/kevinveenbirkenbach/computer-playbook.git
synced 2026-11-08 11:46:35 +00:00
The regular rows began wherever (sweep * capacity) % count pointed. On run 210 that was offset 68: chunk 0 opened at candidate 69, the coverage-first head of the list went undeployed, and no two runs could be compared because the window moved with the run number. A run that looked wrong turned out to be merely rotated, and finding that out meant recomputing the arithmetic by hand. The rotation is gone. Chunk 0 reads the ranking from the top unless an offset says otherwise, and the offset is an input now, threaded from the manual form through the orchestrator and the deploy call down to the matrix builder. The plan renderer takes the same flag, so the table shows the window the run will take. The offset is a row count or a selection token. A token is the honest form: the ranking shifts whenever a variant appears, so 'offset 84' means something different tomorrow while 'web-app-nextcloud#5' still means the same row. Axes the token leaves open match anything, so a bare role name starts at its first row and a pasted job label starts at exactly the job it names. A token that matches no regular row aborts rather than silently starting at the head an operator meant to skip. The run title carries it as ⏩ followed by the value, and only when one was asked for, so a rotated-looking run says so in its own name and the retrigger reads it back from there when a job log has expired. resume_from_chunk leaves the manual form with it. Skipping whole chunks was the coarse way to say 'carry on further down'; the offset says it exactly and keeps the rest of the chain intact. The orchestrator input stays for the other entry points. What this gives up is automatic tail coverage. Rows beyond the budget are reached by moving the offset, widening the budget or narrowing the selection, not by waiting for consecutive sweeps to walk the list. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>