[antoinetoussaint-byte]

What breaks

codefly deploy gitops render <module> --env blue on obin-ai/platform-obin stops, from the postgres agent, with

postgres deployment requires a typed Kubernetes Secret reference for
CODEFLY__SERVICE_SECRET_CONFIGURATION__MODEL__STORE__POSTGRES__POSTGRES_USER

for every module, because the snapshot deploys model/store and the agent requires a typed reference for each of its four primitives.

Why

The restricted render promotes into a typed Secret reference every secret key the service's own configuration declares (promotableConfiguration), and that configuration is read from the service's own configurations/<profile>/ — in a composition, the module cache the CLI materialized and never writes to. obin-ai/module-model-gateway (and module-directory, per directory#25) ship no *.secret.env: by their decision, the run that composes the store generates it. A local run does (cmd/run/generated_secrets.go, before loading configuration); a hosted render has no analogue — codefly deploy secrets mints, in the cell's store, only the keys a render already emitted, and nothing in the render path read service-secrets.generate. So nothing declared the four keys, the render promoted nothing, and the agent refused. Modules that render (robin, records, …) do so only because they commit a key-names file in local/.

The fix (a fix at the owner, not a hack)

withEnvironmentDeclaredSecrets (pkg/orchestration/builder_deploy.go), on the restricted path, adds to a service's configuration every key a service generator naming the service declares that the configuration does not — as a secret with no value — and the existing promotion turns it into the same secretKeyRef a declared key gets. The key name reaches the manifest and its ExternalSecret; deploy secrets plans it as generate; no module tree is written or widened. A key the service declares keeps its declaration; a generator naming other services, or the workspace, adds nothing. The Generate field comment and docs/commands.md say so.

Reused: the environment's existing service-secrets.generate declaration (the same one cmd/run and deploy secrets read), promotableConfiguration and core's ConfigurationAsEnvironmentVariables for the key spelling, resources.Match for name matching. Deliberately not built: writing a generated file into the module cache (a composition never writes there), a second key-declaration source in the agent, or a committed throwaway secret file per module (refused by module-directory#25 and module-model-gateway 87b43cb).

Evidence

• TestEnvironmentDeclaredSecretsPromoteToReferencesWhenTheServiceShipsNoFile does not compile on main (the seam does not exist) and passes here; go test ./pkg/orchestration/ ./pkg/environments/ ./pkg/deploysecrets/ green; golangci-lint 0 issues.
• On platform-obin (blue), v0.1.234 and main 91ed65c refuse model/store; supplying the same four key names through the module tree instead clears the postgres deployment (and then fails on the changed module tree's digest), which isolates the missing declaration as the cause.
• Not yet verified: a complete render with this build. Every run since platform-obin moved robin to dc892ada stops earlier, in the build phase, on robin/chat:0.1.36 is already published from other code (robin/chat's go.mod/go.sum moved without its version; the published label matches the 6030951b tree byte for byte) — a module-robin release matter, independent of this seam.

🤖 Generated with Claude Code