Menu
Computes wave-based implementation order from story dependencies. Groups stories into waves for parallel execution within each wave.
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
Browser-based visual companion for showing mockups, diagrams, and interactive options during brainstorming, brief creation, and architecture design. Runs a local Node.js server that watches for HTML files and serves them with live reload. Optional — requires Node.js.
Write a verified HANDOFF.md (9 base required fields) and an atomically co-committed wave-state.yaml (6 required fields) to the factory-artifacts branch at wave close. Provides the lossless wave-boundary checkpoint required by BC-5.41.001 and BC-5.41.002.
Diagnostic check of STATE.md — validates structure, size, phase numbering, frontmatter, and content routing compliance. Reports HEALTHY, WARNINGS, or NEEDS-COMPACT.
Extract historical content from STATE.md into cycle files (burst logs, adversary passes, session checkpoints, lessons). Slims STATE.md to <200 lines.
Rehydrate session context at the start of a new session after a wave-boundary reset. Reads wave-state.yaml EXCLUSIVELY from the factory-artifacts branch via git show, injects exactly the listed spec files (Set(stories[*].spec_files) ∪ Set(arch_files) ∪ {state_pointer}), and pauses for operator confirmation before any pipeline work begins. Satisfies BC-6.24.001 postconditions 1–8 and VP-088 §1–§4.
Full wave-boundary reset procedure. Clears the current session, starts a new session, and runs /rehydrate-wave as the mandatory first step to restore exactly the next-wave spec context from wave-state.yaml on factory-artifacts. Pairs with /wave-handoff (which produces the manifest) to provide lossless context-window transitions (CAP-032).
| name | wave-scheduling |
| description | Computes wave-based implementation order from story dependencies. Groups stories into waves for parallel execution within each wave. |
Automatically partition stories into implementation waves using the dependency graph, then sub-partition waves into parallel groups based on the one-story-per-agent rule.
Read the story dependency graph from STORY-INDEX.md. Compute topological order. Stories with no dependencies → Wave 1. Stories whose dependencies are all in prior waves → next wave.
| Wave | Contains |
|---|---|
| Wave 1 | All stories with depends_on: [] |
| Wave 2 | Stories whose dependencies are all in Wave 1 |
| Wave N | Stories whose dependencies are all in Waves 1..(N-1) |
Within each wave, partition stories into parallel groups:
Start Wave N+1 stubs while Wave N implementation is still running:
cargo check between stub creation and test writingProduce wave-schedule.md under .factory/cycles/**/implementation/:
| Wave | Group | Stories | Test-Writer Scope | Implementer Scope |
|---|---|---|---|---|
| 1 | A | STORY-001, STORY-002 | 2 stories | 2 stories |
| 1 | B | STORY-003 | 1 story (XL) | 1 story (XL) |
| 2 | A | STORY-004, STORY-005 | 2 stories | 2 stories |
| ... |
After computing wave assignments, emit the stories: sequence in
.factory/stories/sprint-state.yaml as a producer obligation.
Authority: BC-5.41.004 v1.4 PC3 (sprint-state.yaml producer contract) —
producer MUST write stories: as a YAML sequence of {id, status} objects,
not as a count-summary mapping. Ordering governed by ADR-026 §Decision 3a v1.37
two-partition algorithm with full-graph wave-depth (PC3: terminal partition precedes
non-terminal; within each partition depth ASC, lex ASC). EC-010 narrows the
TopoViolation guard: tolerate supersession edges (terminal→superseded non-terminal);
abort genuine anomalies (terminal→active non-terminal).
Consumer dependency: BC-5.41.002 PC3 — consumer derives per-story status
from stories[*].status: draft entries; pending is a reserved no-op token.
Two-partition ordering algorithm (BC-5.41.004 PC3 + ADR-026 §Decision 3a):
The stories: sequence MUST be emitted as two contiguous, non-interleaved
partitions — Partition A (terminal) then Partition B (non-terminal):
Classify each STORY-INDEX story as terminal
(merged / withdrawn / cancelled) or non-terminal (all other statuses).
Compute full-graph wave-depth for every story (single global pass, memoized):
Root (empty depends_on) → depth 1; else depth(S) = 1 + max(depth(P) for P in S.depends_on).
ALL edges included (all statuses, including cross-partition supersession edges detected by
superseded_by:). Depth is memoized; compute via longest-path DFS over the full dependency graph.
Sort each partition by (full-graph-depth ASC, story-ID lex ASC):
Partition A = terminal stories sorted by (depth, id); Partition B = non-terminal sorted by (depth, id).
(No restricted-edge topo-sort; sort key derived from precomputed full-graph depths.)
Emit Partition A (all terminal entries) then Partition B (all non-terminal entries). No terminal entry may appear after any non-terminal entry (BC-5.41.001 P-SPRINT-STATE-WAVE-ORDER precondition).
TopoViolation guard (narrowed — ADR-026 §Decision 3a v1.37 / BC-5.41.004 v1.4 EC-010):
Before sorting, for each terminal story T in the classified set:
for each dep_id in T.depends_on:
if dep_id is non-terminal in STORY-INDEX.md:
read dep_id's story-file frontmatter for a superseded_by: field
(plain working-tree read: grep -m1 '^superseded_by:' .factory/stories/<dep_id>-*.md
— NOT git exec; INV-4 compliant)
if superseded_by: PRESENT → TOLERATE: this is a legitimate abandoned-by-supersession edge.
The edge IS included in the full-graph wave-depth computation (Step 2) like any other edge;
the dependent terminal story still lands in Partition A (placement is by status, not dependency direction).
Do NOT abort; continue.
if superseded_by: ABSENT → HARD-ABORT: "TopoViolation: terminal story <T.id>
depends_on non-terminal story <dep_id>"; no sprint-state.yaml write
Wave ordinal definition (INV-3-compatible) — ADR-026 §Decision 3a v1.37 / BC-5.41.004 v1.4 PC3:
depth(S) = 1 if depends_on is empty; else 1 + max(depth(P) for P in depends_on)
over ALL dependency edges (all statuses, including cross-partition supersession edges).(depth ASC, story-ID lex ASC).wave: field is written to stories: entries. Wave ordering is expressed
by list position only (BC-5.41.004 INV-3).Status values (BC-5.41.004 INV-1):
Exactly 8 valid values: draft, ready, in-progress, partial, blocked,
merged, withdrawn, cancelled. Hard-abort on any other token (EC-007).
Completeness (BC-5.41.004 PC4): Every non-retired story from STORY-INDEX.md MUST appear in exactly one partition. Retired stories are omitted. No phantom entries for stories not in STORY-INDEX.md.
Preserve existing sections (PC5): epics:, frontier:, next_refinement:,
and story_updates: are independent keys in sprint-state.yaml and MUST be
preserved byte-identical when updating the stories: list.
Use ${CLAUDE_PLUGIN_ROOT}/templates/wave-schedule-template.md for the wave schedule output format.