dotfiles/claude/memory/feedback-verify-counts-two-ways.md

name, description, metadata

name	description	metadata
verify-counts-two-ways-mechanical-sweeps-are-finicky-in-this-shell	grep tallies / frontmatter scans misfire in this zsh (glob quirks; all-tree greps catch HTML class= + code-block noise). Verify every count two ways before it enters a record; and don't dismiss correct data on a prior expectation. Three near-false-findings caught this way 2026-05-29.	node_type type originSessionId memory feedback a8eb1d46-314e-4545-a133-f747c69ad5b4

Mechanical corpus sweeps (class-tallies, frontmatter scans, "does X exist" greps) are unreliable in this zsh shell and must be cross-checked before any count enters an audit or a record.

Why: observed repeatedly on 2026-05-29 during the code-represents-spec audit —

• --include=*.md unquoted → zsh "no matches found" (glob expansion); the tally silently didn't run.
• grep -rhoE across all of content/ caught non-frontmatter class: (HTML class= attributes, code blocks) → spurious "types" (offering, lex, not-found, sequence-index) that looked like clause-1 findings.
• Two runs of "the same" tally disagreed wildly (124 essay vs 193 glimpse) — one was noise, one was right.

How to apply:

• Prefer per-pattern grep -lE '^class:[[:space:]]*X' files | wc -l (count files matching one exact pattern) over -o/-m1/sed pipelines.
• Quote globs: --include='*.md'.
• Scope explicitly (e.g. content/posts + content/pages, not all of content/ with its chamber HTML).
• Confirm any surprising count a second way before reporting it — both directions: don't assert a finding from a noisy tally, and don't dismiss a correct tally because it violates a prior expectation (the "essay must be dominant" anchor nearly buried the true glimpse-dominant count).

The cost is real (tool-churn), but it is the "once, correctly" tax. Related: feedback-trust-prior-pass-frame (verify-before-compose); the logged drift asserting-fs-state-from-a-misread-listing.