Spec durable memory promotion path for Memory Gateway candidates

[marcusglee11]

Context

LifeOS issue #129 operationalized Memory Gateway v0.1 adoption for Hermes/OpenClaw through staging and retrieval boundaries, then closed as complete.

Closeout boundary retained there:

• Hermes/OpenClaw adoption proof does not grant direct durable memory/ write authority.
• Future durable memory promotion still requires normal review/governance.

Closeout evidence:

• Issue Operationalize Hermes/OpenClaw use of LifeOS Memory Gateway v0.1 #129 closeout: Operationalize Hermes/OpenClaw use of LifeOS Memory Gateway v0.1 #129 (comment)
• PR Operationalize Hermes/OpenClaw Memory Gateway adoption #130: Memory Gateway adoption/runbook/smoke evidence merged.
• PR Add OpenClaw memory gateway candidate proof #131: OpenClaw-originated staged candidate proof merged after independent review.

Problem

We now need a spec for the next governed step: how candidate packets can be promoted from knowledge-staging/ into durable memory/ without bypassing review, provenance, or authority boundaries.

This issue is intentionally a spec/planning tracker, not implementation approval.

Scope for next session

Draft the durable memory promotion spec:

• Inputs: candidate packets, receipts, review evidence, provenance metadata.
• Authority model: who/what may approve promotion, and what cannot approve itself.
• Required review gates before durable memory/ mutation.
• Audit trail: immutable links from candidate -> review -> promotion -> durable record.
• Rejection/defer path for candidates that should not be promoted.
• Hermes/OpenClaw boundary: agents may propose/stage, but must not directly write durable memory unless a later governed protocol explicitly allows it.

Acceptance criteria

• A spec is drafted as a GitHub issue comment or PR-linked artifact.
• The spec distinguishes candidate staging from durable memory promotion.
• The spec defines promotion authority, review requirements, provenance, audit receipts, and rejection/defer semantics.
• The spec preserves the Operationalize Hermes/OpenClaw use of LifeOS Memory Gateway v0.1 #129 boundary: no direct durable memory/ writes by Hermes/OpenClaw adoption tooling.
• The next implementation slice, if any, is explicitly separated from spec approval.

Next-session prompt

/new
Load relevant skills first: github-issues, next-session-issue-handoff, and any LifeOS planning/spec skills that apply.

Spec the durable Memory Gateway promotion path from staged candidate packets into durable `memory/` records.

Canonical tracker: https://github.com/marcusglee11/LifeOS/issues/132
Prior boundary/evidence: https://github.com/marcusglee11/LifeOS/issues/129#issuecomment-4458692151
Repo: /home/cabra/LifeOS

Immediate objective:
Draft the spec only. Do not implement, merge, close, or grant durable-memory write authority.

Required spec coverage:
1. Candidate inputs and metadata.
2. Promotion authority and explicit non-authorities.
3. Review/provenance/audit receipt requirements.
4. Rejection/defer path.
5. Hermes/OpenClaw boundary: staging/proposal allowed; direct durable `memory/` writes forbidden unless separately governed.
6. Clear implementation/non-goals split.

When finished:
Post the spec or spec checkpoint back to this issue with evidence and the next-session baton.