Pic-standard

Added
- **PIC Canonical JSON v1 spec** — `docs/canonicalization.md` normatively defines PIC-CJSON/1.0: RFC 8785 (JSON Canonicalization Scheme) as the baseline, plus PIC-specific rules for object key ordering, string escaping, number serialization, Unicode handling, boolean/null serialization, lone-surrogate rejection, and the digest-byte rules for `args_digest`, `claims_digest`, `intent_digest`, and attestation-object signed bytes (§8.1–§8.4). Frozen for PIC-CJSON/1.0; edge cases discovered after release are spec-level discussions, not patch-level fixes.
- **Reference canonicalization implementation** — `pic_standard.canonical` module with:
- `canonicalize(value) -> bytes` — PIC-CJSON/1.0 serializer, pure Python stdlib (no runtime dependencies).
- `sha256_hex(value) -> str` — convenience for §8.1 / §8.2 digests.
- `intent_digest_hex(intent) -> str` — §8.3 path: hashes raw UTF-8 bytes of the intent string, explicitly distinct from `sha256_hex` to prevent the common trap of canonicalizing bare strings.
- `CanonicalizationError` — PIC's own exception class, independent of the vendored dependency.
- **Conformance suite (`conformance/`)** — new top-level directory containing:
- 9 canonicalization vectors under `conformance/canonicalization/` covering key ordering (including UTF-16 supplementary-plane trap), array preservation, string escaping (all RFC 8785 named escapes + representative unnamed controls + solidus), number serialization (11 cases across the ECMAScript `Number::toString` branch matrix), booleans/null, and attestation-object / claims-array shapes.
- 4 core-verifier vectors under `conformance/core/` (2 allow, 2 block) pinning `PIC_VERIFIER_FAILED` and `PIC_TOOL_BINDING_MISMATCH` outcomes.
- `conformance/manifest.json` — versioned (`conformance/v0.1`) index of all vectors.
- Per-directory `README.md` files documenting vector format and seeding discipline.
- **Conformance runner** — `conformance/run.py` (`python -m conformance.run`) executes every vector, validates manifest schema strictly (rejects unknown fields and mode/expected mismatches), detects manifest/vector drift, and produces a pass/fail report with CI-friendly exit codes.
- **CI workflow** — `.github/workflows/conformance.yml` runs the conformance suite on every push and pull request as a `PIC Conformance` check, separate from the main CI job.
- **Unit tests** — `tests/test_canonical.py` adds 71 tests covering the conformance vector sweep, §10.1 implementation-local rejection cases (non-finite numbers, non-string keys including the pathological `.encode()`-bearing class, circular references, tuples, non-serializable host types, lone surrogates, integers outside the ±(2^53 − 1) safe range), and the `sha256_hex` ↔ `intent_digest_hex` distinction.
- **Refined attestation object draft** — `docs/attestation-object-draft.md` updated to cite the normative canonicalization spec directly, replace placeholder digests with real byte-verifiable hex values, document the §8.4 signer/verifier contract (both re-canonicalize from the parsed attestation object; raw payload bytes are never signed or verified directly), and link to the conformance vector that pins its worked example.

Changed
- `docs/attestation-object-draft.md` Status banner no longer says the canonicalization spec "does not yet exist"; instead it separates what's frozen in v0.8.0 (canonicalization rules, digest inputs) from what remains DRAFT (field set, freshness semantics, audience semantics).

Vendored
- **Trail of Bits `rfc8785.py`** (v0.1.4, commit `e7bbf8987c484950edfad6cc2a29f69a18920c8e`, Apache-2.0) — vendored at `sdk-python/pic_standard/_rfc8785.py` to provide RFC 8785 number and string serialization. Upstream raw blob SHA-256 `c25bc3a046528482d53bee3487b837f31dd9c05f33e8f13288c7aab320932cec` is pinned in the file header and in `THIRD_PARTY_NOTICES.md` at the repo root. PIC-specific behavior (tuple rejection, lone-surrogate-in-key validation, circular reference detection, `canonicalize`/`sha256_hex`/`intent_digest_hex` public API, exception normalization) lives in `pic_standard.canonical` which wraps the vendored module.

Notes
- **Runtime behavior of existing proposals is unchanged in v0.8.0.** Canonicalization is a new capability exposed through `pic_standard.canonical`; it is not wired into `verify_proposal()` or evidence signing paths. Existing payload-string signatures continue to verify as v0 legacy mode.
- **Wire-up of canonicalization into evidence signing** (attestation-object-backed signatures using `canonicalize(attestation_object)` as the signed bytes per §8.4) is deferred to a future release.
- **Evidence-mode and trust-sanitization-mode conformance vectors** are deferred to v0.8.1+ per the Out of Scope section of the v0.8.0 plan. v0.8.0's conformance suite covers canonicalization mode and core verifier mode only.
- **Cross-implementation conformance** (TypeScript/Go) arrives alongside those reference implementations in Phase 3+; the v0.8.0 conformance suite is deliberately language-neutral (JSON vectors + hex expectations + SHA-256 expectations) so any future language binding consumes the same vectors.

---

Added
- **`strict_trust` pipeline option**: new `PipelineOptions.strict_trust` (default `False`).
When enabled, all inbound `provenance[].trust` values are sanitized to `"untrusted"`
before verification. Evidence verification is the only path to trusted status.
- **Trust deprecation warning**: when a proposal declares `trust:"trusted"` but
effective evidence verification will not run for that proposal, a
`PICTrustFutureWarning` is emitted with migration guidance. In PIC/1.0,
non-sanitizing mode will be legacy and non-conformant.
- **Attestation Object v1 draft**: `docs/attestation-object-draft.md` — non-normative
design document for the canonical minimal signing target (community feedback welcome).
- **Migration guide**: `docs/migration-trust-sanitization.md` — step-by-step guide for
migrating from self-asserted trust to evidence-backed trust.
- `strict_trust` and `key_resolver` parameters in `guard_mcp_tool()`,
`guard_mcp_tool_async()`, and `PICToolNode` for integration-level opt-in.

Changed
- **Pipeline refactor**: `verify_proposal()` now finalizes trust state (sanitization +
evidence verification + trust upgrade) before `ActionProposal` instantiation. This
removes duplicate instantiation/binding and ensures `strict_trust=True` works correctly
with evidence-backed proposals.
- `PICToolNode` constructor now accepts `verify_evidence`, `strict_trust`, `key_resolver`,
`policy`, `proposal_base_dir`, and `evidence_root_dir` for full pipeline configuration.

---

Fixed
- **Import crash on base install**: `import pic_standard.cli` no longer fails
when optional dependencies (`langchain-core`, `mcp`) are not installed.
`integrations/__init__.py` now uses lazy `__getattr__` loading so importing
one integration does not pull in another's dependencies.
- CLI `serve` command import moved inside the handler — `pic-cli verify`,
`pic-cli keys`, etc. no longer trigger any integration imports.

Added
- `docs/spec-status.md` — companion status note for RFC-0001, explaining that
the defensive publication is intentionally preserved with its original SHA-256
fingerprint while the implementation has evolved through v0.7.x.
- `TYPE_CHECKING` imports and `__dir__()` in `integrations/__init__.py` for
IDE/type-checker support.

---

Added
- **`KeyResolver` protocol** — injectable, sync-only interface for trust key resolution.
`get_key(key_id) -> Optional[bytes]` and `key_status(key_id) -> KeyStatus`.
- **`StaticKeyRingResolver`** — zero-I/O resolver backed by a pre-loaded `TrustedKeyRing`.
- `PipelineOptions.key_resolver` — threads custom resolver through the shared pipeline
into `EvidenceSystem`.
- `KeyResolver` and `StaticKeyRingResolver` exported from `pic_standard` public API.
- `tests/test_key_resolver.py` — 7 tests covering resolver protocol, injection,
lazy default semantics, and pipeline threading.

Changed
- **Evidence hot path fix:** `EvidenceSystem` no longer reloads the keyring per signature
item. Default trust resolution is lazy (loaded on first signature verification only).
- `EvidenceSystem.__init__` accepts optional `key_resolver` parameter. When omitted,
the default resolver is constructed lazily via `TrustedKeyRing.load_default()` on
first use — hash-only evidence never triggers keyring loading.
- Deleted `_load_public_key_from_keyring()` module-level function; replaced by
`EvidenceSystem._resolve_public_key()` instance method using the resolver protocol.

Fixed
- Hash-only evidence verification no longer triggers unnecessary keyring file I/O.

---

Changed
- **Shared verification pipeline**: Extracted duplicated verification logic from
MCP guard, LangGraph, and CLI into a single `pipeline.py` module with
`verify_proposal()` as the one function all consumers delegate to.
- All three consumers (MCP guard, LangGraph ToolNode, CLI) now delegate to
`pipeline.verify_proposal()` instead of reimplementing the verification chain.
- **Error code semantics**: `ActionProposal` instantiation / verifier-rule failures
are now reported as `PIC_VERIFIER_FAILED` (instead of `PIC_POLICY_VIOLATION` in
some MCP paths).
- `pic-cli verify` now uses the shared pipeline (`verify_proposal()`), aligning CLI
behavior with MCP/LangGraph verification flow.
- `_debug_enabled()` moved to `errors.py` (shared location).
- `PICEvaluateLimits` canonical home moved to `pipeline.py`.
- `integrations/__init__.py` exports `PipelineOptions`, `PipelineResult`,
`verify_proposal`, and `guard_mcp_tool_async`.

Fixed
- Catch-all in MCP guard wrappers changed from `POLICY_VIOLATION` to
`INTERNAL_ERROR`.
- Evidence imports narrowed from `except Exception` to `except ImportError`.
- Impact resolution now falls back to `expected_tool` when `tool_name` is None.
- Impact enum values normalized to strings before comparison.

Added
- `pipeline.py` — shared verification pipeline with `PipelineOptions`,
`PipelineResult`, and `verify_proposal()`.
- `tests/test_pipeline.py` — 26 tests covering schema, verifier rules, tool
binding, limits, impact resolution, evidence gating, time budget, and result shape.
- `tests/conftest.py` — `make_proposal()` helper and reusable pytest fixtures.
- `_b64decode()` now supports a `strict` mode (default remains permissive for
backward compatibility; strict mode will be used in future canonicalization
tightening).
- Cross-ref comments on `VERIFIER_FAILED` and `POLICY_VIOLATION` in `errors.py`.

---

Added
- **Cordum integration**: Pack for workflow-level PIC verification gating
- Worker topic: `job.pic-standard.verify`
- Workflow routing: `proceed` / `fail` / `require_approval`
- Fail-closed HTTP bridge client (Go)
- Pack source: `cordum-io/cordum-packs` → `packs/pic-standard/`
- `integrations/cordum/` — README, example policy config
- `docs/cordum-integration.md` — full integration guide with architecture diagram

---