feat: Add minimal TrustSummary and separate RuntimeTrustAssessment contracts

Parent

Part of #758. Stored and verified by #794, populated from #793/#795/#796 and evaluation reports, and exposed by #408.

Summary

Add a minimal, deterministic trust metadata layer for compiled bundles without turning ContextWeaver into a deployment-policy or enforcement platform.

The canonical bundle contains a recomputable TrustSummary. Runtime checks create a separate RuntimeTrustAssessment; they never rewrite the manifest, lock or bundle identity.

Canonical statuses

Use exactly:

• verified;
• verified_with_warnings;
• degraded;
• unverified;
• invalid.

Examples:

• invalid — component digest mismatch, malformed mandatory contract or inconsistent manifest;
• unverified — structurally intact but mandatory evidence cannot be validated;
• degraded — explicit stale fallback, partial containment or unavailable optional capability;
• verified_with_warnings — optional non-material evidence absent;
• verified — all applicable mandatory evidence and rules validate.

TrustSummary

The manifest stores a compact projection containing:

• contract version;
• ruleset digest;
• status;
• canonical reason codes;
• evidence-set/provenance digests;
• declarative restrictions and freshness summary.

Detailed source coverage, containment, evaluation, provenance and reproducibility reports remain separate content-addressed components.

The loader must recompute the summary from those components and the pinned ruleset. The stored status alone is never sufficient.

TrustRuleset

• selected from agent.yaml;
• identity/version/digest pinned in lock.json;
• canonical copy embedded as a content-addressed bundle component;
• declarative schema only: evidence roles, applicability, requiredness, states, reason codes and known restriction types;
• no Python callbacks, eval, arbitrary expressions, network, environment reads, implicit clock or model calls.

Mandatory evidence unknown/unsupported → unverified. Integrity-critical malformed evidence → invalid. Optional evidence follows the pinned rule outcome.

Registries

Version and pin small registries for:

Reason codes

• stable namespaced identity and immutable meaning;
• default/minimum severity;
• minimum materiality: informational or material;
• bounded context schema and privacy rules;
• deprecation/replacement metadata.

Restriction types

Initial bundle-fact restrictions may include:

• capability_unavailable;
• capability_not_evaluated;
• capability_requires_fresh_source;
• external_resource_required;
• resource_unavailable;
• development_build;
• canonical_backend_required;
• source_coverage_incomplete;
• containment_partial.

Each type defines selector/context schema, materiality and deterministic composition.

Unknown material reason/restriction semantics → unverified; explicitly informational unknown values may be preserved with a warning. Never infer safety from names.

Runtime assessment

RuntimeTrustAssessment is bound to:

• bundle digest;
• capability/operation/phase subject;
• projected restrictions;
• host-supplied satisfaction evidence;
• verifier identities/configuration when material;
• explicit evaluation time where required.

Core verifiers remain pure: schemas, digests, resource integrity, contract compatibility and bundle facts. External systems, credentials and organizational policy are host/plugin responsibilities.

Runtime evidence cannot alter the canonical TrustSummary; it only describes whether current host conditions satisfy applicable restrictions.

Explicit non-goals

Do not add to the MVP:

• production authorization or approval workflows;
• online revocation infrastructure;
• deployment rollback/quarantine/traffic control;
• acknowledgement/escalation stores;
• NTP/cloud trusted-time integration;
• Kubernetes/cloud/IAM adapters;
• an operational policy engine.

These may be investigated later as an optional extension only after compiler adoption evidence.

Acceptance criteria

• versioned TrustSummary, TrustRuleset and runtime-assessment schemas;
• canonical status ordering and deterministic aggregation;
• reason-code and restriction registries with namespaced extension rules;
• recomputation and stored-summary mismatch tests;
• required/optional/unknown evidence compatibility tests;
• capability/phase-specific restriction projection;
• pure core verifier interface and explicit pinned external verifier identity when material;
• runtime assessment cannot mutate bundle/manifest/lock;
• no unrestricted JSON/code execution in rulesets;
• no deployment enforcement subsystem in core;
• #409 can preview the candidate status and #408 exposes canonical plus runtime results separately.

Start by reading the referenced agent.yaml and lock.json contract-selection and pinning requirements, then trace the manifest and bundle components described in the issue. Define the versioned TrustSummary, TrustRuleset, registries, and RuntimeTrustAssessment boundaries before implementing. Done means deterministic recomputation, mismatch and evidence-compatibility coverage, separate runtime results, and no unrestricted rule execution or deployment enforcement.