fix(module-ci): create a module's intent, or the first one of a kind 404s

[anujhydrabadi]

A modules repo could not carry a module whose intent the Control Plane had never seen. The upload failed outright:

Error: upload failed with status 404: {"message":"Intent gcs not found","code":"404"}

Nothing else creates an intent — raptor create resource-type-mapping rejects one it does not know — so there was no way through from CI at all. A repo bootstrapped against one Control Plane could not be published to another.

Hit for real: vibe-modules carries gcs, firestore, service_account and artifact_registry; all four failed preview registration this way, and a direct raptor create iac-module failed identically.

The fix

raptor already has the flag. This passes --auto-create on the two steps that upload:

Step	Call
Preview modules (pull request)	raptor create iac-module -f "$dir" $AUTO_CREATE --feature-branch --git-ref …
Publish modules (push)	raptor create iac-module -f "$dir" $AUTO_CREATE

It is deliberately not passed to the --dry-run validation, which never touches the intent — confirmed by dry-runs passing while the intent was absent.

Why it is behind an input

--auto-create does two things, and the second is shared state:

Create the intent if it doesn't exist, and update an existing intent's metadata from intentDetails in facets.yaml.

An intent is shared by every flavor under it. Two flavors that disagree will fight, and the last module published wins. That is not hypothetical — it is already true in vibe-modules:

intent	flavor	intentDetails.displayName
cloud_account	gcp_provider	Cloud Account
cloud_account	gcp_org_provider	GCP Org Cloud Account

So auto-create-intents (default true) can be set to false to freeze intent metadata, at the cost of failing on any new intent. The README gains an Intents section explaining the shared-object model and saying plainly that keeping intentDetails identical across a flavor set is the right answer, and a difference is a repo bug.

Default is true because without it the action simply cannot bootstrap a fresh Control Plane, which is the bug being fixed.

Verification

• Against a live Control Plane: with the flag, gcs/standard/1.0 uploaded and registered the gcs intent. Re-running without the flag then succeeded, proving the intent persisted.
• Toggle logic checked for true, false, and unset (unset defaults to on).
• The repo's own gate run locally: action.yml parses, 12 inputs, 0 shellcheck findings across all embedded scripts.

Not in scope

Two further gaps in the same area, both needing work outside this action:

1. Output types are never created. A module referencing an output type the Control Plane lacks fails the same way. A working round-trip exists (raptor module get-output-type -o yaml → raptor create output-type -f), but the repo carries no output-type files — ModulesRepoBootstrapService.exportModules and raptor module sync-repo both export modules only, and the generated workflow filters on modules/**. Needs control-plane work first.
2. Deletions never reach the Control Plane. A module directory removed from the repo maps to no facets.yaml, so the publish loop skips it and the module stays published.

🤖 Generated with Claude Code