@agent-native/core 0.130.2 → 0.131.3

package/corpus/templates/content/docs/product/capabilities/content.view.source-query.md

@@ -0,0 +1,159 @@
+---
+record_type: "capability"
+spec_version: 2
+id: "content.view.source-query"
+name: "Cross-source Queries"
+user_promise: "One visual typed Query composes authorized Databases, Sources, and Queries without copying their records or hiding where values come from."
+primary_user_job: "Combine related work from several places into one useful live result while keeping each record's owner, access, and write route clear."
+kind: "surface"
+state: "approved_shape"
+publicness: "public"
+availability: "universal"
+dependencies: ["content.query.object", "content.source.catalog"]
+related_features: ["content.feature.connect-your-sources"]
+roadmap_boundary: "feature"
+acceptance_summary: "A visual builder composes access-scoped Databases, governed Sources, and Queries with explicit stable-identity alignment and Query-owned outputs; every result retains provenance, and edits or creation route only through declared unambiguous authorized owners."
+proof_requirements:
+  [
+    "Visual and agent editing of one validated typed Query representation with sources, alignment, filters, joins, preview, renderers, scale, and cycle checks",
+    "Access-first provenance, source-qualified field identity, aliases/computed outputs, write-through, read-only derived outputs, and creation-route behavior",
+    "Lossless migration and compatibility verification from row-union and joined-detail donor machinery without treating either donor UI as the product contract",
+  ]
+evidence: []
+superseded_by: null
+last_reviewed: "2026-07-29"
+---
+
+# Cross-source Queries
+
+## Why this exists
+
+Work often lives in several collections that people need to read together.
+Copying it into a third table produces stale duplicates and ambiguous writes.
+A cross-source Query provides one visual composition surface while leaving
+canonical records, stored values, access, and provider authority with the
+Databases and Sources that already own them.
+
+## Example workflow
+
+An editor creates a Query, adds two governed provider collections and a local
+Database, then aligns two stable title fields into an output field named
+`Title`. They add a relation-based join, a filter, and a Board renderer. Each
+result shows its Source provenance. Editing a mapped provider field routes only
+to its authorized owner; the `Title` alias and a computed score are Query-owned
+output and cannot be mistaken for stored source fields. Creating a new result
+uses a declared route or asks which source should own it.
+
+## Product contract
+
+### One visual builder and typed representation
+
+- A Query may compose authorized Databases, catalog-selected Sources, and other
+  Queries through unions, joins, relationships, filters, grouping, sorting,
+  limits, variables, and compatible renderers without creating a third
+  canonical row store.
+- The visual builder and agents manipulate the same validated typed Query AST.
+  Source selection, field alignment, rules, preview, and rendering remain
+  editable through ordinary controls; a textual inspector is optional, not a
+  separate authoring language.
+- Live preview places ambiguity, access exclusions, stale Sources,
+  write-through limits, cycle failures, and scale bounds beside the relevant
+  builder stage rather than returning an unexplained empty result.
+- Query-as-input remains lazy and access-scoped. Dependency and cycle analysis
+  occurs before save; pagination, traversal, aggregation, and cancellation
+  bounds prevent unbounded background work.
+
+### Align fields explicitly and retain provenance
+
+- Exact Custom Property or Source Property identities may align automatically.
+  Same display names do not establish equivalence: unrelated fields stay
+  source-qualified until a person or agent explicitly aligns them.
+- A named Query owns stable output-field identities, aliases, computed fields,
+  output types, documentation, ordering that is part of result meaning, and
+  compatible renderer defaults. Renaming `Title` changes the projection, not
+  either source schema.
+- Every result retains canonical record identity, source and field provenance,
+  freshness, access, and declared write capability. Viewer access applies before
+  results, groups, aggregates, counts, errors, and previews are computed.
+- A View presents and downstream-refines the Query result. It cannot widen the
+  Query contract or turn an output alias into a canonical source field.
+
+### Write and create only through an owner
+
+- An ordinary mapped field writes through only when canonical identity, stable
+  field mapping, authorization, Source policy, and provider capability are
+  unambiguous. Computed fields, aggregates, lossy alignments, and ambiguous
+  joined fields are read-only.
+- A Query declares zero or more creation routes terminating in writable
+  Databases or Sources. A View may select an applicable declared default but
+  cannot invent a destination; zero routes is read-only, one route proceeds,
+  and several routes require a permitted default or an explicit choice.
+- Existing row-union source identity, guarded writes, per-source bindings,
+  joined detail records, and source selection are donor and migration substrate.
+  Their specialized configuration surfaces are not the long-term product model.
+
+## Boundaries and non-goals
+
+- A Database owns a writable collection, schema, membership, validation, and
+  canonical create route. A Query derives a result and output contract. A View
+  presents and refines either input.
+- Sources catalog owns governed Source discovery; Source adapters own provider
+  operations and policy; this Capability does not create a generic provider API
+  or change source ownership.
+- A Query is not an access grant, static share, materialized clone, or a way to
+  infer field equivalence from names.
+
+## Acceptance stories
+
+### Align separate titles without changing either source
+
+Given two authorized collections expose distinct stable fields both labeled
+`Title`, when an editor explicitly aligns them into a Query output called
+`Title`, then the output has Query-owned identity while both source fields,
+schemas, provenance, and writes remain separate.
+
+### Write only when the route is clear
+
+Given a result with a mapped source field, a computed field, and an ambiguous
+joined field, when an authorized editor changes each one, then only the mapped
+field reaches its canonical owner; the computed and ambiguous fields remain
+read-only with an explanatory state.
+
+### Create through a declared source route
+
+Given a Query with two writable creation routes and a View with no applicable
+default, when a person creates a record, then Content presents a compact source
+choice and records the chosen owner's outcome. Given no route, creation is
+truthfully unavailable rather than guessed.
+
+## Current evidence
+
+Existing row-union and joined-detail machinery, source identity, guarded
+writes, field bindings, and source selection provide substantial donor
+implementation. They do not yet prove one visual typed Query experience,
+explicit output ownership, access-first nested composition, or complete
+write/create behavior. This Capability remains `approved_shape`.
+
+## Proof plan
+
+1. Build equivalent Queries through visual controls and agent Actions across
+   Databases, governed Sources, and nested Queries; compare AST, output schema,
+   preview, cycle checks, and compatible renderer behavior.
+2. Test stable field identities, qualified collisions, explicit alignments,
+   aliases, computed outputs, joins, filters, variables, provenance, freshness,
+   access-first results, counts, aggregates, pagination, and scale bounds.
+3. Exercise mapped write-through, derived-field refusal, zero/one/many creation
+   routes, defaults, validation, Source policy, provider receipts, conflicts,
+   retries, and mixed permissions.
+4. Migrate representative row-union and joined-detail configurations without
+   losing local rows, identities, write settings, review history, or Source
+   mappings, then complete the workflow through the real interface.
+
+## Open questions
+
+- The stable ID `content.view.source-query` lives in the View namespace even
+  though the accepted concept is a Query specialization. Preserve it for
+  compatibility until a deliberate graph-wide normalization defines a safe
+  replacement and migration path.
+- Exact materialization/cache strategy and the detailed visual controls for
+  complex joins, traversal, and scale warnings remain implementation work.

package/corpus/templates/content/docs/product/capabilities/content.view.timeline.md

@@ -0,0 +1,86 @@
+---
+record_type: "capability"
+spec_version: 2
+id: "content.view.timeline"
+name: "Timeline View"
+user_promise: "Timeline places and directly edits canonical records across typed dates and ranges while obeying the View conformance contract."
+primary_user_job: "See work across time, adjust an authorized date or range directly, and understand what the timeline cannot safely infer."
+kind: "surface"
+state: "in_progress"
+publicness: "public"
+availability: "universal"
+dependencies: ["content.time.types", "content.view.renderer-conformance"]
+related_features:
+  [
+    "content.feature.see-your-information-your-way",
+    "content.feature.plan-work-across-time",
+  ]
+roadmap_boundary: "feature"
+acceptance_summary: "Timeline renders canonical, access-scoped records across selected typed date or range Properties and edits them through shared Actions with conformance, recovery, and accessible navigation."
+proof_requirements:
+  [
+    "Typed date/range placement, end-date, undated, overlap, range navigation, and configuration persistence coverage",
+    "Shared Action edit, permission, history, optimistic recovery, and agent-context parity coverage",
+    "Real-interface keyboard, assistive-technology, responsive, reload, and unavailable-state workflow",
+  ]
+evidence:
+  [
+    "../../../app/components/editor/database/TimelineView.tsx",
+    "../../../app/components/editor/DocumentDatabase.test.ts",
+  ]
+superseded_by: null
+last_reviewed: "2026-07-29"
+---
+
+# Timeline View
+
+## Why this exists
+
+Time is an important projection of work, but a bar is never a schedule engine or a
+second record. Timeline makes typed temporal values visible and editable in place.
+
+## Example workflow
+
+An editor selects a date Property and optional end-date Property, moves to the next
+range, creates a dated record, and edits a card. The shared Action changes the canonical
+record; undated and unavailable records are reported rather than invented into a lane.
+
+## Product contract
+
+- Timeline consumes canonical, access-scoped results and configured typed dates or ranges.
+- Cards, overlap lanes, range controls, counts, and previews reflect authorized records only.
+- Direct edits and creation use shared Actions, validation, history, and recovery behavior.
+- Timeline is the current shallow renderer donor; Gantt is a composed mode/Feature, not proof of scheduling or a separate renderer contract.
+
+## Boundaries and non-goals
+
+Time types own temporal meaning; schedule constraints own dependency evaluation. Timeline
+does not infer dates, create a Gantt engine, or claim runtime feature-flag work not proven here.
+
+## Acceptance stories
+
+### Place a dated range
+
+Given authorized records with start and end date Properties, when a viewer opens Timeline,
+then overlapping cards appear in the selected range and an undated state is explicit.
+
+### Edit one canonical date
+
+Given an editable timeline card, when an editor changes its date, then the shared Action
+updates one canonical record, records history, and refreshes every authorized projection.
+
+## Current evidence
+
+`TimelineView.tsx` and `DocumentDatabase.test.ts` show a current Timeline renderer and
+date-window donor behavior. They do not prove the complete typed-time, Action-parity,
+conformance, accessibility, or recovery contract; this Capability remains `in_progress`.
+
+## Proof plan
+
+1. Test date-only, instant, ranges, end dates, undated records, overlaps, and range navigation.
+2. Verify Action edits, access closure, history, error rollback, and agent context.
+3. Run keyboard, assistive technology, responsive, reload, and unavailable-source workflows.
+
+## Open questions
+
+Precise Gantt composition and schedule-constraint visualization belong to their own Feature work.

package/corpus/templates/content/docs/product/capabilities/content.view.tree.md

@@ -0,0 +1,77 @@
+---
+record_type: "capability"
+spec_version: 2
+id: "content.view.tree"
+name: "Tree View"
+user_promise: "Tree renders any suitable hierarchical Relationship without creating a parallel parent system."
+primary_user_job: "Navigate and change an authorized hierarchy while knowing that its structure is a typed relationship, not an accidental page parent."
+kind: "surface"
+state: "approved_shape"
+publicness: "public"
+availability: "universal"
+dependencies: ["content.relationship.edge", "content.view.renderer-conformance"]
+related_features: []
+roadmap_boundary: "supporting"
+acceptance_summary: "Tree renders a chosen hierarchical Relationship over canonical access-scoped results, supports authorized relationship edits, and preserves typed edge truth across expansion and arrangement."
+proof_requirements:
+  [
+    "Hierarchical relationship selection, roots, cycles, multi-parent or orphan policy, expansion, and configuration coverage",
+    "Shared typed Relationship Action, access-safe disclosure, history, and recovery coverage",
+    "Real-interface keyboard tree semantics, assistive technology, lazy loading, reload, and dense hierarchy workflow",
+  ]
+evidence: []
+superseded_by: null
+last_reviewed: "2026-07-29"
+---
+
+# Tree View
+
+## Why this exists
+
+Some relationships are best read as nesting. Tree makes that shape useful without
+smuggling a universal parent field into Pages.
+
+## Example workflow
+
+A manager selects the `contains` relationship for a project View, expands a branch,
+and moves a task through the shared Relationship Action. The same edge remains visible
+in Connections and other authorized projections.
+
+## Product contract
+
+- Tree selects a suitable typed hierarchical Relationship and renders canonical nodes and edges.
+- Expansion, collapse, order, and focused state are View presentation; they do not redefine hierarchy.
+- Relationship creation, removal, and move use the shared typed Action with its constraints and history.
+- Access applies before roots, branch counts, labels, traversal, export, or agent context.
+
+## Boundaries and non-goals
+
+Relationships own semantic truth and cardinality. Tree is not Page-parent ownership,
+a sidebar model, a file system, or a separate hierarchy datastore.
+
+## Acceptance stories
+
+### Expand an authorized branch
+
+Given a hierarchy with inaccessible descendants, when a viewer expands a node, then no
+child label, count, or placeholder leaks inaccessible relationships.
+
+### Change a typed edge
+
+Given an editor allowed to alter a hierarchical edge, when they move a node, then the
+shared Relationship Action applies its cycle and cardinality rules and records history.
+
+## Current evidence
+
+The shared relationship boundary is prerequisite substrate; no complete Tree renderer
+contract is proven in the repository. This Capability remains `approved_shape`.
+
+## Proof plan
+
+1. Test roots, cycles, multiple parents, orphans, expansion, configuration, and lazy loading.
+2. Verify Action parity, access closure, history, concurrent changes, and recovery.
+3. Exercise ARIA tree navigation, keyboard moves, screen readers, reload, and dense branches.
+
+## Open questions
+
+The default policy for a relationship type that permits multiple parents needs design.

package/corpus/templates/content/docs/product/capabilities/content.workspace.multi-scope.md

@@ -0,0 +1,80 @@
+---
+record_type: "capability"
+spec_version: 2
+id: "content.workspace.multi-scope"
+name: "Personal and organization contexts"
+user_promise: "One identity can hold personal Content plus several workspaces without account switching"
+primary_user_job: "Work in Personal and organization contexts under one identity without confusing their ownership, authority, or source of truth."
+kind: "primitive"
+state: "approved_shape"
+publicness: "public"
+availability: "universal"
+dependencies: ["content.access.page-database"]
+related_features:
+  [
+    "content.feature.find-your-place-again",
+    "content.feature.work-across-every-workspace",
+  ]
+roadmap_boundary: "feature"
+acceptance_summary: "One identity supports distinct Personal and organization contexts with visible current scope, explicit cross-context retrieval, organization opt-out, provenance, and audit."
+proof_requirements:
+  [
+    "Distinct context identity, current-scope switching, and ownership persistence coverage",
+    "Explicit cross-context retrieval, opt-out, access, provenance, and audit coverage",
+    "Revoked membership, unavailable context, agent context, reload, and recovery workflows",
+  ]
+evidence: []
+superseded_by: null
+last_reviewed: "2026-07-29"
+---
+
+# Personal and organization contexts
+
+## Why this exists
+
+One person may carry private work and belong to many organizations. Convenience must not
+turn those distinct contexts into one leaking room.
+
+## Example workflow
+
+A person switches from Personal to an organization, then asks for an explicitly global
+search. Results carry their origin; an organization policy can exclude its work entirely.
+
+## Product contract
+
+- Personal and organization contexts remain distinct ownership and access domains under one identity.
+- Current context is visible; cross-context retrieval is explicit, access-scoped, policy-governed, and auditable.
+- Every returned object retains origin and opens under its owning context's authority.
+- Membership loss, deletion, stale state, and unavailable contexts are not restored as usable state.
+
+## Boundaries and non-goals
+
+This primitive informs Home and working sets. It does not create an organization, merge
+contexts, duplicate records, or make cross-context write implicit.
+
+## Acceptance stories
+
+### Switch without merging
+
+Given Personal and organization work, when a person changes current context, then only
+that scope is shown until they deliberately choose an allowed global retrieval.
+
+### Revoke a membership
+
+Given a previously visible organization item, when membership is revoked, then it no
+longer appears in navigation, Home, agent context, or session restoration.
+
+## Current evidence
+
+The architecture establishes the required distinction; no complete multi-scope interface,
+policy, provenance, and recovery proof is recorded. This remains `approved_shape`.
+
+## Proof plan
+
+1. Test scope switching, ownership, origin badges, global opt-in, and audit events.
+2. Verify organization opt-out and access changes across UI, Actions, search, and agents.
+3. Exercise revoked membership, unavailable context, reload, and recovery workflows.
+
+## Open questions
+
+The user-facing scope selector and default global-search posture need design.

package/corpus/templates/content/docs/product/capabilities/content.workspace.session-restore.md

@@ -0,0 +1,76 @@
+---
+record_type: "capability"
+spec_version: 2
+id: "content.workspace.session-restore"
+name: "Session resumption"
+user_promise: "Content reopens the authorized object and focused View a person was using without requiring them to reconstruct the route."
+primary_user_job: "Resume interrupted work quickly without reopening stale, deleted, or newly unauthorized information."
+kind: "surface"
+state: "approved_shape"
+publicness: "public"
+availability: "universal"
+dependencies: ["content.workspace.working-set"]
+related_features: ["content.feature.find-your-place-again"]
+roadmap_boundary: "feature"
+acceptance_summary: "Session restoration reopens the last authorized object and focused saved or personal View after a normal interruption, discarding stale or inaccessible UI state safely."
+proof_requirements:
+  [
+    "Restart restoration of focus, View configuration, selection, and authorized route coverage",
+    "Deleted, stale, changed-permission, unavailable, and cross-context invalidation coverage",
+    "Real-interface reload, crash/restart, keyboard focus, agent-context, and recovery workflow",
+  ]
+evidence: []
+superseded_by: null
+last_reviewed: "2026-07-29"
+---
+
+# Session resumption
+
+## Why this exists
+
+Returning to work should feel like a held thread, not a scavenger hunt—and never like a
+resurrection spell for information a person may no longer open.
+
+## Example workflow
+
+An editor leaves a focused Timeline View, restarts the application, and returns there.
+If the Page was deleted or access changed, Content opens a safe fallback and explains it.
+
+## Product contract
+
+- Session state stores UI references and focus, never a substitute copy of object truth.
+- Restoration reauthorizes every target before reopening it and drops invalid state safely.
+- Saved or personal View focus restores when still authorized; ephemeral renderer state is bounded.
+- Recovery distinguishes normal restoration, missing target, denied target, and unavailable source.
+
+## Boundaries and non-goals
+
+Working set owns persisted UI state. Session restoration is not a guarantee to preserve
+every inactive renderer, unsaved local draft, or unauthorized content.
+
+## Acceptance stories
+
+### Resume an authorized View
+
+Given an editor focused on an authorized saved View, when the app restarts normally, then
+Content reopens that object and View with a usable focus target.
+
+### Discard revoked state
+
+Given saved state for an object whose access is revoked, when the session restores, then
+Content omits the object and does not reveal its title, preview, or prior selection.
+
+## Current evidence
+
+Persisted navigation donors do not prove reauthorization, fallback, and recovery. This
+Capability remains `approved_shape`.
+
+## Proof plan
+
+1. Test normal restart, focused Views, selections, and bounded renderer restoration.
+2. Test deleted, stale, denied, unavailable, and cross-context state invalidation.
+3. Exercise reload/crash recovery, keyboard focus, agents, and accessible explanations.
+
+## Open questions
+
+The exact safe fallback order needs interaction design.

package/corpus/templates/content/docs/product/capabilities/content.workspace.view-instance.md

@@ -0,0 +1,76 @@
+---
+record_type: "capability"
+spec_version: 2
+id: "content.workspace.view-instance"
+name: "View instances"
+user_promise: "Tabs, panes, embeds, and windows can show independent focused instances of the same canonical object without duplicating it."
+primary_user_job: "Compare or work through the same object in several places while keeping presentation state independent and data canonical."
+kind: "surface"
+state: "approved_shape"
+publicness: "public"
+availability: "universal"
+dependencies: ["content.workspace.working-set", "content.view.query"]
+related_features: ["content.feature.find-your-place-again"]
+roadmap_boundary: "feature"
+acceptance_summary: "Independent View instances hold their own focus and presentation state over shared canonical objects, reconcile shared mutations, and render lazily within one bounded working set."
+proof_requirements:
+  [
+    "Two-instance identity, independent View state, focus, selection, and persistence coverage",
+    "Shared mutation reconciliation, permission change, close, embed, and recovery coverage",
+    "Lazy-rendering, keyboard, assistive-technology, reload, and agent-context workflow",
+  ]
+evidence: []
+superseded_by: null
+last_reviewed: "2026-07-29"
+---
+
+# View instances
+
+## Why this exists
+
+Two windows can hold two questions about one Page. They should not create two Pages in
+order to do it.
+
+## Example workflow
+
+An editor opens one Database in a Table tab and a Timeline pane, changes a record in the
+Table, and sees the Timeline reconcile while its range and focus remain independent.
+
+## Product contract
+
+- A View instance references a canonical object plus instance-local presentation, focus, and selection state.
+- Tabs, panes, embeds, and later windows may show the same object without duplicating it.
+- Canonical mutations, permissions, and deletion reconcile across instances through shared Actions and state sync.
+- Lazy rendering bounds resource use without falsely treating an unmounted instance as closed or complete.
+
+## Boundaries and non-goals
+
+Working set owns instance persistence. A View instance is not a Page, Database, Query,
+permission boundary, or a fork of data.
+
+## Acceptance stories
+
+### Compare two presentations
+
+Given a Database open in a Table and Timeline instance, when a person changes Timeline
+range, then Table configuration is unchanged while both retain the same canonical records.
+
+### Reconcile one edit
+
+Given two authorized instances of one record, when an editor changes it through one, then
+the other reflects the canonical result without duplicate history or stale copy.
+
+## Current evidence
+
+Existing tabs or embeds are donor substrate only; no complete multi-instance contract is
+proven. This Capability remains `approved_shape`.
+
+## Proof plan
+
+1. Test two-instance focus, presentation, selection, close, persistence, and lazy rendering.
+2. Verify mutations, permission changes, deletion, errors, and recovery across instances.
+3. Exercise keyboard, assistive technology, reload, embed, and agent-context workflows.
+
+## Open questions
+
+Cross-window synchronization and focus-transfer policy need separate implementation design.

package/corpus/templates/content/docs/product/capabilities/content.workspace.working-set.md

@@ -0,0 +1,77 @@
+---
+record_type: "capability"
+spec_version: 2
+id: "content.workspace.working-set"
+name: "Working set"
+user_promise: "Tabs, split panes, and later windows are views over one persisted working set with explicit agent scope"
+primary_user_job: "Keep the few things I am actively using together without turning temporary UI state into object truth or hidden agent context."
+kind: "primitive"
+state: "approved_shape"
+publicness: "public"
+availability: "universal"
+dependencies: ["content.workspace.multi-scope"]
+related_features: ["content.feature.find-your-place-again"]
+roadmap_boundary: "feature"
+acceptance_summary: "A persisted working set holds stable, authorized View references and local presentation state for tabs and panes, with explicit focus, bounded lazy rendering, and visible agent scope."
+proof_requirements:
+  [
+    "Stable references, focus, selection, ordering, pane layout, and persistence coverage",
+    "Scope, access revocation, source boundary, agent-context consent, close, and recovery coverage",
+    "Lazy rendering, reload, keyboard, assistive-technology, and concurrent UI workflow",
+  ]
+evidence: []
+superseded_by: null
+last_reviewed: "2026-07-29"
+---
+
+# Working set
+
+## Why this exists
+
+Active work deserves continuity, but a tab strip must not become a secret database or an
+unannounced briefing packet for an agent.
+
+## Example workflow
+
+A person keeps a project, a filtered task View, and a note in split panes, focuses the
+task View, and chooses which focused context an agent may use. Reordering panes changes
+only their working set.
+
+## Product contract
+
+- The working set persists stable authorized View references and UI state, not object copies or truth.
+- Tabs, panes, and future windows share one explicit focus and selection model with bounded lazy rendering.
+- Current context and explicit consent govern what an agent receives; background tabs are not implied context.
+- Access loss, deletion, source unavailability, and scope changes invalidate or annotate state safely.
+
+## Boundaries and non-goals
+
+Multi-scope owns ownership boundaries and View instances own a rendering occurrence. This
+is not shared document structure, an agent surveillance feed, or a second navigation tree.
+
+## Acceptance stories
+
+### Keep temporary arrangement personal
+
+Given two people viewing the same project, when one rearranges tabs and panes, then the
+other person's layout and the project's canonical structure remain unchanged.
+
+### Make agent scope explicit
+
+Given several open panes, when a person asks an agent about the focused task View, then
+only the explicitly selected authorized context is supplied and its origin remains visible.
+
+## Current evidence
+
+No complete persisted working-set, consent, access-invalidating, and recovery proof is
+recorded. This Capability remains `approved_shape`.
+
+## Proof plan
+
+1. Test references, focus, panes, ordering, persistence, close, and lazy rendering.
+2. Verify access and context changes, source boundaries, agent consent, and recovery.
+3. Exercise reload, concurrent UI changes, keyboard, and assistive-technology workflows.
+
+## Open questions
+
+The first explicit agent-context selector and cross-device persistence policy need design.

package/corpus/templates/content/docs/product/chapters/content.chapter.capture-research.md

@@ -0,0 +1,20 @@
+---
+record_type: "chapter"
+id: "content.chapter.capture-research"
+name: "Capture anything. Keep the thread"
+order: 5
+promise: "Chapter 5 turns the things people encounter into research they can keep using. Material can enter from many capture points, retain its source and exact context, become comfortable to read and annotate, and connect to citations, claims, and other knowledge without losing the original thread. The following Features support that path from capture to understanding."
+features:
+  [
+    "content.feature.capture-into-action",
+    "content.feature.read-and-annotate-anything",
+    "content.feature.cite-what-you-found",
+    "content.feature.sketch-connections-keep-whats-true",
+  ]
+publicness: "public"
+last_reviewed: "2026-07-29"
+---
+
+# Capture anything. Keep the thread
+
+Chapter 5 turns the things people encounter into research they can keep using. Material can enter from many capture points, retain its source and exact context, become comfortable to read and annotate, and connect to citations, claims, and other knowledge without losing the original thread. The following Features support that path from capture to understanding.