opentine v0.9.1: signed claims, scoped trust, hardened capture

opentine v0.9.1 is available on GitHub and PyPI. It brings signed repository claims into the operational workflow and hardens the paths that capture, store, inspect, and exchange agent history.

A claim can carry a signature

An attestation records a claim about a run. A signer label alone is self-asserted. The v0.9 signing surface binds the target, claim, signer, evidence IDs, and signature header to an HMAC-SHA256 or Ed25519 key.

Signing is opt-in. Existing unsigned attestations retain their object IDs and verify as unsigned. Integrity checks establish that stored content matches its identity; trusted signatures establish which key authenticated a claim.

Verify the approval you intended

v0.9.1 adds signer and claim selection to tine repo-verify. A scoped gate passes when at least one selected attestation verifies. Other attestations neither pass nor block that gate.

tine repo-verify heads/main --repo . --key-env OPENTINE_SIGNING_KEY --signer release-team --claim '{"approved":true}' --json

The key comes from the operator environment. JSON results expose the claim and whether each attestation was selected. Signed evaluations rank first in repository search, with score_signed making signature presence visible. Trusted-key verification remains the authenticity check.

Capture follows the output contract

Text-mode agent stdout stays text. Request JSON explicitly for structured Codex capture:

tine run --harness codex --harness-arg --json --prompt "Inspect this repo" --save codex.tine

JSON-shaped prose cannot become fabricated tool calls or charges. The release strengthens credential redaction, sanitizes terminal and MCP messages, bounds imports before parsing, tightens git and filesystem policies, and refuses unsupported Python isolation backends.

The format is published

The specification describes envelopes, object IDs, packs, refs, canonical JSON, and signatures. It ships 523 conformance vectors across 25 families, including cases implementations must reject.

Portable v2 orders object keys by code point; v3 uses UTF-16 code units. Attestation signatures use the v2 canonicalizer over a v3 object. Follow the specification and vectors when implementing readers or verifiers.

Upgrade without changing formats

python -m pip install --upgrade "opentine==0.9.1"

Portable artifacts remain .tine v2 and repository objects remain v3. Files and repositories written since v0.3 remain readable. v0.9.1 writes no format that v0.9.0 cannot read.

Review the upgrade guide, signed attestation reference, and official changelog before updating automation.