PathWeaver

The diagnostics work below was briefly numbered 0.5.4 and held back rather than published: on its own it added no capability, no coverage and no speed, and nobody should update a modpack for a release that only stops the mod misreporting itself. It ships as part of 0.6 instead.

Coverage

• Spiders path off-thread. WallClimberNavigation overrides moveTo(Entity, double) without calling super, so the dispatch marker never ran for it and every spider chasing a player resolved its path on the server thread — while /pathweaver mobs counted spiders as eligible. Third instance of one mixin mistake; NavigationOverrideCoverageTest now derives the overriding navigation subclasses from Minecraft's own bytecode so a future one cannot silently opt out.

The default now explains itself

• The startup log says WHY UNSAFE is the shipped default. It already warned that the denial had been ignored and that searches run alongside unaudited code. What it never said is the reason, which is what turns that from "this mod ships recklessly" into a trade an operator can evaluate: the checked tier denies every family on an ordinary modded pack — measured at 0 of 187 eligible mob types on a 221-jar server pack — so shipping it as the default would ship a mod that does nothing. It is now stated as a trade, explicitly not as a safety claim, and followed by what to actually do: run it on a copy of your world, keep the setting if nothing looks wrong after a few sessions, switch to AUDITED and report it if something does.

Diagnostics that agree with the gates

A cumulative review of everything since 0.5.0 and an adversarial concurrency bug hunt. The bug hunt found no blocker and no high-severity defect, and said so explicitly rather than padding — the epilogue pairing, the install-staleness checks, the evaluator clone, and the pool's generation isolation were all attacked and held.

Fixed

• /pathweaver mobs called every land family eligible while dispatch refused all five. Removing the command's early return so swim mobs stopped being under-reported had a cost nobody priced: the table is now printed in the one state where asking SafetyGate.isAllowed alone is wrong. Measured, not argued — isAllowed(Walk)=true against canDispatch(Walk)=false. The verdict consults the land registry, the command reads the live latch rather than a constant, and both halves are pinned by mutations that were compiled and observed to fail.

• deniedFamilies meant two different things in two places. On the same server in the same second, the startup log said deniedFamilies=0 and /pathweaver status said deniedFamilies=6. Both were right — the log counts what is enforced, status counted what the scan found before the tier waived it — and one label with two meanings is the class of defect this release exists to end. Status now prints deniedByScan= and enforced= separately; the log keeps the name the README teaches.

• A mob held back by its PathFinder was blamed on a mod, including when it was vanilla's. The line named the class with getSimpleName(), which is empty for an anonymous class, so a real pack produced navigates with , a mod-supplied PathFinder. Naming it properly showed what it was: Warden$1$1, a PathFinder subclass vanilla itself constructs. It now falls back to the full name and says "a PathFinder subclass" rather than accusing a mod.

• The command told operators that wall-climber chases stay synchronous — in the release whose headline is that they no longer do.

• The startup banner and /pathweaver status reported "ACTIVE, all six families" while five of the six were being refused every tick. Dispatch consults Fabric's land path-type registry latch in addition to SafetyGate; the two reporting sites did not. On a pack where that verification fails, the mod announced itself fully active, dispatched rose only from squid and fish, and /pathweaver mobs said the opposite — the mod's own diagnostics contradicting each other on the first question an operator asks. All three reporting sites now answer through one predicate, SafetyGate.canDispatch — four, in fact: /pathweaver mobs was open-coding the same rule a fourth time.

  Precisely what is shared, because an earlier draft of this entry overstated it: dispatch does not call canDispatch. It evaluates isAllowed, then requiresEmptyLandRegistry, then the latch, as three separate steps. canDispatch is a reconstruction of that sequence for the reporting sites, and an unpinned reconstruction is exactly how this bug became re-introducible twice — requiresEmptyLandRegistry could be replaced with return false and canDispatch reduced to isAllowed, each leaving all 289 tests green. SafetyGateDispatchParityTest now asserts the reconstruction against the sequence over the whole input space rather than against itself, and the one-argument convenience wrapper that hid the call site is deleted rather than tested beside.

  The land-registry half covers all five land-derived families, not just the exact Walk class. This is the third time a diagnostic has been caught disagreeing with what the gates actually do.

• A setup failure before registration was swallowed entirely — no outcome, no counter, no log. Everything from the attribute captures through the evaluator clone runs before the request reaches the sink, and the catch only recorded an outcome if it had. A deterministic failure there meant the mod did nothing, forever, while reporting itself as working. It is now counted whether or not registration happened — as SETUP_FAILED when the request had already been counted as dispatched and SETUP_FAILED_PRE_DISPATCH when it had not. The split is at markDispatched, not at registration — those are different events, and choosing on the wrong one left a single outcome that was simultaneously "wasted dispatched work" and "not part of dispatched". Logged once per server session. The reachable trigger is a third-party evaluator whose no-argument constructor throws when invoked outside its own construction path: canClone proves a constructor resolves, never that it runs.

• The coverage contract treated an omitted require as safe. ASM only visits values that are present, so require arrived as null whenever it was left out — and null was read as fine. What makes omission safe is injectors.defaultRequire: 1 in the shipped config, which the test read for the mixin list and never consulted for this. It now resolves require the way Mixin does. (That was verified by hand-mutating the config both ways during development; it is not pinned by a shipped test, and saying otherwise here would have been a claim the repo does not support.)

• That contract's declared side was gated on a literal Mob receiver. Every entity call in all six evaluators does have owner Mob on 26.1.2 — verified — but a version emitting the same call with a LivingEntity static type would have emptied the declared side and left every assertion in the class passing over a live attribute race.

• Both worker ThreadLocal captures now happen inside the try. Only an OutOfMemoryError could have separated them, but the residue is the exact failure both javadocs warn about: a step height left published on a pooled thread and inherited by the next mob scheduled onto it.

• The banner blamed the compatibility tier for refusals it did not cause. A family failing only the clone check got the full "you opted into AUDITED" lecture and advice to edit trustedMods, neither of which would have changed anything.

Documentation that was actively wrong

• DESIGN.md §3 still said flying and amphibious evaluators were ineligible. They have been the default async path since 0.4.0. Anyone auditing the threading story from that file would have concluded axolotls, turtles, drowned, frogs and every flying mob were synchronous.
• The recompute seam's javadoc claimed vanilla has two outcomes. It has four, and the whole table is now written out — including the exit where a claim is still dropped, which is recorded as roadmap 2g rather than papered over. That is not a regression (0.5.0 dropped it on all three branches) and re-applying it there is precisely the 0.5.1 bug, so it needs the request to carry its origin rather than a widened condition.
• A javadoc describing rollbackOptimisticTarget was sitting above abortFailedInstall. Two more of the same: a javadoc in RequestOutcome and one in PWNavigation each sat directly above another javadoc, documenting nothing, and an @param dispatchCounted named a parameter that had been replaced by stage.
• The README's eligibility numbers were measured with the wrong instrument. It quoted 187 of 187 at the shipped default, from a harness that never inspects the PathFinder a mob actually holds. /pathweaver mobs — the thing a user can run — says 184 of 187, holding back the two spiders and the warden. Nothing regressed; the old number was optimistic. Every figure in that section has been re-measured on 0.6.0 and the claim that 0.4.0 dispatched the first third-party evaluator is withdrawn: it never dispatched, and direct measurement now says so.
• The release page claimed path equivalence for "all seven evaluator families". There are six, and the seventh row in the harness output is a spider whose third-party PathFinder means it never dispatched — so its "IDENTICAL" compared a synchronous path with itself. The claim also read as a proof where the README says, correctly, that this is one static scenario per family and that flying equivalence is not guaranteed by the design at all. Corrected in the README, the changelog and the Modrinth page. (The underlying result is real and is new: until 0.6.0 only Walk and Swim had an oracle comparison, and all six now have one.)
• The AUDITED + all-nine-trusted row was quoted without the setting it was measured under. allowModdedMobAsync defaults to false, and at that tier the origin gate then refuses 98 of the pack's 187 mob types. The honest pair is 86 of 187 at stock settings and 184 with the bypass on. The old row said 185, then 184, and never said which.
• tools/scan_pack.py counted mixin configs rather than mods in its totals line, and counted PathWeaver itself among the mods claiming a pathfinding target — printing 22, then 21, where the README says 20. The documented figure was only reproducible on a directory with PathWeaver deleted from it, which is not a directory anyone has. It now counts distinct third-party mods.
• PLAN.md was a 0.2.3 artifact sitting in the repo root, whose "Future boundary" section stated no engine work remained after 0.2.2 — beside a roadmap describing 0.6 through 1.0. Archived to docs/PLAN-0.2-archive.md. DESIGN.md's product decision still said "hold publication", reversed at 0.3.0 and four releases ago.

Added

• A worker-reachability analysis (src/test/java/dev/pathweaver/reach/), the first step of the 0.6 plan to replace hand-written hazard lists with derivation. It is a discovery aid, not evidence. An earlier draft of this entry cited it as corroborating that no attribute hazard remains; a review showed it silently truncated in three places that contradicted its own stated guarantee. Those are fixed — it now resolves interface defaults, records every truncation instead of swallowing it, and no longer maps a receiver onto a type that does not implement it. The numbers moved from 1,735 reachable / 0 unresolved / 12 hazards to 2,060 / 168 / 45, which is what an honest version of the same walk looks like. Details in docs/ROADMAP-0.6-archive.md §6. It found no unknown bug. What building it taught is recorded there too: the naive version is useless rather than imprecise, reporting 1,220 hazards including the client renderer.
• tools/scan_pack.py, which measured why AUDITED leaves nothing eligible: 20 mods in a real 221-jar server pack claim a watched target, any one of which denies everything, and 14 have no audit. Nine of those 14 touch only BlockBehaviour$BlockStateBase and are not pathfinding mods at all. The tool over-approximates on purpose — it reads mixin configs, not what the injected code reaches — so it flags five that PathWeaver's own scanner clears. The scanner names nine blockers on this pack; the nine that touch only BlockStateBase are a different nine, which is confusing enough to be worth saying out loud.
• ASM is now an explicit test dependency instead of arriving through fabric-loader.

318 unit tests (zero skipped), three game tests, four server harnesses, the client harness, a benchmark showing no change against 0.5.3, and verification on a real 221-jar server pack in four configurations: AUDITED with nothing trusted (0 of 187 eligible, nine mods named); AUDITED with those nine trusted at stock settings (86 of 187 — the origin gate refuses 98 mod-added mob classes); the same with allowModdedMobAsync=true (184 of 187, nothing enforced, 732 searches installed); and the shipped UNSAFE default (184 of 187, 755 dispatched / 749 installed / 6 discarded on the shipping jar, with no PathWeaver exception in any run). With the world held still, all six evaluator families produced node-for-node identical routes to a synchronous oracle — one scenario each, which is evidence and not proof, and which for flying mobs the design does not guarantee (README, What is unproven).