Skip to content
Fredrin
Documentation

Working the board

Review and merge

When a ticket lands in Review, one person has one job: read the diff and decide. Everything on this page exists to make that decision fast and safe.

Writing code stopped being the bottleneck. Reviewing it did not. This is the page where Fredrin either earns its place or does not.

The glance

A ticket in Review shows you:

  • The diff, as the Worker left it.
  • The plan it was working to, with its acceptance checks.
  • The pull request, if one is open, and its CI status.
  • The session, if you want to know why it did something.

Read the diff against the acceptance checks. That pairing is what makes a fast review honest: you are not asking "does this look plausible", you are asking "does this do the thing I asked for".

Shipping it

Merge from Fredrin and the pull request merges on GitHub. The ticket auto-completes and moves to Completed on the merge signal, not on anyone remembering to move it.

If there is no pull request, because the ticket did not need one, you can complete it directly.

Sending it back

Comment and send it back. The ticket returns to Running and the same Worker picks up in the same session, in the same worktree, with everything it already knew.

That continuity matters. Sending work back is cheap here in a way that re-prompting a fresh chat is not.

Be specific about what is wrong. "This is not right" costs a full round trip. "The retry loop should back off exponentially, and it needs a test for the 429 case" usually costs one.

Approval gates

Two independent gates can require human endorsement before work proceeds. Both are off by default and both are per project.

Build gate. Requires N approvals of the plan before a Worker is dispatched. Approve the approach before spending tokens on it.

Merge gate. Requires N approvals of the diff before any merge path proceeds. This is the analog of a required GitHub PR review, enforced on every route Fredrin can merge through.

Approvals are stage-scoped: the same person can hold one plan approval and one review approval on a ticket, and revoking one leaves the other intact. Re-approving is idempotent, so a double-click never stacks.

The card shows gate progress, so you can see what a ticket is waiting on without opening it.

Conflicts

Conflicts are caught on two fronts.

A pre-push gate refuses to finish a ticket whose branch cannot merge cleanly, rather than opening a pull request that GitHub will immediately mark unmergeable.

When a conflict does appear, Fredrin can dispatch the Worker to resolve it in its own worktree, with full context on both sides of the conflict. This is one of the places where having a real worktree per ticket pays off directly.

CI

Pull request checks flow back onto the card. A red build is visible on the board without opening GitHub, and a ticket whose CI failed can be sent straight back to its Worker to fix.

Next steps