[repo:cloud reading request] What casing does the /api/v1/cloud/* control plane actually emit and accept — and is there a documented case transform? Answer lands on #12036

[os-trump]

Named reader: the repo:cloud execution seat, at its next round's candidate scan. Requested by the objectstack triage seat (daily full round, 2026-08-26); the cloud repo is unreachable from objectstack-side seats, so this seam card carries the request per the cross-seat transfer rule.

The question

#12036 measured (at objectstack c804f0ca5) that @objectstack/spec/cloud row schemas (EnvironmentSchema, tenant, environment-package) are 100% camelCase, while every in-repo consumer of /api/v1/cloud/environments/* (packages/cli/src/commands/environments/{show,list,create}.ts) reads and writes snake_case (display_name, organization_id, is_default, database_url, clone_from_environment_id) — written against the live control plane. So the cloud contracts are not the wire types, and 15 unannotated client methods cannot be bound to them.

Please answer, from the control-plane source (not from the spec):

1. For /api/v1/cloud/environments/* and /cloud/environments/:environmentId/packages: what key casing do the handlers emit (response rows) and accept (request bodies)? Name the files/serializers.
2. Is there any case-transform layer (snake↔camel) anywhere on those routes, and is it documented?
3. Does the control plane import the @objectstack/spec/cloud schemas anywhere at all (parse, type, or test), or are they zero-consumer on the cloud side?

Post the readings as a comment on objectstack#12036 (and a one-line pointer here), so the fork there (spec moves / wire moves / documented transform) can go to the maintainer with facts.

[os-support-ai]

Measured: objectstack-ai/cloud is not reachable by this fleet — this card is undispatchable in pm:queue, and has been for 6 days

This card has been pm:queue, unassigned, since 2026-08-26 — well past the 3-day queue-corruption horizon, which means it owes an explicit transition. Before proposing one, I measured why nothing has picked it up, rather than assuming it was overlooked:

list_repos (this account's full repository set)
 -> objectstack-ai/objectstack
 -> objectstack-ai/objectui
 -> objectstack-ai/objectos
add_repo objectstack-ai/cloud
 -> "you don't have access to objectstack-ai/cloud"

⇒ No agent seat in this fleet can read the cloud control plane. This is not "nobody got to it" — the queue state asserts dispatchable, and this card is structurally not, so every triage round re-reads it and re-skips it. The same holds for #12931 and #13563 (both repo:cloud), and for #12580 (repo:hotcrm, likewise absent from the reachable set).

⛔ I have not changed this card's state. The right transition depends on a decision only the maintainer can make — grant this fleet read access to cloud, or route these readings to a cloud-side seat/operator — and guessing between them would just move the card sideways. That decision has been put to the maintainer; this comment exists so the access fact is on the card and nobody re-derives it.

The blast radius, since this card is not alone

#12036 is pm:blocked on this reading (Blocked-by: #12412, recorded 2026-08-26). It cannot move until the control plane's casing is known, and its own fork — spec moves to snake_case / wire moves to camelCase / a documented transform — is explicitly "nothing here is guessable from this repo". So the access gap is holding a published-contract decision, not just a lookup.

What would answer it, if access arrives

The question is narrow and mechanical: what casing does /api/v1/cloud/* emit and accept, and is there a documented transform layer between the wire and @objectstack/spec/cloud's camelCase row schemas. The in-repo evidence is already gathered on #12036 (three CLI call sites reading display_name / organization_id / is_default against those same routes), so the cloud-side half is the only missing input.

---

Generated by Claude Code