Trust gates

An agent saying "done" isn't done. Before any change your agents make is eligible to merge, it has to clear two independent gates. Anything that doesn't is quarantined for a human — not shipped.

The two layers

1. Your tests. The change runs your test suite. This catches what's specified.
2. An independent reviewer. A separate agent that didn't write the code reviews the change, prompted to find defects rather than rubber-stamp it. This catches what isn't specified — the plausible-but-wrong changes that read fine and still break.

A change is only cleared for merge if both pass.

A gate that knows what was already broken

A gate enforcing an already-red check rejects perfect work every time. So when a check fails in the worktree, partyline re-runs it on the base branch:

• Red on base too — that's pre-existing debt, not this change's fault. The check is recorded as a warning and the run continues. It is never quarantined for it.
• Green on base — a real regression. It fails, exactly as before, and the first regression stops the run.

The harness-verified pre-existing failures then ride into the reviewer's prompt as baseline facts, and the reviewer's per-criterion hard-fail rule gains one carve-out: an acceptance criterion that fails for reasons already true on base is a defect in the criterion — "pre-existing on base, needs rescoping" — never in the work.

The fix runs upstream too. The planning prompts now tell the agent to run a check on the current base before writing an absolute "X passes" criterion, and to scope it ("no new failures in touched files") or split the debt into its own task if base is already red. The web planning agent can't run commands, so it defaults to the scoped form unless you confirm the check is green on base.

Quarantine, by default

When a change fails either gate, the acceptance gate routes it to a human: it's held out of the merge path and surfaced on the run's page to approve or discard. The default is never to ship. Nothing is merged automatically on a failure, and nothing is silently dropped — the failure and its reason are recorded.

Because each change is gated independently, you can put a fleet of agents on the backlog and review the queue of results that already passed — in the Build Board's Review lane — instead of supervising every session live.

The run log

Every step of every run — build, tests, review, and the final decision — is written to a tamper-evident, hash-chained log. Each entry is chained to the one before it, so the record can't be quietly altered after the fact. You get an auditable reason behind every merge or quarantine, on the run's page.

Where this fits

Trust gates run inside every run, whether you started it with ptln work, ptln crank, or a dispatch from the board. A passing change lands in the board's Review column with its PR link and the reviewer's grade — A–F, A/B green through D/F red on the card — waiting for a human Accept. With the review gate on, that PR sits as a draft until you accept: Accept marks it ready, Decline closes it (and asks re-run or backlog), so nothing can merge past you by accident. Want a fresh verdict later? Request review on the run's page re-runs the independent reviewer on demand — and if the machine that built the run is offline but its PR is pushed, another machine with the project picks it up (latest CLI). What accepting does — a branch, a PR, or an auto-merge — is set by the run's merge policy; the gates decide whether it gets that far at all.

Next: Build & Ship · How it works · Security.