Master: World Compute — complete functional implementation

## Overview

This master issue tracks ALL remaining work needed to achieve a fully functional implementation of World Compute as described in the whitepaper and specifications. It was generated from a comprehensive codebase audit on 2026-04-16 that identified every TODO, stub, placeholder, missing test, and unimplemented feature.

### Current State

- **94 source files**, **489+ passing tests**, **20 library modules**
- All 5 CLI command groups functional
- Core infrastructure implemented: WASM sandbox, Ed25519 verification, certificate chain validation, identity verification, transparency logging, OTLP telemetry, NAT detection, Raft consensus, Firecracker/Apple VF drivers
- **Specs 001 (core), 002 (safety hardening), 003 (stub replacement)** complete

### What Remains

The gap between "stubs replaced" and "functional distributed system" is substantial. This issue organizes remaining work into 28 sub-issues across 7 categories.

---

## Category 1: Core Infrastructure Depth (code TODOs)

These address TODO comments found in the source code — structural implementations exist but cryptographic/runtime depth is missing.

- [ ] #28 — Deep attestation: full cryptographic chain verification (TPM2/SEV-SNP/TDX)
- [ ] #29 — Rekor: full Merkle inclusion proof verification
- [ ] #30 — Agent lifecycle: heartbeat, pause/checkpoint, and withdrawal
- [ ] #31 — Policy engine: LLM advisory, artifact registry lookup, egress allowlist
- [ ] #32 — Sandbox: GPU passthrough verification and IOMMU isolation
- [ ] #33 — Firecracker: rootfs preparation from CID store OCI images
- [ ] #34 — Incident containment: real enforcement effects
- [ ] #45 — Preemption supervisor: real-time sovereignty enforcement

## Category 2: Security and Adversarial Testing

- [ ] #35 — Adversarial tests: implement all 8 ignored test scenarios
- [ ] #46 — Confidential compute: client-side encryption and attested key release
- [ ] #47 — mTLS certificate management and rate limiting
- [ ] #53 — Reproducible builds, code signing, and supply chain security

## Category 3: Test Coverage

- [ ] #36 — Integration test coverage: 12 untested src/ modules
- [ ] #51 — Churn simulator: validate 80% completion at 30% churn over 72h

## Category 4: Platform Adapters

- [ ] #37 — Slurm adapter: real HPC cluster integration
- [ ] #38 — Kubernetes adapter: CRD operator with real cluster integration
- [ ] #39 — Cloud adapter: AWS/GCP/Azure instance-metadata attestation
- [ ] #52 — Apple Virtualization.framework: real Swift helper binary

## Category 5: Runtime Systems

- [ ] #44 — Credit system: 45-day decay, DRF accounting, and caliber redemption
- [ ] #49 — Storage GC, acceptable-use enforcement, and data residency
- [ ] #55 — Scheduler: real broker matchmaking, lease management, and job lifecycle
- [ ] #56 — Ledger: threshold signing, CRDT merge, and coordinator quorum

## Category 6: User-Facing Features

- [ ] #40 — Tauri GUI: functional desktop application
- [ ] #43 — REST/HTTP gateway and web dashboard

## Category 7: Operations and Documentation

- [ ] #41 — Deployment infrastructure: Docker, Helm, and release pipeline
- [ ] #48 — Energy metering and carbon footprint reporting
- [ ] #50 — Documentation: README, evidence artifacts, incident disclosure, quickstart

## Category 8: Distributed Mesh LLM (Major Feature — from #27)

- [ ] #54 — Distributed mesh LLM: ensemble-of-experts inference engine

This is the largest single feature. It encompasses the distributed router, expert node management, sparse logit aggregation, self-prompting agent loop, action tier safety system, and governance kill switch. It has a phased rollout (Phase 0-1: centralized model → Phase 4: full distributed autonomy) and requires ~280+ GPU nodes for minimum viable distributed operation.

## Category 9: Validation Milestones

- [ ] #42 — End-to-end multi-node cluster: Phase 1 LAN testnet

---

## Recommended Execution Order

### Phase A: Infrastructure Depth (spec 004)
Issues: #28, #29, #30, #31, #32, #33, #34, #45, #55, #56
**Why first**: These address real TODOs in production code. Without these, the system accepts attestations without full verification, can't enforce containment, and can't run real multi-node scheduling.

### Phase B: Security Hardening (spec 005)
Issues: #35, #46, #47, #53
**Why second**: Principle I (Safety First) requires these before any external deployment. Adversarial tests validate that sandbox boundaries hold.

### Phase C: Test Coverage + Validation (spec 006)
Issues: #36, #51, #42
**Why third**: Principle V (Direct Testing) requires real-hardware validation before any release phase gate.

### Phase D: Runtime Systems (spec 007)
Issues: #44, #49
**Why here**: Credit decay and storage GC are needed for sustained operation but not for initial testing.

### Phase E: Platform Adapters (spec 008)
Issues: #37, #38, #39, #52
**Why here**: Adapters extend reach but aren't required for core functionality.

### Phase F: User-Facing Features (spec 009)
Issues: #40, #43, #48, #50, #41
**Why here**: GUI, web dashboard, documentation, and deployment infrastructure for public-facing operation.

### Phase G: Mesh LLM (spec 010)
Issue: #54
**Why last**: Requires a functioning cluster with 280+ GPU nodes. Phase 0-1 (centralized model) can start earlier but distributed operation requires the full stack.

---

## Existing Issues Addressed by This Plan

Issues #7-#26 (spec 003 stub replacement) will be closed when spec 003 PR merges. Issue #5 (proof-of-personhood providers) is covered by the identity verification already in place. Issue #27 (distributed LLM) is superseded by #54.

## Metrics

- **Current**: 489+ tests, 94 source files, 15 in-code TODOs, 8 ignored adversarial tests
- **Target**: 700+ tests, 12 untested modules → 0, 0 TODOs, 0 ignored tests, all validation milestones passing