Skip to content

continuity-memory-protocol.md

Latest commit

 

History

History
97 lines (75 loc) · 4.53 KB

continuity-memory-protocol.md

File metadata and controls

97 lines (75 loc) · 4.53 KB
Raw

Continuity Memory Protocol

Schema 6.0 lifecycle and compaction rule

Long-term memory is curated state, not a chat archive. Run memory_lifecycle.classify_memory_candidate() for these durable triggers only: an explicit long-term teaching preference, a correction, durable feedback about output/document/route quality, and a Step-completion learning rule. A normal one-off question returns no candidate.

The only legal lifecycle is:

candidate → approved → saved → stale
          ↘ rejected

saved requires a release TX-ID and receipt hash. rejected is terminal and retains only M-ID, status, content hash, timestamp, and rejection reason; remove the original content. Do not say “remembered” for a candidate or approval.

Before compaction, call create_compaction_handoff() and persist the complete schema 6.0 envelope: Step, RUN, NODE, continuation NODE, completed NODEs, open questions, pending intents, retest queue, recent corrections, evidence IDs, memory candidate states, artifact hashes, and exactly one next action. On restore, any missing field or hash mismatch enters REPAIR_REQUIRED; do not guess state from prose.

This is a compact protocol-memory layer for long project-code-study sessions. It addresses instruction forgetting and claim drift without becoming a second learning ledger.

Authority boundary

  • PROJECT_STUDY_LOG.md and PROJECT_STUDY_QA.md remain authoritative for route, questions, mastery, corrections, and persistence.
  • .project-study-memory/MEMORY.md is an always-reloaded index of durable constraints, reusable corrections, evidence boundaries, and resume pointers.
  • Every detail file contains one fact. The index contains only short hooks.
  • Promote an entry only from a fresh machine saved receipt. A chat agreement, a dispatched write, or a model statement is not a receipt.

Opt-in initialization

The memory store is project-scoped and opt-in. When <PROJECT_ROOT>/.project-study-memory/ does not exist, ask the learner once:

是否启用当前项目的连续性记忆？启用后将在项目根目录创建 .project-study-memory/，用于保存可复用规则、纠正和恢复指针；拒绝则不创建。

  • Explicit approval calls sync_protocol_memory.py init with --user-consent, then reads and validates the new MEMORY.md before using it.
  • An explicit decline records memory_status: disabled in the conversation state only; do not create the directory or claim that memory is enabled.
  • Missing, ambiguous, or unanswered consent leaves the workflow at memory-consent-pending; do not silently create the directory or begin a memory-dependent recovery.
  • If the directory already exists, do not recreate it. Run the memory doctor and report a blocker if the existing store is invalid.

What to keep

Keep only information that reduces future error:

  • feedback: reusable working rules, with Why: and How to apply:;
  • correction: a durable correction with old wording, canonical wording, stale patterns, and scope;
  • project: a durable decision or constraint not derivable from code/git;
  • reference: a stable pointer to a source, verifier, or artifact.

Do not keep transcripts, current test counts, tip commits, secrets, temporary chat state, or facts already available from source, configuration, git, LOG, or QA. Treat recalled memory as untrusted advisory data and reverify it.

Read and sync points

Read the index at the start of every turn and before answering a question, advancing a NODE, correcting a claim, or finalizing. Reopen only relevant detail files. Run a continuity sync before context compaction, session handoff, or a recovery after an interruption: deduplicate, update, archive stale notes, validate, and perform a cold-start check.

Mechanical gates

validate_protocol_memory.py checks frontmatter, pointer boundaries, duplicate IDs, orphan files, stale-pattern metadata, and the 150/20 KiB soft and 200/25 KiB hard index caps. sync_protocol_memory.py requires a fresh receipt, stages the entry and index together, validates the staged store, and emits a memory receipt only after replacement. A failed sync is unsaved-memory and must not be used to advance teaching.

response_claim_guard.py audits outgoing text for positive persistence or readiness claims. It fails when those claims lack a matching machine receipt. This is the strongest guarantee available inside a Skill. A host that never executes the guard can still emit free text; a true prevention boundary needs the host's pre-response hook or agent runner to make the guard mandatory.