Grand Diomande Research · Full HTML Reader

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.

Agents That Account for Themselves research note experiment writeup candidate score 32 .md

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 context

Dispatch Scripts

ScriptPathVersionWhat 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]`v1Prompt 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 events

CLI

bash
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:

StageNameWhat It Does
Stage 1EXPLORE3-6 divergent evolution paths (genuinely different directions)
Stage 2COMPOUNDBuild best elements into unified system, each step inherits ALL previous
Stage 3EXPAND + MASTER PLANStress-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

EvolutionScore ChangeStatus
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

WaveNameAgentsStatusCompleted
1Foundation6 (A1-A6)Feb 15 21:35
2Core Services5 (B1-B5)Feb 16 09:30
3API Surface6 (C1-C6)Feb 16 11:31
4Platform Integration6 (D1-D6)Feb 16 12:02
5Features4/6 (E1-E3,E5)Feb 16 13:21
6Autonomy2/5 (F4-F5)Feb 16 16:28
7Harden5 (G1-G5)Feb 16 16:xx
8Ship5 (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

ChannelIDRole
#pulse-v1-sprint1473069789931897028Sprint execution (waves + threads)
#pulse-vision-pipeline1473071832784572436Vision pipeline waves
#pulse-feed1470138461989376000Master status tracker
#pulse-control1470138458214367396Start/pause/abort
#pulse-archive1470138465869107354Completed summaries
Wave 2 thread1472833423692529891V1 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