| Filename | Latest commit message | Latest commit date |
|---|---|---|
|
Some checks failed
repository checks / lockfiles, advisories, tests in CI, workflow hygiene, spec and section references, public text (push) Has been cancelled
An approval was a signature over the call's context digest: action, resource, caller and content hash. Nothing in it named which instance of the call it answered, so the same payment made again, or the same approval presented twice, proceeded on one consent. - `approve` now signs the context digest and the hold: the content id of the `held` receipt the engine sealed for that call. `Decided::hold` carries it. The message is domain-separated (`jcp-policy-approval-v2\0`). - `PolicyEngine::decide` accepts an approval only when its signature verifies and the hold it names is one this engine sealed for this exact call and has not yet consumed. Accepting it consumes the hold. A replayed approval, or the identical call made again, is held anew under a fresh hold. - The approved receipt carries `approves`, the hold it consumed, so the chain itself shows which consent let which call through. Tests: an approval answers one hold once (a replay is held, a forged hold refused, a fresh hold takes a fresh approval), and an approved receipt names its hold. Each of the three mechanisms was switched off in turn: not consuming the hold, not checking the hold is open and this call's, and not signing the hold. Each turned a test red. The example shows the replay held. INGEST.md records the personal-agent and workflow-automation capabilities being added across the standards, each placed with the standard that owns it, and what already exists and is not re-added. Co-Authored-By: Claude Opus 5.5 <[email protected]> |
||
| .. | ||
| policy.rs | ||