What happened
know add entries rejected by WriteGateService print the rejection to stdout and exit 1. Any pipeline that filters stdout (e.g. know add ... | grep ID to capture the new entry id) silently discards the rejection — the operator believes the entry stored when it didn't. Bit me twice tonight before I caught it: a long factual checkpoint entry was gate-rejected and the red message vanished into a grep.
Repro
know add "test-$(date +%s)" --content "$(python3 -c 'print("word " * 400)')" --no-git | grep ID
echo $? # 1, but nothing was printed — rejection message was on stdout, filtered awayProposed fix
- Write gate rejections (and other add failures) to stderr; keep stdout for the success table only. Standard CLI contract: stdout = result, stderr = diagnostics.
- Bonus: a
--quiet flag that prints just the entry UUID on success would make scripted use (ID=$(know add ... --quiet)) robust and remove the temptation to grep the table.
Secondary observation (separate concern, mentioning for context)
The gate rejected a dense, fact-heavy operational handoff (dates, paths, decisions) — plausibly a criteria false-negative on long multi-topic content. Not requesting a change here; just noting the gate's heuristics may deserve an eval set of known-good/known-bad entries, same pattern as hird-eval.
What happened
know addentries rejected by WriteGateService print the rejection to stdout and exit 1. Any pipeline that filters stdout (e.g.know add ... | grep IDto capture the new entry id) silently discards the rejection — the operator believes the entry stored when it didn't. Bit me twice tonight before I caught it: a long factual checkpoint entry was gate-rejected and the red message vanished into a grep.Repro
Proposed fix
--quietflag that prints just the entry UUID on success would make scripted use (ID=$(know add ... --quiet)) robust and remove the temptation to grep the table.Secondary observation (separate concern, mentioning for context)
The gate rejected a dense, fact-heavy operational handoff (dates, paths, decisions) — plausibly a criteria false-negative on long multi-topic content. Not requesting a change here; just noting the gate's heuristics may deserve an eval set of known-good/known-bad entries, same pattern as hird-eval.