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

`a2e41fb`→[main](/content/gh/entireio/cli/commits/main/index.html)·  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

- internal/coreapi

- MUPSTREAM.md+22

- Mclient_test.go+45

- Moas_json_gen.go-221

- Moas_response_decoders_gen.go-27

- Moas_schemas_gen.go+20/-288

- Moas_validators_gen.go-156

- spec

- Mcore.gen.json-13

- Mnormalize.go+71/-9

**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\`.