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

main

Commit

gtrrz-victor1w ago

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

Checkpoints

Fix repo view CLI output and validation

Claude CodeOpus 5
View session
Checkpoint 1