fimo 2.4.0-staging.4 → 2.4.0-staging.5

package/assets/skills/fimo-cli/references/agent-setup.md

@@ -33,6 +33,7 @@ fimo login                             # connect your account when ready
 ```bash
 fimo skills install                            # interactive: pick agents, install the global bootstrap
 fimo skills install --agents=claude-code,cursor   # explicit list
+fimo skills install --agents=hermes               # Hermes default profile, or the active HERMES_HOME
 fimo skills install -a claude-code -a cursor      # repeatable form
 fimo skills sync                               # re-ensure the bootstrap + clean up stale old skills
 fimo skills uninstall                          # remove the global bootstrap
@@ -80,7 +81,7 @@ Every command that takes agents accepts the same selection inputs:
 - `-a claude-code -a cursor` — repeatable short form
 - No flag → interactive multi-select. The picker has two sections:
   - **Universal** — agents that read `AGENTS.md` natively (Codex, OpenCode, Aider, …). Always covered, not toggleable.
-  - **Additional** — agents that get the global bootstrap skill installed. The 6 popular ones (`claude-code`, `cursor`, `codex`, `opencode`, `windsurf`, `gemini-cli`) appear at the top of an 8-item scrollable viewport; the full list of 50+ supported agents is below the fold. Agents already set up on the machine are pre-checked.
+  - **Additional** — agents that get the global bootstrap skill installed. The popular ones (`claude-code`, `cursor`, `codex`, `opencode`, `windsurf`, `gemini-cli`, `hermes`) appear at the top of the picker; the full list of supported agents remains available below them. Agents already set up on the machine are pre-checked.
 - `--agents=none` (only `fimo init`) — skip the global skill entirely.
 
 In headless contexts (CI, agent-spawned commands), pass the flag explicitly. Env-var detection (only Claude Code's `CLAUDECODE` / `CLAUDE_CODE_ENTRYPOINT`) silently targets `claude-code` if the flag is omitted; every other agent must be named explicitly with `--agents` in a headless shell, or the command exits with "No agents detected and no --agents flag passed."

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

@@ -271,7 +271,19 @@ fimo agents runs <name> [--limit <n>] [--cursor <cursor>] [--all-pages] [--branc
 fimo agents report <name> [--session <id>] [--branch <branch>] [--project <id>] [-C <dir>]
 ```
 
-- **`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 `.fimo/agents/<name>/` (or the legacy root bundle) 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 `--branch` to `main`.
+- **`run <name>`** — fire the agent's `manual` trigger on the server; prints a `sessionId` on success. A refusal you must act on exits **1** with a stable code (`--json` puts it in `error.code`, and the raw server reason in `error.details.skipped`):
+
+  | Code                        | Means                                                                           | Fix                                               |
+  | --------------------------- | ------------------------------------------------------------------------------- | ------------------------------------------------- |
+  | `AGENT_NOT_DEPLOYED`        | no bundle for this agent on `main`                                              | `fimo deploy`                                     |
+  | `AGENT_CONFIG_INVALID`      | the deployed bundle does not parse, so the sync registered none of its triggers | `fimo agents validate <name>`, fix, `fimo deploy` |
+  | `NO_MANUAL_TRIGGER`         | the deployed `config.yaml` really declares no `manual` trigger                  | add `- type: manual`, `fimo deploy`               |
+  | `MANUAL_TRIGGER_NOT_SYNCED` | `main` declares it, the background sync has not registered it yet               | wait a few seconds, retry                         |
+  | `TRIGGER_NOT_WIRED`         | registered but not live (see the wiring note below)                             | `fimo agents list` for the reason                 |
+  | `INSUFFICIENT_CREDITS`      | the org is under the credit floor a run needs                                   | `fimo credits`                                    |
+
+  A refusal that clears on its own (`agent-paused`, `run-in-progress`, `task-branch-budget`) exits **0** and prints `Dispatch was skipped: <reason>`. **Pre-flight drift check**: if `.fimo/agents/<name>/` (or the legacy root bundle) 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 `--branch` to `main`.
+
 - **`runs <name>`** — list past run sessions for the agent in a compact table (id, started, duration, status, trigger, Branch, credits — settled credit consumption, `—` until a run settles). Default `--limit 20`; `--branch` filters to one Branch. The response uses the canonical `branch` field.
 - **`report <name>`** — print a run's structured **report**: its durable outcome summary (for a read-only agent like `seo-audit` this _is_ the audit; for a write agent it's a "what I changed" summary). A run that returns plain text without calling `finish_run` receives a small structured fallback document. With no `--session`, the most recent run for `<name>` is used (combine with `--branch` to scope); `--session <id>` targets a specific run. Output is projected 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 report, it says so (and shows the stop reason when there is one).
 

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

@@ -24,7 +24,7 @@ fimo forms delete <id>            # delete a form
 
 Notification recipients for form submissions are configured in the Fimo web UI, not via CLI.
 
-## Reading submissions
+## Reading and deleting submissions
 
 After a form is live and users have filled it out, inspect submissions from the terminal:
 
@@ -32,6 +32,7 @@ After a form is live and users have filled it out, inspect submissions from the
 fimo forms submissions list <formIdOrName> [--limit 50] [--cursor CURSOR] [--all-pages] [--search "<q>"] [--sort asc|desc]
 fimo forms submissions get  <formIdOrName> <submissionId>
 fimo forms submissions stats <formIdOrName>
+fimo forms submissions delete <formIdOrName> <submissionId>
 ```
 
 The list response includes `nextCursor` when another page exists. `--offset` remains a compatibility alias for existing scripts.
@@ -39,7 +40,8 @@ The list response includes `nextCursor` when another page exists. `--offset` rem
 - `<formIdOrName>` accepts either the form's UUID or its `name` (the same name in the JSON file). Names that don't resolve to exactly one form return an error.
 - `list` returns `{ data: [...], total }`. Newest-first by default; pass `--sort asc` to reverse.
 - `search` matches against submission contents server-side.
-- All three are read-only — there's no CLI command to create or delete a submission. Submissions are created by the form intake endpoint when a user submits the published site's form.
+- `delete` removes one submission permanently and prints the deleted record. There is no undo, no bulk delete, and no confirmation prompt — confirm with the user before running it. An unknown or already-deleted id fails with `Submission not found`.
+- There's no CLI command to create a submission. Submissions are created by the form intake endpoint when a user submits the published site's form.
 
 Use this when the user asks "who filled out the contact form?", "how many signups did we get this week?", or "show me the latest submission". For older submissions or bulk export, point them at the dashboard — there's no batch export endpoint yet.
 

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

@@ -51,12 +51,21 @@ From there:
 3. Pick a plan and complete checkout.
 4. Your new monthly credit pool is available right away.
 
+## Extra usage budget
+
+Open **Billing & usage**, then **Details** beside public bandwidth. Billing admins on Pay as you go or Pro can edit one **Monthly budget** for extra public bandwidth and autonomous agent runtime. The page shows each meter's cost and **Spent this period**. This budget does not cover AI credit purchases or auto-refill.
+
+- Enabling extra usage covers both meters. An existing bandwidth-only budget requires explicit consent before it also covers agent runtime.
+- Agents shows included hours, usage, extra cost, and the reset date, with a link to the shared budget. Pay as you go includes 3 hours, then $0.75/hour; Pro includes 40 hours, then $0.33/hour.
+- At the budget, additional paid usage stops; remaining included allowances stay usable. Running agents stop at a safe point, so stopping is not instantaneous.
+- Disabling extra usage preserves charges already incurred. The budget cannot be lowered below existing extra-usage charges.
+
 ## Changing or leaving a paid plan
 
 - Free to Pay as you go or Pro, and Pay as you go to Pro, use checkout and take effect after payment succeeds.
-- Cancelling Pay as you go or Pro stops auto-refill and paid bandwidth immediately. The current plan, remaining allowances, credits, and reset date stay unchanged until Free takes over at renewal. Manual credit purchases remain available while the paid plan is active.
-- Automatic spending cannot be enabled while cancellation is scheduled. Keep your plan first; then you can immediately enable auto-refill and paid bandwidth independently. Keeping the plan itself leaves both off.
-- Usage before cancellation remains payable. Enabling paid bandwidth again does not make usage from the off-period billable.
+- Cancelling Pay as you go or Pro stops auto-refill and paid extra usage immediately. The current plan, remaining allowances, credits, and reset date stay unchanged until Free takes over at renewal. Manual credit purchases remain available while the paid plan is active.
+- Automatic spending cannot be enabled while cancellation is scheduled. Keep your plan first; then you can enable auto-refill and the shared extra-usage budget independently. Keeping the plan itself leaves both off.
+- Usage before cancellation 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.
 - Choosing the current plan again before that date cancels the scheduled change.
 - Pay as you go requires an active payment method. Removing its only valid card returns the organization to Free immediately.

package/dist/cli/bundle.json

@@ -1,7 +1,7 @@
 {
   "bundled": true,
   "bundler": "esbuild",
-  "bundledAt": "2026-09-05T18:55:36.599Z",
+  "bundledAt": "2026-09-06T09:22:37.733Z",
   "cliVersion": "2.3.2",
   "external": [
     "oxc-parser",