feat: generate actions, and verify every kind's bindings against the SDK

[ShocOne]

Phase 5.7 of the phase 5 plan. Base is main.

Actions are the third most-used block kind in the reference provider — 43 of them against 4 list resources — and the simplest, because an action has nothing to reconcile. verify reports 21/21 with no orphans, up from 17, and the provider now satisfies ProviderWithActions.

Three files per action against a resource's five: no construct.go, because an action sends its arguments as call parameters rather than a request body, and no state.go, because it writes nothing back. The pilot gains thousandeyes_disable_endpoint_agent, backed by the pinned SDK's real DisableEndpointAgent.

Generating a real action showed two of my earlier rules were wrong

• Expands() returned true for an action. The reasoning was "an action sends values to the API" — it does, but as call arguments, and the emitter generates no construct function for one, so there is no body for an expand to build into. Now resource-only.
• The flatten requirement was universal — "every kind reads". An action does not: InvokeResponse has no field to carry a result, so a flatten would convert into somewhere that does not exist. Requiring one made the first action unrepresentable. There is now a Flattens() predicate, and a flatten on an action attribute is refused rather than ignored.

Three silent-drop bugs

1. LoadDir merged Resources and DataSources and not Actions. Every action in a split blueprint vanished with no error whatsoever. Found only because the first emit wrote nothing.

2. internal/sdkbind walked bp.Resources and nothing else. Data source bindings have been unverified since 5.2 and list facets since 5.6 — three quarters of the bindings in a blueprint were unchecked, while the command printed a reassuring count and even said "1 resource binding set(s)" while doing it. The accessor check is extracted, verifyOperation takes a key rather than a resource, and data sources, list facets and actions each get a verifier. A list facet's element type is checked too, since identityFrom and displayNameFrom name fields on one element and a typo there is a compile error in someone else's provider. 67 bindings now verified. I confirmed it bites by renaming the action's SDK method:

   disable_endpoint_agent: binding.invoke.method: endpoint_agents.EndpointAgents has no
   method DisableEndpointAgentTypo (did you mean: DisableEndpointAgent?)
   

3. interop export said nothing about actions, so an entire block kind vanished from the exported document in silence — the one failure mode the note mechanism exists to prevent. Reported once for the kind rather than per action, since the loss is that the format has no such concept.

There was also a fourth, smaller one: accessorChain required the receiver to be literally "r", which is why the widened checks first reported every non-resource accessor as "cannot be verified" rather than verifying it. The receiver name is whatever the generated method uses (d, l, a), so it is skipped rather than checked; the field chain from client onwards is the part that resolves, and that is where a wrong accessor is actually caught.

Support addition

client.ForAction, because action.ConfigureRequest is its own type — the resource helper cannot serve it, and the three request types share no interface to write one generic helper against. The doc comment says so rather than leaving the duplication looking accidental.

Verification

• go test ./... clean; golangci-lint run 0 issues; gofumpt clean (via go run, as CI does).
• verify 21/21 no orphans; pilot builds and vets; bindings 67/67 against the pinned SDK; probe -mode verify 39/39; merge idempotent.
• interfaces.go in the pilot asserts ProviderWithActions alongside the other two, so "the generated registries are what make this work" stays a build failure if it stops being true.
• New internal/blueprint/action_test.go: the Expands/Flattens correction stated directly, a refused flatten, six action refusals, and the alias-namespace collision across kinds.

Note on the interruption

The full suite reported internal/sdkbind failing after 607s partway through. That turned out to be a corrupted local Go build cache, not the action — sdkbind passes in ~50s once cleared. Worth saying because it briefly looked like the action's binding was at fault, and it was not.

5.4b is still tracked

Not forgotten, and I want to correct something I said about it: I framed it as needing a fully curated second pilot resource, which over-stated the cost. 5.3b already established a cheaper pattern — ingest a resource from the committed spec, graft the pilot provider block on, emit, and compile it in a scratch directory. That gives genuine end-to-end coverage without committing a second pilot resource. So 5.4b is more tractable than I implied; the remaining work is the IR constraint fields, ingest extraction, render mapping, and regexp.MustCompile vars for RegexMatches.

🤖 Generated with Claude Code