/wbDeploy — Live Demo ()
What /wbDeploy would actually do on wb-labs right now. The live state of working tree, host credentials, and the absence/presence of deployable apps below is real.
1. Live target
| Field | Live value |
|---|---|
| Working tree | Heavily dirty — many uncommitted docs files in frontEnd/wbc-ui/core2/apps/wb-flow/flow.wbc-ui.com/ |
| Existing apps in workspace | Not obvious in current core2/ layout. Apps may live elsewhere (frontEnd/wbc-ui/) per memory's user_profile note |
| Host credentials configured | Unknown — would surface during --prod checks |
| Existing deploy infrastructure | Not visibly active in this session; /wbDeploy would surface "no host config detected" if run |
| Memory rules | feedback_no_git.md (no git ops); feedback_model_selection.md (declare model); release/deploy rules implicit in the docs convention |
The "dirty working tree" reality is the most relevant constraint. Any production deploy attempt right now would warn loudly because the docs sync isn't yet committed.
2. What each input form would resolve to today
| Input | Live resolution |
|---|---|
/wbDeploy apps/wbc-ui.com | Halt or warn — apps/ may not exist in current layout. If found, would warn about dirty tree. |
/wbDeploy --prod (no target) | Halt — target required. |
/wbDeploy production | Halt — environment-as-target refused; needs -P flag. |
/wbDeploy frontEnd/wbc-ui/ (per memory user profile mentioning the @wbc-ui2 ecosystem) | Permitted if an app is identified there. Otherwise halts with "no app config detected." |
/wbDeploy "the main site" | Halt — free-text. |
/wbDeploy apps/wbc-ui.com --dry-run | Safest first invocation in this state. Would surface tree-dirty warning + any build issues. |
3. Per-flag behavior, applied live
| Flag combination | Live result |
|---|---|
| (no flag) | Default to preview env. Single confirmation. Tree-dirty warning. |
--target="staging" | One confirmation. Tree-dirty warning. |
--prod | Two confirmations. Strong "run dry-run first" suggestion. Refuses if HEAD isn't on main. |
--dry-run | No upload. Build only. Useful to validate config without risk. |
--prod --dry-run | Recommended pre-prod combination. |
4. Pipelines
/wbDeploy apps/wbc-ui.com --prod> /wbDeploy apps/wbc-ui.com --prod💠 Pipeline The "tree-dirty" warning on first attempt
💠 Pipeline The --dry-run first
The recommended path in this state:
💠 Pipeline The "no apps here" honesty
💠 Pipeline A clean rollback (hypothetical)
If apps were configured and live, a rollback is a re-deploy of a previous artifact:
5. What would refuse today
| Trigger | Live response |
|---|---|
/wbDeploy (no target) | Halt. |
/wbDeploy production (env as target) | Halt — env must be a flag. |
/wbDeploy "the main site" | Halt — free-text. |
/wbDeploy apps/wbc-ui.com --prod (right now, dirty tree) | Warn, asks confirmation. |
/wbDeploy apps/wbc-ui.com --prod (HEAD not on main) | Refuse — production must come from main. |
/wbDeploy --target="<unknown-env>" | Halt. |
/wbDeploy <multi-app> with one build failure | Atomic refuse — no uploads. |
/wbDeploy "rollback please" (free-text) | Refuse with rollback-shape suggestion (re-deploy with previous artifact). |
/wbDeploy with no host credentials configured | Halt with setup instructions. |
The pattern: /wbDeploy is the irreversible op with multi-gate safety. Refuses fuzzy targets, refuses partial deploys, refuses rollback-as-undo (rollback is just another deploy). In this exact workspace today, the right next step before any deploy attempt is to commit the docs sync via /wbGit -r -e -p — most deploy concerns trace back to "your tree doesn't match what you think you're shipping."