Ralph Status

Ralph Status Reporting

Overview

The Ralph status block is a structured, machine-parseable progress report included at the end of every autonomous loop iteration. It enables automated monitoring, exit detection, and progress tracking. The format is rigid and must be followed exactly — machine parsing depends on consistent structure.

Announce at start: "Producing RALPH_STATUS block for this iteration."

Trigger Conditions

• End of every autonomous loop iteration (mandatory)
• After BUILD phase completes in the autonomous loop
• When monitoring systems need progress data
• When exit gate evaluation is needed
• When the autonomous-loop skill invokes this skill

---

Phase 1: Data Collection

Goal: Gather all metrics needed for the status block.

1. Count tasks completed in this iteration 2. Count files modified (created, edited, deleted) 3. Run the test suite and record result 4. Determine the primary work type 5. Check for blockers or issues

Metric Collection Table

Work Type Classification

STOP — Do NOT proceed to Phase 2 until:

• [ ] All metrics are collected
• [ ] Test suite has been run (not assumed)
• [ ] Work type is determined

---

Phase 2: STATUS Evaluation

Goal: Determine the correct STATUS value based on iteration outcome.

STATUS Decision Table

STATUS Values Defined

When BLOCKED

1. Clearly describe what is blocking progress in RECOMMENDATION 2. Set EXIT_SIGNAL: false (blocked is not complete) 3. The circuit breaker may activate if blocked state persists across iterations

STOP — Do NOT proceed to Phase 3 until:

• [ ] STATUS value is determined
• [ ] If BLOCKED, blocker is clearly described

---

Phase 3: EXIT_SIGNAL Evaluation

Goal: Determine whether EXIT_SIGNAL should be true or false.

<HARD-GATE> EXIT_SIGNAL may ONLY be true when ALL of these conditions are simultaneously met: </HARD-GATE>

EXIT_SIGNAL Decision Table

Dual-Condition Exit Gate

The loop orchestrator uses TWO independent signals to confirm exit:

1. Heuristic detection: Completion language ("all done", "everything passes", "no remaining work") appears >= 2 times in recent output 2. Explicit declaration: EXIT_SIGNAL: true in the status block

Both must be true simultaneously. This prevents:

• False positives from casual completion language
• Premature exits when Claude says "done" while still working productively

STOP — Do NOT set EXIT_SIGNAL to true unless ALL four conditions are verified.

---

Phase 4: Block Production

Goal: Write the RALPH_STATUS block in exact format.

<HARD-GATE> Every loop iteration MUST end with this exact format. No variations. No additional fields. No missing fields. </HARD-GATE>

Required Format

---RALPH_STATUS---
STATUS: [IN_PROGRESS | COMPLETE | BLOCKED]
TASKS_COMPLETED_THIS_LOOP: [number]
FILES_MODIFIED: [number]
TESTS_STATUS: [PASSING | FAILING | NOT_RUN]
WORK_TYPE: [IMPLEMENTATION | TESTING | DOCUMENTATION | REFACTORING]
EXIT_SIGNAL: [false | true]
RECOMMENDATION: [one-line summary of next action or completion state]
---END_RALPH_STATUS---

Field Specifications

RECOMMENDATION Guidelines

---

Phase 5: Validation

Goal: Verify the status block is correct before output.

Validation Checks

---

Anti-Patterns / Common Mistakes

---

Anti-Rationalization Guards

<HARD-GATE> Do NOT skip the status block. Do NOT set EXIT_SIGNAL to true unless all four conditions are verified. Do NOT modify the block format. Machine parsing depends on exact, consistent structure. </HARD-GATE>

If you catch yourself thinking:

• "The status block is just overhead..." — It is the exit gate mechanism. Never skip.
• "Everything is done, EXIT_SIGNAL: true..." — Verify ALL four conditions first.
• "I'll add an extra field for more detail..." — No. Use RECOMMENDATION for details.
• "Tests probably pass, TESTS_STATUS: PASSING..." — Run them. Verify. Then report.

---

Integration Points

---

Concrete Examples

Example: Typical IN_PROGRESS Status

---RALPH_STATUS---
STATUS: IN_PROGRESS
TASKS_COMPLETED_THIS_LOOP: 1
FILES_MODIFIED: 3
TESTS_STATUS: PASSING
WORK_TYPE: IMPLEMENTATION
EXIT_SIGNAL: false
RECOMMENDATION: Next: implement user authentication middleware
---END_RALPH_STATUS---

Example: Completion Status

---RALPH_STATUS---
STATUS: COMPLETE
TASKS_COMPLETED_THIS_LOOP: 1
FILES_MODIFIED: 2
TESTS_STATUS: PASSING
WORK_TYPE: DOCUMENTATION
EXIT_SIGNAL: true
RECOMMENDATION: All tasks complete, tests passing, documentation updated
---END_RALPH_STATUS---

Example: Blocked Status

---RALPH_STATUS---
STATUS: BLOCKED
TASKS_COMPLETED_THIS_LOOP: 0
FILES_MODIFIED: 0
TESTS_STATUS: PASSING
WORK_TYPE: IMPLEMENTATION
EXIT_SIGNAL: false
RECOMMENDATION: Blocked: need database credentials for integration test setup
---END_RALPH_STATUS---

Example: Test Failure Status

---RALPH_STATUS---
STATUS: IN_PROGRESS
TASKS_COMPLETED_THIS_LOOP: 1
FILES_MODIFIED: 4
TESTS_STATUS: FAILING
WORK_TYPE: TESTING
EXIT_SIGNAL: false
RECOMMENDATION: 3 tests failing in auth module — investigating root cause next iteration
---END_RALPH_STATUS---

---

Process Summary

1. Complete the iteration's work (implementation, testing, docs, or refactoring) 2. Count tasks completed and files modified 3. Run the test suite and record result 4. Evaluate STATUS value 5. Evaluate EXIT_SIGNAL conditions (all 4 must be true for true) 6. Write the RALPH_STATUS block in exact format 7. Include a clear, actionable RECOMMENDATION

---

Skill Type

RIGID — The status block format must be followed exactly. Machine parsing depends on consistent structure. No field additions, no format changes, no skipped blocks.