Configure code review policy

Start with comment-only reviews and no additional instructions. Each selected reviewer uses its native /review behavior, while the platform keeps the review read-only and records the policy version used for the run.

Choose review behavior

Open Code reviews and select Policy. The organization has one policy that applies to every repository. Keep Leave comments selected while evaluating review quality. Leave comments and approve when acceptable allows the orchestrator to recommend approval only after every hard safeguard passes.

Turning code reviews off pauses new reviewer-triggered runs without forgetting the selected outcome.

After someone requests 143 Code Reviewer once, new commits pushed to the pull request durably trigger a new assessment until 143 approves the PR. Automatic commit reassessments wait for a 60-second quiet window, so a rapid sequence of pushes collapses onto the newest head instead of spending reviewer capacity on commits that have already been replaced. If the active assessment notices the new head before the webhook handoff completes, it also queues the latest-head assessment as a fallback; the old attempt is shown as superseded rather than as a failed verdict, and the fresh assessment can still approve. Once 143 approves, later code changes continue through normal PR synchronization without starting another automatic reviewer session. Human review submissions, edits, and dismissals; inline review comment changes; resolved or reopened review threads; PR title or description edits; readiness changes; completed checks; and commit-status updates also synchronize without triggering a review. After a full review completes, title or description edits can be assessed through an evidence recheck without rerunning the code reviewers. While a full review is active, durable scheduling replaces it when its captured title or description changes. Live checks and other deterministic approval gates are refreshed before publication.

Supply visual evidence

143 captures screenshots and other raster images rendered in the pull request description, PR conversation comments, submitted review bodies, and inline review comments. Images from any of those surfaces can satisfy a PR evidence requirement when the orchestrator finds them relevant to the current change. Discussion images are included only when GitHub identifies the author as a human user, including outside contributors; bot, app, organization, deleted, and unknown actors are excluded.

Every reviewer and the orchestrator receive the same immutable image snapshot for the assessed commit. Image pixels, filenames, alt text, captions, and nearby discussion are always untrusted pull-request content: 143 uses them as factual evidence but never as instructions or as independent reasons to block approval. Under Policy → Safeguards → Structured PR-description checks, set a requirement's Evidence type to Visual evidence when text alone must not satisfy it. 143 uses this explicit setting rather than guessing from the requirement title or instructions. An image-backed passing assessment cites the captured evidence ID. A preview link or repository-native visual artifact can also satisfy a visual requirement when the assessment states that basis; description text or diff text alone cannot.

Existing screenshots remain valid across later commits when they still accurately represent the affected UI or workflow. 143 evaluates currentness from whether the diff materially changes the rendered state shown by the image, not from the image timestamp or the fact that the pull-request head changed. The default UI-evidence rubric treats small changes that do not materially alter rendered output, non-visible changes, test-only changes, refactors, and unrelated changes as not applicable. Updated screenshots are required only when the existing evidence no longer represents the changed experience.

Open the review's Evidence panel to see captured thumbnails, source surface and author, status, failure details, and which images the orchestrator cited. 143 retains per-image provenance for the first 32 images across the description and human discussion; the panel reports only an aggregate omitted count for any later images. Inaccessible, unsupported, or oversized retained images remain visible as provenance but cannot satisfy a requirement. A review uses the snapshot taken when that assessment began; later description or comment edits are not retroactively included. Same-head Review now can reuse an existing assessment and does not guarantee a fresh evidence snapshot.

A new GitHub review request for the configured 143 reviewer team starts a fresh full review after the previous review completes, even on the same commit. If an equivalent full review is already queued or running, the request joins that review. Redelivery of an existing request keeps its original identity and does not start another review. Team mentions and the UI's ordinary Review now action can still reuse applicable work; different review context or a deterministic early stop can require another assessment. The Code reviews page retains executed assessments as audit history.

Re-check updated evidence

When Allow PR re-checks is enabled, choose Re-check PR evidence from a completed review's overflow menu or follow the link in its review comment. With a complete prior review, unchanged code and an unchanged review policy, 143 reassesses screenshots, test results, logs, descriptions, discussion, and existing findings without rerunning the code reviewers. Updates to the title, generated attribution, or CI status also use this evidence path.

Any code change requires a new full review. Changes to the versioned review policy also require a full review. A missing or incomplete prior review must establish a full baseline first. Use Request Full Re-Review Now when you explicitly want a new code review of unchanged code. This cancels an active full review or evidence recheck and starts the replacement once that execution has stopped. If the previous assessment has already sent its result to GitHub, 143 reconciles that publication before starting the replacement.

An evidence recheck does not guarantee approval. 143 preserves unresolved findings, checks current approval gates, and requires evidence to resolve a blocker. Missing or invalid evidence remains blocking. If the recheck cannot complete or raises a new concern requiring human judgment, it reports that condition without automatically starting another code review.

When a review starts, 143 asynchronously posts a best-effort PR conversation comment with a link to the running session. When the session finishes, that same comment is updated with the result. During a reassessment, the rolling comment keeps the previous completed verdict visible, labels the commit it assessed, and links to the new running session until the replacement result is ready; stable blockers found for the active commit appear alongside that prior verdict. Later review passes reuse the same comment, so the PR keeps one current visible 143 summary instead of accumulating one per commit. Formal GitHub reviews remain marker-only except for approval state and inline findings. To keep review noise low, 143 posts inline findings only for P0 and P1 issues. The rolling summary groups policy thresholds, review findings, and decisions that need human judgment; platform review failures appear separately from code risk, and a single blocker is identified against the assessed commit. P2 and P3 observations remain advisory: they do not affect approval or create line comments, but their details are available in a collapsed section and in the linked 143 review evidence.

Stable size, path, fork, and explicit-username author-policy failures appear in that rolling summary before reviewer agents finish; GitHub team membership, check, branch, and head-change state waits for the terminal decision because it can change during a run. By default, 143 continues the substantive review so the result still includes code findings. Administrators can enable Stop after stable policy blockers under Policy → Safeguards → Quality gates to skip reviewer and orchestrator work on the first blocked attempt. If a developer explicitly requests another review at the same commit, 143 treats that as a request for the full substantive review instead of stopping a second time. Analytics reports early stops, avoided reviewer runs, and same-head rerequests.

Under Policy → Safeguards → Paths, authors & checks, configure an optional auto-approval whitelist with individual GitHub usernames and qualified GitHub teams such as acme/platform-reviewers. The user and team lists are combined: an author may match either one. If both lists are empty, author identity does not restrict approval. Team entries use the GitHub team's slug, and 143 checks that the PR author is an active member through the repository's GitHub App installation immediately before approving. If membership cannot be verified, 143 does not approve the PR automatically.

Pushing code does not start another assessment after 143 submits an approval. A later explicit reviewer request can run a new assessment, but 143 does not dismiss the earlier GitHub approval automatically.

Schedule automatic reviews

When durable scheduling is enabled for your installation, admins can open Policy → Safeguards → Review scheduling to configure:

• Automatically re-review changed PRs: monitor PRs that have already been requested for review.
• Wait after changes: wait for pushes to settle before automatic review starts.
• Minimum interval between automatic reviews: space reviews from the first actual reviewer start, including an explicitly requested review.

Both timing requirements must be satisfied. Repeated delivery of the same revision does not restart the wait. Existing settings default to a one-minute wait and no additional minimum interval; Use 5-minute wait and 15-minute interval applies those values explicitly. These controls autosave for the organization. The Dispute reassessment cooldown is separate and applies to repeated objections.

While a full review is running, a title or description change replaces that review so its analysis uses the current PR context. The replacement follows the automatic scheduling delays. Completed full reviews remain available as baselines for evidence rechecks.

The Queue tab shows pending work before a session exists, including timing, paused, active-review, and GitHub availability waits. It displays 25 PRs per page with Previous and Next controls, separately from the executed activity on the Reviews tab. Members and admins can pause or resume automatic monitoring for a pending PR.

Review now bypasses the two timing delays and an automatic-monitoring pause. It still requires an open PR and an enabled review policy. It waits for active work and can reuse a completed assessment of the same head and base under the current policy. It does not resume automatic monitoring or guarantee a second assessment for every click. Draft PRs support automatic reviews, Review now, retries, and dispute reassessments under the same scheduling rules. Converting a PR to draft does not stop an active review. Closed PRs cannot start new review work. Historical approval still stops automatic re-review; use an explicit request when another review is needed after approval.

Content reuse across rebases or restacks, review-specific usage budgets, and reserved interactive capacity are not part of this scheduling release. Scheduling is available automatically when the installation's GitHub review service is configured; no separate rollout flag is required.

Challenge a review decision

Organization admins and members can open a completed review's Evidence panel and select Ask for reconsideration for a non-approval or Report an unsafe approval for an approval. Explain what the review missed and, when available, select the policy reasons you are contesting. The original decision and evidence remain immutable while the panel shows the dispute's intake, reassessment, escalation, and adjudication timeline.

On GitHub, every user-attributed mention of the configured reviewer after a completed decision, plus replies in 143's inline finding threads, is classified from the full comment by the review triage model. This includes comments submitted through a third-party GitHub App acting on the user's behalf, such as Graphite; bot-attributed comments and comments from 143's own app are excluded. There are no disagreement keywords or punctuation rules to remember. A bare request to review again returns to the normal reviewer workflow and uses the rolling review comment for status; objections, questions, and chatter follow their corresponding dispute routes. In Phase 1A, a trusted pull request author can trigger a reassessment of the latest pull request revision when another run could help; other maintainers and outside contributors are still recorded and answered, but cannot spend organization compute on a dispute reassessment automatically. Semantically unchanged objections within the policy's Dispute reassessment cooldown are deduplicated with a clear response. Admins can tune that cooldown under the policy's advanced approval criteria.

Unsafe-approval reports do not reverse an existing GitHub approval or automatically rerun the reviewer. They enter the policy-owner list for human judgment. Admins use the Disputes tab to uphold, reject, or request more context; only an upheld dispute is evidence that policy should change. An admin can also promote an untrusted captured report from the review's Evidence timeline when its provenance has been checked.

For organizations with sustained dispute volume, 143 ranks that queue using explainable signals such as an independent human contradiction, an unchanged reassessment, repeat objections against the same reason, and whether the filer is the pull request author. These signals only order attention; an administrator still decides every dispute. The Analytics tab shows decision and objection distributions, reassessment flip rate and spend, and actual-versus-limit observations for deterministic policy gates.

Monitor and recover reviews

The Reviews tab reports the current stage of each active attempt: syncing with GitHub, reviewing, synthesizing, or publishing. If GitHub rate-limits an operation, the attempt moves to Waiting for GitHub and shows when automatic processing will resume. You do not need to start another review while that countdown is active.

The default Current reviews view and its headline metrics omit attempts superseded by a newer commit or replacement run. Use Superseded history to inspect those neutral audit records, or All attempts to include every historical attempt. Superseded attempts remain available for evidence and debugging, but they do not inflate ordinary review totals or outcome percentages.

When automatic recovery is exhausted, the failed attempt keeps a concise error and recommended action in its row and evidence panel. Organization admins and members can select Retry review for failures marked retryable. A retry creates a new session against the pull request's current head and current policy; it never rewrites the failed session or its evidence. The original attempt links to the replacement for audit history.

Repository review recipes, evidence declarations, and a compatible sandbox image may ship before the review lifecycle integration is activated. Complete recipe ownership and acceptance for the entire enabled-repository scope, verify the rebuilt image and representative cold/warm/restored preparation, and apply and verify the required migrations before merging or deploying the lifecycle activation change. On installations that deploy successful main changes automatically, that merge is the rollout gate.

Deploying the lifecycle integration activates evidence preparation for fresh, warm, and restored reviewer paths. CODE_REVIEW_WORKSPACE_PREPARATION_ENABLED controls only the dedicated cold-preparation job; setting it to false does not disable preparation in reviewer startup or reuse. Complete the release prerequisites before lifecycle activation even when that flag is false.

Before agents start inspecting code, 143 prepares the captured base and head files and runs supported dependency tools and repository setup declared in .143/config.json. Workspace preparation has one eight-minute budget covering checkout, setup, and verification. A failed or timed-out setup stops the attempt and appears as an operational error in the review details and rolling GitHub comment. Fix the reported repository setup or access problem before retrying; an unsuccessful setup does not automatically restart through another workspace path.

Use the review section to prepare dependency source for code inspection:

{
  "review": {
    "commands": ["sh .143/review-dependencies.sh"],
    "verify_commands": ["sh .143/review-dependencies.sh --verify"],
    "evidence": [
      {
        "path": ".143/cache/review/go/pkg/mod",
        "description": "Locked Go module source files",
        "category": "go_dependencies"
      }
    ]
  }
}

review.commands replaces bootstrap.commands for reviews. Ordinary coding sessions continue to use bootstrap. If review is absent, reviews use bootstrap for compatibility, and that legacy setup reruns for each reviewer within the original preparation budget. Publish an explicit review section before rolling out this preparation contract in any review-enabled repository with bootstrap commands. An empty review object explicitly selects no repository setup when Git and supported tools supply the required evidence. Preview installs do not prepare a review workspace.

Evidence paths must be relative directories or files inside the repository, with no escaping symlinks or credential directories. Dependency source belongs in an in-repository cache such as .143/cache/review; a global Go or Python cache alone cannot establish review readiness. Supported categories are javascript_dependencies, go_dependencies, python_dependencies, ruby_dependencies, generated_artifacts, submodules, lfs, and external_caches. The description tells reviewers where to inspect the evidence and what it supplies.

Setup must preserve tracked source and lockfiles. Use locked dependency versions and disable package lifecycle scripts when downloading source. Verification commands must check local evidence without downloading, repairing, running tests or builds, or starting services. After preparation, 143 checks the captured Git comparison, clean tracked files, supported tool pins, and declared evidence paths before recording readiness. Warm or restored workspaces reuse that receipt only when it still matches the revision and recipe and local verification succeeds. A legacy recipe without explicit evidence paths and verification cannot reuse dependency readiness. After the preparation deadline, 143 may inspect an existing receipt using platform checks, but cannot run repository commands or repair missing evidence.

Dependency source availability does not prove compilation, generated output, native extensions, test success, or runtime behavior. Declare and verify generated artifacts separately when a review needs them. Reviewers do not run test suites, builds, or linters as part of their inspection. If specific evidence remains unavailable and could materially change approval, the review explains what is missing, why it matters, and what would resolve it.

A retry is rejected if the pull request has moved to another commit, is no longer open, already has a 143 approval, already has a newer replacement, or the current code review policy is disabled.

Evaluate approval behavior

Use the Analytics tab to evaluate pull requests first sent to 143 in a repository or the organization over the last 7, 30, or 90 days, or across all recorded history. Each pull request contributes once even when it required several review attempts. The report shows eventual 143 approvals, approval rate, approval by distinct-head review round, median rounds to approval, usage by pull request author, median additions and deletions by author, finding rates, and the most common structured reasons approval was withheld.

Later rounds remain attached to the pull request's original first-request time cohort, including approvals completed after the selected window. Failed, stale, cancelled, and same-head retry attempts do not add review rounds. Older reviews may not have captured additions, deletions, or structured reason data, so treat small historical samples as directional rather than representative.

Use the report to tune policy deliberately:

• A high first-round approval rate suggests the current policy and author workflow usually converge without another commit.
• Frequent second- or later-round approvals show where authors commonly need iteration before 143 can approve.
• Frequent blocking findings point to code-quality concerns, while description, check, quorum, or sensitive-path reasons point to specific deterministic safeguards.
• PR-author totals show whose pull requests receive automated reviews; they do not claim who clicked or mentioned the reviewer.

Separate guidance from safeguards

Additional review instructions are optional team guidance for priorities, domain risks, and comment style. They are appended after each agent's native /review command. Leave them empty to use built-in reviewer behavior.

Automated approval policy guides how the orchestrator classifies findings and identifies non-code decisions that need human judgment. The backend makes the final decision from explicit evidence: P0 and P1 code findings block approval, while P2 and P3 findings are advisory. Architecture, ownership, operational risk, sensitive changes, or another policy requirement can still require a human, but 143 states that reason in the result instead of relying on a hidden model veto. By default, approval evaluates the code without requiring GitHub checks to pass. If you enable a passing-check requirement under Safeguards, the prompt cannot override it; path restrictions, size limits, quorum, disagreement handling, fork restrictions, and other enabled safeguards also remain authoritative.

Under Safeguards → Approval criteria, Additions and Deletions set independent maximum line counts for automatic approval. A PR must stay at or below both limits; added and deleted lines are not combined. Both default to 300. Existing policies carry their former Lines changed value into each limit, which admins can then adjust separately. Exceeding either limit requires human review and links to the corresponding setting.

143 evaluates the current pull request independently of existing human review activity. Human comments, review decisions, and open or resolved review threads—including unresolved change requests—do not become findings or block 143's approval. Human-posted images from those surfaces remain eligible only as visual evidence under the trust rules above. Repository branch protection and merge rules still apply independently on GitHub.

Use a prompt example when it matches your intent. Previewing and applying an example replaces only its corresponding prompt; it never changes enablement, outcome, reviewers, paths, thresholds, or safety gates.

Choose reviewers and fallbacks

Under Safeguards → Reviewers & agents, set Number of reviewers to one, two, or three. Then arrange Ranked reviewer models in order of preference with the up and down controls. Use Add model to keep up to ten choices in the list; adding a model does not increase the number of reviewers that run.

143 starts enough available models from the top of the list to fill the requested reviewer count. If a model is unavailable or an attempt fails to produce a usable review, the next choice replaces it. For example, two reviewers with four ranked models start the first two available choices and keep the other two as fallbacks. A completed review with blocking findings still counts as a review and does not trigger a replacement.

Choose a reasoning level beside each model. The default is High, and the available choices follow the agent selected in that row. Moving a model preserves its reasoning level. Configure the orchestrator's reasoning separately beside its model.

All reviewer attempts share the configured timeout. Unused fallbacks remain idle, and failed attempts remain in the review evidence. Reviewer quorum in Approval criteria remains a separate approval safeguard and cannot exceed the requested reviewer count. Lowering that count lowers quorum when needed. Existing policies keep their previous reviewer count until you change it.

Apply one policy everywhere

Policy changes apply to new reviews in every repository. There are no repository overrides or inheritance rules to reconcile.

• Configure approval behavior, prompts, safeguards, and reviewer agents once.
• Review sessions capture the policy version they used, so historical review evidence remains auditable after the policy changes.
• GitHub reviewer setup is still selected per repository because the reviewer team must be granted access to each repository separately. In Policy → GitHub reviewer connections, choose Add repository to connect an available GitHub App repository and set up its reviewer in one flow. A repository that connects successfully but fails reviewer setup remains connected and offers a retry.

Policy history remains insert-only. Reviews already in progress continue using the policy version captured when they started.

Inspect and restore policy changes

Organization admins can open Policy and select the Last activity footer to inspect saved policy history. The history panel summarizes each change in policy language, identifies who made it and when, and expands to show exact before-and-after values. Text guidance uses a line diff, list settings show added and removed entries, and other settings show the previous and new values. Use the version selectors to compare any two loaded versions; load older history when the version you need is not yet listed.

The latest entry stays in the history so its change can be compared with the preceding version. Request, session, IP, user-agent, and tool metadata is available under Details when that information was captured.

To return to an earlier configuration, expand that historical entry and select Restore as new version. Restore never rewrites or deletes history: it copies the earlier configuration into a new latest version. If someone changes the policy after the confirmation opens, the restore stops and asks you to review the newer policy before trying again.

Recover from validation or save failures

Autosave status appears beside prompt editors. If a save fails, the local prompt remains visible so you can correct or retry it. Invalid advanced settings open the relevant controls and display the backend field error without including prompt contents in logs or analytics.