fimo 0.10.0 → 0.10.1-staging.2
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/assets/skills/fimo-cli/SKILL.md +3 -1
- package/assets/skills/fimo-cli/references/content.md +25 -6
- package/assets/skills/fimo-cli/references/history.md +40 -0
- package/assets/skills/fimo-cli/references/schedules.md +45 -22
- package/assets/skills/fimo-code/references/content.md +1 -1
- package/assets/skills/fimo-studio/SKILL.md +4 -2
- package/assets/skills/fimo-studio/references/cms.md +8 -8
- package/assets/skills/fimo-studio/references/schedules.md +43 -0
- package/assets/skills/fimo-studio/references/version-history.md +9 -9
- package/dist/build/vite/plugins/translations.js +176 -58
- package/dist/cli/bundle.json +1 -1
- package/dist/cli/index.js +80 -67
- package/dist/runtime/content/client/createContentClient.js +1 -1
- package/package.json +2 -1
- package/release.json +2 -2
- package/templates/react-router/package.json +1 -1
|
@@ -5,7 +5,7 @@ description: >-
|
|
|
5
5
|
Load when the user wants to create a new Fimo project, build content
|
|
6
6
|
(schemas, entries, forms, media, labels/locales), deploy a site, manage
|
|
7
7
|
custom domains, configure outbound webhooks and event-driven integrations,
|
|
8
|
-
check site traffic/analytics, invite collaborators, inspect AI credits,
|
|
8
|
+
check site traffic/analytics, inspect or restore project history, invite collaborators, inspect AI credits,
|
|
9
9
|
report a failing or slow Fimo API, rejected documented argument,
|
|
10
10
|
undocumented workaround, missing capability that blocks work, forces a
|
|
11
11
|
fragile or heavily manual workaround, or would materially accelerate a
|
|
@@ -62,6 +62,7 @@ npx fimo@latest clone # interactively choose an existin
|
|
|
62
62
|
cd my-site # then load skills on demand: npx fimo@latest skills get fimo-code
|
|
63
63
|
pnpm dev # run the app locally (use the project's PM: pnpm/npm run/yarn/bun) — your iteration loop
|
|
64
64
|
npx fimo@latest credits # inspect the owning org's AI credit balance (read-only)
|
|
65
|
+
npx fimo@latest history list # inspect this environment's restore points
|
|
65
66
|
npx fimo@latest validate # run all checks + codegen; fails on missing DB labels
|
|
66
67
|
npx fimo@latest deploy # ON-DEMAND: hosted preview / shareable link (runs validate internally)
|
|
67
68
|
npx fimo@latest deploy --publish # ON-DEMAND: publish live (only when the developer says "ship it")
|
|
@@ -92,6 +93,7 @@ Load the matching reference when the user's request fires its trigger. Recipes t
|
|
|
92
93
|
- "Enable provider tools / integrations / API key connection for a provider / agent integration access" → `references/integrations.md`
|
|
93
94
|
- "Firecrawl / scrape a public website / competitor research / agent web research" → `references/integrations.md` **+ load `references/integrations/firecrawl.md`**
|
|
94
95
|
- "Check credits / credit balance / can I keep using AI / billing credits / running low / how many credits are left" → `references/credits.md`
|
|
96
|
+
- "List history / create a restore point / recover content and code / restore a previous version / snapshot usage or retention" → `references/history.md`
|
|
95
97
|
- "Create a branch / feature environment / new env / switch envs / merge envs / diff two envs / env status / what changed on this branch / sync from parent / cut a release / tag a version / go to prod" → `references/branches.md`
|
|
96
98
|
- "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`
|
|
97
99
|
- "Migrate an existing Webflow / Framer / Squarespace / Wix / Carrd site from only a published URL" → load the `fimo-migration` skill and start with `fimo migrate <url> [dir]` to prepare the agent-ready migration draft
|
|
@@ -1,17 +1,17 @@
|
|
|
1
|
-
# Content workflow (schemas + entries)
|
|
1
|
+
# Content workflow (schemas + Singles + entries)
|
|
2
2
|
|
|
3
3
|
> **Run via `npx fimo@latest <command>`** — always the latest CLI, no install needed.
|
|
4
4
|
|
|
5
5
|
> For the JSON shape, field types, Tiptap node spec, slug rules, and generated React Query hooks — these are package surface (version-locked to the project's `fimo`). See **`fimo/references/content.md`**.
|
|
6
6
|
|
|
7
|
-
This file covers the **CLI workflow** for content. Use it when the user wants to add a content type (blog, products, pages) or
|
|
7
|
+
This file covers the **CLI workflow** for content. Use it when the user wants to add a content type (blog, products, pages) or manage Singles and entries.
|
|
8
8
|
|
|
9
9
|
## Flow
|
|
10
10
|
|
|
11
11
|
1. Write `src/schemas/{Uid}.json` — PascalCase filename (e.g. `BlogPost.json`). For the JSON shape and field types, load `fimo/references/content.md`.
|
|
12
12
|
2. Run `fimo schemas push {Uid}`. It generates `src/schemas/{Uid}.types.ts` and `src/schemas/{Uid}.ts`, then registers the schema with Fimo. It does not run whole-project validation.
|
|
13
13
|
3. App code imports the generated client from `@/schemas/{Uid}`, not from `.types.ts` directly. See `fimo/references/content.md` for the hook API.
|
|
14
|
-
4. Seed
|
|
14
|
+
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`).
|
|
15
15
|
5. Write React pages that import from `@/schemas/{Uid}` and render with `fimo/ui` components.
|
|
16
16
|
|
|
17
17
|
Steps 1, 3, and 5 reference the `fimo-code` skill (`npx fimo@latest skills get fimo-code`) for shape and React API. Steps 2 and 4 are CLI commands documented here.
|
|
@@ -34,7 +34,26 @@ The command is `fimo schemas` (plural). There is no singular `fimo schema` alias
|
|
|
34
34
|
|
|
35
35
|
All commands accept `-C, --cwd <dir>` to point at a different project directory.
|
|
36
36
|
|
|
37
|
-
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-
|
|
37
|
+
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.
|
|
38
|
+
|
|
39
|
+
## Singles CLI commands
|
|
40
|
+
|
|
41
|
+
Use Singles for one-off content such as a homepage, site settings, or an About story. The type name identifies the content, so these commands do not take an entry ID.
|
|
42
|
+
|
|
43
|
+
```bash
|
|
44
|
+
fimo singles get <TypeName> [--locale es] [--populate FIELDS]
|
|
45
|
+
fimo singles update <TypeName> [--locale es] (--body '<json>' | --file <path> | --stdin)
|
|
46
|
+
```
|
|
47
|
+
|
|
48
|
+
The update payload uses the regular `{ "data": { ... } }` content body. Pass exactly one input source:
|
|
49
|
+
|
|
50
|
+
```bash
|
|
51
|
+
fimo singles update Story --body '{"data":{"title":"Our story"}}'
|
|
52
|
+
fimo singles update Story --file story-body.json
|
|
53
|
+
cat story-body.json | fimo singles update Story --stdin
|
|
54
|
+
```
|
|
55
|
+
|
|
56
|
+
The first update creates the Single's content; later updates change it. Use `--locale` for localized variants.
|
|
38
57
|
|
|
39
58
|
## Entries CLI commands
|
|
40
59
|
|
|
@@ -232,7 +251,7 @@ Rules:
|
|
|
232
251
|
|
|
233
252
|
Turning an existing field shared is destructive when the languages currently hold different values. The push collapses each document to its default-locale value and discards the others; there is no prompt and no undo. Most documents already agree, so most collapses change nothing — but tell the user what will happen before adding `"i18n": false` to a field that already holds content, and check whether the languages differ if you are unsure.
|
|
234
253
|
|
|
235
|
-
Use `"isSingleton": true` for a
|
|
254
|
+
Use `"isSingleton": true` for a Single with exactly one set of content. Generated Single clients expose `get`/`update` and their React Query hooks, not collection create/remove APIs.
|
|
236
255
|
|
|
237
256
|
## "Add a blog" recipe
|
|
238
257
|
|
|
@@ -261,4 +280,4 @@ fimo scripts sync-schemas # regenerate src/schemas/*.types.ts and src/schem
|
|
|
261
280
|
|
|
262
281
|
## Non-interactive use
|
|
263
282
|
|
|
264
|
-
All `fimo schemas
|
|
283
|
+
All `fimo schemas *`, `fimo singles *`, and `fimo entries *` commands run non-interactively without extra flags (they don't prompt). Just pass the arguments documented above.
|
|
@@ -0,0 +1,40 @@
|
|
|
1
|
+
# Project History
|
|
2
|
+
|
|
3
|
+
> **Run via `npx fimo@latest <command>`** — always the latest CLI, no install needed.
|
|
4
|
+
|
|
5
|
+
History is scoped to the selected project environment. A restore point records the environment's CMS content and the matching Git commit so code and content can be recovered together.
|
|
6
|
+
|
|
7
|
+
```bash
|
|
8
|
+
fimo history list
|
|
9
|
+
fimo history show <version-id>
|
|
10
|
+
fimo history create "Before content migration"
|
|
11
|
+
fimo history restore <version-id>
|
|
12
|
+
```
|
|
13
|
+
|
|
14
|
+
Use the global `--env <name>` option to target a different environment. Use `--project <id>` when there is no local `.fimo.settings.json`.
|
|
15
|
+
|
|
16
|
+
## Pagination and usage
|
|
17
|
+
|
|
18
|
+
`fimo history list` returns 20 restore points by default. Use `--limit <1-100>` to change the page size. When another page exists, the output includes the exact next command and its opaque cursor:
|
|
19
|
+
|
|
20
|
+
```bash
|
|
21
|
+
fimo history list --limit 20 --cursor <cursor>
|
|
22
|
+
```
|
|
23
|
+
|
|
24
|
+
The list also reports compressed snapshot usage and the current retention period. Restore points expire after 14 days on Free and pay-as-you-go plans, or 90 days on Premium. The expiry is fixed when each point is created.
|
|
25
|
+
|
|
26
|
+
## Restore safety
|
|
27
|
+
|
|
28
|
+
Before replacing code and content, Fimo creates an automatic `restore-safety` point from the environment's current state. Restoring that point is the fast recovery path when the selected result is not what the user expected.
|
|
29
|
+
|
|
30
|
+
Pretty mode asks for confirmation. Agents and other non-interactive callers must pass both `--json` and `--yes`:
|
|
31
|
+
|
|
32
|
+
```bash
|
|
33
|
+
fimo --json history restore <version-id> --yes
|
|
34
|
+
```
|
|
35
|
+
|
|
36
|
+
If another history create, update, delete, or restore is already running, the command fails with `HISTORY_BUSY`. Retry after the active history operation finishes. Do not loop without a delay.
|
|
37
|
+
|
|
38
|
+
If content or Git restore does not finish cleanly, the command fails with `RESTORE_INCOMPLETE` and names the automatic safety point. Stop active editing, inspect the environment, and retry the restore. Collaborative-editor resync continues in the background after code and content are ready.
|
|
39
|
+
|
|
40
|
+
Normal CMS edits, Git pushes, and unsaved collaborative-editor changes do not take the history-operation lock. Avoid starting a restore while someone is actively editing the same environment.
|
|
@@ -1,48 +1,71 @@
|
|
|
1
1
|
# Scheduled Commands
|
|
2
2
|
|
|
3
|
-
> **Run via `npx fimo@latest <command>`**
|
|
3
|
+
> **Run via `npx fimo@latest <command>`** - always the latest CLI, no install needed.
|
|
4
4
|
|
|
5
|
-
`fimo schedules` manages recurring commands for
|
|
5
|
+
`fimo schedules` manages recurring commands for one project environment. It uses the current checkout environment by default, or the environment passed with `--env <name>`.
|
|
6
|
+
|
|
7
|
+
The command starts in that environment's sandbox. Commands can still target another environment explicitly, for example with `fimo schemas list --env preview`.
|
|
6
8
|
|
|
7
9
|
## Commands
|
|
8
10
|
|
|
9
11
|
```bash
|
|
10
|
-
fimo schedules create <name> --cron "0 2 * * *" --do "fimo
|
|
11
|
-
fimo schedules create
|
|
12
|
+
fimo schedules create <name> --cron "0 2 * * *" --do "fimo validate"
|
|
13
|
+
fimo schedules create <name> --cron "0 2 * * *" --do "pnpm sync" --secret CMS_TOKEN --secret SEARCH_KEY
|
|
12
14
|
fimo schedules list
|
|
13
|
-
fimo schedules
|
|
14
|
-
fimo schedules
|
|
15
|
+
fimo schedules show <schedule>
|
|
16
|
+
fimo schedules update <schedule> --cron "0 3 * * *" --secret CMS_TOKEN
|
|
17
|
+
fimo schedules update <schedule> --clear-secrets
|
|
18
|
+
fimo schedules pause <schedule>
|
|
19
|
+
fimo schedules resume <schedule>
|
|
20
|
+
fimo schedules run <schedule>
|
|
21
|
+
fimo schedules run <schedule> --no-wait
|
|
22
|
+
fimo schedules runs <schedule> --limit 25 --status failed
|
|
23
|
+
fimo schedules runs <schedule> --all
|
|
24
|
+
fimo schedules runs show <run-id>
|
|
25
|
+
fimo schedules delete <schedule>
|
|
15
26
|
```
|
|
16
27
|
|
|
17
|
-
|
|
28
|
+
`<schedule>` accepts a schedule ID or an exact schedule name. Name-based commands resolve the name in the active environment and then use the stable schedule ID.
|
|
29
|
+
|
|
30
|
+
## Runtime model
|
|
31
|
+
|
|
32
|
+
Scheduled commands run in the project's environment runtime, not on the user's machine. Fimo prepares the environment and executes the stored command from the project root.
|
|
18
33
|
|
|
19
|
-
|
|
34
|
+
`--do` can be any command that works with schedule runtime permissions, such as `fimo validate`, `pnpm test`, or a project script. The runtime can edit project content and publish or unpublish the project, but it cannot manage project access, secrets, schedules, or other project-level settings.
|
|
20
35
|
|
|
21
|
-
|
|
36
|
+
Runs use at-least-once delivery. If Fimo loses a completion response, the same run may execute again. Side-effecting commands should use `FIMO_SCHEDULE_RUN_ID` as their idempotency key.
|
|
22
37
|
|
|
23
38
|
Cron expressions use standard five-field syntax. Schedules must not run more often than every five minutes.
|
|
24
39
|
|
|
25
|
-
##
|
|
40
|
+
## Project secrets
|
|
26
41
|
|
|
27
|
-
|
|
42
|
+
Repeat `--secret KEY` to expose selected project secrets to a scheduled command. Creating a schedule without `--secret` exposes no project secrets. Updating with one or more `--secret` flags replaces the selected key names. Use `--clear-secrets` to remove every selected key; it cannot be combined with `--secret`.
|
|
28
43
|
|
|
29
|
-
|
|
30
|
-
fimo schedules create nightly --cron "0 2 * * *" --do "fimo publish"
|
|
31
|
-
```
|
|
44
|
+
Schedule and run output shows secret key names and snapshot state only. It never returns secret values.
|
|
32
45
|
|
|
33
|
-
|
|
46
|
+
## Runs
|
|
34
47
|
|
|
35
|
-
|
|
36
|
-
|
|
37
|
-
|
|
48
|
+
`fimo schedules run` queues a manual run, prints its run ID, and waits for the run to finish. Use `--no-wait` to return as soon as it is queued.
|
|
49
|
+
|
|
50
|
+
Only one run for a schedule can be active at a time. If a run is already queued or running, the command returns `run_in_progress` with the active run ID.
|
|
38
51
|
|
|
39
|
-
|
|
52
|
+
Run history is cursor-paginated:
|
|
40
53
|
|
|
41
54
|
```bash
|
|
42
|
-
fimo schedules
|
|
55
|
+
fimo schedules runs nightly --limit 50
|
|
56
|
+
fimo schedules runs nightly --cursor <cursor>
|
|
57
|
+
fimo schedules runs nightly --status succeeded
|
|
58
|
+
fimo schedules runs nightly --all
|
|
43
59
|
```
|
|
44
60
|
|
|
61
|
+
Run detail includes status, timing, trigger, exit/error information, retained output, output retention metadata, and secret snapshot metadata. Output is capped and redacted before it is returned.
|
|
62
|
+
|
|
63
|
+
## JSON
|
|
64
|
+
|
|
65
|
+
All schedule commands support the CLI's global `--json` mode. List and run-history responses preserve the API page shape, including `items`, `nextCursor`, `usage`, and `policy`.
|
|
66
|
+
|
|
45
67
|
## Notes
|
|
46
68
|
|
|
47
|
-
-
|
|
48
|
-
-
|
|
69
|
+
- Every operation is scoped to the active environment unless `--env` is passed.
|
|
70
|
+
- Pausing stops future cron runs. It does not delete history.
|
|
71
|
+
- A failed or skipped manual run exits non-zero with its run ID and an exact `runs show` command for inspecting detail.
|
|
@@ -226,7 +226,7 @@ After editing schema JSON, run `fimo schemas push {Uid}` and then `fimo validate
|
|
|
226
226
|
- Changing a reference target clears those connections. Renaming a relation field with the same target preserves them.
|
|
227
227
|
- Preserve top-level or nested renames with repeatable one-time operations: `fimo schemas push Page --rename sections.hero.heading=sections.hero.title`. Renames are command intent, not schema JSON.
|
|
228
228
|
- A many-to-one change or scalar/reference change clears only the changed field.
|
|
229
|
-
- Collection-to-
|
|
229
|
+
- Collection-to-Single removes that type's entries and cleans references to them.
|
|
230
230
|
- Singleton-to-collection preserves the existing entry.
|
|
231
231
|
- Blocks migrations are surgical: unaffected nested fields, block keys, and block order survive every supported change.
|
|
232
232
|
|
|
@@ -6,8 +6,8 @@ description: >-
|
|
|
6
6
|
Triggers: "in Fimo Studio", "in the dashboard", "in the web app",
|
|
7
7
|
"how do I X in the UI", or screenshots of the dashboard. Topics
|
|
8
8
|
covered: dashboard content and CMS, publishing from the dashboard,
|
|
9
|
-
dashboard SEO/domain settings,
|
|
10
|
-
history UI, dashboard sharing/billing, and dashboard chat. Never describe
|
|
9
|
+
dashboard SEO/domain settings, schedules and run history, outbound webhooks,
|
|
10
|
+
visual editing, version history UI, dashboard sharing/billing, and dashboard chat. Never describe
|
|
11
11
|
UI locations, buttons, or panels from memory — always read the relevant
|
|
12
12
|
reference file first.
|
|
13
13
|
---
|
|
@@ -37,6 +37,7 @@ Read the relevant reference file when the user's question matches a topic.
|
|
|
37
37
|
| AI Chat | references/ai-chat.md | "What can the AI do?", "How do I give context?" |
|
|
38
38
|
| Code Editor | references/code-editor.md | "How do I edit code?", "Where are my files?" |
|
|
39
39
|
| SEO Settings | references/seo-settings.md | "How do I set up SEO?", "Favicon, title, share image" |
|
|
40
|
+
| Schedules | references/schedules.md | "Recurring commands", "Run history", "Run now" |
|
|
40
41
|
| Webhooks | references/webhooks.md | "React to forms", "Send events to another service" |
|
|
41
42
|
| Preview & Responsive | references/preview-and-responsive.md | "How does it look on mobile?", "How do I test sizes?" |
|
|
42
43
|
| Visual Editing | references/visual-editing.md | "Can I edit visually?", "How do I change colors?" |
|
|
@@ -55,6 +56,7 @@ Read the relevant reference file when the user's question matches a topic.
|
|
|
55
56
|
| Adding images | Media Library, AI Chat, Edit Mode |
|
|
56
57
|
| Content/CMS | AI Chat, Media Library |
|
|
57
58
|
| Webhooks | Project secrets, Forms, Publishing, Agents |
|
|
59
|
+
| Schedules | Project secrets, Environments, Agents |
|
|
58
60
|
| Visual changes | Edit Mode (quick tweaks), AI Chat (bigger changes), Code Editor (full control) |
|
|
59
61
|
| Something went wrong | Version History, AI Chat |
|
|
60
62
|
| Working with others | Sharing, Collaboration |
|
|
@@ -1,12 +1,12 @@
|
|
|
1
1
|
## How the CMS Works
|
|
2
2
|
|
|
3
|
-
The CMS is where you manage your site's structured content. It separates content by
|
|
3
|
+
The CMS is where you manage your site's structured content. It separates content by whether a schema is repeatable:
|
|
4
4
|
|
|
5
5
|
- **Collections** hold multiple entries of the same kind, such as Blog posts, Team members, or Testimonials.
|
|
6
|
-
- **Singles** hold one
|
|
7
|
-
- **Entries** are the individual
|
|
6
|
+
- **Singles** hold one set of content, such as Site settings, a Homepage, or an About page.
|
|
7
|
+
- **Entries** are the individual records inside a Collection.
|
|
8
8
|
|
|
9
|
-
Both use schemas to define their fields. The difference is whether you edit one
|
|
9
|
+
Both use schemas to define their fields. The difference is whether you edit one set of content or manage a repeatable list.
|
|
10
10
|
|
|
11
11
|
## Browsing Your Content
|
|
12
12
|
|
|
@@ -15,9 +15,9 @@ Both use schemas to define their fields. The difference is whether you edit one
|
|
|
15
15
|
3. Hover over or focus the info icon beside any item for a short explanation.
|
|
16
16
|
4. Each destination shows cards for the schemas in that group.
|
|
17
17
|
5. Click a Collection to see its entries, then click an entry to edit it.
|
|
18
|
-
6. Click a Single to
|
|
18
|
+
6. Click a Single to edit it directly.
|
|
19
19
|
|
|
20
|
-
Collection cards show their entry count. Single cards are labeled **Single** instead because they always represent one
|
|
20
|
+
Collection cards show their entry count. Single cards are labeled **Single** instead because they always represent one set of content.
|
|
21
21
|
|
|
22
22
|
## Editing a Single
|
|
23
23
|
|
|
@@ -25,7 +25,7 @@ Collection cards show their entry count. Single cards are labeled **Single** ins
|
|
|
25
25
|
2. Select the Single you want, such as Site settings.
|
|
26
26
|
3. Update its fields.
|
|
27
27
|
|
|
28
|
-
Changes save automatically. A Single has no entry list, create action, bulk actions, or delete action because it always represents the same
|
|
28
|
+
Changes save automatically. A Single has no entry list, create action, bulk actions, or delete action because it always represents the same set of content.
|
|
29
29
|
|
|
30
30
|
## Navigating the Entry List
|
|
31
31
|
|
|
@@ -96,7 +96,7 @@ The AI chat can help you manage content without navigating through menus:
|
|
|
96
96
|
## Key Concepts
|
|
97
97
|
|
|
98
98
|
- **Collections** are best for repeatable content. Open one to search, sort, create, and manage its entries.
|
|
99
|
-
- **Singles** are best for one-off
|
|
99
|
+
- **Singles** are best for one-off content. Open one and edit it directly.
|
|
100
100
|
- **Content appears automatically** if its schema is connected (wired) to a page on your site. You do not need to manually link each entry.
|
|
101
101
|
- **Forms tab**: View and manage form submissions collected from your site's forms.
|
|
102
102
|
- **Labels & Text tab**: Edit your site's UI labels and static text strings as key-and-value rows. This is for your site's interface copy, not for translated copies of collection entries.
|
|
@@ -0,0 +1,43 @@
|
|
|
1
|
+
# Schedules
|
|
2
|
+
|
|
3
|
+
Schedules run recurring project commands in one environment. Use the Studio surface to review configuration, pause or resume automatic runs, start work now, and inspect what happened afterward.
|
|
4
|
+
|
|
5
|
+
## Open schedules
|
|
6
|
+
|
|
7
|
+
1. Open the project and choose **Settings**.
|
|
8
|
+
2. Select **Schedules**.
|
|
9
|
+
3. Choose the environment whose schedules you want to manage.
|
|
10
|
+
|
|
11
|
+
The list shows each schedule's name, cron, command, enabled state, and latest status. Usage and retention policy are shown for the selected environment.
|
|
12
|
+
|
|
13
|
+
## Create or edit a schedule
|
|
14
|
+
|
|
15
|
+
Choose **New schedule** to set:
|
|
16
|
+
|
|
17
|
+
- A human-readable name
|
|
18
|
+
- A standard five-field cron expression
|
|
19
|
+
- The command to run from the project root
|
|
20
|
+
- The project secret keys the command is allowed to use
|
|
21
|
+
|
|
22
|
+
A schedule with no selected secret keys receives no project secrets. Studio displays key names only and never reveals secret values.
|
|
23
|
+
|
|
24
|
+
Open a schedule to change its configuration. Use **Pause** to prevent future cron runs without deleting its history, and **Resume** to make the cron active again.
|
|
25
|
+
|
|
26
|
+
## Run now
|
|
27
|
+
|
|
28
|
+
Choose **Run now** from a schedule to queue a manual run. Only one run can be active for a schedule at a time. If one is already queued or running, Studio links to the active run instead of starting a duplicate.
|
|
29
|
+
|
|
30
|
+
Runs use at-least-once delivery. If Fimo loses a completion response, the same run may execute again. Side-effecting commands should use `FIMO_SCHEDULE_RUN_ID` as their idempotency key.
|
|
31
|
+
|
|
32
|
+
## Inspect history
|
|
33
|
+
|
|
34
|
+
Open the **Runs** tab on a schedule to browse cursor-paginated history. Filter by queued, running, succeeded, failed, or skipped status.
|
|
35
|
+
|
|
36
|
+
Select a run to see:
|
|
37
|
+
|
|
38
|
+
- Status, trigger, actor, and queued/start/finish times
|
|
39
|
+
- Exit code, stable error code, and error message
|
|
40
|
+
- Redacted captured output, its size, truncation state, and expiry
|
|
41
|
+
- Secret snapshot state and key metadata
|
|
42
|
+
|
|
43
|
+
Secret snapshot metadata helps explain whether a selected key was resolved, missing, deleted, recreated, or rotated after the run. It never contains a secret value or hash.
|
|
@@ -1,25 +1,23 @@
|
|
|
1
1
|
## Where to Find Version History
|
|
2
2
|
|
|
3
|
-
Click your **project name** in the top
|
|
3
|
+
Click your **project name** in the top bar to open the project dropdown menu, then select **History**. This opens the version history panel showing all your saved versions.
|
|
4
4
|
|
|
5
5
|
## How Versions Are Created
|
|
6
6
|
|
|
7
|
-
Versions are created automatically as you work — you don't create them by hand. Whenever the AI makes meaningful changes to your project, it captures a
|
|
7
|
+
Versions are created automatically as you work — you don't create them by hand. Whenever the AI makes meaningful changes to your project, it captures a restore point for the current environment that you can browse, rename, and restore. A restore point includes the project code and CMS data, including schemas, entries, translations, and forms. There is no "create version" button in the panel; the history list only shows the restore points that already exist.
|
|
8
8
|
|
|
9
9
|
## Browsing Versions
|
|
10
10
|
|
|
11
11
|
The version list shows each version's name and timestamp (the relative time, with the full date on hover).
|
|
12
12
|
|
|
13
|
-
- The most recent version shows a **"Current"** badge.
|
|
14
|
-
|
|
15
13
|
## Restoring a Previous Version
|
|
16
14
|
|
|
17
15
|
1. Find the version you want to restore.
|
|
18
16
|
2. Click the **three-dot menu** next to the version and select **Restore**.
|
|
19
|
-
3. A confirmation dialog
|
|
17
|
+
3. A confirmation dialog explains that this will replace the current environment and save its current state as a safety point first.
|
|
20
18
|
4. Click **Restore** to confirm.
|
|
21
19
|
|
|
22
|
-
|
|
20
|
+
The current environment's code and CMS data revert to that restore point. Uploaded assets do not change. If you need to undo the restore, restore the automatically created safety point.
|
|
23
21
|
|
|
24
22
|
## Editing Version Details
|
|
25
23
|
|
|
@@ -28,12 +26,14 @@ Find the version you want to update, click the **three-dot menu**, select **Edit
|
|
|
28
26
|
## Key Concepts
|
|
29
27
|
|
|
30
28
|
- **Automatic versions** -- The AI creates these whenever it makes significant changes to your project. You do not need to do anything for these to appear.
|
|
31
|
-
- **
|
|
32
|
-
- **
|
|
29
|
+
- **Studio is browse and restore** -- Studio does not create restore points manually. Developers can use `fimo history create "Name"` from the CLI.
|
|
30
|
+
- **Environment-scoped history** -- Each environment has its own restore points. Restoring one environment does not change another.
|
|
31
|
+
- **Safe restore** -- Fimo records the current code and CMS data as a safety point before replacing them.
|
|
32
|
+
- **Assets stay in place** -- Restoring changes code and CMS data, but does not remove or roll back uploaded assets.
|
|
33
33
|
|
|
34
34
|
## Quick Restore from Chat
|
|
35
35
|
|
|
36
|
-
Each AI message in the chat that made changes to your project shows an **undo button** (↩ icon) on the right side. Click it and a **"Restore version?"** prompt appears; confirm it to restore
|
|
36
|
+
Each AI message in the chat that made changes to your project shows an **undo button** (↩ icon) on the right side. Click it and a **"Restore version?"** prompt appears; confirm it to restore the current environment to the state it was in at that message. Fimo saves a safety point first, so CMS work completed after that message remains recoverable. This is the fastest way to undo a recent change without opening the full version history panel.
|
|
37
37
|
|
|
38
38
|
The undo button is disabled on the most recent change (you can't restore the version you're already on) and is only available to members with permission to manage history.
|
|
39
39
|
|