Say what is true of a repo the read caught too early

main

Commit

gtrrz-victor2w ago

A native repo always has exactly one primary. For a few seconds after create, though, the registry read lags the coordinates the create response already carried — the window waitForRepoClonable polls through — and in it repo view printed two things that are false of such a repo: a bare web where its name is /et/acme/web, and "Not mirrored on any cluster", which is a GitHub fact about a repo that demonstrably has a home.

The empty table now says the read was early, keyed on whether Entire holds a repo record at all: if it does, the repo has a primary and the placements are merely not visible yet; if it does not, the repo is a GitHub upstream and "not mirrored" is simply true.

The name falls back to the caller's own ref, and only when that ref is already the /et/<project>/<repo> path — the resolver has just proved it names this repo, and it is the only other place the project's NAME appears, since the record carries the project's ULID and nothing else. A ULID or bare-name ref supplies no project, and then the repo's own name is all there is. A path is never assembled from parts the server did not supply: a ref that resolves to nothing is worse than a short one.

Co-Authored-By: Claude Opus 5 (1M context) noreply@anthropic.com Entire-Checkpoint: 01M32DJST8Z67B98REY2623S0X

Checkpoints

Fix repo view CLI output and validation

Claude CodeOpus 5.[1m]
View session
Checkpoint 1