chore(codegen): daily schema refresh (2026-05-21)

[timgl]

Summary

Daily OpenAPI schema refresh — regenerated src/generated/api.d.ts from https://us.posthog.com/api/schema/?format=json filtered through openapi-filter.yaml.

Spec diff size

• src/generated/api.d.ts: +91 / -2 lines (1 file)
• openapi-filter.yaml: unchanged

All edits are schema-level enrichment on existing components — no new paths, no new operationIds for managed resources:

• InsightVizNode: new optional resultCustomizations field (per-breakdown color customizations)
• ExperimentSavedMetric + PatchedExperimentSavedMetric: added query (typed unknown) and field-level descriptions
• Project + PatchedProject: added test_account_filters (typed unknown) with extended docstring
• TeamCustomerAnalyticsConfig: previously Record<string, never>, now has typed fields (activity_event, signup_pageview_event, signup_event, subscription_event, payment_event, account_group_type_index)
• TrendsFilter: docstrings only — aggregationAxisFormat, aggregationAxisPostfix, aggregationAxisPrefix, decimalPlaces
• experiments_list: new prompt_name query parameter

New operationIds added to the filter

None. None of the operationIds new to the live spec correspond to core CRUD for managed resource families. The drift detector flagged a large list of operationIds that exist in the live spec but are absent from openapi-filter.yaml — review confirms they were not previously filtered in either (e.g. *_activity_retrieve, *_bulk_update_tags_create, sharing/collaborators, environment-prefixed duplicates, internal admin endpoints). For managed families, only PUT update endpoints (cohorts_update, experiments_update, experiment_holdouts_update, experiment_saved_metrics_update, event_schemas_update, event_schemas_partial_update, schema_property_groups_update) are new — but the clients all use PATCH (partial_update), so adding them would be dead weight.

Resources touched

None. No client client.ts, pipeline.ts, or test edits — the schema additions are field-only and don't break any existing Zod schemas. pnpm typecheck and pnpm test (291 tests across 35 files) both pass cleanly.

Unresolved drift

None. No operationIds disappeared from the live spec that we were previously managing — all 31 paths we filter in continue to exist.

TaskRun

Task-Id: 34405871-5e31-4616-8bf8-002fe6083aea

[timgl]

Re: failing semgrep check

Semgrep is flagging two pre-existing GitHub Actions shell-injection findings in .github/workflows/release.yml:

1. yaml.github-actions.security.run-shell-injection.run-shell-injection — ${{ inputs.dist-tag }} interpolated into the Resolve dist-tag run: block (lines 38–47).
2. dotgithub-repo..semgrep.rules.github-actions-shell-injection — ${{ steps.tag.outputs.tag }} interpolated into the npm publish run: (line 50).

Neither finding is caused by this PR. The release workflow was last edited in #11 and is unmodified on this branch (git diff main...HEAD --name-only → src/generated/api.d.ts only). Semgrep doesn't run on main pushes — it's a PR-only workflow — so this is the first PR after the rule became blocking, and it inherits the latent finding.

Per my hard-limits, I won't modify .github/workflows/** to clear a CI finding unrelated to this PR's diff. Suggested human follow-up: a separate PR refactoring release.yml to write the dynamic values to env: (or $GITHUB_ENV) and reference them via $DIST_TAG instead of ${{ ... }} inside run: blocks. The schema-refresh diff itself is just enrichment to src/generated/api.d.ts and is otherwise green (typecheck + 291 tests passing).