[infodusha]

Adds enabled_rule_ids to CheckRequest: the IDs of every rule the caller runs in the same check, across builtin rules and all plugins. Follows up on bufbuild/buf#4722, as suggested there.

Why

A plugin only sees its own rule_ids, so it cannot tell when one of its rules runs together with a rule it replaces or contradicts. buf-lint-extra has PACKAGE_DIRECTORY_MATCH_EXTRA, which replaces PACKAGE_DIRECTORY_MATCH, and PACKAGE_CAMEL_CASE, which contradicts PACKAGE_LOWER_SNAKE_CASE, among others. With STANDARD enabled, every file fails one side until the user copies the right lint.except list from the README. With this field the plugin can report the clash once and name the rule to except. A plugin can also pick option defaults based on what else runs, which buf-lint-extra already does among its own rules.

Semantics

• After use/except resolution. The list is what the caller will actually run, of the same rule type as rule_ids. In Buf, deprecated IDs named in the configuration appear as their replacements. Path-based ignores (ignore, ignore_only, comment ignores) do not remove IDs, since they filter annotations afterwards.
• Scoped to one configuration. In Buf, that is one module's lint or breaking section with its plugins, or one policy. Buf already resolves and runs each of these as a separate pass, and a plugin running in a policy cannot change the module's except list anyway.
• Includes the request's own rule_ids. So an empty list means "not provided", and a non-empty list is a superset of rule_ids.
• Not paginated. When rule_ids is split over several requests, each one carries the full list.
• Compatible both ways. Older plugins ignore the field. Plugins see an empty list from older callers.

Validation

Items have the same constraints as rule_ids, plus unique. There is no max_items: a cap would make a large configuration fail validation inside every plugin, and paging makes no sense for a list that every request needs whole.

I also wanted a message-level rule for the subset relation:

size(this.enabled_rule_ids) == 0 || this.rule_ids.all(id, id in this.enabled_rule_ids)

It compiles, but buf lint cannot check it in this repository yet. cel-go's pb.Db.RegisterDescriptor swaps a descriptor for the copy linked into the binary when one exists at the same path, and buf links buf/plugin/check/v1/check_service.proto without the new field, so PROTOVALIDATE reports undefined field 'enabled_rule_ids'. The same file under another path lints cleanly. The rule could be added once buf ships with the regenerated SDK, if you want it.

Coupling

The field is informational. Plugins that do not read it are unaffected. A plugin that looks for a specific builtin ID couples itself to that ID, as its documentation already does today when it tells users what to put in lint.except.

Buf side

Buf would fill the field in one place: multiClient.Check in private/bufpkg/bufcheck/multi_client.go already holds the full resolved list before narrowing it per client, so lint, breaking, the LSP and protoc-gen-buf-lint would all get it. bufplugin-go would expose it as Request.EnabledRuleIDs(). I can follow up with both once the field is settled.

Open questions

• Name: enabled_rule_ids, or something else? configured_rule_ids seemed misleading, since ConfiguredRules in Buf spans the module and its policies.
• No max_items. Is a cap wanted anyway?
• Per-configuration scope as above, rather than one list across a module and its policies?
• Add the subset rule later, or leave the relation documented only?

[CLAassistant]

All committers have signed the CLA.