Trust gates

Merge AI changes on evidence, not trust.

An agent saying “done” isn't done. Every change your agents make runs your tests and an independent adversarial reviewer before it can merge — and anything that fails is quarantined for a human instead of shipped.

$ ptln crank
$ brew install partyline-sh/tap/partyline
$ ptln crank --file backlog.txt --thread checkout

◆ task 1/3  Save a card (Stripe SetupIntent)
  build ......... done · 7 files, +214 −18
  tests ......... ✓ 41 passed
  review ........ ✓ independent reviewer: no blocking issues
  → branch ready for review · checkout/save-a-card

◆ task 2/3  List saved cards at checkout
  build ......... done · 3 files, +96 −4
  tests ......... ✓ 12 passed
  review ........ ✓ independent reviewer: no blocking issues
  → branch ready for review · checkout/list-cards

◆ task 3/3  Delete a saved card
  build ......... done · 4 files, +73 −2
  tests ......... ✗ 1 failed — delete leaves an orphaned Stripe token
  review ........ ✗ reviewer: no revocation call on the payment method
  ⚠ quarantined — held for a human. Not merged.

2 of 3 ready for review · 1 quarantined · nothing pushed

AI agents are confident, and confidence isn't correctness. A change can compile, read well, even pass a shallow test, and still be wrong — an orphaned record, a missing revocation, an off-by-one nobody caught. If your only gate is the agent's own “looks good,” that ships. Trust gates make every change earn its merge: your test suite plus an independent reviewer whose job is to find what's wrong, with a quarantine for anything that doesn't pass.

How it works

1

The agent builds and self-checks

Each task is built in an isolated worktree. The building agent runs and iterates until it believes it's done — the same as today, but that's the start of the gate, not the end.

2

Tests + an independent reviewer run

The change runs your test suite, then a separate adversarial reviewer that didn't write the code and is prompted to find what's wrong — not to rubber-stamp it.

3

Pass merges, fail is quarantined

Clear both gates and it becomes a pull request you can merge. Fail either one and it's held for a human to approve or discard — the default is never to ship.

Two independent layers

Your tests catch what's specified; an adversarial reviewer catches what isn't. A change has to satisfy both to be eligible to merge.

Adversarial, not agreeable

The reviewer is a separate agent that didn't write the code, prompted to look for defects — so it isn't just the author grading its own work.

Quarantine by default

A failing change is routed to a human to approve or discard. Nothing merges on trust, and nothing is silently dropped.

Tamper-evident run log

Every step — build, tests, review, decision — is recorded in a hash-chained log, so you can see exactly why a change did or didn't pass.

Where it shines

Run a fleet unattended

Point many agents at the backlog and trust the gate, not each agent — you review a queue of PRs that already passed instead of babysitting sessions.

Catch the plausible-but-wrong

The changes that read fine and still break are exactly what the independent reviewer is there to flag before they merge.

Keep humans on the hard calls

The gate handles the mechanical “is this correct” pass; humans spend their attention on the quarantined edge cases.

This is the back half of the factory

Trust gates are what make the rest safe to run. Up front, describe turns an idea into a plan; agents build each task in a sandbox; and these gates decide what actually ships.

See the whole pipeline →

Frequently asked questions

What is a trust gate?

It's the check every AI change has to clear before it can merge in partyline: your test suite plus an independent adversarial reviewer. A change is only cleared for merge — as a reviewable branch, or a PR when you set a merge policy — if both pass; if either fails, it's quarantined for a human to approve or discard.

Why not just trust the agent's tests?

Because an agent grading its own work has a blind spot for the things it got wrong. Trust gates add a second, independent layer — a reviewer that didn't write the code and is prompted to find defects — plus your own test suite, so correctness isn't self-certified.

What happens when a change fails?

It's quarantined: held out of the merge queue and routed to a human to approve or discard. It is never merged automatically and never silently dropped — the failure and its reason are recorded in the run log.

Can I see why something passed or failed?

Yes. Every run records its steps — build, tests, review, and the final decision — in a tamper-evident, hash-chained log you can inspect, so there's an auditable reason behind each merge or quarantine.

Does this work when I run a whole backlog at once?

That's the point. Because each change is gated independently, you can put a fleet of agents on the backlog and review the queue of PRs that already passed, instead of supervising every session live.

Ship only what passes.

$ brew install partyline-sh/tap/partyline