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).
58 lines
1.1 KiB
Markdown
58 lines
1.1 KiB
Markdown
# 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
|
|
|
|
```markdown
|
|
# 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 `completed` when the task is done
|
|
- Left as `interrupted` if the session ends mid-task
|
|
- Old sessions (>7 days, completed) can be archived or removed
|
|
|
|
## Recovery
|
|
|
|
On session restart, the Orchestrator:
|
|
1. Checks `memory/sessions/` for `active` or `interrupted` sessions
|
|
2. Reads the context from the most recent relevant session
|
|
3. Decides whether to resume or start fresh
|
|
4. Creates a new session record if starting fresh
|