lidofinance.server

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.

Give every collection dependency you declare in `galaxy.yml` an upper or pinned bound — `<`, `<=`, `==` or `~=` — so that installing your collection cannot silently pull in an arbitrary future release of somebody else’s. If your collection declares no dependencies at all this rule already awards full marks and there is nothing here to change. If we reported a dependency we could not read, the fix is the syntax of its version range rather than the dependency itself.

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.

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.

Write a fragment into `changelogs/fragments/` as each change lands, rather than composing release notes at release time. This reads the same published file as the Quality changelog rule, so shipping and maintaining a changelog answers both at once — if a page told you twice to ship a changelog it would be describing one missing file as two problems. One thing this rule does NOT ask for: an empty fragments directory is not the goal, and cutting a release clears your fragments by design. A maintained changelog with nothing pending still earns partial credit here, so releasing your work does not cost you this rule.

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.