Consolidate Reploid journeys and remove dead code

README.md

@@ -4,15 +4,18 @@
 [![License metadata: MIT](https://img.shields.io/badge/license%20metadata-MIT-blue.svg)](package.json)
 
 Reploid is a browser runtime family for receipt-backed, self-modifying agents.
-Everything runs client-side; agent behavior stays in visible self files, prompts,
-blueprints, traces, and receipts, never on a server.
+Model execution and agent behavior stay in browser-visible self files, prompts,
+blueprints, traces, and receipts. Optional server services provide authentication,
+configuration, metadata relay, and hosted compatibility paths; the Poolday relay
+rejects inference payloads.
 
 It ships as **three distinct surfaces** — Poolday, Zero, and X — each with its own
 route, boot profile, and tool set. They are separate products with separate
 authority: a capability supported on one surface is **not** implied on another.
 Every support claim is machine-checked in the
 [surface claim index](docs/status/surface-claim-index.json); read each row by its
-declared boundary and status.
+declared boundary and status. Current user outcomes and remaining work are owned
+by the three registries in [Critical User Journeys](docs/critical-user-journeys.md).
 
 ## Surfaces
 
@@ -51,7 +54,11 @@ Open `http://localhost:8000`. For the managed Gemini path, set `GEMINI_API_KEY`
 
 ## Self contract
 
-Awaken clears prior live VFS state, writes the generated self manifests, exposes canonical source through a copy-on-write `/self` overlay, mounts Capsule, and starts the runtime.
+Zero and X hydrate route-specific manifests into an instance-scoped VFS, expose
+canonical source through a copy-on-write `/self` overlay, mount their respective
+runtime UI, and start the agent loop. Writable Shadow and artifact state can
+survive reload; live changes require Zero's explicit activated capabilities or
+X's promotion path.
 
 The generated [VFS manifest](self/config/vfs-manifest.json) enumerates seeded files. The executable [tool-surface contract](self/config/tool-surfaces.js) enumerates tool membership. The [RGR runtime contract](self/blueprints/rgr-runtime-contract.md) defines candidate evidence, anchors, quarantine, rollback, and promotion.
 
@@ -76,7 +83,8 @@ Users can bypass the managed access-window path and supply their own browser inf
 | --- | --- |
 | Operators | [Quick start](docs/QUICK-START.md), [configuration](docs/CONFIGURATION.md), and [local models](docs/local-models.md) |
 | Agent and runtime contributors | [System architecture](docs/system-architecture.md), [RGR runtime contract](self/blueprints/rgr-runtime-contract.md), and [tool surfaces](self/config/tool-surfaces.js) |
-| Security and claim reviewers | [Security model](docs/SECURITY.md), [surface claim index](docs/status/surface-claim-index.json), [Poolday claims](docs/poolday/claims-and-nonclaims.md), and [threat model](docs/poolday/threat-model.md) |
+| Product and release reviewers | [Critical user journeys](docs/critical-user-journeys.md), the three [machine-readable journey registries](docs/status/surface-claim-index.json), and the [surface claim index](docs/status/surface-claim-index.json) |
+| Security and claim reviewers | [Security model](docs/SECURITY.md), [Poolday claims](docs/poolday/claims-and-nonclaims.md), and [threat model](docs/poolday/threat-model.md) |
 | Inference integrators | [Browser inference pool](docs/browser-inference-pool.md), [receipt schema](docs/poolday/receipt-schema.md), and [Doppler](https://github.com/clocksmith/doppler) |
 
 The [documentation index](docs/INDEX.md) owns the complete architecture, blueprint, API, and operator inventory.

docs/API.md

@@ -123,8 +123,6 @@ Treat experimental paths as implementation details until they move into the main
 | Module | Path | Purpose |
 |--------|------|---------|
 | Proto UI | `self/ui/proto/index.js` | Main operator UI |
-| UIManager | `self/ui/dashboard/ui-manager.js` | Dashboard orchestration |
-| VFSExplorer | `self/ui/dashboard/vfs-explorer.js` | File tree UI |
 
 ---
 
@@ -182,7 +180,7 @@ Important runtime storage paths:
 - `NeuralCompiler` currently lives under `self/experimental/intelligence/`, not `self/capabilities/intelligence/`.
 - There is no standalone runtime module at `self/infrastructure/introspector.js`.
 - There is no standalone runtime module at `self/core/sentinel-fsm.js`; the current reference is the blueprint `self/blueprints/0x000050-sentinel-fsm.md`.
-- Older docs may refer to `ui/diff-generator.js`; the current UI surface is centered on `self/ui/proto/` and `self/ui/dashboard/`.
+- Older docs may refer to `ui/diff-generator.js`; the current operator UI lives under `self/ui/proto/`.
 
 ---
 

docs/INDEX.md

@@ -33,6 +33,13 @@ Guide to all documentation in the REPLOID project.
 ### Reference
 - **[docs/API.md](./API.md)** - Module API documentation
 - **[docs/status/surface-claim-index.json](./status/surface-claim-index.json)** - Machine-checked surface status, evidence, blockers, and claim permission
+- **[docs/critical-user-journeys.md](./critical-user-journeys.md)** - Canonical index for Poolday, Zero, and X user outcomes
+- **[docs/status/poolday-critical-user-journeys.json](./status/poolday-critical-user-journeys.json)** - Canonical Poolday user outcomes, prerequisites, evidence, limitations, and remaining work
+- **[docs/poolday/critical-user-journeys.md](./poolday/critical-user-journeys.md)** - Human-readable Poolday journey status
+- **[docs/status/zero-critical-user-journeys.json](./status/zero-critical-user-journeys.json)** - Canonical Zero user outcomes, evidence, limitations, and remaining work
+- **[docs/zero/critical-user-journeys.md](./zero/critical-user-journeys.md)** - Human-readable Zero journey status
+- **[docs/status/x-critical-user-journeys.json](./status/x-critical-user-journeys.json)** - Canonical X user outcomes, evidence, limitations, and remaining work
+- **[docs/x/critical-user-journeys.md](./x/critical-user-journeys.md)** - Human-readable X journey status
 - **[docs/browser-inference-pool.md](./browser-inference-pool.md)** - Poolday docs/internal contract for the public Reploid browser inference surface
 - **[docs/poolday/claims-and-nonclaims.md](./poolday/claims-and-nonclaims.md)** - Poolday claim boundary
 - **[docs/poolday/threat-model.md](./poolday/threat-model.md)** - Poolday adversaries, trust boundaries, and evidence
@@ -46,6 +53,7 @@ Guide to all documentation in the REPLOID project.
 - **[docs/multi-model-evaluation.md](./multi-model-evaluation.md)** - Multi-model evaluation harness
 - **[docs/intent-bundle-lora.md](./intent-bundle-lora.md)** - Intent bundle LoRA workflow
 - **[docs/trained-adapter-promotion.md](./trained-adapter-promotion.md)** - Tinker adapter evidence, Shadow staging, and human-only promotion
+- **[docs/archive/reploid-descriptor-peer-orchestration.md](./archive/reploid-descriptor-peer-orchestration.md)** - Archived layer-pipelining research; not the current Poolday execution contract
 - **[docs/CONFIGURATION.md](./CONFIGURATION.md)** - Boot UI settings and localStorage keys
 - **[docs/local-models.md](./local-models.md)** - WebLLM and Ollama setup
 - **[docs/style-guide.md](./style-guide.md)** - Code and UI conventions

docs/TESTING.md

@@ -49,12 +49,12 @@
 
 Isolated tests for individual modules with mocked dependencies.
 
-**34 test files covering:**
+Representative test areas include:
 - Infrastructure: `di-container.test.js`, `event-bus.test.js`, `context-manager.test.js`
 - Core modules: `state-manager.test.js`, `utils.test.js`, `utils-core.test.js`, `vfs-module-loader.test.js`
 - Tools: `tools/read-file.test.js`, `tools/write-file.test.js`, `tools/edit-file.test.js`, `tools/list-files.test.js`, `tools/grep.test.js`, `tools/find.test.js`
 - Execution: `tool-runner.test.js`, `response-parser.test.js`, `schema-validator.test.js`
-- UI/UX: `confirmation-modal.test.js`, `toast.test.js`, `toast-notifications.test.js`
+- UI/UX: `toast.test.js`, `doppler-optimization-ui.test.js`, `design-system-css.test.js`
 - Capabilities: `audit-logger.test.js`, `rate-limiter.test.js`, `rule-engine.test.js`, `policy-engine.test.js`, `gepa-engines.test.js`, `episodic-memory.test.js`, `hybrid-retrieval.test.js`, `knowledge-tree.test.js`, `observability.test.js`, `verification-manager.test.js`
 - Browser: `browser-apis.test.js`, `core-hardening.test.js`
 - Networking: `webrtc-swarm.test.js`, `swarm-sync.test.js`
@@ -76,7 +76,7 @@ Multi-module workflow tests with realistic state management.
 - Memory & state: `prompt-memory.test.js`, `reflection-system.test.js`, `replay-engine.test.js`, `vfs.test.js`
 - Persistence: `long-session.test.js`, `genesis-snapshot.test.js`
 - Tool execution: `tool-runner.test.js`
-- Arena (safety): `arena-harness.test.js`, `doppler-arena.test.js`
+- Arena (safety): `arena-harness.test.js`
 - Networking: `webrtc-swarm.test.js`
 - Routing: `websocket-routing.test.js`
 

TODO_REPLOID.md → docs/archive/reploid-descriptor-peer-orchestration.md

@@ -1,7 +1,7 @@
-# TODO: Reploid Descriptor Peer Orchestration
+# Archived Reploid Descriptor Peer Orchestration Proposal
 
 > [!CAUTION]
-> **Archived research, not the active Reploid plan.** This layer-pipelining proposal predates the shipped whole-job peer-room product and is not a release checklist. The canonical product contract and remaining work live in [`self/pool/pool-config.json`](./self/pool/pool-config.json) and [`self/pool/TODO.md`](./self/pool/TODO.md). Nothing below authorizes public claims that Reploid currently distributes individual model layers.
+> **Archived research, not the active Reploid plan.** This layer-pipelining proposal predates the shipped whole-job peer-room product and is not a release checklist. The canonical product contract lives in [`../../self/pool/pool-config.json`](../../self/pool/pool-config.json), and current outcomes plus remaining work live in the [Poolday critical user journey registry](../status/poolday-critical-user-journeys.json). Nothing below authorizes public claims that Reploid currently distributes individual model layers.
 
 > [!IMPORTANT]
 > **Primary Directive:** Browser-Native Distributed Inference

docs/browser-inference-pool.md

@@ -15,11 +15,15 @@ Do not describe this as trustless compute, hardware-attested inference, or guara
 
 The target retrieval extension is documented in [Poolday Receipt-Backed Retrieval](./poolday/receipt-backed-retrieval.md). That document covers embeddings, vector indexes, query receipts, reranking receipts, and the competitive retrieval strategy. It is not a replacement for this current browser inference claim.
 
+Current product outcomes, prerequisites, limitations, evidence, and remaining
+work are tracked in [Poolday Critical User Journeys](./poolday/critical-user-journeys.md).
+Architecture sections below explain mechanisms; they do not own completion
+status.
+
 The biological-sequence extension is documented in [Poolday Biological
-Sequence Lane](./poolday/biological-sequence-lane.md). Its peer protocol and
-synthetic runtime tests exist, but no biological model is enabled in the
-Poolday catalog until immutable hosted artifacts and a matching Doppler release
-are qualified.
+Sequence Lane](./poolday/biological-sequence-lane.md). ESM-2 35M is enabled for
+explicitly public protein pooled embeddings. The sequence lane is not biological
+interpretation, medical advice, or a private-sequence service.
 
 Participation modes, device-root and passkey identity, adapter authority, route
 selection, and the model-shard boundary are specified in [Poolday Participation,

docs/critical-user-journeys.md

@@ -0,0 +1,27 @@
+# Reploid Critical User Journeys
+
+Reploid has three separate browser surfaces. Current product status is owned by
+one machine-readable journey registry per surface:
+
+| Surface | Route | Readable summary | Canonical registry |
+| --- | --- | --- | --- |
+| Poolday | `/`, `/ask`, `/compute`, `/records` | [Poolday journeys](./poolday/critical-user-journeys.md) | [`poolday-critical-user-journeys.json`](./status/poolday-critical-user-journeys.json) |
+| Zero | `/zero` | [Zero journeys](./zero/critical-user-journeys.md) | [`zero-critical-user-journeys.json`](./status/zero-critical-user-journeys.json) |
+| X | `/x` | [X journeys](./x/critical-user-journeys.md) | [`x-critical-user-journeys.json`](./status/x-critical-user-journeys.json) |
+
+The registries own journey status, prerequisites, executable implementation
+paths, tests, limitations, release-evidence requirements, and remaining work.
+Architecture documents and blueprints may explain mechanisms, but they do not
+advance completion status.
+
+Run `npm run verify:journeys` to validate all three registries. The validator
+fails on missing evidence paths, unlinked work, invalid status, uncovered
+routes, or a missing release gate. Poolday additionally verifies that every
+journey model is enabled and permitted by every policy named by that journey.
+
+`Supported` means an executable outcome with automated end-to-end contract
+coverage. It does not mean every model, device, network, or objective works.
+`Conditional` names those prerequisites. `Limited` names the narrower outcome
+that works while the complete user expectation remains unproved. Deployed
+claims also require a retained artifact; a passing test mentioned only in prose
+does not satisfy that requirement.

docs/multi-model-evaluation.md

@@ -7,7 +7,6 @@ Multi-model evaluation runs the same task suite across multiple model configs an
 ## Module
 
 **Path:** `core/multi-model-evaluator.js`
-**Capability shim:** `capabilities/intelligence/multi-model-evaluator.js`
 
 **Primary API:** `evaluate(tasks, modelConfigs, options)`
 

docs/poolday/critical-user-journeys.md

@@ -0,0 +1,43 @@
+# Poolday Critical User Journeys
+
+Poolday is the internal name for the public Reploid browser-inference surface at
+`/`. The canonical journey registry is
+[`../status/poolday-critical-user-journeys.json`](../status/poolday-critical-user-journeys.json).
+It owns current user outcomes, prerequisites, status, implementation evidence,
+tests, limitations, and remaining work.
+
+## Current journey status
+
+| Journey | Status | Honest outcome |
+| --- | --- | --- |
+| Request a text answer | Conditional | A compatible browser can answer one prompt and return a signed receipt. |
+| Recover with local inference | Conditional | After explicit consent, a qualified browser can load the model and retry the preserved request. |
+| Contribute browser compute | Conditional | A qualified tab can load one complete model, advertise, answer, sign, and stop. |
+| Verify receipt agreement | Supported | The requester can require and inspect deterministic signed-receipt agreement. |
+| Inspect records | Limited | Answers, contributions, room events, and scores persist in this browser and room. |
+| Run a public protein embedding | Conditional | ESM-2 can return a receipt-bound pooled embedding for an explicitly public sequence. |
+| Run a published adapter | Conditional | A promoted, compatible, fetchable adapter can be approved and bound into a receipt. |
+| Earn protocol reputation | Limited | Accepted work creates signed local points and reputation events. |
+| Receive paid compensation | Blocked | No monetary settlement system exists. |
+
+`Conditional` is not a euphemism for supported everywhere. The registry names the
+provider, device, artifact, network, registry, and privacy prerequisites for each
+journey. `Limited` identifies the narrower outcome that works today.
+
+## Updating status
+
+A journey change is complete only when the same registry entry contains:
+
+1. A user-visible outcome and its prerequisites.
+2. Executable implementation paths.
+3. Automated tests for success and relevant failure recovery.
+4. Honest limitations and claim boundaries.
+5. A release gate and, for deployed claims, a retained run artifact.
+
+The release artifact must bind its journey ids, commit, deployment URL, pool
+configuration identity, timestamps, browser, model, receipt, agreement, and final
+result. A passing command reported only in prose does not advance journey status.
+
+Remaining work belongs in the registry's `openWork` collection and must reference
+one or more journeys. Architecture documents may explain a design, but they do not
+own completion status.

docs/poolday/participation-identity-routing.md

@@ -72,9 +72,8 @@ a different route hash cannot enter agreement.
 
 Every provider still loads and runs the complete selected model. Model manifests
 and shards come from pinned artifact hosting and are cached locally by Doppler.
-The shard-negotiation module can verify that a provider has an exact manifest
-and shard set before dispatch, but the current live peer-room path does not
-relay base-model shards between browsers. Adapter chunks do have a verified
-peer-transfer path. Poolday does not claim tensor, layer, attention, or KV-cache
-sharding.
-
+The active runtime verifies the loaded manifest identity and artifact hashes
+before provider registration and assignment. The current live peer-room path
+does not relay base-model shards between browsers. Adapter chunks do have a
+verified peer-transfer path. Poolday does not claim tensor, layer, attention,
+or KV-cache sharding.