serhii9132.base_layer

Ship a `changelogs/changelog.yaml` — the structured form `antsibull-changelog` generates and the `ansible` package consumes — rather than only a hand-maintained `CHANGELOG.md`, and write a fragment into `changelogs/fragments/` as each change lands rather than reconstructing release notes at release time. Both have to be inside the published tarball to be observable: a changelog that lives only in your Git repository is one we cannot read. This is the single highest-leverage change for most collections, because the same missing file is what holds down both changelog rules in this rubric. If you already publish `changelog.yaml` with fragments, this rule is answered.

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 machine-readable SPDX identifier in `galaxy.yml`’s `license` field rather than relying on a `LICENSE` file alone: an identifier is what a consuming organisation’s policy tooling reads without a human opening the file. A `LICENSES/` directory following REUSE ranks above a bare root licence file and below the identifier. One exception worth stating: we record the identifier you publish rather than validating it against the SPDX list, so a wrong identifier will earn these marks and mislead your users at the same time — if no SPDX identifier fits your licence, publish the file instead.

Publish your test evidence inside the artifact: `molecule/` scenarios for a role collection, and `tests/unit/`, `tests/integration/` and `tests/sanity/` for a plugin collection. Ansible’s own packaging documentation suggests excluding `tests/` through `build_ignore`, so if you follow that advice we simply cannot see them — their absence from your tarball is a limit on what we read and never a claim that you have no tests. In this scoring version this rule can only add points: when we observe no test evidence the rule leaves your calculation entirely rather than scoring zero, so publishing tests can raise your score and withholding them cannot lower it.

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.