Review Pipeline

Every pull request in the org is reviewed on the platform’s own model, and no review finding is left as a bare comment. This page describes the ladder a finding goes down until a clean review clears it. Sources: core-code-review.yml, core-agent-fixer.yml, core-agent-resolver.yml, core-review-sweep.yml, core-tag-help.yml.

The ladder

Review (`core-code-review.yml`)

Runs on pull_request opened/synchronize, on a PR comment by an OWNER, MEMBER or COLLABORATOR that contains @core_review, @core_check, @code_review or @review, on workflow_dispatch -f pr=, and on repository_dispatch: core-review. Bot comments never trigger it.

CORE first answers with a ✔️ comment and the core-review label, then agents/reviewer posts PR review comments on the coder tier (REVIEW_MODEL: coder). Reviews are serialized in the concurrency group sovereign-review, because the model plane serves one request at a time. If any findings survive, the PR gets the label review:findings-open. Only a clean review clears it.

Fix (`agents/fixer`, inline)

The review job hands every finding, of any severity, to the fixer inline. The fixer makes a one-shot patch and opens a draft correction PR onto the reviewed branch through the GitHub REST/Git Data API. It never merges. The plan gate judges the patch first; a dissent means nothing is pushed. You can also run it by hand with an @core_fix PR comment or workflow_dispatch -f pr= on core-agent-fixer.yml.

Agent drafts (heads fixer/* and core-resolve/*) are not fixed in place. Their findings go straight to the resolver.

Resolve (`core-agent-resolver.yml`)

When the fixer opens no fix, or the PR is itself an agent draft, the review sends repository_dispatch: core-resolve. The resolver runs a full core session start --base <PR head> with CORE_SESSION_VERIFY=build. It raises that to test only when a live bwrap probe passes on the runner. It opens a draft PR onto the PR’s own branch and closes the agent drafts it supersedes.

It resolves on the root human PR of a chain, with every chain PR’s findings in the goal. A failed attempt re-dispatches itself with a bigger budget, up to MAX_CHAIN: "3" attempts in a row:

Attempt	`--max-turns`	`--timeout`
1	12	40m
2	18	70m
3+	24	100m

After that, the cron 17 */3 * * * sweep re-attempts every open PR still labelled review:findings-open with no fix draft pending.

Merging a draft onto the PR branch re-triggers the review, and a clean review clears the label. “Resolved” therefore means the reviewer agrees, not that an agent said so.

repository_dispatch, not workflow_dispatch, is used throughout because the runink GitHub App has actions: read only.

Repos without their own caller: the central sweep

On GitHub Free, org variables and secrets do not reach private repos, so most repos cannot run the review themselves. core-review-sweep.yml runs every 10 minutes (*/10 * * * *) from core. It lists open, non-draft PRs org-wide that were updated in the last 7 days, and for each head SHA nobody has reviewed:

sets commit status core/review = pending on the head SHA;
sends repository_dispatch: core-review {repo, pr} to org-runink/core, which runs the review against that target with an App token scoped to it.

A dispatched review reports through the core/review status instead of a review check-run, because the App has statuses: write but only checks: read. A core/review status still pending after STALE_MINUTES: "90" is re-dispatched. Nothing is configured per repo; a repo created tomorrow is covered.

The CI counterpart for FORGE and forged repos is core-verify-sweep.yml, which reports core/ci. See Central verification.

Comment tags

core-tag-help.yml answers any comment that looks aimed at CORE (@core… or core @…) but carries no recognised tag, by listing the tags that work:

Tag	What it starts
`@core_review` (also `@core_check`, `@code_review`, `@review`)	sovereign code review of this PR
`@core_fix`	a draft correction PR for this PR’s findings
`@core_deploy`	the deployer agent on a task issue
`@core_ship [images]`	build image(s) and roll what runs them (default `core-operator`)
`core @build`	`core-build.yml`, the cheap build/vet check
`core @curate`	the curator
`@core_datagov`	assess the connected data sources
`@core_judgement`	judge the findings submitted to CORE
`@core_recon`	reconcile the rule book against the engine

@core_review and @core_fix only work on a pull request; on an issue there is no diff to read.

A new tag must be added to core-tag-help.yml’s exclusion list, or the help workflow will reply “unrecognised” to a tag that works. @core_ship exists because @core_deploy was already taken by the deployer. Grep the workflows before minting one.

Where you see it in the console

Agent runs › Reviews (GET /api/reviews) shows, per review type, what is running, the history, and the findings. For type code, runs come from the run store (reviewer, fixer, resolver) and findings from open PRs labelled review:findings-open. See Console Pages.

Agent Fleet CI Workflows