Explain multiphase planning decisions
This commit is contained in:
parent
0b6da9d8e0
commit
511e188d16
2 changed files with 398 additions and 62 deletions
|
|
@ -242,6 +242,9 @@ Current pure planner status:
|
|||
It distinguishes request validation errors, missing patterns, shrink-bound
|
||||
rejections, invalid phase steps, and exact validation failures such as stale
|
||||
starts or phase overlap.
|
||||
- Multiphase planning also has an explained-plan entry point. Accepted plans
|
||||
report the deterministic strategy, phase reasons, participating nodes, and
|
||||
validation result; rejected plans report every attempted strategy and failure.
|
||||
- Planner tests now include a deterministic split-tree generator. It builds
|
||||
valid weighted tiling layouts, derives leaf hierarchy metadata, mutates them
|
||||
through supported transitions, and runs the real planner plus exact validator.
|
||||
|
|
@ -254,6 +257,7 @@ Tests:
|
|||
- nested containers do not produce simultaneous cross-axis motion
|
||||
- interruption restarts only affected phase groups
|
||||
- reversing direction produces equivalent motion in reverse
|
||||
- accepted and rejected plans expose deterministic strategy explanations
|
||||
- child waits for parent/container-space phases when moving upward into a
|
||||
toplevel peer position
|
||||
- mono-mode tab switches do not animate, while entering/exiting mono can animate
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue