Bug: policy loading fails for policies with no `adherence.assessment-plans`

[trevor-vaughan]

Bug: policy loading fails for policies with no adherence.assessment-plans

Pre-existing bug in internal/policy, found while reviewing PR #711 (it predates the PR).

parsePolicyLayer rejects any Gemara Policy that has zero adherence.assessment-plans. Every parse path goes through it, so a policy with a title and a control catalog but no plans can't be loaded at all.

What breaks

• scan / doctor (they build the graph): hard error, "... has no adherence.assessment-plans".
• list / get (metadata display, PR feat: surface Gemara bundle metadata in list and get commands Body: #711): silent. EVALUATOR/CONTROLS show - and no summary prints, even though the title and control count parsed fine. The error is logged and swallowed.
• get itself never builds the graph, so it's otherwise unaffected.

The check

// internal/policy/resolver.go:254 (base f61e943) / :390 (PR head 4cad011d)
if len(gemaraPolicy.Adherence.AssessmentPlans) == 0 {
    return policyLayerResult{}, fmt.Errorf(
        "policy %s: Gemara Policy has no adherence.assessment-plans", policyID)
}

Reached by both the graph path (resolveBundleGraph / resolveSplitGraph) and the metadata path (extractBundleMetadata :153 / extractSplitMetadata :194, added by PR #711).

Reproduce

Cache a policy whose Policy layer has a title and a ControlCatalog with controls but no adherence.assessment-plans. Then complyctl scan fails; complyctl list shows -.

Open question for maintainers

Is a plan-less Policy valid in the Gemara model?

• Plans mandatory → working as intended; just give the metadata path a clearer message than a silent -.
• Plans optional → parsePolicyLayer is too strict. Return the parsed title/evaluator/controls with AssessmentCount = 0, and move the "must have plans" check to the code that actually needs plans (assessment generation), not the shared parser.

References

Base f61e943: resolver.go:254-256. PR head 4cad011d: resolver.go:390-393. From the PR #711 review (finding #5).

---

Related issues: #715, #716