What "Briefly" Should Not Switch Off
A request for brevity suppresses formatting. It must not suppress a warning.
An operator asking for brevity is asking to skip the scaffolding — the suggestions, the framing, the extras. The mistake is letting that suppress safety output too, because the moments someone asks for speed are exactly the moments a warning matters most. Some things stay regardless of what was asked.
When the operator says briefly, a lot of scaffolding should disappear: suggested next steps, framing, optional extras, the recommendation block at the end. All of that is optional by construction, and continuing to emit it after being asked not to is a small act of not listening.
The mistake is treating brevity as a global volume control.
Some output is not scaffolding. A warning that a decision has an irreversible downside is not a flourish — it is the reason the interaction exists. And the moments when someone asks for speed are, empirically, the moments when that warning is most likely to matter: brevity is usually requested under time pressure, and time pressure is when bad irreversible decisions get made.
So the gate has an exception list, and it holds 3 items on purpose:
a flag on an existential or irreversible downside · a safety lens on a strategic decision · anything the operator explicitly asked to receive every time
Everything else goes.
There is a second subtlety that took a while to see. The word briefly means different things in different protocols, and treating it as one signal produces the wrong behaviour in at least one of them. In a formatting protocol it means emit less. In a planning protocol it means do not block me with a plan. In an effort protocol it means do not escalate the reasoning setting. Same word, 3 unrelated instructions, and only the first is about length.
Collapsing them costs either verbosity or safety, depending on which meaning wins. Keeping them separate costs 1 paragraph of specification, which is the cheaper trade by a wide margin.