Exercise 1: Tracing move_to's Update Order — Possible Solution ==================================================================== WHAT move_to UPDATES FIRST ------------------------------ Per this chapter and Chapter 10, move_to first calls update! on the moved page itself, setting its new parent and recomputing its own full_path directly from the new parent's full_path plus its own slug, saving that change immediately. WHAT update_descendant_paths! UPDATES AFTERWARD ------------------------------ Per this chapter and Chapter 10, only after the moved page's own full_path has been saved does update_descendant_paths! run, iterating over each child, updating that child's full_path from the moved page's now-current full_path plus the child's own slug, and recursing into that child's own children afterward. WHY THE ORDER MATTERS ------------------------------ Per this chapter, every descendant's full_path is built directly from its own parent's full_path. If the recursive walk ran before the moved page's own path was updated and saved, every descendant would be recalculated from the stale, pre-move path instead of the correct new one, leaving the whole subtree with wrong paths. WHY THIS WORKS AS AN ANSWER ------------------------------ It correctly describes move_to's first step (updating and saving the moved page's own path), correctly describes update_descendant_paths!'s subsequent recursive walk, and correctly explains why this specific order is required.