diff --git a/.github/badges/conformance.svg b/.github/badges/conformance.svg index d240bd4..f874123 100644 --- a/.github/badges/conformance.svg +++ b/.github/badges/conformance.svg @@ -1,10 +1,10 @@ - - trsdn standard: v1.5.1 - Healthy + + trsdn standard: v1.6.0 - Healthy trsdn standard - v1.5.1 - Healthy + v1.6.0 - Healthy diff --git a/.github/conformance.yml b/.github/conformance.yml index 52a6c5c..56f7f93 100644 --- a/.github/conformance.yml +++ b/.github/conformance.yml @@ -1,4 +1,4 @@ -standard_version: "1.5.1" +standard_version: "1.6.0" assessed_on: "2026-08-31" state: "Healthy" evidence: "docs/self-assessment.md" @@ -24,7 +24,7 @@ criteria: P05: pass P06: pass P07: pass - P08: partial + P08: pass P09: pass S01: pass S02: pass diff --git a/docs/self-assessment.md b/docs/self-assessment.md index fb16700..cc567b5 100644 --- a/docs/self-assessment.md +++ b/docs/self-assessment.md @@ -4,15 +4,20 @@ Per-criterion evidence for [`.github/conformance.yml`](../.github/conformance.ym | Field | Value | |---|---| -| Standard | [Repository Quality Standard](https://github.com/trsdn/.github/blob/main/docs/repository-quality-standard.md) **v1.5.1** | +| Standard | [Repository Quality Standard](https://github.com/trsdn/.github/blob/v1.6.0/docs/repository-quality-standard.md) **v1.6.0** | | Assessed on | 2026-08-31 | | State | **Healthy** | -| Results | 73 pass · 1 partial · 0 fail · 19 n/a | +| Results | 74 pass · 0 partial · 0 fail · 19 n/a | Remediation was tracked in [#32](https://github.com/trsdn/PtionsPlus/issues/32), which followed the first assessment in [#29](https://github.com/trsdn/PtionsPlus/issues/29). +Reassessed against v1.6.0 on 2026-08-31. The only change is `P08`, which moved +from `partial` to `pass` because the standard's badge rule changed, not because +anything in this repository was relaxed. See +[Badge hosting](#badge-hosting-p08) for the reasoning. + ## Profiles Applicable: Baseline, Public, Software, Package And Release, Product Identity, @@ -56,7 +61,7 @@ Not applicable, with rationale: | P05 | pass | README covers install, configuration, examples, compatibility, versioning, troubleshooting, security, privacy, accessibility, and support status. | | P06 | pass | Community Standards at 100%. | | P07 | pass | Description, 14 topics, and a maintained homepage. | -| **P08** | **partial** | The badge block is in the required order — licence, platform, CI, release, conformance — and every value is derived from an authoritative source: licence and release from the GitHub API, CI from the workflow status of `main`, conformance from the committed badge rendered by the record. CI status is served by GitHub's own workflow badge endpoint, which is first-party and live at once. Licence, platform, and release are served by `img.shields.io`. On `github.com` those images load through GitHub's image proxy, so the host observes the proxy rather than the reader; what remains is an availability dependency. The standard asks for first-party images "where practical" without saying what that resolves to, which is why this stays `partial`; [trsdn/.github#31](https://github.com/trsdn/.github/pull/31) settles the rule. The hardcoded `Swift 5.9` badge that this criterion exists to prevent has been removed. | +| P08 | pass | Required order — licence, platform, CI, release, conformance — with every badge linking to what it reports. CI uses GitHub's own workflow badge endpoint, the first-party live image the standard names. Conformance is a committed image, regenerated from the record by a repository event. Licence, platform, and release have no first-party image source and are served live by `img.shields.io`, which v1.6.0 records as a `Pass`. The hardcoded `Swift 5.9` badge this criterion exists to prevent was removed in the previous assessment. Reasoning in [Badge hosting](#badge-hosting-p08). | | P09 | pass | [`.github/stats/repo-card.svg`](../.github/stats/repo-card.svg) and `repo-card-dark.svg`, generated by [`repo-stats.yml`](../.github/workflows/repo-stats.yml) on a weekly schedule, committed, selected with a `` element, and self-contained — the only `url()` in either file is an internal filter reference. | ## Software @@ -157,14 +162,55 @@ Published at from `main` at `/docs`. | Y05 | na | No third-party service and no AI provider receives user content, because nothing leaves the machine. | | Y06 | pass | README **Privacy** states that configuration persists until the user deletes it, and that uninstalling the app does not remove it. | -## Remaining gap - -`P08` is the only criterion not at `pass`. The CI badge is now served by GitHub's -own workflow endpoint, so the one required value that has a first-party live -image no longer comes from a third party. Licence, platform, and release still -do, and committing generated images for them would trade a live value for a -stale one — the staleness problem badges exist to avoid. The standard's "where -practical" does not say which of the two it wants, so there is no work that -clears this criterion as written. [trsdn/.github#31](https://github.com/trsdn/.github/pull/31) -makes the rule turn on how a value changes and closes it at `pass`. Recorded as -`partial` until that lands, rather than argued away. +## Badge hosting (`P08`) + +This is the one criterion whose result changed at reassessment, and it changed +because the standard was corrected rather than because this repository was. + +Under v1.5.1 the rule asked for images "served from the repository or a +first-party source where practical". That is not assessable — it names no +condition a repository can satisfy — so `P08` sat at `partial` with no work that +would clear it. The v1.5.1 assessment also gave a wrong reason for wanting +first-party images: it claimed `img.shields.io` observes every reader. Markdown +rendered on `github.com` loads external images through GitHub's proxy, so the +host sees the proxy, not the reader. That error was carried over from the `W07` +argument for the published site, where it does hold because a browser fetches +those images directly. Badges appear only in the README, so it did not. + +[v1.6.0](https://github.com/trsdn/.github/blob/v1.6.0/docs/repository-quality-standard.md#status-badges) +replaced the test with one that turns on how a value changes: + +| Value | Moves without a commit? | First-party image? | Result here | +|---|---|---|---| +| Licence | No | No | Live third-party — `Pass` | +| Platform | No | No | Live third-party — `Pass` | +| CI status | Yes | Yes, GitHub's workflow endpoint | First-party live — `Pass`, the preferred form | +| Latest release | Yes | No | Live third-party — `Pass` | +| Conformance | No | Committed, regenerated from the record | `Pass` | + +Two readings of the new rule were checked before recording `pass`, because the +distinction is new and the criterion turns on it. + +The committing bullet reads "a badge image **may** be committed to the repository +**only when** a repository event regenerates it", and names licence, platform, +and conformance as qualifying. That is a permission gate on committing, not an +obligation to commit: it forbids committing a moving value, it does not require +committing a stable one. The alternative reading — that "everywhere else" excludes +licence and platform, so both must be committed images — makes "may" do the work +of "must" and leaves a live third-party licence badge with no stated result at +all. The v1.6.0 changelog settles it directly: "No recorded result can turn into +a `Fail` from any of this." + +So licence and platform stay live. Committing generated images for them would be +permitted and would gain nothing: it trades a value that is correct by +construction for one that is correct only until the next regeneration. + +What remains is an availability and trust dependency on `img.shields.io` for +three of the five badges. That is a real dependency and it is worth revisiting if +a first-party source appears for any of those values, but under v1.6.0 it is not +a defect. + +## Open gaps + +None. Every applicable criterion is at `pass`, and the 19 recorded `na` results +each carry a rationale above.