Skip to content

Pilot: OpenClaw comment loop — status request, session report, instruction obedience on one issue #1190

Open

Description

@dezren39

Pilot — OpenClaw integration, information gathering

The long-term design (OpenChamber dispatch + babysitter design,
2026-10-26) ends at babysitting-by-comment for OpenClaw: the monitor
posts a routine status-request comment on the issue; OpenClaw sees it,
answers with its session report in the thread, and acts on
instructions left there — GitHub as the bus, no API polling of the
gateway. This pilot proves or kills that loop on ONE issue before
anything is built on it.

Run

  • One real but low-risk task owned by an OpenClaw session (the gateway
    install landed via PR feat(home): install OpenClaw gateway via nix-openclaw #1025, 2026-10-26).
  • The monitor (a human-driven pass by Muse is fine for the pilot)
    posts a status-request comment in the agreed format.
  • Measure: does OpenClaw notice, how fast, and does its reply contain
    the fields the babysitter needs (progress verdict, pool/route used,
    quota left, blockers)?
  • Then post an instruction comment (checkpoint, then continue; or hand
    back) and record whether it is obeyed precisely.
  • Cost the loop: tokens/messages per check-in round vs an API-driven
    babysitter round over the same session.

Acceptance criteria

  • A written pilot report: loop latency, reply completeness against
    the babysitter's field list, instruction obedience, cost per
    round, failure modes seen.
  • A go / no-go recommendation for mirror mode (babysitter posts
    verdicts as comments for OpenClaw locations), with the comment
    format pinned if go.
  • Any OpenClaw-side setup the loop needs is listed as concrete
    follow-up work, not left as folklore.

Filed by Muse (operator) 2026-10-26 at Drew's direction.

Activity

  1. added
    kind/choreRoutine maintenance, housekeeping, dependency hygiene
    priority/normalOrdinary priority (the default)
    queue/queuedHas a queued task in the Supabase agent queue
    area/infraInfrastructure, deployment, and operations
    effort/mMedium: expected under 1 day of work
    on Oct 27, 2026
  2. developing-today commented on Oct 27, 2026

    @developing-today
    Contributor
  3. dezren39 commented on Oct 31, 2026

    @dezren39
    MemberAuthor

    🤖 Agent note · picked up

  4. added
    queue/claimedQueue worker lifecycle state
    work/assignedQueue worker lifecycle state
    and removed
    queue/queuedHas a queued task in the Supabase agent queue
    on Oct 31, 2026
  5. 30 remaining items

  6. added
    queue/parkedQueue task is parked (waiting on CI, time, or an event)
    status/parkedDeliberately paused with a recorded resume condition
    and removed
    status/blockedQueue or user escalation state
    queue/queuedHas a queued task in the Supabase agent queue
    queue/blockedQueue or user escalation state
    queue/claimedQueue worker lifecycle state
    on Nov 3, 2026
  7. dezren39 commented on Nov 3, 2026

    @dezren39
    MemberAuthor

    🤖 Agent note · parked — #3061 remains open

  8. dezren39 commented on Nov 3, 2026

    @dezren39
    MemberAuthor

    🤖 Agent note · picked up

  9. dezren39 commented on Nov 3, 2026

    @dezren39
    MemberAuthor

    🤖 Agent note · done — triage verdict: already routed; the unblock-pass premise is stale, no new follow-up needed

    Findings

    Route

    No new routing. Task 4649 already carries the full run plan with the fresh-#3061 gate check as its first step. Enqueuing another follow-up would create a duplicate. #1190 stays OPEN with labels mirroring parked task 4649.

    • Task 5911 completes as triaged with follow_up_task_ids=[4649].
  10. added
    queue/queuedHas a queued task in the Supabase agent queue
    source/creatorFiled by the new-issue-creator job
    task/triageQueue packet kind: verify, reproduce, and route this item
    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 4649 (triage, parked, priority 50) 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

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

Metadata

Metadata

Assignees

Labels

area/infraInfrastructure, deployment, and operationseffort/mMedium: expected under 1 day of workkind/choreRoutine maintenance, housekeeping, dependency hygienemode/onlineFully doable remotely: design, config, code, cloudpriority/normalOrdinary priority (the default)queue/parkedQueue task is parked (waiting on CI, time, or an event)queue/queuedHas a queued task in the Supabase agent queuesource/creatorFiled by the new-issue-creator jobstatus/parkedDeliberately paused with a recorded resume conditiontask/triageQueue packet kind: verify, reproduce, and route this itemwork/assignedQueue worker lifecycle state

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions