fimo 0.11.0-staging.4 → 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-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/dist/cli/bundle.json

@@ -1,7 +1,7 @@
 {
   "bundled": true,
   "bundler": "esbuild",
-  "bundledAt": "2026-08-02T09:47:16.199Z",
+  "bundledAt": "2026-08-03T10:18:45.069Z",
   "cliVersion": "0.10.0",
   "external": [
     "oxc-parser",