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

[timgl]

Summary

Daily regeneration of src/generated/api.d.ts from the live PostHog OpenAPI
schema (https://us.posthog.com/api/schema/?format=json), filtered by
openapi-filter.yaml.

Spec diff size

src/generated/api.d.ts: +113 / −11 lines (one file changed).
openapi-filter.yaml: unchanged.

Changes are purely additive:

• New field descriptions on TrendsFilter (aggregationAxisFormat,
  aggregationAxisPostfix, aggregationAxisPrefix) and on
  ExperimentSavedMetric / PatchedExperimentSavedMetric
  (name, description, query).
• New optional fields surfaced on existing schemas:
  • resultCustomizations on a chart filter component.
  • query on ExperimentSavedMetric and PatchedExperimentSavedMetric
    (already covered by the resource's Zod schema as record(string, unknown)).
  • test_account_filters on Team and the patched team payload.
  • usedLazyPrecompute on the query-response schema.
  • TeamCustomerAnalyticsConfig expanded from Record<string, never>
    to a concrete shape (activity_event, signup_*, subscription_event,
    payment_event, account_group_type_index).
• A handful of kind discriminators on union members were re-described
  by openapi-typescript (ActionsNode, EventsNode,
  ExperimentDataWarehouseNode); no semantic change.

New operationIds added to the filter

None. The drift is entirely within existing schemas — no new
endpoints needed to be allowlisted to keep the managed resources
(insights, dashboards, feature_flags, environments_endpoints,
event_definitions, schema_property_groups, event_schemas,
experiment_holdouts, experiment_saved_metrics, experiments,
environments, cohorts, actions) compiling and behaving correctly.

The live spec contains many operationIds outside the filter
(annotations_*, alerts_*, surveys_*, subscriptions_*,
comments_*, tasks_*, plus a large surface of admin / debug /
auxiliary endpoints on already-managed families like
*_activity_retrieve, *_bulk_update_tags_create,
*_sharing_*, dashboards_collaborators_*, etc.). These have
intentionally never been in the allowlist — the filter only
exposes operations the resource clients in src/resources/*
actually call. Adopting any of them is a deliberate, human
decision (new resource family via the add-resource skill) and
out of scope for an automated refresh.

PUT (_update) variants exist for several PATCH-only managed
families (cohorts_update, event_definitions_update,
experiments_update, experiment_holdouts_update,
experiment_saved_metrics_update, schema_property_groups_update,
event_schemas_update, event_schemas_partial_update). The
existing clients only use partial_update (PATCH); adding the
PUT variants would expand the generated surface without any
caller, so they remain unfiltered.

Resources touched

None. All managed resources continue to typecheck and behave
identically against the new schema.

Unresolved drift

None. No previously-filtered operationIds disappeared from the
live spec.

Verification

• pnpm install --frozen-lockfile ✅
• pnpm codegen ✅ — only src/generated/api.d.ts regenerated.
• pnpm typecheck ✅
• pnpm test — all 290 schema/codegen/pipeline tests pass. One
  pre-existing flake in src/pull/run.test.ts ("writes files and
  calls tagOnServer on a non-dry run") times out under full-suite
  CPU contention at 500 ms; passes when run in isolation. Verified
  to flake on main without this PR's changes, so unrelated to
  schema drift.

TaskRun

Task 5f08433d-8a90-4204-86ba-1ea67ef0074a.

Test plan

• CI typecheck green.
• CI vitest green (or only the same pre-existing flake).
• Skim the diff in src/generated/api.d.ts for anything that
  should have triggered a resource client update.