[bernardladenthin]

Summary

• policies/lombok-config.md: the canonical lombok.config gains lombok.addNullAnnotations = jspecify with its reason -- under @NullMarked the parameter of a Lombok-generated equals(Object) reads as non-null while Object.equals accepts null; SpotBugs 4.10.5 (the first release that reads JSpecify) reports NP_METHOD_PARAMETER_TIGHTENS_ANNOTATION per class (27 in java-llama.cpp and in BAF on 2026-10-12), and a consumer's nullness checker believes the same wrong contract. The table row says what Lombok writes and why a suppression was not the answer.
• crossrepostatus.md: the tool-version row re-derived 2026-10-12 (spotbugs-maven-plugin 4.10.5.0, the one value behind), with the usual note of what was behind and how it was found; the "Re-checked" paragraph gains the 2026-10-12 sweep (SpotBugs and the Lombok answer, the BAF inner class made static, JLine 4.4.8 in the agent -- only jansi/AnsiConsole and shell/impl/HelpCommands differ from 4.4.7, none of the files the carried fixes touch -- srcmorph's managed checker-qual 4.3.1, llama.cpp b11558 -> b11574 in java-llama.cpp, nothing else moved since the day before).

Test plan

• Affected unit / integration tests pass locally (documentation only; the lombok.config text is the one the three Lombok-using repositories carry byte-identically, checked by their shared-files jobs)
• CI is green on this branch
• Docs / CHANGELOG updated where applicable

Related issues / PRs

The sweep this documents: bernardladenthin/java-llama.cpp#533, bernardladenthin/BitcoinAddressFinder#387, bernardladenthin/srcmorph#225 and bernardladenthin/streambuffer#179.

Checklist

• I have read CONTRIBUTING.md and CODE_OF_CONDUCT.md
• My commits follow Conventional Commits
• No security-sensitive changes (if there are, I have notified the maintainer privately per SECURITY.md)

🤖 Generated with Claude Code

https://claude.ai/code/session_01AytmJF9faEiQEVt6eetQS2