mirror of
https://github.com/kevinveenbirkenbach/computer-playbook.git
synced 2026-11-14 06:37:25 +00:00
kevinveenbirkenbachandClaude Opus 5
5d53c46c1f
A retrigger started the regular line at the head again, redeploying the exact window the source run had already judged. The red rows come back on the priority line anyway, so that window was runner time spent on questions with an answer. The offset is computed now: the last row of the leading run of rows the source run reached, as a selection token. Green or red does not matter -- what matters is that the row ran. The scan stops at the first gap, because a hole inside the window means that row was filtered out, not that the run got further, and resuming past it would skip everything behind it. The ranking is recomputed under the configuration the retrigger carries, since that is the list the offset resolves against. The priority line is left out of that computation on purpose: it only blacklists rows from the regular query, and a token in it that no longer resolves would abort the very helper whose job is to save time. offset therefore joins priority as an input the retrigger decides rather than carries. The integration test forced that: it asserts every carried input arrives unchanged, and offset no longer did. The category was wrong, not the test. Costs a full local discovery per retrigger. There is no cheaper answer -- jobs inside a chunk are sorted by name, so how far a run got cannot be read off the job list without the ranking. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Integration Tests 🔗
See integration.md for the SPOT: framework, requirements, directory structure, and make test-integration usage.