fcode-release

Original：🇺🇸 English

Translated

Promote a Factorial Code app's code from its dev workspace to its prod workspace — fcode clone the dev- workspace, remote:add the prod- workspace, pull prod's current metadata, then add and push. Use when releasing, promoting, or deploying a Factorial Code (fcode) app's dev workspace to production, or pushing a dev- workspace's code to its prod- counterpart.

2installs

Sourcefactorialco/factorial-code-skills

Added on2026-08-27

NPX Install

npx skill4agent add factorialco/factorial-code-skills fcode-release

SKILL.md Content

View Translation Comparison →

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

team: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

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.
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.

Clone and wire the prod remote:

sh

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).

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.
Push:
sh
```
fcode push
```
On a divergence: stop and ask — never
```
--force
```
on your own.
Report the outcome, reminding the user that the platform release (publish a version, move
```
stable
```
) is a separate step (
```
fcode-ama
```
).