The List
That Broke Five Harnesses

A set of Kubernetes anti-pattern checkers — five of them, each reading manifests independently to catch a different category of mistake — had all been validated the same way: pipe rendered YAML in, confirm the right verdict comes out. `kustomize build`, `helm template`, a raw manifest file. All of it arrives as one or more `---`-separated documents, and every checker's loader was written, reasonably, to split on that separator and parse each chunk.

A Different Way to Ask Kubernetes for the Same Thing

Validating a check against a genuinely running cluster means asking the cluster itself what's live, not just what was declared. The natural way to do that for more than one resource at once is kubectl get deployment app-a app-b -o yaml — name several resources, get their full manifests back in one call instead of one request per resource.

kubectl does return full manifests. It just doesn't return them the way `kustomize` or `helm` would. Naming two or more resources in one get call wraps the result in a single document: kind: List, with every requested resource nested under an items: array. No --- separator anywhere, because there's only one top-level document to begin with.

Five for Five, Not One

This wasn't one checker's parsing bug. Every checker in the set shared the same loader convention — split on ---, parse each chunk — because it had always been sufficient before. The moment a live-cluster validation round started feeding real kubectl get output with multiple resources per call, all five inherited the identical blind spot at once, for the identical reason. A single fix — detect kind: List and unwrap its items into the same document stream the rest of the loader already expected — closed it everywhere at once, which was itself a small confirmation that the five checkers had been sharing more implementation than their separate anti-pattern responsibilities suggested.

Why "No Resources Found" Is the Dangerous Failure Mode

A checker that crashes on unexpected input is annoying but honest — it tells you immediately that something needs fixing. A checker that silently finds zero resources to check looks, from the outside, identical to a checker confirming a clean pass. Nothing in the checker's own output distinguishes "I looked and found no violations" from "I looked at nothing." Anyone piping real kubectl get output with more than one resource per call through any of these checks would have gotten a green result — not because the resources were compliant, but because the checker never actually saw them.

What Changed

The fix isn't clever: check whether the top-level parsed document has kind: List, and if so, treat its items array as the document stream instead of the document itself. Cheap, a few lines, and it means a loader now accepts every shape the tools it actually gets fed can produce — not just the shape that happened to be the one used to build the test fixtures.