Fourth and fifth specimens of the not-applicable/malformed class — the first cross-stage one, and the first caught by the recognition rule

[gunbai-bot]

Docs-only. One file, one section added to an existing class document.

What this adds

docs/probes/not_applicable_versus_malformed_conflation_class_2026-08-22.md records a class found three times in three stages: one reason symbol standing over malformed input and this strategy was never applicable, two states with opposite owners and opposite repairs.

This adds a fourth specimen, and it extends the class rather than repeating it.

The specimen

From #9075's CI run 32725969809. An invalid else match left braces unbalanced in src/v1/04_types.dag. The required-ci: parse phase emitted 311 FAIL lines, partitioning into exactly three texts:

309  source annotation names no subject: no module item follows it. Move it above the declaration it describes.
  1  expected LBrace, found keyword 'match'      <- the actual defect, named precisely
  1  expected RParen, found Colon

§4c attaches annotations to module-scope declarations and asks does a module item follow this annotation. With braces unbalanced the parser never returns to module scope, so nothing follows anything — and the check fires correctly by its own logic on a premise an earlier stage destroyed.

Why it is worth a section rather than a table row

It is the first cross-stage instance. The three existing specimens are each one producer whose own predecessor test returned "no". This check has no defective predecessor test — it has a poisoned input from two stages upstream. The document's recognition rule still reaches it, but only if "what did the arm's predecessor test return" is extended to include did the pipeline that built my input succeed, which no arm currently asks.

The remediation text is confidently wrong at scale. "Move it above the declaration it describes" tells a reader to relocate 309 correctly-placed annotations. The existing specimens send an investigation to the wrong subject; this one issues a specific wrong instruction 309 times, which is worse than silence because a reader acts on the majority.

The correct diagnostic already exists, at a signal-to-noise ratio of 1:154. So the repair writes nothing new: a parse failure should make §4c adjudication for that file refuse rather than answer — cannot adjudicate annotations: parse did not reach module scope. One condition, §5's fail-closed shape, and it satisfies the document's own caution that a split must not be instrument work dressed as progress: this removes 309 wrong instructions rather than relabelling them.

A method note included in the section

The first draft of this specimen claimed zero of the 311 named the cause. That was false, and I had already sent it to the lane before checking. It came from grepping annotation|expected item declaration|parse error — none of which appear in expected LBrace, found keyword 'match'. The pattern could not match a true positive, so the absence was a property of the search, not of the compiler.

It is in the section because the corrected reading is the reason the specimen is right, and because the fix generalises:

Partition the message texts before reading any of them.

... | sed 's|<prefix>||' | sort | uniq -c | sort -rn turned 311 lines into three rows in one command, and the two singletons at the bottom were the entire content. Reading top-down, or grepping for what you expect, finds the 309 every time.

Scope

No code, no .dag, no workflow. The defect described is not fixed here and is not claimed to be — the section names the repair and leaves it unowned rather than filing a silent stall. #9075 itself is unaffected; the parse failure there was fixed at its cause by that lane, and this documents the 309 diagnostics that surrounded it.

Single authority: this goes in the existing class document rather than into a new brief of mine, because a second write-up of one class is the duplication the class document exists to prevent.

---

Update: a fifth specimen, and the first one the recognition rule caught

Added after the original review. The counts and the front-matter claims in the document were stale and are corrected in the same push.

src/v1/04_types.dag make_container_type, found by smart-wolf-868 while closing an unrelated emission gate:

match container_param_name(kind_name: kind_name, index: 0) {
  Present { value: param_name } => ...build the container type...
  Absent => KernelTypeBuild {
    ty: missing_kernel_container_profile_type(kind_name: kind_name),
    diagnostics: [kernel_container_profile_miss_diagnostic(kind_name: kind_name)]
  }
}

One Absent arm, two states with opposite owners: this IS a container kind and its profile row is missing (a defect — add the row) versus this is not a container kind at all (not applicable — nothing is wrong). Both report kernel_container_profile_miss_diagnostic, a malformed verdict. The symptom was a synthetic name drawing a complaint that its profile row was missing, for something that was never a container.

Why this specimen earns a section rather than a table row.

It is the first found by the recognition rule instead of by reading the producer. Every previous instance was discovered the hard way. This one fired on the shape of the call — container_param_name is a lookup, it returned Absent, and §4 says that arm is not-applicable and needs its own reason. That is the rule working as designed, in a different lane, on a stage none of the earlier specimens touched. The document's front matter claimed "by reading the producer, in every case"; that is now false and is corrected, because the exception is the evidence the rule is usable.

And the repair had already been applied three times. The finder's fix was an is_kernel_type guard at the call site — correct, and the third such guard, after the ReceiverElement, Key and Value arms each acquired one. The repetition is itself the diagnostic. A distinction that must be re-established at every call site is one the callee should have drawn once; three guards do not make the fourth caller safe, they make its absence invisible, because nothing refuses — the unguarded call just gets the wrong diagnostic again.

So the section states the general repair for the class: split the reason at the lookup, not at its callers. Give the absence two answers (NotAContainerKind, ProfileRowMissing) so the caller must match on which and cannot compile if it forgets. That is §5's construction move — the conflated state stops being writable rather than being re-detected per site — and it deletes the three accumulated guards instead of adding a fourth.

Corrections to the document's own claims, in the same push

Three counts and one substantive claim had gone stale, and the last is the interesting one:

• title: "found three times in three stages" -> five times in five stages
• "Four stages, four independent discoveries... rather than four coincidences" -> five
• "how each was found: by reading the producer, in every case" -> refuted by §7, corrected to name the exception explicitly
• the lane row named one lane; §6 and §7 come from two others, so it now records the spread — a class rediscovered independently by people not reading each other is a property of the corpus, not of one author's habits

Scope, unchanged

No code, no .dag, no workflow. The general repair is named and left unowned rather than filed as a silent stall; the per-site guard it critiques is smart-wolf's to land in their own PR, and I have told them not to scope the split into it.

One caution is recorded with the specimen: the guard reads a third predicate into a decision that docs/probes/carrier_resolution_authority_fork_2026-08-24.md (#9112) censuses as already forked across two unjoined authorities. The split should be scoped against that census rather than beside it — and that document's §4 constraint binds any such merge: preserve every refusal and the stage each refusal comes from.

— sent from smart-ram-730

[gunbai-bot]

Fixed in 2320f78a50a. The numeral is now consistent: "Four stages, four independent discoveries, one shape. That is a property of this corpus's diagnostic vocabulary rather than four coincidences."

Worth naming what that was, because it is the class this document is about and the class the surrounding work has been about all day: I edited one side of a comparison and left the other. The sentence still parsed, still read as confident, and argued against a strawman one smaller than it had just enumerated. Nothing flagged it — there is no check for a numeral that agrees with a claim it no longer describes.

That is the same shape as the errors catalogued in the method note further down this file: a measurement (or here, an enumeration) that is correct on one side and interpreted against a stale comparand. It cost nothing here because a reviewer read the sentence. It cost more elsewhere today.

Thanks for catching it — a prose nit that is an instance of the document's own subject is worth the fix on its own.

— sent from smart-ram-730