Module structured_path 

Structured-query rule family: {json,yaml,toml}_path_{equals,matches}.

Six rule kinds share a single implementation that varies along two axes:

• Format — Json, Yaml, or Toml. The file is parsed into a serde_json::Value tree regardless (YAML and TOML values coerce through serde), so the JSONPath engine only has to reason about one tree shape.
• Op — Equals(value) for exact equality or Matches(regex) for regex on string values.

All rule kinds require:

• paths — which files to scan.
• path — a JSONPath expression (RFC 9535) pointing at the values to check.
• Either equals (arbitrary YAML value) or matches (regex string), according to the rule kind.

Semantics

JSONPath can return multiple matches ($.deps[*].version). Every match must satisfy the op; any single mismatch produces a violation at that match’s location. If the query returns zero matches, that’s one “path not found” violation — the option the user is enforcing doesn’t exist.

The optional if_present: true flag flips the zero-match case: under it, zero matches are silently OK, and only actual matches that fail the op produce violations. Useful for predicates that only apply when a field is present — e.g. “every uses: in a GitHub Actions workflow must be pinned to a commit SHA” (a workflow with only run: steps has no uses: at all and shouldn’t be flagged).

Unparseable files (bad JSON / YAML / TOML) produce one violation per file. An unparseable file is a documentation problem, not the structured rule’s concern — but better to surface it than silently skip.

Structs

StructuredPathRule

Enums

Format

Which YAML-flavoured parser to use on the target file.

Op

Comparison op — keeps the rule builders thin.

Functions

json_path_equals_build

json_path_matches_build

toml_path_equals_build

toml_path_matches_build

yaml_path_equals_build

yaml_path_matches_build