FeaturesReview agents

A second pair of eyes on every commit.

Turn review agents on, and an agent reads each new commit of every pull request in the project's repositories, whoever wrote it: your agents, your teammates, Dependabot. It says what it found where you already look, on the lines it is about, and stays quiet when there is nothing to say.

Turn them on How review agents work

The Platform project's reviews: review agents on, on Asha's Claude subscription, and every review of the last days with its pull request, commit and outcome.

The Platform project's reviews on a phone.

Everyone's Not just your agents'

Pull requests from your team, your agents and the apps you choose. Outside contributors' when someone asks.

Focused Bugs, not nitpicks

What the change breaks, security problems and breaks of the repository's rules, most severe first.

Returned To the agent that wrote it

Findings on an fctl agent's pull request go back to that agent, which fixes what's real and answers in the thread.

Resolved By the next commit

The next review strikes out what was fixed and resolves its own threads. The check on the commit says where things stand.

Where you already read.

A review is one summary on the pull request, then each finding on its lines: a title, how severe it is, a few sentences on why, and a suggested change where one helps. The commit gets a check, fctl review: green when there's nothing to look at, neutral when there is, since acting on it is up to the pull request's people.

Anouk sent milkfloat her first pull request, driver breaks. Noor asked for a review, and its agent read the code, ran none of it, and found the break that could hang the solver.

src/insert.rs

51+pub fn insert_break(route: &mut Route, brk: &Break) -> Result<(), Infeasible> {

52+ let mut at = brk.window.start.max(route.vehicle.shift.start);

53+ loop {

fctl-shBotyesterday

A break it can't reach makes `insert_break` loop forever

Medium severity. When the break's window ends before the shift starts, or no stop departs inside it, at <= brk.window.end never holds, and once the van has no departures left, next_departure returns at itself: solve never returns. Stop at the window's end and return Infeasible after the loop. None of the three tests tries a window the route can't reach.

Suggested change

− loop {

+ let end = brk.window.end.min(route.vehicle.shift.end);

+ while at <= end {

Apply suggestionAdd suggestion to batch

Found by fctl review in 9c2e1f4.

From finding to fix, before anyone wakes up.

Noor's agent opened shop#1287 at eleven at night: a link in the reminder email that skips next week's box. Two minutes later the review agent found that last week's email would skip this week's box too. fctl handed the finding to the agent that opened the pull request. It agreed, signed the delivery's date into the link, pushed, and answered in the thread. The next review saw the fix and resolved it.

A reading, not an order. The agent checks each finding, fixes what's real, and says why when it disagrees.
No ping-pong. After five reviews in a row without a person in between, findings wait for one.
On someone's subscription. Reviews run on the Claude plan of the owner who turned them on.

src/app/skip/[token]/route.ts Outdated

6+ const subscriptionId = verifySkip(params.token);

7+ if (!subscriptionId) return NextResponse.redirect(new URL("/skip/expired", _req.url));

8+ const delivery = await nextDelivery(subscriptionId);

fctl-shBotyesterday · edited

Fixed in 4e1c9a2. The token carries the delivery's date now, and an old one stops working once that day has passed.

The skip token isn't tied to a delivery

Medium severity. The token only names the subscription, and the route skips whatever delivery comes next, so last week's email skips this week's box. Sign the delivery's date into the token and refuse it once that day has passed.

Found by fctl review in b81d0e7.

fctl-shBotyesterday

Fixed in 4e1c9a2: signSkip signs the subscription and the delivery's date, and verifySkip refuses a token whose date has passed. Two tests try last week's link.

Unresolve conversationfctl-sh[bot] marked this conversation as resolved.

Every review is a session you can open.

Each review runs in a sandbox of its own, as a session of the project, with a token that only reads on GitHub: no secrets, no setup script, no memory. Open it to see what the agent read, what it ran and why it concluded what it did. The session that received the findings shows them in a few lines, each a click from its thread.

What a review agent may do

The review of platform#840: it found one high-severity issue, posted it on GitHub, and sent it to the agent that opened the pull request.

The agent that wrote it gets the memo.

Asha's agent was chasing a double charge. Its fix still let two workers race to charge the same card, and the review said so. The finding arrived in the agent's session as a message from fctl, it reproduced the race with two workers, and pushed the fix that the next review passed.

platform#437 receives the review's finding, two workers can still both charge the card, and fixes it.

Off until an owner says on.

A project's owners turn review agents on, on their own Claude subscription, and choose the model, the effort, instructions of their own and the apps whose pull requests are reviewed by themselves. Pull requests from people who can't write to the repository start nothing alone: whoever looks at one first asks for its review from the Reviews tab, or with fctl review start.