refactor: implementing rule traits, rulematch enum

This commit is contained in:
kevin zhao
2025-11-11 19:22:31 -05:00
parent 4ca1834eac
commit 755331425e
7 changed files with 111 additions and 77 deletions

View File

@@ -1,17 +1,16 @@
# codex-execpolicy2
## Overview
- Policy engine and CLI built around `prefix_rule(pattern=[...], decision?, match?, not_match?, id?)`.
- Policy engine and CLI built around `prefix_rule(pattern=[...], decision?, match?, not_match?)`.
- This release covers only the prefix-rule subset of the planned execpolicy v2 language; a richer language will follow.
- Tokens are matched in order; any `pattern` element may be a list to denote alternatives. `decision` defaults to `allow`; valid values: `allow`, `prompt`, `forbidden`.
- `match` / `not_match` supply example invocations that are validated at load time (think of them as unit tests). `id` is optional; auto-generated if omitted.
- `match` / `not_match` supply example invocations that are validated at load time (think of them as unit tests).
- The CLI always prints the JSON serialization of the evaluation result (whether a match or not).
## Policy shapes
- Prefix rules use Starlark syntax:
```starlark
prefix_rule(
id = "rule_id", # optional; autogenerated if omitted
pattern = ["cmd", ["alt1", "alt2"]], # ordered tokens; list entries denote alternatives
decision = "prompt", # allow | prompt | forbidden; defaults to allow
match = [["cmd", "alt1"]], # examples that must match this rule
@@ -27,9 +26,10 @@ prefix_rule(
"decision": "allow|prompt|forbidden",
"matched_rules": [
{
"rule_id": "<rule id>",
"matched_prefix": ["<token>", "..."],
"decision": "allow|prompt|forbidden"
"PrefixRuleMatch": {
"matched_prefix": ["<token>", "..."],
"decision": "allow|prompt|forbidden"
}
}
]
}