Remote Vault delivery

2026-09-15 — isolated partial materialization and fresh retry

Workspace #558 and Nymph #56 add a bounded local acceptance precursor for Vault #241 under master #247. Real main HTTPS/Mongo, the actual CP/Redis server and the Nymph private runner execute a pinned synthetic checkout. After the first mapping's genuine materialization acknowledgement, a test-owned directory collision makes the second mapping's actual exclusive file writer fail.

The partial phase returned input_failed: exactly the first mapping materialized, the second never materialized, zero execution permits, no task marker, both mappings cleaned and the physical stage absent. Two separately saved entries retained their IDs, revisions, unretired state and values. A new intentional request then succeeded with those same entries after cleanup removed the collision. All owned fixture processes, databases and files were removed. Frozen receipt · Runnable commands and prerequisites.

Independent review reran both phases with the corrected process helper. Three real process tests cover timeout of a separate child process group, an already-signalled child and scan failure after groups are frozen; cleanup is awaited even on failure. Nymph's focused suite passed 23 tests with 2 opt-in tests ignored; the runner fixture was executed separately for both phases. Backend full typecheck was attempted but blocked by a reused older generated Prisma client; that baseline was not altered.

This is test-source evidence, not a release or hosted UI recovery. The CP pin fab458d is older than staging; the harness signs poll/claim, uses synthetic local encryption and a test-only TLS CA with hostname verification. It does not change the published daemon, shared host configuration, authentication or cloud resources. Hosted partial-transfer, failed-authentication and browser recovery cases remain distinct requirements; this test does not close the broader checklist.

2026-09-15 — browser cancellation preserves saved entries

Browser run 6aa91e9c4965a605a6c55cee used the same pinned synthetic env/file task with a 120-second wait. Before cancellation, SSH confirmed the ready marker and the credential stage still present. The user-facing Request cancellation action produced cancel_requested with materialized inputs. The API then recorded cancelled, exit -3 at10:32:38 UTC; a browser refresh showed both inputs cleaned. Independent SSH readback confirmed stage absence and the cleanup journal.

The frozen cancellation receipt includes staging170's API source/digest, fresh signed capability, pinned setup and before/after evidence. Separate metadata-only reads using published Python0.16.1 confirmed that both saved entries still have their exact IDs and revision1, with null retirement, purge and expiry fields. The public SDK does not expose an internal ACTIVE enum; these reads establish that the saved entries remain unretired and unexpired. No secret values were retrieved. Cancelling the task removed its materialized inputs without deleting the saved Vault entries.

This is owner-requested cancellation, not automatic timeout acceptance. Partial transfer, failed authentication and unknown-write/retry cases remain separately required by the broader UI criterion. startedAt remains null, PR545 is not deployed at this checkpoint, and full fixture retirement has not been performed by this evidence task. Source progress remains 58/72.

2026-09-15 — browser-submitted remote task on staging170

The authenticated browser selected the two synthetic env/file mappings, reviewed consent and submitted the pinned repository task. Run 6aa91ce04965a605a6c55ce0 succeeded with exit 0 at10:24:36 UTC. The refreshed UI and API both showed the two mappings cleaned. Independent SSH inspection found the task-ready marker, absent credential stage and recorded cleanup journal. The pinned task source asserts both the selected environment value and file bytes before writing that marker, so this is task-execution evidence rather than a saved-entry or screenshot-only check.

The API target was staging170, source 95ba146db1e0e6155e85b1143eee263fffabed4b, image sha256:077af82e262c2a6e03ac241f2dbd78bbf44ba6f68591797b8dd1a2352a05cc77. The signed worker capability was fresh before submission. Frozen browser/API/worker receipt. The same successful-run browser tab exposed 13 script/style paths. Fresh public and immutable-deploy readbacks matched all 13 files, pinning UI source 4da4f98d271b67844a8f0a65fb9aea8b96d99f9a, deploy 6aa910ee2665880008f8155a (published09:35:07 UTC). This differs from the older UI269 receipt; the evidence uses the actual current build. Independent review approved only the remote-task checkbox. Issues241/247 and the matching project task were read back at 58/72 complete, 14 open; the UI group remains 8/12. The other 71 checkboxes and unknown task timestamps were preserved.

The receipt retains startedAt: null; deliveryState: permit_reserved intentionally describes the grant reservation. PR545 is not deployed, and the known timeout-classification gap remains open. This verifies the one browser-submitted task and its selected-input cleanup, not production readiness, timeout behavior or full fixture retirement.

2026-09-15 — Nymph 0.1.7 publication and owned Linux upgrade

Nymph 0.1.7 is published: 14 versioned public CDN objects and 14 GitHub assets were byte-verified, followed by 15 latest/installer objects with the version marker written last. The build manifest's candidate label records an earlier build checkpoint. GitHub downloads require repository access; the immutable public CDN supplied the actual Linux executable used below. Frozen publication and host receipts.

At 10:00:20 UTC, a fresh owned directory on bos14 downloaded the public Linux x86_64 binary, verified SHA-256 7a69766041d3e5c93de81b85b33757cc3344db956f60b45ee2e8e98e8685e7da (4,933,968 bytes), and successfully ran --version and --help. The temporary directory was removed and the existing daemon remained unchanged. There is no standalone preflight command; this smoke did not start a second worker or inject a broken configuration.

To repeat only the public binary smoke from a workspace checkout, choose an SSH-accessible Linux x86_64 host with Python 3 and curl. The bounded script uses a fresh temporary directory, verifies the pinned checksum before execution, runs version/help and removes its files. It does not install or restart a daemon, read credentials, or test private execution.

ssh -o BatchMode=yes -o ConnectTimeout=10 YOUR_HOST 'python3 -' \
  < scripts/acceptance/nymph-017-linux-smoke.py

At 10:04:08 UTC, after all persisted acceptance runs were terminal and no owned child processes remained, only the existing owned daemon binary was upgraded. Its 0.1.6 rollback copy was retained. Configuration, signing key and unit text remained unchanged. An initial canonical-path guard refused before any mutation; the expected home-directory symlink was then explicitly pinned while retaining ownership and leaf-path checks. The new running executable matched the public hash; six samples and the subsequent readiness check showed the same active PID and zero automatic restarts.

Fresh privateTracked readiness, signed at 10:04:30 UTC and observed at 10:04:48 UTC, used the original active key against revalidated staging169. Nymph advertises that capability only after its configured git/uv functional preflight succeeds, so this proves the valid startup path. Preflight scratch directories were absent; no recognized preflight failures appeared in the owned diagnostic log. It does not prove live broken-tool rejection, resolve the timeout classification/start-time defects below, or change the 55/72 source checklist recorded at this checkpoint. No API, cloud, key, configuration or shared-daemon changes accompanied this upgrade.

2026-09-15 — hosted staging169 execution and cleanup

Staging169 was the sole completed revision at 09:46:18 UTC, with one running task, no pending tasks and rollback alarm OK. It uses source 24215a766f3fe22d9afc3d13446eef6be91f8a8e and image sha256:94d9e1954ff710cf1b432ee8c01efd0af713b6434444defd961b6e85748a725f. Fresh CP readiness preceded these executions on the owned bos14 enrollment. This supersedes the disabled task168 checkpoint below; it does not change production.

The automatic timeout case (6aa91502a660de1789731b0b) used a 60-second timeout with a 120-second wait and no manual cancellation. It reached the ready marker before the deadline, then ended cancelled / -3 at09:51:59 UTC, instead of timed_out. Both inputs were cleaned and independent inspection confirmed stage absence plus the cleanup journal. Cleanup passed; timeout classification failed. This is an open lifecycle defect, not a successful timeout acceptance.

Both selected inputs are cleaned in all four terminal API receipts, under discard-at-source-v1. The successful receipts still report startedAt: null and deliveryState: permit_reserved; cancellation reports revoked but also has a null start time. Here deliveryState tracks grant reservation, not process or cleanup state: permit_reserved after success is intentional and is not a defect. The null startedAt remains a reconciliation gap; that field represents CP claim/setup time, not the actual process start. Physical task markers establish execution. Do not derive process start time or elapsed duration from these fields. Frozen sanitized receipts.

This checkpoint proves the listed hosted client cases and their input-stage cleanup. Browser submission, expiry/recovery coverage and broader acceptance remain separately tracked; it does not mark the full issue complete or change the 55/72 source checklist. The two earlier failed attempts remain below.

2026-09-15 — historical task168 rollout and hosted launch failure

A subsequent external staging168 rollout began at 09:19:44 UTC on source 24215a76, resetting private execution to false and removing the repository-origin configuration. At that checkpoint it was in progress; task167's successful readiness below is historical, not evidence that the newer fleet still permits private execution. No third launch had been submitted at that checkpoint.

The second published CLI attempt (6aa90d41520712c3a3459265) ended dependency_failed at 09:17:59 UTC, with startedAt still null. The API recorded both inputs cleaned; independent worker-journal inspection confirmed the input stage absent and cleanup recorded, with no task-ready marker. This proves cleanup of a failed dependency stage, not successful execution or cancellation acceptance. Sanitized terminal, physical-cleanup and UV receipt.

The configured Snap uv failed its version check because it could not create its user data directory (Not a directory). An owned, verified standalone uv 0.12.14 was installed and the owned configuration corrected without changing the existing Snap installation. The external rollout interrupted fresh readiness at that checkpoint. The later task169 executions above verify the corrected dependency setup; broader acceptance remains separate. Current coordination and evidence.

2026-09-15 — historical task167 rollout and readiness

PR524 merged as 11cbba7f after full CI. Narrow source 1553a62a applies the reviewed two-file patch to task166 source 70b594db, preserving its newer schema, router and retention settings. All 520 image source/schema/package/lock files match that candidate. The build receipt records immutable provenance; deployed: false is its historical pre-rollout checkpoint.

At 09:17:07 UTC, staging167 was the sole completed revision with one running task, verified digest sha256:3b351c9f3c6daa249287c3d27a2d6fe78e69071ba27162bbe9b00cb77a2d0ab8, health200 and rollback alarmOK. Only the image and three previously reviewed private-run settings changed; all other task fields/tags and deployment controls match task166 (AWS reordered the compatibilities array). Private runs are configured and KMS migration remains false. Production was unchanged. Rollout and readiness receipt.

The personal capability readback at09:17:11 returned enabled without changing the namespace record. At09:17:14 the read-only CP probe found the owned worker active, with its matching active key and fresh version-1 discard-at-source capability. These are readiness observations, not execution acceptance. The new published CLI0.20.1 attempt subsequently failed during dependency setup; its terminal outcome and the later external rollout are recorded above. The earlier hosted request timed out before execution without creating a grant/dispatch; that failure remains recorded, and no live database repair was performed. At that checkpoint hosted execution acceptance remained open; see the task169 results above and the remaining scope in Vault241 and master247.

2026-09-15 — historical frozen-connection diagnosis

The first hosted run remained queued before any capability, grant or dispatch was created. Read-only checks found the frozen connection reference failed the production adapter comparison while ownership, fingerprint, key and fresh signed capability checks passed. The Mongo enrollment stores its connection as BSON ObjectId; Prisma exposes the same reference as a string. Two real-Mongo regressions reproduced the capture and production-adapter failure.

The source fix stores new frozen connection references as canonical strings and recognizes BSON references in existing runs. Only ObjectId, valid 24-character hexadecimal strings and an unset reference are recognized. Malformed objects, missing frozen pins and changed connections remain denied before transport; a retry cannot move an existing run to a different control plane. No live database records were repaired. At the diagnosis checkpoint the fix was not deployed, and external task166 rollout halted further guarded live diagnostics. The subsequent rollout checkpoint is above; hosted execution acceptance remains separate. Vault241 · master247.

2026-09-15 — historical task 165 capability verification

At that checkpoint, staging task 165 was the sole completed revision, using narrow source 86a9aa4f and verified image digest 34b97cda…. The rollout changed only the image: task 164 environment, tags, roles, limits and canary/rollback settings were preserved. KMS migration remains false; health returned 200 and the rollback alarm is OK. Rollout and readiness receipt.

PR516 merged after full CI. The deployed candidate applies exactly that routes/test patch to previously deployed cb73cee, preserving its schema and index guards rather than including newer unrelated main changes. The build receipt records the pinned base, source archive and 506 verified image source/schema/lockfile hashes; its deployed: false field is the historical pre-rollout build checkpoint.

At 08:35 UTC, the authenticated capability endpoint returned enabled for the same personal namespace with its organization field still absent. No namespace data repair was performed. A fresh signed poll showed the owned daemon active with the matching active key and version-1 discard-at-source capability. This is readiness evidence; hosted execution, cancellation, expiry and cleanup acceptance remain separately tracked by Vault241 and master247.

2026-09-15 — historical task 164 diagnosis

Staging task 164 settled on the unchanged cb73cee image with exactly the three reviewed private-run settings enabled. KMS migration remains false; the rollback alarm is OK and health returned 200. AWS normalized absent Main.systemControls to an empty array; other task fields and tags are unchanged. Readiness receipt.

The upgraded control plane verified its read-only 44-index startup check, unchanged full 66-index inventory and fresh owned-daemon signed capability. These are readiness checks, not hosted execution acceptance. The main capability API still returned disabled: the authenticated personal namespace omitted orgId, and Prisma distinguishes missing fields from explicit null. No namespace data was changed.

The source fix accepts null or missing personal-namespace organization/deletion fields, matching existing Vault authentication. Explicit organizations, other owners and deleted namespaces remain excluded. Real Mongo HTTP regressions reproduced three failures before the fix; at this checkpoint the source fix still required review, deployment and readback before hosted acceptance. Tracking: Vault241 and master247.

2026-09-15 — staging, retention and project progress verified

Current checkpoint; full Vault acceptance remains open. Tracking: Vault241 · master247. The CLI/Python guide remains capability-gated.

Cleanup evidence records the owned Kubernetes namespace absent, IAM role absent, empty association, three Terraform resources destroyed and SSM session terminated. Main/CP/private-run flags were not enabled by the retention fixture or the artifact update. Worker publication does not upgrade an existing daemon.

Earlier dated entries below retain their evidence scope and are historical; this checkpoint supersedes their release/deployment availability statements.

2026-09-15 — retention deployment configuration

The workflow now forwards the five existing entry-GC/retention/audit variables with JSON escaping and unchanged defaults. This is source wiring, not a deployed setting change. Five workflow/runtime tests passed. Cleanup guide separates owner retirement/restore/unbind from physical collection; shared production purge and backup policy remain open.

2026-09-14 — ordinary production daemon acceptance passed

The post-CA production GNUx64 daemon (046138c, SHA 46a31b7c…) passed actual bound enrollment, signed private polling/claiming, success, owner cancellation and expired-permit refusal on an owned bos14 fixture. Published native CLI 0.20.0 and fresh PyPI Python 0.16.0 submitted/replayed/reconciled status. Every daemon exited normally and CP recorded gone; input stages, processes, tunnels and owned files were verified absent before cleanup.

Durable production-daemon receipt. This receipt used the post-47 daemon with explicit private CA configuration, independently of the frozen pre-CA 0.1.6 artifact. It is not a shared/hosted rollout; current publication status is above. Earlier runner-helper receipts remain unchanged.

2026-09-14 — fresh termination-fixed remote pipeline

All three owned bos14 scenarios passed again using Nymph 3152585 and the new locked Linux test binary b5eaa37c…: success, Python-requested cancellation after task readiness, and authentic expired-permit refusal before launch. The actual main owner HTTP API, CP server, signed poll/claim/result and current CLI/Python source clients participated. Each scenario materialized and cleaned both synthetic mappings; terminal output stayed empty.

The fresh receipt preserves exact source/artifact pins separately from the earlier receipt. Owned processes, input stages and reverse-forward ports were verified absent before deleting binaries, signing fixtures, CAs and the remote root. Local databases and fixture processes were removed. These are source-client tests with test-only CA trust, not installed-package acceptance or a hosted deployment. Nymph45's refusal tests and full pipeline evidence are distinct; daemon restart and detached-descendant containment remain open.

2026-09-14 — task-only credential directory; bos14 acceptance

An earlier bos14 attempt returned task_failed because the workload could not locate its delivered file. Nymph 2a33ea1 materializes files in an owned .credentials directory beside the checkout and supplies DREAMLAKE_SECRETS_DIR only to the intended task after dependency preparation. The working directory stays the checkout. Fifteen focused tests passed; the shell/Python workload examples show explicit file lookup without putting values in arguments or repository files.

The corrected Linux test binary (8439ba30…) passed all three recorded bos14 cases using actual main-owner HTTP, CP, Redis/Mongo and signed poll/claim/results. CLI submitted each run; Python replayed the same request and performed cancellation after the real task marker appeared. Every case recorded two materialized mappings and two cleanup acknowledgements, with empty private logs.

Owned remote files, generated signing keys, local fixture databases/certificates and reverse forwards were removed; CP/Redis/Mongo processes stopped. The remote directory's absence was independently checked over SSH. These cases use synthetic KMS and a locked-build test binary with a fixture CA; TLS hostname/certificate checks remain enabled. They do not repeat AWS/GCP KMS acceptance or establish hosted deployment. Earlier failed attempts also exposed repository access and the snap launcher; the final fixture pins a public repository and isolated uv binary.

API472 merged at 6bbbf8f after full CI on e216b58. CLI74 (b1181b7) and Python55 (b1e2a91) are merged and included in the subsequently published CLI 0.20/Python 0.16 releases. Subsequent staging rollout and hosted private execution evidence are recorded above; this historical fixture alone does not establish them.

Reconciliation481 later merged the reviewed authorization fix. Its read-only staging160 inventory is historical; the completed staging163 application/index checks are recorded in the current checkpoint. One empty Bindr under a retired project was preserved.

Earlier entries below retain their status at the time.

2026-09-14 — permit-authority review history

Independent review reproduced capability-expiry and enrollment-key races during permit commitment. Transaction fences and deadline rechecks fixed both; API472 subsequently merged after full CI. The permit-authority section preserves the regression details. Earlier draft/candidate deployment instructions are superseded by the current checkpoint and operator configuration.

2026-09-13 — proposed contract, not implemented. Vault #241 and master #247 require actual remote task execution with selected access. The delivery contract extends existing TrackedRun/control-plane/Nymph execution with a pinned repository checkout, revision-pinned worker delivery, private files/in-memory environment, durable per-entry outcomes and owned cleanup. CLI/Python and UI use the same run API.

Source inspection found two boundaries that cannot be bypassed: run manifests are persisted, and ordinary tracked runs capture output. Proposed secret-enabled runs use metadata-only manifests and signed direct worker delivery; task output is suppressed at the source, with explicit consent. Decryption must project exact fields even for owner grants. The execution-permit/spawn crash gap remains an explicit unknown outcome, never an automatic second launch.

The initial process-host/uv-lock slice deliberately trusts project/dependency build code before secrets are delivered; a frozen lockfile is not a sandbox. Signed authentication, grant authorization and replay protection need independent review before route implementation. No new host-enrollment engine or Workstream #301 dependency is proposed. Docs build/reference checks validate this document, not remote execution.

2026-09-13 — authentication scaffold under review. The backend now has an unregistered raw-byte signature verifier, a store-owned metadata grant interface, and explicit whole-value/field projection. It rejects compressed/non-JSON requests, duplicate signing headers and noncanonical timestamps. Atomic nonce persistence is an adapter requirement: retain through the entire signed timestamp/skew window, including future timestamps. A second fresh grant read rejects changed ownership, identity, generation or selection. The verifier copies caller-owned bytes, headers and request fields before asynchronous lookups, so validated and signed bodies cannot diverge. No delivery/decryption route is registered.

Focused HTTP/signature tests and isolated real HTTP/Mongo Vault entries cover UUID identity, whole strings, selected fields and whole JSON maps. This does not establish durable grant authorization, KMS race safety or remote execution. Those remain required before enabling the proposed API; CLI/Python commands remain proposals.

2026-09-13 — durable metadata store candidate, not enabled. The next slice adds Mongo-backed grant create/status/revoke and cross-instance nonce uniqueness. It requires an independently issued server capability tied to the exact tracked run, worker/enrollment identity, reviewed intent and source-output suppression policy. Ordinary run requests cannot assert that capability. No capability issuer, route, credential decryption or execution path is enabled by this candidate.

Grants stay scoped to the personal owner namespace and exact current entry revisions. Whole-value/field selection and output destinations are explicit; changed/deleted hosts, keys, entries, expired capabilities and revoked work fail closed. Revocation persists cancellation intent; it does not prove the process stopped. Uncertain grant metadata has no TTL. Nonces use durable uniqueness and the complete signature-window TTL. Real Mongo tests validate ownership, retries, races and index configuration; actual TTL sweeping and remote execution remain separate acceptance requirements. CLI/Python stay on the existing run API until paired pipeline integration is ready.

Existing host/run writers do not all acquire the Vault transaction guard. The store snapshot alone cannot exclude every concurrent run change; coordinated run-generation checks before/after KMS and the execution permit remain required before any delivery route is enabled. Capability verification is bounded to five minutes and the run deadline.

2026-09-13 — private setup contract candidate. Pure validation now normalizes reviewed setup metadata into a distinct private execution kind and fingerprints repository, full commit, destination, enrollment, mappings and execution. The main HTTP path explicitly rejects setup as unavailable before persistence/dispatch; normal logged execution cannot receive a downgraded setup request. Tests cover URL/argument/consent validation and real authenticated HTTP/Mongo rejection with zero run records and zero CP submissions. No capability issuer, private worker execution or decryption route is enabled. The pipeline split records the CP, Nymph and paired CLI/Python work still required.

2026-09-14 — execution binding and disabled delivery adapter under review. The private execution SHA-256 covers canonical JSON {version:1,execution,setup,timeoutSeconds}. Object keys are ASCII and sorted, arrays retain mapping/selection order, strings use UTF-8 without normalization, and numbers are unsigned safe integers. Shared TypeScript/Rust vectors include composed/decomposed Unicode, escaping and ordered selections. The separate manifestHash remains setupRunFingerprint(normalizedSetup, namespaceId) and binds owner namespace, target, enrollment, timeout and consent. Neither hash replaces current ownership, entry revision, enrollment key or server capability checks.

The reviewed candidate authenticates exact raw signed input/permit requests and requires executionHash before KMS. Plaintext is projected to the approved mapping only and withheld if authorization, retirement, revision or execution changes during decryption. A durable permit reserves one attempt for at most five seconds, only after every selected mapping has a materialized acknowledgement for the exact generation and hash, and no selected mapping has been cleaned. Concurrent retries return its original receipt and expiry; a different attempt cannot reserve again. Reservation closes value release, but does not prove a process started. Revocation persists cancellation intent. Metadata-only same-attempt receipt recovery and signed cleanup acknowledgements remain available after cancellation, with current host/enrollment ownership checks. Progress sequences are strictly increasing with exact retries; gaps are allowed. A cleaned acknowledgement is not proof that a detached process erased inherited environment values.

Delivery intent fingerprints now use version 2 and preserve array order. Older unmounted scaffold grants/capabilities fail closed; they are not silently migrated or reactivated. The runtime assembly accepts an explicit programmatic review gate; no environment flag currently enables private delivery, and ordinary setup submission remains rejected. Optional TrackedRun fields store setup, manifest fingerprint and permit reservation ID. Capability issuance, CP dispatch, deployment and real remote task acceptance remain separate work. No delivery endpoint or cloud configuration was deployed by this change.

Permit authority review — 2026-09-14

Independent real-Mongo interleavings reproduced permit issuance after capability expiry during readiness checks and after an enrollment signing-key change committed against the authorization snapshot. Permit creation now writes transaction fences on the exact namespace, host, enrollment and capability documents, in addition to the existing cancellation fence on the run. A concurrent authority mutation forces a retry and fresh validation.

The captured capability/run deadline is checked before and after those writes and after permit persistence. A permit expires at the earliest of five seconds, the grant deadline and the verified authority deadline; receipt retries never extend it. Regression coverage includes namespace/host ownership changes, enrollment key changes, capability revocation, ordinary cancellation, expiry during readiness and expiry during persistence, with no partial permit/grant/run state after denial. These are local isolated tests, not deployment evidence.

The final focused auth/store/hash/setup suite passed 146 tests, including real Mongo and HTTP; TypeScript typecheck passed. A permit can expire in transit, and Nymph must still refuse it immediately before spawn.

2026-09-14 — owner issuance and CP dispatch candidate, default off. The stacked implementation connects the existing owner run endpoint to private setup validation, personal-namespace ownership, active original signing-key verification, short-lived signed CP capability evidence and exact immutable run intent. Durable run and dispatch records recover ambiguous CP replies by replaying the same request ID. Cancellation recovery uses the exact original CP payload with cancel_requested: true; it never recreates a grant, renews the original run deadline or resets cancelled work. Ordinary reconciliation excludes private records, and private logs remain empty. Owner responses expose only selected entry IDs/revisions and bounded progress metadata.

A disposable actual CP HTTP/Mongo fixture accepted an enrolled-key signed poll, exposed original-key capability evidence, received the main service's private dispatch and claimed it through a second signed poll. Nymph test candidate 255207b then used verified localhost HTTPS (a test-only CA) to retrieve the selected synthetic value, acknowledge materialization, reserve/replay the immutable permit, reject further input, reject an expired permit for spawning, and acknowledge cleanup. One Rust test passed in 5.41 seconds. Final Mongo metadata contained one expired permit and exactly materialized sequence 1 / cleaned sequence 2. Normal shutdown dropped the owned fixture databases, stopped the servers/Mongo and removed temporary keys. Exact dirty-source SHA-256 values and the sanitized receipt are preserved in dreamlake-server/src/runs/fixtures/private-pipeline-evidence.json; subsequent owner HTTP response wiring has separate JWT/account/Mongo tests. This proves the signed transport chain, not repository checkout, task execution or a hosted deployment.

To reproduce from the server checkout and the reviewed CP/Nymph checkouts:

PRIVATE_CP_CHECKOUT=/path/to/controlplane \
  ./node_modules/.bin/tsx scripts/check-private-pipeline.ts

# In the Nymph checkout, use the private fixture path printed above.
NYMPH_PRIVATE_API_FIXTURE=/private/fixture.json \
  cargo test --lib actual_main_https_delivery_and_immutable_expired_receipt -- --ignored --nocapture

# Stop the printed fixture PID normally to record receipts and clean up.
kill -TERM <fixture-pid>

The fixture uses generated credentials only and expires after five minutes. It does not disable certificate verification or change trust configuration on the machine. Production activation and real remote repository/task acceptance remain pending.

The follow-up owner-service review adds original-deadline convergence: undispatched runs become timed out without launching, while ambiguous dispatches revoke input authority and reconcile cancellation rather than claiming the remote task stopped. Cancellation compares against terminal state before mutation. A bounded pending cursor advances past unavailable owners without deleting or modifying their records. Cross-client acceptance exercised CLI submission and Python same-request replay, empty logs and cancellation against actual main HTTP/JWT/Mongo; that test uses a controlled CP adapter and is distinct from the signed CP/Nymph TLS snapshot above.

2026-09-14 — owned remote task acceptance passed. CLI submission and Python same-request replay reached the actual control-plane server with signed daemon poll/claim and isolated Mongo/Redis. On bos14-ctrl, a pinned public synthetic repository was checked out, its uv lock synchronized, and selected env/file inputs consumed without output capture. Success, owner cancellation after the task readiness marker, and expired-permit refusal all passed with two cleaned inputs, signed CP results and no payload stage remaining. Generated keys, certificates, fixture databases/processes, reverse forwards and the owned remote directory were removed. Sanitized source pins and receipts.

The locked Nymph test executable uses a test-only CA for the loopback tunnel while retaining certificate/hostname verification. This run uses a synthetic KMS provider; it does not repeat separate AWS/GCP acceptance or deploy hosted services. Earlier failed attempts exposed a private repository, a broken snap launcher and a missing credential-directory contract; corrected runs use a public fixture, an isolated uv binary and a dedicated sibling credential directory.

Current prerequisite, 2026-09-15. The termination-refusal defect was fixed in merged Nymph45. Fresh full-pipeline success, cancellation and expired-permit refusal passed with the fixed runtime; see the updated evidence below. Activation still requires the released/deployed fixed runtime, compatible main/CP configuration and fresh worker capability evidence. These source/test receipts do not prove a shared daemon was upgraded or hosted private execution enabled.

Operator configuration and discovery

Implemented opt-in; deployment must be verified. Private execution remains off by default. An operator can configure the existing authenticated vault runtime with the following additional settings after reviewing the server and daemon versions. The existing real AWS/GCP KMS configuration remains required.

export DREAMLAKE_VAULT_PRIVATE_RUNS_ENABLED=true
export DREAMLAKE_VAULT_PRIVATE_API_ORIGIN=https://api.example.com
export DREAMLAKE_VAULT_PRIVATE_REPOSITORY_ORIGINS='["https://github.com"]'

The direct origin must be canonical HTTPS with no credentials, path, query or fragment. Repository origins are a nonempty JSON array of exact canonical HTTPS origins; no wildcard expansion. Partial or malformed configuration fails startup. Omit all three settings to keep the feature disabled. These environment examples do not activate or deploy an existing service.

Nymph separately requires an owned root, absolute reviewed git/uv executables, its normal verified HTTPS main origin, and exact repository URLs in its existing private_tracked configuration. Its signed fresh poll and active original identity remain mandatory at submission; server discovery is not host readiness.

[private_tracked]
api_origin = "https://api.example.com"
root = "/var/lib/dreamlake/private-runs"
repositories = ["https://github.com/example/task.git"]
git = "/usr/bin/git"
uv = "/opt/dreamlake/bin/uv"
path = "/usr/bin:/bin"

dreamlake runs capabilities alice --json

capabilities = client.runs.capabilities("alice")
assert capabilities["privateSetup"]["hostReadiness"] == "verified-on-submit"

The authenticated discovery route is GET /namespaces/:slug/runs/capabilities. Its private mode is available only for a personal owner namespace on an enabled server. It reports limits, consent requirements and output policy without credential values or claiming that any target is currently connected. Submission still performs fresh worker/key/capability checks and can fail after discovery.

2026-09-15 — release and delivery reconciliation

Implemented and merged; release/deployment status is per surface. Vault241 and master247 remain the acceptance ledger. The usable private-run guide now documents the shared submission/status/cancel interface and immutable recovery, without advertising an unimplemented per-mapping retry API.

The current per-surface status is above. The following hashes and fixture receipts preserve release provenance.

Python 0.16 public artifact SHA-256:

• Wheel: 910a4491868a9e1f2e4f34d9b7b226e2402e05b83177de02ab13af9eab148c2d.
• Source archive: 471e5d88051952a3dfaaab917e74e72b84092f87a356302b4763d78ca6a91810.

Immutable fresh remote receipt pins main 838397d, CP e1df061, Nymph 3152585, CLI f04468a, Python 99993fb, and the synthetic public repository commit. All three cases materialized two mappings, removed owned staging and reconciled signed CP/main status. Owned processes, reverse forwards, signing fixtures, binaries and directories were removed. Nymph45 separately covers ownership-refusal behavior; no detached-descendant containment or restart acceptance is inferred.

UI acceptance and screenshots include exact downloaded-request replay after closing/reopening, same-request conflict409, other-owner403, env/file mappings and cancellation without value/log reads. The export preserves setup, argv and request ID; recording only the ID is insufficient to recover an unknown submission. The product displays actual capability/availability, while operator release prerequisites remain in this note.

Published npm client and completed staging index migration

CLI 0.20.0 is now published on both native downloads and npm. Publication receipt records all eight platform hashes/sizes, wrapper source-byte agreement, fresh isolated npm installation and installed binary SHA/version/capability help. Public registry latest/next both resolve 0.20.0. This is installed-client smoke acceptance, not a repeat of the full private remote pipeline with installed packages.

The separately authorized staging 162 index migration created two canonical Bindr indexes, verified them, and dropped only the reviewed legacy constraint. Fresh read-only inventory passes 232 contracts across 87 collections with no additions, blockers, duplicate groups or parallel arrays. The same task 162/source cd490e/digest 3f835 target remained in place. See the index-safety evidence note; application deployment499 subsequently verified task 163, while enabled hosted Vault acceptance remains pending.

Immutable staging migration receipt records the exact before/apply/after target and index results.