Anders Eknert

Adding to this: ```rego allow if { some i, x in input.message } ``` Both `i` and `x` are unused here, but there's no warnings from neither OPA strict mode...

Not sure about category for this one. Bugs, I guess?

While I'm sure it's nowhere near feature complete, @kristiansvalland wrote a simple implementation in Rego way back that we've been using for the `ignore` patterns users can set in `.regal/config.yaml`...

Yeah, me too. Although if we support _that_, we should also support nested Regal configurations, which we also don't do 😅

Thinking more about it, although probably as a separate issue, would be to flag unnecessary ignores in config too. But that would likely need to entail a new command to...

The configuration is already made available to linter rules. One thing we'd need to figure out for this use case though is how to trigger a rule only _once_ and...

Aggregate rules now solve the problem of "how do we run something once", but they are not provided the configuration as part of the input currently. That however seems like...

Adding `aggregate` tag for this one, as we're unlikely to want to run this agains each input file, but something like the `aggregate_report` rule introduced recently.

With the `directory-package-mismatch` rule having landed, and that being able to do so much with just a single file provided, I doubt we're going to need this anytime soon. If...

I think you're right — this is really only valuable for "main" rules. The only way we have of knowing which ones are would be via the `entrypoint` annotation. We...