Context
History files are cold-start context, not the source of truth for live behavior. Stale or incorrect entries poison decision-making downstream. A stale-history incident proved that an old history claim can cause future spawns to repeat a reversed decision. Reconcile an operational claim with current implementation, workflows, tests, documentation, skills, and applicable decisions before acting on it.
Patterns
- Record the final outcome, not the initial request.
- Wait for confirmation before writing to history — don't log intermediate states.
- If a decision reverses, update the entry immediately — don't leave stale data.
- Link authority for operational facts. Name the current source or workflow when a lesson depends on live behavior.
- Promote reusable rules. Move procedures and incident lessons that future roles need into a focused skill; history should retain only the evidence and outcome.
Examples
✓ Correct:
- "Migration target: v0.8.17 (initial target was later corrected before execution)"
- "Node runtime: follow the current
package.jsonengines.noderequirement"
✗ Incorrect:
- "Migration target: v0.6.0" (when that request was later reversed)
- Recording what was requested instead of what actually happened
- Logging entries before outcome is confirmed
Anti-Patterns
- Writing intermediate or "for now" states to disk
- Attributing decisions without confirming final direction
- Treating history as authoritative over live source or workflow behavior
- Copying dated assignments, status reports, or retired workarounds into a reusable skill