Repository navigation
implement: placement framework v1 — machine-readable decision table + placement record on fleet dispatches (from #2024) #4986
Description
From the placement-framework v1 synthesis on #2024 (design doc PR linked there).
What
Encode the v1 decision table as a machine-readable placement policy artifact, and require a placement record on every fleet dispatch (queue claim handoff, dispatcher launch, scheduled-job creation):
option— one of: Muse, github-action, github-action-jules, opencode-session, opencode-scheduled, aster-codex, openclawrule— the decision-table rule id that selected the option (orexception+ exception id)pool_read_at— timestamp of the quota read the placement relied on (the ≤60-minute measurement gate), orn/afor non-pool options (Actions minutes, Jules)supervision— who babysits/reviews the result
Why
The framework is only real if placements are recorded against it: without a record there is nothing to audit, and placement stays by habit — the exact problem #2024 exists to fix. Pool mechanics themselves are #1157 / epic #1149; this issue is the cross-option decision layer above them, not a duplicate.
Acceptance
- Policy artifact (table as data, e.g. YAML/JSON beside the framework doc) that a dispatcher can consume without parsing prose.
- Placement record emitted for at least the queue-worker handoff path and the OpenChamber dispatcher path.
- A PoC on ONE dispatch path first, reviewed before any permanent rollout (per the design: task-placement framework v1 — decision rules and a shared-pool efficiency model #2024 program rule: never build the permanent feature on an unreviewed PoC).
- Weekly audit sample: placements vs. the table, exceptions listed with their exception ids.
Metadata
Metadata
Assignees
Labels
An agent touched this without the required agent-note comment or labels; needs review of whyHas a queued task in the Supabase agent queueFiled by the new-issue-creator jobNot yet triaged; needs a first lookQueue packet kind: verify, reproduce, and route this itemNeeds a user-look: Muse reviews first and handles what it can
Activity
developing-today commentedon Nov 3, 2026
agent-note:v1
state: reviewed (coverage loop-back)
Coverage pass 2026-11-03, loop-back review: this issue was re-reviewed (drift / overlap / already-handled / stale / blockers / ordering) so every open issue in the four repos is reviewed and in the system. Verdict: still live; in the system as task 8569 (triage, queued, priority 40) in repo-health-code-pilot. Labels audited and synced. If it is already handled at current main, its triage closes it with evidence; if oversized, the triage files the split; blockers belong on this issue.
Found via: coverage loop-back 2026-11-03
dezren39 commentedon Nov 3, 2026
agent-note:v1
state: handed_off (task 8569)
dezren39 commentedon Nov 3, 2026
🤖 Agent note · handed off
opencode, so the task is handed off to the opencode claimant, which launches a bound session to triage issue implement: placement framework v1 — machine-readable decision table + placement record on fleet dispatches (from #2024) #4986 at current main.15 remaining items
dezren39 commentedon Nov 4, 2026
🤖 Agent note · handed off
opencode, so this task is handed off — the laptop claimant launches the bound opencode session, which drives task 8569 to its terminal state. Fresh check this shift: issue implement: placement framework v1 — machine-readable decision table + placement record on fleet dispatches (from #2024) #4986 is OPEN with no hard-stop labels; it carriesuser/review, which is Muse's lane first — the bound session should review and proceed, escalating touser/escalatedonly if the decision is genuinely Drew's. Task 8569 is at attempt 18 of 24 after repeated handoffs.dezren39 commentedon Nov 4, 2026
agent-note:v1
task: 8569
lane: code-y
stage: handed_off
execution_lane: opencode
Issue #4986 verified OPEN, no hard-stop labels (user/review present — the claimant session reviews first per the runbook). Task 8569 re-claimed (attempt 21/24) and handed off again to the opencode claimant. Attempts are near the cap (21/24) after repeated unlaunched handoffs — fleet monitor: claimant launch reliability for this task is worth a look.
dezren39 commentedon Nov 5, 2026
🤖 Agent note · handed off