Skip to content

Promote to main: GT-693 closed — OPA violations now carry their emitting policy - #509

Merged
beyondnetPeru merged 5 commits into
mainfrom
develop
Aug 15, 2026
Merged

Promote to main: GT-693 closed — OPA violations now carry their emitting policy#509
beyondnetPeru merged 5 commits into
mainfrom
develop

Conversation

@beyondnetPeru

Copy link
Copy Markdown
Contributor

Promotes develop (3 commits) to main. Closes GT-693. Registers GT-694.

What lands

A gate referencing an OPA policy was reported passed while the policy's
violations were thrown away. Reproduced against the real bundle before anything was
touched: a satellite with lodash: "^4.17.21" — the literal thing DEP-01 forbids
— made the wasm emit 61 violations, five of them DEP-*, and the gate returned
passed. Both facts printed from the same run, so the finding demonstrably
existed and was discarded.

The evaluator attributed violations through a hand-maintained prefix table. Four
policies were listed; the rest fell through to exact-id matching, which can never
match, so violations.filter(...) matched nothing and the branch fell through to
passed.

The fix is provenance, not a longer list. main.rego now tags every aggregated
violation with the id deriveRuleId builds from the emitting policy's own path, so
attribution compares two things equal by construction. All 34 aggregation rules
rewritten from the imports themselves; opa check clean; opa test 265/265;
bundle rebuilt and re-measured at the same 61 violations. The same gate now
returns failed naming the dependency.

Literal object construction on purpose — only a handful of builtins are dispatchable
in the compiled wasm (GT-644, guard 55).

The collisions resolve, which no id scheme could do. CLI-RR-01..05 are emitted
by both cli-readiness and cli-release-readiness, TAX-05..11 by both taxonomy
and repository-taxonomy; each now attributes to its own policy and not the other.

Also: orphan violations are named rather than dropped; the old table survives only
as a fallback for a pre-change policy.wasm and is deliberately not extended; the
27-name pin was replaced by three cases asserting the invariant that makes it
unnecessary; and ADR-0041 parity is demonstrated on DEP-01 in both engines,
with a negative case so the agreement is not vacuous.

Stated plainly

My own first census was wrong and the row says so. It matched Rego packages by
prefix and skipped every basename containing test, so evolith.testing_pyramid
resolved to the test file and the real testing-pyramid.rego vanished from the
count. Corrected figures: 39 policies / 35 namespaced / 203 ids, not 33 / 31 /
197. A draft finding built on that error is refuted and the refutation kept. The
collision facts were unaffected and were right.

GT-688's row on main carries the earlier figures — the honest reading at the
time, superseded in GT-693 rather than rewritten there.

GT-694 registered rather than absorbed: 15 facets that shipped OPA input
schemas require are never emitted by the input builder, so twelve categories can
never reach their policy — confirmed end to end on multi-tenancy. P2, not P1:
unlike GT-693 it produces no false pass.

Verification

PR #508 merged with 33 checks green. core-domain 1934 · cli 1482 · mcp 575 ·
infra-providers 179 · contracts 115. Guards 01, 04, 07, 08, 26, 28, 32, 46, 49, 55
green. Board 657 / 692 · 3 in progress · 22 pending · 10 deferred.

🤖 Generated with Claude Code

beyondnetPeru and others added 3 commits August 15, 2026 17:27
…tion stops guessing

GT-693. The defect was reproduced against the real bundle before anything was
touched: a satellite whose package.json carries `lodash: "^4.17.21"` -- the literal
thing DEP-01 forbids -- made the wasm emit 61 violations, five of them DEP-*
including DEP-01, and a gate referencing `version-pinning.rego` returned `passed`.
The same gate now returns `failed`, naming
`package.json#dependencies.lodash=^4.17.21`.

THE FIX IS PROVENANCE, NOT A LONGER LIST. `main.rego` tags every aggregated
violation with the id `deriveRuleId` builds from the emitting policy's own path,
so the evaluator compares two things equal BY CONSTRUCTION instead of consulting
a table somebody has to remember to update. All 34 aggregation rules were
rewritten from the imports themselves, not by hand. `opa check` clean, `opa test`
265/265, bundle rebuilt and re-measured at the same 61 violations -- nothing
duplicated, nothing lost.

Literal object construction on purpose: only a handful of builtins are dispatchable
in the compiled wasm (GT-644, guard 55), so `object.union` was not available.
`{id, message}` is the complete shape -- all 251 violation literals carry those two
and nothing else, verified by count.

THE COLLISIONS RESOLVE, WHICH NO ID SCHEME COULD DO. `CLI-RR-01..05` are emitted by
both cli-readiness and cli-release-readiness, `TAX-05..11` by both taxonomy and
repository-taxonomy. Four cases assert each attributes to its own policy AND NOT to
the other, because a verdict naming the wrong policy sends the operator to the
wrong file -- worse than a missing one.

The prefix table stays as a fallback for exactly one thing: a policy.wasm older
than this change. It is deliberately not extended, and a legacy violation it cannot
place is now REPORTED rather than dropped, so a stale bundle cannot look healthy.

The 27-name list is gone because its premise is; it was REPLACED by three cases
asserting the invariant that makes it unnecessary. Mutations: removing one tag
turns 2 red, mis-tagging one turns 1 red, neutering orphan reporting turns 1 red.

ADR-0041 parity demonstrated on DEP-01 in BOTH engines against the real bundle and
a real directory, because the defect lived in the hop between the wasm's output and
the verdict -- and both PASS an exactly-pinned repository, so the agreement is not
vacuous. The bundle's absence fails that suite rather than skipping it.

MY OWN FIRST SCAN WAS WRONG AND THE ROW SAYS SO. It matched packages by PREFIX and
excluded every basename containing `test`, so `evolith.testing_pyramid` resolved to
the test file and `testing-pyramid.rego` vanished from the census. Corrected counts
are 39 policies / 35 namespaced / 203 ids, not 33 / 31 / 197. The collision facts
were unaffected and were right. The spec, which uses exact package keys, validated
all 34 tags -- it caught what my script could have got wrong.

GT-694 registered rather than absorbed: 15 facets that shipped input schemas require
are never emitted by the input builder, so twelve categories can never reach their
policy at all -- a different defect, on the way IN rather than on the way out.

core-domain 1934 · cli 1482 · mcp 575 · infra-providers 179 · contracts 115.
Guards 26, 28, 32, 55 green.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
GT-693 closed with all five criteria measured against the real bundle, and the
before/after recorded literally: a gate referencing `version-pinning.rego` on a
satellite with `lodash: ^4.17.21` went from `passed` to `failed` naming the
dependency, while the wasm had been emitting DEP-01 the whole time.

A CORRECTION TO MY OWN MEASUREMENT, written into the row rather than quietly
fixed. My first census matched Rego packages by PREFIX and skipped every basename
containing `test`. Two consequences: `evolith.testing_pyramid` resolved to
`testing-pyramid.test.rego` -- which actually declares `evolith.testing_pyramid_test`
-- and the real `testing-pyramid.rego` vanished from the count entirely. That scan
produced this row's original "33 policies / 31 namespaced / 197 ids". The corrected
figures are 39 / 35 / 203, and they are used throughout the row now.

A DRAFT FINDING BUILT ON THAT ERROR IS REFUTED AND THE REFUTATION KEPT: I had
written that `main.rego` imports violations from a package declared only in a test
file. It does not. The real policy exists and emits TPY-01..04.

What the error did NOT touch: the collision facts were right (10 ids, CLI-RR-01..05
and TAX-05..08/TAX-11), and the spec -- which uses exact package keys, not prefixes
-- validated all 34 tags, catching what the script could have got wrong.

GT-688's row carries the earlier figures. They were the honest reading at the time;
they are superseded here rather than rewritten there.

GT-694 REGISTERED: 15 facets that shipped OPA input schemas require are never
emitted by `opa-input-builder.ts`, so twelve categories can never reach their
policy -- confirmed end to end on `multi-tenancy`, which returns
`OPA Input Schema Validation Failed: data/satellite must have required property
'multiTenancy'` instead of a verdict. P2 and not P1, stated rather than assumed:
unlike GT-693 this produces no false pass. A different defect on the way IN, not on
the way out, so it is a row and not an extension of this one.

Board 657/692 · 3 in progress · 22 pending · 10 deferred, recounted from the rows
in both languages. Guards 01, 04, 07, 08, 46, 49 green -- 08 caught `MEDIUM` where
the declared interest band is `MED`, which is the debt-economics guard doing its
job.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
…nance

Closes GT-693: give every OPA violation the policy that emitted it
@beyondnetPeru
beyondnetPeru requested a review from a team as a code owner August 15, 2026 22:42
@chatgpt-codex-connector

Copy link
Copy Markdown

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

@github-actions

Copy link
Copy Markdown

📊 Bilingual Coverage Impact

PR Changes

  • Paired EN/ES files modified: 3
  • New EN files needing ES translation: 0

Repository Coverage

Metric Value
Total EN files 527
Total ES files 501
Paired files 0
Coverage 0%

Good: All EN changes have ES counterparts.


Generated by GitHub Actions

…or spec

CodeQL caught this on PR #509 and it is a real finding in my own code, not noise:
`GT-693` deleted the test that pinned the 27 unmapped policies, which was the only
consumer of `CONTEXT_AWARE_VIOLATION_PREFIXES` in this spec. The import stayed
behind.

Removed rather than resolved-as-acceptable. The constant is still exported and
still used in production as the fallback for a pre-GT-693 `policy.wasm`; what was
dead is this file's reference to it.

opa-evaluator spec 19/19.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Drop a dead import in the OPA evaluator spec
@beyondnetPeru
beyondnetPeru merged commit 3b9d0ff into main Aug 15, 2026
59 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants