A delegated run records its outcome but not its consequential acts — merging to main is invisible

[serge-ivo]

The gap

Identified while closing #150 P2, and distinct from it: a delegation run records its objective and its terminal outcome, but not the consequential acts it took along the way.

The concrete case, from live use (raised when closing #276):

Run 73ffc073 merged its own PRs to main unattended. The supervisor view does not show that it happened.

Its detail says the objective completed. Nothing says a branch was pushed, a PR opened, a PR merged, a force-push made, or a file deleted. A supervisor reviewing that run sees "done".

This is not #150. #150 makes a ticket readable, questionable, and reasoned — the surface is now ready to display this the moment something records it. This issue is about what a run writes down.

Why it matters

The whole delegation model assumes a supervisor can review what a subordinate did. Today they can review what it was asked to do and whether it claimed success. For read-only goals that is fine. For a goal that merges to main, it is not review — it is trust.

Note the platform already got this right elsewhere: every admin moderation action writes an audit row with its before-state (#34), and the pump logs a chain.link event correlating a child run to its parent trace. Delegated coding runs are the surface where an agent takes the most consequential actions and records the least.

Shape (judge it, don't assume it)

• Irreversible/outbound acts are the target: push, PR open, PR merge, force-push, branch delete, file delete, git reset --hard, publish, deploy.
• Where does the signal come from? The Engine is a child process on the user's machine; the Pilot drives it. Detecting acts by parsing terminal output is unreliable. Consider instead deriving from repo state deltas (branch/HEAD/remote refs before vs after — [bug] Delegated runs leave repos on feature branches and with uncommitted edits — and subordinate_status reports neither #276 already added branch + dirty reporting), which is observable and cheap, versus instrumenting the runner.
• agent_events already exists as the unified trace and is the obvious sink. Do not add a fifth record of "what happened" — the Agent work as first-class Tickets — granular, with reasoning + per-ticket conversation #150 agent explicitly avoided that and the reasoning holds.
• The supervisor read (subordinate_status, check_delegation) should surface consequential acts, not just "Last action".

Explicitly NOT in scope

Whether an agent should be allowed to merge to main unattended. That is a policy question (see #142's trust framing) and deserves its own decision. This issue is only about making it visible — a policy nobody can audit is not enforceable anyway.

Acceptance

• A delegated run that opens or merges a PR leaves a record naming that act.
• A supervisor can see it without opening the repo.
• No new "what happened" table.

[serge-ivo]

Shipped in 9958d7a (+ c28e63e). All three acceptance criteria met.

Where the signal comes from, and why not the other one

The issue offered repo-state deltas as the cheap candidate, and #276 already reads
git status --short --branch through the runner, so it would have been nearly free. It was
rejected on a fact, not a preference: a pull request is not a git object. gh pr create changes
nothing in the local repository at all, and gh pr merge changes a ref on GitHub that the checkout
does not learn about until somebody fetches. A delta design would have reported a clean tree on
main for run 73ffc073 — the exact run that prompted this issue — and would have failed the
acceptance criterion by name. What it can see (branch moved, tree dirty) #276 already reports, so
building it would have duplicated the covered half and missed the uncovered one.

The signal is the Engine's stream-json protocol events: a tool_use block carries the literal
command it is about to run, and the matching tool_result carries whether it errored. This is not
the parsing the issue warns about — it does not read the model's prose. {"command":"gh pr merge 42 --squash"} is what the Engine ran, in the same class of protocol fact that #267 already takes its
cost figures from. The outcome is recorded honestly in three states: succeeded, FAILED, and not
observed — a gh pr merge refused by branch protection must never be filed as a merge.

The honest gap: only a stream-json engine (Claude Code) reports acts. A raw Codex/Grok session
reports none — the same gap, for the same reason, as engine usage. So every surface treats an absent
acts as NOT OBSERVED and says so in its legend; a supervisor reading silence as "it changed
nothing" would be a confident wrong answer, worse than the gap it replaced.

Reused vs added

No new table. Acts are agent_events rows (migration 0038), already behind /trace and MCP
agent_trace — the #150 P2 reasoning, reapplied. Also reused: the drain-on-capture transport, the
deterministic row id + conflict-ignoring insert (#267), the per-instance UNION-ALL read shape (#205),
and the two strings check_delegation and the board card already carry.

The event name is the generic act.consequential, not coding.act. Supervision reads these
through instance-work.ts, which is deliberately forbidden from importing a domain module (the
coupling migration 0063 removed). A generic name keeps that intact — and any future subsystem that
deploys or publishes can record the same event and appear in a supervisor's view with no change to
supervision at all.

Added: a pure classifier (runner) + a validating sink and readers (cloud). Kinds recorded:
pr.merge, pr.open, push, push.trunk, push.force, branch.delete, reset.hard, clean,
file.delete, release.publish, package.publish, repo.delete, deploy. A plain rm file.txt
and a git commit are deliberately not recorded — the record is only useful while it stays dense.

Two things worth knowing

• Commands are secret-redacted at capture. A command line is where a token gets pasted
  (GH_TOKEN=… git push, https://user:pass@github.com/…), and this record travels into D1 and
  then into a model's prompt; capture is the only point that covers all three.
• irreversible is recomputed cloud-side from a closed kind enum, never trusted from the
  runner. It decides how loudly an act is surfaced, and kind is rendered into a prompt — an open
  string would be an injection surface through a field the reader treats as an enum.

Where a supervisor sees it

subordinate_status (per subordinate, capped at 5) · check_delegation for one run (by time
window, because a console poll can drain a run's acts before the Pilot does) · the run's own
detail · its board card · the chat thread · GET /v1/instances/:id/trace?trace_id=<runId> ·
/trace?level=warn (irreversible acts are logged at warn — the trace's only "a human should look
at this" band) · MCP agent_trace.

Requires CLI ≥ 0.4.36, published and verified in the tarball.

Out of scope, as the issue asked: whether an agent should be allowed to merge to main
unattended stays open as #142's policy question. This only makes it visible.