Add `pipe queries`, which lists every Firestore query a project can issue:
scope, collection, path pattern, filters with operators and value types,
composites, orderBy, limit, cursors, realtime, aggregation, in-loop, plus a
confidence and the reasons it is not exact. Receivers are matched by static
type and cloud_firestore library URI, never by name.
Queries are followed through chains, local variables (flow-insensitive with
two cuts), fields, getters and one level of helper methods with arguments
bound. An --adapter-config (YAML or JSON) maps declarative query APIs such as
a server-side gateway onto the same schema.
Inventory only: no rules, findings or baseline changes. Every emitted name is
validated against a safe character set so no source text reaches the output.
With several --dir values, one that did not exist was skipped silently: the
no-files guard only fires when every directory is empty, so
`--dir lib --dir tset` scanned lib and reported as though it had covered what
was asked for. A --dir that does not exist is now an error naming it.
A directory that could not be listed, or a baseline that could not be read or
written, escaped as an uncaught FileSystemException: exit 255 and a stack
trace. Those paths now raise a PipeException with the OS reason (exit 2), and
bin/pipe.dart catches any remaining FileSystemException the same way. The exit
codes are documented in bin/pipe.dart: 0 success, 1 a gate failed, 2 pipe could
not do what was asked, 64 usage.
rule_scope_claim_test widened the fixture with a test/ directory it does not
have, relying on exactly the silent skip; it now builds a project that has one.
An execution sweep comparing README flags against what each command accepts found
no documented flag that the CLI rejects, but five working flags the README never
mentioned: index --fail-on-error, suggest --max-actions/--budget,
guide --max-findings/--yams-name, recall --manifest. Each is now described with
its verified behaviour (e.g. index exits 1 with analyzer errors, 0 without), plus
a note that numeric flags reject non-positive-integer values instead of falling
back to a default.
Eight sites read a numeric option as `int.tryParse(...) ?? <default>`, so a typo
was answered with a different number and a success exit:
$ pipe check . --top 2o # showed 25 rows, exit 0
$ pipe guide . --budget abc # used 6000 chars, exit 0
Meanwhile --concurrency and --limit already rejected bad input with a clear
message, so the CLI disagreed with itself about whether a bad number is an error.
Every numeric option now goes through readPositiveInt(): --top, --budget,
--max-actions and --max-findings included. This is the same principle as the rest
of the tool - do not silently substitute a value the user did not ask for.
Second, related defect in `suggest`: each numeric option was read inside the one
output branch that uses it (--top in the text branch, --max-actions in the agent
branch, --budget in the agent branch), so a malformed value was ignored entirely
on the other paths - `suggest --top abc --format agent` exited 0. All three are
now read and validated before the format switch, so the value is rejected
regardless of which branch runs.
Found by executing every command with deliberately bad flag values, which is part
of the execution-first sweep that also turned up the broken `graph`. Two external
read-audits reported no defects in this area.
95 tests (was 91), dart analyze clean, determinism re-confirmed byte-identical
across -c 1/4/8 for check/state/graph/suggest.
Registration is not execution: a command can register every option and still
fail at run time. GraphCommand did exactly that, throwing
`ArgumentError: Could not find an option named "--dir"`. This runs the real
command against the fixture and asserts it completes.
`pipe graph` was completely non-functional. GraphCommand had no constructor, so
it never called _addCommonOptions, yet its body reads --dir, --sdk,
--concurrency, --include-generated, --limit and --format. It therefore registered
only --help:
$ pipe graph lib
Unhandled exception:
Invalid argument(s): Could not find an option named "--dir". (exit 255)
$ pipe graph lib --format json
Could not find an option named "--format". (exit 64)
So a documented command died on an unhandled exception instead of a clean CLI
error, and its JSON output was unreachable. Fixed by registering the common
options like every other project command.
Found by smoke-testing every command, which is what the two external audit
rounds never did: this round's auditor listed "run pipe graph and pipe check" as
a NEXT area to audit and never ran graph, and reported no confirmed defects.
Guard: test/cli_options_test.dart asserts every project command registers every
common option it reads (recall is exempted - it deliberately targets a corpus
root and registers its own equivalents). It fails without this fix (+0 -2).
Also, from the same round's unconfirmed suspicions, both of which reproduced:
- recall: an unrecognised `status` is now rejected instead of silently read as
`open`. `status` decides whether a case is a bug pipe must find or a permanent
regression guard, so a typo like "fix" defaulted to `open`, printed MISSED, and
sent the reader hunting for a regression that was really a manifest typo.
- recall: MISSED and REGRESSED entries now print their `note`. The manifest
already carried the explanation for the two nuwayze misses ("wired up on branch
wire/nuwayze-* (unmerged)") but the report never showed it, so an expected miss
looked exactly like a regression in pipe.
Recorded as NOT a defect: `pipe verify` exiting 0 while listing "new" findings.
`--expect-resolved` is documented - and implemented - as failing only on
baselined findings that are still reported; `verify` fails correctly in that case
(exit 1). It has no fail-on-new flag, which is a gap for CI use rather than a
contract violation, so the documented behaviour was left alone.
90 tests pass (was 84), dart analyze clean.
