Delete the stale PhotoCleaner driftNotes - #537
Merged
Merged
Conversation
A driftNote records a current deviation from the baseline, so a note left describing finished work is the drift the reconcile rule exists to catch. Both of PhotoCleaner's remaining notes had gone stale. The onboarding note still said the repo was not conformance-complete and pointed at a report for the open defects. Conformance round 4 landed on 2026-08-03 and spec/audit.py now reports clean, so the note records that instead. The visibility note claimed README.md carries Docker Hub shields only and gains the GitHub build and release shields when the repo goes public. That contradicts spec/readme-structure.md, which holds the README shape constant across repository visibility precisely so that going public is a visibility change and nothing else. The README already carries the full shield set, and its GitHub-sourced shields render broken while the repo is private, which is the accepted outcome rather than a shape to work around. The note now says that. The visibility fact itself is unchanged and the note stays, since the repo is still private and the github-release channel is still not consumer-pullable. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Contributor
There was a problem hiding this comment.
Pull request overview
Updates the PhotoCleaner entry in the hub registry to correct two stale driftNotes, keeping the registry aligned with current reality per the audit reconciliation workflow.
Changes:
- Updates PhotoCleaner
driftNotesto reflect current conformance status and README/badge behavior for a private repository. - Rewrites note text to avoid a README shape claim that contradicts
spec/readme-structure.md.
The previous commit rewrote the onboarding note to record that conformance round 4 had landed and that the audit reads clean. That is the thing AUDIT.md section 8 forbids: a driftNote records a current deviation, and once the deviation is resolved the note is deleted rather than left describing finished work, because hand-maintained prose drifts silently either way. Replacing a stale claim with a completion record only resets the clock on the same failure. The onboarding note is a completion record end to end, so it goes rather than being reworded. Nothing is lost that the entry does not already carry structurally in status, types, publish, and requiredSecrets. The first-release sentence goes from the release-mechanism note for the same reason. The mechanism it describes, a static Docker Hub secret where the fleet default is OIDC, and a two-phase release trigger, is a live deviation and stays. The date a past version shipped is history. The visibility note stays as corrected, since the repo is still private and the declared github-release channel is still not consumer-pullable, which is a current deviation rather than a finished one. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The visibility note explained that README.md carries the full shield set because the README shape is constant across repository visibility. That is spec/readme-structure.md restated, not a deviation from it. A repo doing exactly what the spec requires earns no note, so describing the conformance is the same category error as describing finished work. What remains is the deviation itself: the repo is private, so the declared github-release channel is not consumer-pullable and the GitHub-sourced shields render broken until the flip. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
ptr727
added a commit
that referenced
this pull request
Aug 3, 2026
…ndor groundwork (#542) Six commits, all from one session. Merged as a **merge commit**, never squashed, per the branching model. | Commit | PR | What it does | | --- | --- | --- | | `1ab9b32` | #537 | Deletes three stale PhotoCleaner `driftNotes` that described finished work | | `bf746aa` | #535 | Buckets `TODO.md` by the surface each entry changes, records five issues verified complete, refreshes the divergence ledger | | `69276d1` | #536 | Adds the byte-locked `AGENTS.md` "Fleet Bootstrap" section, the host-wide `fleet-bootstrap` block, and the `AUDIT.md` routing that sends an un-stood-up repo to `STANDUP.md` first | | `530dc0d` | #539 | Records two `gh-write-guard` limits found by running it: a write inside a script is unseen, and a push followed by a newline over-blocks | | `5f4c17f` | #540 | Makes `configure.sh check` verify what the payloads declare, closing a false clean where a `jq` failure left every setting reported as passing while nothing was compared | | `a549572` | #541 | Reports a verbatim section that never arrived as **absent** rather than as hand-modified | ## Why this promotion matters more than most Two of these change what the fleet is measured against, so until they reach `main` every downstream audit compares against ground truth that predates them. **#536 is the one with reach.** A downstream agent had no way to discover this repository. `AGENTS.md` is carried at `intent`, and the hub's only self-reference described *the hub*, which is false about a downstream repo, so an agent adapting the file correctly deleted it. Four repos now hold no hub reference at all and one holds no `AGENTS.md` either. The replacement is `verbatim` so adaptation cannot remove it, declared in `spec/files.json` and classified in `spec/section-model.md` so the audit reports its absence as drift rather than losing it silently. **#540 closes a false clean.** `check_settings` streamed its payload from a process substitution, and a `jq` failure there leaves the loop body unexecuted without tripping `set -e`. Every static setting reported as checked and passing while nothing was compared. Verified by negative test rather than by a clean pass: a malformed `settings.json` now fails with exit 1, an extra live rule fails the rule-set assertion, and a changed `copilot_code_review` parameter fails the parameters assertion. **#541 corrects a report that was actively misleading.** It accused seventeen repos of hand-editing `AGENTS.md` sections they had never been given. They still hold the pre-split monolithic file, so the sections are simply absent. A hand-edit is reconciled against a local decision, an absence is carried, and the report was naming the wrong one. ## Fleet state behind this Seventeen downstream re-vendor pull requests merged alongside this work, each gate-checked at merge time and each verified after. Four repos had `configure.sh` withdrawn from their re-vendor when review found they carry `ruleset-*.json` payload names the canonical does not resolve, which would have left `apply` and `check` aborting on files that do not exist. That payload migration is still owed and is tracked in `TODO.md`. ## Expected immediately after this merges The divergence ledger currently reports the hub itself as not carrying "Fleet Bootstrap" and as owing a `configure.sh` re-vendor. That is the ledger reading each repo's `main`, honestly, before this promotion. Regenerating after the merge is what makes the report meaningful again, and the `configure.sh` re-vendor list will collapse as repos take the corrected script. ## Verification `spec/validate.py` OK (21 cataloged), diff-scoped `prose_lint` clean, `markdownlint-cli2` clean, editorconfig clean, `gh-write-guard --selftest` PASS, 157 `prose_lint` unit tests pass.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A
driftNoterecords a current deviation from the baseline, and AUDIT.md section 8 is explicit about what happens when one is resolved:PhotoCleaner's notes carried three things that are not current deviations. This PR is purely subtractive - three claims removed, nothing added.
Found while running
spec/audit.py PhotoCleanerfor that repo's round 4 conformance work. The audit does not flag these itself: its stale-note check only fires when a repo audits clean, and PhotoCleaner did not until the round landed.1. The onboarding note, deleted
Round 4 landed and
spec/audit.py PhotoCleaner --branch developnow reports clean atdevelop@252f5c5, so the deviation is resolved and the note goes. It is a completion record end to end, and nothing is lost that the entry does not already carry structurally instatus,types,publish, andrequiredSecrets.2. The first-release date, deleted
The mechanism around it stays and is a live deviation: a static Docker Hub secret where the fleet default is OIDC, plus a two-phase release trigger. The date a past version shipped is history.
3. The README shape claim, deleted
This contradicted
spec/readme-structure.md, which holds the README shape constant across repository visibility precisely so that going public is a visibility change and nothing else. PhotoCleaner's README already carries the full shield set, so the note described a reduced private variant the repo does not have and the spec does not want.There is no replacement sentence. A repo doing exactly what the spec requires earns no note, so describing the conformance would be the same category error as describing finished work.
What survives in that note is the deviation itself: the repo is private, so the declared
github-releasechannel is not consumer-pullable and the GitHub-sourced shields render broken until the flip.Result
PhotoCleaner keeps two driftNotes, both describing active deviations.
Verification
spec/validate.pypasses (21 cataloged, 0 backlog).Authored from the downstream repo, per the rule that a downstream repo files hub findings rather than self-certifying. This changes only PhotoCleaner's own registry entry - no spec, no fleet-wide rule.
🤖 Generated with Claude Code