Hermes separation / checkpoint 002
Approved planning checkpoint · 24 July 2026

Hermes separation implementation blueprint

A reversible first separation spike that preserves the useful shared foundation, isolates product behavior and memory, and establishes the contracts that future gateway candidates must meet.

Status: blueprint ready Live mutations: none Next authorization: begin R1 preflight Human needed: maintenance window only at R6
Baseline warning: both Hermes gateways are currently listening, but the Nagato bridge health endpoint is not reachable and its scheduled task last returned failure. R1 begins by diagnosing and restoring that baseline; the separation spike will not conceal an existing outage.
Live topology

Pin what exists before splitting it

The target retains existing public contracts and ports. Shadow processes use unused ports and temporary state, so nothing competes with the live profiles.

Personal gateway

Loopback :8642

Running from the shared patched installation with the default profile.

Nagato gateway

Loopback :8643

Running from the same installation with isolated game-assist state.

Bridge · attention

Loopback :8765

Not listening at discovery time. Scheduled task exists; last result indicates failure.

Shared services

GTC + Valkey

Tool service, portal, search, and capacity coordination are listening on their established local ports.

Scheduler reservation

Loopback :8650

Free and reserved by this blueprint for the provider-neutral Featherless proxy.

Shadow gateways

Loopback :8742 / :8743

Free and reserved for personal and Nagato separation tests using disposable homes.

Installation layout

Separate code from state

Runtime releases are immutable directories selected by a small current pointer. Existing profile state stays in place for the first spike; state migration is a later, separately reversible concern.

RoleRuntime locationState authorityCommand/service identity
Personal%LOCALAPPDATA%\HermesRuntimes\personal\releases\<build>Existing default Hermes homehermes + Hermes_Personal_Gateway
Nagato%LOCALAPPDATA%\HermesRuntimes\nagato\releases\<build>Existing game-assist profile homenagato-hermes + Nagato_Hermes_Gateway
CandidateWorktree-owned build or package cacheTest-owned temporary directory onlyHarness controller; no login autostart
PlansVersioned gaem-proxy application%LOCALAPPDATA%\gaem-plans, outside the static webrootGaem_Plans_Service behind HTTPS proxy
17-patch ledger

Do not duplicate the whole fork

Patch ownership is classified by behavior, not history. Mixed commits must be re-authored into coherent slices before either runtime is built.

ClassCurrent patchesDestinationExit condition
Shared Featherless0001, 0006, 0008, 0010, 0012, 0017Temporary shared-foundation branch for both durable runtimesScheduler parity allows client-side reservation logic to be removed
Nagato product0002, 0003, 0004, 0011, 0014, 0015Nagato runtime onlyRetained while Hermes is the selected product gateway
Must split0005, 0007, 0013Featherless/tool-wire pieces shared; Runs/trace/GTC pieces product-onlyNo mixed patch remains in either manifest
General Windows test infrastructure0009, 0016Build/test overlay; propose upstream separatelyDrop locally when upstream contains equivalent coverage

Build outputs

Personal manifest: exact upstream release + shared Featherless slices + justified general tool-wire/Windows fixes. Nagato manifest: the same shared base + Runs/trace/artifact/privacy/GTC product slices. Both manifests pin source, tree, dependencies, tests, and rollback build.

Featherless service

One queue, many clients

The scheduler is an OpenAI-compatible loopback proxy. It owns the provider credential and actual request queue; clients stop reserving capacity independently.

Personal Hermes

Interactive project work. Uses scheduler base URL and a personal workload identity.

Scheduler · :8650

Weighted fairness, concurrency, deadlines, safe retry boundaries, model metadata, capacity state, and body-free observability.

Nagato + candidates

Foreground game turns, background Recall review, tests, and future gateway implementations.

1
Compatibility surface

POST /v1/chat/completions, streaming SSE, and GET /v1/models. Existing clients switch by base URL, not core patches.

2
Control surface

/healthz and authenticated /v1/scheduler/status; never prompts, responses, credentials, or memory content.

3
Request envelope

Bounded workload class, profile ID, request ID, and absolute deadline headers. Unknown values use safe defaults.

4
Fairness

Weighted queues for interactive, Nagato foreground, background, and maintenance; per-client caps prevent starvation or monopolization.

5
Retry rule

Retry only before provider acceptance/stream output. Once bytes stream, failure is explicit—never silently replay a billable generation.

6
Patch retirement

Streaming, auxiliary calls, context metadata, capacity refresh, deadlines, and recovery must match before old reservation code is removed from both Hermes runtimes and GTC.

Product distribution

Bake in contracts, not copied source

Nagato should install with research and active memory ready to use. “Baked in” means pinned, configured, health-checked, and covered by compatibility tests while each dependency retains its own downstream update channel.

GrokToCrawl · required product service

  • Keep GTC as an independent loopback/Docker service; do not vendor it into the Hermes environment
  • Pin release, source commit, image/dependency digests, API generation, and tool-schema hash in the Nagato distribution manifest
  • Startup readiness checks health, tool catalog, required gtc_* functions, Valkey coordination, and safe result shapes
  • A downstream-update job watches upstream, builds an isolated candidate, and runs the GTC adapter contract before proposing promotion
  • Current local baseline is GTC 0.12.1 on a Featherless integration branch; its existing working-tree change must be inventoried before any refresh

Memory provider · required replaceable slot

  • Ship one selected provider enabled and verified, but keep Hermes’ provider interface as the product boundary
  • Do not lock the architecture to Mnemosyne before the collected 25+ options are screened
  • Evaluate broad candidates cheaply, then run full active-use tests on a short list
  • Pin the winning plugin/package and schema in the Nagato distribution manifest with export/backup/rollback instructions
  • Provider upgrades run the same conformance suite before downstream promotion
G
GTC compatibility gate

Health, capability/version handshake, tool schemas, malformed-call refusal, bounded results, research citations, image handling, timeout/retry behavior, and scheduler integration.

M
Memory-provider gate

Availability, initialize, prefetch, completed-turn sync, session switch, pre-compression, tools, shutdown, backup/export/delete, profile isolation, and failure-soft behavior.

Update principle

GTC and the selected memory provider may move faster than the trimmed Nagato Hermes runtime. Their update pipelines therefore produce independently testable artifacts and compatibility evidence; Nagato consumes an approved version range or exact pin instead of absorbing their source histories.

Memory and development access

Reach the service, not its database

Personal Hermes can be an excellent Nagato developer and operator while its memory remains distinct from the product’s player/game knowledge.

Personal namespace

  • Personal preferences and work history
  • Project-development facts learned by personal Hermes
  • Its own Mnemosyne database and consolidation
  • No automatic game or Recall import

Nagato namespace

  • Runtime execution lessons only
  • Game identity nested beneath authoritative game_id
  • Campaign/Codex/Recall remain bridge authorities
  • No direct personal-memory reads

Candidate namespaces

  • Fresh temporary store per candidate/run
  • Seeded conformance facts only
  • No live profile credentials or player data
  • Deleted with the test data root

Personal-to-Nagato development contract

Repository and Forgejo access stay normal. Runtime inspection goes through authenticated loopback bridge/gateway APIs and explicit development tools: health, bounded configuration metadata, run/trace inspection, test commands, and validated mutations. Direct SQLite/JSON writes remain outside the agent contract.

1
Screen the 25+ list

License, Windows support, local/cloud posture, Hermes integration cost, maintenance activity, data portability, isolation model, and dependency weight.

2
Short-list by executable behavior

Run the same capture/recall/correction/negative-relevance/restart corpus; do not accept project benchmarks or README claims as product evidence.

3
Prove active use

Trace the selected memory IDs and injected byte budget, then verify that recalled context materially changes the agent’s correct plan without leaking irrelevant memory.

4
Keep replacement cheap

Provider-specific tools stay behind an allowlist and canonical adapter vocabulary where needed; export and migration are tested before production adoption.

gaem.moe plan service

Ephemeral first, durable by choice

The current public static directory remains legacy/sanitized during migration. The new surface uses capability links and has no public index.

P1 · Publish and expire

  • POST /api/v1/plans with local publisher authentication, bounded files, title, and TTL
  • Return a 128-bit-or-greater view capability plus a separate management secret
  • GET /p/<capability>/… with noindex, CSP, MIME allowlist, and no directory listing
  • DELETE /api/v1/plans/<id> requires the management secret and immediately revokes the view
  • Default TTL seven days; explicit shorter duration allowed; bounded maximum thirty days

P2 · Save, reply, and own

  • Promote an ephemeral plan into an explicit durable collection without changing its content hash
  • Authenticated ownership and invite-scoped reply capability
  • Replies stored as sanitized text/Markdown, not arbitrary executable HTML
  • Append-only revision/reply audit with deletion and retention controls
  • Trusted interactive plans run only in a separately sandboxed mode

Repository rule

Before proxy behavior changes, move gaem-proxy into a private Forgejo repository with tests, a locked dependency graph, configuration documentation, and a rollbackable service definition. The live folder is currently not version-controlled.

Execution order

Runtime Separation subwaves

R1–R5 are recovery, build, integration, shadow, and memory-proof work. R6 is the only live cutover and requires a short agreed maintenance window. Scheduler extraction follows the first proven separation, as requested.

Baseline health and recoverability

Diagnose the currently failed bridge task, restore health, inventory safe state, create checksummed backups, and prove the current rollback commands.

All current health green

Patch split and dual manifests

Re-author mixed patches, produce personal and Nagato manifests, build immutable release directories, and independently review exact outputs.

Two reproducible builds

Product integration manifests

Pin GTC’s current verified service contract, build its downstream-update test lane, inventory the memory-provider list, and turn Hermes’ provider lifecycle into a reusable conformance suite.

GTC + memory gates executable

Shadow runtime separation

Run personal and Nagato builds on :8742/:8743 with disposable homes, fake providers by default, required GTC adapter checks, then bounded live Featherless smoke.

Contract parity green

Memory provider selection and active proof

Screen the 25+ options, fully test a short list, install the selected provider per durable runtime, run canary/negative/correction/isolation/restart tests, and prove candidates receive temporary stores.

Provider selected; loop evidenced

Live runtime cutover

Stop old gateways, switch task/alias pointers, reuse existing state homes, start new binaries on :8642/:8643, restore bridge :8765, and run human acceptance.

Human acceptance

Featherless scheduler extraction

Build :8650 proxy, migrate one client at a time, compare billing/stream/deadline/capacity behavior, then retire duplicated patches.

One scheduling authority

Gateway candidates resume

Evaluate pi, OAL, Turnstone, stripped Hermes, and ground-up against the now-real runtime, memory, scheduler, and replay contracts.

Evidence-based selection
Recovery

Every mutation has a reverse path

No migration deletes the prior installation or rewrites live state in place. Destructive cleanup waits until post-cutover acceptance and backup expiry.

Shadow failure

Stop the shadow process and delete only its verified temporary home. Live ports and tasks were never touched.

Personal cutover failure

Repoint the personal task/alias to the old shared executable and restart :8642 against the unchanged default home.

Nagato cutover failure

Repoint the Nagato task to the old shared executable, restart :8643, then restore bridge health on :8765.

Memory provider failure

Disable the external provider per affected runtime and return to built-in memory; never delete provider data during rollback.

Scheduler failure

Return each client base URL to its previous direct Featherless path while the shared patch set still exists.

Plans-service failure

Disable the new /p and API routes; legacy sanitized static /plans remains independently served.

No user input is required to finish planning

The next state-changing action is R1: diagnose/restore the existing bridge, create backups, and prepare isolated worktrees/build directories. Before R6, the live gateway cutover will pause for an agreed maintenance window and explicit human approval.