Add config-driven attr-policy linting

[alexeagle]

Summary

• Adds attr-policy: config-driven BUILD attribute checks via attrPolicy in .buildifier.json, plus a JSON schema for config validation.
• Default-on when no config is set: enforces Bazel's shard_count ≤ 50 on tests, and flags deprecated licenses / output_licenses usage.
• licenses and output_licenses are legacy attrs from the pre-rules_license era (bazel#188, bazel#7444). Bazel still accepts them silently — no analysis error, no --incompatible_* flag (contrast distribs, which had --incompatible_no_package_distribs), and the built-in deprecation attribute only warns on deprecated targets, not deprecated attribute names. Existing buildifier attr-licenses only catches the name in rule definitions (.bzl), not on BUILD targets. These default checks are the practical way to surface and finish removal.
• Design doc covers a future testpolicy tool (not implemented here).

Closes #1480

Test plan

• bazel test //warn:warn_test //buildifier/config:config_test //warn/docs:docs_test

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[gemini-code-assist]

Code Review

This pull request introduces a design document for implementing static attribute-policy linting in buildifier and empirical test-tuning in a new testpolicy tool. The review feedback provides valuable improvements to the design, including ensuring the configuration examples use standard JSON to prevent parsing errors, refining linter error anchoring for list attributes, handling mathematical boundary cases in the flakiness formula, and adding guardrails to verify target existence before running buildozer commands.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[alexeagle]

@vladmos could you at least comment whether this FR is in a shape that can be accepted upstream?

[vladmos]

(moving the discussion from the private messaging to Github for visibility)

Should we provide a way to let people define their own rules and use the default at the same time, without copying and maintaining the list of default rules? My suggestion was to allow something like

"attrPolicy": {
    "keepDefault": false,  // true by default
    "rules": [...],
}

would it be a common usecase that a repo maintainer wants to define something custom for their repo without disabling the default checks?

[alexeagle]

I would guess the majority of corporate monorepo users benefit from creating some enforcement of their local conventions (for example, a lexicon of allowed tags values so they don't proliferate meaninglessly)

Personally, I'd like to keep the full list in one place, so I would just copy and modify the default settings. But I'm happy to follow your guidance.

Some complications with keepDefault:

1. To understand the policy, you have to look up the defaults - but if they change from one release to the next, it's easy to make the mistake of looking up the HEAD documentation and concluding you have something enforced.
2. have to explain and test for override situation where default has one value and user has another. Especially tricky for nested values: given a default

      {
        "name": "no-eternal-timeout",
        "ruleKinds": ["*_test"],
        "attr": "timeout",
        "forbidValues": ["eternal"],
        "allowlist": ["//slow/..."]
      }

what happens if a user does

    "keepDefault": true,
    ...
      {
        "name": "no-long-timeout",
        "ruleKinds": ["*_test"],
        "attr": "timeout",
        "forbidValues": ["long"],
        "allowlist": ["//other/..."]
      }

does the forbidValues compose, or is it overridden? How would a user say that no timeout values should be forbidden? What about "allowlist"? Can users provide a name that collides with a default?

[alexeagle]

(note, I'm getting my CLA resolved, that check should be green early next week)