feat(contracts): add result envelope v1 - #321
Conversation
![baz-reviewer[bot]](https://avatars.githubusercontent.com/in/933528?s=60&v=4){kind=small}
| if (executorBinding) { | ||
| const operation = document.invocation.operation; | ||
| if (!executorBinding.skill.clawsec.provides.includes(operation)) { | ||
| addError( | ||
| errors, | ||
| "RESULT_OPERATION_NOT_DECLARED", | ||
| "/invocation/operation", | ||
| `executor metadata does not declare operation ${operation}`, | ||
| ); | ||
| } | ||
|
|
||
| const harnessVersion = document.invocation.harness.version; |
There was a problem hiding this comment.
Duplicate version-range checks
validateBoundResultEnvelope repeats the same semver-range gate for executorBinding and subjectBinding, so the bound-validation path carries two copies of the version logic and any policy change has to be updated twice — should we move that check into a small local helper in scripts/ci/validate_clawsec_result_envelope.mjs?
Want Baz to fix this for you? Activate Fixer
Other fix methods
Prompt for AI Agents
Before applying, verify this suggestion against the current code. In
scripts/ci/validate_clawsec_result_envelope.mjs around lines 467-508 inside
validateBoundResultEnvelope, the harness version support-range check is duplicated for
executorBinding and subjectBinding with only the binding source and error code/path
differing. Refactor by extracting a small local helper function (e.g.,
validateHarnessVersionSupport) that takes (binding, label, errorCode, errorPath) and
encapsulates the shared gate: harnessVersion !== null && isStrictSemver(harnessVersion)
&& !versionIsInRange(harnessVersion, binding.skill.clawsec.supported_harness) &&
!SAFE_REFUSAL_OUTCOMES.has(document.outcome). Then call this helper in both places to
ensure the logic lives in one place and behavior remains identical.
| function addError(errors, code, errorPath, message) { | ||
| const candidate = { | ||
| code: sanitizeDiagnosticText(code), | ||
| path: sanitizeDiagnosticText(errorPath || "/"), | ||
| message: sanitizeDiagnosticText(message), |
There was a problem hiding this comment.
Duplicated validator CLI plumbing
addError is duplicating the sorting, JSON-output, and exit-code plumbing already in scripts/ci/validate_clawsec_metadata.mjs:625-718, so changes to truncation, formatting, or CLI flags have to be made in two validators — should we move that shared logic into a helper module and keep only the result-specific checks here?
Want Baz to fix this for you? Activate Fixer
1 participant
User description
Summary
clawsec.result/v1execution summary.Design boundary
This is only the base execution-report contract. A valid result reports what an executor claims happened; it is not an installation plan, receipt, authorization, attestation, advisory proof, guardian evidence, or suite aggregation proof.
Bound success therefore returns
binding: "exact_metadata"butauthorization: "unverified". Detailed evidence belongs in later typed composition, advisory, plan, receipt, and guardian contracts.This PR intentionally contains no skill implementations, documentation changes, workflows, release changes, store publication, advisory state, receipt schema, suite composition, or guardian evidence. The NanoClaw fixtures are contract examples, not a NanoClaw v2 runtime-support claim.
Security behavior
skill.jsonbytes by SHA-256.nanoclaw.checkoutscope for NanoClaw package operations and identify the subject's declared host package tree for successful or confirmation results.Remote validation
Tested from a fresh isolated remote checkout of exact base commit
8216ac59ad01a3841416cd6cdbf97e939e686ebf, with SHA-256 parity for every changed file:npm run test:result-envelope-contractnpm run test:metadata-contractsnode scripts/test-skill-lifecycle-semver.mjsnpx eslint . --ext .ts,.tsx,.js,.jsx,.mjs --max-warnings 0npx tsc --noEmitnpm run buildgit diff --checkAn adversarial near-1-MiB, 9,000-effect input is rejected in roughly 0.1–0.15 seconds after removing the redundant superlinear object-uniqueness check. Three independent final audits reported no remaining P0/P1/P2 findings.
Stack and release status
Generated description
Below is a concise technical summary of the changes proposed in this PR:
Define the closed
clawsec.result/v1execution envelope, along with theresult-v1schema and supporting registries for outcomes, reason codes, CLI exit codes, and operation/effect policy. Add thevalidate_clawsec_result_envelopevalidator andtest-skill-result-envelope-contractharness to enforce exact metadata binding, invocation/context checks, parser hardening, and synthetic coverage across the supported harnesses and roles.Modified files (5)
Latest Contributors(2)
clawsec.result/v1envelope and the registries that map outcomes, reason codes, exit codes, and per-operation effect policy.Modified files (5)
Latest Contributors(1)