A marked component is silently ignored in production — how would you make a consumer's failure to see that marker detectable?

## Why the silence happens A consumer that never sees a marked declaration produces the same observable behaviour as a system with no marker at all: the plain code runs. There is no error to report, because nothing is malformed — the declaration is valid, the marker is valid, and no component owns the question of whether the two should have met. Detecting this class of fault therefore cannot rely on something going wrong. It requires **manufacturing evidence that the reading happened**. The common causes are worth naming, because each technique below targets one of them: - the consumer never ran in this deployment at all; - it ran, but its candidate set did not include the marked declaration; - it ran and saw the declaration, but rejected it for a reason it did not report; - the marker never reached the phase the consumer runs in. ## Make "found nothing" an observable fact The cheapest and most useful change is to have every scanning consumer publish an inventory of what it accepted: how many marked declarations it found, and which ones. A count of zero, or a count of three where the team expects sixty, is then something a person or an alert can see at boot instead of something inferred weeks later from missing behaviour. Good inventories share a few properties: - they are emitted **once at startup**, at a level that is on by default, not behind a debug switch nobody enables in production; - they name the **candidate set** as well as the result, since "scanned this area, accepted three" diagnoses the wrong-area case immediately; - they report **rejections with reasons**, because a silently dropped candidate is the same failure one layer in; - they are exposed as **data the process can be asked for**, not only as a line of text at boot that scrolls away. ## Prove it in a test, not in production The stronger guarantee is a test that fails before the code ships. The critical detail is *what* the test asserts. Asserting that the marker is attached to the class tests the declaration — the half that is almost never wrong — and passes happily in exactly the scenario you fear. A test that proves consumption asserts the **consumer's observable effect**: 1. Declare a fixture in the test's own area and attach the marker to it. 2. Run the consumer the way the system runs it, over a candidate set that includes the fixture. 3. Assert the effect the consumer is supposed to produce — the fixture appears in the registry, the guard rejects a call that should be rejected, the wrapper is in place. That test fails when the consumer is absent, when it is pointed at the wrong area, and when it silently rejects, which are the three causes that matter. ## Fail the build on an unclaimed marker Where a codebase knows the set of markers it defines and the consumers that read them, a build step can pair them: for each attached marker, is there a consumer registered as its reader? An attached marker that no consumer claims is either a typo, a leftover from a removed feature, or a real gap. The important boundary is **only markers the codebase owns**. Declarations routinely carry markers belonging to consumers outside this build — tooling, other layers, other teams — and treating every unrecognised marker as suspect produces a stream of false alarms that trains everyone to ignore the check. A check that cries wolf about foreign markers is worse than no check. ## Fail closed where silence is dangerous Some markers describe a safety property: this path requires a permission check, this input must be validated, this operation must run inside a transaction. For those, "no consumer was configured" must not mean "the property is skipped". The guarded path should refuse to serve rather than serve unguarded, so the failure mode is a visible outage instead of an invisible hole. Markers that are merely descriptive — a category, a documentation hint, a metric name — do not deserve this treatment and should stay inert. ## What each technique actually catches | Technique | Runs | Catches | |---|---|---| | Startup inventory | every boot | consumer absent, wrong candidate set, unexpected count | | Test against a marked fixture | every build | absent, misdirected or silently rejecting consumer | | Unclaimed-marker build check | every build | markers no consumer in this codebase reads | | Fail closed on the guarded path | on the call | a safety marker whose consumer was not configured | Used together they cover the phases the marker itself cannot: the build knows what was written, the boot knows what was found, and the call knows what was actually applied.