docs: add memory architecture discovery

docs/README.md

@@ -32,8 +32,11 @@ Start here:
 - [Scient product identity](product/scient-product-identity.md) - accepted company, app, native-agent, external-agent, and naming vocabulary.
 - [Product philosophy](product/product-philosophy.md) - draft durable product principles; the accepted PRD governs conflicts.
 - [Technology stack](architecture/technology-stack.md) - current proposed stack direction.
-- [Idea inbox](planning/idea-inbox.md) - categorized intake for unresolved ideas,
-  including the future Scient memory-architecture discovery.
+- [Idea inbox](planning/idea-inbox.md) - lightweight intake for unresolved ideas
+  before they are evaluated and routed.
+- [Memory architecture discovery](planning/memory-architecture-discovery.md) -
+  draft candidate scopes, questions, scenarios, and discovery sequence; no
+  memory architecture or storage technology is selected.
 - [Product roadmap](planning/product-roadmap.md) - current sequence of coherent product outcomes.
 - [First vertical-slice implementation plan](planning/first-scient-vertical-slice-implementation-plan.md) - bounded plan for the active product slice.
 - [Scient and external agents implementation plan](planning/scient-and-external-agents-implementation-plan.md) - proposed plan for building the Scient agent as the owned OpenCode-derived first-party agent while preserving external agents independently.

docs/architecture/local-first-sync.md

@@ -10,7 +10,8 @@ Doc type: Future home
 This page will document Scient's local-first and sync architecture when it
 exists. Unprocessed questions about memory scope, user-selected cloud folders,
 offline behavior, conversation continuity, and future Scient cloud sync remain
-in the [Idea Inbox](../planning/idea-inbox.md#memory-context-and-continuity).
+in the draft [Memory Architecture
+Discovery](../planning/memory-architecture-discovery.md).
 No canonical memory store or sync engine is selected.
 
 Document here:

docs/architecture/project-format.md

@@ -9,9 +9,8 @@ Doc type: Future home
 
 This page will document the Scient project format when it exists. Unprocessed
 questions about project memory, conversations, files, portability, Git, cloud
-folders, and storage boundaries remain in the
-[Idea Inbox](../planning/idea-inbox.md#memory-context-and-continuity) until a
-dedicated memory-architecture discovery begins.
+folders, and storage boundaries remain in the draft
+[Memory Architecture Discovery](../planning/memory-architecture-discovery.md).
 
 Document here:
 

docs/architecture/technology-stack.md

@@ -237,8 +237,8 @@ Scient scientific project database. Scient-owned project persistence has not
 been selected, designed, or implemented. The future memory-architecture project
 will decide the roles of conversations, user memory, project memory, raw
 history, files, local application storage, and cloud storage before evaluating
-their persistence technologies. Unprocessed questions remain in the
-[Idea Inbox](../planning/idea-inbox.md#memory-context-and-continuity).
+their persistence technologies. Open questions remain in the draft
+[Memory Architecture Discovery](../planning/memory-architecture-discovery.md).
 
 Scient should distinguish:
 
@@ -477,7 +477,7 @@ Completed historical experiments remain evidence, not the roadmap.
 | Synara-derived application | Standalone owned source, build, isolated Scient identity and state, reviewed upstream process | Scientific-product fit, sustainable domain UI divergence, and long-term maintenance cost | Gate 1 and Gate 1.5 lab reports; ADR-0001 owns adoption; ADR-0002 owns repository authority |
 | Scient source foundation | Owned OpenCode build, Synara compatibility, project-root fidelity, transcript fidelity, and approval flow for a constrained action | Scient identity and packaging, owned capabilities, isolated Scient state, durable task behavior, and justified inherited-core changes | Gate 1.5 report proves the source baseline; ADR-0001 owns Scient adoption |
 | External agents | Nine inherited adapters and external OpenCode settings/adapter paths are present in source | Per-agent live compatibility, subscription/auth behavior, project-task certification, and migration protection | [Scient and external agents implementation plan](../planning/scient-and-external-agents-implementation-plan.md) |
-| Scient project state and memory | Product responsibilities, high-level memory principles, approved non-Git recovery requirement, and trust boundary are documented | Memory scopes, canonical representation, conversation relationship, package seam, portability, recovery, cloud sync, and first real scientific object relationship | PRD, [Idea Inbox](../planning/idea-inbox.md#memory-context-and-continuity), and future focused architecture work |
+| Scient project state and memory | Product responsibilities, high-level memory principles, approved non-Git recovery requirement, and trust boundary are documented | Memory scopes, canonical representation, conversation relationship, package seam, portability, recovery, cloud sync, and first real scientific object relationship | PRD, [Memory Architecture Discovery](../planning/memory-architecture-discovery.md), and future focused architecture work |
 | Scient-agent and Scient-app boundary | Scient-agent identity plus context, proposal, review, provenance, and permission responsibilities are documented | Actual contract, code placement, event mapping, isolated Scient-agent state, and accepted write-back path | ADR-0001 and linked implementation plans; `agent-runtime.md` remains a future home |
 | Goose | Source seams, ACP path, and safety risks inspected | Incremental capabilities or architecture lessons for Scient; any future external Goose path is a separate decision | Goose source-depth inspection |
 | Cloud sync | Postgres, object storage, and local-first sync are proposed directions | Authority, offline behavior, conflicts, revocation, and recovery | Later roadmap and focused architecture work |

docs/planning/README.md

@@ -3,7 +3,7 @@
 Status: Active
 Owner: Yaacov
 Created: 2026-06-27
-Last updated: 2026-07-17
+Last updated: 2026-07-18
 Purpose: Defines where Scient planning documents live and how they relate to product truth, architecture, design, quality, and research documents.
 Doc type: Repo orientation
 
@@ -16,6 +16,9 @@ Do not use planning docs as product truth, accepted architecture, or current imp
 Current planning docs:
 
 - `idea-inbox.md` - temporary intake for raw, unprocessed ideas before evaluation and routing.
+- `memory-architecture-discovery.md` - draft discussion of candidate memory
+  scopes, authority, lifecycle, agent access, local/cloud boundaries, and the
+  questions to resolve before architecture or storage selection.
 - `product-roadmap.md` - active sequence of coherent product outcomes, beginning with the first Scient scientific project slice.
 - `first-scient-vertical-slice-implementation-plan.md` - draft source-tracing, implementation, and verification plan for the active product slice.
 - `scient-and-external-agents-implementation-plan.md` - proposed end-to-end plan for building the Scient agent as the owned OpenCode-derived first-party agent while preserving external agents independently.

docs/planning/first-scient-vertical-slice-implementation-plan.md

@@ -59,8 +59,8 @@ Phase 2 source tracing is complete in
 state-ownership gaps and candidate seams. Yaacov clarified that conversations,
 project memory, user memory, recovery, cloud synchronization, and their storage
 boundaries belong to a dedicated future memory-architecture project, not an
-immediate persistence decision. Those unprocessed ideas now live in the
-[`Idea Inbox`](idea-inbox.md#memory-context-and-continuity). The permanent
+immediate persistence decision. Those questions now live in the draft
+[`Memory Architecture Discovery`](memory-architecture-discovery.md). The permanent
 scientific-operation package and fake-executor product proof also remain
 deferred. Non-Git recovery, trusted project filesystem scope, and complete
 native-Scient/external-OpenCode runtime independence remain product
@@ -444,8 +444,8 @@ scopes and relationships among conversations, user memory, project memory, raw
 history, files, local storage, and future cloud storage must be discovered
 together in a dedicated future project.
 
-The candidate questions are preserved in the
-[`Idea Inbox`](idea-inbox.md#memory-context-and-continuity). They do not select
+The candidate questions are preserved in the draft
+[`Memory Architecture Discovery`](memory-architecture-discovery.md). They do not select
 SQLite, define a project ledger, authorize memory implementation, or block the
 independent T3 reliability work. The permanent scientific-operation package and
 deterministic fake-executor product proof remain separate deferred decisions.

docs/planning/idea-inbox.md

@@ -57,91 +57,3 @@ not analysis or architecture, and should move with the idea when it is promoted.
 | Idea | Raised by | Date added | Context or source | Possible area |
 |---|---|---|---|---|
 | **Visual literature map.** Add an interactive, Obsidian-style graph view of the literature sources in a Scient project. Sources would appear as nodes, with inspectable relationships such as citations, shared topics, project links, or researcher-created connections. The view should help researchers explore clusters, identify central or isolated sources, review gaps, filter the collection, and open each source in its normal detail view. | Yishai | 2026-07-18 | Spoken idea. The initial scope should focus on sources already imported into the project; broader scholarly-network discovery and the exact relationship types remain open questions. | Source-library product planning, literature-review UX, design, and future source-relationship architecture |
-
-### Memory, Context, And Continuity
-
-| Idea | Raised by | Date added | Context or source | Possible area |
-|---|---|---|---|---|
-| **Future Scient memory architecture.** Discuss Scient's complete memory architecture as a dedicated future product and architecture project before selecting schemas, databases, or synchronization machinery. | Yaacov | 2026-07-18 | Questions about project records, conversations, SQLite, Git, user-selected cloud folders, recovery, and future Scient cloud sync arose during the first-slice source review. They belong to the broader memory-system discussion, not the completed T3 reliability work or an immediate persistence decision. Reusable questions from an oversized standalone persistence brief were condensed here before that out-of-scope architecture file was removed. | Product planning, future memory architecture, agent runtime, project format, security, provenance, synchronization, and product design |
-
-#### Candidate scopes and questions to preserve
-
-Candidate scopes to discuss, not accepted layers:
-
-- **Conversation memory:** short-lived or derived context from one conversation,
-  distinct from the complete transcript.
-- **Task or run memory:** working state for one delegated task or agent run,
-  including what may expire when the run completes.
-- **Project memory:** durable project direction, decisions, source judgments,
-  analysis choices, unresolved questions, collaborator decisions, and prior
-  work needed for continuity.
-- **User memory:** personal preferences, recurring choices, and working style
-  that may apply across projects without silently overriding project rules.
-- **Team or organization memory:** shared methods, conventions, and
-  institutional knowledge with explicit membership, permission, and ownership
-  boundaries.
-- **Scient-maintained knowledge:** built-in product guidance, scientific skills,
-  and maintained procedures; this may require different authority and update
-  rules from user-generated memory.
-- **Raw history and provenance:** complete conversations, events, actions, and
-  evidence that may support memory but are not automatically trusted memory.
-
-Questions for the future discovery project:
-
-- Which candidate scopes are actually needed, and what are their precise names
-  and responsibilities?
-- Who owns, reads, edits, shares, exports, deletes, or promotes information in
-  each scope?
-- What is ephemeral, retained for continuity, durable, canonical, derived, or
-  rebuildable?
-- What is the difference between a complete conversation transcript,
-  conversation context, a summary, and trusted memory?
-- Can a conversation or task propose project memory, and which promotions
-  require explicit researcher review?
-- How are source, authority, confidence, freshness, conflict, staleness,
-  distrust, archival, forgetting, and supersession represented?
-- What happens when user memory conflicts with project memory, or project
-  memory conflicts with current files and evidence?
-- How can researchers inspect, correct, pin, challenge, archive, forget, or
-  disable remembered information?
-- Which memory can Scient use, and which memory may be disclosed to an external
-  agent for one bounded task?
-- How does task context include only the appropriate user, project,
-  conversation, and run information?
-- How do project memory and provenance relate to ordinary researcher-owned
-  files without turning generated summaries into project authority?
-- How do projects remain friendly to Git while never requiring Git for ordinary
-  use, history, or recovery?
-- How should projects behave in iCloud Drive, Dropbox, OneDrive, external
-  drives, network locations, and other user-selected folders?
-- Which information belongs in the project folder, local application storage,
-  a user account, or future Scient cloud storage?
-- What remains fully useful offline, and what is restored or synchronized when
-  cloud access returns?
-- How are concurrent edits, offline divergence, deletion, restoration, device
-  loss, and collaborator removal handled?
-- How are conversations, memory, decisions, and provenance retained, backed up,
-  exported, transferred, encrypted, redacted, or permanently deleted?
-- Which privacy, sensitive-data, institutional-control, and regional-storage
-  requirements constrain the design?
-- What scale, latency, reliability, recovery, migration, portability, and exit
-  requirements must be accepted before evaluating storage technologies?
-- Only after the memory model is understood, which persistence approaches
-  should be evaluated, including SQLite, structured files, derived indexes,
-  local databases, cloud databases, and combinations of them?
-- If SQLite remains a candidate at that later stage, what evidence is required
-  for crash behavior, journal/WAL handling, active copying, cloud-folder sync,
-  backup and restore, integrity checks, locking, migrations, packaging,
-  performance, readable export, and exit from the format?
-
-Explicit non-decisions:
-
-- These scopes are prompts for discussion, not accepted memory architecture.
-- Conversation, user, project, task, team, and system memory are not yet formal
-  product objects or storage boundaries.
-- No database, schema, project ledger, cloud-sync protocol, or retention policy
-  is selected or authorized.
-- The existing application SQLite database remains current app/session
-  implementation; it does not settle the future memory architecture.
-- This future discovery does not block T3 reliability work or unrelated product
-  work.