[A3S Cloud] Complete provider capability contracts needed by C0, S0, and H0

[ZhiXiao-Lin]

Cloud gate

Cross-cutting prerequisite for C0 control operations, S0 stateful resources, and H0 production hardening.

Planning reference: https://github.com/A3S-Lab/Cloud/blob/e2a05b7f1f63486b2fda866b22aa84eea89aadb4/docs/development-plan.md

Problem

Cloud must reason about provider capabilities without leaking provider-specific fields into its domain model. The Runtime compatibility baseline needs explicit, testable contracts for the capabilities used after the initial Task and Service lifecycle.

Scope

• Stabilize and document the Runtime v0.2 compatibility baseline used by Cloud.
• Add typed capability discovery and unsupported-capability errors.
• Extend the exported provider conformance suite for secret projection, log streaming, bounded exec, mounts, outputs, usage, and evidence.
• Define adoption and reconciliation behavior for provider restart, caller retry, and an already-existing unit.
• Define cleanup and ownership rules for capability resources when a Task or Service stops.
• Decide through an ADR whether bidirectional streaming exec belongs in the core contract; do not publish it before cancellation, backpressure, and terminal ownership are specified.
• Publish compatibility and migration notes for providers implementing the baseline.

Acceptance criteria

• The real Docker provider passes the expanded conformance suite on Linux.
• Every capability is discoverable before use and returns a typed result or typed unsupported error.
• Retry and restart tests adopt one provider unit and do not duplicate secrets, mounts, or output records.
• Secret values are excluded from specs, diagnostics, usage records, and evidence payloads.
• Cloud can consume the baseline without importing Docker-specific types.

Non-goals

• Cloud scheduling, tenancy, authorization, or operation policy.
• Provider-specific configuration in the Runtime core.
• Making every optional capability mandatory for every provider.

[ZhiXiao-Lin]

Status audit (2026-07-19): Runtime #2 was human-merged as 010588f, and Cloud #1 was human-merged as b3144bf.

The merged Runtime slice now provides typed provider identity/capability validation, typed unsupported-capability rejection before reservation, capability-triggered conformance profiles for mounts/logs/exec/security/outputs/usage/evidence, durable retry/restart/adoption semantics, inventory-checked cleanup, and explicit wire/migration notes. Cloud consumes the provider-neutral protocol and includes an isolated Docker conformance harness.

Keep this issue open for the remaining acceptance evidence. Cloud #1 explicitly states that shared CI validates only the isolated runner syntax/helper; the real root-owned Linux Docker provider gate was not executed there. The repository also has no ADR decision for bidirectional streaming exec yet. A closure PR/run therefore still needs to execute the expanded Docker profile suite on Linux, prove secret/mount/output non-duplication and nondisclosure across retry/restart, and record the streaming-exec decision. No release was performed as part of this audit.

[ZhiXiao-Lin]

Provider-evidence update (2026-07-20): Cloud #13 was merged as 36d11d98. It adds a fail-closed, root-owned Ubuntu/Docker provider gate for relevant PRs and main merges, nightly, and manual dispatch. The runner uses a restartable nested daemon, private Unix socket, loopback ext4 data disk, exact ignored-test selection, bounded TTL, and retained evidence artifacts.

The post-merge main certification run 29718495849 passed against the exact Cloud-pinned Runtime revision f29e1ef72a2223813700fdf112aa2fa8819fe406:

• real_docker_passes_all_advertised_runtime_profiles: 1 passed, 0 failed, selected with --ignored --exact --test-threads=1;
• Recovery, Networking, Mounts, Health, Resources, Logs, and Security all emitted profile-pass evidence;
• the pinned OCI fixture audited 18 manifests, 34 blobs, and 52 unique objects;
• provider containers, volumes, and semantic networks returned to the exact baseline;
• every host container, volume, network, loop-device, loop-mount, and Docker-netns delta was empty;
• the provider root, target containers/networks/directories, and both Git worktrees were clean after cleanup; and
• the run emitted A3S_DOCKER_CERTIFICATION_PASS cloud=36d11d98... runtime=f29e1ef... with exit status 0.

This closes the audit gap noted above for real Linux evidence covering the Docker driver's currently advertised profile set. Keep this umbrella issue open: capabilities that Docker does not yet advertise, plus the remaining cross-process retry/restart nondisclosure and non-duplication evidence for Secret/output capability resources, are not established by this provider run.

[ZhiXiao-Lin]

Secret-capability evidence update (2026-07-20):

• Cloud #14 merged as 210210a4, adding the provider-neutral registry-credential Secret target, transient authenticated OCI resolution/pull, a real private-registry acceptance path, and updating Cloud's Runtime pin to cfaac63af6f76beebdc64a1ec228cedc42bb98ec.
• Cloud #15 merged as 4e8df176, replacing the Docker fixture's previously declarative-only SECURITY-SECRET-NONDISCLOSURE case ID with real provider behavior.

The post-merge main provider run 29719728655 passed against Runtime cfaac63a and emitted:

A3S_RUNTIME_SECURITY_CASE_PASS case=SECURITY-SECRET-NONDISCLOSURE retry=true provider_restart=true
A3S_DOCKER_CERTIFICATION_PASS cloud=4e8df176... runtime=cfaac63a...

That case resolves a file Secret only inside the Docker driver, requires one 0400 material file on a shared private tmpfs, proves the value is absent from the Runtime spec, Docker inspection, Runtime inspection, and Runtime observation evidence, and requires logs to contain only the exact redaction marker. A distinct caller retry and an isolated provider-daemon restart both re-adopt the same provider resource with one unit container and one material file. Removal deletes the generation directory. The retained artifact records exit status 0, an empty secret-files-after-test.paths, and empty provider, host, loop-device, mount, Docker-netns, target-resource, and Git-worktree deltas. Cloud main CI 29719728633 also passed Rust 1.85/stable, Linux Secret/log/private-registry acceptance, Gateway TLS, S3, policy, and Web.

This establishes real nondisclosure and retry/restart non-duplication evidence for the currently advertised file-Secret path, and real authenticated pull evidence for typed registry credentials. Keep Runtime #1 open: Docker still does not advertise Exec, OutputArtifacts, Usage, or Attestation, and output-resource plus cross-restart mount/output evidence remains outside this slice.

[ZhiXiao-Lin]

Mount-capability evidence update (2026-07-20): Cloud #16 merged as 012ee3f1, strengthening the real Docker MOUNT-VOLUME-PERSISTENCE case from one-shot Task persistence to retry/restart identity evidence.

The post-merge main provider run 29720708892 passed against Runtime cfaac63af6f76beebdc64a1ec228cedc42bb98ec and emitted:

A3S_RUNTIME_MOUNTS_CASE_PASS case=MOUNT-VOLUME-PERSISTENCE retry=true provider_restart=true resource_identity=true volume_identity=true mount_attachment=true
A3S_DOCKER_CERTIFICATION_PASS cloud=012ee3f1... runtime=cfaac63a...

The case starts a named-volume Service with a run-specific token, retries it under a distinct request ID, restarts the isolated provider, and then re-applies and inspects it. Every phase requires the exact same single Docker container, exact same single named volume, and one exact mount attachment. A separate read-only Task observes the pre-restart token and proves writes are denied before the Service and volume are removed explicitly.

Recovery, Networking, Mounts, Health, Resources, Logs, and Security all passed; the exact certification test reported 1 passed and 0 failed. Retained artifact 8452293177 records exit status 0, exact provider container/volume baselines, equal pre/post network semantics, stable provider/keeper network namespace identity, and empty host, loop-device, loop-mount, Docker-netns, target-resource, Secret-file, and Git-worktree deltas. Cloud main CI 29720708852 also passed Rust 1.85/stable, Gateway TLS, S3, Linux Secret/log/private-registry, repository policy, and Web.

This establishes real caller-retry and provider-restart non-duplication evidence for Docker's advertised Volume mount capability while retaining the existing read-only, persistence, tmpfs-isolation, and cleanup checks. Keep Runtime #1 open: Docker still does not advertise Exec, OutputArtifacts, Usage, or Attestation; output-resource recovery evidence and the streaming-exec ADR remain outstanding.

[ZhiXiao-Lin]

Streaming-exec decision audit (2026-07-20): Runtime #4 was merged as e2f5d0b3 and accepts ADR 0003.

The decision keeps Runtime v0.2 Exec bounded, buffered, unary, non-interactive, generation-bound, and durably replayable. It explicitly rejects treating logs, repeated unary calls, direct node access, or untyped provider extensions as compatible streaming exec. Any future interactive protocol must be a distinct optional/versioned capability with its own ADR, wire schema, and conformance profile proving terminal ownership, bounded bidirectional flow control, ordering and half-close behavior, cancellation/deadline races, reconnect/replay bounds, duplicate-input prevention, restart cleanup, authorization, and leak-free fault behavior.

The README, implementation plan, and deep-test release oracle now carry the same boundary. Post-merge main CI 29717231748 passed both Linux Rust 1.85 and stable jobs.

This completes the streaming-exec ADR decision requested by this issue without publishing a premature API. Keep Runtime #1 open for the remaining provider capability work: Docker still does not advertise even bounded unary Exec, OutputArtifacts, Usage, or Attestation, and output-resource retry/restart evidence remains outstanding.