@lumenflow/cli 3.8.6 → 3.9.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +11 -15
- package/dist/cli-entry-point.js +7 -0
- package/dist/cli-entry-point.js.map +1 -1
- package/dist/gate-defaults.js +5 -0
- package/dist/gate-defaults.js.map +1 -1
- package/dist/gates-runners.js +77 -1
- package/dist/gates-runners.js.map +1 -1
- package/dist/guard-main-branch.js +3 -2
- package/dist/guard-main-branch.js.map +1 -1
- package/dist/hooks/enforcement-checks.js +3 -2
- package/dist/hooks/enforcement-checks.js.map +1 -1
- package/dist/hooks/path-utils.js +2 -1
- package/dist/hooks/path-utils.js.map +1 -1
- package/dist/init-detection.js +3 -3
- package/dist/init-detection.js.map +1 -1
- package/dist/lane-create.js +223 -0
- package/dist/lane-create.js.map +1 -0
- package/dist/mem-signal.js +1 -1
- package/dist/mem-signal.js.map +1 -1
- package/dist/public-manifest.js +7 -0
- package/dist/public-manifest.js.map +1 -1
- package/dist/signal-middleware.js +192 -0
- package/dist/signal-middleware.js.map +1 -0
- package/dist/state-doctor.js +135 -0
- package/dist/state-doctor.js.map +1 -1
- package/dist/state-emit.js +72 -10
- package/dist/state-emit.js.map +1 -1
- package/dist/validate.js +2 -2
- package/dist/validate.js.map +1 -1
- package/dist/wu-claim.js +75 -10
- package/dist/wu-claim.js.map +1 -1
- package/dist/wu-done-already-merged.js +2 -7
- package/dist/wu-done-already-merged.js.map +1 -1
- package/dist/wu-done-gates.js +296 -0
- package/dist/wu-done-gates.js.map +1 -0
- package/dist/wu-done-memory-telemetry.js +145 -0
- package/dist/wu-done-memory-telemetry.js.map +1 -0
- package/dist/wu-done-mode-execution.js +136 -0
- package/dist/wu-done-mode-execution.js.map +1 -0
- package/dist/wu-done-policies.js +206 -1
- package/dist/wu-done-policies.js.map +1 -1
- package/dist/wu-done-preflight.js +207 -0
- package/dist/wu-done-preflight.js.map +1 -0
- package/dist/wu-done.js +48 -888
- package/dist/wu-done.js.map +1 -1
- package/dist/wu-edit-validators.js +30 -1
- package/dist/wu-edit-validators.js.map +1 -1
- package/dist/wu-edit.js +7 -2
- package/dist/wu-edit.js.map +1 -1
- package/dist/wu-prep.js +17 -1
- package/dist/wu-prep.js.map +1 -1
- package/dist/wu-spawn-prompt-builders.js +65 -10
- package/dist/wu-spawn-prompt-builders.js.map +1 -1
- package/package.json +9 -8
- package/packs/sidekick/.turbo/turbo-build.log +1 -1
- package/packs/sidekick/package.json +1 -1
- package/packs/software-delivery/.turbo/turbo-build.log +1 -1
- package/packs/software-delivery/package.json +1 -1
- package/templates/core/.lumenflow/constraints.md.template +12 -14
- package/templates/core/LUMENFLOW.md.template +7 -4
- package/templates/core/ai/onboarding/agent-invocation-guide.md.template +2 -2
- package/templates/core/ai/onboarding/docs-generation.md.template +1 -1
- package/templates/core/ai/onboarding/first-wu-mistakes.md.template +40 -0
- package/templates/core/ai/onboarding/initiative-orchestration.md.template +402 -0
- package/templates/core/ai/onboarding/quick-ref-commands.md.template +129 -56
- package/templates/core/ai/onboarding/release-process.md.template +102 -39
- package/templates/core/ai/onboarding/starting-prompt.md.template +1 -0
- package/templates/core/ai/onboarding/test-ratchet.md.template +2 -8
- package/templates/vendors/claude/.claude/CLAUDE.md.template +1 -1
- package/templates/vendors/claude/.claude/skills/bug-classification/SKILL.md.template +2 -2
- package/templates/vendors/claude/.claude/skills/code-quality/SKILL.md.template +3 -3
- package/templates/vendors/claude/.claude/skills/context-management/SKILL.md.template +1 -1
- package/templates/vendors/claude/.claude/skills/frontend-design/SKILL.md.template +1 -1
- package/templates/vendors/claude/.claude/skills/lumenflow-gates/SKILL.md.template +4 -4
- package/templates/vendors/claude/.claude/skills/tdd-workflow/SKILL.md.template +4 -4
- package/templates/vendors/claude/.claude/skills/worktree-discipline/SKILL.md.template +5 -5
- package/templates/vendors/claude/.claude/skills/wu-lifecycle/SKILL.md.template +4 -4
- package/templates/vendors/cline/.clinerules.template +1 -1
- package/templates/vendors/cursor/.cursor/rules/lumenflow.md.template +22 -2
- package/templates/vendors/windsurf/.windsurf/rules/lumenflow.md.template +22 -2
|
@@ -0,0 +1,402 @@
|
|
|
1
|
+
# Initiative Orchestration Guide
|
|
2
|
+
|
|
3
|
+
**Last updated:** {{DATE}}
|
|
4
|
+
|
|
5
|
+
Step-by-step guide for agents orchestrating multi-WU initiatives. This document ties together the orchestration, delegation, memory coordination, and failure recovery patterns into a single prescriptive workflow.
|
|
6
|
+
|
|
7
|
+
---
|
|
8
|
+
|
|
9
|
+
## Prerequisites
|
|
10
|
+
|
|
11
|
+
Before orchestrating an initiative, ensure:
|
|
12
|
+
|
|
13
|
+
1. The initiative YAML exists at `docs/04-operations/tasks/initiatives/INIT-XXX.yaml`
|
|
14
|
+
2. All WUs are linked to the initiative via `initiative:add-wu`
|
|
15
|
+
3. Dependencies between WUs are defined (blocking relationships)
|
|
16
|
+
4. Lane lifecycle is locked (`pnpm lane:status` shows `locked`)
|
|
17
|
+
|
|
18
|
+
---
|
|
19
|
+
|
|
20
|
+
## Step-by-Step: Orchestrating an Initiative
|
|
21
|
+
|
|
22
|
+
### Step 1: Assess the Initiative
|
|
23
|
+
|
|
24
|
+
```bash
|
|
25
|
+
# Check initiative status and WU breakdown
|
|
26
|
+
pnpm initiative:status --id INIT-XXX
|
|
27
|
+
|
|
28
|
+
# Preview the execution plan (dry run)
|
|
29
|
+
pnpm orchestrate:initiative --initiative INIT-XXX --dry-run
|
|
30
|
+
```
|
|
31
|
+
|
|
32
|
+
The dry-run output shows:
|
|
33
|
+
|
|
34
|
+
- **Waves**: Groups of WUs that can run in parallel (computed via topological sort)
|
|
35
|
+
- **Bottleneck WUs**: WUs that block the most downstream work (prioritize these)
|
|
36
|
+
- **Recommended execution mode**: Checkpoint-per-wave vs continuous
|
|
37
|
+
|
|
38
|
+
### Step 2: Choose Execution Mode
|
|
39
|
+
|
|
40
|
+
| Mode | Command | When to use |
|
|
41
|
+
| --------------------- | ---------------------------------------------------- | -------------------------------------- |
|
|
42
|
+
| Checkpoint-per-wave | `pnpm orchestrate:initiative -i INIT-XXX -c` | Large initiatives (>3 WUs or >2 waves) |
|
|
43
|
+
| Continuous | `pnpm orchestrate:initiative -i INIT-XXX` | Small initiatives (<=3 WUs, 1-2 waves) |
|
|
44
|
+
| Manual brief/delegate | `pnpm wu:brief --id WU-XXX --client <client>` per WU | Testing individual WUs, debugging |
|
|
45
|
+
| Manual self-implement | `pnpm wu:brief --id WU-XXX --evidence-only` per WU | You are implementing without sub-agent |
|
|
46
|
+
|
|
47
|
+
Checkpoint-per-wave is recommended for most initiatives. It processes one wave at a time and writes a manifest before exiting, giving you control between waves.
|
|
48
|
+
|
|
49
|
+
### Step 3: Delegate WUs
|
|
50
|
+
|
|
51
|
+
For each WU in the current wave, choose delegation vs self-implementation:
|
|
52
|
+
|
|
53
|
+
```bash
|
|
54
|
+
# Option A: Generate prompt + evidence (no lineage side effect)
|
|
55
|
+
pnpm wu:brief --id WU-100 --client claude-code
|
|
56
|
+
|
|
57
|
+
# Option B: Generate prompt + record delegation lineage (for audit)
|
|
58
|
+
pnpm wu:delegate --id WU-100 --parent-wu WU-050 --client claude-code
|
|
59
|
+
|
|
60
|
+
# Option C: Record evidence only, then implement in current session (no spawn prompt output)
|
|
61
|
+
pnpm wu:brief --id WU-100 --evidence-only
|
|
62
|
+
```
|
|
63
|
+
|
|
64
|
+
**Use `wu:delegate` (not `wu:brief`) when:**
|
|
65
|
+
|
|
66
|
+
- You are the orchestrator agent managing the initiative
|
|
67
|
+
- You need an audit trail of who-delegated-what
|
|
68
|
+
- The initiative has more than one wave
|
|
69
|
+
|
|
70
|
+
**Use `wu:brief --evidence-only` when:**
|
|
71
|
+
|
|
72
|
+
- You are not handing WU ownership to a sub-agent
|
|
73
|
+
- You still need `wu:brief` evidence for `wu:done` policy
|
|
74
|
+
- You will implement directly in the current session
|
|
75
|
+
|
|
76
|
+
**Verification checklist before spawning:**
|
|
77
|
+
|
|
78
|
+
1. The generated prompt ends with `<!-- LUMENFLOW_SPAWN_END -->`
|
|
79
|
+
2. The `</constraints>` block is present near the end
|
|
80
|
+
3. The `LUMENFLOW_TRUNCATION_WARNING` banner is at the start
|
|
81
|
+
|
|
82
|
+
If any of these are missing, the prompt was truncated. Re-generate it or use `--codex` for a shorter format.
|
|
83
|
+
|
|
84
|
+
### Step 4: Monitor Progress
|
|
85
|
+
|
|
86
|
+
Between waves (or during continuous execution), monitor agent progress:
|
|
87
|
+
|
|
88
|
+
```bash
|
|
89
|
+
# Check for coordination signals from spawned agents
|
|
90
|
+
pnpm mem:inbox --since 30m
|
|
91
|
+
|
|
92
|
+
# Compact progress view
|
|
93
|
+
pnpm orchestrate:init-status -i INIT-XXX
|
|
94
|
+
|
|
95
|
+
# Check for stuck or crashed agents
|
|
96
|
+
pnpm orchestrate:monitor --initiative INIT-XXX
|
|
97
|
+
|
|
98
|
+
# View delegation tree
|
|
99
|
+
pnpm delegation:list --initiative INIT-XXX
|
|
100
|
+
```
|
|
101
|
+
|
|
102
|
+
**Do NOT use TaskOutput to poll agent progress** -- it causes context explosion. Use `mem:inbox` instead.
|
|
103
|
+
|
|
104
|
+
### Step 5: Advance to Next Wave
|
|
105
|
+
|
|
106
|
+
After all WUs in the current wave are complete:
|
|
107
|
+
|
|
108
|
+
```bash
|
|
109
|
+
# Re-run orchestrate (idempotent -- skips completed WUs, advances to next wave)
|
|
110
|
+
pnpm orchestrate:initiative -i INIT-XXX -c
|
|
111
|
+
```
|
|
112
|
+
|
|
113
|
+
Repeat Steps 4-5 until all waves are complete.
|
|
114
|
+
|
|
115
|
+
### Step 6: Verify Completion
|
|
116
|
+
|
|
117
|
+
```bash
|
|
118
|
+
# Final status check
|
|
119
|
+
pnpm initiative:status --id INIT-XXX
|
|
120
|
+
|
|
121
|
+
# Mark initiative as done
|
|
122
|
+
pnpm initiative:edit --id INIT-XXX --status done
|
|
123
|
+
```
|
|
124
|
+
|
|
125
|
+
---
|
|
126
|
+
|
|
127
|
+
## Memory Coordination Between Waves
|
|
128
|
+
|
|
129
|
+
Agents coordinate through the memory layer. Here is the signal flow during multi-wave execution.
|
|
130
|
+
|
|
131
|
+
### Signal Flow
|
|
132
|
+
|
|
133
|
+
```
|
|
134
|
+
Wave 1 Agent (WU-100) Orchestrator
|
|
135
|
+
│ │
|
|
136
|
+
├── works on WU-100 │
|
|
137
|
+
├── wu:done (auto-broadcasts signal) │
|
|
138
|
+
│ │
|
|
139
|
+
│ ├── mem:inbox --since 30m
|
|
140
|
+
│ ├── (sees: "WU-100 complete")
|
|
141
|
+
│ ├── orchestrate:init-status
|
|
142
|
+
│ ├── (sees: Wave 1 complete)
|
|
143
|
+
│ ├── orchestrate:initiative -c
|
|
144
|
+
│ │ (spawns Wave 2)
|
|
145
|
+
│ │
|
|
146
|
+
Wave 2 Agent (WU-103) │
|
|
147
|
+
│ │
|
|
148
|
+
├── works on WU-103 │
|
|
149
|
+
└── wu:done (auto-broadcasts signal) │
|
|
150
|
+
```
|
|
151
|
+
|
|
152
|
+
### Key Commands
|
|
153
|
+
|
|
154
|
+
| Command | Who runs it | When |
|
|
155
|
+
| -------------------------------- | -------------- | ----------------------------- |
|
|
156
|
+
| `mem:signal "msg" --wu WU-XXX` | Worker agent | After significant progress |
|
|
157
|
+
| `mem:inbox --since <duration>` | Orchestrator | Between waves, during polling |
|
|
158
|
+
| `mem:checkpoint "msg" --wu WU-X` | Worker agent | Before risky operations |
|
|
159
|
+
| `mem:ready --wu WU-XXX` | Recovery agent | When taking over a stuck WU |
|
|
160
|
+
|
|
161
|
+
### Signal Storage
|
|
162
|
+
|
|
163
|
+
All signals are written to `.lumenflow/memory/signals.jsonl` as append-only JSONL. Signals produce immutable receipts and support read-state tracking (marking signals as read after consumption).
|
|
164
|
+
|
|
165
|
+
---
|
|
166
|
+
|
|
167
|
+
## Checkpoint-Per-Wave Mechanics
|
|
168
|
+
|
|
169
|
+
### How Manifests Work
|
|
170
|
+
|
|
171
|
+
When running with `--checkpoint-per-wave` (or `-c`):
|
|
172
|
+
|
|
173
|
+
1. The orchestrator computes wave groupings using Kahn's algorithm on WU dependencies
|
|
174
|
+
2. For the current wave, it spawns agents for all ready WUs
|
|
175
|
+
3. It writes a manifest to `.lumenflow/artifacts/waves/INIT-XXX-wave-N.json`
|
|
176
|
+
4. It exits (does not poll or wait)
|
|
177
|
+
|
|
178
|
+
### Manifest Contents
|
|
179
|
+
|
|
180
|
+
```json
|
|
181
|
+
{
|
|
182
|
+
"initiative": "INIT-XXX",
|
|
183
|
+
"wave": 1,
|
|
184
|
+
"wus": ["WU-100", "WU-101", "WU-102"],
|
|
185
|
+
"spawned_at": "{{DATE}}T10:00:00Z",
|
|
186
|
+
"agent_ids": ["agent-abc", "agent-def", "agent-ghi"],
|
|
187
|
+
"status": {
|
|
188
|
+
"WU-100": "in_progress",
|
|
189
|
+
"WU-101": "in_progress",
|
|
190
|
+
"WU-102": "in_progress"
|
|
191
|
+
}
|
|
192
|
+
}
|
|
193
|
+
```
|
|
194
|
+
|
|
195
|
+
### Idempotent Re-Runs
|
|
196
|
+
|
|
197
|
+
If the orchestrator crashes or is interrupted:
|
|
198
|
+
|
|
199
|
+
- Re-running `orchestrate:initiative -i INIT-XXX -c` reads the existing manifest
|
|
200
|
+
- WUs with `status: done` in their YAML are skipped
|
|
201
|
+
- WUs still `ready` or `in_progress` are re-spawned
|
|
202
|
+
- Once all WUs in the wave are done, the next wave begins
|
|
203
|
+
|
|
204
|
+
This makes checkpoint mode safe to interrupt and resume at any point.
|
|
205
|
+
|
|
206
|
+
### Auto-Detection
|
|
207
|
+
|
|
208
|
+
Checkpoint mode is auto-enabled when an initiative has:
|
|
209
|
+
|
|
210
|
+
- More than 3 WUs, OR
|
|
211
|
+
- More than 2 waves
|
|
212
|
+
|
|
213
|
+
You can always pass `-c` explicitly for smaller initiatives.
|
|
214
|
+
|
|
215
|
+
---
|
|
216
|
+
|
|
217
|
+
## Failure Recovery Playbook
|
|
218
|
+
|
|
219
|
+
### Escalation Levels
|
|
220
|
+
|
|
221
|
+
The orchestration system uses a 3-level escalation model:
|
|
222
|
+
|
|
223
|
+
| Attempt | Severity | Action | What happens |
|
|
224
|
+
| ------- | ---------- | ---------------- | -------------------------------------------------- |
|
|
225
|
+
| 1st | `warning` | Retry | Re-spawn agent with same parameters |
|
|
226
|
+
| 2nd | `error` | Block | Mark WU blocked, notify parallel agents via signal |
|
|
227
|
+
| 3rd+ | `critical` | Human escalation | Create Bug WU, alert human operator |
|
|
228
|
+
|
|
229
|
+
### Detection: Finding Stuck Agents
|
|
230
|
+
|
|
231
|
+
```bash
|
|
232
|
+
# Default threshold: 30 minutes without progress
|
|
233
|
+
pnpm orchestrate:monitor
|
|
234
|
+
|
|
235
|
+
# Custom threshold (in minutes)
|
|
236
|
+
pnpm orchestrate:monitor --threshold 60
|
|
237
|
+
|
|
238
|
+
# Filter to initiative
|
|
239
|
+
pnpm orchestrate:monitor --initiative INIT-XXX
|
|
240
|
+
```
|
|
241
|
+
|
|
242
|
+
The monitor checks:
|
|
243
|
+
|
|
244
|
+
- Spawn registry for agents that have not completed within the threshold
|
|
245
|
+
- Lane locks that reference dead processes (zombie locks)
|
|
246
|
+
- Memory signals for explicit failure broadcasts
|
|
247
|
+
|
|
248
|
+
### Recovery: Step-by-Step
|
|
249
|
+
|
|
250
|
+
**Scenario 1: Agent stuck (no progress, but process may still be running)**
|
|
251
|
+
|
|
252
|
+
```bash
|
|
253
|
+
# 1. Block the WU
|
|
254
|
+
pnpm wu:block --id WU-100 --reason "Agent stuck for 45 minutes, no progress signals"
|
|
255
|
+
|
|
256
|
+
# 2. Check what the agent accomplished
|
|
257
|
+
pnpm mem:ready --wu WU-100
|
|
258
|
+
|
|
259
|
+
# 3. Unblock and re-delegate
|
|
260
|
+
pnpm wu:unblock --id WU-100
|
|
261
|
+
pnpm wu:brief --id WU-100 --client claude-code
|
|
262
|
+
```
|
|
263
|
+
|
|
264
|
+
**Scenario 2: Zombie lane lock (agent process died, lock remains)**
|
|
265
|
+
|
|
266
|
+
```bash
|
|
267
|
+
# 1. Identify the zombie lock
|
|
268
|
+
pnpm orchestrate:monitor # Shows "Zombie lock (PID XXXXX not running)"
|
|
269
|
+
|
|
270
|
+
# 2. Unlock the lane
|
|
271
|
+
pnpm lane:unlock "Framework: Core" --reason "Zombie lock (PID 12345 not running)"
|
|
272
|
+
|
|
273
|
+
# 3. Release and re-claim the WU
|
|
274
|
+
pnpm wu:release --id WU-100
|
|
275
|
+
pnpm wu:claim --id WU-100 --lane "Framework: Core"
|
|
276
|
+
```
|
|
277
|
+
|
|
278
|
+
**Scenario 3: Agent crashed, worktree left behind**
|
|
279
|
+
|
|
280
|
+
```bash
|
|
281
|
+
# 1. Inspect the worktree
|
|
282
|
+
cd worktrees/<lane>-wu-100
|
|
283
|
+
git log --oneline -5 # What did they commit?
|
|
284
|
+
git status # Any uncommitted work?
|
|
285
|
+
|
|
286
|
+
# 2. Check last checkpoint
|
|
287
|
+
pnpm mem:ready --wu WU-100
|
|
288
|
+
|
|
289
|
+
# 3. Either resume (continue from checkpoint) or release
|
|
290
|
+
# Resume: stay in worktree, continue the work
|
|
291
|
+
# Release: pnpm wu:release --id WU-100
|
|
292
|
+
```
|
|
293
|
+
|
|
294
|
+
**Scenario 4: Repeated failures (3+ attempts)**
|
|
295
|
+
|
|
296
|
+
At this point, stop automated retries and create a Bug WU:
|
|
297
|
+
|
|
298
|
+
```bash
|
|
299
|
+
# The orchestrate:monitor output will suggest this
|
|
300
|
+
pnpm wu:create --lane "Operations: Tooling" \
|
|
301
|
+
--title "Bug: WU-100 repeatedly fails during INIT-XXX" \
|
|
302
|
+
--type bug \
|
|
303
|
+
--description "WU-100 has failed 3 times during initiative orchestration. ..."
|
|
304
|
+
```
|
|
305
|
+
|
|
306
|
+
### Self-Healing Signal Flow
|
|
307
|
+
|
|
308
|
+
The recovery system is agent-in-loop, not fully automated:
|
|
309
|
+
|
|
310
|
+
1. `orchestrate:monitor` detects the stuck spawn
|
|
311
|
+
2. `recoverStuckSpawn()` attempts automatic recovery (retry)
|
|
312
|
+
3. If auto-recovery fails, `signalOrchestratorFailure()` broadcasts a `spawn_failure` signal
|
|
313
|
+
4. The orchestrator reads the signal via `mem:inbox --type spawn_failure`
|
|
314
|
+
5. The orchestrator decides: retry, block, or escalate to human
|
|
315
|
+
|
|
316
|
+
```bash
|
|
317
|
+
# Check for failure signals specifically
|
|
318
|
+
pnpm mem:inbox --wu WU-100 --type spawn_failure
|
|
319
|
+
```
|
|
320
|
+
|
|
321
|
+
---
|
|
322
|
+
|
|
323
|
+
## Delegation Lineage
|
|
324
|
+
|
|
325
|
+
### Why Lineage Matters
|
|
326
|
+
|
|
327
|
+
When multiple agents work on an initiative, you need to answer:
|
|
328
|
+
|
|
329
|
+
- Which agent was responsible for WU-100?
|
|
330
|
+
- Who delegated it, and when?
|
|
331
|
+
- What is the current state of every delegation?
|
|
332
|
+
|
|
333
|
+
### Recording Lineage
|
|
334
|
+
|
|
335
|
+
Use `wu:delegate` instead of `wu:brief` for auditable delegation:
|
|
336
|
+
|
|
337
|
+
```bash
|
|
338
|
+
pnpm wu:delegate --id WU-100 --parent-wu WU-050 --client claude-code
|
|
339
|
+
```
|
|
340
|
+
|
|
341
|
+
This records a delegation record with:
|
|
342
|
+
|
|
343
|
+
- `parent_wu`: The orchestrator or coordinator WU
|
|
344
|
+
- `child_wu`: The delegated WU
|
|
345
|
+
- `client`: The agent type
|
|
346
|
+
- `state`: `pending` (initial), then `completed`, `timeout`, `crashed`, or `escalated`
|
|
347
|
+
- `timestamp`: When delegation occurred
|
|
348
|
+
|
|
349
|
+
### Viewing the Tree
|
|
350
|
+
|
|
351
|
+
```bash
|
|
352
|
+
# All delegations for a WU
|
|
353
|
+
pnpm delegation:list --wu WU-050
|
|
354
|
+
|
|
355
|
+
# All delegations for an initiative
|
|
356
|
+
pnpm delegation:list --initiative INIT-XXX
|
|
357
|
+
|
|
358
|
+
# JSON output for programmatic use
|
|
359
|
+
pnpm delegation:list --initiative INIT-XXX --json
|
|
360
|
+
```
|
|
361
|
+
|
|
362
|
+
### Delegation States
|
|
363
|
+
|
|
364
|
+
| State | Meaning |
|
|
365
|
+
| ----------- | ------------------------------------------------ |
|
|
366
|
+
| `pending` | Agent spawned but not yet complete |
|
|
367
|
+
| `completed` | WU completed successfully (wu:done ran) |
|
|
368
|
+
| `timeout` | Agent exceeded time threshold without completing |
|
|
369
|
+
| `crashed` | Agent process terminated unexpectedly |
|
|
370
|
+
| `escalated` | Repeated failures, escalated to human |
|
|
371
|
+
|
|
372
|
+
---
|
|
373
|
+
|
|
374
|
+
## Quick Reference: All Orchestration Commands
|
|
375
|
+
|
|
376
|
+
| Command | Description |
|
|
377
|
+
| --------------------------------------------------- | ------------------------------------------------------------- |
|
|
378
|
+
| `pnpm orchestrate:initiative -i INIT-XXX --dry-run` | Preview wave plan without executing |
|
|
379
|
+
| `pnpm orchestrate:initiative -i INIT-XXX -c` | Execute one wave then checkpoint and exit |
|
|
380
|
+
| `pnpm orchestrate:initiative -i INIT-XXX` | Execute all waves continuously |
|
|
381
|
+
| `pnpm orchestrate:init-status -i INIT-XXX` | Compact progress view |
|
|
382
|
+
| `pnpm orchestrate:monitor` | Detect stuck agents and zombie locks |
|
|
383
|
+
| `pnpm wu:brief --id WU-XXX --client <client>` | Generate handoff prompt + evidence (claimed workspace/branch) |
|
|
384
|
+
| `pnpm wu:brief --id WU-XXX --evidence-only` | Record evidence only (self-implementation path) |
|
|
385
|
+
| `pnpm wu:delegate --id WU-XXX --parent-wu <P>` | Generate prompt + record delegation |
|
|
386
|
+
| `pnpm delegation:list --initiative INIT-XXX` | View delegation tree |
|
|
387
|
+
| `pnpm mem:signal "msg" --wu WU-XXX` | Broadcast coordination signal |
|
|
388
|
+
| `pnpm mem:inbox --since <duration>` | Read coordination signals |
|
|
389
|
+
| `pnpm mem:checkpoint "msg" --wu WU-XXX` | Save progress checkpoint |
|
|
390
|
+
| `pnpm mem:ready --wu WU-XXX` | Check pending work/checkpoints |
|
|
391
|
+
| `pnpm wu:block --id WU-XXX --reason "..."` | Block stuck WU |
|
|
392
|
+
| `pnpm wu:unblock --id WU-XXX` | Unblock recovered WU |
|
|
393
|
+
| `pnpm wu:release --id WU-XXX` | Release abandoned WU for re-claim |
|
|
394
|
+
|
|
395
|
+
---
|
|
396
|
+
|
|
397
|
+
## Related Documents
|
|
398
|
+
|
|
399
|
+
- [Initiatives Guide (Starlight)](../../../../../../apps/docs/src/content/docs/guides/initiatives.mdx) -- Public user-facing documentation
|
|
400
|
+
- [Quick Reference: Commands](quick-ref-commands.md) -- Complete CLI command reference
|
|
401
|
+
- [Starting Prompt](starting-prompt.md) -- Agent onboarding entry point
|
|
402
|
+
- [Agent Invocation Guide](agent-invocation-guide.md) -- When to use wu:brief vs wu:delegate vs inline context
|