Publish execution receipt schema files#385
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 658f3ba86b
ℹ️ 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".
| "chain_id": { "type": ["string", "null"], "minLength": 1 }, | ||
| "verb": { "type": "string", "minLength": 1 }, | ||
| "agent": { "type": "string", "minLength": 1 }, | ||
| "action": { "type": "string", "minLength": 1 }, |
There was a problem hiding this comment.
Both the scoped execution docs and the execution receipt demo model valid clas.execution.receipt.v1 receipts with action as an object containing fields like name and input_hash, but this newly published schema only accepts a non-empty string here. Consumers who fetch the public schema linked from the docs and validate those advertised receipt shapes will reject them before any proof-scope checks run, so the schema should accept the documented object shape or the examples should be changed.
Useful? React with 👍 / 👎.
| "if": { "properties": { "type": { "const": "settlement" } }, "required": ["type"] }, | ||
| "then": { "properties": { "covers": { "contains": { "const": "settlement" } } } } |
There was a problem hiding this comment.
The docs describe the settlement signer as covering only receipt_id and settlement, but this rule only requires covers to contain settlement; a settlement proof with covers: ["receipt_id", "settlement", "action"] would still be schema-valid. That lets a settlement authority appear to attest execution fields despite the separate trust-boundary model, so settlement proof coverage should be constrained to the allowed fields.
Useful? React with 👍 / 👎.
| "proofs": { | ||
| "type": "array", | ||
| "minItems": 1, | ||
| "items": { "$ref": "#/$defs/proof" } |
There was a problem hiding this comment.
Because proofs only requires one item of either proof type, a clas.execution.receipt.v1 receipt with only a settlement proof currently validates even though the documented valid states are execution-only or execution plus settlement. In that scenario, consumers using this public schema would accept an execution receipt that has no agent/runtime attestation for what actually executed, so the array should require at least one type: "execution" proof.
Useful? React with 👍 / 👎.
| "required": ["payment_ref", "payee_commitment"], | ||
| "properties": { | ||
| "payment_ref": { "type": "string", "minLength": 1 }, | ||
| "payee_commitment": { "type": "string", "pattern": "^sha256:[A-Za-z0-9+/=_:-]+$" }, |
There was a problem hiding this comment.
The schema describes payee_commitment as a sha256: commitment, but this pattern accepts arbitrary non-empty base64-ish text such as sha256:not_a_digest. When a public receipt includes malformed commitment data, schema validation would still pass even though selective disclosure later cannot verify a real SHA-256 commitment, so this should enforce an actual digest format and length.
Useful? React with 👍 / 👎.
| "if": { "properties": { "type": { "const": "execution" } }, "required": ["type"] }, | ||
| "then": { "properties": { "covers": { "not": { "contains": { "const": "settlement" } } } } } |
There was a problem hiding this comment.
For type: "execution", this rule only prevents settlement from being covered; it still validates an execution proof whose covers is just ["receipt_id"]. In that case a receipt would pass the public schema without the agent/runtime signature covering verb, agent, or action, which undermines the documented execution attestation scope, so the execution branch should require the expected execution fields as well.
Useful? React with 👍 / 👎.
| "type": "object", | ||
| "additionalProperties": true, | ||
| "required": ["payment_ref", "payee_commitment"], |
There was a problem hiding this comment.
The privacy warning explicitly says not to publish fields such as settlement.stealth_address, but additionalProperties: true makes those fields schema-valid in the newly published public receipt schema. Builders using this schema as their pre-publication gate could therefore leak private payment linkage while still passing validation, so the public settlement object should be closed or explicitly reject known sensitive fields.
Useful? React with 👍 / 👎.
1 participant
Motivation
clas.execution.receipt.v1but the canonical execution schema and manifest were not published under the public site, so consumers cannot fetch the schema at/schemas/execution/....executionfamily alongside the existingtrust-verificationfamily to keep public schemas discoverable and in sync.Description
public/schemas/execution/execution.receipt.schema.jsonand the execution manifest atpublic/schemas/execution/manifest.jsonto publishclas.execution.receipt.v1publicly.public/schemas/index.jsonto expose theexecutionfamily and point to/schemas/execution/manifest.json.scripts/sync-clas-schemas.shto copy bothtrust-verificationandexecutionfamilies from the CLAS source intopublic/schemas.public/docs/scoped-execution-settlement.htmlto link directly to/schemas/execution/execution.receipt.schema.jsonand/schemas/execution/manifest.jsonand add a test filetests/execution-schema-publication.test.jsthat asserts the files and index entry exist.Testing
npm test, and the full test suite completed successfully (147 tests passed, 0 failed).npm run check:links, and the site link check reported "All local links/assets resolved" across HTML files.npm run build:clas-schemasbut thebuild:clas-schemasscript is not defined inpackage.json.bash -n scripts/sync-clas-schemas.sh(syntax OK), parsed the new JSON files withnodeto ensure they are valid, and rangit diff --checkwith no issues.Codex Task