bellackn.homelab

Ship your README and your `docs/` directory INSIDE the published tarball, not only in your Git repository — we do not read repositories at all yet, so a file that exists only there is a file we cannot see. If your `build_ignore` excludes `docs/`, that exclusion is why we observed nothing. Beyond the README this rule counts documentation FILES, so splitting a long README into per-module and per-role pages is what moves it; adding filler pages to raise a count would satisfy the arithmetic and help nobody.

Declare a `requires_ansible` FLOOR in your `galaxy.yml` naming the oldest ansible-core you actually support, and declare an upper bound alongside it if you test against one — the bound is credited on top of whichever floor tier you reach in the table beside this rule. Declaring nothing now scores zero and STAYS in your score rather than dropping out of it, so omitting the field is no longer a way to avoid the question; if your score fell and you have never declared a floor, this is why. An exact pin or a `~=` compatible-release specifier earns only a small share, strictly below every floor tier: it is a real declaration we could read, so it beats silence, and it sits at the bottom because pinning ansible-core is the practice this category exists to discourage. Raising a floor you cannot actually support would be a false declaration, and this rule is not worth that.

Publish your CI configuration inside the artifact. `.github/workflows/` is what we count most precisely, and other CI config files earn partial credit when your automation runs somewhere we cannot enumerate as exactly. `build_ignore` commonly strips `.github/`, again on the packaging documentation’s own advice, so an absence here is a gap in what we could read rather than a statement that your collection has no CI. In this scoring version this rule can only add points: an unobserved CI signal leaves your calculation rather than scoring zero, so this is worth doing for the credit and never to avoid a deduction.