Your Name
2dabf8ef03
- memory/: cross-session project memory with decisions, lessons, failures, architecture, and sessions categories. Each has format templates and lifecycle documentation. - skills/: 12 reusable specialized methodologies (tdd, systematic-debugging, architecture-design, code-review, security-review, repository-analysis, failure-analysis, refactoring, test-analysis, incident-investigation, browser-automation, research). Each has frontmatter and methodology sections. - improvements/: proposal-based improvement system requiring human approval. - scripts/memory-lifecycle.sh: deterministic memory operations (recall, store, list, search, sessions, cleanup). - scripts/test-memory-system.sh: 12 structural tests for all new systems. - orchestrator.md: added Memory Recall stage, Learning and Memory Storage stage, Improvement Proposals workflow, memory/skills rules, and 3 new actions (A23-A27) to the action catalog. Updated behavioral acceptance test and state separation model. - All 12 subagents: added Memory & Skills Awareness sections with recall and store instructions. - docs/AGENT_ARCHITECTURE.md: documented memory, skills, and improvements systems (sections 12-14). Updated action count (27), state model, and remaining weaknesses. - README.md: documented new systems, updated repository layout, added test-memory-system.sh documentation. All 39 tests pass (16 architecture + 12 memory + 11 bootstrap).
1.1 KiB
1.1 KiB
Session State
Cross-session continuity for long-running work.
Purpose
When OpenCode restarts, the system needs to know:
- What was being worked on
- What was completed
- What was interrupted
- What the next step should be
Format
# Session-NNNN: <task summary>
Started: YYYY-MM-DD HH:MM
Last updated: YYYY-MM-DD HH:MM
Status: active | interrupted | completed
## Task
<what was being done>
## Completed
<what was finished>
## In Progress
<what was interrupted>
## Next Steps
<what should happen next>
## Context
<relevant facts needed to resume — decisions, evidence, file paths>
Lifecycle
- Session records are created at the start of significant work
- Updated incrementally as work progresses
- Marked
completedwhen the task is done - Left as
interruptedif the session ends mid-task - Old sessions (>7 days, completed) can be archived or removed
Recovery
On session restart, the Orchestrator:
- Checks
memory/sessions/foractiveorinterruptedsessions - Reads the context from the most recent relevant session
- Decides whether to resume or start fresh
- Creates a new session record if starting fresh