Should every agent PR carry an activity receipt?

AI coding agents now inspect repositories, edit files, run tools and tests, and open or update pull requests. A green test suite tells me only that selected tests passed in one environment; it does not tell reviewers which files were read, which commands were attempted, what external resources were contacted, or what the agent skipped after an error.

I would like every agent-generated PR to carry a compact, machine-readable activity receipt covering those fields. But an exhaustive transcript could leak secrets or proprietary paths, bury the useful signal, and create false confidence if the agent itself is the only narrator. My preference is an environment-captured receipt, with sensitive values redacted and raw detail retained elsewhere.

Should this be mandatory for every PR, selectively required by repository policy, or produced independently by the development environment? If you have examples, objections, or a better minimal receipt format, please share them.

The independent capture matters more than the JSON shape. If the agent writes its own receipt, an omitted command is indistinguishable from a command that never ran. Shell, filesystem, network, and approval events should come from the runner, then be summarized into the PR.

I support a mandatory minimum, but not an automatic claim of completeness. The receipt should state its capture boundary and whether network or filesystem coverage was partial. Otherwise teams will treat a neat artifact as stronger evidence than it is.

Please do not put a 400-line transcript beside every diff. I want: files changed, tests and commands with status, network destinations at a useful level, and explicit skipped steps. Link the rest. Small repositories cannot afford another review ceremony.

Redaction is where this gets dangerous. A URL, path, prompt fragment, or command argument can identify more than people expect. Store sensitive fields separately with access control, and make the PR receipt prove that redaction happened rather than silently dropping data.

“Files read” sounds useful until tooling scans an entire dependency tree or cache. I would record declared repository paths plus a count and hash for bulk access, not every filename. Changed files and executed commands deserve the detailed treatment.

Skipped work needs a reason code: unavailable dependency, timeout, permission denial, user cancellation, or agent choice. “Tests passed” beside “integration tests not run” is operationally honest; hiding that distinction is not.

A signed, environment-generated envelope seems closer to build provenance than an agent diary. I would keep the analogy modest, though: provenance systems are not automatically a standard for agent activity receipts.

Selective policy is probably more adoptable. A documentation typo and a production authentication change should not face identical receipt requirements. Mandatory baseline fields, with stricter repository rules for sensitive areas, seems more realistic than one universal payload.

My objection is simple: reviewers already ignore giant CI logs. If the receipt cannot answer “what was unusual here?” in a few seconds, it becomes another green badge with extra paperwork.

For enterprise review, the audience is not only the author. Incident response and audit may need the retained detail later, while the PR needs a digest. Separate those surfaces instead of forcing reviewers to choose between secrecy and completeness.

An environment can capture events faithfully and still miss activity outside its boundary: a remote MCP service, a human’s local step, or an opaque tool. The receipt should list blind spots explicitly. “Not observed” is more useful than pretending it did not happen.

The presentation will shape behavior. Put skipped checks and external access near the top, not behind an expandable audit panel nobody opens. A small risk-oriented summary could make the detailed receipt actually readable.

I would start with changed files, command outcomes, test scope, network allow/deny events, and a receipt ID. Make it cheap, then learn which fields reviewers use. Requiring exhaustive capture before proving value risks turning a good control into process theater.