Magnemo 0.6.8 — the yes, asked in the chat

• The yes is one click where you already are. When an agent stages a clean note through the MCP server and the
  client can put a form to its user (MCP elicitation), Magnemo asks the client to ask you: the note's first line, who
  wrote it, "Approve it as memory?" Yes promotes it, No rejects it, anything else leaves it staged. The agent is not
  on that path: it does not see the question and has no tool that answers it. Promotion is still not an MCP tool.
• Where the answer came from is on the record. Every promotion and rejection carries answered_by:
  elicitation:<client and version> or terminal.
• An accepted answer in under 300 ms is refused and logged (answered_by: refused:too-fast). A client with
  nobody at it, which lets go of the question at once, is not an attempt: the note waits, and the tool's answer says
  where the yes is. MAGNEMO_ASK=off stops the asking altogether.
• A client that cannot ask is told once that the note waits for the person's own magnemo yes.
• The first-run paste ends at a restart: the tools load when the client starts, and the first memory is approved
  in the chat. docs/MCP.md has the table of clients, with what was seen.
• The server now answers a protocol revision it does not speak with the newest it does (2025-11-25), not an echo.
• Breaking, and on purpose: a magnemo yes that an agent or a script ran in 0.6.7 is refused in 0.6.8 (exit 3).
  If a pipeline, a hook or an agent's shell runs magnemo yes, no, clear or promote for you, it now stops with
  one line and writes nothing to memory. The yes is yours: type it in a terminal.
• What the engine checks. magnemo yes (and no, clear, promote, their long forms reject and cleartaint,
  and the answers inside review) requires an interactive terminal (a TTY on stdin) and a name in the vault's
  trust.humans. It refuses with no TTY (an agent's tool call, a script, a pipe), with MAGNEMO_AGENT set, from inside
  an MCP server session, or for a --by that is not on the list (never defaulted). With no --by, the first listed
  name is used.
• A refusal names its gate and the route. With no terminal: This yes is yours. Type it yourself in a terminal: magnemo yes <id>. The other refusals say which gate (a seat named, an unlisted name, an MCP session) and end with
  the same route. Each refusal is one line in the trust ledger (judgment.refused, catch: yes-check,
  ran_by: refused:<reason>). Every yes, no and clear that goes through carries ran_by: terminal.
• One override, for a relayed word: MAGNEMO_YES_RELAY=<listed name>, on a terminal only and for that name only;
  the ledger says ran_by: relay:<who ran it>, so a relay is never read as the person's own hand.
• What it is not. A check on the hand, not a credential: a process that allocates its own TTY, clears
  MAGNEMO_AGENT and names a listed person passes. KNOWN_LIMITS.md says so first. Promotion is still not an MCP tool.
• The registry description no longer says "zero network calls": "Governed memory for AI agents, in plain local files.
  No network calls of its own."

Magnemo 0.6.7 — the polish

• magnemo review says HELD and TAINTED. A note Sentinel is holding is labelled before its text, the text of a
  flagged note is shown quoted, and there is no [p] for it: "held by Sentinel — magnemo clear <id> first". The
  terminal now matches what magnemo yes already did in 0.6.6.
• A yes or a no from review is on the record like every other: the ledger line carries ran_by and a reason.
• A note Sentinel caught earns its author no trust. A secret or an instruction-shaped line that you read, cleared
  and kept becomes canon; the trust.event success a promotion gives its author is not written for it.
• The ALERT is scored when it is staged and is read first. No more "unscored — run: cli rescore"; Sentinel's
  notices lead the review queue. The inbox door's and the chest's notices are scored too. It says "an MCP stage".
• README: for a desktop-only Mac, where the app keeps its own claude.

Also in this release: 0.6.6 — the polish

• No traceback reaches a person. magnemo stage with a store the partition does not have answers in one line naming
  the partition's stores (and checks before anything is written, Sentinel's notice included); an unknown partition names
  the vault's partitions; a missing --file says so. An id no note matches is one line on show, yes, no, clear,
  promote, reject and flag. magnemo review without a terminal says "review needs a terminal; use magnemo yes <id> / magnemo no <id>" and lists what waits by short id. Anything else that fails prints magnemo: <one line>;
  MAGNEMO_DEBUG=1 shows the trace.
• The short id works everywhere. The eight characters stage prints (magnemo yes 17f26148) are now taken by
  show, clear and cleartaint as well as yes and no, for staged and canonical notes; two matches are listed.
• yes waits for clear. magnemo yes <id>, magnemo promote and review's [p] refuse a tainted or held note in
  a sentence — "TAINTED — read it, then clear it: magnemo clear --reason …" — until a keyholder has cleared it.
  yes --all skips them and counts them. A Sentinel ALERT is a notice, not a memory, and carries no taint of its own:
  yes --all and a bare yes skip it and count it; you keep one by naming it (magnemo yes <id>) or drop it
  (magnemo no <id> --reason …). A kept alert is served and wakes in the boot pack; the pack says how many notes
  Sentinel is holding.
• magnemo stage --help shows one real example, with a partition, a store and a source, and says what a new vault's
  stores are.

Magnemo 0.6.5 — Sentinel at the gate

• The stage door is swept. Every note staged through the MCP stage tool or the CLI's magnemo stage passes Sentinel,
  the same sweep the inbox, the Room and the chest already ran: a secret-shaped value never lands (the note carries the
  redaction line and a sentinel:secret:<pattern> taint; the reply says HELD and names the pattern, never the value); an
  instruction-shaped line stages TAINTED beside a Sentinel ALERT note. Four doors, one sweep.
• A tainted note is never served to an agent — not by retrieve, not in the boot pack's digest — until a keyholder
  reads it and clears it: magnemo clear <id> --reason … (the short name for cleartaint; ledgered).
• magnemo doctor checks the network sentence instead of the README asserting it: network: transport stdio · listener none · outbound modules none from a static scan of the installed package, FAIL if a network module appears; and
  server: never connected until an MCP client has actually started this vault's server (the server now logs each session
  start to _ledger/connections.jsonl) — the CLI answering is not the server connecting.
• The one paste's step 6 keeps the same-session read and gets the restart back: approve, magnemo bootpack, then restart
  so the memory mounts for every later session. The CLI's stage reply names the word (magnemo yes <id>).
• The companion magnemo-mcp says requires-python >=3.11, the same as the engine it pins; docs/MCP.md says 3.11 too.

Magnemo 0.6.4.post1 — the directory release

• Registry name + privacy section + SECURITY.md. No engine change: the MCP registry name moves to our own domain
  (mcp-name: ai.magnemo/magnemo), the README gains a Privacy section, SECURITY.md says how to report, and the
  Claude Desktop bundle names its privacy page. A post-release in PyPI's own sense: metadata only.

Magnemo 0.6.4 — the words

• The engine tells the truth about Python: requires-python is >=3.11, as the README, the site and the paste
  already say. pip install on 3.10 now refuses with the standard message.
• Found by running the suite on 3.11: a vault path given AFTER flags (magnemo promote <id> --by NAME <vault>,
  magnemo stage … <vault>) was rejected as an unrecognized argument on Python 3.11 (3.12+ parsed it). The CLI now
  reads one leftover word as the vault on every supported Python.
• The words: every sentence a reader meets — the README, the docs, this file, the CLI's help and messages, the MCP
  door's replies, the boot pack, the vault's own README — now says "you", "a person" or "the keyholder". The door's
  refusal reads "an agent seat cannot sign as a keyholder"; the stage reply reads "Awaits KEYHOLDER review"; the caps
  read "keyholder-only". Words only: the config key trust.humans, every identifier, ledger field, file format, tool
  name and the rule itself (promotion and publish are never an agent's) are unchanged.
• magnemo --version prints the version (it was missing; the release drill asked for it).

Magnemo 0.6.3 — the Memory MCP

0.6.3 — THE BLOCK, TRUE TO ITS OWN LAW

The block does what the record says it does. Found by a second agent on a second
machine, told only "you are the first user, run the protocol" (credit: cc-2, whose
patch against the 0.6.1 sdist was the design; re-implemented on main).

• PROVENANCE ENFORCED AT THE DOOR: the stage tool's author is the server's seat
  (MAGNEMO_AGENT), always. A seat that tries to sign as a human (a keyholder in
  trust.humans) is refused with a plain reply and the refusal is ledgered as a
  stage denial; a different non-human name is kept in the new provenance field
  claimed_author (appended; nothing renamed).
• THE GATE LIFT IS A WORD: magnemo yes promotes the top of the queue (the order
  review shows), yes <id-fragment> one note (two matches = refuse and list),
  yes --all the whole queue with one ledger entry per note; magnemo no <fragment> --reason TXT rejects one (the reason stays required). --by defaults to the first
  keyholder; --reason to "approved in chat". Every entry these verbs write carries
  ran_by — the agent seat if MAGNEMO_AGENT is set, else terminal: the yes is the
  human's, the hand that ran it is on the record. promote/reject are unchanged
  (the long form). Promotion is still never an MCP tool: the four tools stay four.
• THE RECORD TELLS THE TRUTH ABOUT ITSELF: the MCP boot line reports queue=<n> (and
  held=<n>), as the docs always said; the stage reply and the review footer name
  the word (magnemo yes); the README's install line carries the uv fallback the site
  paste has (Python 3.11+; uv tool install magnemo if pip can't).
• THE OPERATOR FLAG, deterministic: a note staged by a human hand (the author is a
  keyholder) carries the operator tag automatically; no text sniffing.
  No change to gates, action classes, the L1 cap, trust weights, half-life, the ledger's
  fields (one appended), the vault layout, config keys, the four tool names, or the boot
  pack of an unchanged vault.