Verification

Two sides, one commitCopy Anchor Link

Every run opens two sandboxes from the same commit, in parallel:

• baseline: your repository as it is, with your lockfile,
• after: the upgrade or swap, plus any code changes.

Each side goes through two phases:

1. Install. On Cloudflare Containers (private repositories), only GET and HEAD requests to package registries, toolchain hosts and GitHub's release downloads are allowed. On Token Factory Sandboxes (public repositories and dry runs) the install's network is open, because Token Factory has no allowlist, and no request is recorded. JavaScript installs run no lifecycle or build scripts. The time limit is 600 seconds, 1,200 for Maven and Gradle, whose warm-up downloads the whole build's plugins.
2. Checks. The network is off: Cloudflare refuses and records every request; a Token Factory microVM has no network interface at all, so the error in the output is what Teire reads. Each check has a 300-second limit.

If the baseline fails to install, Teire retries it once. If it still fails, the agent doesn't start, because no edit could be judged.

Which checksCopy Anchor Link

Teire runs the checks your project already has. It reads your CI workflows first, then your scripts or tool configuration, then sensible defaults. The full rules are on each ecosystem's page. verify in teire.yml replaces them per workspace. Lint, format, e2e and deploy steps are skipped.

How the evidence is decidedCopy Anchor Link

The rules apply in this order, and the first that matches wins:

Rule 9 also covers checks that failed before and pass after: the change itself had already broken the repository, as a retired model does.

Rule 8 sorts out why both sides failed:

• needs_local_service: connection refused on localhost to PostgreSQL, MySQL, Redis, MongoDB, Elasticsearch, RabbitMQ or Memcached.
• environment_mismatch: Node engine, native binary or offline build errors.
• needs_live_access: requests the sandbox denied during the checks, or network errors in the output.

verified opens a ready PR. The middle kinds open a draft that names the reason. regression, unverified and timeout open an issue for a person. The model's review never changes this.

When a change touches several projectsCopy Anchor Link

One pull request can change several projects: a package locked in two folders of a monorepo, or a retired model swapped in a TypeScript service and a Go one. The project the change breaks runs the fix and its checks first. Then every other project the final files touch installs and runs its own checks, before and after, in its own sandboxes with its own toolchain. A project that can't be checked (its sandbox didn't open twice, or its verification failed to run) is never left out: the pull request becomes a draft that names the project and why. A tarball over the size limit, or a repository that stopped being public, is not tried a second time. The weakest result decides the pull request, the Verification section lists each project with its before and after, and the receipt lists every project's commands.

When the newest major won't passCopy Anchor Link

If a major upgrade still fails its checks after the agent's attempts, Teire opens nothing for it. It tries once more with the newest version of the previous major, and that pull request opens with Why X, not Y and the checks that failed on the newer one. The newer major is tried again when a scan sees a newer commit.

What is keptCopy Anchor Link

For each install and check, Teire keeps:

• the command,
• its exit code and duration,
• the test counts,
• the last 4,000 characters of its output,
• the hosts it was denied.

The PR shows the before/after table, and the run page shows every command with its time.