Repository navigation
impl(fleet): work-picking jobs consult the orchestrator published priorities before choosing work #911
Closed as not planned
Description
impl(fleet): work-picking jobs consult the orchestrator's published priorities before choosing work
Gap found 2026-10-25: orchestration.json (published hourly by the orchestration-pass, contract in #899) is currently read by NO work-picking job — the issue sweeps, the code sweep, and the new-issue creator each pick work from the repo backlogs + GitHub by their own local rules. The priority ladder (today > tomorrow > next 3 days > longer goals > incoming) therefore only binds the orchestrator itself.
Change (small, bodies + one contract note):
- Each work-picking cron body gains a short "consult the orchestrator first" step: read
~/workspace/goals/keep-the-four-repos-healthy/hidden_files/orchestration.jsonwhen fresh (<2h old). Prefer NEEDS ORCHESTRATOR items and today/tomorrow-horizon linedUp tasks in its goals measurement; respect blockedBy — skip an item whose blocker has an active worker and take the next one (that is the behavior Drew specified 2026-10-25). - Fall back to the job's current picking rules when the file is stale or absent — never block a run on it.
- The orchestrator's published
actions[]already records its own dispatches; picking jobs add their pick to their existing run logs as today (no new reporting channel). - Note the contract on impl(orchestrator): recurring orchestration job — queue triage, priority ladder, blocker awareness, goal measurement #899 so the orchestrator's publisher keeps the fields the pickers depend on (tiers, goals[].linedUp[], blockedBy).
Acceptance: one run each of issue-sweep-rotating and the code sweep shows (in its log) a pick that came from orchestration.json or an explicit "consulted, nothing applicable" line; stale-file fallback exercised once.
Acceptance criteria
- Each work-picking cron body (issue sweeps, code sweep, new-issue creator) consults a fresh (<2h old)
orchestration.jsonbefore choosing work, preferring NEEDS ORCHESTRATOR items and today/tomorrowlinedUptasks and skipping items whoseblockedByhas an active worker. - A stale or absent
orchestration.jsonfalls back to the job's existing picking rules and never blocks a run. - One run each of issue-sweep-rotating and the code sweep logs either a pick sourced from
orchestration.jsonor an explicit "consulted, nothing applicable" line; the stale-file fallback is exercised once. - The contract fields the pickers depend on (tiers,
goals[].linedUp[],blockedBy) are noted on impl(orchestrator): recurring orchestration job — queue triage, priority ladder, blocker awareness, goal measurement #899.
Activity
developing-today commentedon Oct 25, 2026
CODE-151
dezren39 commentedon Oct 26, 2026
Intake review
Still live: verified this run — #899 (the orchestrator contract this builds on) is closed with
orchestration.jsonbeing published, and no work-picking job body yet consults it; the gap stands as filed. An## Acceptance criteriasection has been appended to the body (the body's own "Acceptance:" line is preserved above it).Related: #899 (closed — the publisher contract: tiers,
goals[].linedUp[],blockedBy), #910 (the sibling design+impl for the org-level Project layer, filed in the same pass).Notes / risks: the stale-file fallback is the load-bearing part — a picker that blocks or mis-picks on a stale
orchestration.jsonis worse than no consultation. Keep the change to cron bodies + the #899 contract note, exactly as scoped; no new reporting channel.Suggested approach: add the short "consult the orchestrator first" step to each work-picking cron body as specified, then let one issue-sweep-rotating run and one code-sweep run demonstrate the pick-or-explicit-nothing line in their logs.
🤖 Agent note · filed
dezren39 commentedon Nov 1, 2026
🤖 Agent note · picked up
dezren39 commentedon Nov 1, 2026
🤖 Agent note · done
Triage verdict: CONFIRMED factually, SUPERSEDED as a remedy — close, do not implement
Confirmed (fresh checks this run, 2026-11-01T02:1xZ):
orchestration.jsonis still published and fresh (generatedAt: 2026-10-31T19:16:28Z, hourlyorchestration-pass).orchestrationacross the live cron definitions ingoals/keep-the-four-repos-healthy/crons/hits only the publisher (orchestration-pass),program-tending(residue duty, Fold orchestration-pass residue into stewardship-cycle + program-tending, then retire the hourly pass #2155 step 2), and reporting consumers — zero hits in anyrepo-queue-worker-shift*lane body, anynew-issue-creator*body,issue-sweep-rotating, orpr-diff-review*. The queue-worker instruction (§1, read in full this shift) picks solely by atomic queue claim; no orchestration step exists.Why implementing #911 as written would now be wrong:
queue/queued) are actively retiringorchestration-passitself — residue folds intostewardship-cycle(cross-queue priority calls, which is the successor of this issue's intent) andprogram-tending, retirement last. Building picker-dependence onorchestration.jsonfields (tiers,goals[].linedUp[],blockedBy) directly contradicts that in-flight direction, and the impl(orchestrator): recurring orchestration job — queue triage, priority ladder, blocker awareness, goal measurement #899 contract note would be written on a contract being wound down.Disposition: closing as superseded by #2136/#2155. If the retirement is reversed, reopen — the factual gap above is the reopening evidence. No follow-up fix packet enqueued, deliberately: a packet implementing the original remedy would conflict with #2155's live work.