docs(driver-v5): rewrite swarm reference with real commands (maf.3)

This commit is contained in:
ZenchantLive 2026-03-03 18:57:16 -08:00
parent 801389e87c
commit 645f66a734

View file

@ -1,96 +1,172 @@
# Archetypes, Templates, and Swarms # Archetypes, Templates, and Swarms
## Purpose This document defines how multi-agent work is structured so any agent can join, execute, and exit cleanly.
Define reusable team structure for multi-agent work so assignments are predictable, auditable, and easy for users to orchestrate from BeadBoard. ## Mental Model
## Core Principle - Archetype: role contract (what an agent is accountable for)
- Template/proto: reusable work shape (molecule source)
- Swarm: live execution instance over an epic (or auto-wrapped task)
Archetypes and templates define team composition. Missions define task execution. ## Verified Command Surface
Keep these concerns separate. Swarm lifecycle:
## Archetypes (Role Contracts) ```bash
bd swarm create <epic-id> [--coordinator <rig/witness>] [--force]
bd swarm status <epic-or-swarm-id> [--json]
bd swarm list [--json]
bd swarm validate <epic-id> [--verbose]
```
An archetype is a role with clear responsibilities and deliverable expectations. Template/proto discovery:
Baseline archetypes: ```bash
bd mol show <molecule-id> [--parallel]
```
- `coder`: implements scoped changes and provides evidence. ## Swarm Creation and Discovery
- `reviewer`: validates quality, regressions, and acceptance criteria.
- `writer`: maintains user-facing docs, memory docs, and operator notes.
Optional archetypes may exist per project, but every archetype should specify: Create a swarm for an epic:
- primary responsibilities, ```bash
- quality gates, bd swarm create beadboard-maf --coordinator beadboard/witness
- handoff inputs/outputs, ```
- escalation triggers.
## Team Templates (Composition Contracts) If you create from a single task, `bd` can auto-wrap it into an epic and then create swarm.
A template is a named role composition for repeatable work patterns. Find active swarms:
Examples: ```bash
bd swarm list
```
- Fast lane: `coder + reviewer` Inspect swarm execution state (computed from beads):
- Documentation lane: `writer + reviewer`
- Parallel lane: `orchestrator + coder + reviewer + writer`
Template quality rules: ```bash
bd swarm status beadboard-maf
```
- keep composition minimal, Validate dependency quality before dispatch:
- avoid duplicate authority,
- define ownership boundaries,
- define expected handoff order.
## Swarms (Runtime Team Instances) ```bash
bd swarm validate beadboard-maf --verbose
```
A swarm is a live team instance operating on specific beads/epics. ## Template/Proto Traceability
Lifecycle: To understand what pattern a swarm or molecule came from, inspect molecule structure:
1. Create swarm instance from a template or manual composition. ```bash
2. Join agents into explicit roles. bd mol show <molecule-id> --parallel
3. Assign beads with ownership. ```
4. Coordinate via events and inbox.
5. Leave or close swarm cleanly when complete.
## Command Surface (Representative) Use this to answer:
- Which steps can run in parallel right now
- Which steps are dependency-blocked
- Which work shape this execution follows
Use your environment's swarm commands to manage lifecycle. ## Archetype Contracts
Expected operations: ### Coder
- create swarm Primary responsibility:
- list/show swarm - Implement scoped changes for assigned bead
- join swarm with role
- leave swarm
- close swarm
All swarm actions should produce observable state changes in BeadBoard views. Quality gates:
- `npm run typecheck`
- `npm run lint`
- `npm run test` (or focused + full as required)
## Ownership Rules Handoff payload:
- File list changed
- Commands run + pass/fail
- Remaining risks
- Every in-progress bead should have one clear assignee. Escalation triggers:
- Swarms may collaborate on an epic, but each bead needs an explicit owner. - Missing dependency/input
- Multi-agent edits require reservation and coordination signals. - Conflicting ownership or reservation
- Repeated failing gate without clear root cause
## User Orchestration Relationship ### Reviewer
Users control orchestration from BeadBoard UI: Primary responsibility:
- Validate behavior, regressions, and acceptance criteria
- choose team shape/template, Quality gates:
- assign or reassign roles, - Reproduce relevant tests
- intervene on blockers, - Check edge-case behavior against bead contract
- monitor throughput and liveness.
Agents execute according to assigned role and bead ownership. Handoff payload:
- Findings ordered by severity
- Explicit “no findings” when clean
- Residual risk/testing gaps
Escalation triggers:
- Spec ambiguity affecting correctness
- Inconsistent cross-view behavior
- Insufficient evidence to approve close
### Writer
Primary responsibility:
- Keep user-facing and operator docs accurate and action-oriented
Quality gates:
- Command examples match real CLI help
- Scope/out-of-scope and verification sections are explicit
Handoff payload:
- Updated doc paths
- User impact summary
- Remaining docs debt
Escalation triggers:
- Command surface changed but docs unclear
- Contradictory references across skill docs
## Worker Join Flow (Not Just Orchestrators)
1. Check active swarms and pick assigned epic:
```bash
bd swarm list
bd swarm status <epic-or-swarm-id>
```
2. Read epic + children context before claiming:
```bash
bd show <epic-id>
bd children <epic-id>
bd ready
```
3. Claim assigned bead with explicit assignee and attach hook slot:
```bash
bd update <bead-id> --status in_progress --assignee <agent-bead-id>
bd slot set <agent-bead-id> hook <bead-id>
```
4. Report state and coordinate through mail/events while executing.
## Swarm Closure Ownership
Default ownership:
- Orchestrator/coordinator closes swarm context after all child beads close
- Workers close only their assigned beads and clear their hook slots
Closure checklist:
1. No open child beads remain for the swarm epic
2. No unresolved BLOCKED handoffs remain
3. Required verification evidence exists on completed beads
4. Coordinator posts close summary and archives follow-ups as new beads
## Anti-Patterns ## Anti-Patterns
- Role ambiguity (multiple agents assuming same responsibility). - Starting swarm work without reading epic dependencies
- Oversized swarms with no clear ownership boundaries. - Treating templates as optional and inventing ad-hoc flows each run
- Using templates as mission definitions. - Claiming multiple beads without explicit ownership updates
- Running unassigned parallel work with no bead claim. - Closing swarm before child verification evidence exists
- Treating swarm closure as optional housekeeping. - Hiding blocker state in chat instead of machine-readable bead/mail signals