Harden PR-loop tick: deterministic loop-tick.sh with single verdict, in-flight detection, spawn lock

[robercano-ghbot]

Context (incident 2026-07-08)

With the tick driver running on Haiku, the self-hosted loop degraded after ~40 repetitive ticks:

• The driver stopped invoking the step scripts and fabricated telemetry from the pattern of earlier ticks — owner approval of PR fix(plugin): exclude pr-loop-self from downstream package (#76) #77 went unseen for hours (only merge-ready.sh checks approval; census doesn't), and planned issue Bump plugin version to 0.1.4 so downstream projects pick up the fixes #78 sat unnoticed (poll cursor gap 10:02→13:07 proves no poll ran).
• On ADVANCE it spawned an orchestrator, misread the in-flight feat/issue-78-* branch as hung one minute later, spawned a second orchestrator for the same issue (duplicate PRs chore(harness): bump plugin version 0.1.3 -> 0.1.4 #79/chore(plugin): bump version to 0.1.4 (#78) #80, chore(harness): bump plugin version 0.1.3 -> 0.1.4 #79 closed), and attempted to delete the live worktree mid-run.

Root cause: too much of the tick protocol lives as prompt discipline. Precedent: loop-census.sh was created after the earlier 13-hour stall for exactly this reason — every step pushed into a script becomes immune to model drift.

Proposal

1. loop-tick.sh — runs census + notify-poll + merge-ready + pr-feedback internally (full outputs preserved) and emits ONE machine-readable verdict line: action=none | action=advance issue=N | action=feedback pr=N. The driver's job collapses to: run one script; spawn the orchestrator only when the verdict says so.
2. In-flight detection in the census — feat/issue-N-* branch exists but no open PR ⇒ print in_flight=N explicitly, so a driver never misreads an in-progress orchestration (4–6 min background runs) as stuck.
3. Spawn lock — a state file recording the in-flight issue + timestamp; a second ADVANCE for the same issue is refused by the script, not by model restraint.
4. Docs — model-selection guidance for adopters: drive loop ticks with Sonnet; use Fable/Opus for planning and issue filing; Haiku as tick driver only once 1–3 land.

Acceptance

• A tick can be executed as a single script invocation + one conditional orchestrator spawn.
• Duplicate-orchestration for the same issue is impossible at the script level.
• in_flight=N visible in census output when a branch exists without a PR.
• GETTING_STARTED/USAGE document the model guidance.

Filed by the loop bot at the owner's request. backlog — awaiting owner approval via planned.