There was an error while loading. Please reload this page.
Take the coordinates to 1.0.0, which is the release that carries the BOM 1.0.0 shipped on 2026-08-03 and is the first release with the chunk, instance and shared instance work in it. Installation told readers to depend on 0.3.0. Two statements were not just stale but wrong once 1.0.0 existed. The BOM snippet carried a snapshot coordinate and a comment explaining that the release endpoint did not serve falco-bom yet; it does now, verified against repo.onelitefeather.dev, so the snippet is an ordinary coordinate and the workaround is gone. The snapshot section said 0.3.0 is the latest release and 0.3.1-SNAPSHOT is what the endpoint serves; it is 1.0.0 and 1.0.1-SNAPSHOT. Build Setup and Versioning and Releases quote files rather than describe them -- apiBaselineVersion, the version assignment, the release-please manifest -- and every quoted value was checked against the file it comes from rather than adjusted by pattern. Statements dated to a version were left as they are: "carried out on 2026-08-01 against Falco 0.3.0", "falco-instance shipped in 0.3.0", and the tag list naming v0.2.0, v0.2.1 and v0.3.0 are all true of when they were written, and rewriting them would turn a record into a claim about today.
docs: write down what checkApiCompatibility does and why it looks odd #20 added a binary compatibility gate and left its reasoning nowhere, since build files here carry no comments. Two details of that configuration look like something to tidy up and must not be, so they are written down rather than left to be rediscovered. The baseline resolves through a detached configuration because Gradle substitutes an external dependency with a project of the same group and name from the same build, regardless of version - a named configuration brings the substitution back and the check then compares the local jar against itself. And the new side has to be the archive of the jar task rather than the task, which fails the same silent way. Both were found by removing a public method on purpose and watching the check stay green, which is also why the doFirst guard exists: a compatibility gate that cannot fail reads as coverage while providing none. apiBaselineVersion is the one line a release can leave stale - Release Please rewrites version through its marker and knows nothing about this property. The per-module check table gains the task; it listed only jacoco for the three published modules. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
docs: add the architecture rules page and count seven modules falco-archunit landed in the repository and the wiki still described six modules, with two build tables that did not know the seventh. The stale counts are corrected in Build Setup, Project Status, Publishing, Dependency Management and Benchmarks and Demo, and the two tables in Testing and Javadoc now say what check and javadoc do for a module whose only source set is test. The new page covers what the 39 rules enforce, why the module sees only main sources — which is what lets it catch a public method carrying a package-private type, a mistake no test inside the modules can see — and which invariants it deliberately cannot check: synchronized blocks, the ordering of the seqlock protocol, and the claim that no CPU-bound work happens while a lock is held.
docs: state every measured claim with its conditions and its limits Reworks all 21 wiki pages so that no performance claim can be read as saying more than the measurement supports. The measurement model is now stated once and authoritatively: JMH's score error is the half-width of a 99.9 % confidence interval over the measurement iterations of a single fork, which bounds dispersion within one JVM and says nothing about run-to-run variance. Every published comparison was re-graded against a mechanical significance rule and is labelled supported, indicative-only, or not usable. Ratios whose intervals overlap no longer carry a factor. The 8.00x loader figure is withdrawn. The two-thread 1.9x now carries the independent repeat that did not reproduce it next to the number rather than two pages away. What those repeats do establish - Falco's read time repeats at every thread count and Minestom's does not repeat above one - is stated as the asymmetry it is, not as a factor. Each page separates what was measured from what is reasoned from the code and what is judgement, cites the type or method behind every structural claim, and carries threats-to-validity and reproduction sections precise enough for a third party to attempt replication. Environment facts that were never recorded are marked as gaps rather than filled in. No measured number was changed.
Document the Gradle build setup