flow-next-work-rolling

# Flow work - rolling frontier (experimental beta)

**This skill is a thin delta over the canonical `flow-next-work` skill.** It replaces exactly one thing: canonical phases.md Phase 3 (the task wave loop) becomes the rolling scheduler in [references/rolling-scheduler.md](references/rolling-scheduler.md). Every other contract - hard requirements, mode parsing, setup questions, input grammar, branch handling, quality phase, ship phase, completion review, tracker gating, guardrails - is consumed from the canonical work skill's files **by pointer**, so a fix to canonical work applies here without a second edit.

**Never fork canonical content.** The canonical work skill's files are read, never copied into this skill and never edited from it. A canonical-work change this skill cannot consume by pointer is a blocking defect of THIS skill's structure, fixed here - never by forking or editing the canonical file (fn-203 R3).

**Experimental.** This beta may change or be replaced as it matures; canonical `/flow-next:work` is unchanged and remains the default.

## Preamble

**CRITICAL: flowctl is BUNDLED — NOT installed globally.** `which flowctl` will fail (expected). Define once; subsequent blocks (here and in `references/rolling-scheduler.md`) use `$FLOWCTL`:

```bash
FLOWCTL="${DROID_PLUGIN_ROOT:-${CLAUDE_PLUGIN_ROOT}}/scripts/flowctl"
[ -x "$FLOWCTL" ] || FLOWCTL="<plugin-root>/scripts/flowctl"   # <plugin-root> = the directory two levels above this skill's SKILL.md file (the harness gave you that file's absolute path when the skill loaded); substitute it literally
[ -x "$FLOWCTL" ] || FLOWCTL=".flow/bin/flowctl"
```

**Canonical work skill location (same three-rung shape).** This skill reads the canonical `flow-next-work` files by pointer; resolve their directory once and use `$WORK_SKILL` everywhere:

```bash
WORK_SKILL="${DROID_PLUGIN_ROOT:-${CLAUDE_PLUGIN_ROOT}}/skills/flow-next-work"
[ -f "$WORK_SKILL/SKILL.md" ] || WORK_SKILL="<plugin-root>/skills/flow-next-work"   # <plugin-root> = the directory two levels above this skill's SKILL.md file (the harness gave you that file's absolute path when the skill loaded); substitute it literally
[ -f "$WORK_SKILL/SKILL.md" ] || WORK_SKILL="$(dirname "$(dirname "$FLOWCTL")")/skills/flow-next-work"   # derive from the resolved $FLOWCTL (scripts/ sits beside skills/ under the plugin root)
```

If `$WORK_SKILL/SKILL.md` still does not resolve, stop with `NEEDS_HUMAN: canonical flow-next-work skill not found - the beta consumes it by pointer and cannot run without it`.

## Execution contract

**No-plan refusal (pre-check, before step 1).** A `--no-plan` flag or natural-language no-plan intent ("no plan", "skip planning", "work directly") in this invocation is refused here, before the canonical files are read: a single implicit task degenerates the rolling frontier to one lane, so there is nothing for rolling admission to schedule. The spec's own `no_plan` field counts the same (fn-214): when the target is a spec, run `$FLOWCTL show <spec-id> --json` and refuse a zero-task spec carrying `no_plan: true` — canonical Phase 1 would honor that field as the same explicit instruction and take the direct route. Either way, stop with a one-line redirect to plain `/flow-next:work <spec-id> --no-plan` (a field-carried signal needs no flag - canonical work honors the field by itself). Canonical Phase 1 cannot know it runs under rolling - the refusal lives here or nowhere; a rolling run that reached the canonical zero-task fork has broken this.

1. **Read `$WORK_SKILL/SKILL.md` and follow it in full** - hard requirements (done via `flowctl done` + verified status, `git add -A` staging, green-tree review dispatch), Ralph/autonomous mode rules, input grammar, option parsing, and the setup questions (branch first; review when `REVIEW_BACKEND` is `ASK`). Where that file says "read phases.md", apply step 2 below instead.
2. **Read `$WORK_SKILL/phases.md` and execute it with one substitution**: Phases 1 (resolve input), 2 (branch choice), 4 (quality), and 5 (ship) run exactly as written there. **Phase 3 is replaced**: do NOT execute canonical Phase 3 (3a-3g); instead read [references/rolling-scheduler.md](references/rolling-scheduler.md) and execute it as this run's Phase 3. The scheduler reference re-enters canonical files by pointer where it says so (tracker gates, wave-join mechanics, plan-sync dispatch, completion review gate 3g).
3. **Workers are the canonical `worker` subagent, unchanged.** Every dispatch uses the canonical prompt template and worker.md phases; the scheduler reference fixes the flag values (`PARALLEL_WAVE: true` on every dispatch - review and completion are conductor-owned here for every backend).

## Cross-run claim contention (verified, not assumed)

Task claims live in the shared runtime state store and are spec-scoped, not skill-scoped. A beta run and a canonical `/flow-next:work` run on the same spec contend on the same claims: `flowctl start` on a task claimed by another actor fails (`claimed by '<actor>'`, rc 1 - verified 2026-08-22), and the failed claim drops the task from that run's admissible set (existing semantics, fail closed). Same-actor re-`start` is flowctl's own-task resume, not a second claim - so admission must also treat any task already `in_progress` as in flight elsewhere and never dispatch it. Never clear or steal another run's claim (`--force`/`--reclaim` are human-only repairs).

## Guardrails

- Everything canonical work forbids is forbidden here; its guardrails apply verbatim (read them in step 1).
- **The concurrency cap stays at 3.** Raising it is out of scope for this beta (fn-203 Boundaries).
- **`planSync.enabled=true` disables concurrent admission entirely** - the run degrades to serial, canonical behavior (fail-closed; the scheduler reference carries the gate). **`false` is the shipped default since 4.5.1** (earlier inits wrote `true`), so the prerequisite bites only on repos that opted into plan-sync: `flowctl con