From cc6228a1b360ab45e03c44092856a5b526061c9e Mon Sep 17 00:00:00 2001 From: Pieter Viljoen Date: Mon, 3 Aug 2026 16:13:38 -0700 Subject: [PATCH] Record what a run observed rather than what it predicted Two findings from the review on the promotion, and the second is the one that matters. The Blog audit report closed a paragraph with a prediction, that the same four findings "will appear against every fleet repo the moment that change promotes". A report records what a run observed. It also turned out to be wrong: the change promoted, the findings were traced to spec/audit.py asserting a bypass list the config had deliberately stopped managing, and #551 removed that assertion, so the four do not appear. A prediction in a report is stale the moment reality diverges and nothing re-checks it, which is the same failure the driftNote rules already name in the registry. The sentence now ends at the reason the findings were not counted and hands off to the enumeration that follows. The PENDING_MARKERS comment put its relative clause next to the wrong noun, so "a registry driftNote that assert" read as a disagreement even though the subject is the plural phrases. Reordered so the clause sits with what it describes. Co-Authored-By: Claude Opus 5 (1M context) --- reports/blog/audit.md | 2 +- spec/audit.py | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/reports/blog/audit.md b/reports/blog/audit.md index 718efbda..8a0b41ce 100644 --- a/reports/blog/audit.md +++ b/reports/blog/audit.md @@ -14,7 +14,7 @@ First audit of this repo. It was stood up on 2026-08-01 and reached a proven rel ## Already Owed by the Hub's Own Develop -This audit reads hub `main` (`3a7cc64`), which AUDIT.md section 1 makes the ground truth. Re-running it from a tree at hub `develop` (`362aec8`) reports two additional re-vendors and two DEFECTs, all four from [#545][pr-545] taking `bypass_actors` out of the three ruleset payloads about an hour before this run. They are recorded here rather than counted, because measuring a repo against un-promoted hub content reports work in flight as a conformance failure, and the same four will appear against every fleet repo the moment that change promotes: +This audit reads hub `main` (`3a7cc64`), which AUDIT.md section 1 makes the ground truth. Re-running it from a tree at hub `develop` (`362aec8`) reports two additional re-vendors and two DEFECTs, all four from [#545][pr-545] taking `bypass_actors` out of the three ruleset payloads about an hour before this run. They are recorded here rather than counted, because measuring a repo against un-promoted hub content reports work in flight as a conformance failure. What the re-run observed was: - `repo-config/develop.json` and `repo-config/main.json` become stale carries, re-vendored the same mechanical way as the rest. - The live `develop` and `main` rulesets then diverge from the payloads, because both still carry the `RepositoryRole` admin bypass the new payloads no longer declare. Closing that is a repository-settings change on a protected branch, so it is the maintainer's to apply, not an agent's. diff --git a/spec/audit.py b/spec/audit.py index c7f99966..03c707d3 100644 --- a/spec/audit.py +++ b/spec/audit.py @@ -47,7 +47,7 @@ # That was a field the fleet config had deliberately stopped managing. # Two tools comparing one field under opposite policies is the defect, rather than the field's value. RULESET_SUBSET = ["name", "target", "enforcement", "conditions", "rules"] -# Phrases in a registry driftNote that assert work is still outstanding. +# Phrases that assert work is still outstanding, matched against a registry driftNote. # Deliberately specific, so a note recording a permanent deviation must not match. # An example of one that must not match is a note reading that there is no get-version-task and validate-task is relied on instead. PENDING_MARKERS = ["pending", "not yet", "owed", "todo", "still", "behind", "missing", "absent"]