memorylisted

# Memory Gaia's curated memory lives in the `memory` table of the substrate DB (`~/.gaia/gaia.db`), with a parallel `memory_links` table that lets notes reference each other like a Zettelkasten. This skill covers the full flow: read what is already in your context, query when more is needed, propose a save when a discovery is closed, and curate when the set drifts. Deep mechanics — project-scoped anchoring internals, the periodic curate operations, and the knowledge-graph roadmap — live in `reference.md`, loaded on demand. Memory is mostly a **convention, not a harness** -- but WHO may write it directly is a real runtime boundary, not just an agreement. A PreToolUse guard (`hooks/modules/security/subagent_memory_write_guard.py`, wired into `bash_validator.py`) categorically rejects `gaia memory add|edit|append|reclassify|delete|link` whenever the caller is a subagent dispatch (`is_subagent` -- true whenever the harness supplies an `agent_id`) UNLESS that subagent is `gaia-operator`, the one sanctioned writer alongside the orchestrator itself (the orchestrator is never a subagent, so `is_subagent` is always false for it and it is never blocked here). This is categorical and NOT approvable -- there is no `approval_id` that lifts it, because the correct path for every other subagent is to PROPOSE via `memorialize_suggestions`, never to escalate. Everything else below -- which `class`/`status` to pick, when a fact earns a place in memory, how a body is shaped -- is *not* enforc