docs: Burn Mode Operations Manual — fleet-wide adoption (#839)

Co-authored-by: Allegro <allegro@hermes.local>
Co-committed-by: Allegro <allegro@hermes.local>

docs/burn-mode-fleet-manual.md

@@ -0,0 +1,183 @@
+# 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