fix(coreapi): loosen display-only Repo read enums for forward-compat · Entire

fix(coreapi): loosen display-only Repo read enums for forward-compat

a2e41fb→main· Soph·1w ago·8 files·+158 added/-714 removed

`repo list` / repo-get decode the `Repo` schema through the ogen client, whose generated response decoder calls a strict `Validate()` on every enum field. `Repo.state`, `Repo.visibility`, and `Repo.objectFormat` were modeled as enums, so the day the control plane adds a new value (a new lifecycle state, a new visibility) the entire list/get request would fail to decode with `validate: invalid value: ...` — even though the CLI only displays these fields and never branches on them.

Add a second `spec/normalize.go` transform (`loosenReadModelEnums`, allowlist `readModelEnumFields`) that drops the `enum` constraint from those response read-model fields before ogen runs. ogen then emits plain strings with no `Validate()`, so unknown values decode and print verbatim. Only response read models are loosened; request-body enums (e.g. `SetRepoVisibilityInputBody`) stay strict so we still reject a bad value we are about to send.

Regenerated the client and locked the behavior in with `TestListProjectRepos_UnknownEnumValuesPassThrough`. Tracked in UPSTREAM.md.

Sessions

01KWY2E2S86JVHXWF8EMVRES5RView transcript

Debug CLI Core and Cell API EndpointsClaude Code·Opus 4.8·8 steps

Changes

8

Symptom: read-model string fields the CLI only displays (`Repo.state`, `Repo.visibility`, `Repo.objectFormat`) are declared as `enum`. ogen turns each into a named type with a strict `Validate()` that the response decoder calls unconditionally, so the day the server adds a new value (a new repo lifecycle state, say) the whole `repo list` / repo-get request fails to decode — even though the client never branches on the value.

Fix upstream: model client-display fields that may grow new values as plain strings (drop `enum`), or have ogen treat them as open enums. Enums the client sends (request bodies like `SetRepoVisibilityInputBody`) should stay strict.

Workaround: `spec/normalize.go` (`loosenReadModelEnums`, allowlist `readModelEnumFields`) deletes the `enum` constraint from those response read-model fields, so ogen emits plain strings with no `Validate()` and unknown values pass through for display. Only response read models are loosened; request-body enums stay strict. Locked in by `TestListProjectRepos_UnknownEnumValuesPassThrough` in `client_test.go`.