QualityFlow’s FullSend layer narrows agent authority but does not replace release gates

QualityFlow’s FullSend integration is less a new testing agent than a control layer around one. The repository packages QualityFlow’s seven-stage test-engineering pipeline as a pinned harness, gives it a sandbox policy and defines what evidence returns to a pull request. Those controls reduce the agent’s ambient authority, but they do not make its output safe to merge or release without a human gate.

Where authority is bounded

A consuming repository references the harness by a full commit SHA plus a SHA-256 integrity hash. Updates are therefore explicit: a team must choose a new revision, recompute the hash and change its harness reference. The integration guide also lets teams override selected values such as timeout and environment keys without silently replacing the whole base definition.

The unified harness runs only after a /fs-plan-tests comment on a non-fork pull request. It executes as an unprivileged sandbox user, sets a two-hour timeout and loads named skills for requirements mapping, review, validation and test generation.

The sandbox policy makes most system paths read-only and limits writable storage to the sandbox and temporary directories. Network access is allowlisted by service and executable: the agent can reach Vertex AI or Anthropic, Jira, GitHub and selected package registries, but only through named tools such as git, gh, curl, language package managers or the agent runtime.

That is meaningful containment, not least privilege in the strict sense. The unified policy grants read-write API access to GitHub and Jira, and the harness receives credential material through host-mounted files and expanded environment templates. Teams still need to scope those credentials to the smallest repository, project and operation set that the surrounding platform permits.

What survives the run

QualityFlow turns the task into a staged record: it builds and reviews a software test plan, refines findings, builds and reviews a test design, and then generates implementations. Intermediate pipeline artifacts are saved under outputs/; generated test files use a qf_ prefix and are pushed to the pull-request branch when write access exists. For forked pull requests, the guide says tests remain in sandbox artifacts because the agent cannot push them.

The guide also documents coverage evidence. An analyzer maps existing tests to code symbols, marks already-covered behavior as EXISTING_COVERAGE, and skips duplicate generation. The project cites one run that found five existing tests and generated 12 tests for eight uncovered gaps. That is inspectable evidence of what the agent believed was covered, not proof that the generated tests are correct.

The human gates remain outside

The repository automates branch changes; it does not document authority to approve or merge a pull request, promote an artifact or authorize a release. Teams should keep required reviews, protected branches and CI checks outside the agent harness. Reviewers should examine the plan, design, coverage map and generated code together, then run the project’s normal test and security suites before merge. The sandbox narrows where the agent can act; the release process must still decide whether its evidence is trustworthy.