We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
There was an error while loading. Please reload this page.
docs: mark what the fluent API research produced, and where it was wrong The page was written before any of it was built. #16 implements steps 3 to 6 of its sequence and departs from it in three places, so the page now says so at each of them rather than reading as a plan that is still pending. The three departures, each in a quote box where it happens: Question 13 called the missing copy override a defect. It is not one - the copy keeps its light, because the sections are cloned with it, and losing the scheduler binding is the only correct outcome, since a copy goes into another instance and a bound one would throw on the first block change. Section 3.1 called for a mutable anvil builder, with reuse across dimensions as the argument. That argument does not hold, and following it would have left three builders with two semantics: the same line taking effect on one and silently doing nothing on the other. Step 6 of the sequence wanted a third ServerStack entry. It did not get one, because the comparison holds only while the two servers differ in the loader and the chunk type and in nothing else. Section 7.1 predicted that a mutable light builder breaks sharedStateIsSafelyPublished. That was verified rather than assumed: one field from final to mutable turns the rule red with the predicted message. The blocker in 1.2(f) is marked as cleared, and the lead no longer claims the page describes nothing that exists - it now says to read it as a record and that the code wins where the two disagree. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
docs: give the wiki navigation that survives a deep link Home.md was the only page reaching the other 25, and had no inbound link itself. Between the content cluster and the seven Gradle pages there was exactly one bridge outside it, so a reader arriving by search never reached the other half. Four long pages also ran hundreds of lines past their last internal link — Anvil Chunk Loader carries its last one 247 lines before the end, including the section the README sends the reader to. _Sidebar.md and _Footer.md are new and render on every page. The sidebar groups all 26 pages into four; a group folds to its landing page only where that page lists every subpage, which is why Research: Fluent API stands beside Research and the Gradle cluster stands open. Group labels are bold text rather than headings, so the one-title-per-page rule is avoided rather than broken. Home keeps the full index — the sidebar is not rendered on _pages or _history, and narrow viewports push it below the body. It gains an H1, a "The measured record" rubric that finally gives "These two pages are the measured record" the two entries it refers to, deep links written as statements rather than directions, and a gloss per rationale page so a reader looking for one decision no longer has to guess. Five long pages gain a "## Contents" block in the form Project Status already uses. Two links to a "What the ± is" anchor that never existed now resolve to "The interval after a number" — the one definition the documentation standard calls authoritative. No page renamed, split or deleted; no sentence, link or figure removed. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QzEdy5fN5JKGxJo8gwtNeu
docs: check the fluent API sketches against falco-archunit The page was written before cb30cf0 added the module, so every builder in it was a proposal against rules nobody had read. Section 7 closes that: all five proposed types against the 39 rules as they stand at 4c86c96. One sketch fails. ChunkLightScheduler.Builder needs an Executor field for its executor(Executor) slot, and SHARED_OBJECT selects any class holding a field whose raw type sits in java.util.concurrent. The condition then wants every non-static field final, volatile, or written only from a constructor or a synchronized method - which a mutable builder is not. False positive in intent, true positive in mechanism, and the mechanism runs in CI. The recommendation is an immutable builder, or a record: it passes without touching a rule that was red against a real defect and caught it. Two rules confirm decisions the page had already reached. The module isolation rules forbid any dependency between the three modules, and the javadoc of isolated(...) cites the same ServerStack passage section 4.2 argued from - which is why variant (D) works and (A) and (B) could not: the cast lives in user code, so neither module names a type of the other. And lightCoreKnowsNoMinestom backs putting the Overrides helper in MinestomBlockLightSource rather than in the registry-free interface. The rest costs annotations: @ApiStatus.Experimental on all five, since nested types are in scope, and final on the two builder classes and Overrides. Section 7.4 records what this does not establish - the rules were read, not compiled against, and two of them state limitations of their own. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
docs: add the fluent API research and link it from Home Asks whether falco-anvil, falco-light and falco-instance should get a fluent construction surface, and in what shape. The page describes no existing API: every builder, slot and terminal method in it is a proposal, and the lead says so before anything else, because a reader arriving from Home would otherwise take the code examples for something callable. The finding that outweighs the API question is the blocker in section 1.2(f): FalcoInstance accepts FalcoChunk only while FalcoLightingChunk extends DynamicChunk, so the two modules cannot be combined today. Both demo stacks run on InstanceContainer for that reason. A facade selling "the whole Falco stack" cannot offer the one combination that would be its argument, so the blocker has to be cleared before any API work. What the page recommends: nested builders in all three modules, adding five types and no top-level ones; no fourth falco-api module, because the claim that one follows from the module structure does not hold; the facade as a wiki recipe over existing types; and no observer mechanism of Falco's own where Minestom's EventNode carries. The evidence box carries the two caveats a reader has to know. The Minestom line numbers mix 26.1.2 and 26.2 - types and signatures are identical in both, line numbers are not. And the page is evidenced against 26ac23e: e45dc1e has since fixed the data race it reports in 1.2(c), and cb30cf0 added falco-archunit, whose PublicApiTest binds every builder sketched here against rules the page never checked. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>