Add execution receipt proof scopes

[GsCommand]

Motivation

• Separate execution and settlement attestations so an agent signature cannot be interpreted as attesting payment settlement.
• Allow a single receipt to contain multiple attestations while requiring each proof to declare exactly which top-level fields it covers.
• Provide a public-facing schema-level model that commits to private settlement data without exposing payee addresses or raw transaction hashes.

Description

• Add a new execution schema family and schema clas.execution.receipt.v1 at schemas/execution/execution.receipt.schema.json which requires proofs[] and enforces scoped proof shapes.
• Constrain execution proofs to exactly `[

---

Codex Task

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 2af1cd8bb9

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Require proof hashes on execution proofs

When a clas.execution.receipt.v1 receipt is accepted by this schema, the execution proof is only required to carry scope, canonicalization, and signature metadata, but no payload hash. That conflicts with the repository rule in docs/schema-rules.md that every CLAS receipt proof includes a proof.hash SHA-256 digest, so schema-valid execution receipts will not expose the canonical payload hash that existing verification flows expect before signature verification.

Useful? React with 👍 / 👎.

[chatgpt-codex-connector]

Enforce SHA-256 digest syntax for receipt hashes

The shared sha256Uri accepts any non-empty suffix, so receipts with values like sha256:not-a-digest pass for action.input_hash, action.output_hash, and settlement.payee_commitment. In any flow that treats schema validation as the shape check before canonicalization or selective disclosure, these malformed commitments cannot be used as SHA-256 digests; existing CLAS schemas use ^sha256:[a-fA-F0-9]{64}$ for this reason.

Useful? React with 👍 / 👎.

[chatgpt-codex-connector]

Reject all raw transaction-hash forms

This only rejects the exact lowercase 0x spelling, so a public settlement receipt can still pass schema validation with a bare 64-character hex transaction hash, or the same hash written with 0X, in payment_ref. In contexts where this schema is the privacy gate before publishing receipts, those values still expose the raw public transaction hash that the field description says must not be allowed.

Useful? React with 👍 / 👎.

[chatgpt-codex-connector]

Add the versioned execution schema target

This schema advertises a versioned $id, but the commit only adds it under schemas/execution; I checked the versioned tree and there is no schemas/v1.0.0/execution/execution.receipt.schema.json target for this URL. In environments that resolve schema IDs through the published /schemas/v1.0.0/... path, receipts using clas.execution.receipt.v1 cannot fetch the schema even though the root manifest now lists the family.

Useful? React with 👍 / 👎.