Say that committing a qualifying badge value is permitted, never required

.github/conformance.yml

@@ -6,7 +6,7 @@
 # The badge in .github/badges/ is generated from this file. Change the evidence
 # first, then this record, then regenerate. Never the other way round.
 
-standard_version: "1.6.0"
+standard_version: "1.6.1"
 assessed_on: "2026-08-31"
 state: "Healthy"
 evidence: "docs/self-assessment.md"

CHANGELOG.md

@@ -6,6 +6,20 @@ recorded here.
 Versions follow the compatibility policy in the
 [Repository Quality Standard](docs/repository-quality-standard.md).
 
+## 1.6.1 - 2026-08-31
+
+- Closed an ambiguity in the badge image rule, found by the first repository
+  assessed against 1.6.0. The committing bullet named license, platform, and
+  conformance as qualifying for a committed image, and the following bullet
+  granted a `Pass` to a live third-party image "everywhere else". Read together,
+  the three named values fell outside "everywhere else" and were left with no
+  stated result at all — neither `Pass` nor `Partial` nor `Fail` — which let
+  `may` be read as `must`. Committing a qualifying value is now stated as
+  permitted and never required, and the `Pass` is tied to the absence of a
+  first-party image rather than to "everywhere else". No result changes; 1.6.0
+  already excluded a reading that turns a recorded `Pass` into a `Fail`, and
+  this states in the rule text what that exclusion implied.
+
 ## 1.6.0 - 2026-08-31
 
 - Corrected the reason given for self-hosting images. Both `P08` and `P09`

docs/repository-quality-standard.md

@@ -1,6 +1,6 @@
 # Repository Quality Standard
 
-- Version: 1.6.0
+- Version: 1.6.1
 - Last reviewed: 2026-08-31
 - Review cadence: every six months, even when nothing changes
 
@@ -499,16 +499,18 @@ Rules:
 - Badges outside the required and optional sets need a stated reason. A wall of
   badges carries less information than four accurate ones.
 - A badge image may be committed to the repository only when a repository event
-  regenerates it. License, platform, and conformance qualify. CI status and the
-  latest release move without a commit, so a committed image of either is stale
-  between regenerations. Bounded staleness is acceptable for the activity card
-  in `P09`; it is not acceptable for a badge reporting current status.
+  regenerates it. License, platform, and conformance qualify, and committing
+  them is permitted, never required. CI status and the latest release move
+  without a commit, so a committed image of either is stale between
+  regenerations. Bounded staleness is acceptable for the activity card in `P09`;
+  it is not acceptable for a badge reporting current status.
 - Where the authority for a value publishes its own image, use that image.
   GitHub serves a workflow status badge for a repository's own CI, so that badge
   is first-party and live at once. A third-party render of the same value is not
   a `Fail`, but it is the weaker option and reassessment should replace it.
-- Everywhere else a live third-party image is a `Pass`. Serving a value late is
-  worse than serving it from somebody else's host.
+- A live third-party image is a `Pass` for any value with no first-party image,
+  whether or not that value would also qualify for committing. Serving a value
+  late is worse than serving it from somebody else's host.
 
 A hardcoded `Swift 5.9` badge beside a manifest that has moved to 6.0 is the
 failure this section exists to prevent.

docs/self-assessment.md

@@ -1,6 +1,6 @@
 # Self-Assessment: trsdn/.github
 
-- Standard version: 1.6.0
+- Standard version: 1.6.1
 - Assessed on: 2026-08-31
 - State: **Healthy**
 - Record: [`.github/conformance.yml`](../.github/conformance.yml)

standard.yml

@@ -3,7 +3,7 @@
 # Generated by scripts/standard.py from
 # docs/repository-quality-standard.md. Do not edit by hand.
 
-version: "1.6.0"
+version: "1.6.1"
 last_reviewed: "2026-08-31"
 
 prefixes: