Repository navigation
design(queue): budget-aware claiming — parks carry a minimum required time budget, claim matches the claimer's remaining shift budget #3418
Description
Proposal (Drew, 2026-11-01 ~02:26 CST)
Parks should be able to carry a minimum required time budget, and claiming should match tasks against the claimer's remaining shift budget. A task that needs a dedicated full shift should be claimable immediately by any worker that actually has the budget — instead of sitting out an arbitrary clock delay that no worker may override.
Why
The park mechanism conflates two different waits:
- External-wait — CI, a Codex review, a quota reset. Time is the readiness signal;
not_beforeis correct here. - Capacity-wait — the work is ready now; the claimer is what lacks room. Time is the wrong signal: a fresh shift starting 10 minutes later has the budget, and a shift ending in 10 minutes never will, no matter when the park expires.
Tonight's evidence: opencode task 5256 (issue opencode#1014, Drew-prioritized, expedite, effort/l, 120-min timebox) was claimed by a lane near the end of its shift, scoped, and parked 3600s purely so a future full shift would take it. During that hour no lane may claim it — the not_before gate is hard for every lane regardless of budget — and the opencode queue has a single lane anyway, so "another lane picks it up" does not exist there. The claim itself also had no budget check: the lane only discovered the mismatch by claiming first.
Design sketch
- A park (and a packet) may declare
required_budget_minutes— the minimum uninterrupted budget a claimer must have. Packettimebox_minutesis the natural default source. claim_repo_taskaccepts the claimer's remaining budget (the lane/shift computes it from its own start time and budget cap) and only matches tasks whose requirement fits. Tasks with no requirement behave as today.- Lane/shift instructions pass their real remaining budget on every claim — including the first claim of a shift (full budget) and later ones (remainder), so an oversized task is never claimed just to be re-parked.
- External-wait parks keep
not_beforeunchanged; the two conditions compose (both must pass).
Acceptance
- A capacity-parked task with
required_budget_minutes: 120is claimable immediately by a worker declaring >= 120 minutes remaining, and is skipped (not claimed, not re-parked) by one declaring less. - Lane instructions for all four queues pass remaining-budget on claim.
- Existing external-wait parks behave exactly as before.
- Worked example recorded on completion: a 5256-shaped task flowing to the first full-budget shift without a clock wait.
Cross-ref: opencode#1014 (the fix whose implementation task surfaced this).
Activity
developing-today commentedon Nov 1, 2026
CODE-1306
dezren39 commentedon Nov 1, 2026
Design input from the dsh-superagent comparison (full standalone analysis: #3450; Drew directed posting the adoptable set here, 2026-11-01). Items for THIS issue:
required_budget_minutes: budget matching decides whether a claim FITS; the reservation decides whether priority work can PREEMPT.dezren39 commentedon Nov 1, 2026
Transferred from Slack #alignment at Drew's direction (2026-11-01). Aster (@drewrypope-aster) reviewed the dsh-superagent design package (#3450 / #3424 / #3418) in the thread on Muse's 03:29 CST pass; her replies are below verbatim (formatting converted from Slack mrkdwn to GitHub markdown; wording unchanged). The identical text is posted on all three issues so each record is self-contained.
Aster's acknowledgment (03:29 CST):
I’ll review the package against the original dsh docs, focusing on genuine weaknesses, the deliberate differences worth challenging, and possible misreadings. I’ll treat Drew’s sketches as design direction and keep this to review, with findings returned here.
Aster's review (03:33 CST):
Reviewed #3450, #3424 and #3418, including their comments, against dsh docs 000–008. My conclusion: the shared architecture is real, but “same path, mostly plumbing to borrow” understates their strongest advantage. Their docs specify ownership and recovery across transitions more precisely. Our proposed schema is richer in some areas, but records alone do not establish those guarantees.
This is a documentary design review, not a runtime audit of either system. I would distinguish “implemented,” “proposed,” and “verified” rather than count “have (in design)” alongside shipped capabilities.
Where I would correct the comparison
• Merge authority: dsh does not categorically require humans to merge. Its Executor can enable auto-merge through another explicitly named account’s CLI. Human merge is the fallback. The real comparison is attribution and readiness safeguards: their defaults require an own-Ticket PR, approvals covering the head, fewer than 200 changed lines, and withdrawing auto-merge before a new revision. Keep delegated merge authority, but compare its safeguards rather than calling it an inversion. 003: Merging
• Observe-first: they explicitly permit graduating to auto. Our mature-auto posture plus observation for new or materially changed producers is compatible. Their mode is Policy-level; per-producer modes are our adaptation. Explicit requests work in every mode, which matters when defining what “off” means. 002: Accept modes
• Reserved capacity: their extra slot lets a human message/status request continue an existing Ticket and precedes new launches. It does not interrupt active work or give a newly queued expedited task a full shift. #3418’s proposal is a new scheduling policy, not direct adoption. Raising a bundle cap cannot give a worker with ten minutes left the 120 minutes a task needs. 003: Concurrency
• Expiration: the 24-hour/latest/undismissed rule applies to unavailable Eval Decisions shown for attention, not all unanswered Attention questions. Do not age out Drew’s pending decision by importing it. 002: Unavailable Decisions
• Storage and reconstruction: dsh describes aggregate JSON rows with generated working-set columns, not normal-form consensus. Retained Decisions/dispositions also do not establish full historical state reconstruction. #3424’s “resurrect any moment” is a stronger proposed contract with its own proof burden. 007: Persistence
• Waiting and escalation: they reject Eval scheduling delayed Triggers, not all persisted timers in the core. Queue-native not_before is compatible with that separation. Likewise, one concrete question can include options, consequences and a recommendation. Their questions return through chat too; this is not “panel questions versus substantive chat.” 001: Rejected concepts, 004: Prompts
Where our design needs stronger contracts
Pushback on the deliberate differences
Keep fresh shifts, phone-friendly chat/GitHub, and queue-native waits. But fresh context does not itself guarantee no compaction or no waiting; those require actual runtime bounds. Per-task workspace isolation also does not require a long-lived session.
I would narrow “GitHub-canonical” to human discussion and code artifacts, then state authority per field. Queue leases, admission decisions, skipped inputs and pending effects are not automatically auditable from the repo because notes are mirrored. Define reconciliation and avoid two competing sources of truth.
Do not copy dsh’s trust model wholesale: its workers run as the operator OS user, and the docs explicitly say wrappers/directories are not a security boundary. Its live Mandates also survive Policy changes, with notifications rather than automatic revocation. Those are tradeoffs to examine, not safety guarantees to inherit. 006: Isolation
Five acceptance cases I would put ahead of implementation splitting
• Cancel the task representing a blocking issue and close its resolving PR unmerged: the dependent remains blocked.
• Open Q1, append a finding, supersede it with Q2, then receive Q1’s late/duplicate answer: Q2 remains correctly unanswered and work does not resume twice.
• Present an expedited 120-minute task to a worker with ten minutes left: no cap override claims it; a fresh eligible worker can.
• Crash after GitHub accepts an effect, then resume the old worker after lease reassignment: reconcile delivery and reject stale ownership writes.
• Evaluate inferred work in auto, switch to observe before acceptance, then replay the event: no stale acceptance or duplicate execution.
My recommendation is to retain the overall direction and revise the comparison before using it as design justification. Prioritize authority/ownership, atomic transitions and recovery, then structured attention and blocker semantics. The detailed link model and budget matching remain promising fleet-specific contributions; their value needs to be demonstrated by those failure cases. No implementation or issue changes made.
dezren39 commentedon Nov 3, 2026
🤖 Agent note · picked up
dezren39 commentedon Nov 3, 2026
🤖 Agent note · parked
193 remaining items
dezren39 commentedon Nov 6, 2026
🤖 Agent note · handed off
dezren39 commentedon Nov 6, 2026
🤖 Agent note · handed off
dezren39 commentedon Nov 6, 2026
agent-note:v1
task: 9570
lane: c29174f1-48e0-4b13-b4ff-9b73ab67e9ab
state: picked-up
issue: #3418
at: 2026-11-06T10:42Z
Claimed task 9570 for fresh triage. Current GitHub check: #3418 is OPEN with no hard-stop labels. The packet appears internally inconsistent: its issue field/title identify #3418, while scope, evidence, and context refs identify #3205; I am verifying the packet defect before any task work.
dezren39 commentedon Nov 6, 2026
agent-note:v1
task: 9570
lane: c29174f1-48e0-4b13-b4ff-9b73ab67e9ab
state: blocked
issue: #3418
at: 2026-11-06T10:47:54Z
reason: packet_defect
Task 9570 is blocked because the packet conflicts about its target: task/title/issue identify #3418 (budget-aware claiming), while scope.include, evidence, context_refs, and the problem narrative identify #3205 (per-repo hygiene census). Fresh GitHub checks confirm #3418 and #3205 are different OPEN issues. No safe way to infer intended work; please correct the packet target and retry/re-enqueue. No code changes or follow-up task created.