[v0.1.x/CLI] Cover the bridge's stdout-loss path beside the golden conversations #166

New issue

Closed

opened 2026-09-06 15:26:59 +09:00 by natsukium · 0 comments

natsukium commented

2026-09-06 15:26:59 +09:00

Owner

Why

The golden felis bridge conversations landed in #29 cover the clean
terminal, the failing terminal before the first item, cancel, and
daemon loss (crates/felis-cli/tests/fixtures/bridge/). The fifth
scenario the plan named, stdout loss, is not among them.

What was found

The golden harness (run_golden in
crates/felis-cli/tests/cli_bridge.rs) is defined by the stdout lines
a conversation produces: it feeds the in lines, collects one reply or
terminal per request, and diffs the normalized transcript. A stdout
loss produces no stdout at all — the bridge stops every operation,
closes every daemon link, and exits 1 without a correlated error,
because the channel that would carry one is the channel that failed
(docs/reference/cli.md, "Other verbs"). There is nothing for the
harness to diff, so the scenario needs a different assertion shape
(reader closed early, then exit code and the absence of further
output).

Why it is out of scope for #29

#29's acceptance criteria are the schema bundle, the fixture
validation, deterministic regeneration in CI, and golden coverage of
reordered concurrent replies and every terminal path. Stdout loss has
no terminal: it is an exit-code behavior, and adding a second harness
shape for it would not have made the schemas or the terminals better
covered.

What the follow-up should do

Add a cli_bridge.rs test that drops the read end of the bridge's
stdout while an operation is in flight and asserts exit 1, no
further stdout, and that stderr stays human-only.
Decide whether it belongs beside the golden fixtures at all or as a
plain assertion test; if the former, extend the fixture format with a
directive for closing the reader.

Split from #29.

## Why The golden `felis bridge` conversations landed in #29 cover the clean terminal, the failing terminal before the first item, cancel, and daemon loss (`crates/felis-cli/tests/fixtures/bridge/`). The fifth scenario the plan named, **stdout loss**, is not among them. ## What was found The golden harness (`run_golden` in `crates/felis-cli/tests/cli_bridge.rs`) is defined by the stdout lines a conversation produces: it feeds the `in` lines, collects one reply or terminal per request, and diffs the normalized transcript. A stdout loss produces no stdout at all — the bridge stops every operation, closes every daemon link, and exits `1` without a correlated error, because the channel that would carry one is the channel that failed (`docs/reference/cli.md`, "Other verbs"). There is nothing for the harness to diff, so the scenario needs a different assertion shape (reader closed early, then exit code and the absence of further output). ## Why it is out of scope for #29 #29's acceptance criteria are the schema bundle, the fixture validation, deterministic regeneration in CI, and golden coverage of reordered concurrent replies and every *terminal* path. Stdout loss has no terminal: it is an exit-code behavior, and adding a second harness shape for it would not have made the schemas or the terminals better covered. ## What the follow-up should do - Add a `cli_bridge.rs` test that drops the read end of the bridge's stdout while an operation is in flight and asserts exit `1`, no further stdout, and that stderr stays human-only. - Decide whether it belongs beside the golden fixtures at all or as a plain assertion test; if the former, extend the fixture format with a directive for closing the reader. Split from #29.

natsukium added the

priority/P2

label

2026-09-06 20:10:36 +09:00

natsukium referenced this issue

2026-09-07 15:46:32 +09:00

cli: publish JSON Schemas for the machine surface #180

natsukium referenced this issue from a pull request that will close it,

2026-09-08 20:51:40 +09:00

cli: cover the bridge's stdout-loss path #232

natsukium closed this issue

2026-09-08 21:56:47 +09:00