Implement local runtime persistence and policy gates

docs/architecture.md

@@ -146,6 +146,49 @@ The slice should emit plans first, not mutate durable memory by surprise.
 Durable writes, external adapters, live LLM extraction, vector retrieval, and
 service deployment can follow once the plan model is stable.
 
+## Local Runtime Facade
+
+The second implementation slice adds a local facade, `PhaseMemoryRuntime`, over
+the deterministic core. The facade is not a service runner. It is the small
+application surface that adjacent tools can call before a service deployment
+exists.
+
+Runtime operations currently include:
+
+- profile import
+- graph import
+- profile execution planning
+- graph lifecycle planning
+- graph activation planning
+- package compilation handoff through `ContextPackageCompiler`
+
+Each operation returns a JSON-serializable envelope with:
+
+- `schema_version`
+- `operation_id`
+- `operation`
+- `dry_run`
+- `valid`
+- `subject`
+- `source`
+- `policy_decision`
+- `audit_receipt`
+- `diagnostics`
+- `data`
+
+The local CLI exposes the same facade for fixtures and developer workflows:
+
+```bash
+phase-memory profile plan profile.json
+phase-memory graph lifecycle graph.json --stale-after-days 7 --delete-after-days 30
+phase-memory graph activate graph.json --max-items 3 --max-tokens 60
+```
+
+The default implementation uses in-memory stores, an allow-all local policy
+gateway, a recording audit sink, and a noop context-package compiler. These are
+test and integration adapters, not a claim that durable persistence, policy, or
+package internals belong in this repository.
+
 ## Open Questions
 
 - Should `phase-memory` depend directly on `markitect-tool` for validation, or