core: let a subject declare parts with has:

[jbpros]

Third step of #244. A subject can declare parts: named paths inside it, which its checks read by their alias.

With this input:

{
  "trail": {
    "name": "pr-491-r1",
    "compliance_status": {
      "attestations_statuses": {
        "findings": {"attestation_data": {"truncated": false}},
        "coverage-verification": {
          "attestation_id": "att-7",
          "attestation_data": {"hunks_total": 25, "hunks_acknowledged": 25}
        }
      }
    }
  }
}

a policy can say:

subjects:
  round:
    from: trail
    identified_by: name
    has:
      findings: compliance_status.attestations_statuses.findings.attestation_data
      coverage:
        from: compliance_status.attestations_statuses.coverage-verification
        identified_by: attestation_id
requirements:
  review_round:
    subject: round
    checks:
      complete: findings.truncated is false
      every_hunk_acknowledged: coverage.attestation_data.hunks_acknowledged equals coverage.attestation_data.hunks_total

• Two forms: a part is one line (a path), or from with an optional identified_by, read inside the part. Nothing uses identified_by yet. The fourth step tags inputs with it.
• The swap rule: a part's alias can be replaced by its path and every row stays the same: passed, cause and values. Only the names in expression and inputs keep the alias. The alias is expanded into the path when the policy is read, so this holds by construction.
• Where it works: in the subject's checks, its from line conditions, and the whose of a subject that narrows it. It doesn't apply where a bare word reads an item instead, in the whose and the argument of a one-line every/some.
• Clashes: an alias shadows a field. Two aliases with the same name are alias given twice. .name doesn't get around an alias.
• Narrowing and chains: a subject that narrows another keeps its parts. A chained child reads its parent's part as artifact.pr_attestation.x, and its from can start there.
• Old syntax: a part is read as $coverage.
• The report: parts in the subjects section lists every part as {"from": …, "identified_by": … or null}, kept ones included.

Calls made while building it

1. named by <part alias> is written wrong, as not supported yet. Otherwise it would silently read the subject's field with that name.
2. A part's path can't start at $params or $input: parts are paths inside the subject.
3. ergo.as_sentences leaves an old check as it was when any string in it equals one of its subject's part aliases, since turning ["cov", "x"] into cov.x would change its meaning.
4. Two places where names are imperfect, both in spec/OPEN.md. A walk that enters a list in the middle of a part's path names failed items like x.sub[1].y. And a chained subject whose from starts at a parent's part shows the full path in $min_subjects and $unique_ids. Rows are correct in both cases.

Checks

• Every check in AGENTS.md passes: 1355 tests, no uncovered lines, 1141 spec cases. spec/check_grammar.py finds 0 disagreements.
• The swap rule is tested on about 60 checks: every phrase kind, quantifiers, for lines, derived values, whose, and the old syntax's all/any/any_of/substitutes. They run against 8 groups of bad inputs, and the rows must match.
• Reports from main and from this branch, on every spec case from main and every corpus line on two inputs (1740 reports), are byte-identical. Policies without has: don't change.
• I rewrote pr-reviewer's policy.yaml with 12 parts, and the "round whose …" subjects narrowing review_round. All 106 rows of the fixture round's report are identical to the original's, apart from the order of $applies inputs, which are sorted by their shorter names. pr-reviewer's 131 Rego tests pass. One report takes 0.40 s, against 0.33 s without parts.
• The JS Wasm runtime passes. Memory is 12.7 MB and 10.9 MB, from 12.4 and 10.6 on main, so the sentence report has about 1 MB left under its 12 MB budget.

🤖 Generated with Claude Code