Flywheel skill: go idle (stop ticking, keep the conversation open) only when the pipeline is clear; define 'clear'; stuck is not clear #4530

Problem

The Flywheel skill's idle rule is underspecified, and it conflicts with the skill's own stop condition. Operator decision (2026-10-04): when auto-pickup is off and the pipeline is clear, the loop stops ticking on its own and keeps the conversation open, ready for the operator to close out the run. It does not end the run, and it does not stop while anything is merely stuck.

Current text in sync-sources/skills/pan-flywheel/SKILL.md:

• Phase 2, lines 170-174:

  If nothing is pickable — every remaining item is blocked, parked, or the book/backlog is empty — do not invent work. If anything is still in flight, keep ticking and draining it (phase=watch). Only when nothing is pickable and nothing is in flight, say so plainly in the tick marker (phase=idle needs-you=pipeline idle — nothing pickable) and stop the loop.

• Stop conditions, lines 285-287:

  Backlog and bound book both exhausted — every item merged, parked, or blocked with no path forward. Report and stop; do not manufacture more scope.

• Lines 300-301:

  When stopping, print the tick marker with phase=stopping and end the loop.

Gaps in that text:

1. "In flight" is undefined. It is unclear whether merged-but-not-deployed work, needs-handoff items, or other projects' long-paused agents count.
2. "Blocked with no path forward" lets the loop stop on a stuck pipeline, and a stopped loop then reads the same as a clear one.
3. The idle stop and the exhausted-backlog stop disagree (phase=idle vs phase=stopping "end the loop"), and neither says the conversation stays open or that the report is written first.

Change (replace the Phase 2 paragraph, lines 170-174)

If nothing is pickable — every remaining item is blocked, parked, or the
book/backlog is empty — do not invent work. If anything is still in flight,
keep ticking and draining it (`phase=watch`).

**Pipeline clear → idle.** The pipeline is clear when every issue this run
is draining is merged, its merge is deployed (for Overdeck, `/api/health`
`buildCommit` contains it), and its close-out has run or waits only on the
automatic verify-on-main step. These do not count as in flight: items
labelled `needs-handoff` or waiting on another operator decision, parked or
vetoed issues, and other projects' long-paused agents. When nothing is
pickable and the pipeline is clear:

1. Write and push `.pan/flywheel/report.md` (see Stop conditions).
2. Print the tick marker with `phase=idle needs-you=pipeline clear — ready
   for operator close-out`.
3. Stop scheduling ticks. Keep the conversation open: the operator reviews
   the report and closes out the run (`pan flywheel stop`).

**Stuck is not clear.** If an in-flight issue cannot move without the
operator, keep ticking (`phase=watch`) and name the blocker in `needs-you`.
A loop that stopped ticking must always mean "clear", never "stuck".

And in Stop conditions, replace the "Backlog and bound book both exhausted" bullet with:

- **Pipeline clear with nothing pickable** — go idle as Phase 2 describes:
  report, `phase=idle`, stop ticking, keep the conversation open. Only the
  operator ends the run.

Keep phase=stopping for operator-requested stops only.

Acceptance criteria

• sync-sources/skills/pan-flywheel/SKILL.md contains the new Phase 2 paragraph and Stop-conditions bullet above; the old "blocked with no path forward. Report and stop" wording is gone.
• phase=stopping is described only for operator-requested stops.
• The flywheel-tick parser and pan flywheel status accept phase=idle with a needs-you sentence that contains spaces and an em dash (add or extend a unit test next to the existing tick-marker parser test).
• docs/FLYWHEEL.md describes the idle state: what "clear" means, that the conversation stays open, and that the operator closes out the run.
• After merge, pan sync distributes the updated skill (verify in ~/.claude/skills/pan-flywheel/SKILL.md).

Routing

This is Flywheel loop machinery (TENET-10): route it through a supervised pan handoff, not an unattended pan start. It is also input for the flywheel/gauntlet run design session (.pan/drafts/flywheel-gauntlet-runs.md). If that session's design supersedes the skill, carry these rules into the new design.