@agent-native/core-corpus 0.214.0 → 0.217.0

package/corpus/templates/analytics/shared/output-use.ts

@@ -0,0 +1,205 @@
+/**
+ * "Made it, didn't use it": per app, the output a person makes, the events
+ * that say they made one, and the events that say they used it. Opening an
+ * output never counts as using it; a use shows the output to people or takes
+ * it out of the app.
+ */
+
+/** A use counts only within this many days of the output being made. */
+export const OUTPUT_USE_WINDOW_DAYS = 7;
+export const OUTPUT_USE_WINDOW_MS = OUTPUT_USE_WINDOW_DAYS * 24 * 60 * 60_000;
+/** A presentation shorter than this was a look, not a talk. */
+export const MIN_PRESENTATION_MS = 30_000;
+/** The most outputs one recording lists; the rest are counted, not listed. */
+export const MAX_OUTPUTS_PER_RECORDING = 10;
+/** Output ids are skipped past this length, never cut, like session ids. */
+export const MAX_OUTPUT_ID_LENGTH = 256;
+/** The Sessions URL param naming the app whose unused outputs to find. */
+export const UNUSED_OUTPUT_PARAM = "unused";
+/** Every generator sends this when it makes an output, so it marks an app that makes them. */
+export const OUTPUT_MADE_EVENT = "generation_completed";
+
+type EventProperties = Readonly<Record<string, unknown>>;
+
+export interface OutputUseEvent {
+  eventName: string;
+  qualifies: (properties: EventProperties) => boolean;
+}
+
+export interface OutputUseRule {
+  outputType: string;
+  madeEvents: readonly string[];
+  usedEvents: readonly OutputUseEvent[];
+  /** The output's page, relative to its app's origin. */
+  outputPath: (outputId: string) => string;
+}
+
+/** A missing or non-numeric property never proves a use. */
+function atLeast(value: unknown, minimum: number): boolean {
+  return (
+    typeof value === "number" && Number.isFinite(value) && value >= minimum
+  );
+}
+
+export const OUTPUT_USE_RULES = {
+  slides: {
+    outputType: "deck",
+    madeEvents: [OUTPUT_MADE_EVENT],
+    usedEvents: [
+      {
+        // Moving forward at least once means two or more slides were shown,
+        // even when the presentation started mid-deck.
+        eventName: "presentation_ended",
+        qualifies: (properties) =>
+          atLeast(properties.slides_advanced, 1) &&
+          atLeast(properties.duration_ms, MIN_PRESENTATION_MS),
+      },
+      {
+        // `slide_export_started` fires before the export runs, so only a
+        // finished export of a deck with slides counts.
+        eventName: "deck_exported",
+        qualifies: (properties) =>
+          properties.status === "completed" &&
+          atLeast(properties.slide_count, 1),
+      },
+    ],
+    outputPath: (outputId) => `/deck/${encodeURIComponent(outputId)}`,
+  },
+} as const satisfies Record<string, OutputUseRule>;
+
+export type OutputUseApp = keyof typeof OUTPUT_USE_RULES;
+
+export const OUTPUT_USE_APPS = Object.keys(OUTPUT_USE_RULES) as [
+  OutputUseApp,
+  ...OutputUseApp[],
+];
+
+export function isOutputUseApp(value: unknown): value is OutputUseApp {
+  return (
+    typeof value === "string" &&
+    Object.prototype.hasOwnProperty.call(OUTPUT_USE_RULES, value)
+  );
+}
+
+export function outputUseRule(
+  app: string | null | undefined,
+): OutputUseRule | null {
+  return isOutputUseApp(app) ? OUTPUT_USE_RULES[app] : null;
+}
+
+/** Every event name any rule reads, for the catalog and for ingest. */
+export const OUTPUT_USE_EVENT_NAMES: ReadonlySet<string> = new Set(
+  Object.values(OUTPUT_USE_RULES).flatMap((rule: OutputUseRule) => [
+    ...rule.madeEvents,
+    ...rule.usedEvents.map((used) => used.eventName),
+  ]),
+);
+
+export function outputIdOf(properties: EventProperties): string | null {
+  const value = properties.output_id;
+  if (typeof value !== "string") return null;
+  const outputId = value.trim();
+  return outputId && outputId.length <= MAX_OUTPUT_ID_LENGTH ? outputId : null;
+}
+
+/** Where a recording's session ran, as far as the recording shows. */
+export interface OutputRecordingPages {
+  firstUrl: string | null;
+  lastUrl: string | null;
+  /**
+   * Origins the recording's replay key lists. An empty list accepts uploads
+   * from anywhere, so it vouches for no origin and yields no link.
+   */
+  allowedOrigins: readonly string[];
+}
+
+function recordedPage(value: string | null): URL | null {
+  if (!value) return null;
+  try {
+    const url = new URL(value);
+    return url.origin === "null" ? null : url;
+    // coercion-ok: a recording without a parseable URL has no app to link to; the output id still shows.
+  } catch {
+    return null;
+  }
+}
+
+/**
+ * Where a session's output opens: the app origin the session was recorded on,
+ * its mount path, and the output's page. The app checks access when it opens.
+ * A recording's URLs are whatever its uploader sent, so only an origin the
+ * replay key's owner allowed becomes a link; otherwise this is null.
+ */
+export function outputUrl(
+  app: string,
+  outputId: string,
+  recording: OutputRecordingPages,
+): string | null {
+  const rule = outputUseRule(app);
+  if (!rule) return null;
+  const pages = [recording.firstUrl, recording.lastUrl].flatMap((value) => {
+    const page = recordedPage(value);
+    return page ? [page] : [];
+  });
+  // A recording's id lives in its tab's sessionStorage, which is per origin,
+  // so a real recording never spans origins; pages on two came from a forged
+  // upload, and neither can be trusted.
+  const origin = pages[0]?.origin;
+  if (
+    !origin ||
+    pages.some((page) => page.origin !== origin) ||
+    !recording.allowedOrigins.includes(origin)
+  ) {
+    return null;
+  }
+  // A workspace deploy mounts each app at `/<app id>` on one origin, and a
+  // tab's recording follows it from app to app, so either page may show the
+  // mount. Reading that prefix as the mount assumes the app has no route of
+  // its own there (Slides has none). The recording's app label can't decide
+  // it: without a declared app it is the hostname's first label.
+  const mount = `/${app}`;
+  const mounted = pages.some(
+    (page) => page.pathname === mount || page.pathname.startsWith(`${mount}/`),
+  );
+  return `${origin}${mounted ? mount : ""}${rule.outputPath(outputId)}`;
+}
+
+/**
+ * What became of one output made in a session. `open` means the use window
+ * has not closed yet; `unmeasured` means a failed write may have dropped a
+ * use, so it cannot be called unused.
+ */
+export type SessionOutputStatus = "used" | "unused" | "open" | "unmeasured";
+
+export interface SessionOutput {
+  app: OutputUseApp;
+  outputType: string;
+  outputId: string;
+  madeAt: string;
+  useBy: string;
+  status: SessionOutputStatus;
+  /** The first qualifying use's event name, when it was used in time. */
+  usedEvent: string | null;
+  usedAt: string | null;
+  url: string | null;
+}
+
+export interface SessionRecordingOutputs {
+  /**
+   * By recording id, for each requested recording the viewer can read: its
+   * outputs, [] when it made none since coverage began, or null when they
+   * are unknown: it was shared from another tenant, whose events a share does
+   * not grant, its tenant has not started output tracking, or a batch lost in
+   * ingest overlapped it and may have held an output it made. Ids the viewer
+   * cannot read are absent.
+   */
+  outputs: Record<string, SessionOutput[] | null>;
+  /**
+   * How many more outputs a recording made than `outputs` lists, by
+   * recording id; absent when none were left out. Unused outputs are listed
+   * first.
+   */
+  omittedOutputs: Record<string, number>;
+  /** When the viewer's output tracking began, or null before it has. */
+  coverageStartedAt: string | null;
+}

package/corpus/templates/analytics/shared/session-events.ts

@@ -54,6 +54,8 @@ export interface EventCatalogEntry {
   description: string | null;
   automatic: boolean;
   stoppedFiring: boolean;
+  /** Whether "made it, didn't use it" reads this event as making or using its app's output. */
+  outputRole: "made" | "used" | null;
 }
 
 export interface EventCatalogApp {
@@ -61,6 +63,10 @@ export interface EventCatalogApp {
   eventCount: number;
   volume: number;
   onlyAutomaticEvents: boolean;
+  /** The app sent `generation_completed` in range, so it makes outputs. */
+  makesOutputs: boolean;
+  /** Events that count as using this app's output; empty for an app that makes outputs is a catalog gap. */
+  usedItEvents: string[];
 }
 
 export interface EventCatalogResult {

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/calendar/CHANGELOG.md

@@ -3,6 +3,12 @@
 All notable user-facing changes to Agent-Native Calendar are documented here. Open it any
 time from the command menu (Cmd+K → "What's new") or from Settings.
 
+## 2026-10-21
+
+### Fixed
+
+- Calendar skips notification approval for solo events while preserving it for guest invitations and cancellations.
+
 ## 2026-10-19
 
 ### Changed

package/corpus/templates/calendar/actions/create-event.ts

@@ -338,10 +338,8 @@ export default defineAction({
       ),
   }),
   needsApproval: ({ sendUpdates, attendees, eventType, autoDeclineMode }) =>
-    sendUpdates === "all" ||
-    sendUpdates === "externalOnly" ||
-    (sendUpdates === undefined &&
-      (normalizeAttendees(attendees)?.length ?? 0) > 0) ||
+    ((normalizeAttendees(attendees)?.length ?? 0) > 0 &&
+      sendUpdates !== "none") ||
     (eventType === "outOfOffice" && autoDeclineMode !== "declineNone"),
   run: async (args, actionContext?: ActionRunContext) => {
     const email = getRequestUserEmail();

package/corpus/templates/calendar/actions/update-event.ts

@@ -224,16 +224,45 @@ export default defineAction({
       ),
   }),
   toolCallable: false,
-  needsApproval: ({
+  needsApproval: async ({
+    id,
+    accountEmail: requestedAccountEmail,
+    scope,
     sendUpdates,
     notificationMessage,
     targetAccountEmail,
+    attendees,
     addAttendees,
-  }) =>
-    targetAccountEmail !== undefined ||
-    sendUpdates === "all" ||
-    !!notificationMessage?.trim() ||
-    (sendUpdates === undefined && namesGuests(addAttendees)),
+  }) => {
+    if (targetAccountEmail !== undefined || !!notificationMessage?.trim()) {
+      return true;
+    }
+    if (sendUpdates === "none") return false;
+    if (sendUpdates === undefined) return namesGuests(addAttendees);
+
+    if (namesGuests(attendees) || namesGuests(addAttendees)) return true;
+
+    // An empty replacement can still send cancellation notices to removed guests.
+    const ownerEmail = requireActionUserEmail();
+    const accountEmail = await resolveOwnedAccountEmail(
+      resolveGoogleEventAccountEmail(id, requestedAccountEmail),
+      ownerEmail,
+    );
+    let event = await googleCalendar.getEvent(
+      normalizeWritableGoogleEventId(id),
+      {
+        ownerEmail,
+        accountEmail,
+      },
+    );
+    if (scope === "all" && event.recurringEventId) {
+      event = await googleCalendar.getEvent(event.recurringEventId, {
+        ownerEmail,
+        accountEmail,
+      });
+    }
+    return (event.attendees?.length ?? 0) > 0;
+  },
   run: async (args, actionContext?: ActionRunContext) => {
     const ownerEmail = requireActionUserEmail();
     if (args.addGoogleMeet && args.addZoom) {

package/corpus/templates/calendar/changelog/2026-10-21-solo-events-avoid-notification-approval.md

@@ -0,0 +1,6 @@
+---
+type: fixed
+date: 2026-10-21
+---
+
+Calendar skips notification approval for solo events while preserving it for guest invitations and cancellations.

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.217.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
@@ -233,9 +244,12 @@ supports searching property types by label or machine name.
 List views can save an item layout (`itemLayout`) that decides what each row
 shows: a start slot (page icon, a checkbox property, a status property, or
 nothing), the title weight, line 2 (a text, URL, or non-body Blocks property,
-clamped to 1-3 lines), and ordered property IDs for line 3 and the end of the
-row; end values move under the title on narrow screens and empty values take
-no space. Ticking a row's checkbox writes the property through
+or with `source: "page"` the first lines of each row's page, clamped to 1-3
+lines), and ordered property IDs for line 3 and the end of the row; end values
+move under the title on narrow screens and empty values take no space. While
+any list view shows page text, collection reads give each item an `excerpt`
+with the start of its page as plain text; other collections leave page bodies
+out of row reads. Ticking a row's checkbox writes the property through
 `set-document-property` and strikes the title through without moving the row.
 A view without `itemLayout` keeps the default rows. Agents update it with an
 `update-content-database-view` `update` patch on the list view: pass

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,49 @@
 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
+
+- A collection linked to a big GitHub folder fills faster, and pushes to other linked collections aren't held up while it does
+- 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
 
+### Added
+
+- List rows can show the first lines of each page under its title: pick **Page text** for Line 2
+
+### 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
+
+- Builder content sync keeps read and write status accurate when API responses fail.
+- 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 +59,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.
@@ -35,6 +73,7 @@ time from the command menu (Cmd+K → "What's new").
 
 ### Added
 
+- Fill a collection from a GitHub folder through its Sources settings, which an empty collection links to from under its title and which say up front when GitHub can't link and what to do instead. A short preview comes before linking, the collection shows where its pages come from and when they last updated, with a link back to its folder in Sources, and unlinking asks first
 - Connected AI assistants can make a collection from a GitHub folder, or link an empty one: each Markdown file becomes a view-only page, and a sync brings in the latest pushes
 - Make a collection from a GitHub folder in the sidebar's New menu, or fill an empty one from its Sources settings, which say up front when GitHub can't link and what to do instead. A short preview comes before linking, the collection shows where its pages come from and when they last updated, and unlinking asks first
 - Connected AI assistants can link a new collection to a GitHub folder: each Markdown file becomes a view-only page, and a sync brings in the latest pushes
@@ -57,10 +96,25 @@ 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
+
+- Builder Content avoids retrying a write when Builder accepted it but the response could not be saved.
+- 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