Status / Workflow Pipeline

You do not have to do anything to make the tracker work. Sparkle reads the real state of your project for you and lights up the right stage.

Here is what each color is telling you. Amber (Uncommitted) means the agent has made changes but has not saved a snapshot yet, so if you closed it right now you would lose that work. Cyan (Committed) means the work is safely saved on this agent's own branch (a private lane for its changes), so closing it keeps the work. Violet (Pull Request) means the agent has opened a pull request, which is a formal "please review and accept these changes" request. Blue (On Main) means those changes were accepted into the main line of your project. Green (Merged) means it is all the way done and shipped.

You will mostly watch the line crawl from amber toward green on its own. When it turns green, that thing is real and it is in your project.

The tracker is a live read of git plus the PR probe, distilled to one rail. No more git status in one window and gh pr view in another to reconstruct "wait, did that actually land?" The rail already did it.

The mechanics that matter to you: Committed wins over a dirty tree. Once a branch has commits, a fresh uncommitted edit on top does not drag the bar backward to amber, because the branch has genuinely gotten further than that. And the bar is monotonic: it advances when the evidence advances and holds its high-water mark through the brief dip where a merge drops the commits-ahead count to zero. Start a genuinely new cycle of work (new commits on a branch whose earlier work already shipped) and it correctly tracks the new cycle instead of staying pinned green. You get an honest readout you can trust at a glance and keep shipping.

Two signal sources, furthest-along wins, monotonic. Local git gives you the floor: ahead > 0 reads Committed, otherwise Uncommitted (a clean or dirty pre-commit branch both sit at the start line). PR/On Main/Merged cannot be inferred from ahead/behind/dirty, so they are advanced explicitly from a PR probe plus reachability checks.

Precedence, strongest first: GitHub PR merged forces Merged; reachability into main/origin (or, for a worktree-isolated worker, into its orchestrator's branch) gives On Main / Merged; PR open gives Pull Request; then local ahead/dirty gives Committed / Uncommitted. The reachability checks are gated on a committedSeen watermark, because a freshly cut branch's tip trivially sits in main and would otherwise read as "landed." A build agent's own chevron rolls up to its least-advanced worker: the whole thing is not Merged until every worker is. One known false positive, by design: hard-reset a branch back to main HEAD (discard, not merge) and the watermark still shows On Main. Rare, deliberate, and not worth persisting per-commit merge proofs to catch.

When you are new, the scariest question is "is my work safe, or did I just lose it?" The tracker answers that for you in a color. Amber means "not saved yet," green means "shipped and done," and everything in between is clearly marked. You do not have to learn any commands or trust your memory.

It also kills the worst feeling in software: the quiet doubt of "wait, did that actually happen?" With Sparkle, you look at the rail and you know. No guessing, no hoping.

You are usually running several agents at once. Without a tracker, "where is everything?" is a tab-by-tab investigation. With it, you scan the grid and instantly see which agents are still loose in their working tree, which are in review, and which already landed. The slow-to-ship ones announce themselves.

That is minutes you stop bleeding on status archaeology, and it is the confidence to fan out wider, because you can actually keep track of a fleet instead of one thing at a time.

The value is a single source of truth for "where is this code" across a fleet, derived from the same git and PR facts you would check by hand, but assembled once and shown consistently. No reconstructing state in your head from four terminal commands per agent. The honesty is the feature: it never claims a stage it cannot prove from real git state, and the build rollup tracks the slowest worker, not the most optimistic one. You can trust the green.

In a plain terminal (the black text-only window), there is no tracker. To learn where your work stood, you would type cryptic commands like git status and read walls of output, then do it again for every separate piece of work. It assumes you already know the magic words. Sparkle turns all of that into a colored line you just look at.

A terminal makes you run git status, then gh pr view, then stitch the answer together in your head, per agent, every time you want to know "did it ship?" Sparkle does that stitching once and shows it as a rail. Same facts, zero round-trips, across the whole fleet at once.

One terminal gives you one serial REPL: git status, git log --oneline @{u}.., gh pr view, repeated per agent, with the synthesis happening in your head. Sparkle computes the furthest-provable stage from the same primitives and renders it monotonically, per agent, with a fleet rollup. Nothing here is magic you could not do by hand. It is the by-hand work, done for N agents, continuously, so you do not.