Bootstrap, verify, and transition to a secure local AI system on this Windows computer without exposing private company intellectual property during the build.

GREATER GOAL

Use the currently installed, cloud-connected Hermes only as a temporary bootstrap assistant and only with public information, synthetic examples, or dummy data. Build a separate local system that can later handle private company work after every separation and privacy stop gate has passed.

Keep the architecture clear:

- Qwen is the model: the intelligence that generates responses.
- Ollama is the local runtime: the process that loads and serves the chosen Qwen model.
- Hermes, Codex CLI, Pi, or another selected harness is the tool and orchestration layer: the interface that manages chat, files, commands, Git, memory, skills, and tool use.

Do not blur those roles. A local model does not make a cloud-connected harness private, and a local harness does not prove that every auxiliary service is local.

DATA BOUNDARY DURING BOOTSTRAP

- Treat the installed cloud-connected Hermes as untrusted for private-data handling, but do not describe it as malware or imply malicious behavior without evidence.
- Give the bootstrap Hermes only public documentation, dummy repositories, synthetic files, invented company names, and non-sensitive test data.
- Keep all private company IP, source code, credentials, customer data, strategies, internal documents, private memories, and proprietary prompts out of the bootstrap process until every stop gate below passes.
- Never paste private content into a cloud chat to ask whether the local system is safe.
- Deleting or uninstalling Hermes later cannot undo anything previously disclosed to a cloud service.
- Future private data introduced only after verified separation is not exposed merely because Hermes helped build the local system with public or dummy data.

BASELINE AND ROLLBACK

Before changing anything:

1. Record Windows version, Hermes version and installation method, Ollama version, selected harness version, current profiles, model/provider settings, listening ports, startup behavior, and relevant network connections.
2. Export or back up existing configurations without printing secrets.
3. Record hashes or secret-safe semantic snapshots of the existing cloud-connected Hermes profile so later checks can prove it remained unchanged.
4. Create a rollback plan for every configuration, firewall, startup, package, service, WSL, VM, and profile change.
5. Do not delete the currently working environment during the bootstrap phase.

BUILD A SEPARATE LOCAL SYSTEM

Create a fresh local-only profile or environment. If Hermes is the chosen harness, name the blank profile local-private unless an already verified local-private profile exists. If another harness is chosen, create an equivalently isolated, newly initialized configuration.

Never clone, copy, import, or migrate from the cloud-connected Hermes profile. Do not copy any cloud credential, OAuth token, API key, cookie, provider secret, conversation, memory, skill state, telemetry identity, or hosted-service configuration.

For the new local environment, disable or omit by default:

- Cloud model providers and fallback providers.
- Hosted auxiliary, router, compression, summarization, title, embedding, memory, planning, or background models.
- Web search and browser tools.
- Voice, speech-to-text, and text-to-speech services.
- Plugins, connectors, gateways, remote MCP servers, remote agents, and remote handoff or continuation features.
- Telemetry, update checks, crash upload, cloud synchronization, hosted memory, and automatic remote Git operations where the software allows them to be disabled.

Any outbound capability may be added later only as a separate, clearly labeled feature after explicit user approval, a documented data boundary, and a test showing exactly what it transmits.

OLLAMA AND MODEL PROOF

Do not guess the model tag or assume that every Ollama model is local.

1. Inspect the installed Ollama configuration, account state, model inventory, and current official documentation.
2. Disable Ollama cloud features and cloud-model access. Sign out or remove cloud linkage if required, without deleting the confirmed local model.
3. Discover the exact working non-cloud Qwen model tag from the local Ollama inventory. Verify that its model artifacts are present locally and that it does not resolve to a cloud-only model.
4. Use only the loopback OpenAI-compatible endpoint:

   http://127.0.0.1:11434/v1

5. Verify Ollama listens only on 127.0.0.1 or the equivalent loopback interface, never 0.0.0.0 and never a LAN address.
6. Configure normal chat and every harness-internal model role to use the exact discovered local Qwen tag through that endpoint.
7. If the harness requires an API-key field for this local endpoint, use only a non-secret placeholder. Never reuse a cloud credential.
8. Fail closed if the local model is unavailable. Do not permit a silent cloud or hosted-model fallback.

FUNCTIONAL AND FAILURE TESTS

Use only a disposable directory, dummy repository, synthetic memory, and harmless commands. Keep private company IP out of all tests.

Run and record:

1. Offline chat: with outbound internet blocked, complete an ordinary chat and prove the request went to the exact local Qwen model through 127.0.0.1:11434.
2. Local file edit: create, read, edit, and verify a harmless dummy text file inside the approved test directory.
3. Harmless command: run a command such as printing the current directory and capture the result.
4. Local Git: inspect status in the dummy repository without fetch, push, or any remote contact.
5. Local state: if memory or skills are enabled, use only synthetic test content and verify persistence without an external endpoint.
6. Deliberate Ollama-stop failure: stop Ollama cleanly, send a harmless chat request, and prove the harness fails clearly without contacting a fallback provider or returning a cloud-generated answer.
7. Restart recovery: restart Ollama and the chosen harness, explicitly activate the new local profile, and prove chat, file access, and any local state recover without enabling a cloud connection.

NETWORK AND PROCESS EVIDENCE

Settings alone are not proof. Run the complete test suite with outbound internet blocked or under an equivalent trustworthy Windows process/network observation method.

Collect evidence from Windows tools appropriate to the installed environment, such as process inventory, listening-port inspection, connection monitoring, firewall logs, packet capture, and child-process tracking.

Prove all of the following:

- The inference-serving process is Ollama and the selected harness reaches it only over loopback.
- Model traffic uses only http://127.0.0.1:11434/v1 and the exact non-cloud Qwen tag.
- No model, fallback, auxiliary model, web tool, voice service, plugin, connector, gateway, remote handoff, telemetry, or update service transmits test content externally.
- The deliberate stop-Ollama test produces a visible failure and no silent fallback.
- After restart, the same loopback-only behavior remains in effect.

Record every hostname, IP, port, protocol, process, reason, and whether any content was transmitted. Investigate unexplained DNS lookups and external connection attempts. If the evidence is incomplete or any unexplained callout remains, keep private company IP out and report that the system has not passed.

STOP GATES BEFORE PRIVATE COMPANY IP

Private company IP may enter the system only after all of these gates pass:

- A fresh local-only profile/environment exists and the cloud profile remains unchanged.
- The exact local Qwen model tag and local artifacts are verified.
- Ollama cloud access is disabled and its API is loopback-only.
- Cloud providers, fallbacks, hosted auxiliary models, web tools, voice, plugins, connectors, gateways, telemetry, and remote handoff are disabled or absent.
- Offline chat, file edit, harmless command, local Git/state, deliberate Ollama-stop failure, and restart recovery all pass.
- Windows process and network evidence shows loopback-only inference with no unexplained external callout.
- Rollback and recovery instructions are saved and tested.

Only after every gate passes may private company IP be introduced, and then only inside the verified local environment. Re-run the network/process test after material upgrades, model changes, new tools, new plugins, new connectors, or profile changes.

THREAT-CALIBRATED BOOTSTRAP HERMES CLEANUP

After the new local system passes, prepare a cleanup plan for the temporary bootstrap Hermes installation. Do not accuse Hermes of malware. Cleanup is about minimizing future exposure and reducing unused cloud-connected components.

Inventory before removal:

- Installed files, directories, packages, package-manager records, and configuration.
- Windows services, running processes, startup entries, and scheduled tasks.
- Listening ports, firewall rules, environment variables, certificates, and credential-store entries.
- Browser extensions, native messaging hosts, browser profiles, or other browser integrations.
- WSL distributions, packages, services, mounts, and integration files.
- Virtual machines, containers, gateways, connectors, plugins, remote agents, and update mechanisms.
- Cloud sessions, OAuth grants, API tokens, cookies, device authorizations, and remote account integrations.

Then:

1. Revoke confirmed Hermes-related cloud tokens, sessions, OAuth grants, and API keys from the provider side where possible.
2. Produce a removal preview listing every proposed target, why it is Hermes-owned, the evidence of ownership, expected impact, and recovery path.
3. Require explicit approval before uninstalling or deleting anything.
4. Uninstall only confirmed Hermes-owned components. Preserve shared runtimes, user repositories, models, unrelated packages, shared browser data, and other applications.
5. If Hermes is contained in a dedicated WSL distribution or virtual machine, full destruction is allowed only after proving that it contains no unrelated files, packages, credentials, services, or user data and after preserving any required rollback export.
6. If Hermes shares a WSL distribution, Windows environment, Python/Node installation, browser profile, or other runtime, avoid broad deletion. Remove only individually confirmed Hermes-owned components.
7. Do not use sweeping wildcard deletion, broad registry cleanup, indiscriminate credential removal, or removal of shared firewall rules.
8. Reboot Windows after approved cleanup.
9. After reboot, verify that no removed Hermes process, service, task, startup entry, listener, browser integration, WSL component, token refresh, or external callout restarts.
10. Preserve the inventory, removal preview, approvals, actions, reboot evidence, and rollback/export references.

EVIDENCE RECEIPT

Return a concise, secret-safe receipt containing:

- Architecture: exact Qwen model tag, Ollama version/endpoint, chosen harness/version, and profile/environment name.
- Cloud-profile preservation evidence and confirmation that bootstrap inputs were public, synthetic, or dummy data.
- Disabled cloud/fallback/auxiliary/web/voice/plugin/connector/gateway/telemetry/handoff capabilities.
- Results for offline chat, file edit, harmless command, local Git/state, deliberate Ollama-stop failure, and restart recovery.
- Windows process and network observations, including a complete endpoint-contact table.
- Every stop gate with pass/fail evidence and the decision on whether private company IP is permitted yet.
- Configuration/change log, backups, rollback steps, and recovery test.
- Cleanup inventory and removal preview, or approved cleanup actions and post-reboot verification if cleanup was authorized.
- Residual risks and unverified assumptions.

Do not claim the system is "completely immune," "guaranteed private," "air-gapped," or "fully local" without direct evidence supporting the exact claim. If any required evidence is missing, state that verification is incomplete and keep private company IP out.