docs: correct six stale claims in crossrepostatus.md and record two unrecorded cross-repo states - #39
Merged
Conversation
…t source
The file is a status snapshot that nothing validates, so it drifts silently.
Every claim below was re-checked against the poms on origin/main, Maven Central
metadata, or an opened CI run -- not carried forward from the previous audit.
Corrected:
* Tool-version row: Checker 4.2.2 -> 4.2.3, spotbugs 4.10.4.0 -> 4.10.4.1,
spotless 3.10.1 -> 3.10.2, nullaway 0.14.0 -> 0.14.1, surefire 3.5.6 ->
3.6.0. The row's identity claim held -- all four repos really did carry the
same values -- only the recorded numbers lagged. This is the SECOND time
this row has gone stale exactly this way, and the note added after the first
occurrence did not prevent the second, so the note now says what would
(deriving the row from the poms) instead of asking harder for manual
updates. Every value was additionally probed against maven-metadata.xml.
* do-not-bump registry: slf4j-api 2.0.18 -> 2.0.19. Central's <release>
element points at 2.1.0-alpha1, which is why a naive probe reads wrong here;
the row now says to read the <version> list.
* The log4j pin is no longer a security pin. Both repos moved to logcaptor
2.12.7, whose own pom declares <version.log4j>2.26.1</version.log4j> -- the
exact version the pin forces -- so it changes nothing today and is a floor
guard. Both repos' pom comments still claim "logcaptor ... requests 2.25.3",
which is now false; the row names that and the two options (reword, or drop
the pair and re-confirm the enforcer), without picking one.
* "First green CI observation: srcmorph, 2026-08-31 ... treat BAF and jllama
as pending" was wrong in both halves. jllama was FIRST: the v5.1.0 release
dispatch (run 33275073456, 2026-08-29, success) is green including the
collision-checked native merge and all three smokes. BAF is green too
(run 33866409744, job level). sb's is green as of run 33962076725. Nothing
is pending; each observation now cites a run id.
* "Fat-jar signing -- unverified in production for BAF and srcmorph" is
closed. BAF v1.8.0 attached the fat jar plus its .asc; srcmorph v1.2.0
attached 52 assets, 17 fat jars each with a matching .asc, both uploaded by
github-actions[bot]. Noted that only jllama also attaches .sha256, so the
old ".asc/.sha256" phrasing described one repo, not the convention.
* The GitHub Actions "two pin styles coexist" table described a state
resolved on 2026-08-29 (sb 32b6e3c, BAF c01a95e unpinned codeql-action and
setup-gradle). Replaced with the actual uniform state, enumerated from every
uses: in the four repos.
* GPG preflight: "red-by-design on refs without the secret (fork PRs)" was too
narrow. The jobs declare environment: maven-central and GitHub withholds
environment secrets from ANY pull_request context, same-repo branches
included -- shown by sb run 33962076725, where the two preflights are the
run's only red jobs.
Added, because both are cross-repo states the file did not mention at all:
* srcmorph main cannot resolve its dependencies until jllama releases 5.2.0.
The forward pin is deliberate and documented in the pom; what was not
recorded is that 8 PRs (#198-#205) have been merged since 2026-09-01 with a
red pipeline -- and not only on main: every one of those pull_request runs
failed too, since resolution dies before the first test compiles. For that
window srcmorph's tests, SpotBugs, spotless, PIT and bytecode gates have
asserted nothing.
* A standing caveat that a run's presence proves nothing here: pushes to main
are cancelled in the start-gate window, and merging a PR cancels its own
run. jllama is the live case -- runs 898 through 905 are all cancelled, so
the newest completed run is 897 (b10797, failed) and nothing on the current
main has been validated by CI.
Could not verify, stated as such rather than softened: the four exact-pinned
third-party actions (scorecard, osv-scanner, cuda-toolkit, install-vulkan-sdk).
This environment's proxy answers 403 for github.com/releases/latest and
api.github.com, and the GitHub tooling is scoped to bernardladenthin/*.
The checksum drift table was re-run and is clean: all 9 rows match, with the
expected copy counts.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01AnNYn8W1xuVxVJtyL34GyH
The audit left the do-not-bump row with two options and no verdict. The verdict is: keep the pin, reword the comments. Both pom comments in BAF and jllama claimed logcaptor "requests 2.25.3", which stopped being true at logcaptor 2.12.7; both now describe a lower bound (BAF 3fbf138, jllama on claude/log4j-floor-guard-and-langchain4j). Dropping the pin was the alternative and is recorded as rejected rather than silently omitted, so a future dependency sweep does not re-open it as a stale dependency: it costs nothing to keep and stops a logcaptor release that fell back to an affected line from regressing the test classpath. The row also now names the logcaptor version explicitly and states what the pin is NOT related to. That last part is not padding: the log4j pin and the Java 8 class-file floor work landed in the same week and were conflated once already; the floor is slf4j-simple-instead-of-logback plus checker-qual at provided scope, and it concerns the shipped artifact, while both log4j artifacts are test scope and reach no artifact at all. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AnNYn8W1xuVxVJtyL34GyH
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
2 participants
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.
Summary
crossrepostatus.mdis a status snapshot that nothing validates automatically, so it drifts silently. Every claim below was re-checked against the poms onorigin/main, Maven Central metadata, or an opened CI run — never carried forward from the previous audit.Corrected
maven-metadata.xmlslf4j-api2.0.18<release>points at2.1.0-alpha1, which is why a naive probe reads wrong here)<version.log4j>2.26.1</version.log4j>. Decision recorded: keep the pin, reword the commentssuccess, incl. the collision-checked native merge and all three smokes). BAF green (33866409744, job level), sb green (33962076725). Nothing pendingv1.8.0attached the fat jar +.asc; srcmorphv1.2.0attached 52 assets, 17 fat jars each with a matching.asc32b6e3c, BAFc01a95e)uses:in all four repospull_requestrun — the jobs declareenvironment: maven-centraland GitHub withholds environment secrets from any PR context. Shown by sb run 33962076725, where the two preflights are the run's only red jobsAdded — two cross-repo states the file did not mention at all
maincannot resolve its dependencies until jllama releases 5.2.0. The forward pin is deliberate and documented in the pom. What was not recorded: 8 PRs (#198–#205) have been merged since 2026-09-01 with a red pipeline, and not only onmain— every one of thosepull_requestruns failed too, since resolution dies before the first test compiles. For that whole window srcmorph's tests, SpotBugs, spotless, PIT and bytecode gates asserted nothing.mainare cancelled in the start-gate window, and merging a PR promptly cancels its own run. jllama is the live case: runs 898–905 are allcancelled, so the newest completed run is 897 (b10797, failed) and nothing on the currentmainhas been validated by CI.Could not verify — stated as such rather than softened
The four exact-pinned third-party actions (
ossf/scorecard-action,google/osv-scanner-action,Jimver/cuda-toolkit,jakoch/install-vulkan-sdk-action). This environment's proxy answers403for bothgithub.com/…/releases/latestandapi.github.com, and the GitHub tooling is scoped tobernardladenthin/*.Meta
The tool-version row has now gone stale twice, the same way, and the note added after the first occurrence did not prevent the second. Rather than asking harder for manual updates, the note now says what would actually fix it: deriving the row from the poms. That is left as an observation, not implemented here.
Test plan
repo1.maven.org/…/maven-metadata.xmlRelated issues / PRs
Pairs with the pom-comment rewrites in BitcoinAddressFinder and java-llama.cpp that this file's log4j row now points at.
Checklist
CONTRIBUTING.mdandCODE_OF_CONDUCT.md🤖 Generated with Claude Code
https://claude.ai/code/session_01AnNYn8W1xuVxVJtyL34GyH
Generated by Claude Code