A flag that ships and gets documented is doing something. In practice it can be a boolean handed to a pipeline that never reads it, and what hides that is not silence — it is that the command still answers. Confidently, in the right shape, from the right repository, about the wrong thing entirely.
The flag is --teach on a code-explanation CLI. Teaching is a real mode in the product: it keeps a lesson file, a queue of concepts and a thread, and it refuses to invent a lesson about something the scanned code does not contain. Only the server ever called the function that starts a teach turn. The command-line path passed its boolean in and received nothing back — no thread, no lesson, and, worst of the three, no refusal.
So ask --teach "I want to learn about machine learning" on a repository containing no machine learning did not say it had nothing to teach. It fell through to the ordinary explain path, took the repository digest, and paraphrased it fluently. The output was well-formed and about the codebase, and the only thing wrong with it was that nobody had asked about the codebase.
What makes this worth writing down is why it survived. The failing case requires two conditions at once: you have to use the headless path, and you have to ask about a subject the repository does not contain. Every ordinary use satisfies one and not the other. Ask a question the code can answer and the fall-through is invisible, because the answer you get is the answer you would have got anyway. The gap only opens on the input nobody types, which is the input where a refusal is the entire product.
There is a prior version of the same fault sitting in the history, and it is the reason the fix was written the way it was. This refusal rule had already existed in two copies once — the server had it and a separate bundle did not — and a subject-less ask reached a model call anyway, with each half passing its own tests. Two implementations of one rule is two rules that agree until they don’t. So the fix calls the shared assembly rather than importing the rule and restating it, which sounds like a style preference and is the difference between one behaviour and two that drift.
Seat-checked on the real repository — 1,094 nodes and 2,907 edges, not a fixture — asking to be taught machine learning now returns I could not find a subject for this lesson in the scanned repository, at exit zero, with zero provider calls. Asking about a file that genuinely exists is not refused and goes on to a real turn. The refusal arrives before the digest is built and before the model is reached, because a refusal that costs a model call is a worse answer that also spent money.
The test is the part I would keep if I could keep one thing. It runs a real child process against a real scan with a stub provider that records the prompts it receives, so what is asserted is that the refusal arrived instead of a model call — prompts.length === 0 — rather than that a refusal appeared somewhere in the output. Those are different claims, and only the second one is easy. A test that checks the text would pass just as happily on a version that refused after paying for a completion. Two controls keep it from being vacuous: the same ask without the flag still reaches the provider, and a teach ask naming a real file is still not refused.
And the fix is deliberately partial, which belongs on the page rather than in a commit nobody reads. Only the refusal was wired. The rest of a teach turn — the lesson file, the queue, the concept, the derived chart — is keyed on a thread, and the function that begins a turn refuses to file a lesson under a thread the caller did not name. A one-shot CLI has no conversation to name, so inventing one would put a false record of what somebody was taught into the lesson history. Refusing is computable from the question and the graph alone; the lesson is not. Wiring the rest needs a product decision about what a threadless lesson even means, and that has not been made.
The caveat that limits all of it: this is one command in one product, and the specific fall-through — an unread boolean landing in a path with a sensible-looking default — is a shape, not a measurement. I have no rate for how often it happens elsewhere and I am not going to imply one from a single case.
The judgement I would keep is that a feature can exist in the flag parser, in the documentation and in the code, and still not exist. What made this one invisible for its entire life is that the fall-through had a good default: when the flag did nothing, the command did the next most reasonable thing and did it well. A feature that fails loudly gets found on the first run. A feature that silently degrades into a competent answer to a question nobody asked can ship, get documented, and be used, and the only person who will ever notice is the one who asks it for something it should have refused.