spec: FR/NFR oracle + acceptance test skeletons#74
Conversation
|
Warning You have reached your daily quota limit. Please wait up to 24 hours and I will start processing your requests again! |
|
CodeAnt AI is reviewing your PR. |
Thanks for using CodeAnt! 🎉We're free for open-source projects. if you're enjoying it, help us grow by sharing. Share on X · |
|
Warning Review limit reached
More reviews will be available in 49 minutes and 54 seconds. Learn how PR review limits work. Your organization has run out of usage credits. Purchase more credits in the billing tab to continue. ⌛ How to resolve this issue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based credits. 🚦 How do rate limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (15)
✨ Finishing Touches🧪 Generate unit tests (beta)
✨ Simplify code
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
| @@ -0,0 +1,6 @@ | |||
| @pending | |||
| Feature: FR-7 Delegation pipeline | |||
There was a problem hiding this comment.
Suggestion: Update the feature title to include a repository-compliant FR trace ID in the FR-XXX-NNN format so the acceptance test is traceable by the quality gate. [custom_rule]
Severity Level: Minor
Why it matters? 🤔
The repository rule requires FR references in the FR-XXX-NNN format for test traceability.
This feature title only contains FR-7, which does not match the required pattern, so the violation is real.
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** docs/specs/acceptance/FR-7-delegate.command.feature
**Line:** 2:2
**Comment:**
*Custom Rule: Update the feature title to include a repository-compliant FR trace ID in the `FR-XXX-NNN` format so the acceptance test is traceable by the quality gate.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix| @@ -0,0 +1,6 @@ | |||
| @pending | |||
| Feature: FR-7 Delegation pipeline | |||
| Scenario: Pending -- delegate asks with local fast path and cache | |||
There was a problem hiding this comment.
Suggestion: Add an FR trace reference to the scenario name (or an equivalent scenario-level trace marker) using the FR-XXX-NNN format so the new test case has explicit requirement linkage. [custom_rule]
Severity Level: Minor
Why it matters? 🤔
The rule requires new test cases to include an FR trace marker, requirement annotation, docstring trace, or FR-based test name.
This scenario name has no FR-XXX-NNN reference or equivalent trace marker, so the suggestion identifies a real violation.
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** docs/specs/acceptance/FR-7-delegate.command.feature
**Line:** 3:3
**Comment:**
*Custom Rule: Add an FR trace reference to the scenario name (or an equivalent scenario-level trace marker) using the `FR-XXX-NNN` format so the new test case has explicit requirement linkage.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix| @@ -0,0 +1,8 @@ | |||
| @pending | |||
| Feature: FR-9 Exec TOCTOU protection | |||
There was a problem hiding this comment.
Suggestion: Update this test artifact to include a valid FR-XXX-NNN trace reference (for example in the feature title or an explicit trace tag) so it satisfies the repository's FR traceability requirement. [custom_rule]
Severity Level: Minor
Why it matters? 🤔
The repository rule requires FR-XXX-NNN references in test names, markers, tags, or docstrings. This feature file only contains FR-9, which is not the required trace format, so the suggestion correctly identifies a real traceability violation.
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** docs/specs/acceptance/FR-9-exec-tamper.command.feature
**Line:** 2:2
**Comment:**
*Custom Rule: Update this test artifact to include a valid `FR-XXX-NNN` trace reference (for example in the feature title or an explicit trace tag) so it satisfies the repository's FR traceability requirement.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix| @@ -0,0 +1,8 @@ | |||
| @pending | |||
| Feature: FR-11 Policy edit commands | |||
There was a problem hiding this comment.
Suggestion: Replace the shorthand requirement reference with a full FR-XXX-NNN trace (or add an explicit FR trace tag) so this acceptance test complies with the repository FR traceability format. [custom_rule]
Severity Level: Minor
Why it matters? 🤔
The repository rule requires FR-XXX-NNN references in test names, markers, tags, or docstrings. This feature file only uses the shorthand FR-11, which does not match the required FR trace format, so the suggestion identifies a real violation.
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** docs/specs/acceptance/FR-11-policy-edit.command.feature
**Line:** 2:2
**Comment:**
*Custom Rule: Replace the shorthand requirement reference with a full `FR-XXX-NNN` trace (or add an explicit FR trace tag) so this acceptance test complies with the repository FR traceability format.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix| @@ -0,0 +1,6 @@ | |||
| @pending | |||
| Feature: FR-2 Manifest layer discovery | |||
There was a problem hiding this comment.
Suggestion: Replace the non-canonical FR reference with at least one traceable FR-XXX-NNN ID (for example in the feature title or a trace tag) so this acceptance test satisfies repository FR traceability rules. [custom_rule]
Severity Level: Minor
Why it matters? 🤔
This acceptance test file is intended to satisfy FR traceability rules, but the only requirement reference in the feature title is FR-2, which is not in the required FR-XXX-NNN style mentioned by the repository rule. That makes the suggestion a real rule violation.
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** docs/specs/acceptance/FR-2-manifest.command.feature
**Line:** 2:2
**Comment:**
*Custom Rule: Replace the non-canonical FR reference with at least one traceable `FR-XXX-NNN` ID (for example in the feature title or a trace tag) so this acceptance test satisfies repository FR traceability rules.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix| Given a repository fixture with layered policy files | ||
| When I run `policyctl resolve --harness forge --domain devops` | ||
| Then I should receive JSON with keys policy_hash, scope_chain, policy, source_files, resolved_at | ||
| And final decision should be emitted via JSON mode |
There was a problem hiding this comment.
Suggestion: The scenario asserts that policyctl resolve emits a final decision, but the resolve command only returns resolution metadata (policy hash, scope chain, merged policy, source files, timestamp, etc.) and does not compute authorization decisions. This creates an API contract mismatch and will make the acceptance test fail once implemented. Update this step to assert only resolve output fields, or switch to an evaluate/intercept command if decision output is required. [api mismatch]
Severity Level: Major ⚠️
- ❌ FR-1 resolve acceptance test fails against CLI behavior.
- ⚠️ Confuses resolve versus evaluate responsibilities in SPEC.
- ⚠️ Misleads consumers expecting decisions from resolve output.Steps of Reproduction ✅
1. Inspect the acceptance spec at
`docs/specs/acceptance/FR-1-resolve.command.feature:3-7`, where the scenario for FR-1
includes the step on line 7: `And final decision should be emitted via JSON mode`,
implying that `policyctl resolve` returns a decision.
2. Open the oracle specification at `docs/specs/SPEC.md:11-25`, which defines FR-1 as
"`policyctl resolve` SHALL output a resolved payload containing `policy_hash`,
`scope_chain`, `policy`, `source_files`, and `resolved_at`" and separately defines FR-4 as
"`policyctl evaluate` SHALL return the policy decision and a decision summary", showing
that decisions belong to `evaluate`, not `resolve`.
3. Examine the CLI implementation at `cli/src/policy_federation/cli.py:10-20` where
`resolve_command(args: argparse.Namespace)` calls `resolver.resolve(...)` and then
`_emit_json(result)`; this command's JSON output is exactly the dictionary returned by
`resolver.resolve`.
4. Inspect `cli/src/policy_federation/resolver.py:4-80`, where `resolve(...)` returns a
payload containing `policy_hash`, `scope_chain`, `policy`, `authorization_summary`,
`policy_contract_versions`, `contract_count`, `conflicts`, `resolved_at`, `source_files`,
and `extensions`, but no `decision` or `final_decision` field; thus, when the FR-1
acceptance scenario is implemented and run against `policyctl resolve --harness forge
--domain devops`, the step asserting a final decision in JSON will fail because the
command never produces authorization decisions.(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** docs/specs/acceptance/FR-1-resolve.command.feature
**Line:** 7:7
**Comment:**
*Api Mismatch: The scenario asserts that `policyctl resolve` emits a final decision, but the resolve command only returns resolution metadata (policy hash, scope chain, merged policy, source files, timestamp, etc.) and does not compute authorization decisions. This creates an API contract mismatch and will make the acceptance test fail once implemented. Update this step to assert only resolve output fields, or switch to an evaluate/intercept command if decision output is required.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix| Feature: FR-7 Delegation pipeline | ||
| Scenario: Pending -- delegate asks with local fast path and cache | ||
| Given a command that can be decided by local-fast | ||
| When I run `policyctl intercept --harness forge --domain devops --action write --command "echo hi" --ask-mode delegate` |
There was a problem hiding this comment.
Suggestion: The command uses an unsupported --ask-mode value (delegate), so argparse will reject the invocation before the scenario can test delegation behavior. Use a valid ask mode (from the CLI choices) and model delegation behavior via the scenario setup/assertions instead of an invalid flag value. [api mismatch]
Severity Level: Major ⚠️
- ⚠️ FR-7 delegation acceptance spec cannot run as written.
- ⚠️ Delegation behavior untested due to CLI parse failure.Steps of Reproduction ✅
1. Inspect the FR-7 acceptance spec at
`docs/specs/acceptance/FR-7-delegate.command.feature:5`, which defines the step `When I
run \`policyctl intercept --harness forge --domain devops --action write --command "echo
hi" --ask-mode delegate\``.
2. Open the CLI definition at `cli/src/policy_federation/cli.py:651-668`, where
`intercept_parser = sub.add_parser("intercept")` and
`intercept_parser.add_argument("--ask-mode", choices=["fail", "allow", "prompt"],
default="fail")` define the allowed `--ask-mode` values.
3. Run the exact command from the FR-7 spec (either manually from a shell or via any
future Cucumber step harness that shells out to `policyctl`): `policyctl intercept
--harness forge --domain devops --action write --command "echo hi" --ask-mode delegate`.
4. Observe that `argparse` in `cli.py` rejects `delegate` as an invalid `--ask-mode`
choice (since only `fail`, `allow`, and `prompt` are permitted), raising `SystemExit`
before `intercept_command_cli` is invoked, so the FR-7 scenario never exercises delegation
behavior or asserts a deterministic delegate result.(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** docs/specs/acceptance/FR-7-delegate.command.feature
**Line:** 5:5
**Comment:**
*Api Mismatch: The command uses an unsupported `--ask-mode` value (`delegate`), so argparse will reject the invocation before the scenario can test delegation behavior. Use a valid ask mode (from the CLI choices) and model delegation behavior via the scenario setup/assertions instead of an invalid flag value.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix| Feature: FR-8 Intercept exit mapping | ||
| Scenario: Pending -- allow/deny/ask mapping | ||
| Given policies producing allow and deny and ask outcomes | ||
| When I run `policyctl intercept` with each outcome scenario |
There was a problem hiding this comment.
Suggestion: This invocation is missing required intercept arguments (--harness, --domain, --action, and --command), so it cannot run as written and will fail argument validation instead of exercising exit-code mapping. Provide a fully valid command per outcome case. [api mismatch]
Severity Level: Major ⚠️
- ⚠️ FR-8 intercept exit-code mapping spec fails early.
- ⚠️ Normalized exit-code behavior remains unvalidated.Steps of Reproduction ✅
1. Inspect the FR-8 acceptance spec at
`docs/specs/acceptance/FR-8-intercept-exit.command.feature:5`, which defines the step
`When I run \`policyctl intercept\` with each outcome scenario` without any additional
flags.
2. Open the intercept CLI parser in `cli/src/policy_federation/cli.py:651-668`, where
`intercept_parser.add_argument("--harness", required=True)`, `--domain`, `--action`, and
`--command` are all marked `required=True`.
3. Execute `policyctl intercept` exactly as written in the FR-8 spec (either manually or
via a Cucumber step that shells out to `policyctl`), so the process runs with no
`--harness`, `--domain`, `--action`, or `--command` arguments.
4. Observe that `argparse` reports missing required arguments (`--harness`, `--domain`,
`--action`, `--command`) and exits with `SystemExit` before the intercept implementation
(`intercept_command` mapped from `docs/specs/SPEC.md` FR-8 to
`interceptor.py:intercept_command`) can run, so the exit-code mapping behavior under test
is never exercised.(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** docs/specs/acceptance/FR-8-intercept-exit.command.feature
**Line:** 5:5
**Comment:**
*Api Mismatch: This invocation is missing required `intercept` arguments (`--harness`, `--domain`, `--action`, and `--command`), so it cannot run as written and will fail argument validation instead of exercising exit-code mapping. Provide a fully valid command per outcome case.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix| Scenario: Pending -- deny when policy hash changes before execution | ||
| Given a command that is initially allowed | ||
| And policy files change after pre-exec policy resolution | ||
| When I run `policyctl exec --harness forge --domain devops -- ask -- echo ok` |
There was a problem hiding this comment.
Suggestion: The exec command syntax is malformed: -- ask -- echo ok makes ask the subprocess executable after the -- separator, so the scenario does not execute the intended command and can fail with command-not-found instead of validating TOCTOU denial logic. Use the proper exec ... -- <command> form (and pass ask mode via --ask-mode if needed). [api mismatch]
Severity Level: Major ⚠️
- ⚠️ FR-9 exec TOCTOU acceptance spec mis-specifies argv.
- ⚠️ TOCTOU denial behavior may not be exercised correctly.Steps of Reproduction ✅
1. Inspect the FR-9 acceptance spec at
`docs/specs/acceptance/FR-9-exec-tamper.command.feature:6`, which defines the step `When I
run \`policyctl exec --harness forge --domain devops -- ask -- echo ok\`` to exercise
TOCTOU protection.
2. Open the exec subcommand parser in `cli/src/policy_federation/cli.py:670-688`, where
`exec_parser.add_argument("argv", nargs=argparse.REMAINDER)` captures all tokens after
`--` into `args.argv`, and open `exec_command` at
`cli/src/policy_federation/cli.py:160-173`, which passes `argv=list(args.argv)` directly
to `run_guarded_subprocess`.
3. Execute the FR-9 command literally (e.g., from a shell): `policyctl exec --harness
forge --domain devops -- ask -- echo ok`, so that after `argparse` sees the `--`
separator, `args.argv` becomes `["ask", "--", "echo", "ok"]`.
4. Observe that `exec_command` attempts to run a subprocess with executable `ask` rather
than `echo`, which will typically fail with an OS-level "No such file or directory: 'ask'"
or run an unintended binary, meaning the scenario either errors before TOCTOU denial logic
is evaluated or exercises the wrong command, and therefore does not faithfully test FR-9's
requirement in `docs/specs/SPEC.md:43-45` to deny execution when the policy hash changes.(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** docs/specs/acceptance/FR-9-exec-tamper.command.feature
**Line:** 6:6
**Comment:**
*Api Mismatch: The exec command syntax is malformed: `-- ask -- echo ok` makes `ask` the subprocess executable after the `--` separator, so the scenario does not execute the intended command and can fail with command-not-found instead of validating TOCTOU denial logic. Use the proper `exec ... -- <command>` form (and pass ask mode via `--ask-mode` if needed).
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix|
CodeAnt AI finished reviewing your PR. |



User description
Spec-first oracle (derived from source).
CodeAnt-AI Description
Add the PolicyStack oracle specification and pending acceptance scenarios
What Changed
policyctlandpolicy_federationsurface, covering command behavior, API expectations, and non-functional requirementsImpact
✅ Clearer policy command expectations✅ Faster acceptance test coverage planning✅ Easier validation of policy workflow behavior💡 Usage Guide
Checking Your Pull Request
Every time you make a pull request, our system automatically looks through it. We check for security issues, mistakes in how you're setting up your infrastructure, and common code problems. We do this to make sure your changes are solid and won't cause any trouble later.
Talking to CodeAnt AI
Got a question or need a hand with something in your pull request? You can easily get in touch with CodeAnt AI right here. Just type the following in a comment on your pull request, and replace "Your question here" with whatever you want to ask:
This lets you have a chat with CodeAnt AI about your pull request, making it easier to understand and improve your code.
Example
Preserve Org Learnings with CodeAnt
You can record team preferences so CodeAnt AI applies them in future reviews. Reply directly to the specific CodeAnt AI suggestion (in the same thread) and replace "Your feedback here" with your input:
This helps CodeAnt AI learn and adapt to your team's coding style and standards.
Example
Retrigger review
Ask CodeAnt AI to review the PR again, by typing:
Check Your Repository Health
To analyze the health of your code repository, visit our dashboard at https://app.codeant.ai. This tool helps you identify potential issues and areas for improvement in your codebase, ensuring your repository maintains high standards of code health.