[antoinetoussaint-byte]

What

codefly generate runnable-bindings loads the workspace with common.LoadWorkspaceWithPinnedModules instead of common.LoadWorkspace — the same thing a run, a render and generate fixture-composition already do. ~6 hand-written lines.

Why

--check is the only drift check the runnable-bindings group has, and it could never run where drift is caught. On real obin-ai/platform-obin main (694ac3f4), from a fresh checkout, codefly generate runnable-bindings --env blue --check refused before reading anything:

module resolves to a pinned artifact … pinned modules are pulled by the CLI, not loadable as a local checkout

With this change it reaches regeneration and refuses with the composition's real contradiction instead:

--call-endpoint "saas/auth-gateway/hop": service saas/auth-gateway declares no endpoint hop (it declares [grpc rest workload])

— the saas pin has no hop endpoint yet, the same fact the owner saw as the render's hop/ENDPOINT … the producer declares no such endpoint refusal.

Provenance

This is the first commit of the stale-generated-output work, diagnosed and proven by the agent who owned it before the one-agent-per-repo reorganisation (handoff in the coordinator's scratchpad). It is opened here on its own, rebased onto current main, because it is a fix at the owner, independently proven, and small. The larger branch it came from (#1202) has since had unrelated publish and stop work piled onto it and is conflicting; this slice should not wait on that.

Evidence

go test ./cmd/generate/ -run 'Runnable|Decline' green; golangci-lint run ./cmd/generate/... clean.

Not in this PR

The generic refuse-stale-generated-output gate (doctor comparing committed generated groups against a fresh generation by value, not by key name; today checkRunnableBindingsGroup is green-about-a-name and skipped for --module documents). Design is written in the handoff; it follows v0.1.220.

🤖 Generated with Claude Code

Docs (same PR, from the review)

docs/commands.md: the --check flag row now says writes no binding output and that, like every command reading composed modules, it materializes a pinned module first (cache, overlay, receipt, .gitignore); generate runnable-bindings and generate fixture-composition are added to "Which commands materialize". docs/runnable.md: "a failed preparation writes nothing" narrowed the same way. The --check flag help in cmd/generate/runnable_bindings.go corrected, docs/cli-reference.md regenerated.

Relation to #1209

The code change here (1fac1a7c) is the first commit of #1209's stack. This PR stays open as the slice's docs carrier and merges after #1209: rebased onto it, the duplicate code commit drops and what remains is the docs and flag-help correction above, which #1209 does not carry (its head is the reviewed SHA and is not edited).

[antoinetoussaint-byte]

Superseded by #1209, which carries this slice (1fac1a7c is the stack's first commit) and now also its two remaining docs items (docs/runnable.md preserves-the-existing-binding, docs/commands.md materialising-commands list), per the docs closure. Nothing here is lost.