fimo 2.4.0-staging.6 → 2.4.0-staging.8

package/assets/skills/fimo-cli/references/deploy.md

@@ -54,7 +54,7 @@ Use the publication ID returned by the failed command: run `fimo publish inspect
 A failed `fimo deploy --json` names the cause in `error.details.failure_code` and the phase in `error.details.phase`: `pull` (Git synchronization into the sandbox), `install` (dependency install), `restart` (dev-server start), or `readiness` (the final preview check); `acquire` and `sync-env` are the sandbox and environment steps before them. When the failed process produced output, the same error carries `error.details.exit_code` and a bounded, redacted `error.details.log_tail` (newest line last). Read that tail first: it is the failed process's own output, and a replacement sandbox that failed is discarded, so `fimo logs` shows the preview that is still serving rather than the attempt that failed. The top-level codes remain compatible:
 
 - `SANDBOX_SYNC_FAILED` — the revision never became ready. Fix what the tail reports (a manifest or lockfile for `install`, the Git state for `pull`), then deploy again. When `error.details.failure_code` is `install_policy_blocked`, follow the typed repair in `error.details.repair`.
-- `PREVIEW_NOT_READY` — the revision landed and the dev server never served the page. Fix what the tail reports; when there is no tail, read `fimo logs --json`.
+- `PREVIEW_NOT_READY` — the revision landed and the preview never proved ready. `error.message` names what the readiness probe last saw: a dev server that died, or the optimized dependency the public preview route was still delivering and what the dev server said about it over loopback. Fix what the tail reports; when there is no tail, act on the message before reading `fimo logs --json`, which shows a dev server that may be healthy.
 
 `--no-wait` skips only the final readiness check. Pull, install, and dev-server failures are still reported with the same fields.
 

package/assets/skills/fimo-studio/references/agents.md

@@ -1,6 +1,6 @@
 # Agents
 
-Project agents are versioned bundles from the project's repository. Studio lets project members inspect their configuration and run history, while project managers can start, stop, and resume them.
+Project agents are versioned bundles from the project's repository. Studio lets project members inspect their configuration and run history, while project managers can start, stop, resume, and delete them.
 
 ## Open an agent
 
@@ -20,6 +20,12 @@ A stopped agent shows **Paused** in the header. **Resume** makes the same trigge
 
 Only project managers see Run, Stop, and Resume. Other project members can still see schedule timing, status, settings, and run history.
 
+## Delete an agent
+
+Project managers can open **Agent actions** beside Run/Stop, choose **Delete agent**, and confirm. Deletion stops planned or running work and commits removal of the agent bundle from `main`. Recorded runs remain in history. Remove the bundle from a local checkout before deploying again, or that deployment recreates the agent.
+
+If a run cannot be stopped or `main` changes before deletion commits, the definition stays intact and the agent may remain paused. Reload and retry, or resume it if you want to keep it.
+
 ## Inspect runs
 
 Open **Runs** on an agent to see only that bundle's history. Select a run to read its status, report, captured changes, and any question or review state that needs attention.

package/assets/skills/fimo-studio/references/billing-and-credits.md

@@ -35,7 +35,7 @@ Organization billing admins on a paid plan can configure auto-refill from **Sett
 2. Choose the dollar amount to purchase when the balance crosses that threshold.
 3. Check the plan rate shown in the dialog, then save. Fimo charges the payment method on file and buys credits at that rate when the balance crosses the threshold.
 
-Turn auto-refill off from the same control. Fimo does not keep a separate copy of this configuration; the Billing page always shows the provider's current setting. Leaving a paid plan clears auto-refill, and billing admins retain the off-switch if provider cleanup is delayed.
+Turn auto-refill off from the same control. Leaving a paid plan locks automatic-spending controls while Fimo confirms the stop with the billing provider. The page states when confirmation is pending rather than presenting an old enabled setting as current.
 
 ## Upgrading Your Plan
 
@@ -67,6 +67,7 @@ Open **Billing & usage**, then **Details** beside public bandwidth. Billing admi
 - Automatic spending cannot be enabled while a plan change is scheduled. Keep your plan first; then you can immediately enable auto-refill and paid extra usage independently. Keeping the plan itself leaves both off.
 - Usage before the change remains payable. Enabling extra usage again does not make usage from the off-period billable.
 - Pro to Pay as you go or Free takes effect at the end of the current billing period. Billing shows the destination and effective date until then.
+- Review the confirmation before scheduling Pro to Pay as you go. It explains the immediate spending stop, retained benefits and charges already incurred; opening it does not change the plan.
 - Switching the scheduled destination between Free and Pay as you go keeps the same effective date and the same moment automatic spending stopped. Nothing is re-granted. Team organizations reach Free through **Cancel subscription**, not the plan dialog.
 - Choosing the current plan again before that date cancels the scheduled change and its Pay as you go successor.
 - Pay as you go requires an active payment method. Removing its only valid card returns the organization to Free immediately, and a scheduled Pay as you go with no card on file lands on Free on its effective date instead.

package/dist/cli/bundle.json

@@ -1,7 +1,7 @@
 {
   "bundled": true,
   "bundler": "esbuild",
-  "bundledAt": "2026-09-06T16:45:06.018Z",
+  "bundledAt": "2026-09-07T09:32:43.178Z",
   "cliVersion": "2.3.2",
   "external": [
     "oxc-parser",