@agent-native/core 0.130.1 → 0.131.2

package/corpus/templates/clips/desktop/src/styles.css

@@ -5652,7 +5652,8 @@ body[data-clips-route="recording-pill"] #root {
   opacity: 0.6;
 }
 
-.pill-expand-btn {
+.pill-expand-btn,
+.pill-close-btn {
   margin-left: 4px;
   display: inline-flex;
   height: 28px;
@@ -5667,7 +5668,8 @@ body[data-clips-route="recording-pill"] #root {
   transition: background 120ms;
 }
 
-.pill-expand-btn:hover {
+.pill-expand-btn:hover,
+.pill-close-btn:hover {
   background: rgba(255, 255, 255, 0.1);
 }
 
@@ -5862,6 +5864,44 @@ body[data-clips-route="recording-pill"] #root {
   background: rgba(255, 255, 255, 0.1);
 }
 
+.pill-finished-banner {
+  display: flex;
+  align-items: center;
+  gap: 8px;
+  flex-shrink: 0;
+  margin: 8px 12px 2px;
+  padding: 8px 10px;
+  border: 1px solid rgba(34, 197, 94, 0.45);
+  border-radius: 8px;
+  background: rgba(34, 197, 94, 0.16);
+}
+
+.pill-finished-text {
+  min-width: 0;
+  flex: 1;
+  font-size: 12px;
+  font-weight: 600;
+  line-height: 1.35;
+  color: #86efac;
+}
+
+.pill-finished-open {
+  flex-shrink: 0;
+  padding: 5px 9px;
+  border: none;
+  border-radius: 6px;
+  background: #22c55e;
+  color: #052e16;
+  font-size: 11px;
+  font-weight: 700;
+  cursor: pointer;
+  transition: background 120ms;
+}
+
+.pill-finished-open:hover {
+  background: #4ade80;
+}
+
 .pill-transcript-area {
   min-height: 0;
   flex: 1;

package/corpus/templates/clips/server/db/index.ts

@@ -5,6 +5,7 @@ import { eq } from "drizzle-orm";
 
 import {
   absoluteUrl,
+  recordingShareEmailExtras,
   recordingShareHeroHtml,
 } from "../lib/share-email-hero.js";
 import * as schema from "./schema.js";
@@ -58,6 +59,11 @@ registerShareableResource({
     replyTo: ctx.sender.email,
   }),
   getHeroHtml: (recording, ctx) => recordingShareHeroHtml(recording, ctx),
+  getShareEmailExtras: (_recording, ctx) =>
+    recordingShareEmailExtras({
+      href: ctx.href,
+      senderEmail: ctx.sender.email,
+    }),
   getDb,
   ownerAccessIgnoresOrg: true,
 });

package/corpus/templates/clips/server/jobs/transactional-emails.ts

@@ -32,6 +32,7 @@ import {
 
 const JOB_INTERVAL_MS = 60_000;
 const RECONCILIATION_BATCH_SIZE = 100;
+const RECONCILIATION_WRITE_CONCURRENCY = 8;
 const RECIPIENT_SHARE_BATCH_SIZE = 2;
 const DELIVERY_BATCH_SIZE = 25;
 const REMINDER_DELAY_MS = 48 * 60 * 60 * 1000;
@@ -77,6 +78,27 @@ type ReconciliationCursor = {
   id: string;
 };
 
+async function mapWithConcurrency<Value, Result>(
+  values: readonly Value[],
+  mapper: (value: Value) => Promise<Result>,
+): Promise<Result[]> {
+  const results = new Array<Result>(values.length);
+  let nextIndex = 0;
+  await Promise.all(
+    Array.from(
+      { length: Math.min(RECONCILIATION_WRITE_CONCURRENCY, values.length) },
+      async () => {
+        while (nextIndex < values.length) {
+          const index = nextIndex;
+          nextIndex += 1;
+          results[index] = await mapper(values[index]);
+        }
+      },
+    ),
+  );
+  return results;
+}
+
 export type TransactionalEmailStore = Pick<
   typeof transactionalEmailStore,
   | "ensureEnabledAt"
@@ -608,19 +630,21 @@ async function reconcileDueReminders(
     cursor,
     limit,
   );
-  let enqueued = 0;
-  for (const rawShare of page) {
-    const share = normalizeShare(rawShare);
-    if (!share) continue;
-    const result = await store.enqueue(`unviewed-reminder:${share.id}`, {
-      type: "unviewed-reminder",
-      recipient: share.recipient,
-      recordingIds: [share.recordingId],
-      shareId: share.id,
-      requestedBy: share.createdBy,
-    });
-    if (result.created) enqueued += 1;
-  }
+  const enqueued = (
+    await mapWithConcurrency(page, async (rawShare) => {
+      const share = normalizeShare(rawShare);
+      if (!share) return false;
+      return (
+        await store.enqueue(`unviewed-reminder:${share.id}`, {
+          type: "unviewed-reminder",
+          recipient: share.recipient,
+          recordingIds: [share.recordingId],
+          shareId: share.id,
+          requestedBy: share.createdBy,
+        })
+      ).created;
+    })
+  ).filter(Boolean).length;
   const lastShare = page[page.length - 1];
   return {
     enqueued,
@@ -892,16 +916,16 @@ export async function runTransactionalEmailsOnce(
         });
       }
     }
-    for (const job of jobs) {
-      if (
-        job.state === "pending" &&
-        (job.type === "first-view" ||
-          job.type === "first-import" ||
-          job.type === "unviewed-reminder")
-      ) {
-        await store.transition(job.logicalKey, ["pending"], "ready");
-      }
-    }
+    await mapWithConcurrency(
+      jobs.filter(
+        (job) =>
+          job.state === "pending" &&
+          (job.type === "first-view" ||
+            job.type === "first-import" ||
+            job.type === "unviewed-reminder"),
+      ),
+      (job) => store.transition(job.logicalKey, ["pending"], "ready"),
+    );
 
     if (!(await (dependencies.emailConfigured ?? isEmailConfigured)())) {
       return result;

package/corpus/templates/clips/server/lib/share-email-hero.ts

@@ -1,7 +1,9 @@
 import {
+  emailLink,
   getAppProductionUrl,
   withConfiguredAppBasePath,
 } from "@agent-native/core/server";
+import type { ShareEmailExtras } from "@agent-native/core/sharing";
 
 /**
  * Origin plus the configured mount path. Deployments served under
@@ -52,6 +54,37 @@ function isHttpUrl(value: string): boolean {
   }
 }
 
+/**
+ * Clips-specific body for the share-notification email: the AI companion CTA,
+ * the copyable agent link, and the closing note that routes replies to the
+ * person who shared the clip.
+ */
+export function recordingShareEmailExtras(ctx: {
+  href: string;
+  senderEmail: string;
+}): ShareEmailExtras {
+  const summarizeUrl = new URL(ctx.href);
+  summarizeUrl.searchParams.set("panel", "agent");
+  return {
+    // The heading already says who shared what, so the clip thumbnail follows
+    // it directly.
+    paragraphs: [],
+    secondaryCta: { label: "Summarize with AI", url: summarizeUrl.toString() },
+    linkBlock: {
+      intro: "Copy and paste this link for your own AI agent to summarize:",
+      url: ctx.href,
+      placement: "after-cta",
+    },
+    closingParagraphs: [
+      "Clips is a 100% free, open-source, Agent-Native app for sharing screengrabs with friends and colleagues. No download required.",
+      `Just reply to this email if you want to get back to ${emailLink(
+        ctx.senderEmail,
+        `mailto:${ctx.senderEmail}`,
+      )} directly.`,
+    ],
+  };
+}
+
 export type ShareHeroRecording = {
   thumbnailUrl?: string | null;
   animatedThumbnailUrl?: string | null;

package/corpus/templates/clips/server/lib/transactional-email-store.ts

@@ -180,6 +180,7 @@ export type TransactionalEmailStoreOptions = {
     afterInitialJobTempSynced?: () => Promise<void>;
     afterStaleLockSnapshot?: () => Promise<void>;
     afterJobLockAcquired?: () => Promise<void>;
+    afterFreshLockContention?: () => Promise<void>;
   };
 };
 
@@ -462,6 +463,17 @@ export function createTransactionalEmailStore(
         if (await takeoverMarkerBlocks(takeoverFile)) return null;
       } catch (error) {
         if (!isNodeError(error, "EEXIST")) throw error;
+        const existingLock = await stat(file).catch((statError: unknown) => {
+          if (isNodeError(statError, "ENOENT")) return null;
+          throw statError;
+        });
+        if (
+          existingLock &&
+          Date.now() - existingLock.mtimeMs <= LOCK_STALE_MS
+        ) {
+          await testHooks?.afterFreshLockContention?.();
+          return null;
+        }
         ownsTakeover = await acquireTakeoverMarker(ownerFile, takeoverFile);
         if (!ownsTakeover) return null;
         const lockStat = await stat(file).catch(() => null);
@@ -484,12 +496,10 @@ export function createTransactionalEmailStore(
       if (!sameIdentity(await fileIdentity(file), ownerIdentity)) return null;
       return await operation();
     } finally {
-      if (acquired && !ownsTakeover) {
-        ownsTakeover = await acquireTakeoverMarker(ownerFile, takeoverFile);
-      }
-      if (acquired && ownsTakeover) {
-        await unlinkIfIdentity(file, ownerIdentity);
-      }
+      // A holder only releases the inode it acquired. A stale reclaimer may
+      // replace that inode while the original holder is paused; identity-based
+      // release preserves the replacement without a cleanup-time takeover race.
+      if (acquired) await unlinkIfIdentity(file, ownerIdentity);
       if (ownsTakeover) {
         await unlinkIfIdentity(takeoverFile, ownerIdentity);
       }

package/corpus/templates/clips/shared/clips-ai-prefs.ts

@@ -28,7 +28,6 @@ export type ClipsAiPrefs = {
 export type ClipsUserPrefs = ClipsAiPrefs & {
   defaultPlaybackSpeed?: string;
   emailNotifications?: boolean;
-  displayName?: string;
   transcriptCleanupEnabled?: boolean;
 };
 

package/corpus/templates/content/.agents/skills/agent-native-toolkit/SKILL.md

@@ -117,6 +117,11 @@ in the moment of agent use.
   missing-secret states, OAuth grants, and provider connection health.
 - **Agent UX kit**: sidebar, composer, staged context, mentions, voice, human
   approval, generative UI, progress, and screen-state exposure.
+- **Custom block kit**: optional extension creation, viewer chrome, slots, and
+  promotion affordances. Apps must opt in; Core keeps the sandbox, SQL storage,
+  access checks, and compatibility routes, while Toolkit owns reusable adoption
+  UI. Analytics may expose this as one-off **Custom Blocks**; durable behavior
+  should be promoted to app code.
 - **Chat history kit**: presentational chat lists and recent-chat rails belong
   in Toolkit; Core keeps thread persistence, agent execution, transport, and
   page-to-sidebar handoff. Use Toolkit's `ChatHistoryRail` for the standard

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

@@ -0,0 +1,103 @@
+---
+name: content-product-development
+description: >-
+  Product contracts and proof boundaries for Agent Native Content. Use when
+  planning, implementing, reviewing, testing, or documenting Content behavior
+  or shared framework behavior that changes Content.
+scope: dev
+metadata:
+  internal: true
+---
+
+# Develop Agent Native Content
+
+## Rule
+
+Before changing Content, identify the user workflow, Feature, and atomic
+Capabilities the work touches. Implement through Content's shared primitives,
+then prove the affected workflow before claiming a Capability or Feature is
+complete.
+
+The roadmap is direction, not a substitute for current code. Current code is
+evidence, not permission to invent a conflicting product contract.
+
+## Retrieve the right context
+
+The repository source of truth lives in `templates/content/docs/product/`.
+
+1. Read [architecture.md](../../../docs/product/architecture.md).
+2. Find the workflow in [roadmap.md](../../../docs/product/roadmap.md), or search
+   the Feature records:
+
+   ```sh
+   rg -n "<workflow or Feature>" templates/content/docs/product/features
+   ```
+
+3. Read the Feature's required and enhancing Capability records by stable ID,
+   including each record's workflow, contract, boundaries, acceptance stories,
+   current evidence, proof plan, and open questions. The encyclopedia row is an
+   index, not enough implementation context.
+4. Inspect the current implementation, tests, feature flags, and provider state.
+
+Load only the relevant records. Do not paste the encyclopedia into the context
+and hope the important sentence floats to the top.
+
+If a required record is missing or still contains only the legacy generated
+shell, name the missing or incomplete ID. Do not manufacture edge behavior from
+its one-line summary. A narrow bug fix may still proceed when tests and existing
+behavior make the contract unambiguous; record the context gap in the handoff.
+
+## Classify the change
+
+| Lane | Meaning | Response |
+| --- | --- | --- |
+| Contract repair | Existing behavior violates an accepted contract | Fix the smallest coherent path and prove the regression |
+| Contract fulfillment | Work implements or hardens an incomplete Capability | Follow its dependencies and proof requirements |
+| Local refinement | Reversible polish that does not change the promise | Implement without manufacturing a strategy meeting |
+| Product decision candidate | Work changes identity, access, source truth, a shared primitive, or the user promise | Preserve the user problem and tradeoff for review before making it architecture |
+
+The catalog welcomes new ideas. It prevents accidental decisions; it does not
+require a permission slip for every useful bug fix.
+
+## Preserve the architecture
+
+- Stable objects may have many Views, memberships, embeds, and source mappings.
+- People, agents, automations, APIs, and UI use one typed Action surface.
+- Access applies before search, traversal, Queries, aggregates, exports, or AI.
+- Sources declare truth and write-back policy; unknown provider data survives.
+- Meaningful change preserves actor, origin, history, recovery, and review.
+- Content remains portable and does not demand custody of connected originals.
+- Donor code and completed dependencies do not prove a whole contract.
+
+Load the domain skill for the work, especially `actions`, `security`, `sharing`,
+`storing-data`, `portability`, `real-time-collab`, or `real-time-sync`.
+
+## Prove and record the result
+
+Use the affected Capability's proof requirements and the Feature's example
+workflow. Read [references/verification.md](references/verification.md) for the
+cross-surface matrix.
+
+A Capability becomes `verified` only when its complete atomic contract passes.
+A Feature becomes `available` only when every required Capability is verified
+and its complete example workflow passes end to end. Useful machinery remains
+substrate until then.
+
+Update atomic records when work changes a contract, dependency, state, non-goal,
+proof boundary, or accepted Feature workflow. Regenerate projections and run:
+
+```sh
+pnpm guard:content-product-docs --write
+pnpm guard:content-product-docs
+```
+
+## Handoff
+
+```text
+Product context: <Feature and Capability IDs>
+Workflow: <what now works>
+Proof: <tests and real-interface evidence>
+Remaining gaps: <failures or missing evidence>
+Product decisions: <none or accepted/candidate decision>
+Record updates: <files changed or still needed>
+```

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

@@ -0,0 +1,57 @@
+# Content product verification
+
+Choose proof in proportion to the affected contract. Deterministic tests prove
+data and Action semantics; real-interface testing proves that the workflow is
+actually usable.
+
+## Cross-surface matrix
+
+Verify the applicable rows:
+
+| Surface           | Proof question                                                                                             |
+| ----------------- | ---------------------------------------------------------------------------------------------------------- |
+| UI                | Can a person complete the Feature's example workflow through the real interface?                           |
+| Actions           | Can an agent perform the same authorized operations without a second mutation path?                        |
+| Application state | Does the agent receive the focused object, View, selection, and temporary filters the person sees?         |
+| Access            | Do reads, writes, direct links, derived results, public output, and embeds preserve authority?             |
+| Persistence       | Does the result survive reload, retry, interruption, and process boundaries appropriate to the Capability? |
+| History           | Does the record name the actual human, agent, automation, or integration actor and remain recoverable?     |
+| Sources           | Does identity survive refresh and write-back without dropping unknown provider data?                       |
+| Portability       | Does import, export, or static rendering preserve the accepted meaning or report explicit degradation?     |
+| 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?                         |
+
+## Status evidence
+
+- `verified`: current proof covers the complete atomic contract.
+- `failing`: current behavior contradicts the promise.
+- `stale`: prior proof exists but no longer matches the implementation or
+  environment.
+- `in_progress`: implementation is actively being built or hardened.
+- `approved_shape`: the contract is accepted but lacks implementation or proof.
+- `exploring`: a material boundary remains unresolved.
+- `deferred`: the contract is intentionally sequenced later.
+- `superseded`: another record owns future work; follow `superseded_by`.
+
+Never promote a generic Capability because one provider-specific donor works.
+Never promote a Feature because several dependencies landed. The final proof is
+the actual car, not a tasteful arrangement of engine parts on the garage floor.
+
+## Updating the catalog
+
+Change the atomic record first. Keep dependencies complete even when they are
+already verified. Add public-safe evidence only: repository paths, tests, or
+public documentation that proves the claim without private transcripts or
+workspace links.
+
+After editing records:
+
+```sh
+pnpm test:content-product-docs
+pnpm guard:content-product-docs --write
+pnpm guard:content-product-docs
+```
+
+Inspect the generated roadmap and encyclopedia diff. A regenerated projection
+is not an editorial review; make sure the underlying record still says what a
+new contributor needs to know.

package/corpus/templates/content/AGENTS.md

@@ -8,6 +8,8 @@ actions and application state.
 
 Read the relevant skill before deeper work:
 
+- `content-product-development` — accepted product contracts, roadmap context,
+  dependency records, and proof boundaries for any Content change.
 - `content` — Markdown/MDX authoring, local folder sources, databases, intake
   forms, and Slack/A2A artifact replies.
 - `document-editing` — document and comment actions, screen context and IDs,

package/corpus/templates/content/app/components/sidebar/DocumentSidebar.tsx

@@ -7,7 +7,7 @@ import {
   useActionMutation,
   useActionQuery,
 } from "@agent-native/core/client/hooks";
-import { LanguagePicker, useT } from "@agent-native/core/client/i18n";
+import { useT } from "@agent-native/core/client/i18n";
 import { OrgSwitcher } from "@agent-native/core/client/org";
 import { FeedbackButton } from "@agent-native/core/client/ui";
 import { SidebarFooterActions } from "@agent-native/toolkit/app-shell";
@@ -1610,9 +1610,6 @@ export function DocumentSidebar({
       <TooltipContent side="right">{t("sidebar.search")}</TooltipContent>
     </Tooltip>
   );
-  const translateButton = (
-    <LanguagePicker variant="ghost-icon" label={t("settings.languageLabel")} />
-  );
   const feedbackButton = (
     <FeedbackButton
       variant={collapsed ? "icon" : "sidebar"}
@@ -2141,7 +2138,6 @@ export function DocumentSidebar({
         <SidebarFooterActions
           collapsed
           feedback={feedbackButton}
-          translate={translateButton}
           search={searchButton}
           collapse={collapseButton}
         />
@@ -2387,7 +2383,6 @@ export function DocumentSidebar({
         {isCodeMode ? <DevDatabaseLink /> : null}
         <SidebarFooterActions
           feedback={feedbackButton}
-          translate={translateButton}
           search={searchButton}
           collapse={collapseButton}
           className="px-0 py-0"

package/corpus/templates/content/changelog/2026-07-29-sidebar-footers-now-keep-feedback-search-and-collapse-togeth.md

@@ -0,0 +1,6 @@
+---
+type: improved
+date: 2026-07-29
+---
+
+Sidebar footers now keep Feedback, Search, and Collapse together without a separate language shortcut.

package/corpus/templates/content/docs/product/README.md

@@ -0,0 +1,115 @@
+# Content product knowledge
+
+This folder is the repository source of truth for Agent Native Content's accepted
+product direction. It gives contributors and coding agents enough context to
+change Content without relying on private conversations or a particular
+person's computer.
+
+Start with:
+
+- [Architecture](architecture.md) for the product invariants.
+- [Roadmap](roadmap.md) for the six public Chapters and their complete user
+  workflows.
+- [Capability encyclopedia](encyclopedia.md) for the atomic contracts and
+  dependency graph beneath those workflows.
+
+The roadmap and encyclopedia are deterministic projections. Edit the atomic
+records in `chapters/`, `features/`, and `capabilities/`, then run:
+
+```sh
+pnpm guard:content-product-docs --write
+pnpm guard:content-product-docs
+```
+
+## The record hierarchy
+
+| Record     | Meaning                                                               |
+| ---------- | --------------------------------------------------------------------- |
+| Chapter    | A large public promise and ordering boundary.                         |
+| Feature    | A complete workflow an audience can understand and use.               |
+| Capability | One reusable primitive, surface, or workflow with its own proof gate. |
+| Increment  | A named deepening of one Feature, stored with that Feature.           |
+
+A Feature can require several Capabilities, and one Capability can enable
+several Features. Completion therefore forms a graph rather than a ceremonial
+checklist. Dependencies describe the complete logical contract even when the
+dependency already exists.
+
+## Capability mini-specs
+
+A Capability record must stand on its own. Frontmatter makes the graph
+queryable; the body teaches a source-blind contributor what the contract
+actually means. Version 2 records include:
+
+- **Why this exists:** the human problem, not an architectural noun.
+- **Example workflow:** one concrete end-to-end use case.
+- **Product contract:** settled interactions, identities, authority, failure,
+  deletion, retry, concurrency, or degraded-state behavior that matters for
+  this Capability.
+- **Boundaries and non-goals:** which adjacent Capability owns neighboring
+  concerns and which tempting parallel systems must not be created.
+- **Acceptance stories:** at least two independently named Given/when/then
+  scenarios a developer can execute.
+- **Current evidence:** what the repository actually proves today, what is only
+  reusable donor machinery, and what is missing.
+- **Proof plan:** the deterministic and real-interface evidence required to
+  change the state.
+- **Open questions:** only decisions that are genuinely unresolved. A settled
+  decision omitted by an old summary is not an open question.
+
+Use `primary_user_job` to make the record discoverable by intent. Use several
+concrete `proof_requirements`, not one comma-heavy sentence pretending to be a
+test plan. A mini-spec may add relevant sections, but it must not omit the core
+ones above. These records preserve public product conclusions; private
+conversations, review mechanics, names, local paths, and source links stay out
+of the repository.
+
+## Truthful status
+
+Roadmap status describes a whole Feature:
+
+- `available`: the complete example workflow has current end-to-end proof.
+- `in_validation`: the workflow exists and is being hardened.
+- `partially_implemented`: useful pieces exist, but the workflow is incomplete.
+- `planned`: the shape is approved and ordered.
+- `paused`: work deliberately stopped while its context remains preserved.
+
+Capability state describes one atomic contract:
+
+- `verified`, `failing`, `stale`, `in_progress`, `approved_shape`, `exploring`,
+  `deferred`, or `superseded`.
+
+Donor code and finished dependencies do not make a Feature complete. A Feature
+becomes `available` only when every required Capability is verified and the
+Feature's own example workflow passes end to end.
+
+## Normalization ledger
+
+The original research used a few provisional or partial names. This repository
+normalizes them deliberately:
+
+- The incomplete `content.diff` token and the provisional
+  `content.diff.in-place-review` name resolve to `content.diff.in-place`.
+- The provisional `content.query.typed` name resolves to
+  `content.query.object` for the durable object and `content.view.source-query`
+  for cross-source composition.
+- Presets collapsed into Templates. `content.preset.catalog` remains only as a
+  superseded lineage record.
+- Separate PDF and EPUB product identity collapsed into the shared Reader.
+  `content.reader.documents` points to `content.reader.surface`.
+- Local mode collapsed into governed Sources. `content.source.local-project`
+  points to `content.source.adapters`.
+- The materialized multi-source row-union interface is donor machinery rather
+  than the future product model. `content.source.row-union` points to
+  `content.view.source-query`.
+
+## Change policy
+
+Repairing a bug against an accepted record does not require a new product
+debate. A change to identity, permissions, source truth, shared primitives, or
+the user promise does. Preserve the concrete problem and tradeoff in the pull
+request, then update these records when the decision is accepted.
+
+The catalog is a compass, not a velvet rope. Good small fixes and new ideas are
+welcome; they simply should not arrive disguised as architecture that everyone
+already agreed to.