So i dont fuck the walker kek#8
Closed
infuse21 wants to merge 51 commits into
Closed
Conversation
- Defers off-path recalculation while the player is still moving, animating, interacting, settling after doors/transports, or making recent route/interim progress. - Reworks route minimap clicks and unreachable-tile recovery to stay anchored to the planned raw path, use Euclidean minimap reach, and avoid backtracking to earlier nearby path branches. - Adds sticky interim checkpoint tracking so recovery/continuation clicks are not spammed while valid movement is already in flight. - Tightens door handling by deferring door probes while moving and only blacklisting wrong-traversal doors when the player started near the attempted door edge. - Improves charter ship destination widget lookup/clicking and optional confirmation handling.
cold start - hopefuly fixed Mid-route Stalling rs2 walker now accepts adjacent same-plane transport/objct landing
- Adds a per-loop `WalkLoopSnapshot` so route progress decisions reuse a stable player location and reachable-tile snapshot during each walker loop. - Reworks closest-path-index and route-progress tracking to prefer reachable distance when available, fall back safely when reachability is empty, and preserve forward progress on routes that double back near earlier branches. - Keeps primary minimap clicks, direct short-walk fallback, and unreachable recovery anchored to the raw shortest-path route before using smoothed waypoint nudges or generic fallbacks. - Adds raw-route target selection helpers with candidate predicates so recovery and continuation clicks stay on known walkable/unloaded route tiles. - Defers off-path recalculation while movement, interaction, animation, door/transport settling, recent clicks, route progress, or interim checkpoint progress indicate the player is still advancing. - Adds sticky interim checkpoint tracking and early `interim-in-flight` yields before broad scans, current-tile transport checks, direct short-walk attempts, and path segment scans. - Hints route progress after clicked-ahead checkpoints so later route anchoring does not snap back to nearby already-travelled branches. - Improves startup behavior by skipping speculative timeout-backed obstacle scans before the first movement click, while still allowing immediate planned transport steps to dispatch. - Suppresses active route idle nudges and stall recovery clicks when the current route segment is an explicit transport edge. - Tightens door/gate handling so wrong-traversal blacklisting only happens when the player started near the attempted door edge. - Accepts adjacent same-plane transport/object landings when the player settles near the expected destination instead of requiring the exact destination tile. - Improves charter ship handling by recursively resolving destination widgets, invoking the clickable widget/action, and confirming travel prompts when needed. - Updates `ShortestPathPlugin` route cleanup, pathfinder inventory quantity checks, WebWalk logging volume, movement docs, unit coverage, and the client-thread guardrail baseline. • Rs2Walker.java: immediate planned transports now suppress idle/stall recovery, so first-step teleports like Home Teleport should fire before pointless movement clicks. • Rs2Walker.java: active interim route clicks now yield before broad scans, reducing stop-start spam. • Rs2Walker.java: normal route clicks prefer raw shortest-path tiles instead of side/fallback tiles. • Rs2Walker.java: public walker entrypoints now reject client-thread calls before lock waits or player/tile reads. • Rs2WalkerUnitTest.java: added focused tests for route anchoring, raw-route click selection, interim yielding, and immediate-transport idle nudge suppression. • movement.md: documented the new walker gotchas Implemented the Al Kharid toll gate fix. What changed: • Added Pay-toll(10gp) transports for all four gate tiles in transports.tsv. • Added quest-free Open gate transports for Prince Ali Rescue completion. • Replaced the old quest-only tile restriction with blocked edge rules, so non-quest accounts can route through if they have 10 coins. • Walker now treats paid TRANSPORT rows as currency transports for item/banking checks. • Added special handling for Al Kharid toll gate confirmation: it uses Pay-toll(10gp) and clicks Yes, okay / Yes if prompted. I did not add the “talk to guard” fallback yet; this handles the cleaner object interaction path first.
…48b9742c1eaa667b18052785eb6ed058 (4.16.1) and marked the sync as successful in .quest-helper-sync. Kept the Microbot-specific integration intact: hidden always-on plugin wiring, QuestScript, config toggles, custom quest logic, resource path fixes, and the agent start hook. I also restored compatibility accessors needed by the automation runner and preserved precise farming patch coordinates where they matched older local data.
removed toll-gate helper pattern to avoid guardrail violation
Quest helper
Development web walker
Verified against the live tree on So-I-dont-Fuck-The-Walker-KEK: - #3 (POH TSV) reclassified OPEN -> NEEDS-VERIFY: teleportation_poh.tsv is absent by design; POH is routed programmatically via util/poh/, not a TSV. teleportation_portals.tsv (101 rows) is a different TELEPORTATION_PORTAL type (Castle Wars/god-wars), not POH. - chsami#27 (mushtrees) corrected 8 -> 12 of 16 pairs. - Confirmed boat world-view DONE (WorldPointUtil.fromLocalInstance), closing UPSTREAM_COMPARISON.md #6; PrimitiveIntList (chsami#11) still OPEN. - Added 2026-07-20 reconciliation note and a Facade migration section documenting the frozen 23-member ShortestPathPlugin coupling contract and the staged decouple-before-backport plan. Docs only; no walker/engine code changed. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Read-only sweep of all 26 consumer files outside the shortestpath package. Documents the complete member surface Rs2PathApi must reproduce: - Pathfinder external surface: getPath, isDone (only 2). - PathfinderConfig: refresh, setUseBankItems, isUseBankItems, getTransports, getAllTransports, setIgnoreTeleportAndItems, isTransportUsableWithLeaguesContext, isUseSpiritTrees. - Transport: 15 getters/setters (getDestination/getDisplayInfo/getType dominate); TransportType: all 20 constants + isTeleport + valueOf. - WorldPointUtil: packWorldPoint/unpackWorldPoint/undergroundAwareDistance. - CollisionMap: only the static ignoreCollisionPacked field (Rs2Tile). Key finding: the facade only needs to wrap mutable plugin state (Pathfinder/PathfinderConfig/marker/future/mutex); Transport, TransportType and WorldPointUtil are pure data / pure functions and can stay as-is behind it. Docs only; no walker/engine code changed. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Introduce a Microbot-owned facade (util/walker/Rs2PathApi) that delegates 1:1 to ShortestPathPlugin's mutable static surface catalogued in Stage 1: pathfinder lifecycle (get/set pathfinder, future, executor, mutex), config (getPathfinderConfig, setReachedDistance, override x3), target/walker state (exit, start-point flag, lastLocation), marker get/set, and getTransports; plus the CONFIG_GROUP and MARKER_IMAGE constants. Thin delegation only: no behaviour change, no state of its own. Value types (Pathfinder, PathfinderConfig, Transport) are intentionally not re-wrapped - they are the stable Microbot-facing path API. No consumers migrated yet (that is Stage 3, walker last); ShortestPathPlugin members stay public and binary-compatible until then. Compiles clean (:client:compileJava). Walker untouched. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Route the low-risk, single-package consumers through the facade instead of ShortestPathPlugin directly: - Script.exit path -> Rs2PathApi.exit - questhelper/QuestScript -> Rs2PathApi.getMarker/exit/getPathfinder - util/bank/Rs2Bank, util/depositbox/Rs2DepositBox, util/npc/Rs2NpcManager, util/skills/slayer/Rs2Slayer -> Rs2PathApi.getPathfinderConfig - util/leaguetransport/Rs2LeaguesTransport: field access ShortestPathPlugin.pathfinderConfig -> Rs2PathApi.getPathfinderConfig() Import-only swap where all refs were method calls; value-type imports (Pathfinder, Transport, TransportType, PathfinderConfig) kept as-is. MicrobotPluginChoice keeps ShortestPathPlugin.class (config registration, not state). No residual ShortestPathPlugin refs in migrated files. Rs2Walker deferred to last. Compiles clean (:client:compileJava, exit 0). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Route the walker subpackage helpers through the facade: - lifecycle/Rs2WalkerLifecycleRuntime (26 refs): marker, pathfinder, future, executor, config, start-point, lastLocation, MARKER_IMAGE - banking/Rs2WalkerBankingPlanner (13 refs): getPathfinderConfig, override MARKER_IMAGE resolves to the facade's re-exported constant. Value-type imports (Pathfinder, Transport, TransportType) kept. awaits/ and shared/ subpackages import only value types (Pathfinder/WorldPointUtil) and need no migration. No residual ShortestPathPlugin refs; Rs2Walker.java (77 refs) remains for the final Stage 3c pass. Compiles clean (:client:compileJava, exit 0). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Route the walker itself (77 refs) through the facade. Rs2PathApi is in
the same package so no import is needed; the shortestpath.* wildcard
import stays for value types (Transport/TransportType/WorldPointUtil/etc).
- 5x ShortestPathPlugin.pathfinderConfig field reads -> getPathfinderConfig()
- all method calls -> Rs2PathApi.*
- method reference ShortestPathPlugin::getPathfinder -> Rs2PathApi::getPathfinder
- javadoc {@link ShortestPathPlugin#...} -> {@link Rs2PathApi#...}
No field assignments existed, so no missing-setter issues. Zero residual
ShortestPathPlugin refs in Rs2Walker. All consumers now go through the
facade; ShortestPathPlugin's public static surface is fully wrapped.
Verified: :client:compileJava exit 0; shortestpath unit+regression suite
green (73 tests: ShortestPathCoreTest 43, ShortestPathTier1RegressionTest
18, PathSmootherTest 6, TransportTypeTest 4, benchmark/refresh 1+1;
0 failures, 0 errors).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Record the staged-plan status: Stages 1 (catalogue), 2 (Rs2PathApi), and 3a/3b/3c (consumer migration incl. Rs2Walker) done with commit refs; Stage 4 (backport behind facade) is now the next step. Note that 100% of plugin-state access routes through Rs2PathApi and only plugin identity refs (.class / getSimpleName) remain. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Live-code verification against the KEK branch found most flagged "backport" items already implemented since the 2026-04-18 audit: - #2 wilderness boundaries DONE (PathfinderConfig.java:41-46 match the upstream values; isInLevel20/30Wilderness wired; Chebyshev landed) - #8 bidirectional BFS DONE (meet-in-the-middle, BIDIRECTIONAL_MIN_CHEBYSHEV) - chsami#31 currency-aware transport filter DONE (PathfinderConfig.java:879-892) - chsami#33/chsami#34 transport-index perf DONE (buildPathFirstIndex map) - chsami#11 stale premise: Node already packed-int, not List<Integer>; the only List<WorldPoint> left is the getPath() facade boundary (not a behind-the-facade change) Genuinely-open internal items remain: chsami#10 (reachability prune), chsami#12 (SplitFlagMap LRU eviction), chsami#30 (one-way flag), #3 (POH coverage) - correctness/data-sensitive, want real upstream source. No upstream remote is configured yet (still pinned to 07fca57). Docs only. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Added the skretzo remote and fetched Skretzo/shortest-path. Upstream HEAD is 122 commits + a major refactor past the pinned 07fca57 (transport/ + transport/parser packages, Destination/ItemVariations/ JewelleryBoxTier model, NodeGraph/IntDeque/IntMinHeap/PrimitiveIntList pathfinder internals, standalone WildernessChecker, leagues/, PendingTask). Re-checked the open items against real current source: - #2 wilderness: byte-identical to upstream WildernessChecker -> DONE - #3 POH: real gap - upstream ships teleportation_portals_poh.tsv (137 rows); Microbot routes POH programmatically. Next target: diff that TSV against util/poh coverage and backfill. - chsami#10/chsami#12: no upstream counterpart (Microbot-original perf ideas) - chsami#30 one-way: not confirmed upstream; deprioritized Documented in UPSTREAM_COMPARISON.md "Re-baseline 2026-07-20" and updated the facade-migration staged plan (step 5 done). The divergence now only supports selective feature/data backports, which the facade makes safe. Docs only. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Diffed Microbot's programmatic POH model against upstream's teleportation_portals_poh.tsv (137 rows / 50 dests) and the game's 42 ObjectID.POH_PORTAL_MAG_* portal-chamber destinations. PohPortal covered 28; added the 12 missing ones: Barbarian Outpost, Fishing Guild, Port Khazard, Marim, Civitas illa Fortis, Ourania, Cemetery, Dareeyak, Trollheim, Lassar, Ice Plateau, Paddewwa (PohPortal 28 -> 40). Each uses the authoritative arrival tile from the upstream data set and the MAG/MARBLE/TEAK object-id families (compiler-verified to exist; League variants omitted). They flow into the transport graph automatically: PohPortal.findPortalsInPoh() (BY_OBJECT_ID built from values()) -> PohPanel.portalPanel -> new PohTransport(...), so the walker now detects and routes through these portals when built in a POH. Verified: :client:compileJava clean; no duplicate enum constants; shortestpath regression suite green. Tracker #3 marked DONE in WEBWALKER_IMPROVEMENT_PLAN.md and UPSTREAM_COMPARISON.md. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Recorded in UPSTREAM_COMPARISON.md the file-level and content-level diff of transport data against current upstream: - File-level: the 4 upstream-only TSVs are handled (POH portals/boxes programmatically, quetzal whistle inline, home teleports partial); Microbot adds blocked_edges/dangerous_tiles/npcs/restrictions. - transports.tsv content: present in both (4949 vs 5168 rows). By origin->dest identity, 778 upstream-only pairs vs 553 Microbot-only. Only 14 named; 764 anonymous route objects (mostly Climb/Ladder/ Stairs). 713 of 737 upstream-only origins are brand-new tiles -> a real coverage gap, not coordinate drift. - Flagged bulk import as risky (action-column schema mismatch + collision-map coverage), recommended scoped per-region sync starting with the 14 named routes. Docs only. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Replace bundled collision-map.zip with the current upstream build: 2724 regions (was 2663; +61 new regions covering Varlamore/Kebos and other recent content). Format verified compatible before swap: identical x_y region-entry naming, identical packPosition, and identical per-tile bit layout (FLAG_COUNT=2, same z/y/x index arithmetic) - upstream only refactored BitSet -> long[] internally, the on-disk byte encoding is unchanged, so Microbot's BitSet-based FlagMap decodes it correctly. Validated: shortestpath suite green (73 tests, incl. ShortestPathCoreTest 43 + Tier1 regression 18 doing real cross-region pathfinding; 0 fail). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Import the origin->dest routes present in upstream transports.tsv but absent locally (mostly stairs/ladders/climbs in new areas: Varlamore, Kebos, plus building multi-floor transitions). transports.tsv 4949 -> 5717 data rows. Conversion (scripted, validated): - action column space-form "Open Door 9398" -> ";"-form "Open;Door;9398" (menuOption;menuTarget;objectId); all 768 match Microbot's parser regex. - inserted empty Currency/isMembers columns to match the 12-col schema. - Items: upstream named variations + '|' OR-sets translated to Microbot numeric id-sets (AXE/MACHETE/PICKAXE/ROPE expanded via ItemVariations -> ItemID values; '|' -> space OR-group; '=qty' stripped); COINS=N moved to the Currency column as "N Coins". - Skills/Quests/Varbits/VarPlayers pass through (formats verified identical). - fixed upstream data typo "Shadows of the Storm" -> "Shadow of the Storm" to match RuneLite's Quest enum (otherwise the quest gate silently drops). Excluded: - 15 upstream rows with id-less actions (bare "Climb-up Staircase", name-only walls/gates, 1 empty action) - unmatchable in Microbot's id-based format. - 2 Garden of Tranquillity trellis rows (obj 2149, Varrock Palace) that Microbot intentionally omits - caught by testVarrockSewerPathAvoidsDisabledPalaceTrellisShortcut. Validated: shortestpath suite green (73 tests, 0 fail) incl. real cross-region pathfinding after the import; paired with the updated collision map so the new-area routes have collision coverage. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Update UPSTREAM_COMPARISON.md re-baseline: 768/778 routes imported, collision map refreshed (2663->2724 regions), exclusions and the isMembers caveat recorded. Docs only. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The legacy 2026-04-06 tables were misleading (showed many features as missing that are now present). Verified each against the live tree: - "Critical Bug Fixes Missing Locally" #1-6: all fixed - banner added. - Transport System table: corrected Local column. Actually present now: hot air balloons, magic mushtrees, seasonal transports, teleportation boxes (POH mounted), POH portals, Pendant of Ates, Kharedst's Memoir/ Book of the Dead, Great Conch (CJQ). Genuinely still missing (6): Cowbell Amulet, Sailors' Amulet, Laguna Aurorae spirit tree, bank-visit teleport discovery, per-transport-type cost tuning, currency-threshold cost avoidance (currency requirement filtering IS present). - POH section: granular PohPanel sub-panels present - obsolete-toggle description annotated. Docs only. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Add the three transport data items that were genuinely missing vs upstream (7e7e5bf94b), sourced from upstream's data files: - Cowbell amulet (item 33104) -> teleportation_items.tsv (1 dest) - Sailors' amulet charged (item 32399) -> teleportation_items.tsv (3 dests: The Pandemonium, Port Roberts, Deepfin Point) - Laguna Aurorae spirit-tree destination -> spirit_trees.tsv, gated on the Pandemonium quest (resolves against RuneLite Quest.PANDEMONIUM) Converted to Microbot's column schemas (item '=qty' stripped; members Varlamore items marked isMembers=Y, Consumable=T, wildy 20 as upstream). Validated: shortestpath suite green (73 tests, 0 fail; both files parse). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Docs only. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…ecovery The walker deviated wide, entered buildings, and backtracked near Varrock West Bank. Root cause was in click-target selection, not pathfinding or collision data (verified offline: the raw route is optimal and reaches the goal from every approach). Two defects compounded: 1. The anchored forward scan shared by every click predicate could start past the player's vicinity, breaking immediately on the Euclidean bound and returning null for ALL predicates (observed live as sel=none). Selection then fell through to a smoothed-waypoint Euclidean clamp, producing off-route clicks such as (3176,3428). 2. That clamp picks a target with no straight walkable line to it. A minimap click is resolved by the game's own pathing, so a no-line-of-sight target lets the game improvise a detour: cutting corners through open doors, looping around buildings, and trapping itself so it has to backtrack out. Changes: - Select route clicks by line-of-sight first: the furthest forward raw-path point the player can reach in a straight walkable line (CollisionMap.canStep line trace, mirroring PathSmoother.lineOfSight). Tiers: los > reach > walkable > offscene. - Retry selection anchored at the player's own closest raw tile when the anchored scan yields nothing, so a stale smoothed->raw anchor can no longer drop clicks onto the off-route clamp. - Guarantee selection never returns null while a raw route exists, so a click can no longer leave the planned route. - Consolidate every click path (main loop, idle-nudge/stall recovery, interim continuation, outside-clip route fallback) onto the same selector. Previously each had its own policy, so behaviour depended on which path happened to fire. - Gate the directional scaled-radius fallback and the wall-distance nudge on reachability; the nudge now prefers the neighbour reachable from and nearest to the player instead of an arbitrary tile from an unordered set. - Add bidirectional rejoin for off-path recovery, preferring forward points so normal progress is never sacrificed. - Tag click_candidate_found with the selection tier (sel=/fb=) for diagnosis. Also fixes two startup/pacing issues found while investigating: - The 2000ms wait for a non-null pathfinder expired mid PathfinderConfig.refresh() (measured 2.4-2.7s on a cache miss), sending the walker into recalculatePath() which cancelled the in-flight work and started a second refresh. Raised to 6s so recalculation stays a genuine failure path, and log slow refreshes at INFO. - Shortened the active-route idle-nudge window to a few ticks. Route continuation is one-shot, so when it is missed that window is the visible dead stop per hop. Measured on the reported route: the 41-tile leg now resolves to four straight clicks (3182,3432 -> 3172,3425 -> 3172,3399 -> 3173,3399), confirmed live as sel=los@player. Tests: Rs2WalkerUnitTest 96, LineOfSightClickRegressionTest 3 (new), ClientThreadGuardrailTest 1. Guardrail baseline regenerated (mostly lambda-index churn plus the changed getPointWithWallDistance signature). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
A post-transport raw scene scan was measured at 5640ms returning handled=false (Lumbridge -> Corsair Cove, after the Port Sarim ship). The skip guard behaved correctly there: a charter ship was a genuine upcoming nearby transport, so "no_nearby_planned_transport" did not apply and the scan legitimately ran. The cost is inside the scan itself. Each raw index probes two offsets, and each probe does several client-thread scene lookups (wall exact + adjacency fallback, game object exact + adjacency fallback, plus composition resolution), so a ~14 index window can issue hundreds of client-thread round trips and return nothing. Time each handler separately (doors, door-candidate, rockfall, transports) and log the breakdown at INFO when a scan exceeds 500ms, so the dominant call is identified from one run instead of by guessing. Instrumentation only; no behaviour change. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Instrumentation attributed the stall precisely:
slow raw scene scan: total=5539ms idx=12 doors=4564ms doorCand=974ms
rockfall=1ms transports=0ms resolved=false
handleDoors was 82% of a 5.5s scan that resolved nothing - about 380ms per raw
index. Each probe issued up to four bounded scene queries (wall exact, wall
adjacency, game object exact, game object adjacency), and a scan walks ~12 raw
indices x 2 offsets x several probes, so a single no-op scan could cost hundreds
of client-thread round trips.
Take one bounded snapshot of wall and game objects up front (radius
handlerRange+2, a superset of what the per-probe queries could reach, since
probes stay within handlerRange+1 of the player and only match objects within one
tile of a probe) and resolve probes against it in memory. Two queries per scan
instead of hundreds.
Exact-tile match is still preferred over the one-tile adjacency fallback, so
door selection is unchanged. The snapshot is scoped to one scan and cleared in a
finally block; outside a scan it is null and every other handleDoors caller keeps
the original query-per-probe path.
Guardrail baseline regenerated: the resolver entries are the same off-thread
getWorldLocation reads relocated out of handleDoors (24 added, 23 removed), plus
lambda-index renumbering in untouched methods.
Not yet validated live - the next walk past a transport should show the scan drop
well under the 500ms slow-scan threshold.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The pathfinder cold start the walker blocks on was measured at "slow refresh transports=2639ms restr=1ms total=2640ms" — essentially all of it is refreshTransports re-evaluating every transport on a cache miss. The per-stage breakdown (merge/cache/filter/useTrans/similar plus per-type stats) already existed but only at DEBUG, and nothing recorded why the cache missed. - Log the miss reason: "key" (cache key changed — items, coins, toggles) vs "verify" (items identical, game state moved — skills/varbits/varplayers/quests) vs "no_snapshot". - Include the inventory/equipment/bank fingerprint and the previous refresh's value, so an item-driven miss is visible directly. The fingerprint hashes item quantity, so spending coins on a charter fare or toll gate changes it and invalidates the key on its own — this makes that testable rather than assumed. - Promote the existing stage breakdown to INFO when a refresh is slow enough to be the visible cold start. Instrumentation only; no behaviour change. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Cache-miss attribution showed a miss with an identical cache key AND identical
inventory fingerprint:
refresh_transports cache_miss reason=verify key=76240725 prevKey=76240725
invFp=31671802 prevInvFp=31671802 invChanged=false
The verification gate hashed Arrays.hashCode(boostedLevels) over SKILLS =
Skill.values(), i.e. all 23 skills including HITPOINTS and PRAYER. Those move
constantly from HP regen and prayer drain, so the transport cache was invalidated
during ordinary play regardless of items — forcing the full re-evaluation the
walker blocks on at route start (measured 2652ms, of which useTransport() over
5714 plain transports is 2290ms).
No transport gates on hitpoints, so hitpoints cannot change any transport's
usability and must not participate in the hash. Collect the skills some transport
actually requires (hasRequiredLevels treats level > 0 as a requirement) and hash
only those, mirroring how varbits/varplayers are already collected from the
merged transport list. The skill set is carried on the snapshot so the cache-hit
probe checks the same subset, which also removes 23 per-probe client-thread
getBoostedSkillLevel calls.
Payment-driven misses are unaffected and still correct: spending coins changes
the inventory fingerprint, which is part of the cache key, not this hash.
Tests: HP regen / prayer drain must not invalidate; a required skill (agility)
still must; out-of-range ordinals are ignored.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Both tests called rawPath(START, GOAL) independently. Each call reloaded all 6292 transports and ran a full Pathfinder, and Pathfinder -> CollisionMap.getCachedRegionId calls Rs2Player.getWorldLocation(), which has no client thread under test and blocks for its full 10s timeout before being swallowed. Compute the route once in @BeforeClass and share it. Full unit suite drops from ~70s to 47s (1106 tests, 0 failures) and the duplicate transport load is gone. Two client-thread timeouts remain inside the single Pathfinder run: the region id is cached for only 5s per CollisionMap, and the timeouts themselves push the run past that window, so it re-queries. Removing those entirely would mean not running the real pathfinder in this test, which would cost the route coverage the greedy LOS-chain assertion depends on. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Live log near (3150..3151, 3363): the walker used an agility shortcut, crossed to the far side, then immediately used the opposing entry to come back and could not recover — about 19s of a 2m26s walk. post-handleObject adjacent landing failed | dest=3150,3363 at=3154,3363 post-handleObject landing unresolved | dest=3150,3363 at=3154,3363 post-handleObject landing unresolved | dest=3151,3363 at=3149,3363 <- crossed local reachability miss / route-backed local recovery click The two destinations are adjacent tiles: the same shortcut catalogued as two opposing entries. markAdjacentSamePlaneTransportHandled ran only when waitForPostHandleObjectLanding succeeded. Adjacent same-plane transports require landing on the exact destination tile (maxInclusive == 0) and agility shortcuts routinely land a tile off it, so the crossing succeeded physically while the check reported failure. Nothing was suppressed, so the inverse entry stayed immediately eligible. Suppress both tiles whenever the player is no longer on the origin, regardless of the landing verdict. The landing result is unchanged - it still returns false and replans; this only stops the walker re-crossing straight back. Suppression is already type-agnostic (adjacency and plane only), so shortcuts and doors are covered alike. Adds a unit test that an adjacent same-plane AGILITY_SHORTCUT yields both tiles as suppression points, plus movement.md chsami#22. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Component attribution showed the teleport stall was self-inflicted: transport_handoff_enter type=TELEPORTATION_SPELL post_transport_segment_handler handled=true i=0 ms=16562 refresh_transports cache_miss reason=verify ... changed=varplayers, LAST_HOME_TELEPORT appears exactly once in the transport data - the Home Teleport cooldown in teleportation_spells.tsv - and is one of the 8 varplayers in the verification hash. Casting the spell writes that varplayer, so the teleport invalidated the transport cache by being used, forcing a full ~2.9s re-evaluation of all 12666 transports inside its own 16.5s handling window. It is also structurally wrong independent of teleporting: COOLDOWN_MINUTES compares against wall-clock minutes, so the raw value advances continuously and can never match a stored one. Hash the condition verdict (TransportVarPlayer.matches) plus the condition identity (id, operator, threshold) rather than the raw varplayer value. The verdict flips exactly once - when the cooldown expires and the transport genuinely becomes usable - so an expiring cooldown still invalidates while a ticking one does not. Condition identity is included so adding or changing a condition still invalidates. Same rule as the skills fix: only inputs that can flip a transport's usability may participate in the cache key. The value provider is injectable so the behaviour is unit-testable: two different raw values inside one cooldown window hash identically, crossing the threshold does not, and the condition encoding is order-independent and deduplicated. Adds movement.md chsami#23. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The visible cold start is not the teleport - it is the gap between starting a walk and the walker doing anything at all: walk_start cache_miss reason=verify ... changed=varbits, slow refresh transports=2888ms pf_ready elapsed=2418ms transport_handoff_enter TELEPORTATION_SPELL <- only now does it act That first miss is attributed to varbits, a different cause from the varplayer cooldown fixed in the previous commit. TransportVarbit is structurally identical to TransportVarPlayer - same operators, same matches() - so it gets the same treatment: hash the condition verdict plus the condition identity rather than the raw varbit value. A varbit whose value moves without flipping any verdict cannot change a transport's usability, so it must not force a full re-evaluation the walker blocks on before its first action. Whether this removes the walk-start miss depends on whether that varbit's verdict genuinely flipped. If a miss still appears with changed=varbits it is a real usability change, and the remaining lever is the cost of a miss (~2.3s of useTransport over 5714 transports) rather than its frequency. The value provider is injectable, so the test asserts the real behaviour: 7 -> 9 against "> 5" does not invalidate, 7 -> 3 does. Extends movement.md chsami#23 to cover varbits. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
A minimap click is resolved by the game's own pathing, so line of sight is irrelevant to walking - a player clicks past a corner, through a doorway, or around a building and the server routes them there. Clamping click targets to a straight walkable line made the walker advance corner-to-corner, stopping at each corner to re-aim before issuing the next click. That is a visible behavioural tell and no human walks that way. It also bought no correctness. The off-route click (3176,3428) that motivated the clamp was not caused by a lack of line of sight: selection returned null on a stale anchor, so the caller fell through to clamping a far smoothed waypoint to a Euclidean radius, which landed off the planned route. The game then pathed to that off-route tile its own way. Once the anchor self-heal landed, selection returns a raw-route point by construction and the LOS tier was doing nothing but shortening clicks. The invariant that actually matters is that the target sits ON the raw route: then however the server walks there, we arrive on the planned path. - Primary selection is again the furthest forward raw-route point within minimap reach, with no LOS and no bounded-reachability requirement (the latter could also shorten clicks without protecting anything the route membership does not). - The outside-clip route fallback drops its LOS-preferring tier too. - Removes hasWalkableLineOfSight and isOffSceneOrUnloaded, now unused. - Retained: the anchor self-heal (the real fix), raw-route-only selection, the reachability guard on the wall-distance fallback branch, and the door/gate pre-click guards, which are what stop a click skipping a closed door. Replaces LineOfSightClickRegressionTest with RouteClickTargetRegressionTest, which pins the correct invariant - the historic click is not on the raw route, and the route offers long forward reach within minimap range so clicks are not shortened to the nearest corner. Rewrites movement.md chsami#20 to record that LOS clamping was tried and reverted, so it is not reintroduced. Guardrail baseline regenerated: all 24 entries are lambda-index renumbering in untouched methods (26 removed, 24 added), no new non-lambda violations. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…ary selection chsami#19 instructed selecting the primary click from the player's bounded reachable set "not walkability". The primary selector now uses isKnownWalkableOrUnloaded, so the entry contradicted the code it documents. Scope it to what is still true and still implemented: reachability gating belongs on click targets that are invented rather than taken from the route - the getPointWithWallDistance nudge and the scaled-radius directional fallback - plus the bidirectional rejoin. Records that gating primary selection was tried and reverted, since a BFS bounded by click radius can exclude legitimate around-a-corner points and shorten clicks for no benefit: a point taken from the raw route is safe by construction (chsami#20). Documentation only. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Full audit of all 23 entries against the current source. Symbol check: every symbol named in a "Where this applies" line resolves. Five symbols (atTransportDestination, DIRECT_CLICK_MAX_DISTANCE, clickOptimisticRecoveryTarget, isRouteActive, playerIsIdleForShortWindow) appear only inside "Pattern to follow" blocks as illustrative pseudo-code, which is easy to mistake for a real API when grepping. Numeric claims are consistent with the code: chsami#21 correctly describes 2500ms as the previous idle-nudge window and quotes the current 1200ms constant, and the walker lock #1 refers to exists. Two fixes: - #5 says to suppress the inverse adjacent transport after a *successful* crossing. That is incomplete in isolation: a reader following only #5 reproduces the bug chsami#22 fixes, because adjacent transports require an exact-tile landing and a crossing can succeed while the landing check fails. Cross-referenced. - Added a reading guide noting that pattern blocks may be pseudo-code, that "Where this applies" is the authoritative symbol list, and that chsami#19/chsami#20 deliberately record reverted approaches. Documentation only. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Route selection always returned the furthest candidate inside a fixed radius (MINIMAP_REACH_EUCLIDEAN - 1), so every click covered the same tile span. The existing randomisation nearby does not address this: nextWalkingDistance (9-12) gates whether a waypoint is far enough to be worth clicking, and proximityWake (2-4) gates the post-click wait, but neither varies the reach used to pick the tile. Jitter the reach per click via routeClickReach, applied inside selectRouteClickTarget so every click path picks it up rather than only the main route loop. Varying reach is the safe axis: it changes only how far along the route the target sits, never sideways, so the target stays on the planned route. Lateral tile offsets are the wrong axis - they leave the route, which is what produced clicks on the wrong side of a fence or inside a building, and route membership is what keeps the server's own pathing on our route. Lateral randomness belongs inside the tile, in click-point jitter. Bounds are load-bearing. The floor (7) stays clear of INTERIM_CLOSE_TILES (5) so a short click cannot land inside the interim-close threshold, clear the checkpoint immediately and cause click thrash. The ceiling is the caller's reach, already tuned to the minimap clip. A shortened reach also retries at full reach before giving up, so it can never be the reason selection returns null and drops the click onto the off-route wall-nudge clamp. Adds movement.md chsami#24 and tests for the bounds, actual variation, and degenerate reach values. Not yet validated live. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The player-anchored retry ran at full reach, bypassing the jitter. That retry fires on most first clicks of a route (sel=route@player), so in practice the variation was skipped exactly where it is most visible: measured first-click distances clustered at 9.0-10.0 rather than spreading across the 7-10 band. Use the jittered reach there as well, keeping the full-reach fallback so a shortened reach still cannot be the reason selection returns null. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The class javadoc still said no consumers had been switched over yet and that this was still pending as Stage 3, but Stage 3 completed three commits later in this same branch (eb0e274 leaf consumers, 6ee086b walker-package helpers, e6e7f0c Rs2Walker). A reviewer opening the facade was told the migration had not happened when it had. Records the end state instead, plus the grep that verifies it: the only remaining ShortestPathPlugin static references under microbot/util/ are the delegations in this class, which is the invariant that confines an upstream backport to this one file. Doc only; no behaviour change. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
A walk to an underground goal reported UNREACHABLE while it was still advancing. Two defects combined. partialPath is recomputed every iteration as "path end is further than distance from the goal". The pathfinder stopped 31 tiles short of (3087,9720), so it was true from the first snapshot onward and the retry budget was armed for the whole walk rather than for a stuck stretch. The path loop also exits for good reasons. Opening a door ends the iteration and lands in the same branch as a failure to move, so it spent a retry. Observed: retry 1 at the end of the first segment, ~100 tiles and 46 seconds of successful walking, then retries 2 and 3 within one second of a single door open - the second without the player moving at all. It gave up on the surface having never reached the ladder. Refill the budget when route progress advanced since the last charge, and exempt exit reasons that denote work done (door/transport/blocker handled, movement in flight). The exemption is deliberately narrow: not-near-path, click-failed-off-minimap and the waiting/retry states still consume it, so a genuinely unreachable goal still terminates. Also stop passing placeholders to recordUnreachable. pathEndpoint was the player's location and pathSize a literal 0, so the log read as "pathfinder returned an empty path at your feet" and endpointToTarget became a surface-to-underground y delta (6346) instead of the real 31-tile shortfall. Underground is the same plane at y+6400, so WorldPoint.distanceTo does not bail out across that boundary - it just returns a meaningless number. movement.md chsami#25 and chsami#26 record both. Tests: :client:runUnitTests green, 1113 tests, 0 failures. Guardrail reports 961 known violations, no regressions - baseline unchanged. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The refill condition used routeProgressAdvancedAtMs alone. That field is also bumped by stabilizeRouteProgressIndex whenever the route is merely REPLACED (path size or endpoints differ), and every partial retry calls recalculatePath() - so a retry could refill the budget it had just spent. The path stabilises once the walker is truly stuck, so it still terminated, but only after extra iterations, and a route that flapped between two shapes on successive recalcs could have kept refilling until the 64-iteration tail cap. Also require the player to be standing somewhere new since the last retry. When a target is genuinely unreachable the player stops moving, so movement is the signal that separates "advancing" from "stuck" - which is what lets the budget drain and report UNREACHABLE. Found while probing a walk whose goal (3087,9720) is blocked in the collision map, with 0 walkable tiles within 6. The pathfinder correctly stopped at (3056,9720), the last walkable tile before the rock face. Tests: :client:runUnitTests green, 1113 tests, 0 failures. Guardrail 961 known violations, no regressions. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
A walk to (3087,9720) - inside the rock east of the Dwarven Mine, with zero walkable tiles within 6 - spent ~80s covering 100+ tiles from Draynor, went underground, stopped at (3056,9720) which is the last walkable tile before the rock face, and then reported partial-retries-exhausted. The pathfinder was right; a path request from (3056,9720) to the goal returns size 1, meaning you cannot leave that tile toward the target. Only the diagnosis was wrong: the failure read as a walker fault rather than a bad destination coordinate. The intended target was the Motherlode cave mouth at (3060,9766). processWalk now checks the collision map for any walkable tile within the arrival distance and returns UNREACHABLE immediately with cause target-not-walkable, naming the nearest walkable tile so the coordinate can be corrected. The guard is deliberately permissive. An unmapped region reads as fully blocked, because SplitFlagMap.get returns false for one and CollisionMap.isBlocked negates all four directions - so a naive check would reject every instance and every region absent from the collision map. Adds SplitFlagMap.hasRegion and a CollisionMap delegate, and every ambiguous case (no map, unmapped target, unmapped tile in the search box) returns walkable and lets the pathfinder decide. Only mapped, wholly blocked terrain is rejected. Tests: 5 new cases against the real collision map, covering the buried coordinate, the cave mouth and last-walkable tile still being accepted, unmapped regions never being rejected, and a generous arrival distance reaching real ground. Suite green, 1118 tests, 0 failures. Guardrail 961 known violations, no regressions. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
handleRockfall required BOTH the player and currentTarget to be in region 14936, so any walk leaving the Motherlode Mine bailed before inspecting anything. Observed live at=(3751,5672) goal=(3040,9810): the goal is region 12185, so no outbound route could mine through a rockfall standing directly in its path. Approaching the mine from outside was equally dead, since the player is not in 14936 yet. Rockfalls only exist in the Motherlode Mine, so a region gate is right - it just has to test where the rockfall could BE (the player's tile, or the path tiles about to be inspected), never where the walk ends. Extracted as isMotherlodeRockfallCandidate so both directions are testable without a client. Also defer the pickaxe check until a rockfall is actually found. It ran before any rockfall was located and called setTarget(null), so a route merely passing through the mine without a pickaxe was killed outright. Now only a rockfall genuinely in the way abandons the walk. Note this handler still only fires when a rockfall lies ON the path, and transports.tsv contains no rockfall entries (grep -ic rockfall = 0), while the collision map marks those tiles blocked. So the pathfinder never routes through one and the handler stays dormant. Cataloguing MLM rockfalls as Mine;Rockfall;26679/26680 transports - mirroring the existing Mine;Rock slide;2634 entries - is what will actually exercise it. That needs per-rockfall coordinates from a live session and is tracked separately. Tests: 3 new gate cases (leaving the mine, approaching from outside, closed elsewhere). Suite green, 1121 tests, 0 failures. Guardrail 961 known violations, no regressions. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
An obstacle that stands BETWEEN two walkable tiles - Motherlode rockfalls, rubble, rock slides - can only be modelled as a transport if you know both of its open ends, and the object's own position does not give you those. /objects returns position only, so collecting them meant reading coordinates off a screenshot. Reports each match's surrounding tiles with live-scene walkability, plus a "sides" object pairing opposing neighbours on each axis: the axis whose bothWalkable is true is the transport's origin/destination pair. Walkability is read from the live scene collision flags rather than the bundled collision map, which is the point - the bundled map has these obstacles baked in as permanent walls, so it cannot tell you they are passable. Also reports selfWalkable so a cleared obstacle is distinguishable from a standing one. The flag array is read once per request inside a single client-thread call. Rs2Tile.isWalkable hops the client thread per invocation, so the obvious implementation would have cost 8 hops per object. Tests: suite green, 1121 tests, 0 failures. Client-thread guardrail 961 known violations, no regressions. Documented in AGENT_SERVER.md. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The bundled collision map bakes rockfalls in as permanent walls. That is correct for upstream, which has no automation to clear them, but it left the mine carved into disconnected pockets: a route from the cave arrival tile (3728,5692) to the WEST_LOWER mining area died 10 tiles short, and walking anywhere inside the mine mostly failed. Rs2Walker.handleRockfall already knew how to mine 26679/26680, but it only fires when a rockfall lies ON the path - and since nothing contradicted the collision map, the pathfinder never routed through one. The handler was effectively dead code. Each rockfall is now a Mine;Rockfall;<id> transport between its two open sides, mirroring the existing Mine;Rock slide;2634 entries. 32 spawn points, 90 rows: 19 are chokepoints where exactly one axis is open, 13 are bypassable and only add an alternative edge. Duration 10 keeps an open corridor preferred over mining when both exist. Positions came from the live scene via GET /objects/neighbours, unioned across 9 samples taken minutes apart - rockfalls respawn, and a single snapshot was already one short. All 32 appeared in every sample, so the set looks complete, though a spot that was cleared for the whole session would not have been seen. A missing rockfall is safe: it just stays a wall, which is today's behaviour. Item requirements use ';' (alternatives) rather than the ' ' separator the existing rock slide row uses. Note this is presentational only: Transport parses the column into Set<Set<Integer>>, but PathfinderConfig.hasRequiredItems flattens it and calls anyMatch, so either separator behaves as "any one pickaxe". ';' matches the data model's intent and reads correctly. Tests: 4 new offline cases against the real collision map and transport data, incl. the original failure (arrival -> WEST_LOWER, previously 10 tiles short) and a full Draynor -> mining area route. Suite green, 1125 tests, 0 failures. Guardrail 961 known violations, no regressions. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
hasRequiredTransportItems only admitted plain TRANSPORT entries carrying a currency cost, so an item-gated obstacle - a machete for a jungle bush, a pickaxe for a Motherlode rockfall, a Shantay pass - fell through every branch to the catch-all "return true", was never reported missing by getMissingTransports, and was never withdrawn. That contradicted the pathfinder. PathfinderConfig.hasRequiredItems ORs in Rs2Bank.hasItem when useBankItems is set, and refreshAvailableItemIds includes bank contents on the same flag, so a route was planned through the obstacle on the strength of a banked item the planner then declined to fetch - stranding the walk at the obstacle it had just routed through. Extracted the decision as planningCoversPlainTransport so both directions are testable without a client. This only widens which transports are ELIGIBLE, not how many bank trips happen. Collection is path-scoped: getTransportsForDestination pathfinds first and inspects only transports on the resulting route, so an item is fetched solely when the chosen route actually needs it. The downstream machinery already handled generic items - getMissingTransportItemIdsWith- Quantities walks getItemIdRequirements for any transport, picks whichever alternative has the most in bank, and uses quantity 1 for non-currency transports - so nothing else had to change. 235 rows in transports.tsv become eligible: 90 Motherlode rockfalls (new in this branch), 102 machete-gated jungle bush/tree/vines, 10 White Wolf Mountain rock slides, 6 Shantay passes, and ~27 keyed doors, ladders and slopes. Only the Motherlode case is verifiable offline; the Karamja and desert routes are untested live. Tests: 5 new cases over the real transport data - every item-gated plain transport eligible, every requirement-free one still ignored, currency transports unchanged, rockfalls covered, and null/non-plain types rejected. Full suite green, guardrail 961 known violations, no regressions. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…ting" This reverts commit d16e9d1.
This reverts commit f9aef42.
Region 58_88 (Motherlode Mine, x3712-3775 y5632-5695) regressed in 631884f "update collision map" (23 Jan 2026). Connectivity from the cave arrival tile (3728,5692) collapsed from 1473 reachable tiles to 192 - 87% of the mine cut off - and every lower-floor mining spot became unreachable: a585dc3 (19 Nov 2025) walkable=1623 reachable=1473 spots OK 631884f (23 Jan 2026) walkable=1580 reachable=192 spots dead a19a334 (12 May 2026) walkable=1606 reachable=192 spots dead f8b1138 (20 Jul 2026) walkable=1606 reachable=192 spots dead This is why the world map could once be used to walk into Motherlode and then could not: the pathfinder had no route through the mine, so any target inside it was unreachable regardless of how it was set. Restores just that one 952-byte region from a585dc3. Every other region is left on the current upstream sync - verified by comparing decompressed entries, only 58_88 differs. Safe despite the age: Motherlode Mine last changed in the game on 8 May 2024 (Project Rebalance, minor follow-up 15 May 2024), so the 19 Nov 2025 capture postdates the last map change by 18 months. The January regression was a bad regeneration, not a map update. After: walkable=1623 reachable=1473, with WEST_LOWER, WEST_MID, SOUTH_EAST and SOUTH_WEST all reachable from the arrival tile. The upper floor (WEST_UPPER, EAST_UPPER) stays unreachable in every version including the good one - that needs the ladder catalogued, which is gated behind the 100 golden nugget unlock and is tracked separately. With the mine genuinely connected, Rs2Walker.handleRockfall works as designed: routes now pass through the mine and it mines a rockfall that lies on the path. That is the correct model, unlike the transport rows reverted in 289090d - a transport relocates the player, and mining a rockfall does not. The archive is byte-larger-compressed differently (1197109 -> 1058342) because it was rewritten by a different deflate implementation; entry names, count (2724) and decompressed contents are unchanged apart from 58_88. Verified offline by decoding the FlagMap bitset directly. NOT yet verified in-game. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…uting" This reverts 5c06b86, restoring the pre-flight guard. It was reverted because it appeared to block legitimate walks into the Motherlode Mine. That diagnosis was wrong. The walks it rejected were targets in genuine solid rock in the Dwarven Mine (region 48_151): (3079,9710), (3086,9719), (3087,9720), (3087,9723), (3087,9724) - all produced by clicking the Motherlode inset on the world map, which resolves against the host region's coordinate space and so never yields a Motherlode tile. The guard was correct to refuse them, and naming the nearest walkable tile was the most useful diagnostic in the whole session. What was actually broken was collision region 58_88, fixed in cf8cf03. The revert reasoning also claimed the guard turns "degraded but progressing" into hard failure. That does not hold up: walking to the nearest tile to a rock face achieves nothing, and it costs ~30s before failing with a less specific error. The remaining objection - that collision data can be wrong, so "blocked" is not proof of "impossible" - is real, and the guard already answers it by abstaining wherever data is absent: no map, unmapped target, or any unmapped tile in the search box all return walkable and let the pathfinder decide. Only mapped, wholly blocked terrain is rejected. Not yet verified: this has not been compiled or tested since the revert, and TargetWalkabilityPreflightTest asserts against Dwarven Mine coordinates that cf8cf03 does not touch, so it should be unaffected. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
Important Review skippedToo many files! This PR contains 318 files, which is 218 over the limit of 100. To get a review, narrow the scope: Upgrade to a paid plan to raise the limit. Usage-priced reviews support at most 300 files. ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: ⛔ Files ignored due to path filters (6)
📒 Files selected for processing (326)
You can disable this status message by setting the ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
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
1 participant
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.
No description provided.