TL;DR
gbrain search --json currently emits line-oriented result text instead of a JSON object/array. Search itself works, but automation that reasonably expects parseable JSON from --json will fail.
Evidence
During the eva-v0.42.56.5 local canary:
gbrain search "Customer Support KB Agent Protocol openclaw-support-kb" --source openclaw-support-kb --limit 3 --json
returned output shaped like:
[1.0000] agents -- # Customer Support KB Agent Protocol
...
That is useful human output, but not valid JSON.
Why It Matters
Fleet/support health scripts can work around this by counting result lines, but the CLI flag name promises machine-readable output. This is exactly the kind of thing that makes agents think GBrain is broken even when retrieval is healthy.
Acceptance Criteria
gbrain search --json returns valid JSON.
- Existing human-readable search output remains available without
--json.
- Add a focused regression test for JSON parseability and source-scoped results.
TL;DR
gbrain search --jsoncurrently emits line-oriented result text instead of a JSON object/array. Search itself works, but automation that reasonably expects parseable JSON from--jsonwill fail.Evidence
During the
eva-v0.42.56.5local canary:gbrain search "Customer Support KB Agent Protocol openclaw-support-kb" --source openclaw-support-kb --limit 3 --jsonreturned output shaped like:
That is useful human output, but not valid JSON.
Why It Matters
Fleet/support health scripts can work around this by counting result lines, but the CLI flag name promises machine-readable output. This is exactly the kind of thing that makes agents think GBrain is broken even when retrieval is healthy.
Acceptance Criteria
gbrain search --jsonreturns valid JSON.--json.