fix: filter and capture handling in the query engine, the reporter aborts it exposed, and four parser boundaries

[awsmadi]

Continues #717, which was merged at 567c0d7. These are the commits made on that branch afterwards and so
not part of it. Rebased onto current main; the tree differs from the pre-rebase branch only in the
lockfiles ef17f36 patched.

Same class of defect as #717: a rule that answers compliance for a check that never ran, or a run that
exits non-zero and names no finding.

One CI job is expected to be red, and it is not this branch's doing.
aws-guard-rules-registry-integration-tests-* fails because a change here — failing a run when an
expectation names a rule that produces no verdict — is correct and the registry has 30 such expectations, all
in rules/aws/aws_cloudformation, naming 11 rules their file never defines. Measured: exactly 1 of 49
registry directories changes its exit code, and stdout is byte-identical over the whole corpus, 9,156 lines
either way. The fix is aws-cloudformation/aws-guard-rules-registry#288, which takes
cfn-guard test -d rules on that repository from exit 1 to exit 0 against this branch's binary. Both registry
jobs are also now pinned to a SHA instead of tracking main, so a commit in another repository can no longer
turn this one's CI red without a change here; read that pin as a lock on a known state rather than a green
one, and move it forward once #288 lands.

A typo could delete a rule and report compliance

extract_message searched all remaining input for the closing >>, so one forgotten tag consumed every
rule up to the next rule's tag as message text and those rules ceased to exist. A file whose second rule
the template violated reported PASS at exit 0 — no finding, no diagnostic on any channel, and a parse
tree holding only the first rule with the rest of the file inside its custom message.

A message is now delimited by the grammar the language actually uses, rather than by a bound on the search.
A >> on the opening line closes the message; otherwise the message ends at the first later line whose
trimmed text is exactly >>; otherwise it is the error this code already raised for a missing tag.

Two earlier attempts at this each bounded the search, and each was wrong. They are worth stating because
the shape of the mistake is the same both times. Stopping at the first line whose first token is } or rule
finds a forgotten tag whose next >> is in a later rule, but when the next >> belongs to the next clause of
the same block no such line sits between the tags, so that clause was still swallowed at exit 0 -- in a rule
body, in a type block and in a when block. It also rejected a legitimate body quoting example JSON, because
such a body has a line starting }. Stopping at the next << fixed all of those and broke a third case: with
no second << in the file the search ran on to a >> inside a comment and closed the message there, so

rule one {
    Resources.One.Type == "AWS::S3::Bucket" << closing tag forgotten
}
rule two {
    Resources.One.Properties.Encrypted == true
    # see the runbook for escalation >>
}
rule three {
    Resources.One.Properties.Public == true
}

parsed as rules one and three, with rule two absent from the parse tree, and exited 0 against a template rule
two violates. Taking the minimum of the two bounds does not work either: a comment carrying >> at the end of
the same block is silent under both, since neither a } line nor a second << sits between the tags.

Each of those bounds inferred document structure from a token that may legitimately appear inside a message
body. A terminator line infers nothing -- it is what a closing tag looks like in 231 of the 233 messages that
exist. The census is the whole basis for the design: of the 233 messages in the AWS rule registry and this
repository's fixtures, 231 are block form with the closing >> alone on its line, 2 are inline with both tags
on one line, nothing follows >> on its line in any of them, and there are no other shapes.

Two behaviour changes fall out. The JSON-quoting body now parses, because a brace in a body is text, so this
removes a limitation rather than documenting one. And a block body whose closing >> shares its line with body
text, as in << Violation: X then Fix: Y >>, is now a parse error. That is a narrowing, and it cannot be
avoided: the swallowed clause in the example above is itself a line ending in >>, so anything that accepts
the one accepts the other. No message in the corpus is written that way. It is asserted as a rejection so it
is not reopened by loosening the terminator.

All four broken shapes exit 5 now, for one reason rather than four. Measured against the previous bound over
2,494 fixture pairs and 276 rules files: zero exit-code, stdout and stderr differences, and byte-identical
parse trees, so all 233 messages parse exactly as before. Regression tests cover the four broken shapes, both
accepted forms, the empty message, and the rejectedthree shapes.

Five more readings that were not what the author wrote

• A leading space changed the query part. [x] gave AllIndices and [ x ] gave AllValues, because
  the named branch of all_indices did not skip whitespace. Two spaces were then the difference between a
  working rule and an unevaluatable one: Tags.%k[x] == "prod" passed at exit 0 while Tags.%k[ x ] bailed
  at exit 19, since the %var interpolation arm accepts one query part and not the other.
• when was a tag in front of a cut. It matched the first four characters of whenCreated, the
  whitespace requirement after it failed, and the cut made that unrecoverable — so any clause whose first
  identifier began when or WHEN was a parse failure. rule whenever { ... } defined fine and a
  whenever reference did not: a rule you could declare and never call.
• A name assigned twice in one scope resolved by kind precedence, not order. let v = 1 then
  let v = 999 failed a rule that the reverse order passed, and two assignments of different kinds
  ignored their order entirely, because literals, queries and function calls go into separate maps consulted
  in a fixed order. Rejected now in both scopes. count.guard in this repository was a live instance: it
  bound res twice and asserted %res == 3 after each, so the first assertion tested the second count —
  and would have failed had it been live, because there are five properties and three collection entries.
  Both counts are now named and asserted.
• keys was reserved for every clause rather than for key filters. A cut after the keyword stopped
  [ keys EXISTS ] from reaching the branch that parses it. The identical clause parsed one slot later,
  which is what showed nothing ambiguous forced the rejection.
• in and the seven IS_* operators were plain tags. Size IS_INTEGER parsed as IS_INT plus a
  reference to a rule called EGER — loud with no such rule, PASS at exit 0 with one. The same guard
  true, false and null already had.

Three smaller ones: i64::MIN was the single integer the parser refused, a rule reference could not end its
block (rule b { a } was rejected while the same rule over three lines parsed), and the normative grammar
comment documented NOT_IN and a clause-level KEYS, neither of which was ever accepted.

The data loader, where every rule's answer starts

A data file of nothing but comments aborted the process. Exit 101,
panicked at guard/src/rules/libyaml/event.rs:63: not implemented, on four shapes: one comment line, the same
without a trailing newline, several comments with blank lines between them, and a fully commented-out template.
An empty file and a whitespace-only file already exited 255 saying the file is empty, so the degenerate case was
handled and this one was not. The event arriving at the wildcard arm is YAML_NO_EVENT, and it arrives because
the loop had no exit for a stream that never started a document: DocumentEnd was the only arm that returned
and StreamEnd shared the no-op arm, so the next pull ran past the end of the stream and libyaml answered it
with a success. StreamEnd now ends the loop and reports the file as holding no document, worded as the message
an empty file already gets. The wildcard arm remains and no longer aborts; it returns an error carrying the
event type, so a future miscount stays diagnosable.

True and TRUE were read as strings, so a gate never fired. Under
when Properties.PublicAccess == true, against a bucket with Encrypted: false: true, yes and on exit 19
and catch the violation, and True and TRUE exit 0 leaving it unchecked. is_bool_true and is_bool_false
matched lowercase only, while the null arm two lines below lowercased first, so within one function null was
case-insensitive and bool was not. YAML 1.1 makes all 22 spellings boolean; the 1.2 core schema admits six. The
loader already read yes, on and the single letters, which only 1.1 makes boolean, so the vocabulary was
already 1.1's with the capitalised spellings missing, and those four are boolean under both schemas so they were
missing whichever version was meant. test_handle_bool_happy_path has enumerated all 22 as the intended set
since it was written — and could not fail, because its assertion sat inside an if let MarkedValue::Bool(..) and
14 of the 22 cases passed while asserting nothing. handle_type_ref used str::parse::<bool>, so an explicit
!!bool yes was stricter than a bare yes; both now agree. Case-insensitive matching was rejected because
tRuE is boolean under neither schema, and narrowing to the 1.2 set was rejected because it would take yes
and on from documents that write them, which is a separate argument.

A query for Tags was answered out of Tag. A rule asking Properties.Tags.Name of a bucket with
Properties.Tag.Name reported a ComparisonError over /Properties/Tag/Name carrying that value: the rule
named one property and was answered about another. One-way, since Tag against Tags reported
MissingProperty. The cause is the class-case entry in the converter list the lookup falls back to when a key is
absent as written. cruet's class case is Rails' class-name rule, PascalCase and singular, so
to_class_case("Tags") is Tag; every other entry respells a key rather than naming a different one, and
to_pascal_case already covers PascalCase. It is not a plural rule either — Analysis becomes Analysi and
Metadata becomes Metadatum. Removing it costs no reach, measured by instrumenting the fallback: class case
won 57 lookups across the registry's 193 paired files and pascal, title and train produced the identical string
for all 57.

A duplicated key took the last value and said nothing. Encrypted: false followed by Encrypted: true
evaluates as true, the reverse order as false, and {"Encrypted":false,"Encrypted":true} the same way, all
with nothing on stderr. A reviewer reading a template top-down sees the first value and the tool judges the
last. YAML 1.2.2 makes this a loading failure rather than a merge — a mapping's keys must be unique per §3.2.1.1
and §3.2.1.3, and §3.3 lists non-unique keys among the loading failure points — so rejecting the document would
be defensible, and it would also fail every template carrying one today, which is a maintainer's call. This
reports the fact and leaves the verdict: one line naming the key's path and both locations, the last value still
winning, no exit code moved. The duplicate is not visible in the loader, which keys its maps on name and
location so both entries survive; they collapse a layer up where the map is rebuilt on the name alone, which is
also the only point that holds the path the key was reached by. Detection is per-mapping by construction, so a
property name repeated across two resources — which nearly every real template does — cannot register. Counted
before building: one occurrence in 71 corpus files, in the fixture that exists for it, and none in 256 registry
files. cfn-guard test still cannot report duplicates in its embedded inputs, because serde_yaml collapses a
repeated key during deserialization before any of this runs.

An unreachable!() in the FFI error table. get_code in guard-ffi answered Error::InternalError with
unreachable!(), in the table every error crossing the boundary is fed through and the same one that gained a
code for the no-document error above. It is not reachable through cfn_guard_run_checks as the code stands —
that path parses through serde and never touches the libyaml loader, the one construction site that is on the
path is mapped to ParseError first, and all four non-string key shapes come back as ParseError without
panicking. It is fixed regardless: Error and run_checks are public, the remaining variants are constructed
in a module this path avoids only because it writes through a BufWriter of its own, and a table total over
every variant should not rest on an unreachability the next commit can invalidate. The arm gets a code and the
table stays exhaustive rather than gaining a catch-all, since exhaustiveness is what surfaced it.

A leading space before a numeric index or a quoted key was a parse error, while every other bracket form
tolerated one. Names[0] and Names[0 ] parsed; Names[ 0], Names[ 0 ], Names[ -1 ] and
Resources[ "MyBucket" ] did not. This is the [x]-versus-[ x ] defect a second and third time: that fix
added whitespace skipping to the named branch of all_indices and left the numeric index and the quoted key
alone. The tests compare the resulting query part rather than merely that the file parses, because falling
through to a different part is how the first version of this defect did its damage.

Filters and captures in the query engine

[*] and .* both expand a map and hand each entry's value onward. That is right for a collection and
wrong for a single object whose fields the filter names: for
{ Statement: { Effect: Allow, Action: "s3:*" } } the values reaching the filter were the strings Allow
and s3:*, Effect == 'Allow' matched neither, and the filter selected nothing. An assertion over an empty
selection is a SKIP, so the two spellings disagreed — .* failed and [*] exited 0.

A filter capture leaked across iterations of a block. An iteration that captured nothing under a name fell
through to the parent scope, which by then held the earlier iterations' merged keys, so a non-compliant
resource passed on a compliant neighbour's key. Adding a compliant resource is what made the non-compliant
one pass, which is why such a rule looks correct when tested one resource at a time. BlockScope now carries
the capture names its own clauses declare, read out of the rule text rather than learned at runtime — the
first attempt learned them as keys were captured, which made the verdict depend on document order.

A bare bracket is a capture too, and was not counted as one. Properties.Tags[ tk ] written without a pipe
goes through all_indices and becomes AllIndices(Some("tk")), which captures the entry's key at retrieval
exactly as a filter does, but the name collector read Filter and MapKeyFilter only. No block declared the
name, so the lookup deferred to the parent, which held the keys earlier iterations had merged up. A resource
that captured nothing was credited with a previous resource's key and document order decided the verdict: with
the capturing clause in one when block and the reading clause in a sibling when block that only a resource
without Tags enters, one order exits 0 and the other 255. All orders now agree at 19. Pre-existing;
origin/main gives the same three codes, because no scope there held the name at all. The function's own doc
comment claimed AllValues and AllIndices were collected through arms of their own, and there were none.

Resources[*][ nm | ... ] then %nm ended the run at 255 while Resources[ nm | ... ] — the same filter
without the wildcard — worked. After a wildcard the map was already expanded when the filter ran, so the
name was discarded and the capture never made. The filter now runs at the expansion site, where the key is
still in hand.

Reporter aborts and findings with nowhere to go

Four reachable unreachable!() in the CloudFormation reporter and a reachable todo!() in the Terraform one
took the process down at exit 101, the latter on an everyday rule (IN against a plan). One was reachable
only after fixing the panic in front of it, which is why "not reproduced" is not the same as unreachable.

One rule that could not be evaluated discarded the whole file's report, in all four output paths and in
cfn-guard test: a file whose second rule read a variable that does not exist printed one error line and
threw away five real findings from its third rule.

Findings the per-resource output cannot place are reported under their own heading, Findings that belong to no resource:, each entry naming the rule it came from. The existing Could not be evaluated: is for a block
or rule that failed on a condition nobody could decide; these clauses were decided and merely have nowhere to
be printed, and filing a missing property under "could not be evaluated" would report an ordinary failure as
an undecidable one.

Which findings those are is decided by what the reporter rendered, not by predicting it from paths — and
the first version of this section predicted, wrongly, in both directions. It asked once per rule on the
premise that one placed sibling renders the whole rule; pprint_clauses in fact gates every clause
individually, so a rule with one located finding and one pathless one showed the first and lost the second
from the console entirely while the JSON carried its reason. And it could not see a block whose query failed
at the document root, because it required unresolved to be absent and MissingBlockValue is the one of
four block-report constructors that sets it — so a rule querying a top-level property against a
CloudFormation template exited 19 saying nothing, taking the author's own << >> message with it.

rendered_contexts is the union of the resource clause sets, which is by construction what the per-resource
output will show, and every clause and block is asked against it. Deciding per clause without that set
reintroduces a different fault, because the evaluator emits two reports for one comparison it resolved one
way and could not resolve another — the context set is what separates the unresolved twin from a genuinely
unreported sibling. Alongside: the author's << >> message now reaches the section (.or_else over the two
message slots was dead in its second half), NoValueForEmptyCheck no longer prints the negation of what
happened, and a rule name matched by prefix no longer renders one rule's block under another's findings.

Two further gaps in that section, both found by reviewing it rather than by a test. It keyed "was this shown
under a resource?" on the trimmed context string, so two clauses of one rule whose text is identical were
indistinguishable and the placed one made the pathless one count as shown; a rule asserting Properties.Tags exists both inside a resource block and at the document root reported one of the two and printed no section at
all. What separates that from the legitimate twin the context set exists to suppress took establishing: both are
two ClauseReport nodes, adjacent siblings, with byte-identical context and no recorded source span, and what
differs is the check carried, UnResolved beside InResolved for the twin against UnResolved beside
UnResolved for the collision. The gate is now node identity plus that one case named for what it is, and it
suppresses a strict subset of what the old one did, so a finding the old code printed cannot be lost.

And the 320-character cap on an explanation was applied before trimming, so a message's own indentation spent
its budget. A message is written inside the clause carrying it, so every line arrives indented to that clause's
depth, which made the length an author could write depend on how deeply the rule was nested; 9 of the corpus's
233 messages exceed the cap as written and only 5 do once trimmed. It now measures the content, and an
explanation that fits once trimmed comes out whole and unmarked, because an ellipsis is a claim that content was
dropped. One consequence is visible in four registry outputs: a short message no longer prints the whitespace
around it, so the evaluator's sentence joins it a line earlier rather than after a blank one. No exit code moves
and nothing is lost, but the separation between an author's message and the machine's reason was incidental and
is now absent.

Both console reporters also aggregated findings into a std::collections::HashMap and iterated it to write
the report. That hasher is seeded per process, so ten runs of one binary against a three-resource template
produced five distinct outputs.

Parser boundaries

Items[4294967296] wrapped to Items[0] and compared the wrong element. Non-finite float literals (1e400)
and literals that underflow to zero were accepted. Duplicate rule names and repeated parameter names were
accepted silently. A map key that reads as an integer was treated as an index rather than a key.

cfn-guard test reported success for suites it never ran

Three defects in the same family as the rest of this branch, found by following up why an expectation in the
AWS rule registry had never been checked.

A test suite could be run against the wrong rules file, and its failure reported as success. Test files
under a tests/ directory are paired with rules files by prefix, taking the first match in filename-sort
order, so a shorter stem claims a longer stem's tests. With s3.guard and s3_encryption.guard in one
directory, tests/s3_encryption_tests.yml went to s3.guard, which does not define the rule its expectations
name, and s3_encryption.guard was reported as having no tests associated. A suite that expects PASS where the
template violates the rule exits 7 under test -r/-t and exited 0 under test -d over the same two
files. Paired on the longest matching prefix now. The looseness is deliberate and is kept: requiring a _tests
suffix would stop <prefix>.yml and <prefix>-1.json pairing, and a character-class boundary cannot separate
the readings because _ is both the conventional separator and a word character. min_by_key over the
reversed length rather than max_by_key, so a tie still goes to the first file in sort order as it did before;
ties are reachable, since x.guard and x.ruleset share a prefix.

A test file matching no rules file was discarded without a word. That is what a rename leaves behind.
s3_bucket.guard beside tests/s3_tests.yml, left over from when the rules file was s3.guard: test -d
printed only that the rules file had no tests associated, which reads as benign, and exited 0. Renaming the
test file and changing nothing else gives exit 7. Each unmatched file is now named on stderr with its path.

An unchecked expectation was invisible to every structured reporter. An expectation naming a rule the file
does not define is not checked; the plaintext reporter says so on stderr and json, yaml and junit said
nothing. A test file whose every expectation names a nonexistent rule produced
<testsuites tests="0" failures="0" errors="0"> and exited 0, so a pipeline gating on that report had nothing
to gate on. Reported now as a skip in a field of its own, unchecked_expectations, not folded into
skipped_rules -- those are opposite directions of one mismatch, rules with no expectation against
expectations with no rule, and a consumer reading one array could not tell which had happened. A skip and not a
failure, because escalating it changes the exit code of a shipped CLI for every user with a typo in a test
file, and that is a maintainer's call; making the fact visible is not. The field is omitted when empty, so
every report over a suite with nothing unchecked is byte for byte what it was.

Run against the AWS rule registry at 7f7340c, unmodified, the two diagnostics name three test files that
have never run and eleven expectation names that answer to no rule. Two of those three files are the only test
file their rules file has, so s3_bucket_default_lock_enabled and cloudfront_accesslogs_enabled have no test
coverage at all: one filename drops a trailing d, the other begins with a space. Both suites pass once
wired up. Those are fixed in that repository rather than here.

Merging alongside #719

Both PRs merge into origin/main cleanly on their own. Only the combination conflicts, and no single
resolution direction is correct for it — of the five conflicted paths, three want this branch's side, one
wants #719's, and two want a union. One of them is dangerous to get wrong and the damage is silent.

Measured by trial merge into origin/main at 3e265bb, with rerere disabled so a recorded resolution
could not report a false clean, and judged by the merge output text rather than by the unmerged-path list.

path	this branch's side	#719's side	resolve to
guard/src/rules/parser.rs	the 87-line extract_message grammar	the original unbounded find_substring(">>")	this branch
guard/src/rules/path_value.rs	288 lines of QueryResolver and its two select functions	deleted	#719
guard/src/rules/mod.rs	the add_merged_capture_key trait method	deleted	this branch, plus #719's own deletion
guard/src/commands/reporters/validate/common.rs	an import list including FileReport and Messages	the same list without them	this branch (its superset)
guard/src/commands/reporters/test/structured.rs	has_unchecked_expectations and number_of_unchecked_expectations	build_junit_test_cases with an elided lifetime	both

parser.rs is the one that matters. #719 branched before any of the three attempts at extract_message
and its Apply rustfmt commit reformatted the signature, which is what makes it conflict rather than merge.
Its side is the original unbounded search. Resolving that hunk in #719's favour reinstates the defect where one
forgotten >> consumes every following rule as message text and the run reports PASS at exit 0 — the headline
finding of this PR, and silent when it recurs.

path_value.rs is the mirror image: this branch carries that engine only because it does not delete it, and
deleting it is #719's entire purpose. It does not touch the duplicate-key detection added here, which sits
earlier in the file, well outside the conflict region.

The order matters and only one order is dangerous. If #719 merges first, this branch rebases onto it and
the resolution happens here, so no trap reaches anyone. If this branch merges first, the conflict lands in
#719 and the parser.rs hunk is the one that must not be resolved the obvious way.

This table is re-derived rather than carried forward: it named two conflicted paths when this branch was 27
commits shorter, and both the count and the resolution directions have changed since. Re-derive it again if
either branch moves.

A rule could not be composed out of other rules

rule MAIN { H_A H_B } failed whenever a rule it referenced was not applicable. Two helper rules each
guarded by a when on their own resource type, and a template carrying one of those types but not the other,
gave H_A PASS, H_B SKIP and MAIN FAIL at exit 19 — reporting a violation on a template that violates
nothing. A template carrying neither type failed as well.

eval_guard_named_clause claimed every assertion SKIP as FAIL, in both polarities, which also made the arm
below it unreachable for assertions. eval_parameterized_rule_call carried the identical line for r(...),
with a comment claiming to mirror the first; both are fixed together and one test asserts both, so a change to
one cannot pass on the other's coverage.

This is why decomposing a ruleset over disjoint resource types has not been done: neither workaround holds. A
conjunction of references fails whenever any type is absent. A disjunction returns PASS when any one helper
passes, so a template with a violating IAM Role beside a clean DynamoDB table passes a rule that should fail
it — a false negative in a compliance rule. The AWS rule registry's existing helper idiom composes with OR
only because its helpers are alternative paths to one conclusion, and that does not transfer.

A negated reference is included: rule deny when Resources.*.Type exists { not inner } failed on a template
with one S3 bucket and no KMS key. It now reports the rule did not apply because it referenced rule [inner], which did not apply to this input. A negated reference used as a when gate is deliberately unchanged,
because a gate that closes silently disables the rule it guards; the registry's one negated reference is a
gate, and that decision is what protects it.

Exit codes said the tool broke when the rules file was wrong

Two paths reported an authoring mistake as exit 255, the internal-failure code, where 5 means rules-file
error:

• parse-tree on a rules file it cannot parse — validate said 5 for the same file, so two subcommands
  disagreed about whose fault it was.
• validate on a rules file referencing a variable no let declares. Forgetting a let is a common mistake,
  and the caller was told the tool had failed. The undeclared name is now reported with Could not resolve variable by name <name> across scopes, so it can be acted on.

The reason a 255 survived here is a test that passed for the wrong reason. guard/tests/parse_tree.rs had two
cases sharing one expected output that is an I/O error. One points at dne.guard, absent on purpose. The
other pointed at validate/rules-dir/malformed-rule.guard while the file lives at
validate/malformed-rule.guard — one directory up. So it failed at File::open, matched the shared I/O
string, and passed green. parse-tree's parse-error exit code therefore had no coverage at all. The fixture,
never having been run, also turned out not to contain a syntax error: it is an undeclared-variable file, which
is how the second defect above came to light. The repository had no genuinely malformed rules fixture; there
is one now, the cases assert what their names claim, and the exit codes are documented, which they were not.

A test expectation could name a rule that does not exist

cfn-guard test printed No rule named X is in this file, so its expectation was not checked and exited
0. An expectation naming a rule that is not there asserts nothing, so a rule renamed without its test file
being updated leaves a test that silently stops testing while the suite stays green.

It is now exit 1 — TEST_ERROR_STATUS_CODE, not TEST_FAILURE_STATUS_CODE, following the line this
repository already draws at guard/tests/test_command.rs: "an expectation that could not be evaluated is a
different answer from an expectation that was not met." All four output formats report it; junit uses its
<error> element, which consumers treat as red exactly as they treat failures.

The question that decided whether a blanket failure is right is whether an expectation for a rule in a
sibling rules file can legitimately be checked in directory mode. It cannot: OrderedTestDirectory::from
reduces the candidate rules files with min_by_key, which yields exactly one claimant, so a test file is
never evaluated against a second rules file. A directory whose test files are named to cover several rules
files at once will now go red, and it was never checking what it appeared to.

This has a consequence outside this repository, measured rather than assumed.
aws-cloudformation/aws-guard-rules-registry has 30 such expectations in
rules/aws/aws_cloudformation/tests/cfn_no_explicit_resource_names_tests.yml, across 11 distinct names, in a
suite that reports clean. Its .github/workflows/{ci,build,publish}.yml each install cfn-guard unpinned
from main and run cfn-guard test -d ./rules/, so when this change is released that repository's CI and
its publish pipeline go red until those expectations are dealt with.
aws-guard-rules-registry#286
removes them and is green under every cfn-guard version, released or not, so landing it first leaves no red
window in either repository.

A regular expression's own diagnostic was built and thrown away

Both failure returns in parse_regex_inner were nom::Err::Error, which alt treats as recoverable, so the
fancy_regex message was constructed and discarded and the next value production's complaint was reported
instead. == /a(/ exited 5 saying expecting either a property access "engine.core" or value like "string",
with no mention of the parenthesis. It now says Could not parse regular expression: Parsing error at position 2: Opening parenthesis without closing parenthesis. The file's own convention two functions above already
required Failure here and cross-references parse_range; two sites followed it and these did not. Two
existing tests pinned the Error variant by assert_eq!, and moving those assertions is the point of the
change rather than collateral damage.

Two changes that alter what a rules file means

Both are deliberate, both are measured, and neither is a bug fix you can take without noticing it.

A string or regex literal ending in a backslash. parse_string_inner and parse_regex_inner each decided
whether a delimiter was escaped by testing whether the text in front of it ended with \, which cannot tell
\ from \\. When it guessed wrong the scanner resumed past the closing delimiter, so the next quote or
slash anywhere in the file became the terminator — an apostrophe in a comment was enough — and every clause
and rule in between was absorbed into a string value, unevaluated and unreported, at exit 0.

Fixing it means a backslash consumes the character after it, whichever character that is. That is the rule
every language with a backslash escape uses, and it makes a backslash's meaning independent of its position.
The consequences: in a string "a\\b" is now one backslash rather than two, and in a regex \\ closes
itself so a following / ends the literal. There is no reading in which \\/ both terminates in /^x\\/
and does not terminate in [A-Za-z0-9\\/+=] — the swallow and the fixture are one construct, so one of them
has to move.

Measured blast radius: \\ inside a string literal, a backslash immediately before a quote, and \\/
inside a regex each occur zero times across all 313 .guard files and 435 KB in this repository and the
AWS rule registry. The two exceptions are the two copies of advanced_regex_negative_lookbehind_rule.guard
here, whose \\/ is rewritten to \/ — the spelling that always meant what the file intended. A rules
file in the wild using \\/ in a regex now fails loudly at parse rather than misreading silently.

Mixed range bounds, r[0,20.5], are now accepted — and that commit is separable. It is not a defect fix
and can be dropped without touching anything else. docs/CLAUSES.md promises that integer and float
"compare against each other as numbers. That includes range membership", but its examples are r[5.0, 100.0]
and r[5, 100] — homogeneous bounds with a mixed value. Mixed bounds are not promised, and RangeType
holds one type, so refusing them was a representable-shape limitation rather than a defect. The case for
accepting them is that Size in r[1,2] holds for a Size of 1.5 while Size in r[0,20.5] did not parse at
all, so the gate was narrower than the thing it gated; the integer bound widens to float and is refused if
widening would move it. Accepting more input invalidates no existing file. But it changes the accepted grammar
of a public DSL, which is a maintainer's call, so it is its own commit.

Verification

cargo test --release --no-fail-fast: 1489 pass, 0 fail, 2 ignored across 16 targets, from 1379 at the
branch point. cargo clippy --release --all-targets -- -D warnings and cargo fmt --all -- --check both
clean.

The whole blast radius across both repositories, and every item in it is intended:

• Parse trees. Every .guard file parsed with the branch point's binary and this one, compared on exit
  code and on the sha of the full tree. 210/210 in the AWS rule registry identical. 105 of 108 here identical;
  the three that differ are the deliberately-unparsable fixtures going 255 to 5, with byte-identical tree
  output — the exit-code fix, not a parse change.
• The registry's own suite. All 44 directories with a tests/ subdirectory, run as
  cfn-guard test --dir at clean upstream, before and after. One changed: rules/aws/aws_cloudformation,
  0 to 1, stdout unchanged. That is the ghost-expectation fix firing on the 30 dead expectations described
  above, and nothing else in the registry moves.
• Snapshots, not the working tree. Both sweeps read git archive snapshots at explicit refs rather than a
  live checkout, after two measurements in this work turned out to be reading a tree that had moved
  underneath them.
• A 440-cell oracle matrix over operator x operand-shape x polarity x position, whose expectations come from
  the language semantics rather than from the binary.
• A 1,626-pair sweep for the rule-reference change specifically — 193 registry cfn-guard test pairs plus
  1,433 validate pairs — byte-identical, with sensitivity proved rather than assumed by showing a fixture in
  the same shape does move across the two binaries.

A caveat on all of it, worth more than the numbers. These are regression instruments. Every one of them
reported zero changes for most of the parser fixes here — correctly, because no fixture contains a forgotten
>>, or a string ending in a backslash, or a transposed range. A differential answers "did any of these
inputs change answer", not "is there an input that gets a wrong answer". Every defect in this branch was
found by reading what a function commits to and then constructing the input that violates it, and each fix
carries a test built the same way.

Two flavours of empty selection answered differently

rule H { Resources.*[ Type == 'AWS::DynamoDB::Table' ].Properties.TableName not exists }

document	before	after
{} — no Resources key at all	PASS	SKIP
{"Resources":{}}	PASS	SKIP
one S3 bucket, no DynamoDB table	SKIP	SKIP
one clean DynamoDB table	PASS	PASS
one violating DynamoDB table	FAIL	FAIL

Rows 1 and 2 are the same logical situation as row 3 — an empty selection with not exists over it — and
answered PASS where row 3 answered SKIP. A rule about DynamoDB tables reported compliance for a document
containing nothing, and correctly reported itself inapplicable for a document containing one unrelated resource.
Across sixteen operator spellings twelve disagreed, and the disagreement was not uniformly permissive: for
exists, !empty, == and in the empty-document flavour answered FAIL where the other answered SKIP. The
highest-stakes row was a when condition, where a not exists gate opened on one flavour and closed on the
other — changing whether the guarded body ran at all rather than only what was reported.

Two fixes were implemented and rejected before this one, both caught by measurement. Treating any
all-unresolved result as an empty selection turns Resources.*.Properties.BucketEncryption exists from FAIL into
SKIP — "this bucket has no encryption configured" is the entire point of a compliance rule, so that reading gives
up the tool's main job. Keying off "an expansion with query parts after it" produced every target row correctly
and then failed four existing tests that encode requirements rather than the defect: an IAM role carrying no
Tags must fail Properties.Tags[*].Value == /.../, and some Tags[*].Key == /PROD/ over Tags: [] must fail.
Those four tests are unchanged.

The predicate that satisfies all of it: an empty expansion yields an empty selection only when a filter is
still pending at or after the point the collection came up empty. A filter is how the language says "the subset
of things this rule is about", so a filter that has not yet run over an empty input means the rule has no
subjects. A bare wildcard is a projection over a property of a subject already chosen, so an empty projection is
an answer about that subject. Searching from the current index rather than from zero is what keeps
Resources.*[ Type == 'X' ].Properties.Tags[*].Key == /PROD/ failing on an empty tag list — that filter has
already run, the resource was selected, and its empty Tags belongs to it.

This routes the empty-collection case into the SKIP path that already exists for filters, which
eval.rs's own comment describes as happening "when the query has filters in them". QueryPart::Index is
excluded deliberately: Items[0] names one element rather than enumerating a set.

Blast radius: all 44 directories of the AWS rule registry run as cfn-guard test --dir, and every one of its
210 rules files run against three empty-ish documents — 630 verdict pairs, zero changes. Every registry rule
is gated by when %var !empty, so none takes the path this changes; the defect was reachable by hand-written
ungated rules.

Known limitations

Reviewing this branch found more than reading it did

Later passes over this branch's own commits turned up four things that no amount of reading the diff would
have reached, because each only exists when a documented command is actually run. They are worth listing
separately because three of them are in the tooling around the change rather than in the change.

cargo test --all aborted on this branch. Fifteen of the 34 tests that parse at or near
MAX_NESTING_DEPTH exceeded libtest's 2 MB thread stack in the default debug profile — SIGABRT, cargo exit
101 — while --release passed. pr.yml runs cargo test --verbose, which is debug, on ubuntu, macos and
windows, so this was red on three platforms. The deep parses now run on an explicitly sized thread, so they
no longer depend on the harness's default. What hid it is worth naming: MAX_NESTING_DEPTH's doc comment
justified the bound with "about 2.3x to spare", measured on an optimized build and written without saying so.
Unoptimized, the same ladder tops out below the bound. Every stack figure in that comment now states its
profile, and the argument for 128 rests on the corpus instead, because a corpus fact survives a change of
profile.

cfn-guard test exited 0 on a rules file it could not parse, in json, yaml and junit, while
printing errors="1" in the same run. A CI job gating on the exit code saw success on a broken ruleset,
which is the worst failure direction available for a policy tool. single-line-summary already exited 1 on
the same bytes, so the two format families disagreed. All four now route through the same
TestResult::get_exit_code() rather than assigning codes by hand at each site.

The four output formats disagreed about content and about codes in three more places, found by
enumerating the grid rather than by fixing the reported case: a stale-rule-name diagnostic was dropped in
single-line-summary when the same case also carried an unparseable expectation string, and the
directory path answered 7 where three formats and the single-file path answered 1 for identical input. There
are now tests asserting that every format agrees over one rules file and over a directory — the invariant,
not an instance. Both of the earlier fixes here had been to an instance, and one of them created the same
defect pointing the other way.

The Windows registry CI step decided pass/fail from stdout. if (<command>) in PowerShell tests the
command's output for truthiness, not its exit code, and that command prints thousands of lines — so the step
logged "have passed" for runs that had exited non-zero, and would have failed a successful run that printed
nothing. Its bash twin uses if <command>; then, which does test exit status, so the two legs of one check
were checking different things. Both now test $LASTEXITCODE. The same expression appeared in the
parse-tree loop, where it was correct only by luck.

Four doc comments also stated numbers that could not be reproduced, which matters here because a false
comment in this area misdirected several of these investigations. The corpus depth maximum was 6 and is 7,
reached by two files rather than four; the loader's two corpus figures were each high by one, and one of them
named "the deepest CloudFormation template" in a corpus that contains no template files. A ratio was still
derived from a threshold that had already been corrected. And a call-graph component count was removed rather
than corrected: the figure depends on how a parser passed to a higher-order combinator is attributed, four
defensible models give four different answers, and the sentence named none — so no reader could check it. Two
user-facing refusal messages that quoted corpus statistics now make their point qualitatively, because a
message asserting a maximum over a repository whose release cadence this one does not control is wrong again
on someone else's schedule.

Three questions are left open on purpose, each measured and recorded rather than settled by accident: a key
filter after [*] versus .*; what a filter applied to an already-indexed value (Rules[0][ ... ]) should
mean; and ::MODULE stripping in a type-block name. Each needs a decision about what the language means, and
guessing one is worse than leaving it visible.