Based on these results, the initial pathfinding scope should include:
1.**Standard jumps**: sprint jump can clear up to 5 block gaps (flat)
and 4-5 block gaps with +1.0 height, with full momentum.
2.**Standing sprint jumps**: only reliable for up to 1 block gap with
+1 height, or 2 block gap flat. This is relevant for confined spaces
where a long run-up is unavailable.
3.**Neo jumps (1-2 block walls)**: comfortable margin with sprint.
The pathfinder should include these as standard movement options.
4.**Ascending jumps (+1 block)**: always feasible with sprint for gaps
up to 5 blocks. The key constraint is the 1.252 block jump height
limit, meaning +1.0 is fine but +1.25+ is extremely marginal.
5.**Ceiling constraint**: a 2bc (headhitter) ceiling cuts reach roughly
in half. The pathfinder should detect ceiling height and adjust the
maximum jump gap accordingly.
## Reliability-first rule
Every movement proposal generated by the MCC pathfinder must be grounded in reality: if a move is accepted, it must be one the bot can execute in vanilla 1.21.11 physics. That means the final support footprint is the ultimate arbiter: if the planner can get the player onto a solid block (even if they momentarily hover over air during the transition), the move is considered valid. Conversely, any shape that would finish without block contact, rely on unsupported parkour tricks, or require a start-up/run-up that the current layout cannot provide must be rejected rather than downgraded to a risky heuristic.
The new regression harness in `tools/test-pathing-template-regressions.sh` codifies this rule by automating:
1. Flat-stopping scenarios that ensure the arrival block is within the planner’s tolerance.
2. Parkour + L-turn footprints to watch for actual support at the destination.
3. Side-wall jump acceptance conditioned on an executable landing.
4. A 3×1 no-run-up rejection to prevent non-executable plans from sneaking through.
5. Mixed ascend/descend/climb smoke cases so that both vertical transitions and ladder climbs respect the reliable support requirement.
For the short-route and long-route `1.21.11-Vanilla` live harnesses, accepted routes must complete with all of the following:
-`A* result: Success`
-`0 replan`
-`0` template segment failures
- final position inside the intended goal support block
-`PathMgr` reporting `Navigation complete!`
For rejection scenarios, the requirement is stricter:
-`A* result: Failed` or `No path found`
- no navigation start
- no executor-driven `replan`
Residual speed carried from one movement to the next inside a route is expected and must not be normalized away just to satisfy the harness. The route is only considered reliable if that natural speed carry still produces `0 replan`.
## Baritone Reference Notes For Zero-Replan Work
MCC can borrow specific ideas from the local Baritone reference under `ThirdpartyReference/baritone/`, but not its looser success semantics.
Borrow:
- landing-aware completion, where movement logic keeps controlling after touchdown instead of failing immediately
- next-movement-aware descend and ascend handoff behavior
- conservative parkour admissibility, especially around run-up, overshoot, and blocked landing shapes
- executor timeout and movement-stuck heuristics as diagnostic input, not as acceptance criteria
Do not borrow:
-`GoalBlock` occupancy semantics as a substitute for deterministic execution quality
- executor repath tolerance as proof that a movement is reliable
- any behavior that lets accepted deterministic harness routes succeed only by falling back to `replan`
For this work, Baritone is a movement-control reference, not a correctness oracle. MCC's accepted live routes must still finish with `0 replan` in the deterministic harness.
Keeping the rule explicit here reminds future contributors that the planner should never promise a move that physically cannot finish with block contact.
