Answer with the repo the server described, plus what we worked out
Commit

repo view --json replaced the wire Repo with a hand-built row, so four
of the five fields the spec guarantees on a repo stopped being emitted.
capabilities was the costly one: .capabilities.canPush became null at
exit 0, and null is falsy, so a guard asking "may I push here?" silently
flipped to no. provider, foreign, objectFormat and six others went
the same way, and owningProjectId came back as a project NAME — a
mutable value where a ULID used to be.
This repo already had the shape for it. mergeSynthesizedField renders a
wire object and adds what the command computed, never overriding the
server; repo create --json has always answered that way. The round
trip moves to wireObject so a view can merge several keys rather than
one string, and the native view answers with the record plus repo,
private, status, placements and project — the keys a GitHub
upstream also carries, so the common core parses the same for either
forge, while the rest is present exactly when there is a record behind
it. Nothing is dropped, so most of the documented break stops existing.
That also un-breaks the e2e: repoJSON decodes create AND view, and the
retag to repo had silently zeroed created.Path for every create.
Both verbs carry path again.
Two more the same read turned up. A failed provision never reaches the
placement-shaped check — such a repo has no placement — so
waitForRepoClonable read a zero value, saw nothing wrong, and burned its
full deadline instead of naming the failure; it reads .state now. And
the provision reason printed under every native view, because the field
outlives the failure it describes: a repo reading ready carried "max
retries exhausted" beneath it, with a test pinning that. It is scoped to
a failed repo, and where no table exists it leads on stdout, there being
nothing to keep clean.
The two sentences explaining why a table was missing are gone with it. A failure says it failed; anything else says no cluster holds the repo yet, without guessing on the reader's behalf why.
Co-Authored-By: Claude Opus 5 (1M context) noreply@anthropic.com Entire-Checkpoint: 01M3M8MNKJ0RMVQZBS2GJ69GBR