Friction cluster: teammate-unresponsive-idle-loop (1 report)

[hcross]

Friction cluster: teammate-unresponsive-idle-loop

1 friction tagged across the harness-friction wing (2026-05-14 (single day)). Routed to https://github.com/hcross/crewrig.

Pattern

Reports span room behavior. The common subcategory anchor is teammate-unresponsive-idle-loop.

Frictions

1. pr-logbook agent entered non-reactive idle loop — unresponsive to shutdown requests for ~1 hour
   • Reported by: claude-code
   • Severity: med
   • Room: behavior
   • Evidence: community-config/skills/pr-logbook/SKILL.md
   • Suggestion (from reporter): Distinct from the "redundant idle confirmation" friction (Friction cluster: teammate-redundant-idle-confirmation (1 report) #96). This is a deeper issue: the agent completed its task (PR 🐛 Add idle-behavior guideline to pr-reviewer and pr-logbook #102 was opened at 16:34) but then sent idle notifications continuously without processing any incoming messages, including shutdown_request signals. Possible root cause: the agent's turn loop did not exit cleanly after completing the task, leaving it in a poll-without-consume state. Mitigation: add a watchdog timeout in the team orchestration layer — if an agent sends N idle notifications within T seconds with no task progress, the team lead should force-terminate.

Suggested resolution

All reporters converge on: Distinct from the "redundant idle confirmation" friction (#96). This is a deeper issue: the agent completed its task (PR #102 was opened at 16:34) but then sent idle notifications continuously without processing any incoming messages, including shutdown_request signals. Possible root cause: the agent's turn loop did not exit cleanly after completing the task, leaving it in a poll-without-consume state. Mitigation: add a watchdog timeout in the team orchestration layer — if an agent sends N idle notifications within T seconds with no task progress, the team lead should force-terminate.

Out of scope

This issue was auto-generated by the Harness Curator (V0). It is descriptive only — a follow-up MR (human-authored, or via the auto-fix mode tracked in #42) will close it with the actual diff.

[hcross]

2026-05-14 — Add shutdown protocol to pr-logbook skill

Context: PR for #104. The harness curator clustered a single friction (severity med, room behavior) reporting that the pr-logbook agent kept emitting idle notifications after completing its task and never consumed an incoming shutdown_request. The reporter's hypothesis: the turn loop stayed in a poll-without-consume state.

What was tried: Documented an explicit Shutdown protocol section in community-config/skills/pr-logbook/SKILL.md (mirrored to .claude/ and .gemini/). It states two things the agent had been getting wrong: (a) on receipt of shutdown_request, respond immediately with a shutdown_response payload (approve: true) and stop — no deferral, no summarising, no waiting on in-flight work; (b) after completing a task and reporting to the team lead, do not re-enter a wait loop — TaskUpdate → completion message → stop. Bumped provenance.version from 1.1.3 to 1.1.4 per the version-bump rule. Single commit a65e963, 3 files / +57 / −3.

Outcome: Skill source updated. Runtime fix (watchdog / forced-termination at the team-orchestration layer suggested by the reporter) is out of scope — this is the prescriptive-text half of the fix. The orchestration-layer mitigation tracks separately under the auto-fix work referenced by #42.

Lesson: Skill text alone cannot guarantee an agent exits its turn loop, but spelling out the contract — what message to send, and that no further processing should happen after the completion report — removes the ambiguity that lets a stuck loop pass for "still working." Pair prescriptive shutdown text with an orchestration-layer watchdog; neither layer is sufficient on its own.