@lowdefy/docs-content 0.0.0-experimental-20260909201552 → 6.0.0

package/README.md

@@ -6,7 +6,6 @@ Lowdefy documentation extracted as markdown, for serving to AI coding agents via
 
 - `content/<section>/<slug>.md` — one markdown file per docs page (concepts, tutorial, operators, actions, connections, blocks, ...).
 - `index.json` — manifest of all docs: `{ version, docs: [{ slug, title, section, path, kind?, typeName? }] }`. `kind`/`typeName` map a plugin type (e.g. operator `_get`) to its doc.
-- `hazards.json` — framework-level hazards served by the dev MCP alongside schemas, docs and config lookups: `[{ id, appliesTo: { kinds?, types?, when? }, message, see }]`. This file is hand-authored and committed, not generated — `pnpm docs:content` wipes `content/` but leaves it untouched. Add an entry only for a behaviour verified in the framework source.
 
 ## Regenerating content
 

package/content/actions/login.md

@@ -10,7 +10,7 @@
     pageId?: string
     url?: string
     urlQuery?: object
-  } | false
+  }
   providerId?: string,
 }): void
 ```
@@ -19,46 +19,28 @@ The `Login` action is used to start the user login flow. If only one provider is
 
 The authorization url usually hosts a page where the user can input their credentials. After the user has logged in successfully, the user is redirected to the `api/auth/callback/[provider_id]` route in the Lowdefy app, where the rest of the authorization code flow is completed.
 
-The `callbackUrl` parameter of the Login action specifies where the user lands after login is complete. Three sources are consulted, in order:
-
-1. The `callbackUrl` param, if given.
-2. The `?callbackUrl=` query parameter, which Lowdefy sets when it redirects an unauthenticated user to the sign-in page - so a user who was bounced there returns to the page they asked for.
-3. The app's home page.
-
-If none of the three resolves - an app with no `homePageId` whose menu offers the signed-out user no page to fall back on - the action throws rather than staying silently on the sign-in page.
-
-To sign in without navigating at all, set `callbackUrl: false`. This is for a login form in a modal or an embedded panel, where the session store re-renders the page with the new user in place. It is not valid for magic-link or social/OAuth sign-in, which redirect through a hop Lowdefy does not control.
-
-A sign-in the auth server rejects - a wrong password, an expired or already-used link, an invalid code - is an expected outcome, not an app error. The action throws a `UserError`: `catch` actions on the event still run and the error message still displays, but it is logged to the browser console only and is never reported to the server. The auth server's response is available to `catch` actions as `_actions.<actionId>.error.metaData`, with a `code` (for example `INVALID_EMAIL_OR_PASSWORD`) and the HTTP `status`. A network failure or a server fault is still thrown as an action error and reported.
+The `callbackUrl` parameters of the Login action specify where the user is redirected after login is complete. If `callbackUrl` parameters not set, the user will return to the page from which the action was called.
 
 #### Parameters
 
 ###### object
 - `authUrl: object`:
   - `urlQuery: object`: Query parameters to set for the authorization URL.
-- `callbackUrl: object | false`: Set to `false` to sign in without navigating. As an object:
+- `callbackUrl: object`:
   - `home: boolean`: Redirect to the home page after the login flow is complete.
   - `pageId: string`: The pageId of the page to redirect to after the login flow is complete.
-  - `url: string`: The URL to redirect to after the login flow is complete. An absolute URL is not `basePath`-prefixed, so it can be an external landing page.
+  - `url: string`: The URL to redirect to after the login flow is complete.
   - `urlQuery: object`: The urlQuery to set for the page the user is redirected to after login.
 - `providerId: string`: The ID of the provider that should be used for login. If not set and only one provider is configured the configured provider will be used. Else the user will be redirected to a sign in page where they can choose a provider.
 
 #### Examples
 
-###### Login and land on the home page (or the page the user was bounced from):
+###### Login and return to the same page:
 ```yaml
 - id: login
   type: Login
 ```
 
-###### Login in a modal, without navigating:
-```yaml
-- id: login
-  type: Login
-  params:
-    callbackUrl: false
-```
-
 ###### Login with the google provider:
 ```yaml
 - id: login_with_google

package/content/actions/logout.md

@@ -14,16 +14,16 @@
 
 When the `Logout` action is called, the user data and authorization cookies are cleared by the app.
 
-The `callbackUrl` parameter of the Logout action specifies where the user lands after logout is complete. Unlike the `Login` action it has no default and does not read the `?callbackUrl=` query: with no `callbackUrl` the page is reloaded and the server re-applies the page's auth rules, which sends a signed-out user off a protected page to the sign-in page. Defaulting to the home page instead could land them on a page they may no longer see.
+The `callbackUrl` parameters of the Logout action specify where the user is redirected after logout is complete. If `callbackUrl` parameters not set, the user will return to the page from which the action was called.
 
 #### Parameters
 
 ###### object
 - `callbackUrl: object`:
-  - `home: boolean`: Redirect to the home page after the logout flow is complete.
-  - `pageId: string`: The pageId of the page to redirect to after the logout flow is complete.
-  - `url: string`: The URL to redirect to after the logout flow is complete. An absolute URL is not `basePath`-prefixed, so it can be an external logout landing page.
-  - `urlQuery: object`: The urlQuery to set for the page the user is redirected to after logout.
+  - `home: boolean`: Redirect to the home page after the login flow is complete.
+  - `pageId: string`: The pageId of the page to redirect to after the login flow is complete.
+  - `url: string`: The URL to redirect to after the login flow is complete.
+  - `urlQuery: object`: The urlQuery to set for the page the user is redirected to after login.
 - `redirect: boolean`: If set to `false` the user session will be cleared, but the page will not be reloaded.
 
 #### Examples

package/content/agents/agentchat.md

@@ -68,7 +68,6 @@ The `AgentChat` block renders a streaming AI chat interface. It connects to a [L
 | `agentId` | string | | __Required__ - The `id` of the agent to connect to. |
 | `conversationId` | string | | Active conversation ID. When this changes, messages are cleared. If left empty, the block auto-mints a stable id for the session and surfaces it via `onConversationStart`, so every turn posts a consistent id. App-supplied ids are always authoritative. |
 | `messages` | array | | Load messages externally. `undefined` = no sync, `null` = clear, array = load. |
-| `feedbackValues` | object | | Ratings already recorded for messages in this conversation, keyed by message id, each `like` or `dislike`. The block does not persist a rating, so without this a reload or a conversation switch shows every message unrated even where your app stored it. A rating clicked this visit takes precedence, so the thumb still responds immediately and a rating the user has just withdrawn is not re-lit by a stale value. |
 | `urlQuery` | object | | Query parameters sent with each request. Available server-side via `_payload`. |
 | `sharedState` | object | | Two-way bridge between page state and the agent. See [Shared State](#shared-state). |
 | `height` | string | `'calc(100dvh - 170px)'` | CSS height of the chat container. Only applies when `display` is `'inline'`. |
@@ -327,7 +326,7 @@ With the curated form above, the agent can read `legal_name` and `registration_n
 | `onToolResult` | A tool returns a result. | `toolName`, `toolCallId`, `output`, `error` |
 | `onError` | A streaming error occurs. | `message` |
 | `onStop` | User stops generation. | `messages` |
-| `onFeedback` | User clicks thumbs up/down. `rating` is `like` or `dislike`, or `default` when the user clicks the selected thumb again to clear the rating — branch on it explicitly rather than treating anything that is not `like` as a dislike. | `messageId`, `messageContent`, `rating` |
+| `onFeedback` | User clicks thumbs up/down. | `messageId`, `messageContent`, `rating` |
 | `onRegenerate` | User clicks regenerate. | `messageId`, `messages` |
 | `onDeleteMessage` | User deletes a message. | `messageId`, `content`, `messages` |
 | `onEditMessage` | User edits and resubmits. | `messageId`, `originalContent`, `newContent`, `messages` |
@@ -335,7 +334,6 @@ With the curated form above, the agent can read `legal_name` and `registration_n
 | `onSwitchChange` | User toggles a sender switch. | `key`, `checked` |
 | `onTitleGenerated` | A `data-chat-title` data part arrives — emitted automatically when the agent's [`generateTitle`](/agent-properties) property is set, or manually from an `onFinish` hook. | `title` |
 | `onDataPart` | Any data part arrives from the server. | `type`, `data`, `id` |
-| `onLinkClick` | User clicks a link in a message. Wiring this event suppresses the default navigation for plain left clicks, so the app can open the target in place; modified clicks (new tab, middle click) always navigate. | `href`, `text` |
 
 ###### Validate messages before sending:
 ```yaml
@@ -367,16 +365,6 @@ events:
         type: success
 ```
 
-Saving is only half of it — the block does not persist a rating, so a
-reload or a conversation switch shows the message unrated again. Pass
-what you stored back through `feedbackValues`, keyed by message id:
-
-```yaml
-properties:
-  feedbackValues:
-    _request: saved_feedback_for_conversation
-```
-
 ###### Adapt behavior based on sender switches:
 ```yaml
 events:

package/content/concepts/ai-agent-docs.md

@@ -29,7 +29,6 @@ It provides these tools:
 | `lowdefy_build_status`   | Current build errors and warnings (with source file locations) plus recent browser runtime errors — call after every edit |
 | `lowdefy_get_page_config`| The fully built config for a page, or its structured build errors        |
 | `lowdefy_screenshot_page`| PNG screenshot of a rendered page (headless Chromium) for visual verification |
-| `lowdefy_run_journey`    | Drive a page headless through declarative steps (`click`, `fill`, `select`, `press`, `wait`, `screenshot`, `expect`) and assert state, visibility, text or url — verify behaviour, not just layout |
 | `lowdefy_find_config`    | Which yaml file (and line) defines a given page, block, or request id    |
 | `lowdefy_scaffold_page`  | Create a new page yaml file with a canonical minimal structure           |
 | `lowdefy_app_map`        | The whole-app graph: every page, menu, connection, endpoint, and agent in one call |
@@ -79,9 +78,9 @@ When you have a page open in your browser, the agent can read its **actual live
 
 ## Auth-protected pages
 
-The headless renderer behind `lowdefy_screenshot_page` and `lowdefy_inspect_state` authenticates as a signed-in user, so pages with `auth.public: false` render for the agent instead of bouncing to the sign-in page. That default user carries **no roles**, so a page or request gated on a role still comes back refused or empty.
+The headless renderer behind `lowdefy_screenshot_page` and `lowdefy_inspect_state` authenticates as a signed-in user, so pages with `auth.public: false` render for the agent instead of returning a 404. That default user carries **no roles**, so a page or request gated on a role still comes back refused or empty.
 
-To act as a specific caller, pass `user` — every tool that renders a page headless accepts it: `lowdefy_screenshot_page`, `lowdefy_run_journey`, `lowdefy_inspect_state`, `lowdefy_eval_operator` and `lowdefy_load_state`:
+To act as a specific caller, pass `user` — every tool that renders a page headless accepts it: `lowdefy_screenshot_page`, `lowdefy_inspect_state`, `lowdefy_eval_operator` and `lowdefy_load_state`:
 
 ```json
 { "pageId": "users", "user": { "roles": ["admin"] } }
@@ -89,9 +88,9 @@ To act as a specific caller, pass `user` — every tool that renders a page head
 
 It is merged over the default user, so `{"roles": [...]}` is usually all you need. No auth engine runs for an injected caller, so nothing derives the rest of the record — include `email`, `profile` or `attributes` in the object if the page reads them. Every call opens its own browser context, so one call can act as an admin and the next as a plain member.
 
-`user` applies to the headless renderer only — it is never applied to a page you open in your own browser, which carries your real session and cannot be re-identified. `lowdefy_inspect_state` and `lowdefy_eval_operator` normally prefer your open tab, so passing `user` selects the headless source instead; combining it with `source: "tab"` is an error rather than a silently ignored role, as is combining it with `lowdefy_load_state`'s `mode: "registry-only"` (that mode hands you a URL to open yourself). The plain HTTP routes take the same param: `?user={"roles":["admin"]}` on the GET routes, a `user` key in the body of `POST /lowdefy-docs/journey`, `POST /lowdefy-docs/eval-operator` and `POST /lowdefy-docs/state-checkpoints/load`. They answer a malformed or contradictory `user` with a `400`, distinct from the `502` a failed render returns.
+`user` applies to the headless renderer only — it is never applied to a page you open in your own browser, which carries your real session and cannot be re-identified. `lowdefy_inspect_state` and `lowdefy_eval_operator` normally prefer your open tab, so passing `user` selects the headless source instead; combining it with `source: "tab"` is an error rather than a silently ignored role, as is combining it with `lowdefy_load_state`'s `mode: "registry-only"` (that mode hands you a URL to open yourself). The plain HTTP routes take the same param: `?user={"roles":["admin"]}` on the GET routes, a `user` key in the body of `POST /lowdefy-docs/eval-operator` and `POST /lowdefy-docs/state-checkpoints/load`. They answer a malformed or contradictory `user` with a `400`, distinct from the `502` a failed render returns.
 
-To bypass login for the whole dev server — your own browser included — start it with a mock user instead: `lowdefy dev --mock-user '{"id":"dev","roles":["admin"]}'` (or configure `auth.dev.mockUser`). See [Auth Configuration](/auth-configuration#mock-user-for-testing-dev-server-only).
+To bypass login for the whole dev server — your own browser included — start it with a mock user instead: `lowdefy dev --mock-user '{"sub":"dev","roles":["admin"]}'` (or configure `auth.dev.mockUser`). See [Auth Configuration](/auth-configuration#mock-user-for-testing-dev-server-only).
 
 ## State checkpoints — put the app in a known state
 
@@ -124,90 +123,6 @@ cli:
 
 This is dev-only — enable it when you're comfortable with the agent writing to your dev data.
 
-## Journeys — verify behaviour, not just layout
-
-A screenshot shows what rendered; it cannot tell the agent whether the form submits, the modal opens or the filter works. `lowdefy_run_journey` (or `POST /lowdefy-docs/journey`) opens a page headless and drives it through a declarative list of steps — a tiny Playwright — then reports what happened as data. Blocks are addressed by their `blockId`, through the same `#bl-<blockId>` DOM contract `@lowdefy/e2e-utils` uses, so a journey reads like the config it tests:
-
-```json
-{
-  "pageId": "new_customer",
-  "user": { "roles": ["admin"] },
-  "urlQuery": { "ref": "campaign-1" },
-  "steps": [
-    { "fill": { "blockId": "name", "value": "Ada Lovelace" } },
-    { "select": { "blockId": "country", "value": "United Kingdom" } },
-    { "click": "submit" },
-    { "wait": { "request": "create_customer" } },
-    { "expect": { "state": { "path": "created", "equals": true } } },
-    { "expect": { "visible": "success_modal" } },
-    { "expect": { "text": { "blockId": "success_message", "contains": "Ada Lovelace" } } },
-    { "screenshot": "after-submit" },
-    { "press": "Escape" },
-    { "click": "go_to_list" },
-    { "expect": { "url": { "contains": "/customers" } } }
-  ]
-}
-```
-
-Every step is an object with exactly one key:
-
-| Step                                              | What it does                                                                                                                                                                     |
-| ------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `{ "click": blockId }`                            | Clicks the block — its interactive control (button, link, input, checkbox…) when it has one, otherwise the block itself                                                          |
-| `{ "fill": { blockId, value } }`                  | Fills the block's `input` or `textarea` with `value` (converted to a string)                                                                                                     |
-| `{ "select": { blockId, value } }`                | Opens the block's dropdown and clicks the option whose text is exactly `value`; a native `<select>` inside the block is set by label instead                                     |
-| `{ "press": key }`                                | Presses a key or chord, e.g. `"Enter"`, `"Escape"`, `"Mod+k"` — `Mod` becomes `Meta` or `Control` for the platform the page reports, the same way the app's shortcuts resolve it |
-| `{ "wait": { "ms": n } }`                         | Sleeps `n` milliseconds                                                                                                                                                          |
-| `{ "wait": { "request": requestId } }`            | Waits until the request has finished loading                                                                                                                                     |
-| `{ "wait": { "state": path } }`                   | Waits until the state path is defined                                                                                                                                            |
-| `{ "screenshot": name? }`                         | Captures a PNG of the viewport; returned with the result (`true`, `null` or a missing name defaults to `step-<index>`)                                                           |
-| `{ "expect": { "state": { path, equals } } }`     | The state at `path` structurally equals `equals` (key order does not matter)                                                                                                     |
-| `{ "expect": { "visible": blockId } }`            | The block is visible                                                                                                                                                             |
-| `{ "expect": { "text": { blockId, contains } } }` | The block's text contains the string                                                                                                                                             |
-| `{ "expect": { "url": { contains } } }`           | The page url contains the string                                                                                                                                                 |
-
-Each step gets 5 seconds (Playwright's own auto-waiting — a `click` waits for the block to be attached, visible and enabled; nothing is retried). After an interaction the runner waits for the page to settle — the event the interaction fired, the requests it called — using the same readiness check the page open uses, so the next `expect` asserts against the outcome instead of racing it. The page opens with the same headless `user` and `urlQuery` handling as the other tools.
-
-A step that fails **stops the journey and comes back as data**, never as a tool error — a failed journey is the answer, not a fault:
-
-```json
-{
-  "pageId": "new_customer",
-  "passed": false,
-  "steps": [
-    {
-      "index": 0,
-      "step": { "fill": { "blockId": "name", "value": "Ada Lovelace" } },
-      "status": "ok",
-      "durationMs": 18
-    },
-    { "index": 1, "step": { "click": "submit" }, "status": "ok", "durationMs": 71 },
-    {
-      "index": 2,
-      "step": { "expect": { "state": { "path": "created", "equals": true } } },
-      "status": "failed",
-      "durationMs": 1
-    },
-    { "index": 3, "step": { "screenshot": "after-submit" }, "status": "skipped", "durationMs": 0 }
-  ],
-  "failure": {
-    "index": 2,
-    "step": { "expect": { "state": { "path": "created", "equals": true } } },
-    "expected": true,
-    "actual": null,
-    "message": "Expected state \"created\" to equal true but found undefined."
-  },
-  "screenshots": [],
-  "state": { "name": "Ada Lovelace", "country": null }
-}
-```
-
-`expected` and `actual` hold the compared values for an `expect` step, and for an interaction step what the runner needed (`block "submit" to be actionable`, `option "Chile" in the dropdown of block "country"`) against Playwright's own message. The remaining steps are marked `skipped`. A passing journey returns `passed: true` and no `failure`. The final page `state` is always included, pass or fail — it is what the agent needs to write the next assertion. Screenshots taken before the failure are kept: over MCP they arrive as image content after the JSON (with the JSON listing only their names); over HTTP they are base64 in the JSON body.
-
-Malformed steps are answered before a browser opens — an unknown key returns `Unknown journey step "hover". Steps are: click, fill, select, press, wait, screenshot, expect.` (a `400` on the HTTP route), distinct from the `502` a render that could not run returns.
-
-Journeys are also the file format of `tests/journeys/*.yaml`, which `lowdefy test` runs through this same route — write the journey the agent used to verify a change, and it becomes the regression test for it.
-
 ## Setting up a project — one command
 
 ```bash
@@ -290,7 +205,6 @@ Everything the MCP tools serve is also available as plain GET routes — useful
 | `GET /lowdefy-docs/build-status`    | Current build errors/warnings + recent browser runtime errors   |
 | `GET /lowdefy-docs/page-config/{pageId}` | Fully built page config, or its build errors               |
 | `GET /lowdefy-docs/screenshot/{pageId}` | PNG screenshot of the rendered page                         |
-| `POST /lowdefy-docs/journey`        | Drive a page headless through declarative steps and assert what happens; screenshots returned as base64 |
 | `GET /lowdefy-docs/find/{id}?pageId=` | Locate where a page/block/request id is defined               |
 | `GET /lowdefy-docs/app-map`         | Whole-app graph: pages, menus, connections, endpoints, agents   |
 | `GET /lowdefy-docs/inspect-state/{pageId}` | Live state/requests/eventLog of a running page (tab or headless) |

package/content/concepts/custom-styling.md

@@ -3,7 +3,7 @@
 Lowdefy provides several ways to style blocks and customize the look of your app:
 
 - **`class`** — Apply CSS class names (including Tailwind CSS utility classes) to blocks.
-- **`style`** — Apply inline CSS styles to blocks. Use `.`-prefixed keys to target specific parts (CSS slots).
+- **`style`** — Apply inline CSS styles to blocks. Use `--`-prefixed keys to target specific parts (CSS slots).
 - **`properties.theme`** — Override antd design tokens per block. See [Theming](/theming) for details.
 - **`public/styles.css`** — A global CSS file for custom styles.
 
@@ -11,7 +11,7 @@ Lowdefy provides several ways to style blocks and customize the look of your app
 
 The `class` property applies CSS class names to a block. [Tailwind CSS](https://tailwindcss.com/) is always available in Lowdefy apps, so you can use any Tailwind utility classes directly.
 
-`class` can be a string, an array of strings, an object keyed by the block's CSS keys, or an operator that computes the classes at runtime:
+`class` can be a string, an array of strings, or an object keyed by the block's CSS keys:
 
 ```yaml
 # String — applied to the block wrapper
@@ -27,60 +27,15 @@ The `class` property applies CSS class names to a block. [Tailwind CSS](https://
     - shadow-lg
     - rounded-xl
 
-# Object — target specific parts of the block using CSS keys (. prefix)
+# Object — target specific parts of the block using CSS keys (-- prefix)
 - id: my_card
   type: Card
   class:
     .element: "shadow-lg"
     .header: "bg-gray-100"
     .body: "p-8"
-
-# Operator — the block's classes are computed at runtime
-- id: status_badge
-  type: Box
-  class:
-    _if:
-      test:
-        _eq:
-          - _state: status
-          - error
-      then: bg-red-100 text-red-700
-      else: bg-green-100 text-green-700
-```
-
-An operator's result may be a string, an array of strings, or an object of `{ class: boolean }` where each class with a truthy value is applied:
-
-```yaml
-- id: status_badge
-  type: Box
-  class:
-    _if:
-      test:
-        _eq:
-          - _state: status
-          - error
-      then:
-        bg-red-100: true
-        text-red-700: true
-      else: bg-green-100
 ```
 
-An operator at the root of `class` computes the classes of the block wrapper. To compute a specific part's classes, place the operator under that CSS key:
-
-```yaml
-- id: my_card
-  type: Card
-  class:
-    .header:
-      _if:
-        test:
-          _state: highlighted
-        then: bg-yellow-100
-        else: bg-gray-100
-```
-
-> **Note:** An operator's result is never expanded into a map of CSS keys — a root operator always sets the block wrapper's classes.
-
 Tailwind responsive prefixes work as expected:
 
 ```yaml
@@ -103,7 +58,7 @@ See [Theming](/theming) for the full list of bridged tokens and how to add custo
 
 ## The `style` property
 
-The `style` property applies inline CSS styles to a block. When used with flat CSS properties (no `.` prefix), it targets the block's layout wrapper:
+The `style` property applies inline CSS styles to a block. When used with flat CSS properties (no `--` prefix), it targets the block's layout wrapper:
 
 ```yaml
 - id: my_block
@@ -148,7 +103,7 @@ Each block's documentation page lists its supported CSS keys.
 
 Each block declares named style targets in its `meta.cssKeys`. For example, the [Card](/Card) block supports: `element`, `header`, `body`, `cover`, `actions`, `extra`.
 
-Both `class` (object form) and `style` use `.`-prefixed versions of these keys to target specific parts of a block. The `.` prefix mirrors CSS selector convention and avoids confusion with CSS property names.
+Both `class` (object form) and `style` use `--`-prefixed versions of these keys to target specific parts of a block. The `--` prefix mirrors CSS custom property convention and avoids confusion with CSS property names.
 
 To find the CSS keys for a block, check the block's documentation page.
 

package/content/concepts/events-and-actions.md

@@ -225,11 +225,9 @@ events:
           searchOpen: true
 ```
 
-## Page lifecycle events
+## Page initialization events
 
-The first blocks on a page, usually a [`container`](/container) type block, can define page lifecycle events. The page initialization events `onInit` and `onInitAsync` are triggered when the page is first loaded, and the browser lifecycle events `onVisible`, `onHidden`, `onOnline`, `onOffline` and `onResize` are triggered while the page stays open. All blocks have `onMount` and `onMountAsync` events, that can be used to initialize the page or blocks.
-
-### Page initialization events
+The first blocks on a page, usually a [`container`](/container) type block, can define `onInit` and `onInitAsync` events. All blocks have `onMount` and `onMountAsync` events, that can be used to initialize the page or blocks.
 
 The `onInit` event is triggered the first time a page is loaded. This event blocks page render, in other words, the page __will__ remain in a loading state, rendering only the progress bar, until all the actions have completed execution. It can be used to set up [`state`](/page-and-app-state). Actions that take a long time to execute, like `Request`, should be used sparingly here for a better user experience.
 
@@ -239,62 +237,6 @@ The `onMount` event is triggered every time a block is rendered on a page. This
 
 The `onMountAsync` event is triggered every time a block is mounted, but does not render the block in loading.
 
-### Browser lifecycle events
-
-The first blocks on a page can also define events that react to the browser: `onVisible`, `onHidden`, `onOnline`, `onOffline` and `onResize`. These are useful to refresh data that went stale while the user was away, instead of polling the server on a timer.
-
-These events are only attached while the page is mounted, and are removed again when the user navigates away, so they never trigger for a page the user has left. They never trigger on the initial page load either — only a change after the page has loaded triggers them. Their action chains run like `onMountAsync`: they do not keep the page or block in a loading state.
-
-The `onVisible` event is triggered when the browser tab becomes visible again, or when the window regains focus. Rapid pairs of these signals — a tab switch usually produces both — are coalesced over 300ms, so the event is only triggered once. The [`_event`](/_event) object contains `visible: true` and `reason`, which is `visibility` when the browser reported the tab becoming visible, or `focus` when the window regained focus.
-
-```yaml
-events:
-  onVisible:
-    - id: refresh_tasks
-      type: Request
-      params: get_tasks
-```
-
-The `onHidden` event is triggered when the browser tab is hidden, or when the window loses focus, coalesced in the same way. The `_event` object contains `visible: false` and the same `reason` field.
-
-```yaml
-events:
-  onHidden:
-    - id: stop_refreshing
-      type: SetState
-      params:
-        live: false
-```
-
-The `onOnline` and `onOffline` events are triggered when the browser reports that the network connection was regained or lost. The `_event` object contains `online: true` or `online: false`.
-
-```yaml
-events:
-  onOnline:
-    - id: back_online
-      type: Message
-      params:
-        content: You are back online.
-  onOffline:
-    - id: went_offline
-      type: Message
-      params:
-        status: warning
-        content: You are offline, changes will not be saved.
-```
-
-The `onResize` event is triggered when the window is resized, debounced by 200ms so that the actions only run once the user stops resizing. The `_event` object contains the `width` and `height` of the window.
-
-```yaml
-events:
-  onResize:
-    - id: set_width
-      type: SetState
-      params:
-        window_width:
-          _event: width
-```
-
 ## Action types
 
 The following actions can be used:
@@ -327,7 +269,3 @@ See additional action type available under the Actions tab in the menu.
 - The `onInitAsync` event is triggered the first time a page is mounted and does not keep the page in loading.
 - The `onMount` events is triggered the every time a block is mounted and keeps the block in loading until all actions have finished.
 - The `onMountAsync` event is triggered the every time a block is mounted, after `onMount` has completed, and does not keep the block in loading.
-- The `onVisible` and `onHidden` events are triggered when the browser tab is shown or hidden, or when the window gains or loses focus, coalesced over 300ms.
-- The `onOnline` and `onOffline` events are triggered when the browser reports that the network connection was regained or lost.
-- The `onResize` event is triggered when the window is resized, debounced by 200ms.
-- Browser lifecycle events are never triggered on the initial page load, and are removed when the user navigates away from the page.

package/content/concepts/i18n.md

@@ -214,7 +214,7 @@ config:
         agent.antdx.actions.feedbackDislike: 'Gefällt mir nicht'
 ```
 
-**Agent runtime errors.** HTTP error responses from the agent endpoint (a 405 for a wrong method, a 400 for a malformed request, and so on: `Only POST requests are supported.`, `Invalid agent path`, `Agent "X" does not exist.`, etc.) translate via `agent.runtime.*` keys against the request's `Accept-Language`. Server-side validation errors and stack traces stay in English (developer diagnostics).
+**Agent runtime errors.** HTTP 400/500 errors from the agent endpoint (`Only POST requests are supported.`, `Invalid agent path`, `Agent "X" does not exist.`, etc.) translate via `agent.runtime.*` keys against the request's `Accept-Language`. Server-side validation errors and stack traces stay in English (developer diagnostics).
 
 **Agent config translation.** `agent.properties.instructions` passes through the operator parser at request time, so `_t:` works:
 

package/content/connections/mongodb.md

@@ -34,15 +34,12 @@ The `MongoDBCollection` connection sets up a connection to a MongoDB deployment.
 
 >Since the connection URI contains authentication secrets, it should be stored using the [`_secret`](operators/secret.md) operator.
 
-When the connection has a `changeLog` collection, all write requests log a change record to that collection. The record contains the request arguments, the request context (`blockId`, `pageId`, `requestId`, `connectionId`, `payload`), a `timestamp`, the request `type`, the connection's `changeLog.meta` value, and either the driver response or `before`/`after` document snapshots (for `MongoDBUpdateOne`, `MongoDBVersionedUpdateOne` and `MongoDBDeleteOne`). The response shape of every request stays the same whether or not a log collection is configured.
+When using MongoDBUpdateOne and MongoDBDeleteOne requests, take note that the responses differ if the connection has a log collection.
 
 #### Properties
 - `databaseUri: string`: __Required__ - Connection uri string for the MongoDb deployment. Should be stored using the [_secret](operators/secret.md) operator.
 - `databaseName: string`: Default: Database specified in connection string - The name of the database in the MongoDB deployment.
 - `collection: string`: __Required__ - The name of the MongoDB collection.
-- `changeLog: object`: Log all changes made by write requests to a log collection.
-  - `collection: string`: __Required__ - The name of the collection change log records are written to.
-  - `meta: object`: Additional data to include in every change log record, for example the user making the change.
 - `read: boolean`: Default: `true` - Allow read operations like find on the collection.
 - `write: boolean`: Default: `false` - Allow write operations like update on the collection.
 - `options: object`: See the [driver documentation](https://mongodb.github.io/node-mongodb-native/4.0/interfaces/mongoclientoptions.html) for more information.
@@ -108,13 +105,10 @@ Request types:
   - MongoDBDeleteOne
   - MongoDBFind
   - MongoDBFindOne
-  - MongoDBInsertConsecutiveId
   - MongoDBInsertMany
-  - MongoDBInsertManyConsecutiveIds
   - MongoDBInsertOne
   - MongoDBUpdateMany
   - MongoDBUpdateOne
-  - MongoDBVersionedUpdateOne
 
 
 ### MongoDBAggregation
@@ -297,7 +291,7 @@ requests:
 ### MongoDBDeleteOne
 
 The `MongoDBDeleteOne` request deletes a single document in the collection specified in the connectionId. It requires a filter, which is written in the query syntax, to select a document to delete. It will delete the first document that matches the filter.
-> When the connection has a log collection, a findOneAndDelete operation is performed instead of the standard deleteOne operation so the deleted document can be captured in the change log. The response shape is the same in both cases.
+> MongoDBDeleteOne response differs when the connection has a log collection. When a log collection is set on the connection, a findOneAndDelete operation is performed compared to the standard deleteOne operation.
 
 #### Properties
 - `filter: object`: __Required__ - The filter used to select the document to update.
@@ -471,34 +465,6 @@ requests:
           _payload: _id
 ```
 
-### MongoDBInsertConsecutiveId
-
-The `MongoDBInsertConsecutiveId` request inserts a single document into the collection specified in the connectionId, assigning a sequential, human-readable `_id` like `INV0001`. The id is built from a prefix and the next consecutive number for that prefix, zero-padded to `length` digits. The id read and the insert run inside a transaction so concurrent requests cannot claim the same id.
-
-> Transactions require MongoDB to run as a replica set. Standalone deployments are not supported by this request.
-
-#### Properties
-- `doc: object`: __Required__ - The document to be inserted. The `_id` is assigned by the request.
-- `prefix: string`: __Required__ - Prefix to add to the id, for example `INV`.
-- `length: number`: The numeric part of the id is zero-padded to this number of digits. If omitted, the number is not padded.
-- `options: object`: Optional settings passed to the insert. See the [driver documentation](https://mongodb.github.io/node-mongodb-native/4.0/classes/collection.html#insertone) for more information.
-
-#### Examples
-
-###### Insert an invoice with a sequential id (INV0001, INV0002, ...):
-```yaml
-requests:
-  - id: insert_invoice
-    type: MongoDBInsertConsecutiveId
-    connectionId: my_mongodb_collection_id
-    properties:
-      prefix: INV
-      length: 4
-      doc:
-        amount:
-          _state: amount
-```
-
 ### MongoDBInsertMany
 
 The `MongoDBInsertMany` request inserts an array of documents into the collection specified in the connectionId. If a `_id` field is not specified on a document, a MongoDB `ObjectID` will be generated.
@@ -546,33 +512,6 @@ requests:
 
 ```
 
-### MongoDBInsertManyConsecutiveIds
-
-The `MongoDBInsertManyConsecutiveIds` request inserts an array of documents into the collection specified in the connectionId, assigning each document a sequential, human-readable `_id` like `INV0001`. Ids continue from the highest existing id for the prefix. The id read and the insert run inside a transaction so concurrent requests cannot claim the same ids.
-
-> Transactions require MongoDB to run as a replica set. Standalone deployments are not supported by this request.
-
-#### Properties
-- `docs: object[]`: __Required__ - The documents to be inserted. The `_id` values are assigned by the request.
-- `prefix: string`: __Required__ - Prefix to add to the ids, for example `INV`.
-- `length: number`: The numeric part of each id is zero-padded to this number of digits. If omitted, the numbers are not padded.
-- `options: object`: Optional settings passed to the insert. See the [driver documentation](https://mongodb.github.io/node-mongodb-native/4.0/classes/collection.html#insertmany) for more information.
-
-#### Examples
-
-###### Insert order lines with sequential ids:
-```yaml
-requests:
-  - id: insert_order_lines
-    type: MongoDBInsertManyConsecutiveIds
-    connectionId: my_mongodb_collection_id
-    properties:
-      prefix: LINE
-      length: 6
-      docs:
-        _state: order_lines
-```
-
 ### MongoDBInsertOne
 
 The `MongoDBInsertOne` request inserts a document into the collection specified in the connectionId. If a `_id` field is not specified, a MongoDB `ObjectID` will be generated.
@@ -680,15 +619,11 @@ requests:
 ### MongoDBUpdateOne
 
 The `MongoDBUpdateOne` request updates a single document in the collection specified in the connectionId. It requires a filter, which is written in the query syntax, to select a document to update. It will update the first document that matches the filter. If the `upsert` option is set to true, it will insert a new document if no document is found to update.
-
-If no document matches the filter, the request throws `No matching record to update.` — a silent no-op update usually indicates a bug. Set `disableNoMatchError: true` on the request to restore the pre-5.5.0 behavior of returning `matchedCount: 0`. Requests with the `upsert` option never throw this error. Running `lowdefy upgrade` adds `disableNoMatchError: true` to existing requests so upgraded apps keep their behavior.
-
-> When the connection has a log collection, a findOneAndUpdate operation is performed instead of the standard updateOne operation so before and after document snapshots can be captured in the change log. The response shape is the same in both cases.
+> MongoDBUpdateOne response differs when the connection has a log collection. When a log collection is set on the connection, a findOneAndUpdate operation is performed compared to the standard updateOne operation.
 
 #### Properties
 - `filter: object`: __Required__ - The filter used to select the document to update.
 - `update: object | object[]`: __Required__ - The update operations to be applied to the document.
-- `disableNoMatchError: boolean`: Default: `false` - Do not throw an error when no document matches the filter.
 - `options: object`: Optional settings. See the [driver documentation](https://mongodb.github.io/node-mongodb-native/4.0/classes/collection.html#updateone) for more information. Supported settings are:
   - `arrayFilters: object[]`: _Array_ - Array filters for the [`$[<identifier>]`](https://docs.mongodb.com/manual/reference/operator/update/positional-filtered/) array update operator.
   - `authdb: string`: Specifies the authentication information to be used.
@@ -757,47 +692,6 @@ requests:
             _date: now
 ```
 
-### MongoDBVersionedUpdateOne
-
-The `MongoDBVersionedUpdateOne` request updates a single document while preserving the previous version. The matched document is re-inserted under a new `_id`, and the update is applied to the new copy — so the collection keeps a full version history of the document.
-
-If no document matches the filter, the request throws `No matching record to update.`. Set `disableNoMatchError: true` on the request to suppress the error. Requests with the `upsert` update option never throw this error.
-
-> The version insert and the update are separate operations, not a transaction. If the update fails, the inserted version copy remains in the collection.
-
-> When the connection has a log collection, a findOneAndUpdate operation is performed instead of the standard updateOne operation so before and after document snapshots can be captured in the change log. The response shape is the same in both cases.
-
-#### Properties
-- `filter: object`: __Required__ - The filter used to select the document to version and update.
-- `update: object | object[]`: __Required__ - The update operations to be applied to the new copy of the document.
-- `disableNoMatchError: boolean`: Default: `false` - Do not throw an error when no document matches the filter.
-- `options: object`: Optional settings for each underlying operation:
-  - `find: object`: Options for the find one operation. See the [driver documentation](https://mongodb.github.io/node-mongodb-native/4.0/classes/collection.html#findone).
-  - `insert: object`: Options for the insert one operation that creates the version copy. See the [driver documentation](https://mongodb.github.io/node-mongodb-native/4.0/classes/collection.html#insertone).
-  - `update: object`: Options for the update operation. See the [driver documentation](https://mongodb.github.io/node-mongodb-native/4.0/classes/collection.html#updateone).
-
-#### Examples
-
-###### Update a document, keeping the previous version:
-```yaml
-requests:
-  - id: versioned_update
-    type: MongoDBVersionedUpdateOne
-    connectionId: my_mongodb_collection_id
-    payload:
-      doc_id:
-        _state: doc_id
-    properties:
-      filter:
-        doc_id:
-          _payload: doc_id
-        current: true
-      update:
-        $set:
-          status:
-            _state: status
-```
-
 ## Websockets
 
 Websocket types: