A merge-readiness packet should let a reviewer verify the exact change, its accepted evidence, unresolved effects, and rollback path without reconstructing the assignment from several agent conversations.
Anchor the packet to an exact revision
Start with the assignment ID, repository, branch, worktree, base commit, head commit, merge target, and concise requested outcome. Include the changed-file list and a diff summary generated from those revisions. Link every artifact and test to the same head commit. If the branch moves after review begins, mark the prior packet stale and create a new one rather than editing the identifier in place.
List dependencies and overlapping assignments. State whether each dependency is accepted, merged, still changing, or represented by a temporary fixture. Show generated files, migrations, lockfile changes, permissions, external calls, and customer-visible behavior separately. This helps the reviewer find consequential surfaces without treating a small line count as evidence of low risk.
Present acceptance evidence and exceptions together
For every criterion, show the check or rubric result, exact command or grader configuration, time, environment, evidence link, and disposition. Include failed, skipped, unavailable, and flaky checks next to passing ones. A packet that hides exceptions creates more work for the reviewer and can make an automated green status appear broader than the underlying test.
GitHub explains that required checks can be enforced through branch protection and rulesets. Use those controls for the checks that must block merging, while keeping richer context in the packet. The reviewer should see security-sensitive changes, unresolved comments, known limitations, recovery or rollback instructions, and any manual verification that remains necessary after the automated gate.
Record the decision without impersonating the reviewer
The control layer may calculate ready for review when the written prerequisites are present. Final outcomes should name the authorized reviewer and record accepted, changes requested, stopped, superseded, or merged as distinct events. A request for changes should point back to the failed criterion and preserve the earlier submission so later revisions can be compared rather than replacing the record.
Reality Contact, LLC implements this packet through Fleet Completion Control. The buyer owns repository policy, appoints reviewers, resolves conflicts, and performs every merge and release. The packet summarizes evidence for the named revision and accepted criteria. It does not certify the change, replace domain review, or authorize consequential repository actions.
Where the service stops
Reality Contact, LLC installs bounded completion and evaluation controls but does not manage the buyer's staff, declare disputed work correct, merge or deploy changes, delete worktrees, reassign tasks, or operate the fleet indefinitely. The buyer defines completion and review authority, approves rubrics and stopping rules, resolves disputed judgments, controls repositories and credentials, and authorizes every merge and deployment. This is technical implementation, not legal advice. Automated evaluation supports named criteria; final technical, security, legal, and production decisions remain with the buyer. We do not promise conflict-free parallel work, correct grader judgments, successful merges, or coverage beyond the accepted sources, criteria, and scenarios.
Sources: GitHub guidance for required status checks; GitHub documentation for rulesets.