chore: adopt NovaForge compute contract

.vscode/tasks.json

@@ -0,0 +1,67 @@
+{
+  "version": "2.0.0",
+  "tasks": [
+    {
+      "label": "Compute Guard: Check command",
+      "type": "shell",
+      "command": "${workspaceFolder}/scripts/check-compute-distribution.sh \"${input:guardCommand}\"",
+      "problemMatcher": []
+    },
+    {
+      "label": "Remote Compute: Dry run command",
+      "type": "shell",
+      "command": "${env:HOME}/.codex/bin/remote-compute-run --dry-run -- ${input:remoteCommand}",
+      "problemMatcher": []
+    },
+    {
+      "label": "Remote Compute: Run command on Hetzner",
+      "type": "shell",
+      "command": "${env:HOME}/.codex/bin/remote-compute-run -- ${input:remoteCommand}",
+      "problemMatcher": []
+    },
+    {
+      "label": "Remote Compute: Provision workspace",
+      "type": "shell",
+      "command": "${env:HOME}/.codex/bin/remote-compute-provision",
+      "problemMatcher": []
+    },
+    {
+      "label": "Remote Compute: Git status on Hetzner",
+      "type": "shell",
+      "command": "${env:HOME}/.codex/bin/remote-compute-run --no-update -- git status --short --branch",
+      "problemMatcher": []
+    },
+    {
+      "label": "Remote Compute: Doctor",
+      "type": "shell",
+      "command": "${env:HOME}/.codex/bin/remote-compute-doctor --quick ${workspaceFolder}",
+      "problemMatcher": []
+    },
+    {
+      "label": "Remote Compute: Inventory",
+      "type": "shell",
+      "command": "${env:HOME}/.codex/bin/remote-compute-inventory ${workspaceFolder}",
+      "problemMatcher": []
+    },
+    {
+      "label": "Local Sovereignty Audit",
+      "type": "shell",
+      "command": "${env:HOME}/.codex/bin/local-sovereignty-audit",
+      "problemMatcher": []
+    }
+  ],
+  "inputs": [
+    {
+      "id": "guardCommand",
+      "type": "promptString",
+      "description": "Workload or local command to classify",
+      "default": "pnpm test"
+    },
+    {
+      "id": "remoteCommand",
+      "type": "promptString",
+      "description": "Command to run on Hetzner from this repo's remote workspace",
+      "default": "git status --short --branch"
+    }
+  ]
+}

AGENTS.md

@@ -0,0 +1,72 @@
+# Remote Compute Distribution
+
+This project follows the Mac Mini / Hetzner compute boundary.
+
+## Execution Identity
+
+- `Mac_Mini`: local control surface only.
+- `Hetzner_AX102`: remote metabolic infrastructure.
+
+## Mac Mini Allowed
+
+- VS Code GUI
+- editing
+- code navigation
+- git status, diff, branch, commit, push, pull, PR metadata
+- local secrets and signing material
+- lightweight smoke checks that finish quickly and do not create sustained memory, swap, thermal, Docker, indexing, OCR, embedding, build, or test load
+
+## Hetzner Required
+
+- dependency installs
+- Docker and devcontainers
+- full test suites
+- CI reproduction
+- heavy builds and release packaging
+- long-running dev servers
+- database services
+- embeddings, vectorization, semantic indexing
+- OCR and batch document processing
+- coverage generation
+- benchmark gates
+- background inference
+
+## Required Workflow
+
+Open the project through VS Code Remote SSH when doing real implementation:
+
+```text
+VS Code GUI: Mac Mini
+Workspace: Hetzner
+Terminal: Hetzner
+Heavy proof: GitHub Actions or Hetzner
+```
+
+Local Mac checkouts are for navigation, small edits, and emergency fixes only. Do not present heavy local execution as completion proof.
+
+## Proof Integrity
+
+Remote proof must correspond to explicit project state. If the local worktree is
+dirty, `remote-compute-run` refuses by default because the Hetzner workspace may
+represent stale code. Commit or stash the local changes, use
+`remote-compute-provision` for a clean bundle, or use `--allow-dirty-local`
+only as an explicit human-approved non-proof override.
+
+## Versionability
+
+The compute-distribution contract surfaces must be versionable:
+
+- `docs/compute-distribution.md`
+- `docs/operator-tooling.md`
+- `docs/remote-workspace.md`
+- `docs/novaforge-ax102-stack.md`
+- `scripts/check-compute-distribution.sh`
+- `AGENTS.md`
+- `.vscode/tasks.json`
+
+Do not hide these files behind `.gitignore`. `remote-compute-audit` treats
+ignored contract files as invalid even when they exist locally.
+
+## Override
+
+Local heavy compute requires explicit human override for the specific task. Hidden fallback to the Mac Mini is invalid.

README.md

@@ -189,3 +189,9 @@ Current CI enforces:
 - typecheck (`pnpm typecheck`)
 - build (`pnpm build`)
 - baseline tests (`pnpm test`)
+
+## Compute Distribution
+
+This project follows the Mac Mini / Hetzner split documented in `docs/compute-distribution.md`.
+Use VS Code Remote SSH for normal implementation and use GitHub Actions or Hetzner output as proof for heavy gates.
+See `docs/operator-tooling.md` and `docs/remote-workspace.md` for the operator contract and remote workspace proof rules.

docs/compute-distribution.md

@@ -0,0 +1,129 @@
+# Compute Distribution
+
+This project uses the global Mac Mini / Hetzner workload split.
+
+## Rule
+
+The Mac Mini is the local control surface. Hetzner is the compute substrate.
+
+## Local Safe
+
+- VS Code GUI
+- code reading and editing
+- `git status`
+- `git diff`
+- `git log`
+- small targeted smoke checks
+- secrets/signing operations that must remain local
+
+## Remote Required
+
+- dependency installation
+- Docker and devcontainers
+- full test suites
+- CI reproduction
+- release builds and packaging
+- coverage
+- benchmarks
+- OCR
+- embeddings
+- vector indexing
+- long-running servers
+- databases
+- background inference
+
+## Operator Workflow
+
+Use VS Code Remote SSH for normal work:
+
+```text
+Remote host: hetzner-server
+Remote workspace: /home/krille/workspaces/selectpilot
+```
+
+Use GitHub Actions or Hetzner terminal output as proof for heavy gates. Local Mac output is valid only for bounded smoke checks.
+
+Remote proof is valid only when it corresponds to the explicit project state.
+If the local worktree is dirty, `remote-compute-run` must refuse by default
+because the Hetzner workspace may represent stale code. Commit or stash the
+local changes, use `remote-compute-provision` for a clean bundle, or make an
+explicit human-approved non-proof override with `--allow-dirty-local`.
+
+Dirty protected repositories require read-only reconciliation evidence before
+any merge, stash, branch, reset, or manual integration strategy is selected.
+Use `remote-compute-reconcile-report` to surface upstream delta, dirty count,
+local-only contract files, changed paths, and a recommended next step without
+mutating the worktree. The same evidence is available with
+`remote-compute-reconcile-report --json`.
+Use `remote-compute-inventory-summary` before broad adoption decisions to expose
+protected, dirty-protected, external, container/no-origin, and auto-adopt
+candidate counts without mutating repositories.
+Use `remote-compute-inventory-action-plan` to convert inventory state into a
+read-only per-repository action plan before deciding whether a repo needs
+reconcile approval, fork/ownership decision, project identity decision, or no
+action.
+Use `remote-compute-inventory-decision-template` to turn unresolved action-plan
+rows into a read-only, human-fillable decision template. Unresolved decisions
+must remain `selected_decision: null` and `mutation_allowed: false` until a
+separate human review fills the template.
+Use `remote-compute-reconcile-plan` to inspect the read-only phase plan before
+any human-approved local mutation.
+Use `remote-compute-reconcile-preservation-plan` to inspect the dirty head,
+dirty count, suggested preservation branch, verified-export requirement, and
+human-approval requirement before any dirty protected repository is mutated.
+Use `remote-compute-reconcile-export --out <dir>` to write patches and evidence
+outside the source repository before a manual reconcile.
+Exported reconcile evidence must include checksums for replayability and
+integrity review.
+Verify exported reconcile evidence with
+`remote-compute-reconcile-verify-export <dir>` before manual application.
+Run `remote-compute-reconcile-mutation-preflight <dir>` before any
+human-approved mutation to prove the verified export still matches current
+dirty repository state.
+Generate `remote-compute-reconcile-approval-template <dir>` before any dirty
+protected repository is mutated; every repository must remain `approved: false`
+until explicit human review changes that approval outside this read-only step.
+Verify the human-filled approval file with
+`remote-compute-reconcile-verify-approval <dir> <approval.json>` before any
+mutation; approval is invalid unless each repository row is explicitly approved
+with reason, approver, and timestamp.
+Generate `remote-compute-reconcile-mutation-packet <dir> <approval.json>` after
+approval verification and before mutation; the packet must remain read-only and
+surface exact preservation branches, dirty heads, evidence paths, and
+operator-visible commands.
+
+## Versionability
+
+These contract surfaces must be versionable and must not be hidden by
+`.gitignore`:
+
+- `docs/compute-distribution.md`
+- `docs/operator-tooling.md`
+- `docs/remote-workspace.md`
+- `docs/novaforge-ax102-stack.md`
+- `scripts/check-compute-distribution.sh`
+- `AGENTS.md`
+- `.vscode/tasks.json`
+
+`remote-compute-audit` fails closed if any of these files exist only as ignored
+local state.
+
+## NovaForge Stack
+
+This project docks into the AX102 stack documented in
+`docs/novaforge-ax102-stack.md`.
+
+## Operator Tooling
+
+`docs/operator-tooling.md` defines the local tools that enforce this boundary.
+`docs/remote-workspace.md` defines the Hetzner workspace and proof rules.
+
+## Local Guard
+
+Run:
+
+```bash
+scripts/check-compute-distribution.sh "command or workload description"
+```
+
+The guard exits non-zero for known heavy local workloads.

docs/novaforge-ax102-stack.md

@@ -0,0 +1,84 @@
+# NovaForge AX102 Stack
+
+NovaForge is the operational expression of the compute-distribution boundary on
+Hetzner AX102.
+
+It is not generic hosting and must not become a remote desktop replacement. Its
+topology is:
+
+```text
+persistent sovereign metabolic layer
+```
+
+## Role
+
+NovaForge carries sustained thermodynamic load for Namaka systems:
+
+- dependency installation
+- Docker and devcontainer execution
+- full tests, heavy builds, coverage, benchmarks, and release packaging
+- persistent PostgreSQL, Redis, ChromaDB, queues, replay engines, and runtime services
+- OCR, embeddings, vectorization, chunking, semantic indexing, and batch processing
+- monitoring, backup, and long-running service stability
+
+The Mac Mini remains the sovereign control surface for UI, editing, git
+metadata, local secrets, signing material, orchestration approval, lightweight
+smoke checks, and local reasoning.
+
+## Base System
+
+The AX102 baseline is Ubuntu Server 24.04 LTS.
+
+Required service classes are:
+
+- Docker Compose
+- remote devcontainers
+- PostgreSQL
+- Redis
+- ChromaDB
+- queue workers
+- OCR workers
+- embedding workers
+- semantic indexing workers
+- reverse proxy
+- monitoring
+- backup
+
+Implementation may use different package managers or deployment automation, but
+the resulting system must expose these service classes as explicit, inspectable
+infrastructure. Hidden installation state is invalid.
+
+## First Priority Migration
+
+Move these workloads first:
+
+1. NovaArchive OCR
+2. NovaArchive embeddings
+3. NovaArchive vectorization
+4. NovaArchive chunking
+5. NovaArchive semantic indexing
+6. ChromaDB remote persistence
+7. PostgreSQL remote persistence
+8. Redis remote persistence
+9. queue workers
+10. replay engines
+
+These workloads are metabolic load, not control-surface activity.
+
+## Forbidden Topologies
+
+NovaForge must not become:
+
+- a remote desktop replacement
+- generic hosting
+- silent local heavy fallback
+
+If AX102 is unavailable, the system must surface the causal failure or route to
+another explicit remote proof surface. It must not silently pull heavy execution
+back to the Mac Mini.
+
+## Docking Boundary
+
+This document governs the broader AX102 stack that downstream systems can dock
+into. Axiom Core may validate the topology, but it is not itself a long-running
+service.