@agent-native/core-corpus 0.214.0 → 0.216.0

package/corpus/README.md

@@ -32,4 +32,4 @@ rg -n "defineAction|useActionQuery" node_modules/@agent-native/core-corpus/corpu
 
 ## Generated Counts
 
-- template files: 13667
+- template files: 14513

package/corpus/templates/analytics/.agents/skills/actions/references/action-fields.md

@@ -140,6 +140,6 @@ export default defineAction({
 
 When the gate is truthy and the call isn't yet approved, the loop emits an `approval_required` event and **stops the turn — `run()` never executes**. A predicate gates conditionally (e.g. only external recipients) and **fails closed**: a throw is treated as "approval required". It receives its own copy of the prepared snapshot of the validated arguments, defaults applied, and the approval binds to the snapshot's hash, so an approved call runs only with the arguments that were approved (a Date binds by its time). The human approves via the chat UI's Approve affordance, which re-issues the turn with the call's `approvalKey`, and only then does the action run.
 
-Approval is given in the app, so HTTP never grants it. The HTTP action route and the generated Workers entry run a gated call only for the proven app UI (a frontend call from the signed-in user, same origin, holding the short-lived UI capability; `isProvenUiRequest`, the proof `uiOnly` uses) or the app's MCP directory widget. Every other HTTP caller (bearer or API key, MCP OAuth token, org service token, A2A, extension iframe, mobile app) gets `409 approval_required`, and a service identity can never approve. The shared client presents the capability with every write from a signed-in session (minted once per user, reused for nine minutes, never for reads or public pages), so a gated button works on its first request. A call without proof gets `403 ui_capability_required`; the client then re-mints and retries once, which is only the fallback for an expired or rejected capability. Every surface evaluates the gate through `preparedCallNeedsApproval`, so a throwing predicate asks there too. A caller that must run unattended needs a different action, never a bypass of the gate.
+Approval is given in the app, so HTTP never grants it. The HTTP action route and the generated Workers entry run a gated call only for the proven app UI (a frontend call from the signed-in user, same origin, holding the short-lived UI capability; `isProvenUiRequest`, the proof `uiOnly` uses) or the app's MCP directory widget. Every other direct HTTP caller (bearer or API key, MCP OAuth token, org service token, extension iframe, or mobile app) gets `409 approval_required`, and a service identity can never approve. A2A tasks use their separate approval flow. The task pauses until its owner approves, then replays the approved tool call under its approval lease. The shared client presents the capability with every write from a signed-in session (minted once per user, reused for nine minutes, never for reads or public pages), so a gated button works on its first request. A call without proof gets `403 ui_capability_required`; the client then re-mints and retries once, which is only the fallback for an expired or rejected capability. The agent loop, plan mode registry, HTTP action route, generated Workers entry, and MCP dispatch evaluate the gate through `preparedCallNeedsApproval`, so a throwing predicate asks there too. The local `pnpm action ...` CLI calls `handler.run()` directly and does not evaluate `needsApproval`. Treat it as a local development tool, not an approval boundary. A caller that must run unattended needs a different action, never a bypass of the gate.
 
 **Keep approvals rare** — the default is off and almost every action should leave it off. The canonical example is Mail's `send-email` (`needsApproval: true`). See the `security` skill and the Human Approval doc.

package/corpus/templates/analytics/CHANGELOG.md

@@ -12,6 +12,7 @@ time from the command menu (Cmd+K → "What's new") or from Settings.
 
 ### Fixed
 
+- Session replay quotas count the compressed size Analytics stores, so recordings from other sites no longer use up the daily limit early
 - Preserve unknown replay availability in partial journeys
 
 ## 2026-10-20

package/corpus/templates/analytics/changelog/2026-10-21-session-replay-quotas-count-the-compressed-size-analytics-st.md

@@ -0,0 +1,6 @@
+---
+type: fixed
+date: 2026-10-21
+---
+
+Session replay quotas count the compressed size Analytics stores, so recordings from other sites no longer use up the daily limit early

package/corpus/templates/analytics/server/lib/session-replay.ts

@@ -728,8 +728,15 @@ async function storeReplayChunkBlob(
     ownerEmail: string;
     orgId: string | null;
   },
-): Promise<NormalizedSessionReplayChunk> {
-  if (chunk.storageKind === "blob" || !chunk.inlineData) return chunk;
+): Promise<{
+  chunk: NormalizedSessionReplayChunk;
+  storedBytes: number | null;
+}> {
+  // A blob the client stored itself declares its own size, which the server
+  // never measures, so it reports no stored size.
+  if (chunk.storageKind === "blob" || !chunk.inlineData) {
+    return { chunk, storedBytes: null };
+  }
 
   const gzipBytes = gzipSync(Buffer.from(chunk.inlineData, "utf8"));
   const handle = await putPrivateBlob({
@@ -759,14 +766,17 @@ async function storeReplayChunkBlob(
       );
     }
     warnInlineReplayFallback();
-    return chunk;
+    return { chunk, storedBytes: chunk.byteLength };
   }
 
   return {
-    ...chunk,
-    storageKind: "blob",
-    storageRef: encodeReplayBlobRef(handle),
-    inlineData: null,
+    chunk: {
+      ...chunk,
+      storageKind: "blob",
+      storageRef: encodeReplayBlobRef(handle),
+      inlineData: null,
+    },
+    storedBytes: gzipBytes.byteLength,
   };
 }
 
@@ -1828,12 +1838,21 @@ export async function recordSessionReplayChunks(
       });
     }
   };
+  // The usage row reserves the request's size while chunks upload, so
+  // concurrent ingests see it, then settles at the gzipped bytes actually
+  // stored. Cross-origin uploads arrive uncompressed and would otherwise count
+  // several times what they cost to keep. A gzipped request can settle a
+  // little above its wire size, since each chunk is gzipped on its own. A
+  // request carrying client-stored blobs keeps its reservation, since their
+  // sizes are only what it declares.
+  const reservedBytes = replayIngestByteLength(clampedInput, context);
+  let storedBytes: number | null = 0;
   try {
     await db.insert(schema.sessionReplayIngests).values({
       id: ingestId,
       publicKeyId: key.id,
       recordingId: recording.id,
-      byteLength: replayIngestByteLength(clampedInput, context),
+      byteLength: reservedBytes,
       createdAt: ingestedAt,
       ownerEmail: key.ownerEmail,
       orgId: key.orgId,
@@ -1860,7 +1879,7 @@ export async function recordSessionReplayChunks(
           413,
         );
       }
-      const chunk = await runWithRequestContext(
+      const stored = await runWithRequestContext(
         { userEmail: key.ownerEmail, orgId: key.orgId ?? undefined },
         () =>
           storeReplayChunkBlob(rawChunk, {
@@ -1870,6 +1889,11 @@ export async function recordSessionReplayChunks(
             orgId: key.orgId,
           }),
       );
+      const chunk = stored.chunk;
+      storedBytes =
+        storedBytes === null || stored.storedBytes === null
+          ? null
+          : storedBytes + stored.storedBytes;
       if (rawChunk.storageKind !== "blob" && chunk.storageKind === "blob") {
         const ref = decodeReplayBlobRef(chunk.storageRef);
         if (ref) uploadedBlobHandles.push(ref.handle);
@@ -2060,6 +2084,13 @@ export async function recordSessionReplayChunks(
       }
       errorCount = persistedErrorCount;
       rageClickCount = persistedRageClickCount;
+      const settledBytes = storedBytes ?? reservedBytes;
+      if (settledBytes !== reservedBytes) {
+        await tx
+          .update(schema.sessionReplayIngests)
+          .set({ byteLength: settledBytes })
+          .where(eq(schema.sessionReplayIngests.id, ingestId));
+      }
     });
     uploadedBlobHandles.length = 0;
   } catch (error) {

package/corpus/templates/assets/.agents/skills/actions/references/action-fields.md

@@ -140,6 +140,6 @@ export default defineAction({
 
 When the gate is truthy and the call isn't yet approved, the loop emits an `approval_required` event and **stops the turn — `run()` never executes**. A predicate gates conditionally (e.g. only external recipients) and **fails closed**: a throw is treated as "approval required". It receives its own copy of the prepared snapshot of the validated arguments, defaults applied, and the approval binds to the snapshot's hash, so an approved call runs only with the arguments that were approved (a Date binds by its time). The human approves via the chat UI's Approve affordance, which re-issues the turn with the call's `approvalKey`, and only then does the action run.
 
-Approval is given in the app, so HTTP never grants it. The HTTP action route and the generated Workers entry run a gated call only for the proven app UI (a frontend call from the signed-in user, same origin, holding the short-lived UI capability; `isProvenUiRequest`, the proof `uiOnly` uses) or the app's MCP directory widget. Every other HTTP caller (bearer or API key, MCP OAuth token, org service token, A2A, extension iframe, mobile app) gets `409 approval_required`, and a service identity can never approve. The shared client presents the capability with every write from a signed-in session (minted once per user, reused for nine minutes, never for reads or public pages), so a gated button works on its first request. A call without proof gets `403 ui_capability_required`; the client then re-mints and retries once, which is only the fallback for an expired or rejected capability. Every surface evaluates the gate through `preparedCallNeedsApproval`, so a throwing predicate asks there too. A caller that must run unattended needs a different action, never a bypass of the gate.
+Approval is given in the app, so HTTP never grants it. The HTTP action route and the generated Workers entry run a gated call only for the proven app UI (a frontend call from the signed-in user, same origin, holding the short-lived UI capability; `isProvenUiRequest`, the proof `uiOnly` uses) or the app's MCP directory widget. Every other direct HTTP caller (bearer or API key, MCP OAuth token, org service token, extension iframe, or mobile app) gets `409 approval_required`, and a service identity can never approve. A2A tasks use their separate approval flow. The task pauses until its owner approves, then replays the approved tool call under its approval lease. The shared client presents the capability with every write from a signed-in session (minted once per user, reused for nine minutes, never for reads or public pages), so a gated button works on its first request. A call without proof gets `403 ui_capability_required`; the client then re-mints and retries once, which is only the fallback for an expired or rejected capability. The agent loop, plan mode registry, HTTP action route, generated Workers entry, and MCP dispatch evaluate the gate through `preparedCallNeedsApproval`, so a throwing predicate asks there too. The local `pnpm action ...` CLI calls `handler.run()` directly and does not evaluate `needsApproval`. Treat it as a local development tool, not an approval boundary. A caller that must run unattended needs a different action, never a bypass of the gate.
 
 **Keep approvals rare** — the default is off and almost every action should leave it off. The canonical example is Mail's `send-email` (`needsApproval: true`). See the `security` skill and the Human Approval doc.

package/corpus/templates/brain/.agents/skills/actions/references/action-fields.md

@@ -140,6 +140,6 @@ export default defineAction({
 
 When the gate is truthy and the call isn't yet approved, the loop emits an `approval_required` event and **stops the turn — `run()` never executes**. A predicate gates conditionally (e.g. only external recipients) and **fails closed**: a throw is treated as "approval required". It receives its own copy of the prepared snapshot of the validated arguments, defaults applied, and the approval binds to the snapshot's hash, so an approved call runs only with the arguments that were approved (a Date binds by its time). The human approves via the chat UI's Approve affordance, which re-issues the turn with the call's `approvalKey`, and only then does the action run.
 
-Approval is given in the app, so HTTP never grants it. The HTTP action route and the generated Workers entry run a gated call only for the proven app UI (a frontend call from the signed-in user, same origin, holding the short-lived UI capability; `isProvenUiRequest`, the proof `uiOnly` uses) or the app's MCP directory widget. Every other HTTP caller (bearer or API key, MCP OAuth token, org service token, A2A, extension iframe, mobile app) gets `409 approval_required`, and a service identity can never approve. The shared client presents the capability with every write from a signed-in session (minted once per user, reused for nine minutes, never for reads or public pages), so a gated button works on its first request. A call without proof gets `403 ui_capability_required`; the client then re-mints and retries once, which is only the fallback for an expired or rejected capability. Every surface evaluates the gate through `preparedCallNeedsApproval`, so a throwing predicate asks there too. A caller that must run unattended needs a different action, never a bypass of the gate.
+Approval is given in the app, so HTTP never grants it. The HTTP action route and the generated Workers entry run a gated call only for the proven app UI (a frontend call from the signed-in user, same origin, holding the short-lived UI capability; `isProvenUiRequest`, the proof `uiOnly` uses) or the app's MCP directory widget. Every other direct HTTP caller (bearer or API key, MCP OAuth token, org service token, extension iframe, or mobile app) gets `409 approval_required`, and a service identity can never approve. A2A tasks use their separate approval flow. The task pauses until its owner approves, then replays the approved tool call under its approval lease. The shared client presents the capability with every write from a signed-in session (minted once per user, reused for nine minutes, never for reads or public pages), so a gated button works on its first request. A call without proof gets `403 ui_capability_required`; the client then re-mints and retries once, which is only the fallback for an expired or rejected capability. The agent loop, plan mode registry, HTTP action route, generated Workers entry, and MCP dispatch evaluate the gate through `preparedCallNeedsApproval`, so a throwing predicate asks there too. The local `pnpm action ...` CLI calls `handler.run()` directly and does not evaluate `needsApproval`. Treat it as a local development tool, not an approval boundary. A caller that must run unattended needs a different action, never a bypass of the gate.
 
 **Keep approvals rare** — the default is off and almost every action should leave it off. The canonical example is Mail's `send-email` (`needsApproval: true`). See the `security` skill and the Human Approval doc.

package/corpus/templates/calendar/.agents/skills/actions/references/action-fields.md

@@ -140,6 +140,6 @@ export default defineAction({
 
 When the gate is truthy and the call isn't yet approved, the loop emits an `approval_required` event and **stops the turn — `run()` never executes**. A predicate gates conditionally (e.g. only external recipients) and **fails closed**: a throw is treated as "approval required". It receives its own copy of the prepared snapshot of the validated arguments, defaults applied, and the approval binds to the snapshot's hash, so an approved call runs only with the arguments that were approved (a Date binds by its time). The human approves via the chat UI's Approve affordance, which re-issues the turn with the call's `approvalKey`, and only then does the action run.
 
-Approval is given in the app, so HTTP never grants it. The HTTP action route and the generated Workers entry run a gated call only for the proven app UI (a frontend call from the signed-in user, same origin, holding the short-lived UI capability; `isProvenUiRequest`, the proof `uiOnly` uses) or the app's MCP directory widget. Every other HTTP caller (bearer or API key, MCP OAuth token, org service token, A2A, extension iframe, mobile app) gets `409 approval_required`, and a service identity can never approve. The shared client presents the capability with every write from a signed-in session (minted once per user, reused for nine minutes, never for reads or public pages), so a gated button works on its first request. A call without proof gets `403 ui_capability_required`; the client then re-mints and retries once, which is only the fallback for an expired or rejected capability. Every surface evaluates the gate through `preparedCallNeedsApproval`, so a throwing predicate asks there too. A caller that must run unattended needs a different action, never a bypass of the gate.
+Approval is given in the app, so HTTP never grants it. The HTTP action route and the generated Workers entry run a gated call only for the proven app UI (a frontend call from the signed-in user, same origin, holding the short-lived UI capability; `isProvenUiRequest`, the proof `uiOnly` uses) or the app's MCP directory widget. Every other direct HTTP caller (bearer or API key, MCP OAuth token, org service token, extension iframe, or mobile app) gets `409 approval_required`, and a service identity can never approve. A2A tasks use their separate approval flow. The task pauses until its owner approves, then replays the approved tool call under its approval lease. The shared client presents the capability with every write from a signed-in session (minted once per user, reused for nine minutes, never for reads or public pages), so a gated button works on its first request. A call without proof gets `403 ui_capability_required`; the client then re-mints and retries once, which is only the fallback for an expired or rejected capability. The agent loop, plan mode registry, HTTP action route, generated Workers entry, and MCP dispatch evaluate the gate through `preparedCallNeedsApproval`, so a throwing predicate asks there too. The local `pnpm action ...` CLI calls `handler.run()` directly and does not evaluate `needsApproval`. Treat it as a local development tool, not an approval boundary. A caller that must run unattended needs a different action, never a bypass of the gate.
 
 **Keep approvals rare** — the default is off and almost every action should leave it off. The canonical example is Mail's `send-email` (`needsApproval: true`). See the `security` skill and the Human Approval doc.

package/corpus/templates/chat/.agents/skills/actions/references/action-fields.md

@@ -140,6 +140,6 @@ export default defineAction({
 
 When the gate is truthy and the call isn't yet approved, the loop emits an `approval_required` event and **stops the turn — `run()` never executes**. A predicate gates conditionally (e.g. only external recipients) and **fails closed**: a throw is treated as "approval required". It receives its own copy of the prepared snapshot of the validated arguments, defaults applied, and the approval binds to the snapshot's hash, so an approved call runs only with the arguments that were approved (a Date binds by its time). The human approves via the chat UI's Approve affordance, which re-issues the turn with the call's `approvalKey`, and only then does the action run.
 
-Approval is given in the app, so HTTP never grants it. The HTTP action route and the generated Workers entry run a gated call only for the proven app UI (a frontend call from the signed-in user, same origin, holding the short-lived UI capability; `isProvenUiRequest`, the proof `uiOnly` uses) or the app's MCP directory widget. Every other HTTP caller (bearer or API key, MCP OAuth token, org service token, A2A, extension iframe, mobile app) gets `409 approval_required`, and a service identity can never approve. The shared client presents the capability with every write from a signed-in session (minted once per user, reused for nine minutes, never for reads or public pages), so a gated button works on its first request. A call without proof gets `403 ui_capability_required`; the client then re-mints and retries once, which is only the fallback for an expired or rejected capability. Every surface evaluates the gate through `preparedCallNeedsApproval`, so a throwing predicate asks there too. A caller that must run unattended needs a different action, never a bypass of the gate.
+Approval is given in the app, so HTTP never grants it. The HTTP action route and the generated Workers entry run a gated call only for the proven app UI (a frontend call from the signed-in user, same origin, holding the short-lived UI capability; `isProvenUiRequest`, the proof `uiOnly` uses) or the app's MCP directory widget. Every other direct HTTP caller (bearer or API key, MCP OAuth token, org service token, extension iframe, or mobile app) gets `409 approval_required`, and a service identity can never approve. A2A tasks use their separate approval flow. The task pauses until its owner approves, then replays the approved tool call under its approval lease. The shared client presents the capability with every write from a signed-in session (minted once per user, reused for nine minutes, never for reads or public pages), so a gated button works on its first request. A call without proof gets `403 ui_capability_required`; the client then re-mints and retries once, which is only the fallback for an expired or rejected capability. The agent loop, plan mode registry, HTTP action route, generated Workers entry, and MCP dispatch evaluate the gate through `preparedCallNeedsApproval`, so a throwing predicate asks there too. The local `pnpm action ...` CLI calls `handler.run()` directly and does not evaluate `needsApproval`. Treat it as a local development tool, not an approval boundary. A caller that must run unattended needs a different action, never a bypass of the gate.
 
 **Keep approvals rare** — the default is off and almost every action should leave it off. The canonical example is Mail's `send-email` (`needsApproval: true`). See the `security` skill and the Human Approval doc.

package/corpus/templates/clips/.agents/skills/actions/references/action-fields.md

@@ -140,6 +140,6 @@ export default defineAction({
 
 When the gate is truthy and the call isn't yet approved, the loop emits an `approval_required` event and **stops the turn — `run()` never executes**. A predicate gates conditionally (e.g. only external recipients) and **fails closed**: a throw is treated as "approval required". It receives its own copy of the prepared snapshot of the validated arguments, defaults applied, and the approval binds to the snapshot's hash, so an approved call runs only with the arguments that were approved (a Date binds by its time). The human approves via the chat UI's Approve affordance, which re-issues the turn with the call's `approvalKey`, and only then does the action run.
 
-Approval is given in the app, so HTTP never grants it. The HTTP action route and the generated Workers entry run a gated call only for the proven app UI (a frontend call from the signed-in user, same origin, holding the short-lived UI capability; `isProvenUiRequest`, the proof `uiOnly` uses) or the app's MCP directory widget. Every other HTTP caller (bearer or API key, MCP OAuth token, org service token, A2A, extension iframe, mobile app) gets `409 approval_required`, and a service identity can never approve. The shared client presents the capability with every write from a signed-in session (minted once per user, reused for nine minutes, never for reads or public pages), so a gated button works on its first request. A call without proof gets `403 ui_capability_required`; the client then re-mints and retries once, which is only the fallback for an expired or rejected capability. Every surface evaluates the gate through `preparedCallNeedsApproval`, so a throwing predicate asks there too. A caller that must run unattended needs a different action, never a bypass of the gate.
+Approval is given in the app, so HTTP never grants it. The HTTP action route and the generated Workers entry run a gated call only for the proven app UI (a frontend call from the signed-in user, same origin, holding the short-lived UI capability; `isProvenUiRequest`, the proof `uiOnly` uses) or the app's MCP directory widget. Every other direct HTTP caller (bearer or API key, MCP OAuth token, org service token, extension iframe, or mobile app) gets `409 approval_required`, and a service identity can never approve. A2A tasks use their separate approval flow. The task pauses until its owner approves, then replays the approved tool call under its approval lease. The shared client presents the capability with every write from a signed-in session (minted once per user, reused for nine minutes, never for reads or public pages), so a gated button works on its first request. A call without proof gets `403 ui_capability_required`; the client then re-mints and retries once, which is only the fallback for an expired or rejected capability. The agent loop, plan mode registry, HTTP action route, generated Workers entry, and MCP dispatch evaluate the gate through `preparedCallNeedsApproval`, so a throwing predicate asks there too. The local `pnpm action ...` CLI calls `handler.run()` directly and does not evaluate `needsApproval`. Treat it as a local development tool, not an approval boundary. A caller that must run unattended needs a different action, never a bypass of the gate.
 
 **Keep approvals rare** — the default is off and almost every action should leave it off. The canonical example is Mail's `send-email` (`needsApproval: true`). See the `security` skill and the Human Approval doc.

package/corpus/templates/community/qr/package.json

@@ -11,7 +11,7 @@
     "typecheck": "tsc --noEmit"
   },
   "dependencies": {
-    "@agent-native/core": "^0.214.0",
+    "@agent-native/core": "^0.216.0",
     "postgres": "^3.4.9",
     "qrcode": "^1.5.4",
     "zod": "^4.6.7"

package/corpus/templates/content/.agents/skills/actions/references/action-fields.md

@@ -140,6 +140,6 @@ export default defineAction({
 
 When the gate is truthy and the call isn't yet approved, the loop emits an `approval_required` event and **stops the turn — `run()` never executes**. A predicate gates conditionally (e.g. only external recipients) and **fails closed**: a throw is treated as "approval required". It receives its own copy of the prepared snapshot of the validated arguments, defaults applied, and the approval binds to the snapshot's hash, so an approved call runs only with the arguments that were approved (a Date binds by its time). The human approves via the chat UI's Approve affordance, which re-issues the turn with the call's `approvalKey`, and only then does the action run.
 
-Approval is given in the app, so HTTP never grants it. The HTTP action route and the generated Workers entry run a gated call only for the proven app UI (a frontend call from the signed-in user, same origin, holding the short-lived UI capability; `isProvenUiRequest`, the proof `uiOnly` uses) or the app's MCP directory widget. Every other HTTP caller (bearer or API key, MCP OAuth token, org service token, A2A, extension iframe, mobile app) gets `409 approval_required`, and a service identity can never approve. The shared client presents the capability with every write from a signed-in session (minted once per user, reused for nine minutes, never for reads or public pages), so a gated button works on its first request. A call without proof gets `403 ui_capability_required`; the client then re-mints and retries once, which is only the fallback for an expired or rejected capability. Every surface evaluates the gate through `preparedCallNeedsApproval`, so a throwing predicate asks there too. A caller that must run unattended needs a different action, never a bypass of the gate.
+Approval is given in the app, so HTTP never grants it. The HTTP action route and the generated Workers entry run a gated call only for the proven app UI (a frontend call from the signed-in user, same origin, holding the short-lived UI capability; `isProvenUiRequest`, the proof `uiOnly` uses) or the app's MCP directory widget. Every other direct HTTP caller (bearer or API key, MCP OAuth token, org service token, extension iframe, or mobile app) gets `409 approval_required`, and a service identity can never approve. A2A tasks use their separate approval flow. The task pauses until its owner approves, then replays the approved tool call under its approval lease. The shared client presents the capability with every write from a signed-in session (minted once per user, reused for nine minutes, never for reads or public pages), so a gated button works on its first request. A call without proof gets `403 ui_capability_required`; the client then re-mints and retries once, which is only the fallback for an expired or rejected capability. The agent loop, plan mode registry, HTTP action route, generated Workers entry, and MCP dispatch evaluate the gate through `preparedCallNeedsApproval`, so a throwing predicate asks there too. The local `pnpm action ...` CLI calls `handler.run()` directly and does not evaluate `needsApproval`. Treat it as a local development tool, not an approval boundary. A caller that must run unattended needs a different action, never a bypass of the gate.
 
 **Keep approvals rare** — the default is off and almost every action should leave it off. The canonical example is Mail's `send-email` (`needsApproval: true`). See the `security` skill and the Human Approval doc.

package/corpus/templates/content/.agents/skills/content-product-development/references/verification.md

@@ -21,6 +21,42 @@ Verify the applicable rows:
 | Accessibility     | Do keyboard and assistive-technology paths support the primary workflow?                                   |
 | Performance       | Does the workflow stay inside its declared scale, time, memory, and output limits?                         |
 
+### Editor-ready budget (D4)
+
+A lane that touches Content startup compares itself with main before calling
+its PR ready. Serve main and the lane's build on two ports against the same
+fixture account, then run from `templates/content`:
+`node scripts/trace-startup.mjs --compare --main-url <main> --lane-url <lane>`.
+The defaults are the budget: cached `/home` at 1280x800, four alternating blocks
+of seven runs, metric `content-editable:painted`. The lane passes when its p50
+is at most main's p50 plus the gap between main's two block p50s. Paste the
+final `D4 PASS` or `D4 FAIL` line into the PR. A fail is a finding, not a run to
+repeat until it passes; `D4 UNMEASURED` proves nothing, and a run with
+overridden defaults says `(not a D4 run)`.
+
+### Stored-form acceptance (SF-01 to SF-12)
+
+SF-09, migration safety, is checked by the census and backfill scripts' own
+guard tests, which land with those scripts. The rest live here: browser and MCP
+checks in `e2e/stored-form/`, writer checks in `acceptance/*.db.test.ts`. CI
+runs both on each side of the live-body gate, and checks tagged known-loss run
+in steps that report without failing the PR. A lane's fix drops the tag from
+every check it flips, in the same PR, so the
+check blocks every PR after it. A check main fails differently on each side of
+the gate takes `knownLossOnArm` from `e2e/live-body-gate.ts`; a fix that flips
+one arm deletes only that arm's entry. Run the browser checks against the production
+build, which refuses PGlite: serve `.output/server/index.mjs` on Postgres with
+`PING_MESSAGE=<nonce>`, then from `templates/content` run
+`CONTENT_BASE_URL=<url> CONTENT_E2E_SERVER_NONCE=<nonce> CONTENT_LIVE_BODY_GATE=off npx playwright test -c e2e/playwright.config.ts e2e/stored-form/`.
+Global setup refuses a server whose ping answers anything else. A server that
+fails to start leaves its port to whatever else listens there, and without the
+nonce the run would test that server instead.
+Global setup connects one MCP connector for the run, because the device flow
+allows 20 starts a minute; two runs from one checkout at once overwrite each
+other's connector. A change that means to alter what a writer stores with the
+gate off reruns `acceptance/gate-off-stored-bytes.db.test.ts` with `-u` and
+commits the golden diff.
+
 ## Status evidence
 
 - `verified`: current proof covers the complete atomic contract.

package/corpus/templates/content/.agents/skills/document-editing/SKILL.md

@@ -155,6 +155,12 @@ literally empty, pass non-whitespace `initializeContent` instead of `find` or `e
 Initialization rejects whitespace-only and all other nonempty bodies, preserves
 the Markdown bytes exactly, and safely replays an identical retry.
 
+A page in Trash refuses edits with `DOCUMENT_NOT_FOUND`, the same way
+`get-document` refuses to read it, including a page moved to Trash while the
+edit commits. Restore it before editing. A local-folder sync
+(`import-content-source`) leaves a page in Trash unchanged and lists it in
+`skipped`.
+
 ### update-document
 
 Update an existing document's metadata or browser-owned content. External
@@ -167,6 +173,10 @@ pnpm action update-document --id abc123 --title "New Title" --content "New conte
 pnpm action update-document --id abc123 --description "Stable guidance for what belongs on this page"
 ```
 
+A page in Trash refuses `update-document` (except a favorite toggle),
+`restore-document-version` and a Blocks value set with `set-document-property`,
+with `DOCUMENT_NOT_FOUND`, like `edit-document`.
+
 ### Suggested edits
 
 When the user asks to **suggest**, **propose**, or **leave changes for review**,

package/corpus/templates/content/.agents/skills/document-editing/references/databases.md

@@ -180,6 +180,17 @@ checked/unchecked. Users can reorder stacked sort and filter conditions from
 the collection toolbar menus, and sort priority follows the same top-to-bottom
 order shown in the menu.
 
+Filters can be grouped. Rules with `filterGroupId: "advanced"` and no parent
+form the UI's advanced filter; rules with `parentFilterGroupId: "advanced"` and
+their own `filterGroupId` (the UI uses `advanced-<id>`) form a group nested one
+level inside it. The view's `filterMode` combines ungrouped rules with each
+top-level group as one member. A group's And/Or lives on its rules:
+`filterGroupMode` is the mode of the rule's `filterGroupId`, and
+`parentFilterGroupMode` (nested rules only) is the mode of its parent. Write a
+group's mode onto every rule in it; the first rule that stores one wins, and a
+group with none inherits the view's `filterMode`. `update-content-database-view`
+rejects a group mode on a rule without the matching group ID.
+
 New rows created from a filtered UI view inherit simple editable equality and
 checkbox filters as initial property values, resolving option labels back to
 stable option IDs for select, status, and multi-select filters, so a row

package/corpus/templates/content/.agents/skills/notion-integration/SKILL.md

@@ -186,8 +186,10 @@ bold/italic/strike/code/underline/color/background and links, inline + block
 equations, code blocks, dividers, `<empty-block/>`, callouts, toggles, columns,
 tables (header row/column, cell/row colors), images/audio/video/file/pdf, page
 and database references, synced blocks (children preserved), mentions, and
-backslash-escaped special characters. Visual indentation is a block `indent`
-attribute (Tab indents a block, matching Notion).
+backslash-escaped special characters. A list item's, callout's, toggle's,
+column's, or synced block's children sit one tab deeper than its line or tags.
+Visual indentation is a block `indent` attribute (Tab indents a block,
+matching Notion).
 
 ## Sync State
 

package/corpus/templates/content/CHANGELOG.md

@@ -3,12 +3,43 @@
 All notable user-facing changes to Agent-Native Content are documented here. Open it any
 time from the command menu (Cmd+K → "What's new").
 
+## 2026-10-22
+
+### Improved
+
+- Accept remaining and Reject remaining show the result for every suggested edit at once
+- Accepting a group of suggested edits saves faster and adds one page version
+
+### Fixed
+
+- Changes made from a menu or popover, such as an image's alt text, are always saved.
+- Agents can read saved page titles and text after an unrelated icon change fails.
+- Text an agent writes inside a callout, column or synced block without indenting it now shows on the page and survives your edits.
+
 ## 2026-10-21
 
+### Improved
+
+- Suggested edits show an agent's whole reason: open a group to read past the first two lines, and lone edits show the reason above the change
+
 ### Fixed
 
+- Blocks fields keep unconfirmed saves visible, and agent reads handle changing collection fields and older editors reliably
+- Compact HTML table row groups keep their cells, and unsupported block colors are reported during Markdown checks.
+- Suggestions keep refusing unmatched emphasis in stored Markdown
 - Organization favorites include documents shared with the current member
 
+## 2026-10-20
+
+### Improved
+
+- The advanced filter and each filter group inside it have their own And/Or, so a view can match rows like "Status is Done and (Owner is me or Owner is empty)".
+
+### Fixed
+
+- HTML table cells preserve a trailing backslash when opening Markdown.
+- Preserve empty paragraph colors and refuse unsupported inline image and oversized math formatting before content is stored.
+
 ## 2026-10-19
 
 ### Added
@@ -22,6 +53,7 @@ time from the command menu (Cmd+K → "What's new").
 
 ### Fixed
 
+- Fresh document reads require confirmation from every open editor before returning saved content.
 - List views no longer run off the side of the screen on phones
 - Edits made from a block's menu or a table's row and column menus, such as deleting a table, adding a row or turning off the header row, are now saved instead of coming back after a reload
 - Starting a comment puts the cursor in the comment box, ready to type.
@@ -57,10 +89,24 @@ time from the command menu (Cmd+K → "What's new").
 
 - Connected AI assistants can read a page with the edits still open in your editor
 
+### Fixed
+
+- Agents reading a page you have open no longer wait or fail when your edits are already saved
+
 ## 2026-10-16
 
+### Improved
+
+- Opening a page you can edit no longer rebuilds its editor once the live copy connects, so the page holds still and keeps your scroll position.
+
 ### Fixed
 
+- A page open in a tab that shows it's in the trash reopens within seconds when someone restores it.
+- A page restored from Trash returns to its place in its collection, and edits to a page in Trash are refused
+- Agent-written Markdown keeps nested lists indented with spaces, underscore bold and italics, and escaped punctuation
+- Pages moved or imported at the same time can no longer end up under their own sub-pages, under a page in Trash, or with stale sharing
+- Re-importing a Markdown export of a page brings it back as it was, without reporting it as lost, and the import report names any other page fields it leaves out.
+- Saving a page or restoring one of its versions no longer fails when the page is restored or moved to Trash at the same moment, and a page in Trash can't be saved over
 - Opening a page in a new tab while another tab is still saving no longer sends a second save or files a copy to History.
 - Typing steadily in one tab no longer makes another open tab show "This page changed elsewhere" after its edits saved.
 - Reopening a page after someone else renamed it no longer adds a copy of your edits to Version History