Shared binary
Two profiles, one installation
Personal Hermes and the game-assist gateway have isolated profile homes, but they still share one patched executable, Python environment, dependency graph, desktop build, and updater.
Separate the executable runtimes, connect them through supported contracts, and make memory prove that it is captured, retrieved, injected, and used—not merely stored.
These facts were checked live before proposing any installation or service changes.
Personal Hermes and the game-assist gateway have isolated profile homes, but they still share one patched executable, Python environment, dependency graph, desktop build, and updater.
Both profiles name Mnemosyne as their provider, but Hermes reports the plugin as not installed. Structured external capture, recall, and consolidation are therefore not running.
Hermes injects each profile’s built-in memory files. Nagato separately injects bounded campaign memory, Codex records, retrieval evidence, and Recall-derived state into game conversations.
The installed source is a pinned Nagato patch branch rather than upstream’s normal update branch. A routine update check currently fails before it can report a clean upgrade path.
Gameplay evidence is game-scoped and provenance-bearing. Raw screenshots, private paths, and unvalidated extraction output must not leak into a shared personal memory store.
Nagato’s bridge validates scope, redaction, evidence, artifacts, and agent mutations. A memory integration should extend that boundary rather than bypass it with a second source of truth.
A profile isolates state. It does not isolate upgrades, dependencies, regressions, or patched core behavior. Those are the reasons to split the runtime itself.
Your personal Hermes remains free to work inside the Nagato repository and carries only the temporarily shared capabilities it genuinely needs—most importantly Featherless compatibility. Nagato’s service runtime stays pinned and can be trimmed to the product essentials. Candidate gateways and risky memory experiments run in throwaway worktrees/environments until they pass the shared contracts.
Your desktop and CLI agent for ordinary work, including working on Nagato’s codebase.
A service backend owned by the Game Assist compatibility and privacy contracts.
Candidate adapters and memory experiments that must not disturb either daily runtime.
Featherless coordination is useful beyond Nagato. Keeping it as repeated client patches makes every runtime carry the same provider policy and concurrency bugs.
Both durable Hermes installations may carry the current Featherless compatibility and safety patches during separation. Treat that as migration debt with an explicit exit: a standalone loopback scheduler becomes the single owner of capacity, reservations, model routing metadata, retry/backoff, and observability.
Personal Hermes, Nagato Hermes, and future candidate harnesses call one local service instead of implementing provider concurrency independently.
Clients submit bounded model requests and priorities; the scheduler owns Featherless credentials, reservations, rate state, and fairness.
A scheduler outage fails explicitly and cannot corrupt sessions, memory, or Nagato’s persisted traces. Direct-provider fallback is a deliberate policy, never an accidental bypass.
Shared client patches are removed only after parity tests prove streaming, auxiliary calls, deadlines, accounting, and recovery through the scheduler.
“The database contains memories” is not an acceptance test. The model must receive relevant memory, use it correctly, and leave evidence that the loop worked.
A planted prior decision is found in a new session and changes the answer or tool plan in the expected way.
Irrelevant memories are withheld; the prompt records memory candidates and actual injected bytes without private content in diagnostics.
A newer explicit correction supersedes an older fact, while provenance and history remain auditable.
Personal, project, profile, game, and Recall namespaces cannot read one another without an explicit sharing rule.
Nagato may promote only validated derived facts tied to exact Recall evidence; raw screenshots never become generic memory.
Restarting the gateway preserves the same authoritative memory outcome and does not duplicate capture or actions.
Every phase has an exit condition and a rollback. The live bridge keeps using its current runtime until the replacement passes the same requests side by side.
Back up profile state, record ports/services/source heads, and define health probes. No mutation to the live gateways.
Install an upstream-oriented build separately, carrying only the reviewed shared foundation patches needed now. Point desktop/CLI aliases to it and prove repository work, sessions, tools, Featherless behavior, and rollback.
Reproduce the reviewed patch stack in its own installation and service identity, preserving the existing game-assist home without copying secrets into plans or logs.
Install the supported provider package per runtime. Personal, Nagato, and every candidate use separate stores. Personal Hermes may reach Nagato through authenticated development contracts, never by mounting Nagato’s memory database.
Keep campaign/Codex/Recall authority in the bridge. Permit only bounded, provenance-linked derived facts into the product runtime’s provider namespace.
Switch the bridge endpoint, retain the old service stopped but recoverable, run live gaming-machine acceptance, then begin the update cadence.
Only after the two stable lanes and active-memory contract exist should a candidate runtime compete to replace Nagato’s backend.
“Stay current” and “stay compatible” are different jobs, so they get different release channels.
The main plan remains the stable decision record. Checkpoints are append-only snapshots linked from here and published after evidence-bearing events.
These decisions now constrain Checkpoint 003 and the first separation spike.
/plans should evolve into an ephemeral plan service.