What happened
During review of PR #1832, the fullsend review agent's trust-boundary-bypass (high) finding flagged that the new acceptance shim acceptance/policy/sbom_proxy/lib/sbom_acceptance_shim.rego declares package lib.sbom — the same package name used by production policy/lib/sbom/sbom.rego. In Rego, rules declared in the same package are unioned across all loaded files, so an acceptance-only shim colocated on the load path would silently extend production behavior. The author responded in commit f2b08647 by scoping the shim to the acceptance/policy/sbom_proxy/ subtree so that production ec eval invocations do not load it. The package name was intentionally kept identical to satisfy the acceptance harness's ability to override rules under test — this is a working, reviewed solution. However, the guardrail — 'acceptance-only Rego files must never appear on the production data path under a production package name' — is currently an unwritten convention enforced only by reviewer vigilance. Neither coderabbitai nor the two human approvers (@robnester-rh LGTM 2026-09-10, @BohdanMar LGTM 2026-09-15) surfaced this class of defect on their own; only the fullsend review agent did.
What could go better
The next reviewer of a similar acceptance shim may or may not catch the same class of issue — the current signal is one datapoint. Confidence that a lint rule would be helpful is high; confidence that it can be written without false positives on the existing acceptance tree is medium — I did not enumerate every package lib.* / package release.* declaration under acceptance/, and there may be existing intentional overlaps that would need to be allowlisted. A lightweight first pass could simply be an AGENTS.md guardrail that names the pattern (production package name + acceptance/ path = requires reviewer sign-off and justification comment) rather than a hard-fail CI rule. Uncertainty: I have not confirmed whether the production ec eval invocation actually excludes acceptance/policy/** from its policy load path in every downstream consumer — if any consumer loads the whole tree, the shim would still leak. If confirmed safe, the lint rule alone is enough; if not, the leak is a latent runtime risk and the scoping needs to be enforced at the ec-eval level.
Proposed change
Add to AGENTS.md (or a new acceptance/AGENTS.md) a short section titled 'Acceptance shims must not extend production packages' that (a) states the rule, (b) shows the sbom_acceptance_shim.rego example with the justification for why it is safe (path-scoped, not on production ec eval load path), and (c) requires that any new acceptance rego file declaring a package lib.* or package release.* name include a comment # ACCEPTANCE-ONLY: <justification of why this does not leak to production>. Optionally, add a make lint-acceptance target (or extend make ci) that grep-asserts package lib. / package release. declarations under acceptance/ are accompanied by that marker comment. Do not attempt to enforce package renaming — the review of PR #1832 established that the identical-package pattern is deliberate for the acceptance harness.
Validation criteria
Within the next 10 PRs to conforma/policy that add or modify files under acceptance/policy/**, no fullsend review agent finding of category trust-boundary / trust-boundary-bypass / package-sharing should appear against an acceptance shim that carries the new marker comment; conversely, any new acceptance shim submitted without the marker comment should be caught either by the (optional) make lint-acceptance step in CI or by a human reviewer citing the new AGENTS.md section. Measure at the next retro that touches an acceptance-shim PR (target: sample of 5 acceptance-touching PRs within 60 days).
Generated by retro agent from #1832
What happened
During review of PR #1832, the fullsend review agent's
trust-boundary-bypass (high)finding flagged that the new acceptance shimacceptance/policy/sbom_proxy/lib/sbom_acceptance_shim.regodeclarespackage lib.sbom— the same package name used by productionpolicy/lib/sbom/sbom.rego. In Rego, rules declared in the same package are unioned across all loaded files, so an acceptance-only shim colocated on the load path would silently extend production behavior. The author responded in commitf2b08647by scoping the shim to theacceptance/policy/sbom_proxy/subtree so that productionec evalinvocations do not load it. The package name was intentionally kept identical to satisfy the acceptance harness's ability to override rules under test — this is a working, reviewed solution. However, the guardrail — 'acceptance-only Rego files must never appear on the production data path under a production package name' — is currently an unwritten convention enforced only by reviewer vigilance. Neither coderabbitai nor the two human approvers (@robnester-rh LGTM 2026-09-10, @BohdanMar LGTM 2026-09-15) surfaced this class of defect on their own; only the fullsend review agent did.What could go better
The next reviewer of a similar acceptance shim may or may not catch the same class of issue — the current signal is one datapoint. Confidence that a lint rule would be helpful is high; confidence that it can be written without false positives on the existing acceptance tree is medium — I did not enumerate every
package lib.*/package release.*declaration underacceptance/, and there may be existing intentional overlaps that would need to be allowlisted. A lightweight first pass could simply be an AGENTS.md guardrail that names the pattern (production package name +acceptance/path = requires reviewer sign-off and justification comment) rather than a hard-fail CI rule. Uncertainty: I have not confirmed whether the productionec evalinvocation actually excludesacceptance/policy/**from its policy load path in every downstream consumer — if any consumer loads the whole tree, the shim would still leak. If confirmed safe, the lint rule alone is enough; if not, the leak is a latent runtime risk and the scoping needs to be enforced at the ec-eval level.Proposed change
Add to
AGENTS.md(or a newacceptance/AGENTS.md) a short section titled 'Acceptance shims must not extend production packages' that (a) states the rule, (b) shows thesbom_acceptance_shim.regoexample with the justification for why it is safe (path-scoped, not on productionec evalload path), and (c) requires that any new acceptance rego file declaring apackage lib.*orpackage release.*name include a comment# ACCEPTANCE-ONLY: <justification of why this does not leak to production>. Optionally, add amake lint-acceptancetarget (or extendmake ci) that grep-assertspackage lib./package release.declarations underacceptance/are accompanied by that marker comment. Do not attempt to enforce package renaming — the review of PR #1832 established that the identical-package pattern is deliberate for the acceptance harness.Validation criteria
Within the next 10 PRs to
conforma/policythat add or modify files underacceptance/policy/**, no fullsend review agent finding of categorytrust-boundary/trust-boundary-bypass/package-sharingshould appear against an acceptance shim that carries the new marker comment; conversely, any new acceptance shim submitted without the marker comment should be caught either by the (optional)make lint-acceptancestep in CI or by a human reviewer citing the new AGENTS.md section. Measure at the next retro that touches an acceptance-shim PR (target: sample of 5 acceptance-touching PRs within 60 days).Generated by retro agent from #1832