Treating the speedup as a diagnostic is a useful frame, because it turns a tooling debate into a question about the organization. The three placements line up neatly: the objective before the work, context during it, verification after it.

The ASKUL part stood out most. A team told to restore optimizes differently from a team told to go past where it was, and no stage in AI-DLC can produce that sentence for you. Your suggestion to have two people write the objective separately and compare is cheap and would catch most cases where a team only thinks it agrees.

We see the same pattern at a smaller scale on client builds. When the problem and its finish line are written on a page before anything is generated, verification has something to check against, and the Spotify question about change volume becomes measurable. Without that page, review time goes into working out what was intended. Will the next part look at how LY assigns owners to the refresh triggers?