Skip to content

Add ask-the-author: interrogate a task's implementing agent during review - #366

Draft
dkrattiger wants to merge 1 commit into
mainfrom
panopticon/ask-the-author
Draft

Add ask-the-author: interrogate a task's implementing agent during review#366
dkrattiger wants to merge 1 commit into
mainfrom
panopticon/ask-the-author

Conversation

@dkrattiger

Copy link
Copy Markdown
Contributor

Exposes a task's claude session as an API a review tool (the tarot half of ask-the-author) can drive: a reviewer posts a question, panopticon delivers it to the task's implementing agent, and the reviewer polls for the answer. The agent's session — its reasoning about why the code is the way it is — already persists in the per-task config volume and resumes via --continue; this makes it interrogable.

Plan: see the task's plan.md artifact.

Contract (task service, REST)

  • GET /tasks/lookup?repo_id=&branch= or ?url= — resolve the task by its branch or PR/URL; 404 if none.
  • POST /tasks/{id}/ask {question, context}{ask_id} — capped at one unanswered ask per task (409); 404 for an unknown task.
  • GET /tasks/{id}/ask/{ask_id}{status: pending|answered, answer} — 410 when the task's config volume was reaped (the review tool's documented fallback signal).

An ask is conversation, not a transition: it never changes workflow state or seeds responsibilities, so asking a COMPLETE task's author works (the turn may flip agent→user as it answers, as normal). Auth is the same same-host trust as the rest of the REST API (v1).

Design (along the determinism invariant, mirroring provisioning)

  • Task service holds the ephemeral Ask record (in memory, like registrations/lifecycle) and enforces the cap; it never touches a container.
  • Session service — a new AskWorker in the host daemon — delivers: inject the question into a live tmux session, or --continue-resume a parked/terminal one with the question as the prompt (spawn_for_ask deliberately allows terminal tasks so a COMPLETE author can be interrogated). Marks the ask gone when the config volume is reaped.
  • Container Stop hook extracts the reply from the transcript (anchored on an embedded marker) and records it — the Stop-hook flip is the completion signal.

Terminal tasks carry a strict read-only guardrail in the delivered message (answer about merged/proposed work; don't modify anything).

Notes

  • The repo's default_base is dimitri/pending-fixes, but per the task memo this PR is kept open against main as usual; the integration-branch landing is handled outside this PR.
  • Live tmux injection is the first send-keys/paste-buffer path in the repo; the parked --continue path covers the common review case (a COMPLETE/parked author).
  • Follow-ups: long-poll on the GET, persisted ask history, reaping idle terminal ask containers.

…view

Expose a task's claude session as an API a review tool (the tarot half)
can drive: a reviewer posts a question, panopticon delivers it to the
task's agent, and the reviewer polls for the answer.

Contract (task service, REST):
- GET  /tasks/lookup?repo_id=&branch= | ?url=  — resolve a task, 404 if none
- POST /tasks/{id}/ask {question, context}      — {ask_id}; capped at one
  unanswered ask per task (409); 404 for an unknown task
- GET  /tasks/{id}/ask/{ask_id}                 — {status, answer}; 410 when
  the config volume was reaped (the review tool's fallback signal)

An ask is conversation, not a transition: it never changes state or seeds
responsibilities, so asking a COMPLETE task's author works (the turn may
flip agent->user as it answers, as normal).

Split along the determinism invariant, mirroring provisioning:
- task service holds the ephemeral Ask record (in memory, like registrations
  /lifecycle) and enforces the cap; it never touches a container.
- session service (new AskWorker in the host daemon) delivers: inject into a
  live tmux session, or --continue-resume a parked/terminal one with the
  question as the prompt (spawn_for_ask allows terminal tasks); marks the ask
  gone when the volume is reaped.
- container Stop hook extracts the reply from the transcript (by an embedded
  marker) and records it — the Stop-hook flip is the completion signal.

Terminal tasks carry a strict read-only guardrail in the delivered message.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant