Make a coding-agent task replayable

A finished coding task is easier to review when its handoff answers three separate questions: what work was declared, what repository bytes changed, and what still needs a person's judgment. A chat transcript or a green badge alone cannot answer all three.

This guide includes an original data-only replay lab. It uses an invented repository tree, stipulated file replacements, and recorded check evidence. It does not run a coding agent, model, shell command, test command, container, OpenHands, Multica, or a third-party repository. Passing means only that the supplied packet is internally consistent and produces the expected synthetic file manifest.

The packet is a handoff, not a verdict

GitHub pull requests bring commits, changed files, checks, and review discussion into one review surface. OpenHands maintains separate benchmark infrastructure for standardized task evaluation. Multica describes task assignment and progress around coding agents. Those sources show why task state and evaluation artifacts matter, but neither project is claimed to emit the packet used here.

The original packet contract keeps these layers separate:

1. Declared task: intent, exclusions, allowed paths, and starting-tree identity.
2. Observed effect: exact data-only replacements and the resulting file hashes.
3. Recorded evidence: check labels, exit codes, and evidence hashes supplied as data.
4. Review state: unresolved decisions that the packet cannot settle.

The verifier can establish whether those fields agree. It cannot establish that the code is correct, the recorded check really ran, the task was authorized, or the change should merge.

A tiny synthetic handoff

The starting tree contains a range helper, its test, and an untouched README. The packet replaces the helper and test through an explicit write operation and adds a generated text report. Each operation binds to the expected prior hash: existing files name their current hash, while the new artifact requires null.

The verifier derives the changed-file inventory and final manifest. It rejects writes outside the declared path set, stale starting hashes, duplicate effects, no-op writes, unknown fields, unsafe paths, malformed hashes, unsupported operations, and output overwrite. The README must remain byte-identical.

Paths live in a portable, case-insensitive virtual namespace. Each slash-separated segment must be nonempty, cannot be . or .., cannot end in a dot or space, and cannot use Windows reserved device names. Case-insensitive collisions are refused. The lab never creates these paths on a host filesystem; a real materializer would need a separately reviewed root-containment and symlink policy.

Recorded checks are deliberately inert. A check has a label, stipulated exit code, and evidence hash; it has no command field. Recorded checks are not executed or verified. The script copies those records into the result without claiming they are genuine runtime evidence.

Download the replay kit

Keep these five files together:

• Replay verifier — rename to .mjs before running;
• invented starting-tree fixture;
• invented task packet;
• exact expected result; and
• blank task-packet worksheet.

The intended local invocation is:

node task-packet-replay.mjs task-packet-start.synthetic.json task-packet.synthetic.json result.json

Prerequisite: Node.js 24 or newer. The implementation uses Node.js built-ins and performs no network request. Repository tests run two isolated replays and require byte-identical output. The exact expected result must equal a fresh serialization, not merely parse to similar values.

Reader action: preserve the starting point

Before delegating a real task, record the immutable starting revision and the allowed paths. After work returns, derive effects from the actual repository rather than trusting a summary. Keep command execution in a separately controlled runner; bind its reviewed evidence back into the packet by hash. Replay data-only changes in a fresh copy, then have a qualified person review intent, implementation, test sufficiency, and merge readiness.

Primary sources:

• GitHub pull requests
• OpenHands canonical repository
• OpenHands benchmark infrastructure
• Multica canonical repository

The task-packet schema, synthetic tree, replacement format, verifier, conclusions, and limitations are original. Upstream projects were not installed or executed, and no performance, isolation, compatibility, or autonomous-delivery claim is made.