Add optional reel mode for loop skill

[MrFlashAccount]

Summary

Keep loop core simple for PR #82, but preserve the future extension we discussed: reel mode (рабочее имя: “режим роя”) as an optional advanced mode for exploration-heavy loops.

This should not block the current generic loop skill. Treat it as a later enhancement.

Current loop core

The core loop remains sequential and bounded:

mode: sequential
maxIterations: 3
parallelExecutors: 1

Lifecycle:

1. Orchestrator initializes loop state.
2. One executor/subagent runs one focused iteration.
3. Executor reports and stops.
4. Orchestrator updates state, reports progress, and decides continue/stop.
5. Continue only while progress/next action/approval boundaries allow it.

Proposed future mode: reel

reel is the optional “many independent passes per round” mode:

mode: reel
parallelExecutors: 3
maxIterations: 30
dedupeBy:
  - finding signature
  - touched files
  - hypothesis
stateStore: .loop/<loopId>/outputs

Semantics:

sequential: 1 -> 1 -> 1 -> 1
reel: [1,2,3,4] -> aggregate/dedupe -> [5,6,7,8]

Why this is different from just high maxIterations

A high maxIterations loop is still sequential.

reel changes the execution topology:

• launches multiple independent executors per round;
• gives each executor a unique direction / hypothesis / output path;
• aggregates results after the round;
• dedupes findings before the next round;
• assigns the next round based on what was already found.

Useful for

• bughunt: find many independent bugs or uncovered areas;
• refactor discovery: collect candidates before choosing what to implement;
• design exploration: generate many distinct options;
• optimization search: explore multiple bottleneck hypotheses;
• docs cleanup audit: inspect multiple user journeys or document clusters.

Stability mechanics to preserve from upstream Infinite Agentic Loop

The upstream Infinite Agentic Loop is interesting not because it is literally infinite, but because it has stronger exploration mechanics:

• wave/batch execution;
• unique assignment per executor;
• output directory as state store;
• dedupe before next wave;
• explicit max iteration/cost/time bounds;
• stop on no progress / saturation / blocker / approval boundary.

Open design questions

• Naming: reel vs wave vs batch. Current preferred name: reel.
• Should reel live only in references/protocol.md, or become a first-class mode in SKILL.md?
• What is the minimal state store shape?
• How should dedupe signatures be defined per task type?
• Should reel allow parallel implementation, or only parallel discovery/audit?
• How should it compose with future workflow / role sequences?

Non-goals for now

• Do not make PR Add loop skill #82 depend on this.
• Do not add Claude-specific commands.
• Do not require CI/PR/auto-merge assumptions.
• Do not make loop infinite by default.