Summary
The authenticated web chat at / renders a single message box. Outside the conversation itself there is no way to see what the factory is doing, what it has done, or which items are waiting on a person. This proposes a read-only activity view alongside the chat.
The run-history layer this would read from already exists and is documented in the README: redacted lifecycle events under the run-history/v1/ Blob namespace, reachable through read_run_record and list_run_history. This is a presentation layer over stored data, not new backend machinery.
Problem
A visitor to / sees one input and nothing else. The product of the factory is a reviewed draft PR, and none of that is visible from the app.
Work that is waiting on a human is the highest-signal state, and today it is only discoverable by reading chat scrollback.
Repository state and agent state are in two separate places, so answering "what is the state of this repo" means leaving the app.
Proposed behavior
- Run board. One row per work item showing current station, elapsed time, and a link to the draft PR when one exists.
- Needs-a-person queue. Draft PRs awaiting review, pending clarification questions, and runs that stopped without opening a PR. This is the panel worth checking daily.
- Run detail. The redacted stage events for a single run, so a past run's path and stopping point can be read without replaying the conversation.
- Repo rollup. Open issues by label, open PRs, and which issues have a run attached.
- Issue and PR context inline. Issue body and comments, plus a diff preview for a reviewed branch.
The first two are the highest value for the effort, since the data already exists. Live updates and inline GitHub content are a later layer.
Open questions
Run IDs are Eve session IDs. Grouping events into one row per work item may need a mapping that does not exist yet. Worth confirming before scoping.
Does the deployment carry a fixed repository context, or is it per-session? The view needs to know which repo it is showing.
Should the view be read-only, or allow the same actions the chat allows? Read-only is the safer first step.
Safety and scope
Read-only. No approval, merge, or ready-for-review action from this surface.
Only data already visible to the signed-in user through existing tools.
No credentials or unredacted run content in the view.
Acceptance criteria
- A signed-in user can see the current station of an in-flight run without reading chat scrollback.
- Items waiting on a person are listed in one place.
- A completed run's stage events are readable after the fact.
- The view cannot approve, merge, or mark a PR ready.
- It renders correctly when there are no runs and when the Blob namespace is empty.
Relationship to existing work
Builds on #37 and #35 (durable run history and cross-session context index, both closed), which provide the data this view renders. Separate from #47 (advisory reviews on PR comments), which is a GitHub-side surface.
The outbound issue-filing capability is tracked separately in #63. This activity view remains read-only and should not depend on granting the web surface any write capability.
Summary
The authenticated web chat at
/renders a single message box. Outside the conversation itself there is no way to see what the factory is doing, what it has done, or which items are waiting on a person. This proposes a read-only activity view alongside the chat.The run-history layer this would read from already exists and is documented in the README: redacted lifecycle events under the
run-history/v1/Blob namespace, reachable throughread_run_recordandlist_run_history. This is a presentation layer over stored data, not new backend machinery.Problem
A visitor to
/sees one input and nothing else. The product of the factory is a reviewed draft PR, and none of that is visible from the app.Work that is waiting on a human is the highest-signal state, and today it is only discoverable by reading chat scrollback.
Repository state and agent state are in two separate places, so answering "what is the state of this repo" means leaving the app.
Proposed behavior
The first two are the highest value for the effort, since the data already exists. Live updates and inline GitHub content are a later layer.
Open questions
Run IDs are Eve session IDs. Grouping events into one row per work item may need a mapping that does not exist yet. Worth confirming before scoping.
Does the deployment carry a fixed repository context, or is it per-session? The view needs to know which repo it is showing.
Should the view be read-only, or allow the same actions the chat allows? Read-only is the safer first step.
Safety and scope
Read-only. No approval, merge, or ready-for-review action from this surface.
Only data already visible to the signed-in user through existing tools.
No credentials or unredacted run content in the view.
Acceptance criteria
Relationship to existing work
Builds on #37 and #35 (durable run history and cross-session context index, both closed), which provide the data this view renders. Separate from #47 (advisory reviews on PR comments), which is a GitHub-side surface.
The outbound issue-filing capability is tracked separately in #63. This activity view remains read-only and should not depend on granting the web surface any write capability.