Phase 5 for Non-Deployable Projects

Phase 5 is the deployment phase of the GAIA lifecycle. Before the multi-shape model, Phase 5 always meant /gaia-deploy + /gaia-post-deploy. That assumption breaks for plugins, libraries, CLIs, mobile apps, container images, and static sites -- none of which have a deployable URL to push to. This tutorial covers the routing extension that lets /gaia-help recommend the right command based on YOUR project's shape, not the historical default.

What Phase 5 used to mean

The original Phase 5 contract: you have a staging URL and a production URL, you run /gaia-deploy --env staging, then /gaia-post-deploy --env staging to verify, then promote to production via the promotion chain. That's still the correct flow when you HAVE deployable environments. The problem is GAIA assumed everyone did.

Under the multi-shape model, Phase 5 reads two config-side signals:

environments[*].kind -- per-env, the closed enum deployable | branch-only | distribution-only.
distribution: -- presence vs absence of the top-level publish block.

The detector at scripts/lib/config-shape-detect.sh reads both and emits one of four tokens; /gaia-help routes Phase 5 from the token.

The 5-case decision table

Case	environments[*].kind	distribution:	Detector token	`/gaia-help` Phase 5 suggestion
(i)	all `deployable`	absent	`deploy-only`	`/gaia-deploy` (baseline)
(ii)	all `deployable`	present	`deploy-and-publish`	BOTH `/gaia-deploy` AND `/gaia-publish` (rare hybrid)
(iii)	all `branch-only`	present	`publish-primary`	`/gaia-publish` only
(iv)	all `distribution-only`	present	`publish-primary`	`/gaia-publish` only
(v)	mixed (>=1 deployable + >=1 non-deployable)	present	`deploy-and-publish`	BOTH (with per-env clarification)

Case (i) is the historical baseline -- byte-identical to the pre-multi-shape behavior. Cases (iii) and (iv) are publish-primary; /gaia-deploy is intentionally absent from the suggestions (the command would HALT on the kind gate). Cases (ii) and (v) are mixed-shape; both commands are surfaced and the body distinguishes which envs are reachable via which.

Walkthrough

For a Claude plugin (case iii):

$ /gaia-help

[Phase 5: Deployment]
This project is publish-primary -- no environment is marked deployable.

Recommended command:
  /gaia-publish              # ships to claude-marketplace via your release_workflow

Not recommended:
  /gaia-deploy               # HALTs on kind: branch-only

For a microservice with staging + production deployable envs AND a library exported on the side (case v -- mixed shape):

$ /gaia-help

[Phase 5: Deployment]
Mixed shape -- one or more deployable envs AND a distribution: block.

Recommended commands:
  /gaia-deploy --env staging       # service-side rollout
  /gaia-deploy --env production    # service-side rollout
  /gaia-publish                    # publishes the library export per distribution.channel

Publish-readiness mode

/gaia-deploy-checklist also reads the detector token. For publish-primary projects, the checklist swaps to publish-readiness mode: the gate items are publish-oriented (manifest version matches, release workflow exists, credentials env vars set, adapter sub-fields satisfy per-channel schema) instead of the deploy-oriented gate items (rollback plan, smoke endpoints, etc.). The switch is automatic -- you do NOT need to pass a flag.

You'll know it worked when

/gaia-help on a plugin / library / CLI / mobile-app / container-image / static-site project recommends /gaia-publish and does NOT recommend /gaia-deploy.
/gaia-help on a historical all-deployable project recommends /gaia-deploy unchanged -- byte-identical to the pre-cascade baseline.
/gaia-deploy-checklist on a publish-primary project renders publish-oriented gate items instead of deploy-oriented ones.
/gaia-deploy --env <branch-only-or-distribution-only> HALTs with use /gaia-publish instead.