Disasmer release dry run f22d0a5791 Public dry run dryrun-309831e1e021

Source commit: 309831e1e021f962c118452336776fd9a94025f9

Public tree identity: sha256:6fa95c1745579bd6256dbeb3d476db0b07c2f24aa9213b0f7783ce1adfc8aca5

2026-07-03 16:07:13 +02:00

41 KiB

Raw Blame History

Disasmer MVP Release Acceptance Criteria

Status: phase 2 superset of acceptance_criteria.md Purpose: define the strict release gates for the MVP described by the current MVP plan and supporting design notes.

This document is intentionally stricter than a milestone checklist. The MVP is accepted only when the product behaves like live infrastructure from a clean checkout, not when the codebase merely contains the right traits, models, mocks, or experiment outputs.

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.

Verification contract

Partial: Every release-blocking criterion in this document is satisfied by automated acceptance checks or an equivalent reproducible release gate. Current source, local smoke, public split, and public-tree preparation gates pass, but the current Forgejo Release upload, live service smoke, public-operator compatibility smoke, and full public dry-run e2e verification still need to be rerun from the fresh released assets.
Passed: Release-blocking behavior is exercised across real service/process boundaries whenever the feature crosses a coordinator, node, DAP, CLI, browser, database, VFS, or network boundary.
Passed: The acceptance environment is treated as live infrastructure as much as possible; NixOS may be used to make Auth, Postgres, coordinator, nodes, browser-facing services, Podman, networking, and test projects reproducible.
Passed: A criterion cannot be accepted solely because a type, trait, schema, mock, or unit-level model exists.
Passed: The acceptance report records commit SHA, public/private mode, OS/kernel, Rust toolchain, Node.js version, Podman version, Postgres version when used, browser/VS Code harness version, and whether Windows validation was run.
Passed: Windows criteria are best-effort unless explicitly marked release-blocking by the current release target. Windows docs and UI must not imply validated production-grade sandboxing before that validation exists.
Passed: Existing acceptance_criteria.md remains required unless it conflicts with this stricter release document; this document wins in conflicts.

1. Public release split

Passed: Excluding private/** produces a public source tree that builds the SDK, CLI, coordinator, node runtime, DAP adapter, VS Code extension, protocol crates, and examples.
Passed: Public coordinator/local mode remains useful without private hosted modules.
Passed: Private hosted modules are isolated under private/** or equivalent publish-filterable paths.
Passed: Public code does not import private modules except through explicit feature-gated boundaries that are absent from public release builds.
Passed: Hosted deployment works when private modules are included.
Passed: OIDC/Auth hosted integration, community tier quota policy, zero-cap hosted enforcement, hosted admin controls, and service-specific policy modules are private-hosted features.
Passed: The node runtime is not forked between public and hosted modes.
Passed: Hosted restrictions are policy/module decisions, not a separate incompatible runtime.
Passed: Public/self-hosted coordinators do not silently apply hosted community tier restrictions to owner-controlled deployments.
Passed: experiments/** is excluded from release artifacts and is not imported by runtime, coordinator, node, DAP, CLI, SDK, extension, or hosted private code.
Passed: Release source scans reject known demo-only credentials, placeholder device codes, hard-coded artifact links, hidden local paths, and experiment-specific process names.

2. Public local MVP workflow

Passed: From a clean public checkout, a developer can build or install the CLI using documented commands.
Passed: From a clean public checkout, a developer can build or locally install the VS Code extension using documented commands.
Passed: A local coordinator and local node run as separate OS processes.
Passed: disasmer node attach enrolls the node through the real identity path.
Passed: disasmer node attach auto-detects OS, architecture, backend, source-provider, and environment capabilities.
Passed: disasmer node attach --cap ... remains available as an override, not as required normal configuration.
Passed: disasmer run defaults to the current project directory.
Passed: disasmer run --project <path> overrides the project directory.
Passed: disasmer run uses hosted mode implicitly when the CLI has a hosted login and no local coordinator override is selected.
Passed: disasmer run --local or equivalent forces local coordinator mode when both local and hosted contexts exist.
Passed: disasmer run [entry] can select an entrypoint from the same project.
Passed: Multiple project entrypoints can be listed and run without duplicating project configuration.
Passed: The flagship local workflow crosses the CLI, coordinator, and node boundary rather than running all work inside the CLI process.
Passed: The local node performs real build work and reports task state, logs, VFS metadata, and artifact metadata to the coordinator.
Passed: The local workflow remains usable after excluding private hosted modules.

3. Hosted/community control plane

Passed: A hosted coordinator starts with private hosted modules enabled and public runtime crates unchanged.
Passed: Browser login completes through OIDC against Authentik or a live-compatible test OIDC provider.
Passed: CLI browser login receives a scoped CLI session without exposing provider tokens to nodes.
Partial: Public released binaries default to a real human browser/account flow for disasmer login --browser: source and local binary smoke cover the browser path, account/login handoff, and local callback behavior, and raw JSON login-plan output is opt-in or diagnostic. This remains partial until the current Forgejo Release binaries are published and rerun through the hosted service flow.
Passed: Agent authentication works through public-key identity without requiring an interactive browser session.
Passed: Agent public keys can be registered, listed, rotated, and revoked.
Passed: A signed-in user can create or select a project through hosted API or UI.
Passed: A signed-in user can create a short-lived node enrollment token for a project.
Passed: A user-attached Linux node exchanges the enrollment token for a scoped long-lived node identity.
Passed: The hosted coordinator accepts the node's authenticated persistent session and heartbeat.
Passed: Hosted scheduling targets only authorized user-attached, team-shared, or managed nodes.
Passed: Community tier users can run real work on their own attached nodes.
Passed: Community tier users cannot run arbitrary hosted native commands, hosted containers, host filesystem access, secrets, inbound ports, outbound network, or arbitrary syscalls.
Passed: Hosted zero-capability Wasm is bounded by policy before start: fuel, memory, wall-clock, state, logs, metadata, UI events, and API calls.
Passed: Quota failures are returned before dispatch with a specific actionable reason.
Passed: Admin controls can suspend a tenant, revoke a node credential, and stop an active hosted process.
Passed: Hosted UI or API exposes node status, process status, logs, artifact metadata, and debug-session status.

4. Auth, identity, and tenant isolation

Passed: Browser sessions, CLI sessions, agent public-key identities, node identities, task identities, project identities, process identities, and artifact identities are represented distinctly.
Passed: User OAuth/browser/session tokens are never sent to nodes in task payloads, environments, logs, debug variables, panel events, or credential fields.
Passed: Node credentials are scoped to tenant, project or enrollment scope, node, and capability policy.
Passed: A node cannot claim a task for another tenant or project.
Passed: A node cannot publish logs, artifacts, VFS events, debug events, or panel events for an unauthorized process.
Passed: A user cannot list, inspect, debug, download, mutate, or infer another tenant's projects, nodes, processes, logs, artifacts, panels, source manifests, capabilities, or credentials.
Passed: Debug attach requires explicit project permission.
Passed: Debug memory, variables, handles, recent output, and artifact references are scoped to tenant, project, process, and authorized actor.
Passed: Artifact download authorization is checked at link creation and during streaming.
Passed: Negative tenant-isolation checks use the same public/private APIs used by normal clients.

5. Coordinator persistence and restart semantics

Passed: The coordinator has an abstract store boundary for durable product state.
Passed: Hosted deployment persists durable product state in Postgres or the configured production store.
Passed: Local development can use an in-memory store when durable projects are not required.
Passed: Durable state is limited to objects that must survive restart: users, tenants, projects, memberships, node identities, credentials, source-provider configuration, durable policy records, audit/security records, and private hosted configuration.
Passed: Active virtual processes, live virtual threads, debug epochs, node sessions, scheduler queues, in-flight task state, transient logs, VFS manifests, and artifact locations are ephemeral unless explicitly promoted to durable product/audit state.
Passed: Coordinator restart invalidates live virtual processes rather than pretending to recover them.
Passed: After coordinator restart, nodes reconnect with their persistent node identity.
Passed: After coordinator restart, nodes cannot continue stale virtual processes under the old coordinator epoch.
Passed: After coordinator restart, a user can re-run the process while retaining project, source-provider, and node identity state.
Passed: Migrations do not add durable tables for live process state without an explicit durability justification.

6. Node runtime and coordinator session

Passed: The node runtime opens a persistent authenticated session after enrollment.
Passed: The same session carries registration, heartbeat, capability updates, task assignments, debug commands, log events, VFS metadata, artifact metadata, and completion/failure events.
Passed: Session reconnect preserves node identity but not stale process ownership.
Passed: Coordinator-requested cancellation reaches the node and produces a terminal task state.
Passed: Debug freeze/resume reaches Wasm tasks through the node runtime.
Passed: Controlled native command tasks participate in freeze/resume when the backend supports it.
Passed: If a backend cannot freeze a controlled task, the node reports failure rather than pretending success.
Passed: Hosted and self-hosted nodes execute through the same node runtime code path.
Passed: Node capability claims are reported, authorized, and visible in coordinator/inspector state.

7. Wasmtime, SDK, task ABI, and spawn/join

Passed: A Disasmer program compiles to Wasm using the documented SDK and macros.
Passed: #[disasmer::main] registers at least one virtual-process entrypoint.
Passed: Multiple #[disasmer::main] or named entrypoints can coexist in one project and be selected by disasmer run [entry].
Passed: #[disasmer::task] registers named task entrypoints that the runtime can start remotely.
Passed: spawn::task(...).start().await creates a debugger-visible virtual thread through the runtime.
Passed: TaskHandle::join().await returns small serialized values or runtime handles across a task boundary.
Passed: Raw pointers, borrowed references, local file handles, sockets, native process handles, and unbounded byte buffers are rejected before dispatch.
Passed: Large task inputs and outputs cross boundaries through SourceSnapshot, Blob, Artifact, VirtualFile, or VFS handles.
Passed: The flagship workflow uses the public SDK and runtime APIs, not custom demo-only APIs.
Passed: Task compatibility hashes distinguish restartable implementation changes from schema/capability/ABI changes requiring process restart.

8. Native commands and Linux Podman backend

Passed: Native command execution is invoked from a Wasmtime-backed virtual task through node host capabilities.
Passed: Native commands are exposed as node host imports or equivalent runtime calls, not as coordinator-side shell execution.
Passed: Hosted coordinator control-plane code cannot run native commands or containers for community users.
Passed: Native command execution is denied when the selected node or task lacks the required capability.
Passed: Linux nodes materialize envs/<name>/Containerfile or envs/<name>/Dockerfile environments with rootless Podman.
Passed: Linux command tasks run inside the selected materialized environment.
Passed: Command stdout/stderr are associated with the virtual thread that started the command.
Passed: Command output can be staged into /vfs/artifacts.
Passed: Local Linux source checkouts remain local when the local node can run the task.
Passed: The coordinator does not create a full-repo tarball, serve compiler reads, or receive source bytes in the normal local Linux path.
Passed: Linux Podman behavior is marked incomplete if Podman is unavailable in the release gate environment.

9. Windows attached node best-effort track

Passed: Windows node support uses the same coordinator session, task protocol, capability model, VFS/artifact API, and debug model as Linux.
Passed: Windows command execution is labeled as user-attached development execution, not production-grade managed sandboxing.
Passed: Windows sandboxing remains behind an explicit backend interface until independently validated.
Passed: The scheduler can represent env!("windows") requirements and select a Windows-capable node when one is available.
Passed: Windows tasks publish logs and artifact metadata through the same protocol as Linux.
Passed: VS Code/coordinator views can represent Windows tasks as virtual threads in the same virtual process.
Passed: Windows-specific code does not leak into Linux backend code or generic node runtime abstractions.
Passed: If real Windows validation is not run, docs and UI state that Windows support is unvalidated for the release.
Passed: Real Windows validation is not enabled for this release unless the manual Forgejo Windows validation workflow succeeds on the intermittent windows runner; that workflow runs disasmer node attach, executes a simple windows-command-dev command, publishes artifact metadata, checks placement, and verifies the debugger shows the Windows virtual thread.

10. Source providers and local-first source behavior

Passed: Git support is an optional source-provider module included by default.
Passed: VFS core builds and runs without depending on Git internals.
Passed: A non-Git source provider can be implemented through the public source-provider interface without changing VFS core code.
Passed: Source preparation can run as node work when the coordinator lacks checkout or provider access.
Passed: Coordinator-hosted capless orchestration can await “any capable node” for source preparation instead of failing immediately.
Passed: The default build example does not require coordinator-side Git, filesystem, shell, or container capability.
Passed: Local source bytes remain local for local capable builds.
Passed: Remote source transfer moves only required content or explicit snapshot chunks, not a default full-repo tarball.
Passed: Locality regressions are release blockers when the coordinator receives source bytes on the default local path.

11. Scheduler and placement

Passed: Placement uses logical environment requirements, node capabilities, source locality, environment cache state, dependency cache state, artifact locality, connectivity, and quota/policy state.
Passed: A compatible local/warm node is preferred over remote transfer unless policy or capability requirements prevent it.
Passed: Work can be placed on any capable node when the program asks for a capability rather than a specific node.
Passed: Scheduler errors explain missing capability, missing environment, source unavailability, quota denial, artifact unavailability, or connectivity failure.
Passed: Scheduler behavior crosses at least two node identities in the release gate environment.
Passed: The scheduler remains replaceable through a public module boundary.
Passed: The default scheduler never silently falls back to coordinator bulk relay to make placement succeed.

12. QUIC, rendezvous, and bulk transfer

Passed: QUIC transport is behind a transport abstraction.
Passed: The default MVP data-plane implementation uses a Rust-native QUIC stack.
Passed: Public docs and examples do not require a non-Rust QUIC implementation for the MVP default path.
Passed: Two nodes can establish an authenticated direct node-to-node connection when network conditions allow.
Passed: Coordinator-aided rendezvous exchanges endpoint candidates without becoming a silent bulk relay.
Passed: A node can request an authorized artifact, source, blob, or VFS chunk from another node over the data plane.
Passed: Each data-plane stream is scoped to tenant, project, process where applicable, object id, and authorization context.
Passed: Failed direct connectivity produces a clear placement/export/sync/download error.
Passed: The coordinator does not receive bulk source, artifact, blob, or build-cache bytes by default.
Passed: Any explicit coordinator-proxied download path is visible, authorized, metered, and never treated as default artifact storage.

13. VFS, artifacts, retention, and downloads

Passed: flush() publishes metadata and visibility information without uploading large bytes by default.
Passed: sync() is explicit and moves bytes only according to user code or configured policy.
Passed: Task-local VFS writes remain isolated until flush().
Passed: Downstream tasks can consume flushed artifacts through handles.
Passed: Same-node artifact reuse avoids unnecessary copying where the platform supports it.
Passed: Artifact metadata includes tenant, project, process, producer task/thread, producer node, digest, size, retention/location, and flush epoch.
Passed: Artifact bytes are best-effort retained on nodes by default.
Passed: The coordinator has no default durable artifact store for large outputs.
Passed: Loss of an unsynced node-local artifact is surfaced as unavailable.
Passed: Artifact garbage collection is configurable and documented as best-effort retention, not durability.
Passed: Final artifact export works through an attached receiver node or explicit user-provided storage integration.
Passed: Control-panel artifact downloads stream from a retaining node or explicit user-provided storage path.
Passed: Download link creation fails before showing a link when retention, location, size, authorization, quota, connectivity, or community tier limits make the download impossible.
Passed: Download links are authenticated, authorized, scoped, expiring, revocable, and not usable merely by guessing a URL.
Passed: Download links are bound to the tenant, project, process, artifact, actor, and policy context.
Passed: Cross-tenant and cross-project download attempts are denied through the real download endpoint or API.
Passed: Download bytes are accounted before link creation and during streaming.
Passed: A download that becomes impossible mid-stream fails honestly and does not imply durability.

14. Debugging, DAP, and VS Code

Passed: VS Code F5 launches a Disasmer virtual process through the extension and DAP adapter.
Partial: Live/debug launch starts the coordinator-side virtual process without requiring a node at launch; when that process reaches a virtual task with capability/environment requirements, the coordinator places that task on a capable node. The DAP adapter does not secretly spawn a worker node or expose a direct scheduler action as the programming model. Missing capable nodes produce normal placement/unavailable-capability state. Local coordinator/worker DAP smoke and quick-test binary smoke pass, and the deployed private hosted coordinator accepts the current launch_task / worker-assignment protocol; this remains partial until the released public-repo assets and VS Code/DAP path are rerun end to end against the live private hosted coordinator.
Passed: The DAP adapter presents one debug target with multiple virtual threads/tasks.
Passed: Ordinary VS Code breakpoints in main and spawned task code bind to real runtime stop points.
Passed: A breakpoint in one virtual thread creates a Debug Epoch for the whole virtual process.
Passed: Wasm tasks participate in all-stop behavior.
Passed: Controlled native-command tasks participate in all-stop behavior when supported by the backend.
Passed: If a participant cannot freeze, the debugger reports failure and does not claim all-stop succeeded.
Passed: Continue resumes every frozen participant in the Debug Epoch.
Passed: Pause stops the whole virtual process, not only the selected thread.
Passed: The debugger shows coherent virtual process identity, virtual thread names, stack frames, task args, Disasmer handles, command status, recent output, and artifact references for the current flagship demo.
Passed: The normal debugger Variables pane exposes the MVP launch variable set: task arguments, task return values, target structured fields, selected Rust locals around Disasmer API calls, runtime-captured Wasmtime frame locals, Artifact, SourceSnapshot, and Blob handles, current VFS mounts, current command spec/status, and recent stdout/stderr tail.
Passed: Selected top-level locals around Disasmer API calls are visible in the normal debugger Variables pane from virtual-thread runtime state. This is implemented outside experiments/**; experiment-local hardcoded variable mapping does not satisfy this criterion.
Passed: The shippable node/DAP path captures real Wasmtime frame-local slots from guest-debug runtime state and exposes them through a normal DAP Variables scope. This is implemented outside experiments/**; the experiment remains proof only, not implementation basis.
Passed: Arbitrary Rust locals use best-effort source metadata when full value snapshots are unavailable, and variables that cannot be inspected are reported clearly while task args and handles remain visible.
Passed: Per-task stdout/stderr tails, VFS/artifact state, and command status are visible through normal scopes or optional Disasmer views without requiring users to understand node IDs, transport links, VFS manifests, or environment-cache internals.
Passed: The debugger does not claim to debug arbitrary native child process internals unless that support exists.
Passed: Restart selected or failed task works after a compatible source edit.
Passed: Incompatible edits require whole-process restart with a clear message.
Passed: The DAP adapter remains a standard DAP server so non-VS Code DAP clients can integrate later without a proprietary protocol.
Passed: The launch-critical DAP surface required by the MVP is implemented and release-tested: initialize, launch/attach, setBreakpoints, configurationDone, threads, stackTrace, scopes, variables, continue, pause, next/step-over at probe granularity, disconnect, stopped events, and continued events.
Passed: VS Code views show nodes, virtual processes, logs, artifacts, and inspector state without replacing the normal debugger UX.

15. Operator/control panel foundations

Passed: Protocol and state foundations exist for immediate-mode operator panels.
Passed: The MVP exposes a built-in control panel or panel preview for process status, tasks, logs, artifacts, and control-plane actions.
Passed: Program-defined panel content uses only built-in typed widgets.
Passed: User-provided panel content cannot inject custom HTML or JavaScript.
Passed: Panel state is scoped to tenant, project, and virtual process.
Passed: Panel events are typed, rate-limited, and delivered to the virtual process only when allowed.
Passed: Operator panels cannot collect passwords, tokens, secrets, OAuth codes, or OAuth-like credentials.
Passed: A stopped debug process shows the last rendered panel state without executing program UI logic.
Passed: Control-plane actions such as restart, cancel, debug, and artifact download remain available while program UI events are disabled.
Passed: Artifact download buttons use the same secure download semantics as the artifact API.

16. Abuse controls and resource limits

Passed: API calls, spawns, logs, metadata, debug reads, UI events, rendezvous attempts, artifact downloads, and hosted zero-capability Wasm resources are metered through policy before work starts.
Passed: Log output is capped, backpressured, and associated with the producing virtual thread.
Passed: Large task arguments are rejected or warned before dispatch can cause accidental distributed copies.
Passed: Community hosted tasks cannot use network, secrets, host filesystem, native commands, containers, inbound ports, or arbitrary syscalls.
Passed: Quota counters cannot be bypassed by reconnecting a node, restarting a CLI, retrying an API call, or switching tenants/projects without authorization.
Passed: Public hosted endpoints validate users, nodes, programs, logs, artifacts, UI events, source manifests, capabilities, debug requests, and download requests as hostile input.
Passed: Abuse controls are enforced at the running hosted service boundary, not only in internal model code.
Passed: Community tier language is used consistently in user-facing docs and UI.
Passed: Public-facing docs and repository text avoid naming a specific launch forum or traffic source as a product goal.

17. Packaging, docs, and first-run UX

Passed: README quickstart covers install/build, local coordinator, node attach, demo run, VS Code debug, artifacts, and cleanup.
Passed: Docs explain flush() versus sync() without implying default durability.
Passed: Docs explain best-effort artifact retention and explicit export/storage.
Passed: Docs explain secure artifact downloads and why download links may fail before creation.
Passed: Docs explain node trust, user-attached execution, and Windows sandbox limitations honestly.
Passed: Docs explain hosted/community limits without framing community tier as arbitrary hosted compute.
Passed: Docs explain browser login and public-key authentication for agents.
Passed: Docs explain disasmer run [entry], implicit hosted mode, local override, and project override.
Passed: Docs explain auto-detected node capabilities and --cap override behavior.
Passed: Docs explain how to add non-Git source-provider support.
Passed: VS Code extension packaging or documented local install works from a clean checkout.
Passed: First-run diagnostics guide users toward missing nodes, missing environments, quota limits, unavailable artifacts, auth failures, failed debug freezes, and source-provider capability gaps.

18. Flagship release matrix

Passed: Public local Linux demo: clean checkout, build/install CLI and extension, attach Linux node, run flagship build, debug in VS Code, inspect logs/artifacts, export or download final artifact.
Passed: Hosted/community Linux demo: browser login, project creation, node enrollment, task run on user node, debug, logs, artifact metadata, secure artifact download, and no hosted native/container compute.
Passed: Public split demo: same public local workflow succeeds after excluding private/**.
Passed: Hosted private demo: hosted workflow succeeds with private OIDC/policy/admin modules included.
Passed: Breakpoint in main all-stops the virtual process.
Passed: Breakpoint in a Linux task all-stops the virtual process.
Partial: The release demo lets the user inspect task args, selected locals around Disasmer API calls, runtime-captured Wasmtime frame locals, command status, logs, stdout/stderr tail, VFS mounts, and artifact handles from the normal VS Code debugging experience. Current DAP/F5 evidence covers these debugger behaviors, including selected Disasmer API source-local values and Wasmtime frame-local slots; the public release dry-run e2e still needs to be rerun later with the released public-repo assets.
Passed: Failed task restart works after compatible source edit.
Passed: Incompatible edit requires whole-process restart with a clear message.
Passed: Local-first no-upload assertions pass during the release demo.
Passed: Community tier quota enforcement and cross-tenant forbidden-access checks pass during hosted acceptance.
Passed: Demo and docs avoid coordinator-side filesystem, Git, shell, container, durable artifact store, or hard-coded machine assumptions.
Passed: Windows demo steps are included only when the current release target enables Windows validation.

18a. Public release dry run

Partial: A public release dry run deploys the real platform on a public network path so it is reachable as disasmer.michelpaulissen.com:9443; when the DNS record is live, no resolver override is required, and before propagation access may use an explicit test resolver, hosts entry, or equivalent controlled resolution path, but the service is not a loopback-only, local-only, or mock deployment. Earlier service evidence exists, but current-release acceptance remains partial until the live service smoke is rerun for the current acceptance commit.
Partial: The dry run can be shared with selected external users, such as friends, by giving them the public repository/release assets and either public DNS access or controlled fallback resolution instructions for disasmer.michelpaulissen.com:9443; the platform and public repo are live, but current Forgejo Release assets are prepared locally and not yet published.
Passed: The deployed disasmer.michelpaulissen.com:9443 platform is the default operator endpoint used by the public CLI/extension for the dry run, not a mock, local-only coordinator, or documentation-only placeholder.
Partial: The deployed default operator is explicitly the private hosted coordinator from private/hosted-policy, with private hosted modules enabled. The phrase public release dry run means public Forgejo repository, public release assets, selected-user network reachability, and public client protocol compatibility; it does not mean deploying the standalone public/open-source coordinator as the hosted operator. Current-release proof still needs a fresh live service smoke for the current acceptance commit.
Partial: The dry run validates both coordinator implementations: the private hosted coordinator through the live default-operator deployment and service/e2e evidence, and the standalone public/open-source coordinator through the filtered public repository and public release binaries in a local/self-hosted coordinator smoke. The public tree and local assets are current, but release/e2e evidence is stale and must be rerun from the fresh Forgejo Release.
Partial: The dry-run platform runs the real hosted/control-plane service path with private hosted modules included and can coordinate browser or CLI login, project selection, node enrollment, task execution, debug state, logs, artifact metadata, and secure artifact download/export. Current-release proof requires rerunning the hosted service smoke.
Passed: The dry run includes a real browser-facing account/login website served from disasmer.michelpaulissen.com through the VPS nginx configuration, woven into the same public deployment path rather than hosted as a separate mock site or local-only helper.
Passed: The dry-run website is deliberately barebones functional HTML with no CSS and no layout or UX optimization work hidden in this phase; a later acceptance pass may add explicit good-UX criteria.
Passed: The dry-run public repository is a real public repository on the Forgejo instance at git.michelpaulissen.com, produced by filtering out private release-only material, including private/** and experiments/**, not only a local temporary tree.
Partial: The Forgejo public repository can build/install the public SDK, CLI, coordinator/node runtime, DAP adapter, VS Code extension, protocol crates, and examples, and can use the deployed default operator without importing private source. The filtered public tree for the current acceptance commit is pushed and local release assets build, but default-operator use still needs current released-asset e2e proof.
Partial: A Forgejo Release for the dry-run public repository publishes compiled release assets for the supported public binaries and extension package, so a user can download the appropriate artifacts from git.michelpaulissen.com and start without building from source. The current source archive, platform binary archive, VS Code extension VSIX, invite, getting-started guide, and checksums are prepared locally for the current acceptance commit, but not yet uploaded as Forgejo Release assets.
Partial: A full e2e dry-run test uses that filtered public repository against the deployed disasmer.michelpaulissen.com:9443 service, covering build/install, default operator selection, auth, attaching a user node, running the flagship workflow, VS Code/debugger behavior, logs, artifact metadata, and artifact download or explicit export. Existing e2e evidence is stale; the current release must be verified end to end from the Forgejo Release assets.
Partial: The dry run records the public source commit, filtered public tree identity, deployed service commit/version, default operator endpoint, DNS-publication state, resolver requirement or lack of required override, environment/tool versions, and acceptance commands/results. Current local preparation records the current source and filtered public tree identities, but final evidence must be regenerated after Forgejo Release upload, deployment/service smoke, and e2e verification.
Passed: The dry-run instructions make a later fresh-domain and public GitHub-release reproduction mechanically straightforward, but actually performing that fresh-domain/public-GitHub release is explicitly out of scope for this dry run.

19. Non-goals preserved

Passed: The MVP does not imply transparent raw remote pointers.
Passed: The MVP does not imply global consensus on every memory access.
Passed: The MVP does not imply live native process migration.
Passed: The MVP does not imply live stack migration, live socket checkpointing, or arbitrary hot code replacement.
Passed: The MVP does not imply durable artifacts without explicit export/storage policy.
Passed: The MVP does not imply public hosted compute for arbitrary workloads.
Passed: The MVP does not imply secure managed Windows compute.
Passed: The MVP does not require users to understand distributed internals for the normal build/debug path.
Passed: The MVP does not require the coordinator to own source bytes, artifact bytes, build caches, or command execution in the default path.

20. Release blockers

Any item below blocks MVP acceptance until resolved:

Passed (blocker absent): Public or private runtime behavior depends on experiments/** implementation code.
Passed (blocker absent): Public source cannot build and run the public local workflow after excluding private/**.
Passed (blocker absent): Hosted coordinator can run arbitrary native commands or containers for a community tier user.
Passed (blocker absent): Hosted capless Wasm can obtain network, host filesystem, secrets, native commands, containers, inbound ports, or arbitrary syscalls.
Passed (blocker absent): Coordinator receives bulk source, artifact, blob, or build-cache bytes on a default path where the MVP says bytes stay node-local or move directly.
Passed (blocker absent): Cross-tenant access succeeds for projects, nodes, processes, logs, artifacts, downloads, debug state, panels, capabilities, source manifests, credentials, or metadata.
Passed (blocker absent): A node can claim or publish outside its authorized tenant, project, process, or task scope.
Passed (blocker absent): A debugger reports all-stop success when any controlled participant failed to freeze.
Passed (blocker absent): Artifact download link creation succeeds when the artifact cannot be downloaded under current retention, location, authorization, connectivity, size, or quota constraints.
Passed (blocker absent): Artifact download links are usable by guessing, sharing to an unauthorized actor, or bypassing tenant/project/process authorization.
Passed (blocker absent): The default system behaves as if a durable coordinator artifact store exists when the user did not explicitly configure one.
Passed (blocker absent): Coordinator restart pretends to preserve live virtual processes or stale node-owned execution state.
Passed (blocker absent): disasmer run or the flagship example requires coordinator-side Git, shell, container, or source-checkout access.
Passed (blocker absent): Windows docs or UI imply production-grade managed Windows sandboxing before such sandboxing exists and has been validated.
Passed (blocker absent): The flagship demo requires undocumented manual state, hard-coded local paths, demo-only credentials, or hidden setup.
Passed (blocker absent): User-facing docs, plans, examples, or UI name a specific external launch forum as a product goal.
Partial (blocker absence source-proven, current-release proof pending): Public released binaries only print a raw JSON login plan for normal human browser login, or the deployed default operator lacks a real browser/account login web surface served through disasmer.michelpaulissen.com. Source and local smoke coverage prove the intended browser path, but current Forgejo Release binaries and deployed nginx/Auth evidence must be rerun for the current acceptance commit.

41 KiB Raw Blame History