Compaction Survival System

Prevent context loss during LLM compaction via Write-Ahead Logging (WAL), Working Buffer, and automatic recovery. Three mechanisms that ensure critical state...

Security Scan

The skill's required actions (writing/reading session files, using a WAL and buffer, and recovering from them) are consistent with its stated purpose of preserving exact context across compaction, but it persists potentially sensitive specifics to disk and relies on runtime utilities that are not defined in the SKILL.md.

Purpose & Capability

The name/description (prevent context loss via WAL, working buffer, recovery) maps directly to the runtime instructions (scan incoming messages, write SESSION-STATE.md, maintain memory/working-buffer.md, recover from those files). There are no unrelated environment variables, binaries, or install steps requested; everything requested is proportional to the stated goal.

Instruction Scope

The SKILL.md explicitly instructs the agent to write and read files (SESSION-STATE.md, memory/working-buffer.md, memory/YYYY-MM-DD.md) and to stop responding until WAL updates are written. This is within scope for preserving context, but it also directs the agent to persist exact values, paths, IDs, URLs and other specifics to disk — which can include sensitive data. The instructions reference runtime utilities/values that are not defined in the document (e.g., session_status for context utilization and memory_search), creating implementation ambiguity. The skill also instructs the agent to 'NEVER ask' the user and to recover silently, which could cause the agent to assert recovered context confidently even if recovery is incomplete.

Install Mechanism

There is no install spec and no code files; this is instruction-only. That minimizes supply-chain risk (no downloads, no package installs).

Credentials

The skill requests no environment variables, credentials, or external APIs. That aligns with the described purely behavioral/local approach. Note that absence of credentials does not eliminate privacy risk because the skill persists user-provided specifics to disk.

Persistence & Privilege

The skill instructs persistent file writes into a memory/ directory and SESSION-STATE.md that survive compaction and across sessions. always:false (not always-included) and no system-wide config changes are requested, which is appropriate, but persistence of raw specifics (numbers, paths, IDs, URLs, etc.) is a material privacy/security consideration: files may be readable by other processes, survive backups, or be exfiltrated if the runtime is compromised. The SKILL.md does not specify storage location, access controls, encryption, or retention policies.

Assessment

This skill appears coherent for preventing context loss, but it writes exact details (numbers, paths, IDs, URLs, decisions) to local files which may contain sensitive information. Before installing or enabling it, confirm the following: - Where will SESSION-STATE.md and memory/ be stored? Ensure the directory is in a controlled, access-restricted location (not world-readable). - Are these files encrypted at rest or covered by your retention/backup policies? If not, consider adding redaction or encryption. - Who/what processes can read these files? Make sure other services or users cannot access them. - Does your OpenClaw runtime provide the referenced utilities (session_status, memory_search)? Define these APIs and their permissions so behavior is deterministic. - Consider redacting secrets (passwords, API keys) before WAL writes, or add explicit rules to avoid logging credentials. - Test the behavior in an isolated environment to confirm it recovers as expected and doesn't expose sensitive data or make incorrect assertions. If you cannot control storage location, access rules, or confirm the runtime utilities, treat this skill cautiously despite its coherence.

Compaction destroys specifics: file paths, exact values, config details, reasoning chains. This skill ensures critical state survives.

The problem: When your context window fills up, OpenClaw compacts older messages into a summary. Summaries lose precision — exact numbers become "approximately," file paths vanish, decisions lose their rationale. Your agent wakes up dumber after every compaction.

The fix: Three mechanisms that capture critical state before compaction hits, and recover it after.

Three Mechanisms

1. WAL Protocol (Write-Ahead Logging)

On EVERY incoming message, scan for:

• ✏️ Corrections — "It's X, not Y" / "Actually..."
• 📍 Proper nouns — names, places, companies, products
• 🎨 Preferences — styles, approaches, "I like/don't like"
• 📋 Decisions — "Let's do X" / "Go with Y"
• 📝 Draft changes — edits to active work
• 🔢 Specific values — numbers, dates, IDs, URLs, paths

If ANY appear:

1. STOP — do not compose response yet
2. WRITE — update SESSION-STATE.md with the detail
3. THEN — respond to the human

The trigger fires on the human's INPUT, not your memory. Write what they said, not what you think.

2. Working Buffer (Danger Zone)

At 60% context utilization (check via session_status):

1. Create/clear memory/working-buffer.md, write header:

   # Working Buffer (Danger Zone)
   **Status:** ACTIVE
   **Started:** [timestamp]
   

2. Every exchange after 60%: append human's message + your response summary
3. Buffer is a file — it survives compaction
4. Leave buffer as-is until next 60% threshold in a new session

Location: memory/working-buffer.md

3. Compaction Recovery

Auto-trigger when:

• Session starts with <summary> tag in context
• You should know something but don't
• Human says "where were we?" / "continue" / "what were we doing?"

Recovery steps (in order):

1. Read memory/working-buffer.md — raw danger-zone exchanges
2. Read SESSION-STATE.md — active task state
3. Read today's + yesterday's memory/YYYY-MM-DD.md
4. Run memory_search if still missing context
5. Extract important context from buffer → update SESSION-STATE.md
6. Report: "Recovered context. Last task was X. Continuing."

NEVER ask "what were we discussing?" — the buffer has the answer.

SESSION-STATE.md Format

# Session State — Active Working Memory

## Current Task
[What we're actively working on]

## Key Details
- [Specific values, paths, configs captured via WAL]

## Decisions Made
- [Decisions with rationale]

## Pending
- [What's waiting/blocked]

## Last Updated
[timestamp]

Update this file frequently. It's your RAM — the only place specifics survive between compaction events.

How It Works Together

                    ┌──────────────────────────┐
                    │    Human sends message    │
                    └────────────┬─────────────┘
                                 │
                    ┌────────────▼─────────────┐
                    │  WAL: Scan for specifics  │
                    │  Found? Write first.      │
                    └────────────┬─────────────┘
                                 │
               ┌─────────────────▼─────────────────┐
               │  Context > 60%? Buffer everything  │
               └─────────────────┬─────────────────┘
                                 │
                    ┌────────────▼─────────────┐
                    │    Respond to human       │
                    └────────────┬─────────────┘
                                 │
                        ┌────────▼────────┐
                        │  COMPACTION HIT  │
                        └────────┬────────┘
                                 │
                    ┌────────────▼─────────────┐
                    │  Recovery: Read buffer,   │
                    │  SESSION-STATE, daily log  │
                    │  → Full context restored   │
                    └──────────────────────────┘

Integration

• Works alongside MEMORY.md (long-term) and memory/YYYY-MM-DD.md (daily logs)
• SESSION-STATE.md = working memory for current task
• Working buffer = emergency capture for the danger zone
• All three layers stack: WAL → Buffer → Recovery
• No dependencies. No API keys. Pure behavioral patterns.

Why This Works

Most "memory" solutions try to store everything forever. That's the wrong problem. The real problem is precision loss during compaction. You don't need to remember everything — you need to remember the RIGHT things at the RIGHT time.

WAL catches specifics the moment they appear. The buffer captures the danger zone. Recovery restores context after the reset. Three layers, zero dependencies, zero data leakage.

---

Built by @rustyorb + S1nthetta ⚡ — Battle-tested across 30+ compaction events.