fimo 2.10.0-staging.7 → 2.10.0-staging.8

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/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-26T18:26:44.293Z",
   "cliVersion": "2.9.0",
   "external": [
     "oxc-parser",