Pulse Chain System — Living Documentation
A Pulse Chain is a **self-orchestrating multi-agent pipeline** that uses Discord as its execution spine. Work decomposes into **waves** (phases), each wave runs **parallel agents**, and completion of one wave auto-triggers the next.
Full Public Reader
Pulse Chain System — Living Documentation
> Last updated: 2026-02-16 18:25 EST
> Status: Active sprint, Wave 8 in progress | Evo³ running on orchestration layer
---
What Is a Pulse Chain?
A Pulse Chain is a self-orchestrating multi-agent pipeline that uses Discord as its execution spine. Work decomposes into waves (phases), each wave runs parallel agents, and completion of one wave auto-triggers the next.
Key principle: Discord's structure IS the execution graph.
Category = Project/Chain scope
Channel = Specific chain instance
Message = Wave/Phase definition
Thread = Individual agent task execution---
Discord Hierarchy
🔄 Pulse Chains (category)
├── #pulse-v1-sprint (channel — this sprint)
│ ├── Wave 1 ✅ — Foundation (A1-A6)
│ ├── Wave 2 ✅ — Core Services (B1-B5)
│ ├── Wave 3 ✅ — API Surface (C1-C6)
│ ├── Wave 4 ✅ — Platform Integration (D1-D6)
│ ├── Wave 5 ✅ — Features (E1-E3, E5)
│ ├── Wave 6 ✅ — Autonomy (F4-F5)
│ ├── Wave 7 ✅ — Harden (G1-G5)
│ ├── Wave 8 🟡 — Ship (H1-H5)
│ └── Vision Pipeline 🟡 — (V1-V6)
├── #pulse-vision-pipeline (vision chain)
├── #pulse-feed (master status)
└── #pulse-control (orchestration commands)Constraint: Discord allows Category → Channel → Message → Thread. No sub-sub-threads. Deep dives branch into sub-pulses (new threads on new messages within the same channel).
---
Enrichment Architecture
> Rule: NEVER dispatch a bare `claude -p` prompt. EVER.
> Learned 2026-02-16: Bypassing enrichment to "save time" produces inferior output and wastes more time re-doing poor work.
What Every Sub-Agent Receives (13KB enriched prompt)
┌─────────────────────────────────────────────────┐
│ ENRICHED SUB-AGENT TASK │
├─────────────────────────────────────────────────┤
│ 1. AGENTS.md (80 lines) │
│ - Task Persistence Protocol │
│ - Momentum Continuation │
│ - RTD 6-level verification │
│ - "Never bypass enrichment" rule │
│ - Safety & memory protocols │
├─────────────────────────────────────────────────┤
│ 2. SOUL.md (50 lines) │
│ - Quality bar: Extravagant > Elegant > ... │
│ - Personality & communication style │
│ - The ALL Pattern — parallel execution │
│ - "Decide and execute, never ask what next" │
├─────────────────────────────────────────────────┤
│ 3. Project CLAUDE.md (full) │
│ - Architecture, code style, key files │
│ - Project-specific protocols │
├─────────────────────────────────────────────────┤
│ 4. DEP — Deep Enhancement Protocol (inlined) │
│ - Anticipation-driven depth control │
│ - RLM commitment/uncertainty 2D space │
│ - TIE creative techniques │
│ - Every agent ENHANCES, not just implements │
├─────────────────────────────────────────────────┤
│ 5. Detected Skills (up to 5) │
│ - ios-deploy, evo-cubed, cae, etc. │
├─────────────────────────────────────────────────┤
│ 6. CEF (Chunked Evil Flow) — if multi-step │
│ - Chunk decomposition for complex tasks │
├─────────────────────────────────────────────────┤
│ 7. Quality Gates │
│ - Build check, conventional commits │
│ - No secrets, proper formatting │
├─────────────────────────────────────────────────┤
│ 8. Completion Report Format │
│ - Structured output for chain tracking │
└─────────────────────────────────────────────────┘Enrichment Flow
Task String
│
▼
enriched_spawn.py ──→ Detects skills (DEP always included)
│ Loads AGENTS.md (80 lines)
│ Loads SOUL.md (50 lines)
│ Loads project CLAUDE.md
│ Inlines DEP content
│ Adds RTD, quality gates, CEF
│
▼
13KB Enriched Prompt ──→ claude -p (via stdin pipe)
│
▼
Agent executes with full governance contextDispatch Scripts
| Script | Path | Version | What It Does |
|---|---|---|---|
| `chain-engine.py` | `[home-path]` | v1 (Evo³) | Declarative chain evaluator + state machine + dispatcher |
| `wave-watcher.sh` | `[home-path]` | v4 (Evo³) | Cron orchestrator — delegates to chain-engine |
| `enriched-dual-dispatch.sh` | `[home-path]` | v2 (Evo³) | Single task → enriched → routes to least-busy Max account |
| `parallel-dispatch.sh` | `[home-path]` | v2 (Evo³) | Two tasks → both enriched → account1 + account2 simultaneously |
| `enriched_spawn.py` | `[home-path]` | v1 | Prompt builder — injects AGENTS.md, SOUL.md, CLAUDE.md, DEP, skills |
| `pulse-health-reporter.sh` | `Desktop/pulse-v1/` | v2 (Evo³) | Health check with chain-engine integration |
| `pulse-health-reporter.sh` | `[home-path]` | Health check — agent status, stale detection, capacity |
---
Auto-Trigger Protocol
When a task is identified (via conversation, heartbeat, or cron):
1. Classify — Is this an agent task? (code change, research, build, test)
2. Route — Which chain/channel does it belong to?
3. Create — Post a wave message in the channel
4. Thread — Create threads for each agent task on that message
5. Enrich — Build enriched prompt via `enriched_spawn.py` (MANDATORY)
6. Dispatch — Launch agents via enriched dispatch on available Max account
7. Monitor — Agents write completion files + post to their thread
8. Chain — On wave completion, auto-launch next wave
Detection Heuristic
IF message contains:
- Code task (build, fix, implement, refactor)
- Multi-step plan (phases, waves, steps)
- Multiple projects affected
THEN:
→ Suggest: "This looks like a Pulse Chain. Create in #pulse-v1-sprint?"
→ If confirmed or obvious: auto-create---
Wave Watcher v4 (Evo³ Upgrade)
The wave watcher runs every 5 minutes via cron. It delegates to `chain-engine.py` for all wave evaluation and dispatch logic.
Architecture (Evo2)
[home-path] ← Declarative chain definitions
[home-path]
chain-engine.py ← State machine + gate evaluator + dispatcher
wave-watcher.sh ← Cron entry point (lock, log, delegate)
wave-watcher-pids.json ← PID registry
wave-watcher-state.json ← Legacy state (retained for compat)
chain-*-state.json ← Per-chain state files
[home-path]
wave-watcher.log ← Human-readable log
wave-watcher.jsonl ← Structured JSONL for dashboards
chain-engine.jsonl ← Engine-level eventsCLI
wave-watcher.sh # Cron mode: evaluate + auto-dispatch
wave-watcher.sh --status # Print all chain status
wave-watcher.sh --status --json # JSON for dashboards
wave-watcher.sh --dispatch WAVE # Force-dispatch a wave
wave-watcher.sh --retry AGENT # Retry a failed agent
wave-watcher.sh --reap # Kill stale + auto-retry
wave-watcher.sh --help # Help
chain-engine.py evaluate # Evaluate all chain gates
chain-engine.py dispatch # Dispatch next ready wave
chain-engine.py retry H4 # Retry specific agent
chain-engine.py status --json # Full status with progress %
chain-engine.py list # List chain definitions### What It Checks
1. Stale agents — Kill agents >2h, auto-retry once
2. Chain gates — Evaluate YAML-defined gate conditions
3. Dispatch — Launch pending agents when gates satisfied
4. Chain completion — Detect when all waves done → notify Discord
5. JSONL logging — Every event logged for observability
State Machine
Agent States: PENDING → RUNNING → COMPLETE | STALE → KILLED → RETRY
Wave States: GATED → PENDING → RUNNING → COMPLETE | PARTIAL_FAIL### Security (Evo2.7)
- All Python state writes use `os.environ` (no shell injection via `$VAR` interpolation)
- Completion file paths validated before dispatch
- Agent processes verified alive after launch
---
Evolution Protocol
Evo³ (Evolution Cubed)
The Pulse system evolves through the Evo³ protocol — a three-stage recursive evolution:
| Stage | Name | What It Does |
|---|---|---|
| Stage 1 | EXPLORE | 3-6 divergent evolution paths (genuinely different directions) |
| Stage 2 | COMPOUND | Build best elements into unified system, each step inherits ALL previous |
| Stage 3 | EXPAND + MASTER PLAN | Stress-test, fill gaps, implement everything, produce master checklist |
DEP (Deep Enhancement Protocol)
Every agent applies DEP thinking — not just implementing, but enhancing:
Audit → Find gaps → Commit/Recurse/Branch/Abort decision →
If COMMIT: ship the enhancement
If RECURSE: go deeper on the same path
If BRANCH: fork parallel exploration paths
If ABORT: circuit-break (complexity ceiling reached)DEP uses a 2D decision space:
- X-axis: Commitment (how confident in the path)
- Y-axis: Uncertainty (how much is unknown)
Evolution History
| Evolution | Score Change | Status |
|---|---|---|
| Evo1 (wave-watcher v3) | 4.7 → 6.5 | ✅ Done |
| Evo² (architecture upgrades) | 6.5 → 8.0 | 🟡 In Evo³ |
| Evo³ (full system evolution) | 4.7 → 9.0+ target | 🟡 Running |
---
Sprint Scorecard
### Pulse V1 Sprint (Feb 15-28, 2026)
Goal: Ship 7 interconnected surfaces through unified Gateway API
| Wave | Name | Agents | Status | Completed |
|---|---|---|---|---|
| 1 | Foundation | 6 (A1-A6) | ✅ | Feb 15 21:35 |
| 2 | Core Services | 5 (B1-B5) | ✅ | Feb 16 09:30 |
| 3 | API Surface | 6 (C1-C6) | ✅ | Feb 16 11:31 |
| 4 | Platform Integration | 6 (D1-D6) | ✅ | Feb 16 12:02 |
| 5 | Features | 4/6 (E1-E3,E5) | ✅ | Feb 16 13:21 |
| 6 | Autonomy | 2/5 (F4-F5) | ✅ | Feb 16 16:28 |
| 7 | Harden | 5 (G1-G5) | ✅ | Feb 16 16:xx |
| 8 | Ship | 5 (H1-H5) | 🟡 | H1✅ H2✅ H3✅ H4⏳ H5⏳ |
Vision Pipeline:
| Wave | Agents | Status |
|------|--------|--------|
| V-Wave 1 | V1-V4 | ✅ V1✅ V2✅ V3✅ V4✅ |
| V-Wave 2 | V5-V6 | ⏳ Pending re-dispatch |
Gated tasks (Twin SFT): E4, E6, F1, F2, F3
### Projects Touched
| Project | Path | Waves |
|---------|------|-------|
| Gateway API | Desktop/pulse-gateway-api | 1-3, 5-8 |
| Agent Command Center | Desktop/AgentCommandCenter | 2, 4-6, 8 |
| Compass | Desktop/compass | 2-4, 7-8 |
| LifeOS | Desktop/lifeos | 2, 4-5, 7-8 |
| SecuriClaw | Desktop/SecuriClaw | V1-V6 |
| VisionClaw | Desktop/VisionClaw | V3-V4 |
| Pulse V1 (orchestration) | Desktop/pulse-v1 | Evo³ |
---
Channels
| Channel | ID | Role |
|---|---|---|
| #pulse-v1-sprint | 1473069789931897028 | Sprint execution (waves + threads) |
| #pulse-vision-pipeline | 1473071832784572436 | Vision pipeline waves |
| #pulse-feed | 1470138461989376000 | Master status tracker |
| #pulse-control | 1470138458214367396 | Start/pause/abort |
| #pulse-archive | 1470138465869107354 | Completed summaries |
| Wave 2 thread | 1472833423692529891 | V1 sprint updates |
---
Quality Enhancement Protocol
On re-run or audit, every agent applies the 6-level RTD verification:
1. Structure — Does the code/file structure make sense?
2. Compilation — Does each project compile clean?
3. Integration — Do cross-project dependencies resolve?
4. Content — Is the logic correct? Edge cases handled?
5. User Journey — Does the end-to-end flow work?
6. Deployment — Can this be built, tested, and shipped?
Plus DEP-specific checks:
- Gap analysis — What's missing? Dead code? Unused imports?
- Security — Env vars exposed? Auth bypasses?
- Documentation — Are completion files accurate?
- Enhancement — Did the agent improve what it touched, not just implement?
---
Lessons Learned
### 2026-02-16: Never Bypass Enrichment
What happened: Dispatched H4, H5, V5+V6 with bare `claude -p` because enriched-dual-dispatch.sh had a filename-too-long bug. Agents missed governance, skills, quality gates.
Fix: Fixed the bug (`LOG_FILE` sanitization). Upgraded `parallel-dispatch.sh` to run enrichment. Added rule to AGENTS.md.
Rule: When a dispatch script has a bug, FIX THE BUG. Never send bare prompts.
### 2026-02-16: DEP Is Always On
What happened: Sub-agents were implementing but not enhancing. DEP skill was rarely detected.
Fix: DEP (`sys:deep-enhance`) is now always injected and inlined in every enriched prompt. Not optional, not keyword-detected.
---
This document auto-updates. Last modified by Claw 🦞
Promotion Decision
Attach run IDs, datasets, metrics, and reproduction commands.
Source Anchor
PULSE-V1/PULSE_CHAIN_SYSTEM.md
Detected Structure
Method · Evaluation · Code Anchors · Architecture