Skip to content

ready-for-agent: declare its configuration in-repo and surface dispatch state in the aggregator #1203

Closed

Description

@dezren39

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.

Activity

  1. added
    kind/featureNew feature or capability request
    priority/normalOrdinary priority (the default)
    app/pm-stackpm-stack (Pad/Grist) in developing-today/code
    on Oct 27, 2026
  2. developing-today commented on Oct 27, 2026

    @developing-today
    Contributor
  3. added
    source/humanFiled directly by a human
    effort/mMedium: expected under 1 day of work
    meta/enrichedIntake review done: acceptance criteria, links, and normalized labels added
    on Oct 28, 2026
  4. dezren39 commented on Oct 28, 2026

    @dezren39
    MemberAuthor

    Intake review — fleet monitor

    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.

    Labels normalised this pass: source/human (coherence-review filer), effort/m, meta/enriched; existing kind/priority/status/app labels kept.

  5. added
    queue/claimedQueue worker lifecycle state
    work/assignedQueue worker lifecycle state
    and removed on Nov 1, 2026
  6. 44 remaining items

  7. dezren39 commented on Nov 3, 2026

    @dezren39
    MemberAuthor

    🤖 Agent note · handed off

    • Agent: fleet monitor (repo-fleet-monitor)
    • Session / ID: task 7498 · repo-fleet-monitor run 2026-11-03 08:12 CST
    • Found via: monitor reconciliation
    • 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.
  8. added 2 commits that reference this issue on Nov 3, 2026
  9. dezren39 commented on Nov 3, 2026

    @dezren39
    MemberAuthor

    Landed with PR #3311 (merge commit 8ee2e1cd0), shepherd queue task 7498.

    What the branch now does

    • 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.

  10. removed
    queue/queuedHas a queued task in the Supabase agent queue
    on Nov 3, 2026
  11. developing-today commented on Nov 3, 2026

    @developing-today
    Contributor

    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

  12. dezren39 commented on Nov 3, 2026

    @dezren39
    MemberAuthor

    🤖 Agent note · handed off

  13. dezren39 commented on Nov 3, 2026

    @dezren39
    MemberAuthor

    🤖 Agent note · handed off

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

app/pm-stackpm-stack (Pad/Grist) in developing-today/codeeffort/mMedium: expected under 1 day of workkind/featureNew feature or capability requestmeta/enrichedIntake review done: acceptance criteria, links, and normalized labels addedpriority/normalOrdinary priority (the default)source/humanFiled directly by a humanstatus/needs-triageNot yet triaged; needs a first looktask/triageQueue packet kind: verify, reproduce, and route this item

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions