You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The gap between "stubs replaced" and "functional distributed system" is substantial. This issue organizes remaining work into 28 sub-issues across 7 categories.
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.
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.
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
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.
Category 2: Security and Adversarial Testing
Category 3: Test Coverage
Category 4: Platform Adapters
Category 5: Runtime Systems
Category 6: User-Facing Features
Category 7: Operations and Documentation
Category 8: Distributed Mesh LLM (Major Feature — from #27)
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
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