How it works

From a changelog to a pull request.

Seven stages. The interesting ones are the two that decide not to act — because the only number that matters is how many opened pull requests are correct.

One change, all the way through

vendor Stripe · Charges.source removed

  1. 1Claim

    untrusted — vendor changelog, 2026-05-18The source parameter on Charges is removed as of API version 2026-05-28.

    An announcement, not a fact. Nothing is dispatched on this alone.

  2. 2Artifact

    POST /v1/charges− source: string+ payment_method: string

    Spec snapshot 2026-04-30 → 2026-05-28. The removal is observed, not reported.

  3. 3Reach

    billing/charges.py:84billing/refunds.py:31jobs/sync.py:210

    3 confirmed sites, 2 repos. Pinned stripe==12.4.0 — applicable.

Announced2026-05-18
Confirmed2026-06-17
Today2026-09-01
Bites2026-11-07
  1. 01

    Watch the vendor

    Each watched vendor has a source — a spec repository, a changelog, or both — polled on its own schedule.

    Every fetch is stored as a snapshot. Nothing is inferred from a page as it looked once; the record is kept so a claim can be checked against it later.

  2. 02

    Diff, then classify

    A new snapshot is diffed against the previous one. That diff is the raw material, and for vendors with a machine-readable spec it is already precise: a parameter is present or it is not.

    Where a vendor only publishes prose, a model reads it — under a strict output schema, so it can only produce a shape the pipeline understands, and it cannot name a symbol that the spec snapshot does not contain.

  3. 03

    Confirm against an artifact

    This is the step that makes a pull request possible, and the one most tools skip. A vendor announcing a removal is a claim about the future written by a marketing calendar.

    Whether it happened, and when it bites, is settled by something observed: the spec snapshot that no longer contains the symbol, or a probe asking the live API directly whether it still exists. If nothing was observed, nothing proceeds.

  4. 04

    Find the call sites

    Your repositories are indexed on install and re-indexed as you push. A confirmed change is matched against that index to find the places it could reach.

    Then the version basis is checked. If you are pinned to a version the change does not affect, the result is a skip with the reason attached — shown, not hidden, because a skip is the receipt that proves something was looked at.

  5. 05

    Re-confirm before spending anything

    Before any agent starts, the runner clones your repository fresh and re-confirms the call sites by content rather than by line number.

    Zero confirmed sites means the run exits having spent nothing. That is the cheapest possible outcome and it is designed to happen often — an index can be stale, and acting on a stale index is how a wrong pull request gets written.

  6. 06

    Write the fix

    An agent works inside the clone with one capability: editing files. No tokens, no network, no git.

    Its licence is the single change it was dispatched for, at the sites that were confirmed. Not a sweep, not an upgrade, not tidying on the way past.

  7. 07

    Verify, then open

    Astra records a test baseline before the agent runs and runs the suite again afterwards. Both results are its own run, not the agent's report of its work.

    What was touched is checked against what was allowed. Then the pull request opens, carrying the spec diff, the confirmed sites, the version basis, both test runs, and anything the agent said it was unsure about — verbatim.