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

[timgl]

Daily OpenAPI schema refresh — 2026-05-31

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

Spec diff size

• src/generated/api.d.ts: +983 / −24 lines (17,571 → 18,530)
• openapi-filter.yaml: unchanged
• Managed operationId set: unchanged (71 operations, identical before/after)

The diff is purely field-level schema evolution on operations we already
manage — no operation was added to or removed from the generated surface.
Notable upstream additions flowing in through the shared query/response schemas
that insights & endpoints reference:

• New query node types: AccountsQuery, RevenueAnalyticsMRRQuery,
  RevenueAnalyticsOverviewItem, CalendarHeatmapFilter, ErrorTrackingIssueFilter
• New experiment-metric fields: ExperimentMetricOutlierHandling,
  ExperimentRatioMetric, numerator/denominator outlier handling,
  lower/upper_bound_percentile, ignore_zeros
• DataWarehouseSyncWarning, expanded EndpointResponse / EndpointVersionResponse,
  assorted query-status warnings fields

New operationIds added to the filter

None. Every new operationId in the live spec that is missing from
openapi-filter.yaml falls into one of two buckets:

1. Belongs to an existing managed family but not referenced by client code —
   e.g. PUT _update variants (cohorts_update, experiments_update,
   event_definitions_update, experiment_holdouts_update, …) and per-resource
   sub-actions (*_activity_retrieve, *_sharing_*, *_bulk_update_tags_create).
   Every resource client uses PATCH (partial_update) for updates, never PUT,
   plus POST/GET/DELETE. Adding the PUT or sub-action operations would only bloat
   the generated types with surface no client touches, so they are intentionally
   left out (consistent with the existing filter).

2. Brand-new resource families, not currently managed — the spec exposes the
   full PostHog API surface (annotations, alerts, surveys, batch exports, hog
   functions/flows, error-tracking rules, warehouse queries, LLM analytics, etc.).
   Adopting any of these is a deliberate, human-reviewed decision (it requires a
   new client.ts + pipeline.ts + tests + registration via the add-resource
   skill), not something this unattended daily refresh should do on its own.
   Per docs/resources.md, the flagged next candidates remain annotations and
   alerts. Ping if you'd like one wired up.

Resources touched

None of the hand-written resource clients, pipelines, or Zod schemas required
changes — pnpm typecheck passes clean and the existing schemas still align with
the regenerated types.

Unresolved drift

• No removed operationIds. The managed operation set is byte-for-byte
  identical to the previous generation, so nothing managed disappeared upstream.
• Flaky test (not drift): src/pull/run.test.ts > writes files and calls tagOnServer on a non-dry run timed out once under full-suite load (503 ms vs
  the 500 ms test timeout). It passes cleanly in isolation (307 ms) and is
  unrelated to schema content — a pre-existing timing sensitivity, not a
  regression from this refresh.

Verification

• pnpm install --frozen-lockfile ✅
• pnpm codegen ✅
• pnpm typecheck ✅
• pnpm test — 290/291 pass; the one failure is the timing flake above (passes in isolation)

---

TaskRun: 6e47b4a6-ca1a-4a2f-b7ad-2dd36c221ef0