reviewer-horizonlisted

# Curated context becomes the reviewer's design boundary ## Problem You send a reviewer the rules you judged relevant. It returns a recommendation that violates a rule you did not send. You now have a collision that looks like a disagreement between two authorities, and it is not one — the reviewer never had the second authority in front of it. The damage is not the collision. It is what you do next. The natural write-up is *"the reviewer proposed X, but our conventions say Y, so the tree overrides."* That sentence attributes to the reviewer an error you created, and it closes the question without anyone testing whether Y is right. Worse, it is self-sealing. You selected the context, so the answer came back shaped like your selection, which reads as confirmation. ## Context / Trigger conditions - A review recommends something the codebase's own documented conventions forbid. - You are drafting the words "the reviewer did not know about" or "our rule overrides this." - You are assembling a brief and deciding which rules count as relevant to the question. - A recommendation fits your existing framing unusually well. - The reviewer had no repository access and worked from what you pasted. - You are dispatching a subagent to design or decide, rather than to fetch. ## Solution ### 1. Treat the collision as evidence about your brief first Before writing that a reviewer was wrong, check whether it was shown the rule it violated. If it was not, the finding is about the brief