fimo 2.10.0-staging.7 → 2.10.0-staging.9

package/assets/skills/fimo-cli/SKILL.md

@@ -135,7 +135,6 @@ These fire at specific moments in the project lifecycle. **Surface them proactiv
 - **Right after `fimo init`** → start the app locally with the project's package-manager `dev` script (`pnpm dev` / `npm run dev` / `yarn dev` / `bun dev`) in the background. This localhost server with live reload is your iteration loop — edit, show, repeat. No deploy is needed to see local changes. If the initiating request did not say what to build, ask the developer — after the first preview on the create-new path, never as a blocker before initializing.
 - **When a user-visible unit of work looks done outside first-time onboarding** → **offer** to deploy (`fimo deploy` for a hosted project preview, `fimo deploy --publish` to go live) and run it only after the developer confirms — or immediately if they ask. Never deploy ordinary edits on your own. See `references/deploy.md`.
 - **Optional, outside new-project onboarding (its first preview already warms the sandbox), if you already know a deploy is coming** → warm the sandbox early with `fimo deploy -m "chore: init" &` in the background so the one-time ~15-30s provision + dep install happens while you work and the real deploy lands warm (~4-10s). This is a perf optimization, not a requirement. See `references/deploy.md` § Warm the sandbox early in a session.
-- **Iterative code-only deploys** → once you are deploying, `fimo deploy --no-restart` skips the sandbox dev-server restart on HMR-safe edits. See `references/deploy.md` § Skipping the dev-server restart for when it's safe.
 - **You need the current preview URL but haven't changed code** (opening it, screenshotting it, handing it to another tool, the previous URL expired) → `fimo preview url`, never a no-op `fimo deploy`. See `references/preview.md`.
 - **When the user wants to try something risky / explore a redesign without touching the live site** → suggest a feature Branch: `fimo checkout -b <name>` gives an isolated Branch + DB + preview. Deploy previews there, then `fimo merge` it back and `fimo publish`. See `references/branches.md`.
 - **After completing or safely preserving the user's main work, when a confirmed Fimo platform failure still materially blocks the task after one safe recovery attempt, or a confirmed missing capability blocks completion or forces a fragile or heavily manual workaround** → use the built-in `supportReport` tool. Do not wait for the user to ask and do not stop after only describing the gap. See `references/support.md`.

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

@@ -15,7 +15,6 @@ Before deploying, Fimo fast-forwards a clean checkout that is behind and stops o
 ```bash
 fimo deploy                                  # preview only (default; reversible)
 fimo deploy -m "<commit message>"            # commit pending + push + sandbox sync
-fimo deploy --no-restart                     # skip dev-server restart (HMR-safe changes only)
 fimo deploy -m "<commit message>" --publish  # also publish a new live version
 ```
 
@@ -23,7 +22,6 @@ fimo deploy -m "<commit message>" --publish  # also publish a new live version
 - **`fimo deploy --publish`** — same as above, then triggers a live publish and prints the live URL. Runs from the configured Production source Branch only. **Only use `--publish` when the user signals "ship it"** — first-time site completion, or an explicit "publish" / "go live" request. Otherwise stick to plain `fimo deploy`. (For a _versioned_ prod release, use `fimo publish` instead — see below.)
 - **`-m`** is the commit message used when there are uncommitted local changes; required in non-interactive shells. Omit if the working tree is already clean.
 - **`--description "<why>"`** — the commit body for those changes: why they were made. Teammates and agents that later edit the same files read it, for example when a merge conflicts. Pass it with `-m` when the reason is not obvious from the diff.
-- **`--no-restart`** — tells the sandbox to skip the dev-server restart and let Vite HMR pick up the change. Shaves ~3s per deploy. A deploy that carries changed variables restarts anyway. See "Skipping the dev-server restart" below for when it's safe.
 
 ## Reading deploy destinations
 
@@ -89,7 +87,7 @@ Redirects, response headers, and URL shape belong in
 
 This is a **performance optimization, only worth doing when you already know a deploy is coming** (the developer asked to publish, or you're confident they'll want a hosted preview soon). If you're just iterating locally, skip it — don't deploy pre-emptively. New-project onboarding never needs it: its automatic first preview deploy is the warm-up.
 
-The first deploy of a project's life pays a one-time cost: the sandbox has to provision (create the VM, install the user's deps if they differ from the template's baked ones, start the dev server) — about 15-30s. Every deploy after that lands on a warm sandbox (~10s, or ~4s when you also use `--no-restart` and the lockfile hasn't changed).
+The first deploy of a project's life pays a one-time cost: the sandbox has to provision (create the VM, install the user's deps if they differ from the template's baked ones, start the dev server) — about 15-30s. Every deploy after that lands on a warm sandbox (~4-10s).
 
 **To hide that one-time cost, kick off an early deploy in the background while you keep working.** The provisioning happens during your generation work, so by the time the developer wants a hosted preview, the sandbox is already warm and the deploy is fast.
 
@@ -99,29 +97,6 @@ fimo deploy -m "chore: init" &        # background; keep generating code while i
 
 There's nothing special about this — it's the same `fimo deploy` you'd run later. The `-m` is the commit message for any files `validate` writes via codegen; pick a sensible conventional-commit string (e.g. `chore: init`, `chore: scaffold`). The point is purely the timing: pay the provisioning tax up front instead of when the user is waiting on a result. **This is also the only path that installs your project's deps on the sandbox** — if you skip it, the first interactive deploy will pay both costs.
 
-## Skipping the dev-server restart
-
-`fimo deploy --no-restart` tells the API not to restart the sandbox's dev server after pulling new code. Vite's HMR picks up the change instead, which is what it's designed for — 3+ seconds saved per deploy.
-
-**Use `--no-restart` when you only touched HMR-safe files:**
-
-- Anything under `src/**` (components, pages, hooks, styles)
-- Fixed-path static files under `public/`, such as favicons or `robots.txt` (images and videos belong in the media library, not the repository; see the `fimo-code` skill's non-negotiable boundaries)
-- Content / entries / translations / form definitions (JSON the Fimo runtime hot-loads)
-
-**Do NOT use `--no-restart` when you touched any of these — they require a fresh dev server:**
-
-- `vite.config.*` (Vite plugin or config changes)
-- `react-router.config.*` (router config)
-- `tsconfig.json` (TypeScript compiler)
-- `.env` (env vars are read at process start)
-- `package.json` or any lockfile (dep changes)
-- Anything under `.fimo/` (Fimo's own pre-build / runtime config)
-
-**When in doubt, omit the flag.** The default (restart) is the safe choice — a wasted restart costs 3 seconds; a missing one costs the user serving stale code until they notice and re-deploy.
-
-**One case is handled for you:** if the deploy changes the project's route set (a page added, removed, or moved), the API tells the preview to reload regardless of this flag. A router builds its route table once per document, so the new page would otherwise exist but be unreachable — missing from the Studio route selector and 404-ing from the site's own links. This costs a page load, not a restart.
-
 ## Publishing: `fimo deploy --publish` vs `fimo publish`
 
 Use `fimo deploy --publish` to push and publish local changes. Use `fimo publish` to publish the revision already on the Fimo remote without pushing. Both target the configured Production source Branch.

package/assets/skills/fimo-studio/references/ai-chat.md

@@ -37,7 +37,7 @@ A routine is saved instructions an agent runs in a thread of its own, by hand, o
 
 The AI can place choices, cards, tables, images, and contextual actions directly in its reply. Optional suggestions do not interrupt the conversation.
 
-When the AI needs an answer before it can continue, it pins a form directly above the message box and waits for your response. While the question is the last message, the form stays there as you scroll the conversation; the message that asked shows **Waiting for your answer...** in its place in the history. If you send a message that does not answer it, the question moves back to its place in the history, folded to one line with an orange **?**. Select it to open it there and answer it at any time, with an optional note from **Add a note**; the answer is sent as a new message at the end of the chat. An answered question shows a gray check next to its title. Select **Minimize** to fold the form to one line without losing your answers, then select that line to reopen it. **Submit** sends only the completed form and leaves anything typed in the message box unsent. Sending from the message box includes any selections already made in the form with your message; with no selections, it is an ordinary reply and the question stays open. A form with many steps scrolls inside its own area, and its **Next** / **Submit** buttons stay in view.
+When the AI needs an answer before it can continue, it opens a form in the conversation, under the message that asks, and waits for your response. The form goes one step at a time with **Previous**, **Next**, and **Submit**, and a step with choices has an optional note field under them. If you send a message that does not answer it, the question folds to one line with an orange **?** where it was asked. Select it to open it there and answer it at any time; the answer is sent as a new message at the end of the chat. An answered question shows a gray check next to its title. When a routine asks again before anyone answered, its earlier question stays unanswered, folded where it was asked. Select **Minimize** to fold the form to one line without losing your answers, then select that line to reopen it. **Submit** sends only the completed form and leaves anything typed in the message box unsent. Sending from the message box includes any selections already made in the form with your message; with no selections, it is an ordinary reply and the question stays open.
 
 ## Attaching Context
 

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

@@ -61,6 +61,15 @@ From there:
 3. Pick a plan and complete checkout.
 4. Your new monthly credit pool is available right away.
 
+## Activating a team organization
+
+Only your personal organization starts on Free. A new team organization opens nothing until someone completes a Starter or Pro checkout: every page of it lands on **Choose a plan for {organization}**, and its sites, integrations, members, domains and settings stay unavailable until then.
+
+- An owner or admin picks **Continue with Starter** or **Continue with Pro** and completes checkout. Other members see that an owner or admin must activate it.
+- Leaving checkout without paying keeps the organization inactive. Use the organization switcher at the top of the page to go back to another organization.
+- An owner who no longer wants the organization can delete it from the same page.
+- A team organization that has paid once stays usable if it later moves to Free.
+
 ## Extra usage budget
 
 Open **Billing & usage**, then **Details** beside public bandwidth. Billing admins on Starter or Pro can edit one **Monthly budget** for extra public bandwidth. The page shows its cost and **Spent this period**. This budget does not cover AI credit purchases or auto-refill.

package/assets/skills/fimo-studio/references/project-creation.md

@@ -11,13 +11,13 @@ To build with your own AI instead, select **Build with ChatGPT, Claude or a codi
 ## Start From a Website
 
 1. Enter the website address. Fimo checks that it can read the site; if it cannot, it says why and nothing is created.
-2. Fimo creates the site, reads its homepage, works out what kind of site it is (business, non-profit, portfolio, hobby or personal site), and asks three questions that fit it in a short chat. It always starts by confirming what it understood. A business then keeps or adds its competitors and says how it stands out and how it is priced; other sites say what visitors should do and what to put forward, picking suggestions or typing their own. The answers are saved as the site's knowledge. If Fimo cannot read the site for the questions, select **Try again**.
-3. The report opens as soon as the last question is answered. It shows how ready the site is for search engines (SEO) and AI answers (GEO), with every check and how to fix it. Leaving and coming back resumes where you left off.
-4. Select **Copy & optimize my homepage**, at the top of the report. The site opens on its **Getting started** chat, where Fimo rebuilds the homepage with the report's problems fixed, then shows the scores before the rebuild and the checks it fixed. Only the homepage is rebuilt; links to other pages still go to the current site. Fimo covers the cost of the analysis, the questions and the first two rebuilds; credits are not used for them.
+2. Fimo creates the site, reads its homepage, works out what kind of site it is (business, non-profit, portfolio, hobby or personal site), and asks three questions that fit it in a short chat. It always starts by confirming what it understood. A business then keeps or adds its competitors and says how it stands out and how its prices compare to those competitors; other sites say what visitors should do and what to put forward, picking suggestions or typing their own. The answers are saved as the site's knowledge. If Fimo cannot read the site for the questions, select **Try again**.
+3. The report opens as soon as the last question is answered. It shows how ready the site is for search engines (SEO) and AI answers (GEO), with every check and how to fix it. To keep or share it, select **Export**. Leaving and coming back resumes where you left off.
+4. Select **Recreate and fix my homepage**, under the score. The site opens on its **Getting started** chat, where Fimo rebuilds the homepage with the report's problems fixed, then shows the new score and what it changed. Only the homepage is rebuilt; links to other pages still go to the current site. The first two homepage rebuilds are free; after that, a rebuild uses credits.
 
 Fimo does not rebuild a site that breaks its terms of use: the onboarding stops with a message to contact support.
 
-The report and the homepage copy Fimo read are deleted after 7 days.
+The report and the homepage copy Fimo read are deleted after 7 days. Export the report to keep it.
 
 Once the homepage is rebuilt, a banner offers to bring over the other pages: copy a prompt into an AI, or book a call or write to the Fimo team. Website migration is in alpha, so review every result. Dismissing the banner hides it for good.
 

package/dist/cli/bundle.json

@@ -1,7 +1,7 @@
 {
   "bundled": true,
   "bundler": "esbuild",
-  "bundledAt": "2026-10-26T15:15:56.841Z",
+  "bundledAt": "2026-10-27T12:30:49.379Z",
   "cliVersion": "2.9.0",
   "external": [
     "oxc-parser",