Publish a repository for anyone to read

A published repository can be browsed by someone with no account, no client and no clone — its tree, file contents, blame, changes, diffs, comparisons, conflicts, lanes, tags, policies, proposals and activity. This is the surface behind a public repository link.

Publishing therefore discloses more than your files. Proposal records — the change one carries, its author, its target lane, its state — are anonymously readable too. The prose layer the application puts around a proposal, its description and its comments, is not served here, but the record and the author identifier are. Decide to publish with that in mind.

Two gates, and you need both

A repository is readable anonymously only when both hold:

1. The deployment carries a publication binding naming it — organization, repository, default ref, the refs that may be read, and a description.

2. Its live visibility is Public.

Either one missing answers a plain not-found. The second gate is defence in depth: making a published repository private drops it off the anonymous surface immediately, with no configuration edit and no window in which it is still being served.

The practical consequence, and the question people ask first: setting a repository to public does not by itself put it on the anonymous browse surface. Publication is a separate, deliberate decision.

Only the refs you published

A request for a ref outside the published set answers not-found rather than quietly redirecting to the default. A redirect would confirm which lane names exist, and this surface has no caller to authorise, so it cannot afford to answer that.

For the same reason, an unbound repository and a private one answer identically. The surface never distinguishes does not exist from not published.

Protected content is never rendered here

A policy-protected path is never shown in plaintext on this surface under any operation. It appears as metadata carrying its protection marker, or it is left out of the shapes that carry content at all. The edge holds no recipient key and does not decrypt — there is nobody to decrypt for.

Big things degrade rather than fail

Responses are bounded. A very large diff, blame, conflict or file does not error and does not silently hand you half a file: it comes back marked as truncated, trimmed largest-first, and never as partial bytes. If a response cannot be honestly reduced, it fails rather than serving something misleading.

What it is not

• Not a clone endpoint. It serves derived views, not objects. Clone over the normal sync path — including when you are exporting.

• Not authenticated. A credential presented here is ignored, not honoured. Private data is read through the signed-in surface.

• Not writable. Every operation is a read.

Responses are cached briefly and shared between everyone, which is another reason nothing caller-specific can ever appear in one.