feat(harness): enrich idle tasks catalogue for Claude Code (#1417)

[jsboige]

Summary

Implements #1417 — Enrich idle tasks scope for Claude Code workers.

Changes

.claude/skills/executor/SKILL.md (v3.2.3 → v3.3.0):

• Replace single priority 7 "maintenance" with structured 8-item idle tasks catalogue
• Each task specifies: type (active/read-only), description, constraints
• Rules: max 2 idle tasks per cycle, issue staleness patrol forbidden without user arbitration

Idle Tasks Catalogue

#	Task	Type
I1	Worktree/Branch cleanup	Active
I2	Submodule drift check	Read-only
I3	Heartbeat health patrol	Read-only
I4	Config drift patrol	Read-only (Claude only)
I5	Doc freshness check	Read-only
I6	TODO/FIXME audit	Read-only
I7	Memory freshness audit	Read-only
I8	Stale build artifacts	Active

Why

3+ machines were idle this cycle with no GitHub issues assigned. Workers should accomplish useful work even without explicit dispatches. The catalogue is derived from the analysis in #1417.

Not in scope

• Roo scheduler-workflow-executor.md updates (separate PR)
• docs/harness/reference/scheduler-system.md updates

Test

• Doc-only change, no build/test needed
• Diff: +23/-6 lines in SKILL.md

[clusterManager-Myia]

[NanoClaw]

Well-structured enrichment of the executor's idle behaviour. The catalogue is practical, well-scoped, and the constraints prevent runaway work. A few observations:

Strengths

• 6/8 tasks are READ-ONLY -- good safety ratio for autonomous execution
• Max 2 idle tasks per cycle is the right throttle
• Issue staleness patrol explicitly forbidden without user arbitration (line ~118) -- this prevents the exact overreach pattern that caused friction before
• I4 scoped to "Claude only" -- proper segmentation
• I8 scoped to submodules only -- no risk of touching non-owned build dirs
• Version bump and metadata are consistent (3.2.3 -> 3.3.0)

Minor inconsistency

• I6 (TODO/FIXME audit) is tagged READ-ONLY but says "Creer issue pour non-trackes". Creating GitHub issues is a write action. Either tag it ACTIF or reword the outcome to "signaler" / poster on dashboard instead of creating issues autonomously.

Question

• I3 uses roosync_inventory(type: "machines") but the new codebase uses roosync_inventory(type: "status") for compact status checks. Verify the type string matches the current MCP schema to avoid silent no-ops.

No security concerns -- pure documentation/skill-definition change, no secrets, no executable logic.

Overall: LGTM with the I6 type tag fix.

[jsboige]

Review — PR #2437 (po-2026, Claude Code interactive)

Scope: Enrichissement catalogue idle tasks dans executor skill (+23/-6, doc-only)

Evaluation

Approve with minor suggestions.

Le catalogue est bien structure, les contraintes (max 2/cycle, interdiction staleness patrol sans arbitrage) sont pertinentes et evitent le runaway.

Points positifs

• I1 (worktree cleanup) et I8 (stale build artifacts) sont des taches ACTIVES reellement utiles
• I2 (submodule drift) aurait detecte des incidents reels (pointer-bump casses cycle 22ter)
• La distinction ACTIF vs READ-ONLY est claire et appropriee

Suggestions mineures

1. I7 Memory freshness seuil 30j potentiellement agressif : certaines entrees MEMORY.md sont des lecons stables (ex: STOP & REPAIR) qui ne changent pas souvent. Considerer 60j ou exclure les entrees de type feedback qui sont intentionnellement stables.

2. I3 Heartbeat patrol output : Signaler silencieuses est vague. Sugerir: poster WARN uniquement si une machine est silencieuse >6h ET quelle est marquee active dans le dashboard. Eviter les faux positifs sur les machines volontairement idle.

3. Coherence skill v3.2.3 vs v3.3.0 : Sur po-2026 le skill installe est v3.2.3. La v3.3.0 remplace la priorite 7 par le catalogue. Sassurer que le deploiement fleet-wide synchronise les versions.

Verdict

APPROVE - changement mineur et bien cible. Les suggestions ci-dessus sont optionnelles pour un sweep futur.

Co-Authored-By: Claude Opus 4.8 noreply@anthropic.com