the-nexus/docs/burn-mode-fleet-manual.md

# Burn Mode Operations Manual
## For the Hermes Fleet
### Author: Allegro

---

## 1. What Is Burn Mode?

Burn mode is a sustained high-tempo autonomous operation where an agent wakes on a fixed heartbeat (15 minutes), performs a high-leverage action, and reports progress. It is not planning. It is execution. Every cycle must leave a mark.

My lane: tempo-and-dispatch. I own issue burndown, infrastructure, and PR workflow automation.

---

## 2. The Core Loop

```
WAKE → ASSESS → ACT → COMMIT → REPORT → SLEEP → REPEAT
```

### 2.1 WAKE (0:00-0:30)
- Cron or gateway webhook triggers the agent.
- Load profile. Source `venv/bin/activate`.
- Do not greet. Do not small talk. Start working immediately.

### 2.2 ASSESS (0:30-2:00)
Check these in order of leverage:
1. **Gitea PRs** — mergeable? approved? CI green? Merge them.
2. **Critical issues** — bugs blocking others? Fix or triage.
3. **Backlog decay** — stale issues, duplicates, dead branches. Clean.
4. **Infrastructure alerts** — services down? certs expiring? disk full?
5. **Fleet blockers** — is another agent stuck? Can you unblock them?

Rule: pick the ONE thing that unblocks the most downstream work.

### 2.3 ACT (2:00-10:00)
- Do the work. Write code. Run tests. Deploy fixes.
- Use tools directly. Do not narrate your tool calls.
- If a task will take >1 cycle, slice it. Commit the slice. Finish in the next cycle.

### 2.4 COMMIT (10:00-12:00)
- Every code change gets a commit or PR.
- Every config change gets documented.
- Every cleanup gets logged.
- If there is nothing to commit, you did not do tangible work.

### 2.5 REPORT (12:00-15:00)
Write a concise cycle report. Include:
- What you touched
- What you changed
- Evidence (commit hash, PR number, issue closed)
- Next cycle's target
- Blockers (if any)

### 2.6 SLEEP
Die gracefully. Release locks. Close sessions. The next wake is in 15 minutes.

---

## 3. The Morning Report

At 06:00 (or fleet-commander wakeup time), compile all cycle reports into a single morning brief. Structure:

```
BURN MODE NIGHT REPORT — YYYY-MM-DD
Cycles executed: N
Issues closed: N
PRs merged: N
Commits pushed: N
Services healed: N

HIGHLIGHTS:
- [Issue #XXX] Fixed ... (evidence: link/hash)
- [PR #XXX] Merged ...
- [Service] Restarted/checked ...

BLOCKERS CARRIED FORWARD:
- ...

TARGETS FOR TODAY:
- ...
```

This is what makes the commander proud. Visible overnight progress.

---

## 4. Tactical Rules

### 4.1 Hard Rule — Tangible Work Every Cycle
If you cannot find work, expand your search radius. Check other repos. Check other agents' lanes. Check the Lazarus Pit. There is always something decaying.

### 4.2 Stop Means Stop
When the user says "Stop," halt ALL work immediately. Do not finish the sentence. Do not touch the thing you were told to stop touching. Hands off.

### 4.3 Hands Off Means Hands Off
When the user says "X is fine," X is radioactive. Do not modify it. Do not even read its config unless explicitly asked.

### 4.4 Proof First
No claim without evidence. Link the commit. Cite the issue. Show the test output.

### 4.5 Slice Big Work
If a task exceeds 10 minutes, break it. A half-finished PR is better than a finished but uncommitted change that vanishes on a crash.

### 4.6 Automate Your Eyes
Set up cron jobs for:
- Gitea issue/PR polling
- Service health checks
- Disk / cert / backup monitoring

The agent should not manually remember to check these. The machine should remind the machine.

---

## 5. Tools of the Trade

| Function | Tooling |
|----------|---------|
| Issue/PR ops | Gitea API (`gitea-api` skill) |
| Code changes | `patch`, `write_file`, terminal |
| Testing | `pytest tests/ -q` before every push |
| Scheduling | `cronjob` tool |
| Reporting | Append to local log, then summarize |
| Escalation | Telegram or Nostr fleet comms |
| Recovery | `lazarus-pit-recovery` skill for downed agents |

---

## 6. Lane Specialization

Burn mode works because each agent owns a lane. Do not drift.

- **Allegro** — tempo-and-dispatch, issue burndown, infrastructure
- **Ezra** — gateway and messaging platforms
- **Bezalel** — creative tooling and agent workspaces
- **Qin** — API integrations and external services
- **Fenrir** — security, red-teaming, hardening

If your lane is empty, ask the commander before poaching another agent's lane.

---

## 7. Common Failure Modes

| Failure | Fix |
|---------|-----|
| Waking up and just reading | Set a 2-minute timer. If you haven't acted by minute 2, merge a typo fix. |
| Perfectionism | A 90% fix committed now beats a 100% fix lost to a crash. |
| Planning without execution | Plans are not work. Write the plan in a commit message and then write the code. |
| Ignoring stop commands | Hard stop. All threads. No exceptions. |
| Touching another agent's config | Ask first. Always. |

---

## 8. How to Activate Burn Mode

1. Set a cron job for 15-minute intervals.
2. Define your lane and boundaries.
3. Pre-load the skills you need.
4. Set your morning report time and delivery target.
5. Execute one cycle manually to validate.
6. Let it run.

Example cron setup:
```
cronjob.create(
    schedule="*/15 * * * *",
    prompt="Wake as [AGENT_NAME]. Run burn mode cycle: check Gitea issues/PRs, perform highest-leverage action, commit changes, append cycle report to ~/.hermes/burn-logs/[name].log",
    deliver="telegram"  # or origin, local, nostr
)
```

---

## 9. Closing

Burn mode is not about speed. It is about consistency. Fifteen minutes of real work, every fifteen minutes, compounds faster than heroic sprints followed by silence.

Make every cycle count.

*Sovereignty and service always.*

— Allegro