Notifications

Fermata’s notifications are written for someone who has not looked at the app in an hour. Each banner says in one plain sentence what happened; when the run has genuinely stopped for you, a second sentence says what to do about it. Nothing in a banner uses internal vocabulary, and nothing arrives that the run could have handled itself. This page lists every sentence a banner can say, when each lane says it, and which of them reach a paired phone. The banner is also how a parked gate reaches you when no Fermata window is in front of you.

​

The shape of a banner

The title is the piece name, a separator, and a short phase tail: “Spec”, “Strategy”, “Agents”, “Review”, “Complete”, or “Done”. While agents run, the tail carries progress (“Agents 3/7”); mid-review it reads “Review 2/5”. A long piece name is what gets cut, never the tail, because the tail is what tells two banners from the same run apart. The body is the sentence for what happened, followed by a call to action when the run is parked on a decision. Clicking the banner opens the piece it names.

​

What each moment says

Every sentence a phase banner can carry, grouped by where the run is. Counts agree with the run (“1 agent”, “4 agents”); the examples below use a four-agent run. A clean finish is one breath; a finish with casualties itemizes them, and a count of zero is dropped rather than written. The merged sentence quotes the branch and shortens a long one with an ellipsis, so the name never crowds out the rest of the banner.

​

The call to action

When the banner announces a stop you have to clear, the sentence for the pending decision is appended after the sentence for what happened: “The strategy is ready. Approve the strategy or ask for changes.” The appended sentence comes only when the run is genuinely parked. The answer to “is this run waiting on me” is read from the same place the Loop board’s chips read it, so a banner never claims the run needs you while the card says “Advancing”. A run that stopped with failed agents recommends the retry and names the count; a clean stop says nothing about retrying, because there is nothing to retry.

​

What each lane says out loud

On the Manual lane, every row in the table above arrives. Manual means you drive each phase, so the banners narrate each phase. A hands-off run, a released Auto piece or a playing Loop, stays quiet while the machine is working: a working machine is exactly what you asked for when you released the lane, and narrating it is noise. It speaks in exactly two situations:

• At a gate the runner will not clear itself. The banner carries the call to action, whatever the moment.
• At five bookends. The lane opening (“Fermata is running this piece on its own now.”), the run halting (“The run stopped and can be picked up again.”), the run hitting its cost ceiling (“The run hit its cost limit and stopped.”), the agents finishing (“4 agents finished the work.”), and the piece closing (“The piece is done.”).

The merge and the no-merge finish are steps on the way to done, not the end of the story, so a hands-off run does not announce them separately.

​

When conflict resolution finishes

Solve Conflicts on a pull request is a walk-away action: you press the button, an agent works through the tree, and Fermata pushes the branch when it is clean. The ending is what you need to hear, and there are three of them, each with its own title tail in place of the phase. These never name the branch; a branch name is unbounded and would spend the space the second sentence needs. The concrete reason a push failed waits in the piece’s Activity feed, where there is room for it and where it stays on your Mac. “Conflicts remain” is said once per run, however many turns the run takes, and none of the three reach a phone. The flow itself is covered in review and pull request.

​

Quiet successes, surfaced failures

Successes are quiet and failures are loud, and the two are on separate switches so muting one never mutes the other. Sessions that finish cleanly ride the Session Completed toggle; everything that breaks rides Failures. A failure banner’s title names what broke: “Spec failed”, “Strategy failed”, “Decomposition failed”, “PR creation failed”, “PR merge failed”, or “Merge failed”. Its body opens with a plain sentence and appends the concrete reason, the git output or gh error that actually came back. That reason never leaves your Mac. A failed agent inside a running piece has its own recovery story, with retries, skips, and a failure policy: see when an agent fails.

​

Turning them off

Settings → Notifications carries one toggle per notification type, each with a subtitle saying what it covers: The phase banners and the conflict-resolution endings on this page ride SDD Phases. An external MCP client parked on a confirmation shares Required Input, because it is input the app requires from you. Play sound with notifications sits below the four and controls the sound for all of them.

​

The same words on your phone

A paired phone hears about the same moments in the same words. The strategy landing pushes “The strategy is ready. Approve the strategy or ask for changes.”; the plan landing pushes “The plan is ready. Check the agents, then start the run.”; completion pushes the title tail “Complete” with “Confirm the piece is done.” Failures push with the same title tails as the Mac, and a run that halts with failed agents pushes once, titled “Agents halted”. Two things the phone deliberately says differently, because it knows less than the Mac that wrote the sync record: the plan-ready push drops the agent count, and the completion push carries only the call to action. And one thing it never says: per-agent progress. Every agent is its own session, and a twenty-agent run would be twenty near-identical pushes; progress rides the phase boundaries instead. The concrete reason behind a failure never crosses the wire; the phone gets the kind, the Mac keeps the details. The phone has its own per-type switches, covered in the mobile companion.