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]>
16 lines
1.3 KiB
Markdown
16 lines
1.3 KiB
Markdown
# Sandbox conformance vectors — v1
|
||
|
||
The v1 wire vectors. Each file is regenerated by `gen_vectors` and verified by the harness; see [`../README.md`](../README.md) and [`../VERSIONS.md`](../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.
|