[tbantle22]

Re-vendors specs/hosted-v1.yaml from ld main (0f750e88e6a) and regenerates. dolthub-v2.yaml is unchanged there, so v2 is untouched.

Most of the month's spec work — operations, backups, database versions, reboot, Dolt credentials — was already vendored by fc96066 and 362a1c9. Three things remain.

1. One new endpoint

Method	Path	Operation
POST	/api/v1/deployments/{owner}/{deployment}/change-primary	changePrimary

plus ChangePrimaryRequest. Deployment-tagged, 202 with an OperationRef, so no new page or nav entry — in the overview it takes a table row and a paragraph in long-running work. The paragraph covers the two things the operation alone won't tell you: it needs admin, Hosted rejects a current_primary_id that is no longer the primary (so a request built from a stale read can't undo a newer change), and Hosted picks the replacement, so succeeded means the switch happened but not what it landed on — the instance list is what says which instance is primary now.

2. Instances now carry their own state

DeploymentInstance gains a required state, backed by a new DeploymentInstanceState enum. models.md goes 47 → 49 schemas.

This falsifies a standing claim in the overview. Instance changes were documented as the case with no per-instance state to poll — observed only by an instance gaining a host, or by its leaving the list. Both are now followed by state, which is what the spec's own add and remove descriptions were rewritten to say.

3. A 403 hardening pass

403 Forbidden added to fourteen existing operations across all four tag pages. user.md, operation.md, and pull-request.md change by nothing else.

Verification

• npm run build:dolt succeeds; check-content-frontmatter passes
• Generators idempotent over the committed tree
• #changePrimary, #model-changeprimaryrequest, #model-deploymentinstancestate resolve in the built HTML, and the overview link points at the first

One spec bug this surfaces — not fixable here

changePrimary's description tells callers to poll the operation "until it reports SUCCEEDED, FAILED, or EXPIRED", and that "when it reports SUCCEEDED, the primary change has completed". OperationStatus never takes those values — it is queued, running, succeeded, failed. EXPIRED and FAILED are OperationErrorCode values, carried on error.code once status is already failed.

So a client written against that sentence polls for a status that never arrives. Every other operation-returning endpoint describes this correctly, and so does the Operation model.

The fix belongs in ld's v1.yaml, since this repo only vendors it — I have the change prepared and will open it on request.

🤖 Generated with Claude Code