Plan, build, verify, and document a polished private Hermes desktop on this Windows computer through safe, reversible phases. Execute the phases rather than merely summarizing them.

USER CONTEXT AND ULTIMATE GOAL

- Operating system: Windows.
- GPU: NVIDIA GeForce RTX 3090 with 24 GB dedicated VRAM.
- System RAM: 128 GB.
- The chosen Qwen model is already downloaded and running through Ollama.
- Hermes Desktop and a paid, cloud-capable Hermes profile already exist and must remain unchanged and usable.
- The supplied assumptions say that official Hermes Desktop source is MIT-licensed in the NousResearch/hermes-agent repository and that Ollama officially supports launching Hermes Desktop with `ollama launch hermes-desktop`. Treat both as claims to verify against current official sources before relying on them.
- The end state is a polished personal-agent and Chief-of-Staff desktop whose model, harness, tools, memory, sessions, skills, files, and any future optional speech stack are local and independently verifiable.

ARCHITECTURE LANGUAGE

Keep the layers explicit throughout the work:

- Qwen is the model.
- Ollama is the local model runtime and API server.
- Hermes Desktop, Codex CLI, Pi, or another chosen harness is the tool/orchestration layer.
- Windows, WSL, containers, or a VM provide the operating-system and isolation boundary.

Source availability, an MIT license, vendor documentation, local-looking settings, and a localhost model URL are supporting evidence. None of them alone proves runtime privacy or that every component is local.

GLOBAL RULES

1. Use only public documentation, synthetic examples, dummy repositories, and non-sensitive test data until every private-lane stop gate passes.
2. Never send private company IP, credentials, customer data, proprietary source, internal documents, private memories, or sensitive prompts to the cloud-capable Hermes or another external service.
3. Preserve the existing online/cloud Hermes installation and paid profile unchanged and usable. Never disable, overwrite, uninstall, migrate, or repurpose it while building the private system.
4. Make every phase reversible. Before each mutation, show the intended changes, affected targets, risks, rollback, and verification plan.
5. Never expose secret values in output, logs, diffs, screenshots, evidence packets, or commands.
6. Do not authorize destructive deletion, production changes, credential disclosure, broad system cleanup, or transmission of private IP.
7. Stop for owner input only when a choice is genuinely necessary, authorization is required, an operation is destructive or materially risky, or evidence reveals ambiguity that changes the safe path. Otherwise continue safe, reversible, non-sensitive work.
8. Fail closed. Do not fabricate proof or silently substitute a cloud service when a local component is unavailable.
9. Keep a durable phase/status table and evidence ledger from the beginning.

PHASE 0 — FACT-CHECK AND INSPECT BEFORE CHANGING ANYTHING

Treat every supplied fact as a hypothesis. Before installing, launching, editing, signing out, or changing configuration:

1. Verify against current official sources:
   - The canonical NousResearch/hermes-agent repository and the exact Hermes Desktop source location.
   - The current license covering the source and any separately licensed bundled assets or dependencies.
   - Current official Hermes Desktop build and profile documentation.
   - Current official Ollama documentation for Hermes Desktop integration, including whether `ollama launch hermes-desktop` remains supported and exactly what it installs, configures, launches, or contacts.
   - Current Ollama cloud-model, sign-in, local-model, bind-address, and OpenAI-compatible API behavior.
2. Inspect the actual Windows/Hermes/Ollama state:
   - Windows version, hardware, driver, available RAM/VRAM, free disk, and relevant virtualization/WSL state.
   - Hermes Desktop version, installation source, install path, process tree, profiles, HERMES_HOME or equivalent state roots, app data, config, credentials, sessions, memory, skills, logs, plugins, connectors, gateways, startup behavior, and listening ports.
   - Ollama version, account/cloud state, configuration, listening address, local model inventory, exact installed Qwen artifacts, running processes, and current connections.
   - Existing online Hermes shortcuts, app identity, services, scheduled tasks, firewall rules, browser integrations, WSL/container components, and credential-store entries.
3. Discover the exact working non-cloud Ollama model tag from the local inventory. Do not guess, pull, or substitute a model.
4. Record every correction in a table: supplied assumption, official or observed evidence, correction, impact, and next action.
5. Report corrections before changing anything. If the official source, license, launch path, or local-model claim is materially different, revise the plan and explain why.

PHASE 1 — INVENTORY, BACKUP, AND CREATE A SEPARATE PRIVATE IDENTITY

Build a secret-safe baseline and rollback foundation.

1. Inventory and back up current Hermes config, profiles, credential metadata, sessions, memory, skills, app data, launchers, and relevant system integration. Redact secret values.
2. Hash or semantically snapshot the existing online/cloud profile so later phases can prove it was not changed.
3. Preserve “Hermes Online” as the clear name and purpose of the current installation: public web/cloud research with no sensitive private-company content.
4. Create “Hermes Private” as a distinct identity. Where supported, give it:
   - A fresh blank profile.
   - A separate HERMES_HOME or equivalent state root.
   - Separate config, credentials, app data, sessions, memory, skills, caches, logs, and temporary files.
   - A distinct app name, shortcut, icon, application identity, or package identity.
   - A separate project folder and working directories.
   - Separate ports or IPC names if required to prevent collisions.
5. Never clone or copy online/cloud credentials, tokens, cookies, login state, chats, memory, sessions, caches, skills, plugins, gateways, remote MCP configuration, provider fallbacks, or automatic handoffs.
6. Do not silently change the default profile or launcher. Make selection of Online versus Private explicit.
7. Write a rollback manifest with every backed-up item, current hash/state, new target, restore command or action, and validation check.
8. Prove Hermes Online still opens and remains usable without introducing private data or altering its profile.

PHASE 2 — PROVE THE OFFICIAL HERMES DESKTOP + OLLAMA PATH FIRST

Do not fork, strip, or source-modify Hermes Desktop yet. First test the officially supported path using the exact local non-cloud Qwen model and the loopback endpoint.

1. Verify what `ollama launch hermes-desktop` will do in the current versions before running it. Show a change/network preview and preserve rollback.
2. Configure the new Hermes Private identity to use only the exact discovered local Qwen tag through the intended localhost endpoint, expected to be:

   http://127.0.0.1:11434/v1

   If current official behavior differs, stop and report the correction before proceeding.
3. Use only a non-secret placeholder if a local OpenAI-compatible provider schema requires an API-key field. Never copy a cloud credential.
4. Keep all tests inside a disposable dummy project with synthetic content.
5. Prove the basic desktop workflow end to end:
   - Ordinary chat.
   - Harmless local file read and edit with byte verification.
   - A harmless terminal command.
   - A local Git operation in a disposable repository without fetch or push.
   - Profile-local memory persistence.
   - Session creation, history, reopen, and restart persistence.
   - A harmless local skill.
   - Tool-result propagation from tool execution back into the model’s next turn and visible final answer.
6. Explicitly test known-risk areas rather than assuming them away:
   - Ollama tool-call and tool-result formatting/propagation through Hermes Desktop.
   - Session-history completeness, including tool inputs, tool outputs, assistant turns, memory events, attachments, and restored context after reopening.
   - Multiple consecutive tool calls and a tool failure path.
7. Record exact versions, commands, configuration, UI path, expected behavior, observed behavior, logs, and failures.
8. If the official path cannot complete the workflow, preserve evidence, keep Hermes Online intact, and diagnose the smallest reversible correction. Do not jump directly to broad code removal.

PHASE 3 — LOCAL-CORE STOP GATE

Do not call the private lane fully local merely because Phase 2 works.

1. Disable Ollama cloud features and cloud-model access, and log the exact change. Sign out or remove cloud linkage if current official guidance requires it, without deleting the confirmed local Qwen model.
2. Prove the exact model tag is a local non-cloud model with local artifacts.
3. Prove the exact endpoint, bind address, and owning process. Ollama must listen only on loopback, never 0.0.0.0 or a LAN interface.
4. Run the Phase 2 workflow with the physical internet disconnected or outbound traffic blocked by a controlled, reversible method.
5. Stop Ollama deliberately, send a harmless chat request, and prove Hermes Private fails clearly. It must not return a cloud-generated answer, switch models, call an auxiliary model, or silently use a fallback.
6. Restart Ollama and Hermes Private, then prove the workflow and persistent state recover.
7. Collect Windows process, child-process, listening-port, connection, DNS, firewall, and packet evidence showing that inference traffic is loopback-only.
8. Record every contacted endpoint with hostname/IP, port, protocol, process, reason, data category, and whether content was transmitted.
9. Treat any auxiliary model, updater, browser/web tool, gateway, voice service, plugin, connector, remote MCP server, fallback, telemetry process, or subprocess capable of external transmission as an open gate.
10. If anything unexplained can call out, report the lane as not yet fully local and keep private company IP out.

PHASE 4 — SOURCE-BUILD THE OFFICIAL DESKTOP AS A SEPARATE PRODUCT

Only after the official path works and Phase 3 evidence is recorded:

1. Create a separate source checkout and build workspace for Hermes Private. Do not modify the online installation directory.
2. Verify the canonical source repository, exact commit, tag or branch, commit signature where available, applicable license, submodules, release notes, and security/build documentation.
3. Inspect dependency manifests and lockfiles. Record package-manager versions and resolve dependencies exactly from lockfiles where supported.
4. Produce a dependency and build-network preview. Do not expose credentials or private content to build services.
5. Build Hermes Desktop locally under a distinct product/package identity. Keep separate app data, shortcuts, installer identity, update identity, and state roots.
6. Record source commit, dependency-lock hashes, build configuration, compiler/runtime versions, installer and binary outputs, and hashes where practical.
7. Verify the built desktop uses the intended local Hermes backend and the exact Ollama model/endpoint rather than the existing online backend.
8. Re-run the complete Phase 2 and Phase 3 suite against the source build.
9. Never overwrite, uninstall, rename, or disable the working Hermes Online installation during this phase.

PHASE 5 — HARDEN ONE REVERSIBLE SLICE AT A TIME

Do not perform a big-bang rewrite. For each slice: preview the exact files/settings/code, back up, make one cohesive change, build, run the full functional suite, run the full network suite, compare with the prior evidence baseline, and either accept or roll back.

Discover actual features in source and runtime behavior. Disable or remove from Hermes Private, one verified slice at a time:

- Cloud model providers and every fallback chain.
- Hosted auxiliary, routing, compression, summarization, title, embedding, memory, planning, or background models.
- Nous login, portal, dashboard, account, subscription, and cloud-profile connections.
- Remote gateways, messaging integrations, and remote agent services.
- Web search and browser tools.
- Remote MCP servers.
- Marketplace, skill discovery, and automatic skill or plugin downloads.
- Cloud speech-to-text and text-to-speech.
- Automatic update checks, telemetry, crash upload, analytics, asset download, and other remote fetches.
- Remote handoff, continuation, synchronization, and cross-device features.
- Mixed local/cloud mixture-of-agents or routing behavior.
- Any additional outbound feature or subprocess found during source and runtime inspection.

After each slice, keep these local capabilities working:

- Local files and previews.
- Terminal commands.
- Local Git operations.
- Local memory and session history.
- Local skills.
- Tool-result propagation.
- Ollama model access.
- Restart recovery.

Do not assume a disabled UI control or configuration flag prevents runtime access. Trace source paths, environment variables, process spawning, network clients, default fallbacks, and error behavior, then verify with observed execution.

PHASE 6 — ENFORCE LOCALITY AT THE OPERATING-SYSTEM BOUNDARY

Application configuration is one layer, not the final boundary.

1. Map the full Hermes Private process tree, subprocess launch paths, helper processes, shells, WSL commands, containers, browser processes, plugin hosts, and update processes.
2. Define a least-privilege execution identity and minimum file-system/project access appropriate to the private app.
3. Design an outbound-deny policy scoped to Hermes Private and everything it can launch, permitting only the minimum loopback/local communication required for Ollama and approved local services.
4. Account explicitly for Windows Firewall behavior, per-program rules, service identities, IPv4 and IPv6 loopback, Windows-to-WSL networking, WSL-to-Windows networking, container bridges, NAT, proxies, DNS, and subprocess escape paths.
5. Produce a firewall/system-change preview with exact rules, targets, expected impact, rollback commands, and recovery access.
6. Require owner approval before applying broad, privileged, or potentially disruptive operating-system changes.
7. Never change unrelated system firewall policy, shared WSL networking, other applications, production environments, or the Hermes Online network path.
8. After applying an approved scoped policy, run the complete functional, deliberate-failure, restart, process-tree, and network regression suite.
9. Prove that an allowed local workflow succeeds and a deliberately attempted external connection from the private app or relevant child process is denied and logged.

PHASE 7 — MAINTAIN TWO CLEARLY SEPARATED PRODUCTS

The final desktop must make the boundary obvious:

- “Hermes Online” is for public web/cloud research and must not receive sensitive private-company content.
- “Hermes Private” is for verified offline/local work after all gates pass.

They must not share profiles, credentials, tokens, memory, chats, session databases, caches, logs, plugins, gateways, remote MCP configuration, working directories, project indexes, clipboard automation, or automatic handoffs.

Use distinct names, shortcuts, app identities, state roots, visual indicators, and project directories where supported. Add a visible privacy-state indicator to Hermes Private based on verified runtime state, not marketing language.

Private company IP may enter only after every private-lane gate passes. Deleting an online or bootstrap installation later cannot undo any information previously disclosed to a cloud service. Future private IP introduced only after verified separation is not exposed merely because Hermes Online helped bootstrap the private system using public or dummy data.

Re-run the gate after material source updates, model changes, Ollama changes, added tools, new skills, new plugins, connector changes, firewall changes, or state migration.

PHASE 8 — OPTIONAL LOCAL VOICE AND DELIBERATE RESEARCH BRIDGES

Voice is a later optional module, not part of the local-core gate.

1. Keep voice disabled until the text/tool desktop passes every local gate.
2. If voice is added, use independently verified local speech-to-text and local text-to-speech components with local model/assets and observed offline behavior.
3. Do not claim official cloud voice, hosted transcription, or hosted synthesis is local.
4. Apply the same process-tree, file-access, outbound-deny, failure, restart, and evidence tests to the speech stack.
5. Keep web research in Hermes Online by default.
6. Design a bridge to Hermes Private only as a separately approved project with explicit data minimization, one-way flow where practical, content review/redaction, provenance, logging, and proof that private context is not sent outward.
7. No automatic online-to-private or private-to-online handoff is permitted.

PHASE 9 — THREAT-CALIBRATED RETIREMENT OPTION

After Hermes Private passes, offer—but do not automatically execute—a retirement path for a bootstrap installation. Do not accuse Hermes of malware without evidence.

Inventory:

- Installed files, directories, packages, package-manager records, and configuration.
- Services, processes, startup entries, scheduled tasks, update agents, and native helpers.
- Listening ports, firewall rules, environment variables, certificates, credential-store entries, and account sessions.
- Browser extensions, native messaging hosts, profiles, and browser integrations.
- WSL distributions, packages, services, mounts, integration files, and Windows interop.
- Virtual machines, containers, gateways, plugins, connectors, remote agents, and cached installers.

Then:

1. Produce an exact removal preview: target, path/identifier, evidence it is owned by the bootstrap Hermes, expected impact, shared dependencies, backup/export, rollback, and post-removal check.
2. Revoke confirmed Hermes-related tokens, sessions, OAuth grants, and API keys from the provider side where possible.
3. Require explicit approval before uninstalling, deleting, revoking, or destroying anything.
4. Uninstall only confirmed owned components. Preserve shared runtimes, models, repositories, browser data, WSL assets, and unrelated applications.
5. Destroy a WSL distribution or VM only after proving it is dedicated to the bootstrap Hermes, contains no unrelated files, packages, credentials, services, or user data, and has any required rollback export.
6. Otherwise avoid broad deletion. Never perform a root-level purge, sweeping wildcard deletion, indiscriminate registry cleanup, or removal of shared firewall/credential entries.
7. Reboot Windows after approved removal.
8. Verify that no removed process, service, task, startup entry, listener, browser integration, WSL component, token refresh, updater, or outbound connection returns after reboot.
9. Preserve the inventory, preview, approvals, actions, hashes, token-revocation evidence, reboot evidence, and rollback references.

PHASE 10 — DURABLE EVIDENCE PACKET AND NEXT SAFE ACTION

Maintain and return a concise, secret-safe packet containing:

- Corrected assumptions with authoritative citations and observed-state evidence.
- Architecture diagram or mapping of model, runtime, harness, state roots, process boundary, and network boundary.
- A phase/status table with not-started, in-progress, passed, failed, rolled-back, or owner-decision-needed status.
- Exact changes, source commits/tags, lockfile hashes, build inputs, installer/binary hashes, and package identity.
- Backups, exports, rollback manifest, and recovery-test results.
- Exact local Qwen model tag, local artifact proof, Ollama version, bind address, endpoint, and Hermes Private model-role configuration.
- Functional results for chat, file edit, terminal, Git, memory, sessions/history, skills, tool results, failures, and restart.
- Offline, deliberate Ollama-stop, process-tree, port, firewall, DNS, packet, and endpoint-contact evidence.
- Every unexpected behavior, failed assertion, residual risk, unverified assumption, and remaining exit door.
- The exact next safe action, including any owner decision genuinely required.

At the end of every phase, update the packet and state whether private company IP is still forbidden. Do not proceed past a failed stop gate unless the phase explicitly exists to diagnose and safely correct that failure.

Never claim “completely immune,” “guaranteed private,” “fully private,” “air-gapped,” or “fully local” until direct functional, source, process, and network evidence supports the exact claim. If proof is incomplete, say so plainly and continue only safe, reversible, non-sensitive work.