When Work Overlaps

Tenbi runs many tickets at once. Most of the time they never touch each other and you never think about it. But sometimes two runs edit the same files, a ticket has to wait for another one, or main moves after a run has already finished. When that happens the console shows you a word — a chip, a banner, a button — and this chapter is the plain-language glossary for those words.

One promise underpins all of it: you never touch git. There is no branch to check out, no conflict to resolve by hand, no command to type. Tenbi does the git work; the console tells you what it did and, when there's a genuine choice, offers you a button. If you have never resolved a git conflict in your life, you are exactly the reader this chapter is written for.

Two runs touched the same files

When two in-flight runs plan to edit at least one file in common, Tenbi flags it the moment it knows — a small overlap chip on each run's row in the Dashboard, and an overlap banner on each run's detail page. The banner reads:

Overlaps with run #47 (3 shared files) This run's planned file scope intersects run #47. Same files rarely mean the same lines — most overlaps still merge cleanly — but review before merging.

It also lists the specific files the two runs share.

This is informational. There is nothing to do. Two runs editing the same file usually edit different lines of it, and git stitches those together automatically. The flag exists so nothing lands as a surprise at merge time — not because something is wrong. Tenbi flags, it never pauses: both runs keep going, finish, and open their pull requests as normal. You get one notification per overlapping pair (in Slack, if you've wired up notifications), and the banner stays on each record so you can glance at the shared files before you merge. If the two PRs genuinely conflict once one of them merges, the Conflicts with main flow below takes over — again, with nothing for you to do in git.

"Waiting on #N" — a ticket that hasn't started yet

Sometimes a ticket is picked up but shows a Waiting on #N chip instead of starting. That's deliberate: the ticket declared that it depends on other work, and Tenbi holds it until that work is done so the two don't collide.

It starts automatically. The moment every ticket it's waiting on closes (a merged or closed pull request counts as closed), Tenbi releases the hold and the run begins on its own. You don't re-label it, press anything, or come back to it — a held ticket re-checks its dependencies every polling cycle and picks itself up when they clear.

How to declare a dependency. Write it in the ticket body:

Depends on #42

A few conveniences:

• Several at once — Depends on #42, #43 holds the ticket until both close.
• Case doesn't matter — depends on, Depends On, and depends-on: all work.
• Another repo — Depends on owner/repo#9 waits on a ticket in a different repository.

Until those tickets close, the dependent ticket sits quietly with its Waiting on #N chip and never burns a run.

"Conflicts with main" and the Resolve button

A run can finish, open its pull request, and then have main move underneath it because another PR merged first. When that happens Tenbi walks a short ladder, and the console shows you where on the ladder you are.

First, Tenbi tries the free thing automatically. Before it ever asks you anything, it attempts a plain mechanical merge of the latest main into the run's branch. This costs nothing — it's ordinary git bookkeeping with no AI involved, so there are no tokens to spend. When it works (which is most of the time), you'll see the record note "Branch updated against main" and that's the end of it. Nothing for you to do.

If the mechanical merge can't do it cleanly, the record shows a Conflicts with main chip and a Resolve button. Resolve is one click. It runs a small, focused AI pass over just the conflicting sections — not a whole new run. Before it starts, it asks you to confirm and tells you what to expect:

Resolve conflicts Run a scoped resolution pass over the conflicted hunks. This spends a small amount of tokens (far less than a full run).

So you always consent before any tokens are spent, and the pass is deliberately narrow — it costs a fraction of a full run. And, as everywhere in this chapter, there is nothing to do in git, ever. You don't open the branch, you don't pick sides in a diff. You click Resolve (or don't), and Tenbi handles the rest.

"Needs re-run" — the codebase changed underneath

Rarely, even the scoped Resolve pass isn't safe to apply, and the record moves to Needs re-run. In plain words: the codebase changed underneath this work. So much shifted in main after the run finished that patching just the conflicting lines would be guesswork — the honest move is to do the ticket over against the code as it stands now.

You're not left guessing why. The record explains it:

This conflict couldn't be resolved without a full re-run.

…followed by the specific reason Tenbi attached. To actually run it again, use the Rerun button described in the next section.

About the cost of these: a re-run is a full run, so it counts like one — unless Tenbi caused the conflict itself. When the collision came from Tenbi's own scheduling (two of its runs overlapping), the record carries a Tenbi-scheduled overlap · fair-use exempt chip, and that work does not count against your fair-use. You're never charged fair-use for a conflict our own parallelism created — at any step on the ladder.

Re-running a ticket

Whenever you want a ticket to run again — you edited it, a re-run was flagged, or you just want a fresh attempt — use the Rerun button on the record page. It re-fetches the ticket first, so any edits you made are picked up.

Rerun checks before it charges. A plain Rerun click first runs a quick pre-flight: it does a live check of any earlier pull requests to make sure prior work isn't still open and undelivered. If it finds something worth your attention, it stops and tells you — without consuming an attempt:

Rerun blocked — prior work may still be open A live check found prior pull request(s) that still deliver this ticket. Close them (or address the review feedback) before re-running — no attempt has been consumed.

And it offers to fix it for you. For each blocking pull request, Tenbi shows a Close PR #N and continue button — one click closes that PR and proceeds, so you don't have to leave the console. (If Tenbi can't close a particular PR itself, it says so and lets you close it on your side first.)

You also never have to do label surgery. Tenbi's own bookkeeping labels — the lifecycle labels it adds to track a run — are cleared automatically as part of a Rerun. You don't add or remove ai-completed, ai-failed, or anything like it by hand; that's Tenbi's job, and it does it for you.

What each step costs

Here's the whole ladder in one table. The short version: the common cases are free, the one paid step asks first and costs a fraction of a run, and anything Tenbi's own scheduling caused is exempt from fair-use.

What happens	When	What it costs	Counts against fair-use?
Overlap flag (banner + chip)	Two runs plan to touch the same files	Free — informational only, nothing to do	No
Waiting on #N (dependency hold)	A ticket declares Depends on #N	Free — the ticket just waits, then starts itself	No
Branch updated against main (auto-merge)	main moved but merges cleanly	Free — mechanical git, no AI, no tokens	No
Resolve (scoped pass)	A conflict needs a focused fix, and you consent	A small amount of tokens — far less than a full run	No when Tenbi caused the conflict
Needs re-run (full run)	The codebase changed too much to patch	A full run	No when Tenbi's own scheduling caused it — otherwise like any run

No step ever asks you to open a terminal or run a git command. The most you'll ever do is read a banner and, once in a while, click a button.