fix(module-ci): declare compatibility when publishing on merge

[anujhydrabadi]

Publish-on-merge is currently broken in every modules repo

raptor v0.1.106 added publish guards (raptor #434): an already-published version needs --backward-compatible yes, and a new contract version needs --versionupgrade. The action published with neither:

raptor publish iac-module "$REF"      # no declaration

From raptor's own guard test matrix:

target	already published	flags	result
0.2	—	none	✅ first publication
0.2	0.2	none	❌ --backward-compatible yes required
0.3	0.2	none	❌ --versionupgrade required

So the only case that still works is the first module of a brand-new type/flavor. Every ordinary merge — editing a module that already shipped — fails at publish.

This is not caused by any workflow change: the action installs raptor_version: latest, so it went live the moment v0.1.106 was released. On vibe-app, all 18 of vibe-modules' modules are PUBLISHED, so every one of them is affected.

The fix

In a repo-first flow the author has already declared, in git:

What the author did	What CI passes
Edited modules/{intent}/{flavor}/0.2 in place	--backward-compatible yes
Added a new modules/{intent}/{flavor}/0.3 directory	--versionupgrade
Added the first module of a type/flavor	nothing

The publish step reads the published versions of that intent/flavor back off the Control Plane and passes the matching flag.

Version ordering stays raptor's job. A "bump" that is not actually greater than every published version is rejected there, and must be — the action does not second-guess it. Likewise a non-README module still fails raptor's README guard, as intended.

A failed listing fails the module rather than publishing. Reading an unreadable count as "nothing is published" would send a first-publication declaration for a module that already has one.

Testing

The derivation was exercised against the live vibe-app registry:

cloudrun/cpu/1.0   -> --backward-compatible yes    (already published)
cloudrun/cpu/1.1   -> --versionupgrade             (new version, existing family)
brandnew/thing/1.0 -> (no flag, first publication)

bash -n and shellcheck --severity=warning clean.

A full merge-path test needs a real publish into a control plane; happy to run one on vibe-modules if you want it before the tag.

Why this blocks the v1 tag

Moving v1 is an auto-upgrade for every consumer. It should not advertise one into a broken publish path — this fix wants to ride the same tag as #17 and #18.

🤖 Generated with Claude Code