fimo 2.3.0-staging.2 → 2.3.1-staging.1

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

@@ -13,7 +13,7 @@ Never remove `isSingleton: true` merely because `fimo entries create` rejects th
 
 ## Flow
 
-1. Write `src/schemas/{Uid}.json` — PascalCase filename (e.g. `BlogPost.json`). Run `fimo skills get fimo-code --ref content/schema` for the JSON contract.
+1. Write `src/schemas/{Uid}.json` — PascalCase filename (e.g. `BlogPost.json`). Run `fimo skills get fimo-code --ref content/schema` to decide what becomes editor-managed content (Single, collection, blocks, references, labels, or `json`) and for the JSON contract.
 2. Run `fimo schemas push {Uid}`. It registers the schema and generates the framework-specific public modules. It does not run whole-project validation.
 3. App code imports generated public modules, never `.types.ts` directly. Load the detected framework reference before choosing server modules, client modules, hooks, or a registry.
 4. Seed collections via `fimo entries create`, or update one-off content via `fimo singles update`. Generate cover images first with `fimo image generate` if needed (see `media.md` / `assets.md`).

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

@@ -55,8 +55,7 @@ fimo integrations enable firecrawl --connection client-a
 
 Bare enable uses the integration's default auth path. For Firecrawl, that is "Use Fimo credits".
 
-If an integration has no safe default auth path, bare enable should stop with a repair command instead of guessing. OAuth
-integrations point to `fimo integrations connect <integration>`. API-key integrations point to
+If an integration has no safe default auth path, bare enable should stop with a repair command instead of guessing. API-key integrations point to
 `fimo integrations connect <integration> --name <name> --token-stdin`, then
 `fimo integrations enable <integration> --connection <name>`.
 
@@ -76,13 +75,14 @@ There is no silent fallback. If a project is enabled with a named API-key connec
 ## Connections
 
 ```bash
-fimo integrations connect slack
 fimo integrations connect firecrawl --name client-a --token-stdin
 fimo integrations enable firecrawl --connection client-a
 ```
 
 Use `connect` for provider accounts, workspaces, OAuth installs, and API-key accounts. Connections live at the organization level and are shared as capabilities, not as visible credentials. A project chooses one by enabling the integration with `--connection <alias>`.
 
+Set up Slack from **Project Settings > Connections** in Fimo Studio. Slack app creation and workspace approval require an explicit organization app choice, so the CLI does not guess one.
+
 ## Run
 
 ```bash

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

@@ -23,6 +23,18 @@ Write one schema per `src/schemas/<Uid>.json`. The PascalCase filename must matc
 
 Required root keys: `uid`, `name`, and `fields`.
 
+## Model what editors manage
+
+Design schemas around what content editors need to see and change in Fimo Studio.
+
+- Use clear, editor-facing names for Singles, collections, fields, blocks, and groups. For example, use `heroHeading` instead of `H1`, and `Testimonial` with the name `Testimonials`. Order and group fields the way editors work through the form.
+- Use labels for small standalone interface copy. Use schemas when content has structure, media, or repeated records.
+- Use a Single for one shared document such as site settings or navigation. Set `isSingleton` at the schema root: `{ "uid": "HomePage", "name": "Homepage", "isSingleton": true, "fields": {} }`. Use a collection for independent records such as posts, products, or team members.
+- Prefer structured fields: `richtext` for formatted prose, `blocks` for repeatable sections, `reference` for shared records, and `media` for assets.
+- Avoid `json` for editor-managed content. Use it only for opaque data that editors do not need to understand or edit.
+
+Keep routing, layout, computed values, and external system data in code. Load `fimo-cli/references/content.md` for the Single and collection write workflows.
+
 ## Group fields in Studio
 
 Use optional top-level `groups` when an entry has meaningful editing areas, such as Overview, Tickets, SEO, or Scheduling. They work best for longer forms where editors regularly work on one area at a time. Usually skip groups for short forms, one-field groups, or vague buckets such as General and Other. Prefer two to five groups organized around editor tasks. This is guidance, not a schema limit.
@@ -46,19 +58,6 @@ Assign each top-level field with `group`; one field may appear in more than one
 
 Group IDs must be unique, at most one group may be the default, and memberships must reference a declared group. Only top-level fields can be grouped; fields inside blocks cannot declare `group`.
 
-Use `"isSingleton": true` whenever the site has exactly one logical document: a homepage, site settings, an About page, or one campaign landing page. Do not turn it into a one-entry collection just to seed content; keep the Single and load `fimo-cli/references/content.md` for the `fimo singles update` workflow.
-
-```json
-{
-  "uid": "HomePage",
-  "name": "Homepage",
-  "isSingleton": true,
-  "fields": {
-    "title": { "type": "string", "required": true }
-  }
-}
-```
-
 ## Locale policy
 
 - Omit `i18n` or use `{ "enabled": true }` for localized variants.

package/dist/cli/bundle.json

@@ -1,8 +1,8 @@
 {
   "bundled": true,
   "bundler": "esbuild",
-  "bundledAt": "2026-09-02T16:54:02.222Z",
-  "cliVersion": "2.2.1",
+  "bundledAt": "2026-09-03T08:31:37.703Z",
+  "cliVersion": "2.3.0",
   "external": [
     "oxc-parser",
     "fsevents",