# Disasmer MVP Acceptance Criteria Every criterion below must be covered by automated verification; when behavior crosses coordinator, node, CLI, DAP, browser, storage, or network boundaries, that verification should include integration coverage. The final product should be exercised as much as possible as if it were live infrastructure: separate services, real process boundaries, real auth boundaries, real quota decisions, realistic networking, realistic retention/GC, and realistic failure behavior. Because the main environment is NixOS, the live-infra shape can be credibly simulated with NixOS-based service and VM setups. Windows-specific runtime behavior does not need to be validated by the main acceptance suite for the MVP. The Windows implementation should still be best-effort correct, kept behind clean interfaces, avoid false sandboxing claims, and be structured so it can be validated and fixed independently later. These criteria intentionally avoid implementation detail. Architecture, protocol, and milestone details live in the MVP and feasibility documents. Important reading note: an item marked **Partial** or **Open** does not automatically mean new product code, a new feature, or even actual implementation work is required. It means the item must become a proven fact about the system. Many items describe facts that may already be true, or should have been fundamental invariants from the start, but still need stronger evidence at the required boundary. Before adding implementation, first check whether the fact is already true in the current system and prefer proving, documenting, or tightening that existing behavior over duplicating capability or overengineering a parallel mechanism. **Status Prefixes** - **Passed:** implemented with focused automated/source-scan coverage or a narrow source-level guard in the current tree; this is not final MVP acceptance until the full release gates run. - **Partial:** modeled or covered at unit/smoke/source-scan level, but missing live boundary coverage, packaging coverage, hosted coverage, or end-to-end acceptance. - **Open:** not implemented, not yet wired through the required boundary, or not yet covered by an appropriate acceptance gate. For release-blocker lists, **Passed** means the listed blocker condition is currently guarded as absent; **Open** means absence has not been proven by the release gate yet. --- ## 1. Public product bar - [x] **Passed:** A user can run Disasmer locally with the open-source runtime, coordinator, node runtime, SDK, CLI, and VS Code extension. - [x] **Passed:** A user can use the hosted coordinator as a control plane without receiving arbitrary hosted compute. - [x] **Passed:** A user can attach their own node and run actual build work on that node. - [x] **Passed:** The flagship build workflow is expressed as Rust source code, not CI YAML. - [x] **Passed:** Public-facing docs and repo text avoid naming any external launch forum or traffic source as a product goal. - [x] **Passed:** User-facing docs, UI, CLI, and plan language use `community tier` consistently. - [x] **Passed:** The public story remains: one virtual process, many virtual threads/tasks, ordinary source-level debugging, and local-first distributed execution. --- ## 2. Repository and release split - [x] **Passed:** Public source can be produced by excluding `private/**` without breaking the open-source runtime, local coordinator, node runtime, CLI, SDK, or VS Code extension. - [x] **Passed:** Hosted-only Authentik/OIDC, community quota enforcement, hosted zero-capability limits, abuse tooling, and admin controls live in `private/**` or equivalent filterable modules. - [x] **Passed:** Public crates expose clear policy/auth interfaces that private hosted modules implement. - [x] **Passed:** The open-source coordinator remains useful for local clouds, trusted team use, and VPN deployments without hosted-service-only modules. - [x] **Passed:** Hosted and self-hosted nodes use the same node runtime code path; hosted restrictions are policy modules, not a separate node implementation. --- ## 3. Coordinator state model - [x] **Passed:** Postgres is used only for data that must survive coordinator restart. - [x] **Passed:** Tenants, users, projects, node identities, credentials, source-provider configuration, and durable service policy records persist across coordinator restarts. - [x] **Passed:** Active virtual processes, live virtual threads, live scheduler state, debug epochs, ephemeral VFS manifests, and transient artifact locations may live in RAM for MVP. - [x] **Passed:** Coordinator restart requires active virtual processes to restart rather than pretending live execution survived. - [x] **Passed:** Nodes reconnect cleanly after coordinator restart and cannot continue an old virtual process under stale coordinator state. - [x] **Passed:** Persistent project state remains intact after coordinator restart. --- ## 4. Auth and identities - [x] **Passed:** Browser login works through the hosted identity flow. - [x] **Passed:** CLI login works for human users without manually copying long-lived secrets. - [x] **Passed:** Agent/worker authentication supports public-key identity without requiring browser interaction on every run. - [x] **Passed:** Node enrollment converts a short-lived enrollment grant into a scoped long-lived node identity. - [x] **Passed:** User OAuth/session tokens are never passed to nodes as task credentials. - [x] **Passed:** Node identity, user identity, project identity, and task identity are distinct in coordinator authorization decisions. --- ## 5. CLI behavior - [x] **Passed:** `disasmer run` defaults to the current project directory. - [x] **Passed:** `disasmer run --project ` runs a project other than the current directory. - [x] **Passed:** `disasmer run` uses the hosted coordinator implicitly when the user is logged in and no local override is selected. - [x] **Passed:** `disasmer run [entry]` selects a named entrypoint while preserving a sensible default when omitted. - [x] **Passed:** One project can define multiple entrypoints such as build, test, package, release, watch, or custom workflows. - [x] **Passed:** `disasmer node attach` auto-detects OS, architecture, environment backends, source providers, and ordinary node capabilities. - [x] **Passed:** `disasmer node attach --cap ...` remains available for explicit overrides and advanced cases. - [x] **Passed:** CLI commands are usable non-interactively by agents once their public-key identity is enrolled. --- ## 6. Project and bundle model - [x] **Passed:** A project works without requiring a hand-written configuration file for the common case. - [x] **Passed:** `envs//Containerfile` or `envs//Dockerfile` defines an environment named ``. - [x] **Passed:** Source code can reference discovered environments with `env!("name")`. - [x] **Passed:** Missing environment references produce clear build/editor diagnostics. - [x] **Passed:** Bundle identity changes when Wasm code, task ABI, environment recipe, source-provider manifest, or selected inputs change. - [x] **Passed:** Bundles do not embed full container images by default. - [x] **Passed:** Generated environment and bundle metadata are inspectable by the user. --- ## 7. Source-provider modularity - [x] **Passed:** Git support is an optional source-provider module included by default. - [x] **Passed:** The VFS core does not require Git as a hard dependency. - [x] **Passed:** Users can add non-Git source providers without rewriting the VFS core. - [x] **Passed:** Source snapshot creation can run as a node task instead of requiring coordinator filesystem or Git access. - [x] **Passed:** Coordinator-run code remains zero-capability and does not directly inspect the user checkout. - [x] **Passed:** A task can wait for any capable node to pick up source-preparation work rather than failing immediately when the coordinator lacks source access. --- ## 8. Wasmtime and task execution - [x] **Passed:** Disasmer programs compile to Wasm and run under Wasmtime on node runtimes. - [x] **Passed:** `#[disasmer::main]` defines a virtual-process entrypoint. - [x] **Passed:** `#[disasmer::task]` defines named, remotely startable task entrypoints. - [x] **Passed:** `spawn::task(...).start().await` creates a debugger-visible virtual thread/task. - [x] **Passed:** `TaskHandle::join().await` returns small serialized results or runtime handles. - [x] **Passed:** Task arguments reject host-only values such as raw pointers, references, local files, sockets, and process handles. - [x] **Passed:** Large data crosses task boundaries through handles such as `SourceSnapshot`, `Blob`, `Artifact`, or VFS references. - [x] **Passed:** Small data can move into and out of tasks without awkward user ceremony. --- ## 9. Native command execution - [x] **Passed:** Native commands are invoked from Wasm tasks through node host capabilities. - [x] **Passed:** A virtual process remains Wasmtime-backed even when a task calls into the node to run shell/native commands. - [x] **Passed:** Hosted coordinator control-plane code cannot run native commands or containers. - [x] **Passed:** Open-source/private deployments can allow normal local-node command capabilities by default. - [x] **Passed:** Command stdout and stderr are associated with the virtual thread that started the command. - [x] **Passed:** Native command execution is denied when the selected node or task lacks the required capability. --- ## 10. Linux execution backend - [x] **Passed:** Linux nodes can materialize Containerfile-based environments with rootless Podman. - [x] **Passed:** Linux nodes can run command tasks inside the selected environment. - [x] **Passed:** Linux command outputs can be staged into the VFS artifact namespace. - [x] **Passed:** Local Linux source checkouts stay local when the local node can run the task. - [x] **Passed:** Linux command tasks participate in virtual process lifecycle, cancellation, logging, and debug freeze/resume behavior. --- ## 11. Windows execution backend - [x] **Passed:** Windows node support is represented by the same node protocol and capability model as Linux. - [x] **Passed:** Windows command execution is clearly labeled as user-attached development execution, not production-grade untrusted sandboxing. - [x] **Passed:** Windows sandboxing exists behind an explicit backend interface or stub. - [x] **Passed:** Windows-specific code does not infect the Linux backend or generic node runtime model. - [x] **Passed:** Windows tasks can publish artifacts through the same VFS/artifact APIs once the backend is enabled. --- ## 12. Scheduler and placement - [x] **Passed:** Scheduler placement is based on logical environment requirements, not hard-coded runner names. - [x] **Passed:** Scheduler prefers nodes with the source snapshot, environment cache, dependency cache, and required artifacts already local. - [x] **Passed:** Scheduler avoids network transfer when a compatible local/warm node exists. - [x] **Passed:** Scheduler can place a task on any capable node when the program asks for capability rather than a specific node. - [x] **Passed:** Scheduler failure messages explain which capability, environment, source, or connectivity constraint could not be satisfied. - [x] **Passed:** The scheduler is a replaceable module with a simple default implementation. --- ## 13. QUIC transport and networking - [x] **Passed:** QUIC transport is behind a transport abstraction. - [x] **Passed:** The MVP default uses a Rust-native QUIC implementation. - [x] **Passed:** Node-to-node bulk transfer uses authenticated direct connections when possible. - [x] **Passed:** The coordinator can aid rendezvous but does not silently relay bulk artifact/source/blob data. - [x] **Passed:** Failed direct connectivity results in a clear placement/export/sync error. - [x] **Passed:** Each data-plane transfer is scoped to tenant, project, process, object, and authorization context. --- ## 14. VFS and local-first behavior - [x] **Passed:** `flush()` publishes metadata and visibility information without uploading large bytes by default. - [x] **Passed:** `sync()` is explicit and may move bytes according to user code or configured policy. - [x] **Passed:** A local build from an existing checkout does not create a full-repo tarball by default. - [x] **Passed:** Coordinator-routed compiler file reads are not part of the normal local-first path. - [x] **Passed:** Source bytes, build-cache bytes, and artifact bytes remain node-local unless a consumer/export/sync/download path requires movement. - [x] **Passed:** VFS overlays provide task-local writes and published manifest epochs. - [x] **Passed:** Parent/downstream tasks can consume artifacts after the producing task flushes them. - [x] **Passed:** Same-node artifact reuse avoids unnecessary copying where the platform supports it. --- ## 15. Artifact lifecycle and downloads - [x] **Passed:** Artifacts and other large blobs are best-effort retained on nodes by default, not durable coordinator objects. - [x] **Passed:** Artifact metadata can exist after `flush()` even when artifact bytes are only present on a retaining node. - [x] **Passed:** Artifact bytes may be garbage collected according to node retention policy unless explicitly exported or stored by user code. - [x] **Passed:** Loss of a node-local unsynced artifact is surfaced as artifact unavailability, not silent recovery. - [x] **Passed:** The operator/control panel can expose a download button for a best-effort retained artifact. - [x] **Passed:** Artifact download streams from a retaining node or explicit user-provided storage path, not from default durable coordinator artifact storage. - [x] **Passed:** A download action is not created when the artifact cannot be downloaded within current retention, location, size, authorization, or community tier limits. - [x] **Passed:** A failed download-link creation returns a clear error before showing a user-facing link. - [x] **Passed:** Artifact download links are authenticated, authorized, scoped, and not usable merely by guessing a URL. - [x] **Passed:** Cross-tenant and cross-project artifact downloads are denied even if an artifact ID or link-like value is known. - [x] **Passed:** Download usage is accounted against the relevant limits before and during streaming. --- ## 16. Checkpoint and restart semantics - [x] **Passed:** Task restart is based on task entrypoint, serialized args, environment handle, and VFS/artifact checkpoint boundaries. - [x] **Passed:** The MVP does not claim live stack migration, live socket checkpointing, or arbitrary hot code replacement. - [x] **Passed:** Restarting a failed or selected task after source edit works when task compatibility checks pass. - [x] **Passed:** Compatibility failure requires a whole virtual-process restart with a clear message. - [x] **Passed:** Unflushed task-local filesystem changes are discarded or explicitly preserved according to documented policy. - [x] **Passed:** Best-effort retained artifacts can help restart, but restart never depends on pretending ephemeral artifacts are durable. --- ## 17. Debugging and DAP - [x] **Passed:** VS Code F5 can launch a Disasmer virtual process. - [x] **Passed:** The debugger presents one process with multiple virtual threads/tasks. - [x] **Passed:** Breakpoints in `main` and spawned task code stop the virtual process. - [x] **Passed:** A breakpoint in one virtual thread creates a Debug Epoch for the whole virtual process. - [x] **Passed:** Wasm tasks and controlled native-command tasks participate in all-stop debug behavior. - [x] **Passed:** If a node cannot freeze a controlled task, the debugger reports failure instead of claiming all-stop succeeded. - [x] **Passed:** The debugger shows coherent thread names, stack frames, task args, handles, command status, and recent output. - [x] **Passed:** Continue resumes every frozen participant in the Debug Epoch. - [x] **Passed:** Pause requests stop the whole virtual process, not just the currently selected thread. - [x] **Passed:** Restart selected/failed task is available from the debugging workflow. - [x] **Passed:** The DAP adapter targets VS Code first while remaining ordinary enough for other DAP clients to integrate later. --- ## 18. VS Code extension - [x] **Passed:** The extension discovers environment resources and provides useful diagnostics for `env!(...)` references. - [x] **Passed:** The extension builds or refreshes the Disasmer bundle before launch/debug when needed. - [x] **Passed:** Normal VS Code thread, breakpoint, variables, stack, output, continue, pause, and restart flows work for the flagship demo. - [x] **Passed:** Disasmer-specific views show nodes, virtual processes, logs, artifacts, and inspector state without replacing the normal debugger UX. - [x] **Passed:** Error messages guide the user toward missing nodes, missing environments, quota limits, unavailable artifacts, or failed debug freezes. --- ## 19. Operator/control panel - [x] **Passed:** The MVP includes protocol and state foundations for immediate-mode operator panels. - [x] **Passed:** Program-defined panels use built-in typed widgets only. - [x] **Passed:** User-provided panel content cannot inject custom HTML or JavaScript. - [x] **Passed:** Panel state is scoped to tenant, project, and virtual process. - [x] **Passed:** Panel events are typed, rate-limited, and delivered back to the virtual process only when allowed. - [x] **Passed:** A stopped debug process shows the last rendered panel state without executing program UI logic. - [x] **Passed:** Control-plane actions such as restart, cancel, debug, and artifact download can remain available while program UI events are disabled. --- ## 20. Hosted/community service policy - [x] **Passed:** Community hosted mode can create or use a project, attach user nodes, run tasks on those nodes, debug, and view logs/artifact metadata. - [x] **Passed:** Community hosted mode does not provide arbitrary hosted native commands or hosted containers. - [x] **Passed:** Hosted zero-capability Wasm has strict fuel, memory, wall-clock, state, log, and event limits. - [x] **Passed:** Hosted community policies are enforced before work starts, not only after resource usage is observed. - [x] **Passed:** Quota failures are explicit and actionable. - [x] **Passed:** Public hosted endpoints treat users, nodes, programs, logs, artifacts, UI events, source manifests, and capabilities as hostile input. --- ## 21. Authorization and tenant isolation - [x] **Passed:** Every user-owned or project-owned object has tenant ownership. - [x] **Passed:** Users cannot list, inspect, debug, download, or mutate another tenant's nodes, processes, logs, artifacts, projects, or panel state. - [x] **Passed:** Nodes cannot claim tasks or publish artifacts outside their authorized tenant/project/process scope. - [x] **Passed:** Debug attach requires explicit project permission. - [x] **Passed:** Debug memory/variable/handle reads are authorized and scoped. - [x] **Passed:** Artifact provenance includes producer task, process, project, and node identity. - [x] **Passed:** Tenant isolation failures are treated as release blockers. --- ## 22. Abuse and resource limits - [x] **Passed:** API calls, spawns, logs, metadata, debug reads, UI events, rendezvous attempts, and artifact downloads are subject to resource policy. - [x] **Passed:** Log output is capped, backpressured, and associated with the producing virtual thread. - [x] **Passed:** Large task arguments are rejected or warned before causing accidental distributed copies. - [x] **Passed:** Community hosted tasks cannot use network, secrets, host filesystem, native commands, containers, inbound ports, or arbitrary syscalls. - [x] **Passed:** Operator panels cannot collect passwords or initiate OAuth-like flows inside user-defined widgets. - [x] **Passed:** Admin controls can suspend abusive tenants, revoke node credentials, and stop active hosted processes. --- ## 23. Documentation and examples - [x] **Passed:** The README shows the build-system workflow with Rust source, environments, attached nodes, debugging, and artifacts. - [x] **Passed:** Docs explain `flush()` versus `sync()` without implying default durability. - [x] **Passed:** Docs explain that artifacts are best-effort retained unless explicitly exported or stored. - [x] **Passed:** Docs explain node trust, user-attached execution, and Windows sandbox limitations honestly. - [x] **Passed:** Docs explain hosted/community limits without framing them as a compute giveaway. - [x] **Passed:** Docs explain how agents authenticate with public keys. - [x] **Passed:** Docs explain how to add non-Git source-provider support. - [x] **Passed:** Example code avoids coordinator-side filesystem, Git, shell, or container assumptions. --- ## 24. Flagship demo acceptance - [x] **Passed:** A clean developer setup can install the CLI and VS Code extension. - [x] **Passed:** The user can sign in, create or select a project, and attach at least one Linux node. - [x] **Passed:** The demo project recognizes `env!("linux")` and, when available, `env!("windows")`. - [x] **Passed:** Pressing F5 starts one virtual process through the Disasmer debugger. - [x] **Passed:** The Linux build task runs as a node-hosted command from a Wasmtime-backed virtual task. - [x] **Passed:** A second task can run concurrently as another virtual thread when a capable node is available. - [x] **Passed:** A breakpoint in a spawned task all-stops the virtual process. - [x] **Passed:** Task args, command status, logs, and artifact handles are inspectable. - [x] **Passed:** A failed task can be restarted after a source edit when compatibility permits. - [x] **Passed:** Final artifacts can be exported, downloaded from retained nodes, or otherwise handled explicitly by user code. - [x] **Passed:** The coordinator does not route bulk source or artifact bytes by default during the demo. --- ## 25. Non-goals preserved - [x] **Passed:** The MVP does not imply transparent raw remote pointers. - [x] **Passed:** The MVP does not imply global consensus on every memory access. - [x] **Passed:** The MVP does not imply live native process migration. - [x] **Passed:** The MVP does not imply durable artifacts without explicit export/storage policy. - [x] **Passed:** The MVP does not imply public hosted compute for arbitrary workloads. - [x] **Passed:** The MVP does not imply secure managed Windows compute. - [x] **Passed:** The MVP does not require users to understand distributed internals for the normal debug/build path.