You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
ready-for-agent: declare its configuration in-repo and surface dispatch state in the aggregator #1203
Part of epic #1184 (PM stack coherence review, 2026-10-26).
ready-for-agent is configured by prose, serves one repo, and is invisible to the dashboard. Evidence: ready-for-agent/install.sh contains only a pin and unit, and clone handles only developing-today/code; registered repos, mergePolicy OFF, model and unpause exist only as README instructions for manual GraphQL calls. No aggregator code references ready-for-agent state, despite derive.ts treating the ready-for-agent label as 'implementing'.
Acceptance:
A fresh install from the repo reproduces the documented settings from declarative config.
Cloning/registration covers all served repos.
An issue labelled ready-for-agent shows its real dispatch state or an explicit 'not picked up'; harness status appears on /health.
Acceptance criteria
A fresh install from the repo reproduces the documented ready-for-agent settings from declarative config.
Cloning/registration covers all served repos, not only developing-today/code.
An issue labelled ready-for-agent shows its real dispatch state or an explicit 'not picked up', and harness status appears on /health.
Liveness: Verified still live at intake (2026-10-28): issue is open and unheld, and a merged-PR search for #1203 returned only unrelated text matches (no PR title or fix reference resolves this item). Part of epic #1184 (PM stack coherence review, 2026-10-26); sibling batch #1210–#1222 was enriched in the previous monitor run.
Notes: Config-as-prose is why registration, mergePolicy, and model choice drift. Note derive.ts already treats the ready-for-agent label as 'implementing' — the dispatch-state surfacing closes that honesty gap.
Risks: Scope creep across the pm-stack pages is the main risk for this batch; the acceptance criteria above (converted from the issue's original Acceptance list) bound the work. CI on the aggregator's render/derive tests is the verification surface.
Suggested approach: Take the acceptance criteria in order; keep the JSON twins in lockstep with the HTML pages, per the batch convention.
Task: Claim-evaporation repair. Task 7498 was claimed and this issue labelled queue/claimed + work/assigned, but the holder's run ended without complete/park/park/block; the lease expired and the task returned to queued, unclaimed. Labels are reset to the truth: queue/queued + status/needs-triage. Last checkpoint stage recorded on the task: handed_off — the next claimant resumes from that checkpoint, it does not restart from zero.
Expectation: a queue lane re-claims task 7498 and continues from stage handed_off.
Declarative config: pm-stack/ready-for-agent/config.json names all four served repos (code, opencode, openchamber, nix) with mergePolicy OFF, model, issue-author and paused settings; apply-config.sh converges a running harness idempotently over GraphQL; install.sh clone clones/fetches every configured repo and every install run applies the config once the new process is verified serving.
Aggregator: src/sources/ready-for-agent.ts reads the harness live (repositories, backend readiness, per-repo work items, 60 s cache), dispatchStateFor() returns the real work-item state or the explicit "not picked up", and /health + /api/health carry an rfa facet (state, backend detail, per-repo paused/mergePolicy/work-item counts).
Conflicts and review findings resolved before merge
Merge conflict with main in pm-stack/ready-for-agent/install.sh: kept main's pending-restart marker and verified-restart/start loop and the config-driven clone loop + apply-config.sh step.
Codex P2 "expose the harness facet": renderHealth() now renders the facet, /api/health now includes rfa, and a down/unreadable harness participates in the aggregate degraded flag instead of hiding behind the service row's HTTP 200.
Codex P2 "cache failed harness reads": failures are cached for the same bounded 60 s window and rethrown, so a stalled harness costs one 2.5 s timeout per window rather than per dashboard/attention request.
Verification
bun test test/ready-for-agent.test.ts test/health.test.ts — 33 pass / 0 fail (new: facet on view+page+/api/health, down-on-error degrades health, failure cached then retried).
Full aggregator suite — 1339 pass, 1 fail (test/nav.test.ts phone-breakpoint), identical on clean main.
bash pm-stack/ready-for-agent/test-apply-config.sh — PASS (dry-run / first apply / idempotent second apply).
bunx tsc --noEmit — same 30 pre-existing errors as main, none new.
Residual gap (acceptance item 3, first half)
The harness status is now visible on /health, but an issue labelled ready-for-agent still does not show its per-issue dispatch state anywhere: dispatchStateFor() has no production caller and src/derive.ts still treats the bare label as "implementing". Filed as #4969 and enqueued as queue task 8108; scoped to the item page + JSON twin.
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 8617 (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
Activity
developing-today commentedon Oct 27, 2026
CODE-337
dezren39 commentedon Oct 28, 2026
Intake review — fleet monitor
Liveness: Verified still live at intake (2026-10-28): issue is open and unheld, and a merged-PR search for
#1203returned only unrelated text matches (no PR title or fix reference resolves this item). Part of epic #1184 (PM stack coherence review, 2026-10-26); sibling batch #1210–#1222 was enriched in the previous monitor run.Notes: Config-as-prose is why registration, mergePolicy, and model choice drift. Note derive.ts already treats the ready-for-agent label as 'implementing' — the dispatch-state surfacing closes that honesty gap.
Risks: Scope creep across the pm-stack pages is the main risk for this batch; the acceptance criteria above (converted from the issue's original Acceptance list) bound the work. CI on the aggregator's render/derive tests is the verification surface.
Suggested approach: Take the acceptance criteria in order; keep the JSON twins in lockstep with the HTML pages, per the batch convention.
Labels normalised this pass:
source/human(coherence-review filer),effort/m,meta/enriched; existing kind/priority/status/app labels kept.44 remaining items
dezren39 commentedon Nov 3, 2026
🤖 Agent note · handed off
handed_off— the next claimant resumes from that checkpoint, it does not restart from zero.handed_off.fix(pm-stack): expose the ready-for-agent facet and cache failed harn…
Merge pull request #3311 from developing-today/queue/4911-1203-ready-…
dezren39 commentedon Nov 3, 2026
Landed with PR #3311 (merge commit
8ee2e1cd0), shepherd queue task 7498.What the branch now does
pm-stack/ready-for-agent/config.jsonnames all four served repos (code, opencode, openchamber, nix) with mergePolicy OFF, model, issue-author and paused settings;apply-config.shconverges a running harness idempotently over GraphQL;install.sh cloneclones/fetches every configured repo and every install run applies the config once the new process is verified serving.src/sources/ready-for-agent.tsreads the harness live (repositories, backend readiness, per-repo work items, 60 s cache),dispatchStateFor()returns the real work-item state or the explicit "not picked up", and/health+/api/healthcarry anrfafacet (state, backend detail, per-repo paused/mergePolicy/work-item counts).Conflicts and review findings resolved before merge
maininpm-stack/ready-for-agent/install.sh: kept main's pending-restart marker and verified-restart/start loop and the config-driven clone loop +apply-config.shstep.renderHealth()now renders the facet,/api/healthnow includesrfa, and a down/unreadable harness participates in the aggregatedegradedflag instead of hiding behind the service row's HTTP 200.Verification
bun test test/ready-for-agent.test.ts test/health.test.ts— 33 pass / 0 fail (new: facet on view+page+/api/health, down-on-error degrades health, failure cached then retried).test/nav.test.tsphone-breakpoint), identical on cleanmain.bash pm-stack/ready-for-agent/test-apply-config.sh— PASS (dry-run / first apply / idempotent second apply).bunx tsc --noEmit— same 30 pre-existing errors asmain, none new.Residual gap (acceptance item 3, first half)
The harness status is now visible on
/health, but an issue labelledready-for-agentstill does not show its per-issue dispatch state anywhere:dispatchStateFor()has no production caller andsrc/derive.tsstill treats the bare label as "implementing". Filed as #4969 and enqueued as queue task 8108; scoped to the item page + JSON twin.fix(aggregator): clear the last Typecheck errors on main (#4848)
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 8617 (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 · handed off
dezren39 commentedon Nov 3, 2026
🤖 Agent note · handed off