How Teire works

1. Noticeregistries · OSV
2. your deps
3. Impactthe exact lines
4. call sites
5. Fixswap or Nemotron
6. checks
7. Verifynetwork off
8. evidence
9. Pull requestquotes · receipt

1. NoticeCopy Anchor Link

Teire reads the repository at one commit as a GitHub tarball, without git, and inventories every manifest and lockfile. For each dependency it asks the registry for newer versions, their publish dates and deprecations. It also queries OSV and GitHub's advisory database for every locked version, direct and transitive.

The target version is the newest stable one that:

• is at least 7 days old (upgrades.cooldownDays, and longer if your package manager sets its own release-age gate),
• respects your npm, pnpm, Yarn or Bun overrides and resolutions,
• is not deprecated, yanked or a prerelease.

Security fixes skip the cooldown and take the smallest version that fixes every advisory.

For APIs, Teire looks at the URL literals and the SDKs in your code. A provider's change pages are read only when your repository talks to it, and at most once every 6 hours, shared by every repository. Active repositories are rescanned daily, and a new record on a provider's page rescans every repository that uses it, so an idle repository still hears about a retirement. See Providers.

2. ImpactCopy Anchor Link

For a major upgrade, Teire diffs the public API of your installed version against the target, using the tool for your ecosystem. It then finds the lines in your code that use what changed:

Minor and patch upgrades get no API diff. They are plain bumps, and the sandbox decides them. Model IDs and API URLs are found with ast-grep in JS/TS, Python, Go, Rust, Ruby, Java and Kotlin.

Each finding gets one verdict:

3. FixCopy Anchor Link

A run starts with the upgrade itself. Teire edits the manifest as text, then your package manager regenerates the lockfile inside the sandbox.

Next come deterministic edits:

• a model swap to the replacement the provider names,
• for npm packages, an import or call rename that a quoted migration note maps old → new, only where the target proves the new name exists,
• in Python, Go, Rust, Ruby and Java, a rename a quoted note states (a function, a method, a class, a keyword argument), edited at each site the locator resolved by type or import, only where the target version's own source defines the new name and no longer has the old one; a site matched by name alone (a method on an unknown receiver) is the agent's,
• in Python, an import rewritten where the target moved the class or function, and a keyword argument the function no longer takes removed from each call that passes it,
• for Go, go fix -inline for the functions the upgraded module marks //go:fix inline, keeping only the changes that call them through the module's own import; inlined method calls are left to the agent.

If verification is already good enough for a pull request at that point, the run stops without starting the agent. A model swap then costs nothing; a package upgrade has already paid for Nemotron to read its release notes.

Otherwise NVIDIA Nemotron 3 Ultra works as an agent with its tools: read_file, search, edit_file, run_check, lookup_docs, update_plan, finish, and request_upgrade where dependabot-core's updater decides the ecosystem. It may edit only the files the change reaches and the files your check output names. It never edits manifests, lockfiles, config or CI; another dependency it needs moved goes through the updater. It has up to 24 steps per attempt and 4 attempts. After 2 failed verifications it starts over from a plan. When an attempt passes, a review pass reads the diff and sends back any real problem once; a run with no code edits gets a short review of the dependency change instead. See Nemotron on Token Factory.

Checks pass after the upgrade

1. A changereaches your code
3. Upgrademanifest + lockfile
5. Deterministic editsswaps · renames
6. sandbox
7. Your checksbefore vs after
8. pass
9. Pull requestready

Checks fail: Nemotron fixes what broke

1. Your checksfail
2. edits
3. Nemotron 3 Ultra≤4 attempts · 24 stepsa fresh plan after 2
4. loops
5. Checks againpass
6. once more if not
7. Review passtests kept
9. Pull requestready · draft · issuethe evidence decides

4. VerifyCopy Anchor Link

Two sandboxes start from the same commit: the baseline with your lockfile, and the after side with the change.

1. Each side installs. While it does, it may only download from package registries and toolchain hosts.
2. Each side then runs your typecheck, build and tests with the network off.

Teire compares the two sides check by check and test count by test count. The result is one evidence kind, decided by rules, never by a model. See Verification.

5. Pull requestCopy Anchor Link

There is one PR per package and target version, and one per provider for model and API changes (models/openai, api/stripe). A newer target for the same package closes the older PR as superseded. A PR you close stays closed: later scans skip that package version or provider group. See Anatomy of a Teire PR.

What starts a scanCopy Anchor Link

Changes are fixed most urgent first:

1. a security fix with a fixed version,
2. a change that already broke the code,
3. a dated change within 90 days,
4. a breaking change,
5. everything else.