chore(drift): triage the dedicated pools and the conversion catalogue

[stephrobert]

Summary

Five operations appeared in instance/v2alpha1 and nobody had decided about them, so drift:check exited 2 on every branch. #784 has been carrying them since 16 September.

Declined, in two entries rather than one, because they fail for different reasons — and both survive a promotion of v2alpha1 to a stable instance/v2, which the blanket alpha reason below them would not.

The four Dedicated Pool operations are the provider's fleet

The SDK says it plainly: "List Dedicated Pools for an organization", "Instance types available in a Dedicated Pool and their technical details".

A dedicated pool is physical capacity reserved for somebody, and this emulator has none. Answering would publish headroom a client could plan a migration onto — the refusal GetServerTypesAvailability already carries, and what docs/limits.md states as policy.

ListServerCompatibleTypes is a missing measurement, not a missing fleet

"List the Instance types that a given instance could be converted to" is a compatibility matrix: local volumes, architecture, generation. corpus/ holds no recording of it across its 619 exchanges, and the catalogue this pack serves is a small fixed table rather than Scaleway's.

An invented answer would have a client plan a resize the real API refuses. Same verdict as the pools, different reason, so a different entry.

Measured, not assumed

occurrences of either subject in corpus/	0
GetDedicatedPool appeared upstream	2026-09-15
ListServerCompatibleTypes appeared upstream	2026-09-16

One thing worth knowing for the next drift

The issue's body still reads "The refreshed baseline is in the pull request tagged chore/upstream-drift" and still lists four operations. Neither is a defect in the scan: the workflow posts updates as comments rather than editing the body, and the latest comment (01:47 this morning) carries all five correctly. The body is simply frozen at the day the issue was opened.

The line about a pull request is now inaccurate, though, since #761 stopped the workflow from creating one — repository policy forbids Actions from opening pull requests. Worth a follow-up so the body points at the compare link instead; not folded in here, to keep this change to the triage.

Type of change

• Chore / tooling

Checklist

Always

• mise run check passes, and mise run prepush in full — which is what was red before this
• No new external Go dependency
• internal/core still knows no provider
• Nothing in the diff could be written identically for another provider
• mise run testplan was run. It asks for conformance:leg -- scw-cli on a pack change; it was not played, deliberately: this change mounts no route and alters no handler. It adds five strings to Declined() and the documents drift:update regenerated from them. No response any client can observe differs before and after, so the leg would re-prove the previous commit.

When a model wrote a substantive part of this

• An Assisted-by: trailer names the tool and the model version
• N/A on mise run conformance, for the reason stated just above
• Every name in the diff comes from scaleway-sdk-go's api/instance/v2alpha1/instance_sdk.go, read directly, along with the doc comments quoted in the reasons

When a route is added or changed

N/A — no route added or changed. mise run drift:update was run and coverage/ is committed with the change, along with the README.md and docs/routes.md it regenerated.

When behaviour a client can observe changes

N/A — none does. A declined operation answered 501 before this change and answers 501 after; what changes is that the refusal now carries a reason.

When .github/workflows/ is touched

N/A.

When a machine runtime is involved

N/A.

Related issues

Triages what #784 reports.

🤖 Generated with Claude Code