Code review, integration tests and PR delivery

Review happens before integration

AiOrch assigns scoped implementation work and sends results through a separate reviewer. Findings can return to the implementation agent for revisions and another review round. The configured review-round limit bounds that loop.

Review assesses the result against the task and project context. Approval is a review outcome, not proof that every possible defect is absent. Your team still reviews the integrated branch or final PR.

Choose the controls for your session

• Plan approval: keep auto-approval disabled to inspect and adjust tasks before execution.
• Independent audit: enable it when needed and supply the planning/specification document it will use.
• Branch integration: choose whether approved agent branches should be combined.
• Remote push and GitHub PR: enable the relevant delivery options and configure repository access.

These are distinct settings. A session with every option disabled does not automatically acquire an external audit or a GitHub PR.

Use the repository’s actual validation command

Session configuration supports integration_test_command. When set, that single command replaces the heuristic integration gates and runs against the integrated project. A zero exit status passes; a nonzero exit status fails.

Choose your repository’s real CI entry point and prepare its runtime, dependencies and services in the execution environment. Examples such as make test, npm test or a project-owned validation script are useful only if they are actually the right command for your repository.

Without an explicit command, AiOrch uses detected compile gates and applicable syntax checks. Compilation and syntax checks are not equivalent to running the full test suite. Session-level gate allowlists and denylists can scope the detected checks.

Understand advisory and strict policies

A source-code failure and a missing execution toolchain are different outcomes. Code failures follow the repair/retry path and can fail the session. The environment policy governs cases where a required compiler, runtime or SDK is missing.

The global setting is ORCH_INTEGRATION_GATE_POLICY; a session can override it through integration_gate_policy. Treat an unverified warning as missing evidence, not as a successful test run.

What to inspect before merging a PR

1. Compare the integrated diff with the task and approved plan.
2. Read reviewer findings, revisions and any independent audit result.
3. Confirm the validation command and outcome; inspect unverified or skipped-check warnings.
4. Check common-file changes, migrations, security-sensitive behavior and rollback requirements.
5. Apply your team’s normal human review and CI gates before merging.

A reviewed PR is a useful handoff, not an instruction to skip your existing engineering controls. Learn how to reduce integration friction in the parallel worktree guide.