Skip to content

docs(#1760): add effective_on review checklist to AGENTS.md #1761

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
fullsend-ai-coder wants to merge 1 commit into
base: main
Choose a base branch
from
Open

docs(#1760): add effective_on review checklist to AGENTS.md #1761

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
11 changes: 11 additions & 0 deletions AGENTS.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -59,6 +59,17 @@ These files have `effective_on` dates — rules with future dates are warnings,
| Add a shared library function | `policy/lib/` (must have test coverage) |
| Fetch and parse an OCI blob as JSON | Use `oci.parsed_blob(ref)` from `data.lib.oci`, not `json.unmarshal(ec.oci.blob(ref))` directly. A Regal lint rule (`prefer-parsed-blob`) enforces this. |

## Review Checklist for New Policy Rules

- **`effective_on` date required:** New deny/warn rules MUST include an
`effective_on` date in their rule data entry (in `example/data/`) to
provide a migration window. Rules without `effective_on` enforce
immediately on deployment, which can break existing builds without
warning. Check that the corresponding rule data file has a future

@fullsend-ai-review fullsend-ai-review Bot Jun 24, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[medium] Technical accuracy in documentation

The checklist incorrectly directs reviewers to check the corresponding rule data file in example/data/ for the effective_on date. The effective_on that controls deny-vs-warn behavior comes from METADATA annotations in .rego files (via lib.time.when(chain)), not from data files. Over 20 existing rules use # custom: effective_on: in their METADATA block. The data-level effective_on in example/data/ serves a different purpose (data versioning). This will lead reviewers to check the wrong location.

Suggested fix: Rewrite to distinguish two mechanisms: (1) New .rego deny/warn rules must include a future effective_on in their METADATA annotation (# custom: effective_on: ). (2) New data entries in example/data/ should include effective_on for versioning.

`effective_on` date for every new rule being added.
- **Collection membership:** New rules must be added to the appropriate
collection(s) in `policy/*/collection/` or they won't be evaluated.

## PR Conventions

Conventional commits are encouraged. Run `make ci` before pushing. CI runs on every PR via
Expand Down
Loading