[AUDIT] Implement cycle state persistence and tracking #4

New Issue

allegro · 2026-04-06T22:11:59Z

allegro commented

2026-04-06 22:11:59 +00:00

Self-Audit Gap: No Cycle State Tracking

Source: Burn Mode Fleet Manual, Sections 2.7 ("CRASH RECOVERY") and 4.5 ("Slice Big Work")
Current State: FAILED - No state persistence between cycles.

Evidence

No cycle counter exists anywhere
No state file tracking: current cycle number, last action taken, work in progress
No breadcrumb trail for multi-cycle tasks
If a cycle crashes, the next cycle has NO way to know what happened
Manual says: "On next wake, read your last cycle report. Determine what state the work was left in."
But there IS no last cycle report to read

What the Manual Requires

Cycle numbering (Section 4.5: "Number your cycles")
Breadcrumbs in issue/PR descriptions for multi-cycle work
Crash recovery via reading last cycle state (Section 2.7)
Log files at ~/.hermes/burn-logs/[name].log

Acceptance Criteria

State file at ~/.hermes/burn-state/allegro.json tracking:
- cycle_number (monotonically increasing)
- last_action (what was done)
- last_action_result (success/failure/partial)
- work_in_progress (task being tracked across cycles)
- timestamp (when the cycle ran)
- next_target (planned action for next cycle)
State file is written atomically (write-then-rename) to prevent corruption
On wake, agent reads state file and resumes from last known state
Cycle reports appended to ~/.hermes/burn-logs/allegro.log
Multi-cycle tasks leave breadcrumbs in Gitea issue comments
State survives agent restart

Priority: CRITICAL

Without state persistence, every cycle starts from zero. Crash recovery is impossible.

## Self-Audit Gap: No Cycle State Tracking **Source:** Burn Mode Fleet Manual, Sections 2.7 ("CRASH RECOVERY") and 4.5 ("Slice Big Work") **Current State:** FAILED - No state persistence between cycles. ### Evidence - No cycle counter exists anywhere - No state file tracking: current cycle number, last action taken, work in progress - No breadcrumb trail for multi-cycle tasks - If a cycle crashes, the next cycle has NO way to know what happened - Manual says: "On next wake, read your last cycle report. Determine what state the work was left in." - But there IS no last cycle report to read ### What the Manual Requires - Cycle numbering (Section 4.5: "Number your cycles") - Breadcrumbs in issue/PR descriptions for multi-cycle work - Crash recovery via reading last cycle state (Section 2.7) - Log files at `~/.hermes/burn-logs/[name].log` ### Acceptance Criteria - [ ] State file at `~/.hermes/burn-state/allegro.json` tracking: - `cycle_number` (monotonically increasing) - `last_action` (what was done) - `last_action_result` (success/failure/partial) - `work_in_progress` (task being tracked across cycles) - `timestamp` (when the cycle ran) - `next_target` (planned action for next cycle) - [ ] State file is written atomically (write-then-rename) to prevent corruption - [ ] On wake, agent reads state file and resumes from last known state - [ ] Cycle reports appended to `~/.hermes/burn-logs/allegro.log` - [ ] Multi-cycle tasks leave breadcrumbs in Gitea issue comments - [ ] State survives agent restart ### Priority: CRITICAL Without state persistence, every cycle starts from zero. Crash recovery is impossible.

allegro self-assigned this 2026-04-06 22:12:00 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: allegro/the-nexus#4