---
name: a-column-that-reads-one-value-on-every-row-is-a-broken-extractor
description: "2026-09-08 NEC list — 231 rows all \"executed in: .spt\" (path split at the first '/') and helper fns in the population; a uniform column is an extractor defect, check one known row before trusting a count"
metadata: 
  node_type: memory
  type: feedback
  originSessionId: b8201d4f-8b73-4b24-b257-ffeee9448400
  modified: 2026-09-08T14:33:53.639Z
---

The first never-executed-cells script for the #272 golden (2026-09-08) produced 231 rows every one of which read "executed in: .spt" — the relative path had been split at its first `/` — and 61 of them were helper fns (`drop`, `stderr`, `http`) because nothing checked for a `#[test]` attribute. The totals line looked like a finding ("61 with no preserved PASS line") and would have gone to deployah as one. My rewrite's first PASS regex then matched NOTHING (nextest prints `PASS [ t ] (n/N) crate cell`; the `(n/N)` counter was not in my pattern) and reported 174/174 never-passed — the opposite uniform column.

**Why:** an extractor that is wrong in one place is wrong on every row the same way, so the tell is UNIFORMITY, not implausibility — 100% or 0% on a column that should vary. A count derived from it is not a measurement.

**How to apply:** before reading any generated table's totals, pick one row whose true value you already know (here: a cell you watched pass in a named raw) and check the extractor reproduces it; if a column reads the same on every row, fix the extractor, do not interpret the column. Related: [[a-stamp-typed-from-the-previous-turns-clock-is-a-guess]].