fimo 2.10.0-staging.4 → 2.10.0-staging.5

package/assets/skills/fimo/SKILL.md

@@ -41,7 +41,7 @@ Pick by task:
 - AI agent setup — connect Claude Code, Codex, Cursor, or another agent → `fimo-cli` (`references/agent-setup.md`)
 - Integrations — Search Console, Slack, or an MCP server: add, inspect, search, or run its tools → `fimo-cli` (`references/integrations.md`)
 - The Fimo Studio dashboard / web app UI → `fimo-studio`
-- Migrating an existing site into Fimo → `fimo-migration`
+- Migrating an existing site into Fimo, or putting an existing app on Fimo (`fimo link`) → `fimo-migration`
 
 For project setup, load `fimo-cli` first. Its `references/init.md` decision tree distinguishes a new or empty
 project, an existing Fimo site, and an external migration; load `fimo-migration` for the last path.

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

@@ -111,6 +111,7 @@ Load the matching reference when the user's request fires its trigger. Recipes t
 - "Create a Branch / feature Branch / switch Branches / merge Branches / diff two Branches / Branch status / what changed on this Branch / sync from parent / cut a release / tag a version / go to prod" → `references/branches.md`
 - "List my projects / clone an existing project locally / check out a project / delete this project / unpublish / rename the project / manage projects across the org" → `references/projects.md`
 - "Migrate an existing Webflow / Framer / Squarespace / Wix / Carrd site from only a published URL" → load the `fimo-migration` skill, set the target up with `fimo migrate init <dir>`, and read the published site yourself with a browser — the CLI does not crawl it
+- "Put my existing site or app on Fimo / link or deploy the app in this folder / host the site I built" → load the `fimo-migration` skill and follow its source-backed, same-framework path: `fimo link` keeps every word typed in the code, which Studio cannot edit, until the migration's content pass moves it to labels and the CMS
 - "Migrate from an exported project, source repository, Webflow code export plus CMS CSVs, Framer CMS CSVs, Squarespace XML/CSV, Wix CSVs, Carrd/static export, or downloaded site files" → load the `fimo-migration` skill and use the source repo/export as the migration source of truth
 - "How do AI agents read my site / markdown for agents" → `references/deploy.md`
 - "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`

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

@@ -105,6 +105,10 @@ Use `fimo link <projectId>` to adopt the application in the current folder witho
 fimo link <projectId> --relink
 ```
 
+Linking keeps every word typed in the code, where Fimo Studio shows "Nothing to edit". When people will edit the site,
+load `fimo-migration` and follow its source-backed, same-framework path: its content pass moves that
+text to labels and the CMS, and its `editable-text` guardrail proves it.
+
 ## What gets written (create-new path)
 
 `fimo init` (create-new path) scaffolds:

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

@@ -20,11 +20,11 @@ into a real Fimo project without silently dropping source material.
 > supports the source framework, preserve it explicitly and verify the runtime
 > before importing data.
 >
-> Use the CLI invocation selected for this flow for every `fimo` command in the migration. Otherwise use `npx fimo@latest`; do not install it globally.
+> Use the pinned CLI invocation selected for this flow for every `fimo` command in the migration (see CLI provenance); do not install it globally.
 
 The first pass is a faithful migration, not a framework conversion. Detect the
-source framework before creating the target and pass it explicitly to
-`fimo migrate init`. For a Next.js source, use `--framework nextjs`; never rely
+source framework before setup. When `fimo migrate init` creates the target, pass
+it explicitly: for a Next.js source, use `--framework nextjs`; never rely
 on the React Router default. The setup receipt must report the target runtime
 framework, and a mismatch is a setup failure before any schemas, entries,
 assets, labels, or forms are imported.
@@ -90,30 +90,43 @@ artifact, and record which one.
 
 ## Initialized target precondition
 
-Before workers start, the root process must establish a real Fimo project and
-environment, link the migration checkout to it, and prove the data plane is
-reachable with a read such as `fimo schemas list -C <target> --branch <branch>` using
-the selected pinned CLI. Give workers the project id, environment, exact CLI
-invocation, and verification command. Generated `.fimo` JSON without a
-successful platform read is not initialization.
-
-Pick the setup path from the evidence:
-
-- **Source-backed, same framework** — copy or `git worktree` the source into the
-  target directory first, then run `fimo link -C <target> --branch <branch>`
-  (`fimo link <project-id> -C <target> --branch <branch>` when the owner supplied an
-  id). Link creates or selects the project, keeps the source's code, framework,
-  git history, and `origin`, initializes a repository when the copy has none,
-  and adds only the Fimo dependency, `.fimo/project.json`, the `fimo` remote,
-  and `.fimo/config.json#runtime.framework`. It never overlays a template, so
-  the target must already contain the source.
-- **Empty target, or an explicit framework conversion** — `fimo init` or
-  `fimo migrate init <dir>` with the chosen `--framework`. Both refuse a
-  non-empty target and write nothing when they refuse.
-
-If authentication, organization selection, project creation, environment
-resolution, linking, or the verification read fails, stop before workers and
-report the exact failed command and setup requirement.
+This is the one setup decision; every other reference points here. Pick the
+row that matches the user's request and the folder's state. When the target is
+genuinely unclear, ask once in the preflight question batch.
+
+| Starting point                                                                         | Setup                                                                                                                                                                                     | Original evidence                                                                                                                                                                      |
+| -------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| The user asked to put this existing folder on Fimo; it is already linked               | Reuse it. Verify its project, branch, and framework. Run `fimo link <same-id> -C <folder>` only to repair it.                                                                             | Keep the baseline below.                                                                                                                                                               |
+| The same, but the folder is not linked                                                 | Keep the baseline, then run `fimo link -C <folder> --branch <branch>`, with the project id when one was chosen.                                                                           | Keep the baseline below. Never reset, overwrite, or discard existing work.                                                                                                             |
+| The source is read-only input, or the user asked for a separate target; same framework | Copy or clone the source into the target first. If the copy kept a `.fimo/project.json`, reuse that project or resolve it on purpose. Then run `fimo link -C <target> --branch <branch>`. | The original stays read-only. A `git worktree` shares the repository's config and remotes: use an independent copy or clone when adding the `fimo` remote must not touch the original. |
+| An empty or new target with nothing to adopt, or an explicit framework conversion      | `fimo migrate init <target> --framework <chosen>` (see Target setup). Never overlay a template on populated source.                                                                       | The source repository or export stays separate.                                                                                                                                        |
+
+The baseline is an exact copy of the folder's pre-migration state, kept outside
+the folder. A commit plus a detached worktree is enough only when the tree is
+clean; otherwise also keep the dirty and untracked files. Never copy secret
+values into evidence.
+
+`fimo link` keeps the folder's code, framework, git history, branches, and
+`origin`, initializes a repository when there is none, and adds only the Fimo
+dependency, `.fimo/project.json`, the `fimo` remote, and
+`.fimo/config.json#runtime.framework`. It never overlays a template.
+
+Never invent a project or organization id, and never silently relink a folder
+to another project (`fimo link --relink` needs the owner's explicit choice).
+In a non-interactive shell, `fimo link` on an unlinked folder without an id,
+and `fimo migrate init` without `--project-id`, create a new project in the
+active organization, else the only one; `fimo migrate init` also takes `--org`. With several organizations and none
+active, the CLI fails clearly: ask the user which one. Ask only for a selection
+the CLI cannot resolve.
+
+Every row ends at the same gate. Before workers start, prove the actual project
+id and branch, a runtime framework that matches the source or the chosen
+conversion, the selected pinned CLI, and a successful data-plane read such as
+`fimo schemas list -C <target> --branch <branch>`. A local marker, generated
+`.fimo` JSON, or a `ready: true` receipt without that read is not
+initialization. Give workers the project id, branch, exact CLI invocation, and
+verification command. If any setup step fails, stop before workers and report
+the exact failed command and setup requirement.
 
 ## Core contract
 
@@ -135,7 +148,9 @@ report the exact failed command and setup requirement.
   ports the source's APIs, loaders, hardcoded content, integrations, and
   visible behavior into the new framework unchanged, and Fimo schemas,
   payloads, imports, and code wiring happen later through the content workers
-  (`references/workers/content-execution.md`). If the framework or hosting
+  (`references/workers/content-execution.md`). That content pass is part of the
+  migration, never a follow-up: the `editable-text` guardrail
+  (`references/qa.md`) fails while visible text is still typed in the code. If the framework or hosting
   setup is unclear or unsupported, stop and ask instead of guessing,
   converting it, or deleting provider-specific files.
 - Inventory provider-specific files and rules before editing them. Classify each
@@ -247,25 +262,24 @@ report the exact failed command and setup requirement.
 
 ## Target setup
 
-The target is its own Fimo project directory. The client source checkout is
-read-only evidence: never run setup inside it, never modify it, and never
-hand-write a `.fimo/project.json` marker to fake a link.
-
-`fimo migrate init` is the setup gate for an empty target; a target that
-already holds the copied source is set up with `fimo link` instead (see
-Initialized target precondition). `fimo migrate init` validates the target and
-CLI auth, then delegates project selection and creation to the standard
-`fimo init` flow (same options, no separate creation path), and returns a setup
-receipt covering auth, the target link, the migration directory, and readiness.
-It fails with a structured error when auth is missing, the target is missing or
-invalid, or the project or organization is inaccessible. Both forms need a real
-ID supplied by the owner — without one, stop with an unresolved owner action
-instead of inventing an ID:
-
-- Link an owner-supplied (empty) project:
+Choose the setup row in "Initialized target precondition". Never modify an
+original that the row keeps read-only, and never hand-write a
+`.fimo/project.json` marker to fake a link.
+
+`fimo migrate init` serves the empty-target and conversion row. It validates
+the target and CLI auth, then delegates project selection and creation to the
+standard `fimo init` flow (same options, no separate creation path), and
+returns a setup receipt covering auth, the target link, the migration
+directory, and readiness. It fails with a structured error when auth is
+missing, the target is missing or invalid, the target is populated but not
+linked, or the project or organization is inaccessible:
+
+- Use an existing (empty) project:
   `fimo migrate init <target-dir> --project-id <projectId> --framework <framework> --source-platform <platform>`
-- Create a new project in an owner-supplied organization:
-  `fimo migrate init <target-dir> --org <organizationId> --framework <framework> --source-platform <platform>`
+- Create a new project:
+  `fimo migrate init <target-dir> --framework <framework> --source-platform <platform>`,
+  adding `--org <organizationId>` when the precondition's organization rule
+  needs it.
 
 `--source-platform` names what the site is migrated from (`wordpress`, `nextjs`,
 `astro`, `react-router`, `webflow`, `framer`, `squarespace`, `wix`, `carrd`,
@@ -277,9 +291,11 @@ framework files before starting workers. A Next.js target must still have its
 Next runtime/configuration (`next.config.*` and the source router shape), not a
 React Router scaffold.
 
-Setup scaffolds the target and pushes its initial commit; that is the only
-remote write it performs — it never pushes schemas, uploads assets, or imports
-entries. Setup itself never deploys or publishes; the one new-project preview
+`fimo migrate init` on a new target scaffolds it and pushes its initial
+commit. `fimo link` and reusing a linked folder scaffold and push nothing; the
+first commit waits for `fimo deploy`. Project creation or linking and that
+initial push are the only remote writes setup performs — it never pushes
+schemas, uploads assets, or imports entries. Setup itself never deploys or publishes; the one new-project preview
 deploy happens only after successful local QA (see Completion and deployment).
 
 ## Command surface
@@ -289,20 +305,18 @@ up and nothing else: it never reads, fetches, or renders the source site, and
 it produces no evidence pack, draft, manifest, or scaffold to inspect. Reading
 the source is your job, and every finding is yours to prove.
 
-- `fimo migrate init <dir> --project-id <projectId>` — link an owner-supplied
-  project.
-- `fimo migrate init <dir> --org <organizationId>` — create a new project.
+- `fimo migrate init <dir> --project-id <projectId>` — use an existing project.
+- `fimo migrate init <dir> [--org <organizationId>]` — create a new project.
 - Both accept `--framework`, `--source-platform` (see Target setup),
   `--install` / `--no-install`, `--agents` / `-a`, `--mode`, `--template-root`,
   and `--json`; `-C <dir>` replaces the positional for an already-linked target.
 
-The link/creation and its initial commit push are the only remote writes. Data
-writes go through the normal commands against the linked target:
+Setup (`fimo migrate init` or `fimo link`, chosen in Initialized target
+precondition) makes only the remote writes listed in Target setup. Data writes
+go through the normal commands against the linked target:
 
 - `fimo schemas push`, `fimo assets upload`, `fimo entries create|update`,
   `fimo singles update`, `fimo labels set|set-many`, `fimo forms push`.
-- `fimo link`: project creation or selection plus the in-place adoption of a
-  copied source target.
 - `fimo deploy` / `fimo publish` — owner-approved only.
 
 ## Migration loop
@@ -312,7 +326,7 @@ writes go through the normal commands against the linked target:
    edit, or move environment values until the user answers every consent gate.
 2. Run the setup path from "Initialized target precondition" and inspect the
    initialized target before any worker edits it. A `fimo link` adoption keeps
-   the source framework; the `fimo init` / `fimo migrate init` paths choose the
+   the source framework; the `fimo migrate init` path chooses the
    target framework through the same canonical option as
    `fimo init`: pass the detected source framework for a source-backed
    migration, the framework the user explicitly chose for a conversion, and —
@@ -404,8 +418,8 @@ Use one final status:
 
 Never call a migration complete when CMS entries, media mappings, forms, route
 coverage, or migration-induced content-delivery regressions are unknown. Local
-QA remains the acceptance gate. If
-`fimo migrate init` created a new Fimo project, run one `fimo deploy` after QA
+QA remains the acceptance gate. If setup created a new Fimo project
+(`fimo migrate init` or `fimo link`), run one `fimo deploy` after QA
 and return its preview and dashboard links; skip it when the user said not to
 deploy or `FIMO_MIGRATION_NO_DEPLOY=1` is set. For an existing linked project,
 offer the deployment and wait for approval. Never run `fimo publish` without an

package/assets/skills/fimo-migration/references/import-contract.md

@@ -10,7 +10,7 @@ items.
 
 Every data-plane write in this contract targets the linked project from
 workflow Phase 0. Planning and payload authoring need no link; running the
-writes does. When no owner-supplied target exists, the writes stay unresolved
+writes does. When setup cannot produce a linked target, the writes stay unresolved
 owner actions; do not fake a link to make them pass.
 
 ## Media Files

package/assets/skills/fimo-migration/references/qa.md

@@ -182,6 +182,13 @@ check is the acceptance evidence.
      or imprint.
    - `links-resolve`: every internal link rendered on the inventoried routes
      points at an inventoried route or an explicitly allowed path prefix.
+   - `editable-text` (required in every inventory): every visible body text node
+     sits inside an element a Fimo primitive renders, so an editor can change it
+     in Studio. A faithful port is not editable yet: text still typed in the code
+     shows "Nothing to edit". Move it to a label or a CMS field. List in `allow`
+     only the exact text the owner keeps in code, such as a brand glyph or a
+     legal line, and record why in the migration report. Assistive and hidden
+     text does not count.
 
    Internal links are resolved against the final document URL and any
    `<base href>`; query and fragment do not change route identity. An `allow`
@@ -203,14 +210,18 @@ check is the acceptance evidence.
          "source": "<owner decision>"
        },
        { "id": "footer-privacy", "kind": "required-link", "href": "/legal/privacy", "source": "<source navigation>" },
-       { "id": "nav-resolves", "kind": "links-resolve", "allow": ["/blog"], "source": "<source navigation>" }
+       { "id": "nav-resolves", "kind": "links-resolve", "allow": ["/blog"], "source": "<source navigation>" },
+       { "id": "editable-text", "kind": "editable-text", "allow": [], "source": "Fimo: visitors' text is editable" }
      ]
    }
    ```
 
 2. The validator observes the rendered application, not files in the
-   repository. For a server-rendered target, run the check with `--base-url`
-   while the built app serves locally. For a client-rendered target, save each
+   repository, with Fimo editing metadata on: build and serve with
+   `FIMO_EDITING_METADATA=true`, or observe the dev server. Without it no text is
+   marked editable and `editable-text` fails as unmeasured. For a
+   server-rendered target, run the check with `--base-url` while the app serves
+   locally. For a client-rendered target, save each
    hydrated document from the browser pass as `<captures>/index.html` and
    `<captures>/<route>.html` and pass `--captures`. Save a JSON sidecar next to
    each HTML file, such as `index.html.json` or `legal/privacy.html.json`:

package/assets/skills/fimo-migration/references/workers/content-planner.md

@@ -5,7 +5,10 @@ handoff. Do not import entries or rewrite application consumers.
 
 1. Trace active source clients, endpoint/query declarations, frontend types,
    and every consumer before designing schemas. Then inspect their
-   content-bearing files, inline values, APIs, or CMS sources.
+   content-bearing files, inline values, APIs, or CMS sources, and the visible
+   text typed in route and component code: headings, paragraphs, buttons, link
+   and navigation text, alt and placeholder text. Each is an item, even when no
+   data source holds it.
 2. Classify each value as collection content, single content, an
    editor-visible label, or application-owned code. Repetition is evidence,
    not an automatic collection rule. Assistive text, identifiers, and values

package/assets/skills/fimo-migration/references/workers/validator.md

@@ -23,9 +23,10 @@ passed.
 Verify:
 
 - every source route renders with expected status and representative content;
-- the rendered guardrail inventory passes: brand, legal, compliance, and
-  navigation rules are proven on rendered HTML or a running local server with
-  `scripts/check-rendered-guardrails.mjs`, never by grepping target source.
+- the rendered guardrail inventory passes: brand, legal, compliance,
+  navigation, and `editable-text` rules are proven on rendered HTML or a running
+  local server with `scripts/check-rendered-guardrails.mjs`, never by grepping
+  target source. An inventory without an `editable-text` rule is incomplete.
   Browser captures include the response metadata required by `references/qa.md`;
 - schemas, entries, singles, labels, media, forms, and locales exist through
   CLI read-back;

package/assets/skills/fimo-migration/references/workers.md

@@ -62,8 +62,8 @@ other after it. Do not add a metadata format for a small overlap.
 
 ## Coordinator gates
 
-1. Run `fimo migrate init` and inspect the real target paths before workers
-   write.
+1. Pass the setup gate in SKILL.md "Initialized target precondition" and
+   inspect the real target paths before workers write.
 2. Start runtime/routes/content-planner/locales together, or the framework
    worker plus content planner/locales in conversion mode.
 3. Wait for every discovery receipt to become terminal, then perform one fan-in

package/assets/skills/fimo-migration/references/workflow.md

@@ -15,32 +15,22 @@ ask a generic optimization question.
 
 ## Phase 0: Initialize the target
 
-1. Confirm the target path. The target is a separate directory; the source
-   checkout remains read-only evidence.
-2. Initialize or reuse exactly one linked Fimo target before workers start:
-   - link an existing project: `fimo migrate init <target-dir> --project-id <projectId> --framework <framework>`
-   - create a project: `fimo migrate init <target-dir> --org <organizationId> --framework <framework>`
-   - add `--source-platform <platform>` when the source platform is known
-     (webflow, framer, squarespace, wix, carrd, wordpress, nextjs, astro,
-     react-router, other). Nothing detects it; omitting it records `unknown`.
-     Use the detected source framework for source-backed migrations. A framework
-     conversion requires an explicit user choice; URL-only and rebuild
-     migrations ask the user which framework to use. Never choose a framework by
-     copying an arbitrary `--template-root`, invent a project ID, or hand-write
-     `.fimo/project.json`.
-3. Inspect the target's real `package.json`, `.fimo/config.json`, framework config, and route
+1. Pick the setup row in SKILL.md "Initialized target precondition", run it,
+   and pass its gate before workers start. Framework and `--source-platform`
+   rules for `fimo migrate init` live in SKILL.md "Target setup".
+2. Inspect the target's real `package.json`, `.fimo/config.json`, framework config, and route
    directories. They are the authority for paths. Do not infer an app root
    from a skill example and do not create a second `app/` or `src/app/` tree.
-4. Verify dependency provenance before workers start. A project created by a
-   published CLI pins that exact CLI release and matching companion packages.
-   A local source-checkout project uses the checkout-local CLI. Stop when the
-   target records an absolute package-manager cache path, an unapproved
-   `latest`, or a CLI and API from different runtime channels; do not let the
-   producer repair release setup inside the migration.
-5. If the target is non-empty and not a Fimo project, stop and ask for a target
-   path; do not overlay a template on top of it.
-6. Keep source material in `.fimo/migration/source` or another explicit source
-   location. Do not copy source files over the initialized target root.
+3. Verify dependency provenance before workers start. The target pins the
+   CLI artifact that set it up: an exact published release with matching
+   companion packages, or the exact dev artifact from SKILL.md "CLI
+   provenance". Stop when the target records an absolute package-manager cache
+   path, a `file:` link, an unapproved `latest`, or a CLI and API from
+   different runtime channels; do not let the producer repair release setup
+   inside the migration.
+4. When `fimo migrate init` scaffolded the target, keep source material in
+   `.fimo/migration/source` or another explicit source location. Do not copy
+   source files over the scaffolded target root.
 
 Write a short `.fimo/migration/migration-plan.md` containing the source
 location, selected framework, actual target directories, worker owners, and

package/assets/skills/fimo-migration/scripts/check-rendered-guardrails.mjs

@@ -26,7 +26,7 @@ const USAGE =
   'Usage: node check-rendered-guardrails.mjs [project-root] [--inventory .fimo/migration/guardrails.json] ' +
   '(--captures <dir> | --base-url <http://localhost:port>) [--output .fimo/migration/guardrails-report.md]';
 
-const RULE_KINDS = ['required-text', 'forbidden-text', 'required-link', 'links-resolve'];
+const RULE_KINDS = ['required-text', 'forbidden-text', 'required-link', 'links-resolve', 'editable-text'];
 
 async function main() {
   const args = parseArgs(process.argv.slice(2));
@@ -318,6 +318,8 @@ function evaluateRules(inventory, observations) {
         return linkRule(rule, observed);
       case 'links-resolve':
         return linksResolveRule(rule, inventory, observed);
+      case 'editable-text':
+        return editableTextRule(rule, observed);
       default:
         return result(rule, false, observed.length, [`unknown rule kind ${rule.kind}`]);
     }
@@ -382,6 +384,105 @@ function linksResolveRule(rule, inventory, observed) {
   return result(rule, failures.length === 0, observed.length, failures, `${internal.length} internal links`);
 }
 
+// FIMO-3141: text a visitor reads that no Fimo primitive renders shows "Nothing to edit" in Studio, so a faithful
+// port is not done until each such text node is a label, a CMS field, or an `allow` entry the owner accepts in code
+// (a brand glyph, a legal line). Fimo marks editable text only when editing metadata is on (the dev server, or a
+// build with FIMO_EDITING_METADATA=true); a route with no mark at all is unmeasured, never passed.
+/** @param {Rule} rule @param {Observation[]} observed */
+function editableTextRule(rule, observed) {
+  const allow = new Set(asArray(rule.allow).filter(isNonEmptyString).map(normalizeText));
+  const failures = [];
+  let editable = 0;
+  let typed = 0;
+  let unmarked = 0;
+  for (const item of observed) {
+    const nodes = textNodes(item.html ?? '');
+    // A route with no mark at all is a site with no label or CMS text yet, or editing metadata that is off: its text
+    // is still listed, so a reviewer sees what would move, and the route never counts as measured.
+    if (!nodes.marked) {
+      unmarked += 1;
+      failures.push(
+        `no Fimo-marked text on ${item.route}: the site renders no label or CMS text yet, or editing metadata is off (capture the dev server or a build with FIMO_EDITING_METADATA=true)`
+      );
+    }
+    editable += nodes.editable;
+    for (const text of uniqueArray(nodes.typed)) {
+      if (allow.has(normalizeText(text))) continue;
+      typed += 1;
+      failures.push(`"${text}" on ${item.route} is typed in the code`);
+    }
+  }
+  const summary = `${editable} editable, ${typed} typed in the code${unmarked > 0 ? `, ${unmarked} routes with no Fimo mark` : ''}`;
+  return result(rule, failures.length === 0, observed.length, failures, summary);
+}
+
+const VOID_ELEMENTS = new Set([
+  'area',
+  'base',
+  'br',
+  'col',
+  'embed',
+  'hr',
+  'img',
+  'input',
+  'link',
+  'meta',
+  'param',
+  'source',
+  'track',
+  'wbr',
+]);
+
+// Body text nodes with at least two letters: those inside an element Fimo marks (`data-fimo-source`,
+// `data-fimo-richtext`) are editable; the rest are typed in the code. Assistive and hidden text is skipped: it is
+// not a label (see references/decision.md).
+/** @param {string} html @returns {{marked: boolean, editable: number, typed: string[]}} */
+function textNodes(html) {
+  const cleaned = html
+    .replace(/<!--[\s\S]*?-->/g, ' ')
+    .replace(/<[!?][^>]*>/g, ' ')
+    .replace(/<(script|style|noscript|template|head)\b[^>]*>[\s\S]*?<\/\1\s*>/gi, ' ');
+  const marked = /\sdata-fimo-(?:source|richtext)\b/i.test(cleaned);
+  /** @type {{tag: string, editable: boolean, hidden: boolean}[]} */
+  const stack = [];
+  let editable = 0;
+  /** @type {string[]} */
+  const typed = [];
+  for (const match of cleaned.matchAll(/<(\/?)([a-zA-Z][\w:-]*)([^>]*)>|([^<]+)/g)) {
+    const [, closing, rawTag, attributes = '', text] = match;
+    const parent = stack.at(-1);
+    if (text !== undefined) {
+      const value = normalizeText(decodeEntities(text));
+      if (parent?.hidden || (value.match(/\p{L}/gu) ?? []).length < 2) continue;
+      if (parent?.editable) editable += 1;
+      else typed.push(value);
+      continue;
+    }
+    const tag = rawTag.toLowerCase();
+    if (closing) {
+      const index = stack.map((entry) => entry.tag).lastIndexOf(tag);
+      if (index !== -1) stack.length = index;
+      continue;
+    }
+    if (VOID_ELEMENTS.has(tag) || attributes.trim().endsWith('/')) continue;
+    stack.push({
+      tag,
+      editable: Boolean(parent?.editable) || /\sdata-fimo-(?:source|richtext)\b/i.test(attributes),
+      hidden:
+        Boolean(parent?.hidden) ||
+        /\shidden\b/i.test(attributes.replace(/=\s*(?:"[^"]*"|'[^']*')/g, '')) ||
+        /\saria-hidden\s*=\s*["']?true\b/i.test(attributes) ||
+        /\sclass\s*=\s*["'][^"']*\b(?:sr-only|visually-hidden)\b/i.test(attributes),
+    });
+  }
+  return { marked, editable, typed };
+}
+
+/** @param {string} value */
+function normalizeText(value) {
+  return value.replace(/\s+/g, ' ').trim();
+}
+
 /** @param {Rule} rule @param {boolean} passed @param {number} observed @param {string[]} failures @param {string} [extra] @returns {Result} */
 function result(rule, passed, observed, failures, extra) {
   return { id: rule.id, kind: rule.kind, passed, observed, failures, extra: extra ?? null };

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

@@ -24,7 +24,7 @@ The **Compliance** default runs three routines backed by Studio's built-in `fimo
 
 ### Routines
 
-A routine is saved instructions an agent runs in a thread of its own, by hand, on a schedule, or when something happens in the project, so each run sees its earlier runs and the agent's chat never fills with its work. The agent creates, changes, runs and deletes its routines from its chat with its `routines` tool: a person asks in the chat ("check the prices every Monday", "run after each publish"), and Studio only shows routines. A trigger is set in words; Fimo checks them and either says when the routine runs or why it cannot follow them and what it can do instead; for what Fimo cannot see as an event (traffic, rankings, errors) the agent offers a schedule whose run checks it and stops when there is nothing to do. Fimo follows publishes of the site (or only its first publish) and content changes on the main branch by content type, action, locale, changed fields, the entry's current values ("price over 100", "status changes to archived") or a yes/no question about what the content says ("mentions Contentful or Sanity"; for "a competitor" it uses the names given or those in the site knowledge, and asks for them otherwise; a run started on an uncertain answer says so), media files uploaded or changed (by name or file type), the site's code changing through a deploy or a merge (by file path glob, or a yes/no question about the changed files such as "a page was added"), another routine of the same agent finishing (optionally with a yes/no question about its report; never its own end), a visitor submitting a form (optionally with a yes/no question about the answers), a form or content type changing, a branch merged into main, a locale added, removed or made the default, a publish of the site failing, a domain added or removed, and the prices on a page of another web site changing ("tell me when https://example.com/pricing changes its prices": checked daily, a change must hold on three reads before the routine runs, the run lists each plan with its old and new price, the routine page shows the watch as **OK**, **Needs repair**, **Blocked** or **Unstable** with its last check, at most 10 watched pages a project); comparing a field's old and new values is not supported; what a routine changes, publishes or reports can start the agent's other routines, in chains of any length, each routine at most once per change that started the chain (across every routine that change leads to, so routines never loop or multiply; a person's new change, a run by hand or on a schedule starts a new chain); events that come in while a run is busy wait, then run together in one next run (up to 10), which the Runs list shows as one run with its event count; the agent can also make a routine's event runs wait until the changes stop for a set number of minutes (at most 2 hours from the first), then read them all in one run (a yes/no question is then answered once for all the waiting changes, each entry once in its latest version; a waiting change it says no to leaves the queue, and when it says no to all of them no run starts); the default routines that read what changed (Meta tags, Image SEO, Internal linking, Structured data, AI citation optimization, Content lifecycle, Translation, Accessibility, Mobile optimization, Brand compliance) wait 10 minutes after the last change, and those that guard the live site (Technical SEO, Broken links, Hreflang, AI readiness, Cookie consent, Privacy and legal pages) run at once. The agent's settings list its **Routines** as cards (name, when it runs such as its event trigger's title, **Every Monday at 08:00** or **By hand**, next run, an **Active** switch); the default agents come with theirs (a new project's defaults wake on changes from five minutes after it is created, so its first push and seed start no run). A routine's page is read-only: **What it does** (one or two plain sentences the agent writes with the routine, Fimo's for a default routine), with **Instructions** folded under it (the task, run on every trigger; a routine created before descriptions shows only its **Instructions**), **Model** (the model its runs use: Opus 5.5 by default, while most default routines run on Claude Haiku 5.5 or Claude Sonnet 5.5; the agent sets another when asked), **Triggers** (**By hand** with **Run now**, which starts a run right away; **Schedule** and the event trigger, given a short title by Fimo from the words it was set with and showing those words, shown when set), the **Runs** list (newest first, two lines each: how it ended (**Quiet**, **Sent to agent**, **Asked for a decision**, or **Failed** and **Stopped** in red), when and what started it (**On schedule**, **On event**, or **By hand** with the person's name or **agent** when their message started it), then the first sentence of what it told the agent; select one to open the routine's thread, read-only, at that run), and the **Active** switch in the header (pauses the schedule and the trigger, not **Run now**). Routines report to the agent, never to a person: a run that has something the agent should know writes it to the agent's chat as a message only the agent reads, and the agent takes a turn on it (reports waiting together are read in one turn); a run with nothing to say reports nothing. The agent decides what the team sees: nothing (the chat stays as it was, the row stays read), one short message (several reports folded into one), or a form when a person must decide, and the chat's row reads **Needs you** while that form is open. A person answers the form in the chat; the agent sends the decision to the routine with its `routines` tool and the routine runs again with it. Only the agent answers a routine: its page has no answer box. Quiet runs leave no message: they fold into one line placed where the last run happened among the messages (**N runs since <date>**), counted from the last report the agent answered visibly, and the chat's row reads **Ran <date>** with that count while the newest thing in the chat is a run, the ordinary status and the last words when a message is newer, and **First check <day> <time>** or **No checks scheduled** before the first run. A routine whose runs keep failing or are refused for credits is reported to the agent once per streak, as a message from Fimo. Routine runs use the plan's agent-hours, from each run's start to its end (Studio chats do not); Billing shows the hours used this period, and each run shows its duration and credits. Once the included hours are used, nothing runs (no schedule, event or Run now, which the routines tool reports to the agent); Studio shows **Routines paused** under the chat list and in the agent's settings with the reset date and the button that resumes them sooner (**Upgrade**), and the routine's page says until when. No run lasts longer than 2 hours.
+A routine is saved instructions an agent runs in a thread of its own, by hand, on a schedule, or when something happens in the project, so each run sees its earlier runs and the agent's chat never fills with its work. The agent creates, changes, runs and deletes its routines from its chat with its `routines` tool: a person asks in the chat ("check the prices every Monday", "run after each publish"), and Studio only shows routines. A trigger is set in words; Fimo checks them and either says when the routine runs or why it cannot follow them and what it can do instead; for what Fimo cannot see as an event (traffic, rankings, errors) the agent offers a schedule whose run checks it and stops when there is nothing to do. Fimo follows publishes of the site (or only its first publish) and content changes on the main branch by content type, action, locale, changed fields, the entry's current values ("price over 100", "status changes to archived") or a yes/no question about what the content says ("mentions Contentful or Sanity"; for "a competitor" it uses the names given or those in the site knowledge, and asks for them otherwise; a run started on an uncertain answer says so), media files uploaded or changed (by name or file type), the site's code changing through a deploy or a merge (by file path glob, or a yes/no question about the changed files such as "a page was added"), another routine of the same agent finishing (optionally with a yes/no question about its report; never its own end), a visitor submitting a form (optionally with a yes/no question about the answers), a form or content type changing, a branch merged into main, a locale added, removed or made the default, a publish of the site failing, a domain added or removed, and the prices on a page of another web site changing ("tell me when https://example.com/pricing changes its prices": checked daily, a change must hold on three reads before the routine runs, the run lists each plan with its old and new price, the routine page shows the watch as **OK**, **Needs repair**, **Blocked** or **Unstable** with its last check, at most 10 watched pages a project); comparing a field's old and new values is not supported; what a routine changes, publishes or reports can start the agent's other routines, in chains of any length, each routine at most once per change that started the chain (across every routine that change leads to, so routines never loop or multiply; a person's new change, a run by hand or on a schedule starts a new chain); events that come in while a run is busy wait, then run together in one next run, which the Runs list shows as one run with its event count (a very large burst, such as a bulk import, runs in several runs, in order); the agent can also make a routine's event runs wait until the changes stop for a set number of minutes (at most 2 hours from the first), then read them all in one run (a yes/no question is then answered once for all the waiting changes, each entry once in its latest version; a waiting change it says no to leaves the queue, and when it says no to all of them no run starts); the default routines that read what changed (Technical SEO, Meta tags, Image SEO, Internal linking, AI readiness, Structured data, AI citation optimization, Content lifecycle, Translation, Accessibility, Mobile optimization, Brand compliance) wait 10 minutes after the last change, and those that guard the live site (Broken links, Hreflang, Cookie consent, Privacy and legal pages) run at once. The agent's settings list its **Routines** as cards (name, when it runs such as its event trigger's title, **Every Monday at 08:00** or **By hand**, next run, an **Active** switch); the default agents come with theirs (a new project's defaults wake on changes from five minutes after it is created, so its first push and seed start no run). A routine's page is read-only: **What it does** (one or two plain sentences the agent writes with the routine, Fimo's for a default routine), with **Instructions** folded under it (the task, run on every trigger; a routine created before descriptions shows only its **Instructions**), **Model** (the model its runs use: Opus 5.5 by default, while most default routines run on Claude Haiku 5.5 or Claude Sonnet 5.5; the agent sets another when asked), **Triggers** (**By hand** with **Run now**, which starts a run right away; **Schedule** and the event trigger, given a short title by Fimo from the words it was set with and showing those words, shown when set), the **Runs** list (newest first, two lines each: how it ended (**Quiet**, **Sent to agent**, **Asked for a decision**, or **Failed** and **Stopped** in red), when and what started it (**On schedule**, **On event**, or **By hand** with the person's name or **agent** when their message started it), then the first sentence of what it told the agent; select one to open the routine's thread, read-only, at that run), and the **Active** switch in the header (pauses the schedule and the trigger, not **Run now**). Routines report to the agent, never to a person: a run that has something the agent should know writes it to the agent's chat as a message only the agent reads, and the agent takes a turn on it (reports waiting together are read in one turn); a run with nothing to say reports nothing. The agent decides what the team sees: nothing (the chat stays as it was, the row stays read), one short message (several reports folded into one), or a form when a person must decide, and the chat's row reads **Needs you** while that form is open. A person answers the form in the chat; the agent sends the decision to the routine with its `routines` tool and the routine runs again with it. Only the agent answers a routine: its page has no answer box. Quiet runs leave no message: they fold into one line placed where the last run happened among the messages (**N runs since <date>**), counted from the last report the agent answered visibly, and the chat's row reads **Ran <date>** with that count while the newest thing in the chat is a run, the ordinary status and the last words when a message is newer, and **First check <day> <time>** or **No checks scheduled** before the first run. A routine whose runs keep failing or are refused for credits is reported to the agent once per streak, as a message from Fimo. Routine runs use the plan's agent-hours, from each run's start to its end (Studio chats do not); Billing shows the hours used this period, and each run shows its duration and credits. Once the included hours are used, nothing runs (no schedule, event or Run now, which the routines tool reports to the agent); Studio shows **Routines paused** under the chat list and in the agent's settings with the reset date and the button that resumes them sooner (**Upgrade**), and the routine's page says until when. No run lasts longer than 2 hours.
 
 ## Sending a Message
 

package/dist/cli/bundle.json

@@ -1,7 +1,7 @@
 {
   "bundled": true,
   "bundler": "esbuild",
-  "bundledAt": "2026-10-23T17:25:43.853Z",
+  "bundledAt": "2026-10-25T09:02:35.843Z",
   "cliVersion": "2.9.0",
   "external": [
     "oxc-parser",