fimo 0.11.0-staging.3 → 0.11.0-staging.5

package/assets/agent-templates/content-translator/GOAL.md

@@ -31,4 +31,4 @@ For each entry:
 
 Cloud-time activation of this agent requires
 `agents.notifications.email_recipients` to be non-empty (per ADR-0009).
-Add at least one address before running `fimo agents activate`.
+Add at least one address before deploying, or the cloud trigger stays unwired.

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

@@ -102,7 +102,7 @@ Load the matching reference when the user's request fires its trigger. Recipes t
 - "Modify the URL of the website / change my project's address / connect a custom domain (e.g. blog.example.com) / rename the Fimo-provided `*.fimo.site` subdomain / buy a new domain through Fimo / set up a domain" → `references/domains.md`
 - "Invite a collaborator / add Marc / share with client" → `references/invite.md`
 - "Login / log out / who am I / switch organization" → `references/account.md` — note: switching **org** is `fimo orgs switch`; bare `fimo switch` switches **env** (see `references/branches.md`)
-- "Create / scaffold / run / validate / activate / deactivate an agent / agent bundle / list agent templates / view agent runs, reports, or logs (`fimo agents *`)" → `references/agents.md`
+- "Create / scaffold / run / validate an agent / agent bundle / wire or enable its triggers / list agent templates / view agent runs, reports, or logs (`fimo agents *`)" → `references/agents.md`
 - "Install Fimo for my AI tool / fimo skills install / set up Claude Code or Cursor for Fimo / add an agent to this project" → `references/agent-setup.md`
 - "Refresh / update installed Fimo skills / fimo skills sync / agent missing the latest fimo conventions" → `references/agent-setup.md`
 - "Report a Fimo problem or blocking feature request / contact Fimo support / a Fimo API or command keeps failing / a documented argument is rejected / a supported operation needs an undocumented workaround / a Fimo API is abnormally slow / a confirmed missing capability blocks completion or forces a fragile or heavily manual workaround" → `references/support.md`
@@ -140,4 +140,4 @@ These fire at specific moments in the project lifecycle. **Surface them proactiv
 - **Hardcoding tokens in flags** — use the credentials written by `fimo login` (one file per backend at `~/.config/fimo/credentials/<host>-<hash>.json`).
 - **Treating the daily allowance as extra credits** — `fimo credits` already includes spendable daily free credits in "Available now"; the allowance section is accounting context, not an amount to add.
 - **Trying to refill credits from the CLI** — `fimo credits` is read-only. Buying/refilling credits belongs in the billing UI for now.
-- **`fimo agents activate` / `run` to push bundle changes** — they don't. The bundle reaches the server through `fimo deploy` (it lives in git, not the DB). `activate` only writes activation rows; `run` dispatches the _deployed_ version. Deploy first. See `references/agents.md`.
+- **`fimo agents run` to push bundle changes** — it doesn't. The bundle reaches the server through `fimo deploy` (it lives in git, not the DB), and that push to `main` is also what wires the declared triggers. `run` dispatches the _deployed_ version. Deploy first. There is no `activate` command. See `references/agents.md`.

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

@@ -9,9 +9,9 @@ The `fimo agents` namespace authors and operates **agent bundles** — multi-fil
 The namespace splits cleanly in two:
 
 - **Bundle authoring** — `create`, `list-templates`, `list`, `validate`, `secrets add/remove/list`. Local config editing, no API call except the project-level validation path. Operates on the files under `agents/<name>/`.
-- **Cloud ops** — `run`, `activate`, `deactivate`, `runs`, `report`, `logs`. Env-aware, talk to the server. Default `--env` is `main`; `--project` defaults to the `projectId` in `.fimo.settings.json`.
+- **Cloud ops** — `run`, `runs`, `report`, `logs`. Env-aware, talk to the server. Default `--env` is `main`; `--project` defaults to the `projectId` in `.fimo.settings.json`.
 
-The bundle lives in **git** (`agents/<name>/`), not the database. The DB only holds **activations** (which triggers are wired on which env) and **run sessions**. So the bundle reaches the server through `fimo deploy`, not through `activate`/`run`.
+The bundle lives in **git** (`agents/<name>/`), not the database. The DB only mirrors what `config.yaml` declares on `main` (which triggers are wired) plus **run sessions**. So the bundle reaches the server through `fimo deploy` — and that push to `main` is also what wires its triggers. There is no activate command: deploying IS the enablement act, and removing a trigger from `config.yaml` tears it down on the next deploy.
 
 Typical flow:
 
@@ -21,8 +21,7 @@ fimo agents secrets add <name> FIRECRAWL_API_KEY  # request a project secret in
 fimo secrets add FIRECRAWL_API_KEY --stdin        # store the hidden value in Fimo
 fimo agents validate <name>   # parse + policy + composition + requested secrets
 fimo validate                 # project build and codegen checks
-fimo deploy                   # push the bundle to the env's git branch
-fimo agents activate <name>   # wire its triggers on the env (DB row)
+fimo deploy                   # push to main — this also wires the declared triggers
 fimo agents run <name>        # trigger a manual run → sessionId
 fimo agents runs <name>       # see past sessions
 fimo agents report <name>     # print a run's report (the agent's final message)
@@ -63,24 +62,28 @@ integrations:
 
 ```bash
 fimo agents run <name> [--env <env>] [--project <id>] [--skip-drift-check] [-C <dir>]
-fimo agents activate <name> [--trigger <type>] [--env <env>] [--project <id>] [--quiet] [-C <dir>]
-fimo agents deactivate <name> [--trigger <type>] [--env <env>] [--project <id>] [-C <dir>]
 fimo agents runs <name> [--limit <n>] [--env <env>] [--project <id>] [-C <dir>]
 fimo agents report <name> [--session <id>] [--env <env>] [--project <id>] [-C <dir>]
 fimo agents logs <name> [--session <id>] [--project <id>] [-C <dir>]
 ```
 
-- **`run <name>`** — trigger a real manual run on the server; prints a `sessionId` on success (or a skip reason when the server short-circuits). **Pre-flight drift check**: if `agents/<name>/` has uncommitted git changes, the command refuses — the server would dispatch the _deployed_ version, so deploy first. Pass `--skip-drift-check` to dispatch the deployed bundle anyway. Defaults `--env` to `main`.
-- **`activate <name>`** — wire the agent's triggers on an env (writes `agent_activations` rows). A `schedule` trigger creates a cron, a `webhook` trigger reserves a path, and `manual` just enables dispatch. `--trigger <type>` (`schedule` / `webhook` / `manual`) activates only that type; otherwise all declared triggers. **The bundle must be deployed first.** Cloud triggers (`schedule` / `webhook`) require `notifications.email_recipients` in `fimo-config.json` (the dash-form scaffold file; legacy `fimo.config.json` is also accepted). Capability install-consent runs unless `--quiet`.
-- **`deactivate <name>`** — remove activation rows on an env. Idempotent. `--trigger <type>` scopes to a single trigger type.
+- **`run <name>`** — fire the agent's `manual` trigger on the server; prints a `sessionId` on success. Skips with `no-manual-trigger` when `config.yaml` declares none, or `trigger-not-wired` when the push-to-main sync recorded the trigger but refused to wire it (see the wiring note below). **Pre-flight drift check**: if `agents/<name>/` has uncommitted git changes, the command refuses — the server would dispatch the _deployed_ version, so deploy first. Pass `--skip-drift-check` to dispatch the deployed bundle anyway. Defaults `--env` to `main`.
 - **`runs <name>`** — list past run sessions for the agent in a compact table (id, started, duration, status, trigger, env, cost). Default `--limit 20`; `--env` filters to one env.
 - **`report <name>`** — print a run's **report**: the agent's final message, captured when the run finishes (for a read-only agent like `seo-audit` this _is_ the audit; for a write agent it's a "what I changed" summary). With no `--session`, the most recent run for `<name>` is used (combine with `--env` to scope); `--session <id>` targets a specific run. Output is raw markdown, so it stays readable in the terminal and pipes cleanly (e.g. `fimo agents report seo-audit | glow`). If the run hasn't finished, or produced no message, it says so (and shows the stop reason when there is one). This is the command to read what a run actually produced — see the `logs` note below.
 - **`logs <name>`** — stream a run's log (defaults to the latest session; `--session <id>` targets one). **Note:** the log-streaming endpoint is still a server-side stub at time of writing — the command prints a placeholder rather than real log lines. To read a finished run's output today, use `report`.
 
+## How triggers get wired
+
+Agents are not env-scoped: they belong to the project, are read from `main`, and their triggers are global. A branch env has no agents of its own — Studio's agents view shows main's agents whichever env you are on, and a bundle sitting only on a feature branch appears nowhere until it reaches main.
+
+Pushing `agents/<name>/config.yaml` to `main` is the whole enablement act — `fimo deploy` does it. The server reconciles the file into its trigger rows on every push: a `schedule` trigger gets a cron, a `webhook` trigger gets its path, and `manual` becomes runnable. Removing a trigger from the file deletes it (cron torn down, path released) on the next deploy; deleting the agent's directory removes the whole deployment.
+
+Cloud triggers (`schedule` / `webhook`) additionally require `notifications.email_recipients` in `fimo-config.json` (the dash-form scaffold file; legacy `fimo.config.json` is also accepted). Without it the trigger is recorded but deliberately left **unwired** and will not fire — `fimo agents validate` warns about this before you deploy, and the Studio agents view shows the reason afterwards.
+
 ## `-C, --cwd <dir>`
 
 Every `fimo agents` command accepts `-C, --cwd <dir>` to point at a different project directory. For the cloud-ops commands, `--project <id>` overrides the project id otherwise read from `.fimo.settings.json`.
 
 ## Non-interactive use
 
-Authoring commands (`list-templates`, `list`, `validate`) never prompt. `create` and `activate` run an install-consent flow when the bundle declares capabilities — pass `--quiet` to skip it in scripts / CI (critical capabilities still abort).
+No `fimo agents` command prompts — authoring and cloud ops both run unattended.

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

@@ -41,11 +41,11 @@ All of these accept the global `--env` override. `diff`, `status`, `merge`, and
 
 > **`fimo switch` is the ENV switcher, not the org switcher.** To change your active organization, use `fimo orgs switch` — see `references/account.md`.
 
-## The 7 surfaces
+## The 6 surfaces
 
 `status`, `diff`, and `merge` all reason over the same per-env surfaces, in this order:
 
-`code` · `schemas` · `content` · `translations` · `assets` · `forms` · `activations` (agent activations)
+`code` · `schemas` · `content` · `translations` · `assets` · `forms`
 
 `--surface <name>` on `diff` and the per-surface flags on `status` (`--code`, `--content`, `--i18n`, `--agents`, `--assets`, `--forms`) filter to one of them.
 

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

@@ -34,6 +34,8 @@ The command is `fimo schemas` (plural). There is no singular `fimo schema` alias
 
 All commands accept `-C, --cwd <dir>` to point at a different project directory.
 
+Blocks schemas support at most 7 nested `blocks` levels, 40 variants in one `schema.oneOf`, and `min` or `max` values up to 200 items per blocks field. Load `fimo/references/content.md` for the complete blocks JSON shape.
+
 Schema transitions are automatic. Adding optional fields and changing labels preserve content. A new required field backfills its `default` only where existing values need it; the push fails safely when no default can satisfy existing content. Removing a nested field or block variant removes only those values. `string` and `text` preserve values in both directions. Other primitive changes convert safe values and reject unsafe ones without changing the schema or entries. Lowering block `max` trims from the end; raising `min` fills from the blocks `default` templates. A reference target change clears its connections. Use repeatable `--rename old.path=new.path` arguments when a field moved by name so the one-time migration preserves its values; the operation is not stored in schema JSON. Collection-to-Single removes that type's entries and cleans inbound references; Single-to-collection preserves its entry. Run `fimo validate` after pushing.
 
 ## Singles CLI commands

package/assets/skills/fimo-code/references/content.md

@@ -163,6 +163,7 @@ A field may declare `showIf` (every clause must match) or `showIfAny` (one claus
 
 - `blocks.schema.fields` repeats one homogeneous shape.
 - `blocks.schema.oneOf` lets the editor choose exactly one variant per item.
+- Blocks schemas support at most 7 nested `blocks` levels, 40 variants in one `schema.oneOf`, and `min` or `max` values up to 200 items per blocks field.
 - Blocks always read and write arrays. A field with `max: 1` is `[]` or `[item]`, never a bare object.
 - `min` and `max` constrain the total number of blocks. Use `min: 1` to require at least one block; `required: true` has the same minimum-one behavior.
 - Fimo creates a stable `_key` for each item. A `oneOf` item also carries `_type`, matching the variant `uid`.

package/assets/skills/fimo-code/references/setup-plain-vite.md

@@ -90,11 +90,11 @@ The `seo` plugin rewrites `<title>`, og, twitter, canonical tags from
 
 ## File: `src/main.tsx`
 
-`FimoProviders` (and the runtime primitives it wraps) require **two** contexts:
-a React Router `<Router>` ancestor (it reads `useLocation`/`useNavigate`) and a
-`@tanstack/react-query` `<QueryClientProvider>` (its internal
-`RefreshContentProvider` calls `useQueryClient`). Mount both around
-`<FimoProviders>`:
+`FimoProviders` requires a React Router `<Router>` ancestor (it reads
+`useLocation`/`useNavigate`). It reuses a host app's
+`@tanstack/react-query` client when one exists and supplies a stable fallback
+for adopted SPAs. This recipe still mounts an explicit provider so the app owns
+the shared cache and its configuration:
 
 ```tsx
 import { FimoProviders } from 'fimo/react-router';
@@ -122,8 +122,9 @@ createRoot(document.getElementById('root')!).render(
 
 `react-router` and `@tanstack/react-query` are peer dependencies of `fimo`;
 both are in the install command above. `FimoProviders` is exported only from
-the `fimo/react-router` adapter barrel — there is no router-free (or
-react-query-free) provider surface in the package today.
+the `fimo/react-router` adapter barrel. Keep the explicit QueryClientProvider
+when the app needs custom query defaults or shared cache access; adopted SPAs
+can omit it.
 
 ## File: `src/App.tsx`
 

package/assets/skills/fimo-code/references/setup-react-router.md

@@ -100,6 +100,11 @@ when to render them, and how.
 
 ## File: `src/root.tsx`
 
+The explicit `QueryClientProvider` below is the canonical template shape so the
+app can configure query defaults such as `staleTime`. Adopted SPAs can omit it:
+`FimoProviders` reuses an ancestor client when present and supplies a stable
+fallback otherwise.
+
 ```tsx
 import { QueryClient, QueryClientProvider } from '@tanstack/react-query';
 import { FimoProviders, FimoScripts, loadFimoMetaData, buildFimoMeta, fimoHtmlProps } from 'fimo/react-router';

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

@@ -9,6 +9,12 @@ The AI chat opens as a floating panel by default. You can dock it to the left or
 3. Press **Enter** or click the **send button**.
 4. The AI responds in a stream. You see tool status badges appear as it works, and the preview updates automatically.
 
+## Responding to Choices and Forms
+
+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 shows a form in the chat and waits for your response. Complete the form for a structured answer, or reply normally in the chat to answer in your own words.
+
 ## Attaching Context
 
 Give the AI more to work with:
@@ -37,9 +43,9 @@ While the AI works, you see small badges in the chat showing what it is doing. E
 
 Chat changes are prepared separately and then applied to the environment you are viewing. Most changes merge automatically.
 
-If the project changed in the same place while the AI was working, the response shows a **Review changes** card instead. Open it to inspect the proposal, resolve any conflicts, and merge when it is ready. Until you merge it, the proposal is not part of the environment and later chat messages will not see it.
+If the project changed in the same place while the AI was working, the response shows a **Review changes** card and an attention banner above the chat input. The banner remains visible when floating chat history is collapsed.
 
-Discarding the merge leaves the current environment unchanged and keeps the proposal separate.
+Choose **Auto fix** or keep chatting to let Fimo continue in the retained proposal, resolve the conflict, and retry the merge. Choose **Review manually** to inspect and resolve the proposal yourself. Discarding leaves the current environment unchanged and permanently removes the proposal.
 
 ## Tips for Better Results
 

package/assets/skills/fimo-studio/references/custom-domains.md

@@ -12,7 +12,7 @@ If you're driving Fimo from the terminal, the equivalent commands are `fimo doma
 ## Adding a Custom Domain
 
 1. Open **Settings** from the top navigation bar (gear icon), alongside Preview, Content, Assets, Agents, and Analytics.
-2. In the Settings menu on the left, select **Domains** (globe icon) — listed with General, SEO, and Audit log.
+2. In the Settings menu on the left, select **Domains** (globe icon) — listed with General and SEO.
 3. Click the **Add domain** button (+ icon) in the top-right of the panel. (When domain purchase is enabled, a **Buy domain** button with a shopping-cart icon sits next to it.)
 4. A drawer opens. Type or select a domain — you can enter a subdomain or an apex domain. Domains your organization already owns appear in an autocomplete dropdown, and Fimo checks availability live as you type. For an apex domain, a checkbox lets you also redirect it to the `www` subdomain (on by default). Confirm to add it.
 5. A DNS table appears showing the record(s) you need to add. For a **subdomain** it's a single CNAME record:

package/assets/skills/fimo-studio/references/publish-and-deploy.md

@@ -14,7 +14,7 @@ Every change you make is automatically saved to your project, but saved changes
 
 To push your latest changes live, open the publish panel from the header **Publish** button and click **Publish** inside it again. It redeploys with your latest code and content.
 
-> **Tip:** Before your site has ever been published, the chat shows a one-click **Publish** button that deploys immediately without opening the panel.
+> **Tip:** After completing relevant work, the AI may offer a one-click **Publish** callout in chat. It appears only when publishing is available; the header **Publish** control remains the reliable path at any time.
 
 ## Publishing Changes That Need Review
 
@@ -29,6 +29,7 @@ The header **Publish** button itself only shows the label "Publish" (or a spinne
 - **"Not published yet"** — Your site has never been published. The **Publish** button inside the panel is ready to click.
 - **"Publishing"** — Publishing is in progress. A spinner and a **Publishing** status badge show while it builds, and the button is disabled.
 - **"Published"** — Your site is live. A **Published** status badge appears, your live URL is listed under a **Published site** heading as a clickable link, and a **Last published** date and time is shown.
+- **"Couldn't publish · N issues"** — Project validation found issues that must be fixed first. Choose **Fix with Fimo** to send the safe issue list to the project chat and ask Fimo to repair it.
 
 ## Key Concepts
 

package/dist/cli/bundle.json

@@ -1,7 +1,7 @@
 {
   "bundled": true,
   "bundler": "esbuild",
-  "bundledAt": "2026-07-31T07:49:25.482Z",
+  "bundledAt": "2026-08-03T10:18:45.069Z",
   "cliVersion": "0.10.0",
   "external": [
     "oxc-parser",