The mission lead loop — tickets, one wake, your scoreboard, a seat that survives

What a ticket is

A ticket is one message the lead has to deal with, written down before it is delivered. It records who really sent it, which crew it concerns, and what it asks. Every source goes through the same door: you, a worker finishing, another agent, a review result, an app notice.

• Pushed once. A ticket's message enters the lead's conversation at most once, even when the sender retries or the app restarts. A push the app could not confirm is never repeated; the ticket stays listed as possibly not delivered so the lead still sees it.
• Always listed. Every open ticket appears on the lead's next wake, either as a line or inside a counted "more" line saying how to open it.
• Ends with the lead. A ticket closes when the lead closes it, answers it, hands it to a worker, or accepts/declines it — never because a session ended.
• Two lanes. Asks from a crew outside the lead's own crew line land in triage. Triage never wakes the lead and never becomes a task until the lead accepts it.

What a lead's wake looks like

Each lead sets its own interval (15 minutes to a day; one hour by default) and the app builds the wake. There is exactly one per interval, and nothing else wakes a lead on a timer.

1. The scoreboard first — one line per measure: the reading, the target, and how old the reading is. A measure the app could not read says so, with the reason, instead of showing a number.
2. Progress in the last day — only a scoreboard reading that improved, or an app-checked milestone that passed. Tasks closed and helpers started are shown below, as activity.
3. The open tickets, owner messages that still need a label first.
4. The lead's chosen report views, then one focus line.
5. The whole wake is capped at 2,500 characters, and a slow or failed read never leaves it blank: it says which part is unavailable and still carries the scoreboard and tickets.

Your messages and the three labels

Every message you send a lead on the loop is kept whole and labelled, and every lead of that crew line reads your standing rules word for word. There are three labels and they behave differently:

• Mission change — anything that changes the mission itself. It waits for your yes before it takes effect.
• Standing rule — a rule that holds from now on. Every lead of that crew line loads it verbatim, and it travels into a hand-over.
• Today's order — work for today. It is listed as open until it is done and never changes the mission.

You can change any label on the crew page, and your label always wins over the lead's. A lead may label its own understanding, but it cannot overwrite yours.

Where the scoreboard comes from

The scoreboard is yours. It is the ## Scoreboard section of the mission document you approved, and it holds at most three measures, each with a target, a unit, a direction, an app source and a cycle. Every crew of the mission reads the same scoreboard.

• A lead may propose a change; it only becomes effective when you approve it.
• Every reading is taken by the app from the named source. Nothing a lead types becomes a reading.

What happens when a lead's session is closed

The seat belongs to the crew, not to the session. Tickets, the wake interval and views, running workers, worktrees, held messages and standing permissions all stay with the seat.

When the app proves the lead's session is gone (missing, archived, closed, ended, or a cloud box that keeps failing), it seats a successor through one journaled hand-over — never sooner than five minutes after the app starts, and within about ten minutes. The successor's note is built from the record: the mission, the scoreboard, milestones, your standing rules verbatim, open orders and open threads. The outgoing lead may add at most 1,500 characters of what it learned, below that.

The app never re-seats a lead that is merely quiet or slow, and never one whose state it cannot read.

How to switch a crew off

• One crew: the lead can turn its own crew off with PUT /crew/mission-loop and { "crewId": …, "on": false }, and the owner's full-trust CLI token may do it for any crew. The crew then runs exactly as it did before the loop: the old heartbeat, notices and reminders come back for it.
• Every crew: the missionLoopEnabled setting (on by default) turns the loop off everywhere.
• Switching back on keeps the crew's first cutover date, so its history stays readable.

A hand-over already in progress runs to its end even if the crew is switched off midway.

Not the same thing as

• The mission documents repository — its approval of the mission page and strategy, and its own per-mission switch.
• Plain Speak cards — the overlay on a lead's report to you.
• The Board — the independent review that can redirect a mission; it uses this hand-over but is not governed here.