Refresh the PhotoCleaner audit report and driftNotes - #508
Conversation
The committed snapshot dated 2026-07-23 and predated the release pipeline, so it still listed both branch rulesets as missing and the Dockerfile as dead weight. All of that landed. Re-audited against main@15b9b5b. The remaining findings are a different set, created mostly by the hub advancing rather than by the repo regressing: the agent instruction set predates the router split, the README intro is over the 100-char cap with the Docker Hub description no longer mirroring it, two verbatim carries are stale, and build-release-task.yml has no validate-release job even though this repo's own WORKFLOW.md names it in D2.2 and in scenarios S1, S4, and S10. Six convergence pull requests are open against PhotoCleaner develop, one per drift class, listed in the report and left for the maintainer. The report also raises five spec questions rather than resolving them, per AUDIT.md section 9. Three are hub-side defects this convergence surfaced: the hub's own copilot-instructions "Reviewing Carried Fleet Content" still describes the pre-split AGENTS.md, CODESTYLE.md still says MD033 flags every HTML element after the config gained allowed_elements, and readme-structure.md has no stated behavior for a private repo whose GitHub shields cannot render. driftNotes drop the stale claim that the report predates the release wiring, drop the cross-repo comparison a carried registry entry should not make, and record the private-repo versus public-channel conflict. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
Pull request overview
Updates the PhotoCleaner audit snapshot and registry drift notes to reflect the current main state and newly observed hub-vs-repo drift, replacing the outdated 2026-07-23 report.
Changes:
- Refreshed
reports/photocleaner/audit.mdwith a new run stamp, updated dimensions/verdicts, and current drift/defect findings. - Updated PhotoCleaner’s
driftNotesinregistry/repos.jsonto remove stale claims and record the repo-privacy vs publish-channel mismatch.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.
| File | Description |
|---|---|
| reports/photocleaner/audit.md | Re-audits PhotoCleaner and updates findings/driftNotes narrative to the 2026-08-01 run. |
| registry/repos.json | Refreshes PhotoCleaner drift notes to align with the new audit report and current publish/visibility reality. |
CI's editorconfig-checker failed: the report was written with LF while .editorconfig pins markdown to CRLF. Converted, and repo_gate.py now reports eol 0 issues. Two review findings applied: the dimension key drops the space to match the other single-token keys, and the second defect title is rephrased so it says plainly that the two description mirrors no longer match the README intro. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 2 out of 2 changed files in this pull request and generated no new comments.
Suppressed comments (2)
reports/photocleaner/audit.md:3
- The audited-commit reference uses a 7-character short SHA (
15b9b5b), while other audit reports in this repo consistently record the full 40-character commit SHA (e.g.,reports/plexcleaner/audit.md:3,reports/utilities/audit.md:3). Using the full SHA improves traceability and avoids ambiguity/collisions.
- **Audited branch:** main (`15b9b5b`)
registry/repos.json:253
- The second drift note says “Fully onboarded 2026-07 … all live”, but the refreshed audit report in this PR still records multiple open defects/drift items and an overall verdict of “not operational” (reports/photocleaner/audit.md:5, 26-28). Rewording this note to “baseline onboarding completed” (or similar) would avoid implying conformance is complete.
"driftNotes": ["Multi-arch Docker (linux/amd64,linux/arm64 on main) pushed to Docker Hub via the static DOCKER_HUB_USERNAME/DOCKER_HUB_ACCESS_TOKEN secret, plus a github-release attaching the multi-arch executables as a 7z. Release is two-phase (workflow_dispatch + weekly Mon 02:00 schedule). First release 1.0.9 published 2026-07-23.", "Fully onboarded 2026-07 (rulesets, repo-config/, version.json, WORKFLOW.md, AUDIT.md, dependabot.yml, and the release pipeline all live).", "The repo is private while its Docker Hub image is public, so the declared github-release channel is not pullable by a consumer and GitHub-sourced README shields cannot render. Raised with the maintainer in reports/photocleaner/audit.md; either the visibility or the declared channel is wrong."]
Two collapsed review findings, both correct. The audited-commit reference used a 7-character short SHA where the other seven reports in this directory all record the full 40 characters. Now 15b9b5b7411bbba43b8bff8044c4b651355c10a4. The second driftNote said "Fully onboarded", which reads as conformance complete while this same PR records a not-operational verdict with two open defects. Reworded to "Baseline onboarding completed", with a pointer to the report for what is still open. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
Both collapsed findings from the review on Short SHA. Confirmed against the directory rather than taken on trust: the other seven "Fully onboarded" implying conformance. The sharper catch of the two, since the note contradicted the verdict in the same PR. Reworded to "Baseline onboarding completed 2026-07 ... Not conformance-complete: see reports/photocleaner/audit.md for the open defects." That keeps the useful fact (the scaffolding is all live) without the reading that there is nothing left to do, which is exactly the stale-note failure
|
The maintainer answered the sixth question this report raised: the repo is private deliberately and temporarily, and goes public once the conformance work settles, which serves prospective users and lowers the GitHub bill. So the declared github-release channel is not wrong, it is correct as of that flip, and the registry now records the plan rather than asserting a contradiction. The spec question in escalation 4 stands regardless, and is sharpened rather than dropped: a repo is often private precisely while it is being made presentable, which is when its README is written, so readme-structure.md needs a stated behavior for GitHub-sourced shields that cannot render yet. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 2 out of 2 changed files in this pull request and generated no new comments.
Suppressed comments (1)
reports/photocleaner/audit.md:35
- Defect #2 claims there are “two description mirrors”, but the supporting text here (and the earlier readme-structure dimension evidence) only mentions the Docker Hub short description. This reads like a leftover from an earlier phrasing and makes the defect ambiguous. Suggest aligning the defect title with the actual evidence you cite in this report.
2. **README intro over the cap, and the two description mirrors no longer match it.** The intro is 150 characters against the 100-character Docker Hub cap, and the Docker Hub short description (`Pre-process media files for import into photo management systems.`) no longer matches it, so the repo carries two different canonical sentences.
The defect title claimed both mirrors had diverged, which the evidence in the same paragraph did not support. Checked against the live repo: the GitHub About panel matched the README exactly, and only the Docker Hub short description had drifted. The title now says so, and names the two mirrors GOVERNANCE.md "Repository Details" defines so the distinction is readable without opening that file. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
The collapsed finding on the review of The title claimed both mirrors had diverged while the paragraph under it only evidenced one. Verified against the live repo rather than re-reasoning from the report: Two different canonical sentences did exist, so the defect itself stands; it was the count of diverged mirrors that was wrong. |
AUDIT.md section 9 says to surface spec questions rather than resolve them silently, and a report section listing five with no tracking issue is the silent half of that. Filed as #509. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
Handing this over rather than landing it. Flagging the provenance so whoever picks it up can judge it fairly. This PR was authored by an agent working in PhotoCleaner, not by the hub. It came out of that repo's conformance sweep: the audit was run from a full clone of this repo ( The reason to look twice: Nothing is lost by rejecting it. The findings are reproducible on demand: python3 spec/audit.py PhotoCleaner # main
python3 spec/audit.py --branch develop PhotoCleanerAs of Take it, rewrite it from a fresh run, or close it. No objection either way, and no action needed from PhotoCleaner's side. The separate escalation issue #509 is on a different footing and stands on its own: |
|
Verified independently and adopting it. Per README.md, "the audit proves the result instead of accepting the agent's report of it", so a report authored by the audited repo is a claim until the hub checks it. I re-ran
The only differences are findings that postdate this report: Two follow-ups for the next re-audit rather than blockers here: The general rule this establishes, so the next repo does not have to guess, is going into |
Restores the forward-only invariant after I merged #508 without checking its base branch. ## What happened #508 was opened against **`main`**, not `develop`. I verified its content, its checks, and its review threads, and merged it without ever reading `baseRefName`. It landed as `048a442` on `main` alone. The branching model is feature to `develop` by squash, then `develop` to `main` by promotion merge. A feature PR merged straight to `main` puts content on `main` that `develop` does not have, which is exactly the divergence the forward-only rule exists to prevent. Left alone, the next promotion either conflicts or silently reverts the audit refresh, since `develop` would carry the older `reports/photocleaner/audit.md`. ## The fix `048a442` cherry-picked onto `develop`. Confirmed it is the **only** content commit `main` holds that `develop` lacks: ``` $ git log --oneline origin/develop..origin/main 048a442 Refresh the PhotoCleaner audit report and driftNotes (#508) 6501479 Promote the prose-gate fixes and the configure.sh sweep to main (#502) ... 100+ further entries, all promotion merges ``` Everything below `048a442` is a promotion merge commit, main-only by construction, which is topology rather than drift. After this merges, the two branches carry identical content again and the next promotion is clean. ## Two separate errors, worth naming **Mine**: I ran the full merge gate, checks, review coverage, unresolved threads, and an independent re-audit of the report's claims, and never checked which branch the PR targeted. A base-branch check belongs in that gate, and it was not in it. **The PR's**: a downstream conformance PR against the hub targeted `main`. That is the same class as the report-authorship question #508 raised, an agent filling a gap the instructions never addressed, and it argues for `AUDIT.md` stating the base branch explicitly alongside who may author a report. ## Verification ``` python3 spec/validate.py OK, 21 cataloged registry/repos.json parses prose_lint reports/photocleaner/audit.md --check charset --check dupword --check spelling clean editorconfig-checker (docker, canonical) clean ``` Content-identical to `048a442`, so no review of the report's substance is re-opened here. It was verified against a live `spec/audit.py PhotoCleaner` run before #508 merged, and every substantive claim was corroborated. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Closes the governance question #508 raised: may a downstream repo open a pull request against the hub to write its own audit report? ## Why there was a vacuum `AUDIT.md` said the audit is read-only and produces a report under `reports/`, and `AUDIT.md` section 10 said "the hub audits and the agent applies the fixes via target PRs". Neither ever said **who writes the report**, so an agent filled the gap, reasonably. ## The answer: the hub authors it The maintainer's call, and the argument that settles it is **efficiency, not principle**: > consider you want it in develop, and you want to audit it anyway, you are going to run the same effort, and the result would be the same if you agree with their audit That is correct and it dismantles the case I had been making. I argued a submitted report preserves downstream context the hub would otherwise rebuild. But **verifying the judgment dimensions is the audit**: confirming a verdict like "analyzers enforced, `TreatWarningsAsErrors` present" means reading the same files the audit reads. Only the deterministic subset is cheap. So a submitted report saves the **writing up**, which is the trivial part once the audit is done. The independence argument survives as a second reason, since a repo grading itself produces a claim rather than evidence, but on its own it would only have justified verifying a submission rather than declining one. ## A third reason #508 demonstrated **A submitted report is stale by construction.** It is a snapshot of one hub revision arriving at a later one. #508 was authored against hub `6501479` and merged at `839ecde`, and before adopting it I had to reconcile two findings that did not exist when it was written: `OPERATIONS.md` became universal in #507, and the merge-bot workflow was declared in #512. That reconciliation is inherent to the workflow, not incidental. ## What downstream still does, and it matters Unchanged, and it is where downstream context is worth most: - **File findings about the hub as issues.** The opposite of self-certification, and it has surfaced several real hub defects today: the merge-bot workflow that no spec required while `WORKFLOW.md` D8.1 graded it, `copilot-instructions.md` describing a pre-split `AGENTS.md`, `CODESTYLE.md` contradicting the markdownlint config, and D2.2 wording that nearly caused a real regression. - **Apply fixes to its own repo** per section 10. ## Also names the base branch `#508` targeted **`main`**, and I merged it without checking `baseRefName`. That put content on `main` that `develop` lacked, breaking the forward-only invariant, and needed a forward-port in #513. The branching model was already stated in `GOVERNANCE.md`, but not in the place an agent opening a conformance pull request against the hub would be reading. It is now stated here too. ## Verification ``` prose_lint AUDIT.md --check charset --check dupword --check spelling --check charset-unknown clean markdownlint-cli2 (docker, canonical) 0 issues editorconfig-checker (docker, canonical) clean python3 spec/validate.py OK, 21 cataloged ``` Prose only, no engine change. `AUDIT.md` is carried at `intent`, so downstream repos pick this up on their next re-vendor. ## What this does not solve Thirteen of twenty-one cataloged repos still have no committed audit report, tracked in `TODO.md`. This decision means the hub writes them, which is a capacity question rather than a governance one. Accepting unverified submissions would have closed the gap by lowering the bar rather than by doing the audits. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
The committed
reports/photocleaner/audit.mdwas dated 2026-07-23 and predated the release pipeline, so it still listed both branch rulesets as missing and the Dockerfile as dead weight. All of that landed, and release1.0.9shipped that same day. Re-audited againstmain@15b9b5b.Run stamp:
audit run 2026-08-01T15:30:19Z | hub 6501479What the re-audit found
Everything the old snapshot called a defect is fixed. The remaining findings are a different set, created mostly by this hub advancing rather than by the repo regressing:
GOVERNANCE.mdabsent,AGENTS.mdstill the pre-split single file, so neither verbatim region compares and all ten sections read as undeclared.markdownlint-cli2.jsoncandrepo-config/configure.shboth match a past hub revisionbuild-release-task.ymlhas novalidate-releasejob, though that repo's ownWORKFLOW.mdnames it in D2.2 and in scenarios S1, S4, and S10, and itsgithub-releasebody matches no hub revisiondevelopandmainreport identical findings, so the commit-count gap remains the benign promotion-merge ancestry artifact.Convergence
Six PRs are open against PhotoCleaner
develop, one per drift class per AUDIT.md section 10, each with a Copilot review on its head SHA, left for the maintainer to merge. They are listed in the report.Three hub-side defects this surfaced
Raised per AUDIT.md section 9 rather than resolved here, since each re-vendors fleet-wide and deserves its own change:
.github/copilot-instructions.mddescribes the pre-split file.Reviewing Carried Fleet Contentsays "Most ofAGENTS.mdis universal fleet law: every section that states a rule, as opposed to the two that describe this repository's own directory tree and devcontainer". After the split those sections are inGOVERNANCE.md, andAGENTS.mdcarries exactly two verbatim sections and no repo-specific ones. PhotoCleaner had to adapt the text on the way down, and every other repo carrying it inherits the stale description.CODESTYLE.mdcontradicts.markdownlint-cli2.jsoncon MD033. The prose still says "HTML elements are flagged" after the config gainedallowed_elements: ["details", "summary"]. This is the "when you change a behavior, search for prose that asserts the old one" rule, unswept.spec/readme-structure.mdassumes a public repository. PhotoCleaner is private, so shields.io cannot read its GitHub release, build, or commit data and every GitHub-sourced badge renders broken. Build Status and Releases state no behavior for that case.Plus two softer ones: the
HISTORY.mdmirror rule lives only in hub-onlyspec/readme-structure.md, so a downstream repo cannot point at the rule it is measured against; andWORKFLOW.mdD2.2's "skipped on smoke" is ambiguous enough that a Copilot review read it as the GitHub job status and proposed a change that would have coupledgithub-releaseto smoke through itsneeds.driftNotes
Dropped the stale claim that the report predates the release wiring, dropped the cross-repo comparison (the "Carried files carry no coordination references" rule bans a sibling repo named as an illustrative example, and a registry entry is the same shape of problem), and recorded that the repo is private while its Docker image is public, so the declared
github-releasechannel is not pullable by a consumer.Verification
spec/validate.py: "Spec validation OK: 21 cataloged, 0 backlog repos classify cleanly."scripts/repo_gate.py: eol 0 issues, sha-pin 0 issues.scripts/prose_lint.pyon the report: exit 0.markdownlint-cli2on the report: 0 issues.