Bumps the protect-mcp pin from 0.5.5 to 0.7.4 in both review-agent-governance and protect-mcp hooks so the PreToolUse `evaluate` and PostToolUse `sign` verbs resolve and the governance gate runs fail-closed (deny -> exit 2). Rewrites the test suite (init --dir, receipts.jsonl, v2 receipt schema, real Cedar entity shape); 8/8 pass. Verified locally: verbs function on 0.7.4, deny path exits 2, make validate STRICT=1 clean.
Closes#601.
Closes the version-pinning suggestion from @wshobson on #494. The
tamper-detection test in plugins/protect-mcp/test/run-tests.sh
previously called `npx protect-mcp@latest` and `npx @veritasacta/verify`
with no version constraint, meaning an upstream npm publish could
flip the test green or red without any repo-side signal. Pinning
eliminates that.
Changes
───────
- plugins/protect-mcp/hooks/hooks.json: 2 x
protect-mcp@latest -> protect-mcp@0.5.5
(PreToolUse evaluate + PostToolUse sign)
- plugins/protect-mcp/test/run-tests.sh:
6 x protect-mcp@latest -> protect-mcp@0.5.5
3 x @veritasacta/verify -> @veritasacta/verify@0.3.0
(the four PreToolUse test invocations, keygen, sign, plus the two
verify calls in tests 7 and 8)
- Header comment at the top of run-tests.sh now mentions the pinned
@veritasacta/verify version for clarity.
What is NOT pinned
──────────────────
README.md and SKILL.md references remain as `npx protect-mcp@latest`
and `npx @veritasacta/verify`. Those are documentation of the pattern
a user should use in their own project, and "latest" is the right
advice for that audience. The test infrastructure is the only
executed path where pinning matters for reproducibility.
How to bump
───────────
When you want to update (e.g., protect-mcp publishes 0.6.0 with a
breaking change to --input handling), update both files together:
perl -i -pe 's/protect-mcp\@0\.5\.5/protect-mcp\@0.6.0/g' \
plugins/protect-mcp/hooks/hooks.json \
plugins/protect-mcp/test/run-tests.sh
Then re-run ./plugins/protect-mcp/test/run-tests.sh to confirm the
tamper-detection guard still passes before merging.
This PR does NOT touch review-agent-governance or signed-audit-trails
because those plugins are still in review (#495, #496). Once they
land, a follow-up PR will pin them too.
Tests
─────
- python3 -m json.tool hooks.json passes
- bash -n run-tests.sh passes
- No other files touched; no marketplace.json changes (avoids conflict
with #495 and #496)
Follow-up to #484 closing the test-plan commitment. Adds a
plugins/protect-mcp/test/ directory with:
- Six deterministic fixtures covering PreToolUse (allow + deny paths
on Read / Bash safe / Bash destructive / Write) and PostToolUse
(receipt signing input)
- A Cedar test policy exercising both permit and forbid semantics
- An expected receipt-schema.json (JSON Schema draft-07) pinned to
draft-farley-acta-signed-receipts required fields
- run-tests.sh: full round-trip, requires node >= 18 and python3.
Eight tests covering evaluate (permit/forbid exit codes), sign
(receipt file produced), schema conformance, verify (valid + tamper
detection).
- verify-fixtures.sh: static fixture validation, python3 only, safe
to run in sandboxed CI without network access.
- README.md explaining the layout, how to run, and the exit-code
convention (including 77 = autotools "skip" for missing tools).
The critical regression guard is test 8: flipping the `decision` field
in a signed receipt MUST invalidate the Ed25519 signature, so
`@veritasacta/verify` MUST exit 1. This locks in the tamper-detection
property that the plugin claims.
No changes to the plugin itself. No new runtime dependencies. No
changes to marketplace.json or hooks.json.
TJF