Problem
aegisctl test-action actually submits the action to the admin API, which records it in the audit chain and (for review decisions) creates an approval queue entry. That is the right behaviour most of the time.
But when someone is iterating on a policy pack and just wants to see "what would happen if I tried this", they do not want to pollute the audit chain or queue with dry runs.
Acceptance criteria
Files to touch
cmd/aegisctl/testaction.go
cmd/aegisctl/testaction_test.go
How to test locally
./bin/aegisctl test-action --dry-run --protocol mcp --tool github.delete_repo --target foo
# Expected: decision=block, but no admin API call, no audit entry, no approval queued
./bin/aegisctl test-action --protocol mcp --tool github.delete_repo --target foo
# Expected: same decision, but audit chain and approval queue should reflect it
Notes
Local evaluation means loading the policy pack from disk and running the toolpolicy engine against the envelope. Look at how cmd/aegisctl/simulate.go and cmd/aegisctl/testaction.go handle local vs remote evaluation.
Problem
aegisctl test-actionactually submits the action to the admin API, which records it in the audit chain and (for review decisions) creates an approval queue entry. That is the right behaviour most of the time.But when someone is iterating on a policy pack and just wants to see "what would happen if I tried this", they do not want to pollute the audit chain or queue with dry runs.
Acceptance criteria
--dry-runtoaegisctl test-actionruns the policy evaluation locally (not against the admin API) and prints the decisionFiles to touch
cmd/aegisctl/testaction.gocmd/aegisctl/testaction_test.goHow to test locally
Notes
Local evaluation means loading the policy pack from disk and running the toolpolicy engine against the envelope. Look at how
cmd/aegisctl/simulate.goandcmd/aegisctl/testaction.gohandle local vs remote evaluation.