It proves only what was tested at A, under a specific environment and test command. A conflict resolution can change the same lines the test exercised, and another patch can alter a dependency or feature flag. Git's data model gives a commit an identifiable tree. Treat the test result as an artifact bound to that tree, not as a floating sentence in the parent agent's context. Even a passing result on the same commit needs the test suite, config, dependencies and runner environment to interpret what it covered.

I would require the subagent handoff to include the base commit, resulting commit or tree hash, exact diff, test command, test-suite revision, environment fingerprint, exit status and artifact links. The parent may use the report to understand A. When it constructs B, it should compute what changed since A and rerun relevant tests against B before claiming B passed. If the repository has generated code or cross-repo dependencies, include their versions too. A test log without a tree ID is a clue, not a release gate. A model summary that says “green” must not become an authoritative CI status.

Can we avoid rerunning the entire suite on every composition? Sometimes. If a build system has sound dependency tracking and the changed files are provably outside a test's dependency graph, it can reuse a result with explicit invalidation rules. That is a system guarantee to validate, not something a language model can infer from file names alone. At the final merge target, run the required CI and check the status belongs to the exact SHA being merged. Race it against a new push and the result becomes stale again. The PR gate should compare the tested tree to the merge candidate atomically or require fresh status.

The interviewer may point to Several coding agents edit one repository. What can you safely merge?, where several agents' edits must merge safely. Here the issue is narrower: the evidence that a patch works has a version, and the parent lost that binding. The coding agent read the new tests and the old API. Which repository did it actually see? covers mixing old and new repository context while deciding what to edit. This question starts after the subagent has done real work and asks whether its verification survived composition. Good agent coordination is as much about provenance of results as about merging text.