find --meta results display a note_type value that matches nothing

[phernandez]

The trap

find --meta note_type=X aliases to the frontmatter type: field, which holds the authored casing (Chapter). But the result row displays the snake-cased search-index projection (chapter). So the output shows you a value that, fed back into the same query, returns zero rows — silently, exit 0.

Verified against a live project:

$ bm find --meta 'note_type=chapter' --fields chapter_number --plain
exit=0                                       # <- zero rows, no error

$ bm find --meta 'note_type=Chapter' --fields chapter_number --plain
chapters/Chapter 1.md	{"chapter_number":"1"}
...
exit=0

$ bm find --meta 'note_type=Chapter' --json | jq '.results[0].metadata'
{"note_type": "chapter"}                     # <- the value that matches nothing

Same shape for multi-word types: LiteraryDevice is authored, literary_device is displayed.

Why it matters

An agent reading its own results learns the wrong value and writes a query returning nothing. Zero rows with exit 0 is indistinguishable from "no notes match" — the failure never announces itself. This is the same silent-wrong-answer class as the wrong-project writes (#1415) and the never-indexed empty reads (#1414).

Options

1. Display the value that queries (authored type) rather than the index projection.
2. Match case-insensitively on note_type predicates, so both spellings work.
3. Normalize the predicate the same way the projection is normalized, so chapter matches Chapter.

(2) or (3) seem kinder than making callers care about which representation they are looking at; (1) alone still leaves the two spellings behaving differently.

Found while verifying the literary-analysis skill's documented commands (#1424), where every note_type example was written from the displayed value and therefore returned nothing.

🤖 Generated with Claude Code

https://claude.ai/code/session_014pmKq6bqCi6Zp6BTHuZjrp

[claude]

Claude finished @phernandez's task in 51s —— View job

---

Triage

Type: Bug — find --meta note_type=X displays the search-index projection (snake-cased, e.g. chapter) instead of the authored frontmatter type: value (e.g. Chapter) that the same predicate actually matches against. Feeding the displayed value back into the query silently returns zero rows with exit 0.

Priority: High — this is a silent-wrong-answer failure (indistinguishable from "no notes match"), and it's the kind of thing an agent hits by trusting its own tool output, not a rare edge case. Not Critical since there's no data loss/corruption, but it actively misleads callers writing follow-up queries.

Component: Search/find (CLI find --meta, backed by the search index metadata projection — likely search_repository/search_service and the CLI find command). No Cloud-specific behavior involved.

Complexity: Medium — the fix is a normalization/matching decision (display vs. predicate parity), not a large refactor, but it needs to be applied consistently across the metadata-filter code path and covered by regression tests for both single-word and multi-word (LiteraryDevice/literary_device) type names.

Related: #1180 (closed) covered the same underlying authored-vs-normalized casing mismatch for write_note/schema_validate/search_notes note_type matching. This issue shows the same class of bug surfacing in a different path (find --meta display vs. predicate matching), so the fix for #1180 either didn't cover this code path or the display/query asymmetry was reintroduced. Worth checking whether #1180's fix was scoped narrowly enough to miss find --meta.

No reproduction steps needed — the issue includes a clear live-project repro and root-cause analysis. Leaving implementation (including the choice between the three proposed options) to a follow-up PR.