docs: pivot memory continuity to lifecycle plugin design

references/scope.md

@@ -20,7 +20,7 @@ The canonical working-state record is a Markdown checkpoint file:
 
 Longer-term direction:
 - keep the checkpoint file as source of truth
-- add a runtime-delivered continuity snapshot derived from that file
+- add runtime-assisted continuity delivery derived from that file
 - keep the file readable/editable by humans and agents
 
 ## Responsibilities
@@ -38,10 +38,11 @@ Memory continuity is **not responsible for**:
 2. Replacing `MEMORY.md` or daily notes
 3. Replacing OpenClaw compaction summaries
 4. Replacing OpenClaw `memoryFlush`
-5. Acting as a project-management database
-6. Acting as a full conversation transcript
-7. Storing every detail of recent chat history
-8. Guaranteeing perfect semantic recall of arbitrary facts from all prior turns
+5. Replacing session transcript memory search
+6. Acting as a project-management database
+7. Acting as a full conversation transcript
+8. Storing every detail of recent chat history
+9. Guaranteeing perfect semantic recall of arbitrary facts from all prior turns
 
 ## Relationship to native OpenClaw systems
 ### Native OpenClaw handles
@@ -51,6 +52,7 @@ Memory continuity is **not responsible for**:
 - transcript persistence
 - tools, sessions, and runtime orchestration
 - context engine selection and plugin lifecycle
+- session transcript recall via session-aware memory search
 
 ### Memory continuity adds
 - a **structured checkpoint** for working state
@@ -58,6 +60,18 @@ Memory continuity is **not responsible for**:
 - explicit fields for `Objective`, `Current Step`, `Next Action`, `Blockers`, and `Unsurfaced Results`
 - stronger short-term recovery for in-flight work than generic compaction summaries alone
 
+### Boundary with session memory search
+Session memory search can help answer questions like:
+- what did we discuss before?
+- what decision was mentioned in a prior session?
+
+Memory continuity is for a different question:
+- what are we doing **right now**, where did we stop, and what should happen next?
+
+In short:
+- session memory search is good at **recalling prior conversation material**
+- memory continuity is good at **recovering active working state**
+
 ## Product forms
 ### 1. Skill version (current / fallback version)
 Purpose:
@@ -76,17 +90,26 @@ What it cannot guarantee:
 - recovery without correct tool/config support
 - automatic runtime injection on every turn
 
-### 2. ContextEngine plugin version (target architecture)
+### 2. Lifecycle plugin version (target architecture)
 Purpose:
-- runtime-backed continuity guarantees
+- runtime-assisted continuity guarantees without taking the exclusive ContextEngine slot
 - reduced dependence on `read`
-- better compaction and subagent continuity
+- better startup, `/new`, and compaction continuity
+- coexistence with context engines such as `lossless-claw`
 
 What it should do:
-- inject a tiny continuity snapshot through `assemble`
-- checkpoint state before compaction
-- optionally maintain/update state after turns
-- support parent/child continuity hooks
+- use ordinary lifecycle hooks to checkpoint and recover working state
+- improve startup recovery behavior
+- checkpoint before destructive context transitions when hooks permit it
+- support minimal parent/child continuity handoff without requiring full bidirectional sync
+
+### 3. ContextEngine version (future option, not v1)
+Purpose:
+- more powerful prompt-time continuity injection when the ecosystem tradeoff is worth it
+
+Why it is not the current primary path:
+- `contextEngine` is an exclusive plugin slot
+- users should not be forced to choose between memory continuity and widely useful context engines such as `lossless-claw`
 
 ## Design principles
 1. **Files remain source of truth**
@@ -96,6 +119,7 @@ What it should do:
 5. **Continuity complements native OpenClaw memory; it does not replace it**
 6. **Working-state recovery must prefer truth over confident guessing**
 7. **User-visible recovery should prioritize current task state over generic greetings when continuity is clearly requested**
+8. **Ecosystem compatibility matters: continuity should not unnecessarily block other high-value plugins**
 
 ## Minimal recovery fields
 Any continuity implementation should preserve, at minimum:
@@ -129,10 +153,12 @@ The continuity layer is considered insufficient if, after a reset-like event, th
 - cannot identify the next action
 - hides completed but unsurfaced results
 - hallucinates prior work instead of expressing uncertainty
+- when `CURRENT_STATE.md` exists and contains active work, opens with generic greeting/chit-chat instead of first surfacing the recovered state in a recovery scenario
 
 ## Current roadmap stance
 - **Short term:** strengthen the existing skill + file discipline version
-- **Medium term:** implement a ContextEngine plugin version aligned with OpenClaw’s official extension model
-- **Long term:** keep both forms
+- **Medium term:** implement a standard lifecycle plugin version aligned with OpenClaw’s official hook model
+- **Long term:** keep multiple compatible forms
   - skill = fallback + behavior contract
-  - plugin = runtime-backed reliability layer
+  - lifecycle plugin = primary runtime-assisted reliability layer
+  - context-engine variant = optional future path when slot tradeoffs are acceptable