feat(attestation-type): custom attestation type summaries

[FayeSGW]

Closes #1097

What

Adds --summary-json to kosli create attestation-type, and shows the summary in kosli get attestation-type table output.

The backend accepts an optional summary list at the top level of the create/update endpoint's data_json body — ordered {name, expression} entries whose expressions are jq, evaluated against attestation data. Because it lives in that JSON blob rather than the uploaded schema file, there was no user-facing way to set it.

kosli create attestation-type security-scan \
  --schema scan-schema.json \
  --jq '.critical_count == 0' \
  --summary-json '[{"name":"Critical","expression":".critical_count"},{"name":"Scanner","expression":".scanner.name"}]'

                   Evaluator:
                                 Content Type:  jq
                                 Rules:
                                      .critical_count == 0
                   Summary:
                                 Critical:  .critical_count
                                 Scanner:   .scanner.name

Why this flag shape

The issue floated three options. This takes the JSON-passthrough one, which maps 1:1 to the API.

The repeatable --summary "Name=.expr" alternative was rejected because jq expressions contain both = and ,. Note the existing key=value idiom in this repo (--annotate, --set, --link) uses cobra's StringToStringVar, which would have been wrong here twice over: it CSV-splits values, so an expression like [.a, .b] | map(select(.x == 1)) | length gets mangled, and it returns an unordered map where summary is an ordered list.

Notes for review

Validation. Each entry must have a non-empty name and expression, reported by 1-based index. Without that, a typo such as {"name":"X","expr":".y"} unmarshals silently into an empty expression and ships a broken summary to the API, surfacing far from its cause. DisallowUnknownFields would catch that more directly, but would hard-reject payloads if the backend later adds an optional field to the entry shape — which the issue explicitly reserves the right to do.

omitempty is safe. Verified against a local server that the endpoint replaces rather than merges: creating a type with a summary and re-running without the flag produces a version with summary: null. So omitting the flag clears the summary, and [] vs "omitted" being indistinguishable on the wire loses no expressiveness. Existing invocations produce a byte-identical request.

Second commit came from code review — the summary was write-only in the default view, visible only via --output json. Combined with full-replace semantics, a later create without the flag silently cleared it with nothing in the table to show it had gone.

Testing

Full suite green: 2205 tests, 51 skipped. make lint clean.

Beyond the goldens, I queried the local server after the suite to confirm the data actually lands rather than just being accepted: the comma/== expression stores byte-identical, and summary coexists with both a jq evaluator and an uploaded type_schema.

Types created without a summary have a null summary in the response, which fails the []interface{} assertion and prints nothing — existing golden files pass untouched.

Known gap

No test pins CreateAttestationTypePayload to the OpenAPI contract — it is not in the openapiContract_test.go drift-guard registry, so a server-side rename would leave the suite green while the summary is silently dropped. The new get-with-summary golden partly mitigates this by round-tripping the field through a real server. Happy to add the registry entry here or as a follow-up.

🤖 Generated with Claude Code

[claude]

Claude finished @FayeSGW's task in 1m 31s —— View job

---

PR Review: custom attestation type summaries

• Static analysis (go build, go vet, go mod tidy)
• Review the diff & changed files
• Post review feedback

Static checks: go build ./... ✅ · go vet ./... ✅ · go mod tidy → go.mod/go.sum clean ✅

---

This is a well-executed, well-tested change. The flag-shape reasoning in the PR body is sound: StringToStringVar would indeed have mangled jq expressions on both , and the unordered-map problem, so raw JSON passthrough is the right call. Nice work.

What's good

• parseSummaryJSON error handling is precise. Distinguishing *json.SyntaxError (malformed JSON) from type-mismatch/validation errors gives genuinely useful messages, and 1-based, position-tracking indices are a thoughtful touch. The test matrix ([null], [1,2,3], ["a"], [] trailing, whitespace-only fields, second-entry-is-bad) is comprehensive and pins each branch.
• omitempty semantics verified against a real server and documented — the note that omitted vs [] is indistinguishable and lossless is exactly the analysis this needs. Confirmed existing invocations stay byte-identical.
• Second commit (showing the summary in the default table) was the right catch — a write-only field under full-replace semantics is a silent-data-loss trap. Good that review surfaced it.
• New table code mirrors the existing evaluator block's map[string]interface{} idiom, so it reads as part of the file rather than bolted on.

Minor points (non-blocking)

1. <nil> rendering on malformed server data (getAttestationType.go:202) — already raised in the prior inline review. Worth noting it's consistent with the neighbouring evaluator code (evaluator["content_type"] has the same behaviour), so leaving it is defensible for consistency; create-side validation guarantees both fields non-empty for anything this CLI writes. Fine to leave or guard — your call.

2. The OpenAPI drift-guard gap you flagged is a one-liner — openapiContract_test.go:67 takes a single registry entry: {name: "create attestation-type", payload: CreateAttestationTypePayload{}, component: "<ComponentName>"}. Since the whole risk is a server-side rename silently dropping summary, and the fix is this small, I'd lean toward adding it in this PR rather than as a follow-up — the round-trip golden only mitigates it while the local server stays in sync. Only blocker is knowing the exact OpenAPI component name.

Testing

Golden files, unit tests for parseSummaryJSON, and the round-trip get-with-summary golden together give solid coverage. I could not run make test_integration here (requires the local Kosli server + API tokens), but the suite is reported green (2205 passed, 51 skipped) and the goldens look correct.

Overall: clean, focused, mergeable. 👍
· 1097-add-cat-summaries

[sami-alajrami]

I assume expression validation to be a valid JQ is still happening on the API?