find --fields returns numeric frontmatter values as strings

[phernandez]

What happens

bm find --meta … --fields chapter_number --json returns "fields": {"chapter_number": "63"} for a note whose frontmatter stores chapter_number: 63. Metadata predicates on the same field compare numerically (chapter_number>100 works), so the projection and the predicate disagree about the value's type.

Repro on the Moby Dick project:

bm find --meta 'note_type=chapter' --fields chapter_number,pov --page-size 2 --project moby-dick --json
# fields.chapter_number -> "63" (str), "62" (str)

Why it matters

Every consumer has to re-parse projected numbers (tonumber in jq, int() in Python); the skill's coverage jq currently does this defensively without knowing it is load-bearing. Booleans and dates presumably round-trip the same way.

Expected

Projected values keep the JSON type the frontmatter parsed to (int, float, bool, list), the same values the predicate layer compares against.

Found during the #1398 Moby Dick qualitative run.

🤖 Generated with Claude Code

https://claude.ai/code/session_014pmKq6bqCi6Zp6BTHuZjrp

[claude]

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

---

Triage

Type: Bug — find --fields projects frontmatter values through a code path that stringifies them, while the --meta predicate path on the same field compares numerically. The two are inconsistent about the value's type for the same underlying frontmatter data.

Component: CLI (bm find), specifically the --fields projection in src/basic_memory/cli/commands/posix.py (_display_find_fields/_plain_find_fields, which just serialize whatever the API/service layer hands back as row["fields"]). The predicate/comparison side normalizes numeric values via _normalize_scalar in src/basic_memory/repository/metadata_filters.py:86-95 (which stringifies int/float/bool for SQL comparison purposes) — worth checking during a fix whether the projection path reuses that same normalization instead of returning the original parsed JSON/YAML value. Not a Cloud-specific issue.

Priority: Medium — doesn't break find outright (numeric predicates still work correctly), but silently changes the JSON type of projected values, forcing every consumer (jq, Python, etc.) to defensively re-parse. Data-fidelity bug rather than a crash or data-loss issue.

Complexity: Simple–Medium — likely requires tracing where --fields builds its projection dict and ensuring it returns the original frontmatter-parsed value (int/float/bool/list) rather than a stringified one, plus regression tests confirming type round-tripping for at least int, float, bool, and date/list values.

No duplicate issues found for this report.

Labels applied: bug.