fcode-release

Factorial Code — Release

Promotes an app's code from its dev-… workspace to its prod-… workspace using CLI remotes. Input: the two workspace slugs. This updates prod's current (unversioned) code only — publishing a workspace version and moving the stable alias is the separate platform release (model in fcode-core-concepts, journey in fcode-ama): don't run settings:versions:* or move stable in this flow unless explicitly asked.

Gate every release with fcode-code-validation — see the procedure.

Gotchas

• Prod write access is required. Only operators and the app's Factorial team admins can push to a prod-… workspace; the admin's grant lands when a release is requested and rides in the access token — if prod access is refused right after requesting, run fcode login and retry. Who promotes and why: fcode-ama.
• A ✅ validation is required before pushing. Run fcode-code-validation on the dev workspace first; while the report has Blockers, refuse to push. Only an explicit user override ("push anyway despite the Blockers") proceeds — record that the gate was overridden.
• Always confirm before the final fcode push. Summarize what will change in the prod workspace and wait for an explicit yes — prod code serves live installations.
• Never --force. If fcode pull or fcode push reports a divergence between local and prod, stop, show what diverged, and ask the user how to proceed (fcode-cli).
• The fcode pull after remote:add is mandatory — it picks up the prod workspace's current metadata. Skipping it pushes stale settings over prod's.
• Both slugs are encoded tokens (dev-… / prod-…), not the app's UUID (see fcode-cli). Verify the prefixes: cloning target and push target must not be swapped.
• A failing fcode clone usually means a mistyped token or missing access (see fcode-ama) — don't retry blindly.
• If dev-xxx/ already exists locally, don't reuse it silently — ask whether to release from a fresh clone (recommended) or the existing copy, and fcode pull it first.

Procedure

1. Collect the two slugs. One dev-… (source) and one prod-… (target). Wrong prefix or any ambiguity about which app they belong to: stop and ask.

2. Validation gate. Ensure a current ✅ APP_VALIDATION_REPORT.md exists for the dev workspace — run fcode-code-validation when it is missing or stale. On ❌, list the Blockers and refuse; proceed only on an explicit user override.

3. Clone and wire the prod remote:

   fcode clone --skipSkillsSetup dev-xxx
   cd dev-xxx
   fcode remote:add prod-xxx
   fcode pull          # mandatory: picks up prod's current metadata
   fcode add           # registers resources prod doesn't have yet
   

   On a divergence reported by fcode pull: stop and ask (see Gotchas).

4. Confirm. Run fcode status, summarize for the user what the push will change in prod-xxx (processes, modules, variables, settings), and wait for explicit confirmation.

5. Push:

   fcode push
   

   On a divergence: stop and ask — never --force on your own.

6. Report the outcome, reminding the user that the platform release (publish a version, move stable) is a separate step (fcode-ama).