Extend the chat ergonomics roadmap now that the core workspace and MCP path are in place for the narrowed chat-host persona. Add the next planned phase around project-aware chat startup, host bootstrap and repair, reviewable agent output, opinionated use-case modes, and faster daily loops so the roadmap keeps pushing toward a repo-aware daily tool instead of a generic VM or SDK story. Document the constraints explicitly: optimize the MCP/chat-host path first, keep disk tools secondary, and take advantage of the current no-users-yet window to make breaking product-shaping changes when needed.
54 lines
1.7 KiB
Markdown
54 lines
1.7 KiB
Markdown
# `4.3.0` Reviewable Agent Output
|
|
|
|
Status: Planned
|
|
|
|
## Goal
|
|
|
|
Make it easy for a human to review what the agent actually did inside the
|
|
sandbox without manually reconstructing the session from diffs, logs, and raw
|
|
artifacts.
|
|
|
|
## Public API Changes
|
|
|
|
The product should expose a concise workspace review surface, for example:
|
|
|
|
- `pyro workspace summary WORKSPACE_ID`
|
|
- `workspace_summary` on the MCP side
|
|
- structured JSON plus a short human-readable summary view
|
|
|
|
The summary should cover the things a chat-host user cares about:
|
|
|
|
- commands run
|
|
- files changed
|
|
- diff or patch summary
|
|
- services started
|
|
- artifacts exported
|
|
- final workspace outcome
|
|
|
|
## Implementation Boundaries
|
|
|
|
- prefer concise review surfaces over raw event firehoses
|
|
- keep raw logs, diffs, and exported files available as drill-down tools
|
|
- summarize only the sandbox activity the product can actually observe
|
|
- make the summary good enough to paste into a chat, bug report, or PR comment
|
|
|
|
## Non-Goals
|
|
|
|
- no full compliance or audit product
|
|
- no attempt to summarize the model's hidden reasoning
|
|
- no remote storage backend for session history
|
|
|
|
## Acceptance Scenarios
|
|
|
|
- after a repro-fix or review-eval run, a user can inspect one summary and
|
|
understand what changed and what to review next
|
|
- the summary is useful enough to accompany exported patches or artifacts
|
|
- unsafe-inspection and review-eval flows become easier to trust because the
|
|
user can review agent-visible actions in one place
|
|
|
|
## Required Repo Updates
|
|
|
|
- public contract, help text, README, and recipe docs updated with the new
|
|
summary path
|
|
- at least one host-facing example showing how to ask for or export the summary
|
|
- at least one real smoke scenario validating the review surface end to end
|