e526133f21
Add a coherent set of long-running-agent capabilities, each as a spec section + reference implementation + conformance class, every one metered, attested, and receipt-chained. Sandbox: - §13 Durable run records (C6): the receipt chain IS the resumable run; execute/suspend/resume segments hash-chained; idle energy metered across parks. (sandbox-attest::runrecord) - §14 Environment manifest (C7): devcontainer.json declarative-subset ingestion -> canonical, content-addressed, signed manifest; command/widening and unknown fields refused. (sandbox-attest::manifest) - §5.5 Content-addressed process control (C8): exec allow/deny by BLAKE3 of the binary; denylist absolute, survives rename/move/wrapper. - §15 Warm pools (C9): a claim attributes accrued idle energy to the run (a fast start has a visible joule price); evictions record overhead, not zero. (sandbox-attest::warmpool) - §16 Fleet records (C10): merkle aggregate receipt over per-item runs; log-size membership proofs. (sandbox-attest::fleet) - durable.json cross-impl wire vectors + file-backed verify. JCP: - §4.6 Standing grants (C20): a signed mint policy turns a held grant into bounded, rate-limited, event-triggered children via the attenuation path. (jcp-grant::standing) - §4.7 Checkpoints + amendments (C21): mid-run steering under separation of duties — the agent checkpoints its own state, only the issuer (a distinct principal) may amend, and only to tighten. (jcp-grant::checkpoint) - standing.json cross-impl vectors. Both workspaces green; conformance harnesses pass with no skips; clippy clean. Co-Authored-By: Claude Opus 4.8 <[email protected]>
1.3 KiB
1.3 KiB
Sandbox conformance vectors — v1
The v1 wire vectors. Each file is regenerated by gen_vectors and verified by the harness; see ../README.md and ../VERSIONS.md.
| File | Class | Contents |
|---|---|---|
content_addressing.json |
C1 | byte inputs (hex) → expected b3: content id |
capability.json |
C2 | grant sets → allow/deny decision per query (incl. negatives) |
receipt.json |
C3 | a CPU+GPU receipt → canonical core (hex), content id, sealed JCR-1 envelope (hex), steward key |
attestation.json |
C4 | an S5 attestation → JCS bytes, content id, Ed25519 signature (hex), supervisor key |
tier.json |
C5 | grant set + isolation flags → required tier (S0–S7) |
durable.json |
C6/C7/C10 | a run-record trace → head id; a devcontainer → manifest id; a fleet → merkle root (all b3:) |
negative.json |
C-neg | malformed receipts + attestations a conformant host MUST reject |
confidential.json |
C-tee | SEV-SNP report verify (valid + negatives) + audit-chain check |
The signing keys are fixed test keys embedded in the vector builders (receipt key [3;32], supervisor key [5;32]); the public keys travel in the vector files. These are conformance fixtures, not operational keys.