Define destination capability snapshots in ASIF 0.4

[LevinGuy]

ASIF 0.4 makes destination fingerprints reproducible: reports supply a versioned, immutable capability snapshot and bind destination-dependent assessments to its components. Earlier reports hashed unspecified placeholder bytes, preventing consumers from reproducing the fingerprint or detecting invalidation.

Closes #4.

Release target: ASIF 0.4, portable continuation and destination reports 0.2, local reference package 0.4.0. The new snapshot format starts at 0.1. Migration guidance covers 0.3 to 0.4, including the tool-call, task, action-specific prerequisite and destination snapshot changes.

Normative proposal / RFC

asif.destination-capabilities/0.1 defines runtime identity/revision, supported features, observation/expiry, producer/evaluation mode and component identities, versions, non-secret revisions and availability. Models, services/accounts, workspaces and operations have required typed facts. Tool/configuration/policy/environment/native state uses defined opaque revision tokens that must change with relevant state; tokens do not replace compatibility evidence.

Reports supply exact UTF-8 snapshot bytes as canonical padded base64, byte count, observation evidence reference and SHA-256 of decoded bytes. No canonicalization or implicit reserialization occurs. Invalid bytes, duplicate keys, mismatched hashes/counts, missing evidence, wrong identities and inconsistent/expired intervals are refused. Unknown formats/versions and explicitly unavailable evidence produce unsupported results. Snapshots are bounded to 1 MiB.

Every assessment records component IDs. Supported/adapted destination subjects require available components of the corresponding kind. Validators compare dependency versions, model budgets/capabilities, service identities/access, workspace roots/path bindings and recovery identities. Source hashes and action-specific blockers remain independently enforced.

Any material destination change invalidates the whole report. validate-report --current-capabilities <snapshot> compares caller-supplied current bytes; it does not probe or authenticate a destination. Operational authorization remains false.

Compatibility, alternatives and privacy

Old fingerprint-only reports must be replaced with newly assessed reports. Preserve immutable historical captures/reports and their original versions; real-data migration emits a derived capture and a new assessment. The current validators reject older/future core, profile and report contracts. Current synthetic fixtures and their dependent hashes/signatures are regenerated for 0.4.

Supplied bytes avoid canonicalization disagreements and arbitrary network retrieval. Opaque fingerprints alone would leave the original interoperability gap. Whole-report invalidation is conservative and reproducible; selective reuse needs a separately specified dependency/evidence model.

Snapshots prohibit credentials and credential hashes. They contain non-secret identities, scopes, logical handles and revision tokens. Producer trust, live observation and writer coordination remain integration responsibilities. All supplied scenarios are synthetic and do not establish independent interoperability or live continuation.

Validation

• Shared continuation corpus: 119 cases passed, including invalid versus unsupported outcomes, changed capabilities and version refusal.
• Python reference: 135 checks; schema: 30 checks; 12 core examples and 5 negative checks passed.
• TypeScript typecheck and 237 tests passed.
• Python/TypeScript CLI and package exchange: 15 checks passed.
• Four fixed exact-byte hash vectors checked in Python/TypeScript and cross-checked with shasum -a 256; original vector bytes remain unchanged.
• Documentation: 128 objects, 140 validated examples, freshness, links and strict MkDocs build passed.
• git diff --check passed.