chore: regenerate catalog from OpenAPI spec

[github-actions]

Automated catalog update from the Kosli OpenAPI spec.

Please review the diff to verify the changes look correct before merging.

[claude]

Claude encountered an error after 4m 4s —— View job

---

Catalog diff review

• Compare action ID sets (added / removed / renamed)
• Inspect changed actions (params, schemas, deprecations)
• Grep for dangling references in src/, test/, README.md
• Sanity checks (action count, surviving $ref)
• Post summary

Bottom line: no capability was lost. Action count 118 → 121. Every one of the 118 method + path endpoints in main is still present. The 48 IDs that disappear from the diff are renames, not removals — so the usual "confirm against the live spec" caveat does not apply here. Safe to merge, with one release-note item below.

---

1. Actions added (3)

All three are new Evaluations endpoints — genuinely new method + path pairs, not renames:

id	method	path
list_evaluations	GET	/evaluations/{org}
get_evaluation	GET	/evaluations/{org}/{evaluation_id}
create_evaluation	POST	/evaluations/{org}

create_evaluation takes a JSON body (EvaluationPostInput: context.trails[] 1–100 items, policy.files Rego bundle 1–100 entries, optional params). Correctly classified as write; the two GETs land in execute_read_action.

⚠️ Worth knowing: all three carry **BETA** — the server-side evaluation feature is in beta. Requests from organizations without it enabled receive 403 Forbidden. in their description, and that text is in searchText. They will surface via search_actions for every user and 403 for most. The description does explain the 403, so an LLM should be able to report it sensibly — no change needed, just don't be surprised by 403 reports.

2. Actions removed (0)

Nothing to confirm against the live spec. I compared on method + path rather than id:

• endpoints only in main: none
• endpoints only in this PR: the 3 evaluations endpoints above

So this is not #16 (stale-branch clobber — that would show endpoints vanishing) and not #18 (upstream retirement — same signature). It's an upstream operationId naming cleanup.

All 48 renames (endpoint unchanged, ID only)

The upstream spec moved to a consistent verb_noun scheme — list_* for collections, get_* for singletons, create_or_update_* for PUT upserts, attest_* for attestations, report_*_environment for env reports, and env → environment spelled out.

endpoint	old id → new id
DELETE /environments/{org}/{env_name}/policies	detach_policy_from_env → detach_environment_policy
GET /artifacts/{org}/{flow_name}/commit_sha/{commit_sha}	get_artifact_by_commit_sha → list_artifacts_by_commit_sha
GET /artifacts/{org}/{flow_name}/{fingerprint}/audit_package	get_audit_package → download_artifact_audit_package
GET /attestations/{org}	get_attestations → list_attestations
GET /attestations/{org}/{flow_name}	get_flow_attestations → list_flow_attestations
GET /builds/{org}/statistics	build_statistics → get_build_statistics
GET /custom-attestation-types/{org}	get_custom_attestation_types → list_custom_attestation_types
GET /env-diff/{org}	environment_diff → get_environment_diff
GET /environments/{org}	list_envs → list_environments
GET /environments/{org}/{env_name}/auditlog	get_env_auditlog → get_environment_audit_log
GET /environments/{org}/{env_name}/deployments	list_env_deployments → list_environment_deployments
GET /environments/{org}/{env_name}/events	get_env_events → list_environment_events
GET /flows/{org}	get_flows → list_flows
GET /organizations/{org}/environments_notifications	get_environment_notifications → list_environment_notifications
GET /schemas/environment-policy/v1	environment_policy_schema_v1 → get_environment_policy_schema_v1
GET /schemas/flow-template/v1	flow_template_schema_v1 → get_flow_template_schema_v1
GET /search/{org}/sha/{search_value}	get_search → search_artifacts
PATCH /environments/{org}/{env_name}	update_env → update_environment
PATCH /tags/{org}/{resource_type}/{resource_id}	patch_tags → update_tags
POST /attestations/.../custom	post_custom_attestation → attest_custom
POST /attestations/.../generic	post_generic_attestation → attest_generic
POST /attestations/.../jira	post_jira_attestation → attest_jira
POST /attestations/.../junit	post_junit_attestation → attest_junit
POST /attestations/.../override	post_override_attestation → override_attestation
POST /attestations/.../pull_request	post_pull_request_attestation → attest_pull_request
POST /attestations/.../snyk	post_snyk_attestation → attest_snyk
POST /attestations/.../sonar	post_sonar_attestation → attest_sonar
POST /attestations/.../system	post_system_attestation → attest_system
POST /controls/{org}	post_control → create_control
POST /custom-attestation-types/{org}	post_custom_attestation_type → create_or_update_custom_attestation_type
POST /environments/{org}/{env_name}/policies	attach_policy_to_env → attach_environment_policy
PUT /actions/{org}/environments	create_or_update_env_action → create_or_update_environment_action
PUT /allowlists/{org}/{env_name}	allow_artifact_for_env → allow_artifact_for_environment
PUT /controls/{org}/{identifier}	put_control → update_control
PUT /environments/{org}	create_env → create_or_update_environment
PUT /environments/{org}/{env_name}/archive	archive_env → archive_environment
PUT /environments/{org}/{env_name}/join	join_physical_to_logical → join_logical_environment
PUT /environments/{org}/{env_name}/report/ECS	ecs_report → report_ecs_environment
PUT /environments/{org}/{env_name}/report/K8S	k8s_report → report_k8s_environment
PUT /environments/{org}/{env_name}/report/S3	s3_report → report_s3_environment
PUT /environments/{org}/{env_name}/report/azure-apps	azure_apps_report → report_azure_apps_environment
PUT /environments/{org}/{env_name}/report/cloud-run	cloud_run_report → report_cloud_run_environment
PUT /environments/{org}/{env_name}/report/docker	docker_report → report_docker_environment
PUT /environments/{org}/{env_name}/report/lambda	lambda_report → report_lambda_environment
PUT /environments/{org}/{env_name}/report/server	server_report → report_server_environment
PUT /flows/{org}/template_file	create_flow_with_template → create_or_update_flow_with_template
PUT /organizations/{org}/environments_notifications	put_environment_notifications → create_or_update_environment_notification
PUT /policies/{org}	put_policy → create_or_update_policy
PUT /user/{org}	put_user_default_org → set_user_default_org

3. Actions changed

Across all 118 retained endpoints:

• Parameters added: none. Parameters removed: none. No param schema changed.

• Descriptions / summaries / tags: unchanged.

• Request bodies: 12 differ, but 11 of those are purely the inlined schema title tracking the renamed operation (e.g. Body_put_policy → Body_create_or_update_policy). After normalising title away, exactly one substantive change remains:

  create_artifact (POST /artifacts/{org}/{flow_name}) — template_reference_name gained a length cap:

  - {"anyOf":[{"type":"string","pattern":"^[a-zA-Z0-9\\-_]+$"},{"type":"null"}]}
  + {"anyOf":[{"type":"string","maxLength":255,"pattern":"^[a-zA-Z0-9\\-_]+$"},{"type":"null"}]}

  A validation tightening, not a behaviour change. Fine.

• Deprecations: 4 deprecated: true markers in the catalog (include_scaling ×2, require_provenance, snapshot interval). All pre-existing — no field is newly deprecated in this diff (consistent with zero description changes).

4. Dangling references

Clean. I grepped the whole repo for all 48 retired IDs as whole words: zero hits outside my own scratch files. Commit 67cfa97 handled the fallout correctly:

• src/hints.json — both keys renamed (put_policy → create_or_update_policy, create_flow_with_template → create_or_update_flow_with_template). I verified both keys resolve to real IDs in the new catalog. This one actually mattered: a stale hint key silently stops surfacing the policy/flow-template schema URLs in search_actions.
• test/fixtures/catalog-subset.json, test/client/kosli-client.test.ts, test/scripts/format-json.test.ts, test/tools/execute-action.test.ts, test/tools/search-actions.test.ts — all updated.
• README.md — no action IDs referenced, nothing to update.

5. Sanity checks

check	result
Action count	118 → 121 (+3). No suspicious drop.
Endpoints lost	0
Surviving $ref in src/	0 — generator inlined everything
Catalog parses as JSON	yes
Empty searchText / summary	none
Hint keys resolve to catalog IDs	2/2
CI	✅ passing on 67cfa97

---

Two notes for the merge

1. This is a breaking change for anything with a hard-coded action ID. The MCP server itself is fine — the LLM discovers IDs through search_actions each session, so it will pick up the new names automatically. But 48 IDs changed, and any user-side saved prompt, skill, or agent config that names e.g. put_policy directly will now get "action not found". Worth a minor bump rather than a patch when this ships, with the rename table in the release notes.

2. Nothing enforces that the test fixture's IDs match the real catalog — and it had already drifted. In main, test/fixtures/catalog-subset.json carried search_artifacts_by_sha for GET /search/{org}/sha/{search_value}, while the catalog's ID for that endpoint was get_search. The fixture ID was simply wrong and no test caught it; this PR happens to fix it by coincidence, since the upstream rename landed on search_artifacts. A small test asserting every fixture id exists in src/catalog.json (and every src/hints.json key too) would turn both classes of drift into a red build instead of a silent gap.

Fix this →
· branch chore/update-catalog