How Should I Structure This Code?
Answer the question in front of you and the tree narrows. Every leaf names why, what the recommendation costs, the simpler thing to try first, and the way the recommended design itself fails — because a recommendation with none of those attached is a preference wearing a diagram.
The questions are deliberately about the requirement rather than the technique. How many reasons this code has to change, whether the variation is observed or imagined, how long it has to live, and how many people edit it decide far more than any preference about patterns — and once those are answered most of the argument disappears. No leaf here tells you a structure is mandatory, because none of them is.
§207, the flagship. A requirement has arrived and you know roughly where it lands. Before reaching for a pattern name, say what the hard part of it actually is — a workflow, a rule, a dependency, a variation, a lifecycle, a boundary in the wrong place, or code nobody dares touch. Each of those has a different right answer, and every answer below costs something. If a leaf here looks free, it has been read wrong.