Review, QA, and Shipping: Making Completion Verifiable

For gstack, an agent finishing an edit is not the same as a branch being ready to release. This chapter follows the path from a browser or code finding to a verified change, then from that change to a pull request, deployment, and production check. The reader’s practical judgment is how review, QA, shipping, and monitoring divide the work, and why gstack treats fresh evidence as a condition of completion rather than a confidence boost.

The distinction matters because each stage sees a different failure surface. CI can prove that selected tests pass. Structural review can find a race or an incomplete enum path that the tests never exercise. Browser QA can reveal a broken redirect or an inaccessible control. Shipping can discover that the code changed after the tests ran. A canary can show that a production page fails only after deployment. gstack connects these checks without treating them as interchangeable.

Review looks beyond the green test suite

A test suite answers the cases its authors wrote. It may not answer whether a new status value is handled in every switch, whether two concurrent requests can violate an invariant, whether an LLM result is trusted before validation, or whether a shell command receives an unsafe value. gstack’s /review workflow is designed for that gap. It examines the branch against its base and looks for structural failure modes that can survive ordinary CI.

The review categories are not a list of style preferences. They are questions about behavior outside the happy path: data safety, race conditions, trust boundaries around model output, shell injection, enum and value completeness, asynchronous work, type coercion, time windows, frontend behavior, completeness gaps, and distribution or CI concerns. A particularly revealing rule requires reading outside the diff when a change introduces a new enum, status, tier, or type. The new value may be correct in the edited file and still break a separate allowlist or switch elsewhere.

Consider a new payment state named awaiting_confirmation. The edited handler may create it correctly and the focused test may pass. A structural review asks where sibling states are converted to user-facing labels, which transitions permit retries, whether a background worker treats unknown values as failures, and whether an access rule assumes the old set is exhaustive. The issue is not that the new state is wrong. The issue is that a state is a system-wide contract, and the diff may show only one place where that contract changes.

The same reasoning applies to concurrency. A test that creates one request can verify a response while missing two requests that both observe the same old value. /review looks for the invariant and the update boundary: what must remain true, which operation owns the transition, and whether the database or service actually enforces it. The workflow does not report every theoretical race. It asks for a concrete path through which the race could break behavior. That keeps the review wider than CI without turning it into an undirected list of fears.

That wider search is one reason review is not redundant with tests. A test can pass because the new state was never constructed. A structural reviewer can trace the state through the codebase and ask where it should be accepted, rejected, persisted, displayed, or converted. The result is still a review finding, not proof of a vulnerability.