@agent-native/core 0.130.2 → 0.131.2

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/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.

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

@@ -0,0 +1,98 @@
+# Agent Native Content architecture
+
+Agent Native Content is one composable system in which documents, structured
+records, connected data, human collaboration, and agent work share stable
+objects and one Action surface. A person chooses the surface that fits the
+moment: a Page for writing, a Database for governed records, a View for a
+particular presentation, a Query for derived collections, a Reference for
+reuse, an Expression for computation, or a Template for distributing a whole
+working system.
+
+```text
+Stable Pages, Blocks, Blocks fields, Databases, and References
+                              ↓
+              Typed Properties and one expression language
+                              ↓
+                  Queries, Views, and reusable renderers
+                              ↓
+                    Committed Events and typed Actions
+                              ↓
+             History, review, Rules, notifications, and agents
+                              ↓
+                 Templates compose and govern the same graph
+```
+
+Everything uses one Content object graph and one access model. Tasks,
+dashboards, public roadmaps, research systems, blogs, and editorial workflows
+are configurations of these primitives, not parallel engines.
+
+## Product principles
+
+1. **One object, many projections.** Views, memberships, References, embeds,
+   Sources, Graphs, and Canvases do not create accidental copies.
+2. **Simple gestures, composable machinery.** An `@` mention remains a
+   Reference; computation and automation appear only when requested.
+3. **Typed underneath, humane on top.** Values retain stable meaning while
+   renderers change how they look.
+4. **One Action surface.** People, agents, automations, APIs, and the interface
+   use the same permissions, validation, audit behavior, and mutation semantics.
+5. **Access before computation.** Search, Queries, relationships, aggregates,
+   exports, agents, and embedded hosts see only authorized information.
+6. **Source truth is explicit.** Every connected Source declares how reads,
+   synchronization, and write-back behave. Unknown provider data survives
+   faithful round-tripping.
+7. **Events describe committed meaning.** They record actors, origins,
+   causality, and recoverable change rather than every keypress.
+8. **Changes remain reviewable work.** Suggestions, typed diffs, Versions,
+   automation receipts, and History persist instead of evaporating with a
+   dialog.
+9. **Templates fork; they do not possess.** Instances are owned, editable
+   snapshots with provenance and optional reviewed updates.
+10. **Import and export are constitutional.** Collaborative Content may use SQL
+    as its working truth, but people can bring work in, take it out, and keep
+    connected originals where they belong.
+11. **Product status stays honest.** Donor code, dependencies, and isolated
+    tests never prove a whole Capability or Feature by association.
+
+## Object boundaries
+
+- A **Page** owns stable identity, title, access, top-level Properties, and one
+  or more Blocks fields.
+- A **Blocks field** owns one editable rich-content body and its attributable
+  revision history. Comments and Discussion messages use the same grammar
+  without becoming full Pages.
+- A **Database** owns membership, schema, defaults, validation, Rules, and the
+  canonical creation route for its records.
+- A **Query** derives a typed collection from Databases, Sources, or other
+  Queries without owning the source records.
+- A **View** belongs to one Database or Query and owns downstream filtering and
+  presentation. It may be shared or Only me, but it never grants access to its
+  input.
+- A **Relationship** is one canonical typed edge. Relation Properties, inline
+  references, Info, Queries, Graph, and Canvas are projections and editors of
+  that edge.
+- A **Source** is an adapter with explicit capabilities, provenance, access,
+  and synchronization policy. It never becomes a Page's identity or primary
+  Database.
+
+## Change and proof boundaries
+
+Every atomic Capability has its own proof requirements. A Feature is complete
+only when its required Capabilities are verified and its example workflow works
+end to end through the real interface and Actions. Existing provider-specific
+machinery may donate implementation, but it does not promote a generic contract
+until that contract is tested on its own terms.
+
+Named Page Versions sit above ordinary Blocks-field revision history. Revision
+history supports attribution, comparison, and recovery everywhere. Named
+Versions later provide deliberate alternatives, selective merge, access
+restriction, and canonical promotion under one Page identity.
+
+## Governance boundary
+
+Content provides flexible local objects and governed reusable catalogs.
+Organizations can approve Sources, Templates, Custom Properties, Expressions,
+Skills, and Custom Blocks without turning every ordinary object into a global
+type. Non-bypassable security and identity policy remains framework-wide;
+Content can be its best management surface without becoming an independent
+authority with conflicting answers.

package/corpus/templates/content/docs/product/capabilities/content.access.page-database.md

@@ -0,0 +1,76 @@
+---
+record_type: "capability"
+spec_version: 2
+id: "content.access.page-database"
+name: "Page and Database access"
+user_promise: "Page and Database roles separate reading, commenting, entry editing, and structure authority."
+primary_user_job: "Share work at the appropriate level without accidentally granting collection-wide power."
+kind: "primitive"
+state: "approved_shape"
+publicness: "public"
+availability: "universal"
+dependencies: []
+related_features: []
+roadmap_boundary: "supporting"
+acceptance_summary: "Fixed Page and Database roles are enforced by the shared Action surface before every read or mutation, including deletion and structured-value policy."
+proof_requirements:
+  [
+    "Page role decisions for view, comment, edit, and full access",
+    "Database role decisions for entry versus schema authority",
+    "Identical UI, agent, API, and automation enforcement",
+    "Deletion, select-option, source-policy, and stale-capability failure coverage",
+  ]
+evidence: []
+superseded_by: null
+last_reviewed: "2026-07-29"
+---
+
+# Page and Database access
+
+## Why this exists
+
+Collaboration needs more than editor or viewer. A teammate may comment on a Page, edit a Database entry, or manage the Database structure—those are deliberately different powers.
+
+## Example workflow
+
+A manager gives a collaborator **Can edit entries** in a planning Database. The collaborator changes authorized rows but cannot alter Properties or delete the Database; a Page commenter can discuss a brief but cannot edit its body.
+
+## Product contract
+
+- Page roles are **Can view**, **Can comment**, **Can edit**, and **Full access**.
+- Database roles are **Can view**, **Can comment**, **Can edit entries**, **Can edit database**, and **Full access**.
+- Roles are fixed product roles backed by internal capabilities, not custom checkbox combinations.
+- Every UI, agent, automation, and API operation calls the same Action authorization and operation-specific validation.
+- Source truth, Property locks, and policy can narrow authority; they never widen a role.
+- Deletion and option/schema mutation require the stronger authority their impact demands.
+
+## Boundaries and non-goals
+
+- This record defines role semantics, not row-specific overrides, public publication, or derived-result closure.
+- A personal Favorite or Only-me View is a private capability, not shared edit authority.
+- Seeing an object or relationship never grants authority to mutate it.
+
+## Acceptance stories
+
+### Edit entries but not structure
+
+Given a collaborator with **Can edit entries**, when they update an allowed row, then it succeeds through UI and Action. When they rename a Property or change a select option, then it is denied without a partial mutation.
+
+### Comment without editing body
+
+Given a Page commenter, when they add a comment, then it is permitted. When they submit a body edit or ask an agent to do it, then both surfaces return the same denial.
+
+## Current evidence
+
+Current Content actions and Database permission work provide role and ownership substrate, but the complete fixed-role matrix, shared effective operation capabilities, and all destructive/structured-value paths are not yet proven together. This remains `approved_shape`.
+
+## Proof plan
+
+1. Build a role-by-operation matrix for Page and Database actions and UI controls.
+2. Test direct, bulk, agent, automation, source-backed, and stale client capability paths.
+3. Verify denial is typed and leaves content, schema, and audit state unchanged.
+4. Test role changes during a pending mutation, reload, keyboard, and assistive technology.
+
+## Open questions
+
+Internal capability representation is an implementation detail. The fixed product role vocabulary and no-widening rule are settled.

package/corpus/templates/content/docs/product/capabilities/content.access.row-private.md

@@ -0,0 +1,75 @@
+---
+record_type: "capability"
+spec_version: 2
+id: "content.access.row-private"
+name: "Row-level privacy"
+user_promise: "A Page or Database row can be shared more narrowly than its collection's ordinary visibility."
+primary_user_job: "Keep a sensitive item in an otherwise shared workflow without copying it into a secret parallel system."
+kind: "primitive"
+state: "approved_shape"
+publicness: "public"
+availability: "universal"
+dependencies: ["content.access.page-database"]
+related_features: ["content.feature.explore-alternatives-safely"]
+roadmap_boundary: "feature"
+acceptance_summary: "Default Database visibility can be narrowed by row/Page principals, and every read, query, source operation, and mutation applies the resulting access before returning data."
+proof_requirements:
+  [
+    "Default inheritance and explicit row/Page principal behavior",
+    "Access-first query, view, search, aggregate, and export behavior",
+    "Shared Action and UI mutation enforcement",
+    "Source synchronization, deletion, restore, and access-change tests",
+  ]
+evidence: []
+superseded_by: null
+last_reviewed: "2026-07-29"
+---
+
+# Row-level privacy
+
+## Why this exists
+
+A shared tracker sometimes contains a draft, personnel matter, or private alternative. The item should remain in the governed workflow without becoming ambiently discoverable.
+
+## Example workflow
+
+A team keeps a hiring Database visible to managers. One candidate row is restricted to a smaller panel. The panel can work with the row; other managers see neither its fields nor its contribution to counts.
+
+## Product contract
+
+- A Database supplies ordinary default access; a Page/row may narrow that visibility through explicit principals.
+- Narrower row access applies before list, View, Query, relation traversal, search, aggregate, export, agent context, and source operations.
+- An authorized direct link opens the Page; an unauthorized known direct link returns an honest generic denial.
+- Row privacy does not make a Page's identity dependent on a Database or grant access through another membership.
+- All mutations use the shared Action decision and record attributable history.
+
+## Boundaries and non-goals
+
+- Row privacy narrows inherited access; it does not widen a Page beyond allowed policy.
+- It does not define public publishing or named-Version access, which have their own boundaries.
+- Hiding a View column is presentation, not row privacy.
+
+## Acceptance stories
+
+### Hide a restricted row from collection work
+
+Given one private row in a shared Database, when an unauthorized member opens a View, searches, groups, or exports it, then the row and its values do not appear or affect derived output.
+
+### Keep direct access honest
+
+Given an unauthorized person knows the private row's URL, when they open it or invoke an Action, then access is denied without reporting a successful empty Page or exposing its title.
+
+## Current evidence
+
+The repository has ownable records and access-aware Content surfaces, providing substrate. It does not yet prove complete per-row principals across every derived path and source policy, so the capability remains `approved_shape`.
+
+## Proof plan
+
+1. Exercise inheritance, restriction, principal changes, and recovery through UI and Actions.
+2. Re-run Views, Queries, search, relationships, exports, agents, and aggregates for each role.
+3. Test source sync/write-back and access changes during pending work.
+4. Verify trash, restore, audit/history, and generic denial behavior.
+
+## Open questions
+
+Exact principal-management controls remain a surface design choice; no implementation may turn unavailable data into a successful empty result.