Skip to content

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

Description

@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

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workingllm_assistedFiled or drafted with LLM assistance

    Type

    Fields

    Priority

    Medium

    Effort

    None yet

    Projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions