@agent-native/core 0.205.0 → 0.206.0-nightly-20261009011246

package/docs/content/observability.mdx

@@ -360,10 +360,21 @@ Tool calls always appear (PostHog derives its tool tags from them), but their
 `capturePrompts`. When those are off the fields are omitted entirely rather than
 sent empty, so an unrecorded prompt is never mistaken for an empty one.
 
-Errors carry a structured `$ai_error` with the terminal code and whether the
-failure was retryable, and exceptions captured during a run carry the run's
-`$ai_trace_id` — so an issue in error tracking and the trace it came from link
-to each other.
+Run failure messages are omitted from Analytics and Monitoring, even when
+content capture is enabled. `$ai_error` carries a terminal code, named cause,
+retryability, and fixed message derived from the code. Tracking omits
+`error_message`, `agent_run_terminal.error_detail`, and failed tool result text.
+The terminal event retains `error_code` and `error_cause`. Local
+`agent_runs.error_detail` and `agent_trace_spans.error_message` remain available
+for owner-scoped debugging in the app's own database.
+
+Run and Builder gateway exceptions retain their type, code, and stack frames,
+with a fixed `Internal Server Error` message and no original message header or nested
+cause text. Monitoring groups these issues by app, type, frame, error code, and
+failure class, rather than names in the original message. Exceptions retain
+`$ai_trace_id` so an issue links to the run's trace. Optional host-owned
+OpenTelemetry run exports also omit failure text and retain `agent.error_code`
+and `agent.error_cause`. Other exception capture keeps its existing behavior.
 
 ### Feedback in PostHog
 
@@ -404,7 +415,7 @@ The agent loop emits three span kinds:
 | `chat {model}`        | per model call             | `gen_ai.provider.name`, `gen_ai.request.model`, `gen_ai.response.model`, `gen_ai.response.finish_reasons`, `gen_ai.usage.*`                                                   |
 | `execute_tool {tool}` | once per action invocation | `gen_ai.tool.name`, `gen_ai.tool.call.id`, plus success/error status                                                                                                          |
 
-Spans are finished with OK/ERROR status and record the error message on failure. Zero/sentinel attribute values are pruned so spans aren't cluttered with noise. This OTel layer is purely additive to the in-house `agent_trace_spans` / `agent_trace_summaries` tables that power the dashboard above — both are produced from the same run events.
+Spans are finished with OK/ERROR status and record a fixed code-derived message on failure. Zero/sentinel attribute values are pruned so spans aren't cluttered with noise. This OTel layer is purely additive to the in-house `agent_trace_spans` / `agent_trace_summaries` tables that power the dashboard above — both are produced from the same run events.
 
 ### Metrics {#otel-metrics}
 

package/docs/content/organizations-teams-permissions.mdx

@@ -186,7 +186,7 @@ import { defineAppRoles } from "@agent-native/core/org-team";
 export const coachAccess = defineAppRoles({
   appId: "coach",
   roles: ["member", "coach-admin"] as const,
-  defaultRole: "member", // display only — never satisfies a guard
+  defaultRole: "member", // display only — does not grant permissions
   label: "Coach role", // column header in TeamPage
   roleLabels: { "coach-admin": "Coach admin" },
   permissions: { approve: ["coach-admin"] },
@@ -272,7 +272,8 @@ null })` means "this run has no user" and does not fall back to the ambient
   an app id the server never declared.
 - **An app admin is not an org admin.** Only org owners and admins may change
   app-role assignments, and nothing in the org handlers reads an app role. The
-  implication does not run in either direction.
+  `allowOrgAdmins` policy can exempt org owners/admins from app-permission
+  checks, but never grants org administration to an app role.
 
 In the browser, `<TeamPage appRoles={coachRoles} />` adds a role column and
 picker next to the org role. The argument is the descriptor — the serializable
@@ -293,6 +294,47 @@ a client that shows the wrong affordance still cannot perform the operation.
 See [Actions → Authorization](/docs/actions-access-control#authorize) for how `authorize`
 differs from `needsApproval` and from row-level access guards.
 
+### Opt-in permission policies
+
+By default, permission guards require an assigned app role. Pass an optional
+second argument to `defineAppRoles` to change that policy on the server. Forms
+uses:
+
+```ts
+const formsAccess = defineAppRoles(
+  {
+    appId: "forms",
+    roles: ["editor", "reviewer"] as const,
+    defaultRole: "editor",
+    permissions: {
+      "forms.edit": ["editor"],
+      "forms.review": ["editor", "reviewer"],
+    },
+  },
+  { unassignedRole: "editor", allowOrgAdmins: true },
+);
+```
+
+- `unassignedRole` uses a declared role's permissions for active members with
+  no app-role assignments. Permission overrides still apply. It does not
+  create an assignment or apply to removed members or assignments containing
+  only retired roles. Clearing all assignments restores this fallback.
+- `allowOrgAdmins: true` lets active organization owners and admins pass any
+  declared app-permission guard, regardless of their app roles or permission
+  overrides. It does not grant organization administration to app admins.
+
+These options affect only `requirePermission` and `assertPermission`.
+`resolve`, `requireAny`, and `assertAny` retain their explicit-assignment
+semantics, and `defaultRole` remains display only. Both options are opt-in;
+omitting them keeps the strict permission policy. Neither option replaces
+resource authorization: keep `accessFilter` and `assertAccess` checks.
+
+Forms keeps existing unassigned members' editing access. An explicitly assigned
+Reviewer can review submissions but cannot edit forms; Editor can do both.
+Resource sharing still determines which forms and submissions they can access.
+
+For organization-owned forms, editing and submission review require active membership in the form's organization unless the sharing system recognizes the caller as its owner. A direct share alone does not satisfy this app-permission check.
+
 ## Resource permissions (sharing RBAC)
 
 Organization roles and resource roles are different systems:

package/docs/content/recurring-jobs.mdx

@@ -127,9 +127,8 @@ The framework includes cron utilities (`isValidCron()` and `describeCron()`) for
 
 ### From the Automations UI
 
-Open **Automations** on the full-page Agent surface, then create a
-**Scheduled** automation. The stable compatibility URL is `/agent#jobs`; the
-hash does not change when the visible tab name changes.
+Open **Settings › Automations**, then create a **Scheduled** automation. Old
+`/agent#jobs` links redirect there.
 
 ### By asking the agent
 
@@ -258,13 +257,10 @@ fire schedules, the **Automations** page says so and names the reason.
 
 ## Debugging a job {#debugging}
 
-- Open the automation's details in **Automations**, or inspect
+- Open the automation's details in **Settings › Automations**, or inspect
   `jobs/<name>.md` in Agent Resources — the frontmatter shows `lastRun`,
   `lastStatus`, `lastError`, and `nextRun`.
-- **Test it without waiting:** open the automation in **Automations** and
-  choose **Run now**. It runs the automation immediately, with its real side
-  effects, and doesn't wait for a scheduler tick, so it also works locally and
-  on hosts without a trigger.
+- **Test it without waiting:** click **Run now** in **Settings › Automations**, or ask the agent to run it (`manage-automations` with `action=run-now`). The job's prompt runs immediately with its real side effects, and `nextRun` doesn't change. The exception is a job the framework paused: a successful run turns it back on and recomputes `nextRun`. Run now doesn't wait for a scheduler tick, so it also works on localhost without `AGENT_NATIVE_ENABLE_LOCAL_RECURRING_JOBS` and on hosts without a scheduler trigger.
 - **Pause it:** flip `enabled: false`. The file stays put, just stops running.
 
 ## Agent tool {#agent-tool}

package/docs/content/template-forms.mdx

@@ -133,3 +133,9 @@ If you run Forms alongside other apps in [Dispatch](/docs/template-dispatch), a
 - [**Actions**](/docs/actions-overview) — the action system powering the builder
 - [**Messaging**](/docs/messaging) — Slack and other submission destinations
 - [**Sharing**](/docs/sharing) — the share-grant model form shares build on
+
+Forms enforces the Team page roles through shared permission guards. Reviewer can review submissions and export or analyze responses, but cannot create, edit, publish, archive, delete, or restore forms. Editor can edit and review. Submission review still requires an editor-level resource share; the app role does not grant access to private forms. Form owners and organization owners/admins bypass the app-role restriction while resource sharing checks remain in force. Members without an assigned role retain Editor permissions for compatibility; assigning Reviewer removes those edit permissions. Authenticated personal deployments without an organization retain their existing resource access. Forms opts into `defineAppRoles(descriptor, { unassignedRole: "editor", allowOrgAdmins: true })`; `defaultRole` remains display-only, and other apps retain strict guards unless they opt in.
+
+Organization-owned forms always use that organization's role policy, even when personal scope or a different organization is selected. Changing a form's visibility also requires edit permission.
+
+For organization-owned forms, editing and submission review require active membership in the form's organization unless the sharing system recognizes the caller as its owner. A direct share alone does not satisfy this app-permission check.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@agent-native/core",
-  "version": "0.205.0",
+  "version": "0.206.0-nightly-20261009011246",
   "description": "The agentic application framework for building autonomous agents with intuitive UIs",
   "homepage": "https://github.com/BuilderIO/agent-native#readme",
   "bugs": {
@@ -183,6 +183,7 @@
     "./client/lazy-chunk-error-boundary": "./dist/client/tombstone/lazy-chunk-error-boundary.js",
     "./client/lazy-chunk-retry-fallback": "./dist/client/tombstone/lazy-chunk-retry-fallback.js",
     "./client/secrets": "./dist/client/secrets.js",
+    "./client/session-replay-privacy": "./dist/client/session-replay-privacy.js",
     "./client/use-db-sync": "./dist/client/use-db-sync.js",
     "./client/zoom-gesture": "./dist/client/zoom-gesture.js",
     "./client/ui": "./dist/client/ui/index.js",
@@ -685,8 +686,8 @@
     "yaml": "^2.9.0",
     "yjs": "^13.6.33",
     "zod": "^4.3.6",
-    "@agent-native/recap-cli": "^0.5.67",
-    "@agent-native/agentkit": "^0.205.0"
+    "@agent-native/agentkit": "^0.206.0-nightly-20261009011246",
+    "@agent-native/recap-cli": "^0.5.68-nightly-20261009011246"
   },
   "devDependencies": {
     "@ai-sdk/anthropic": "^3.0.71",
@@ -756,7 +757,7 @@
     "xlsx": "^0.18.5"
   },
   "peerDependencies": {
-    "@agent-native/core-corpus": ">=0.196.0",
+    "@agent-native/core-corpus": "0.206.0-nightly-20261009011246",
     "@ai-sdk/anthropic": ">=3",
     "@ai-sdk/cohere": ">=3",
     "@ai-sdk/google": ">=3",

package/src/templates/builder-code-starter/server/routes/index.get.ts

@@ -0,0 +1,2 @@
+// Nitro's [...page] catch-all doesn't match "/", and this starter serves its home page at "/".
+export { default } from "./[...page].get.js";