diff --git a/AGENTS.md b/AGENTS.md index 3af5d62..1c882d8 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -3,28 +3,27 @@ Status: Active Owner: Yaacov Last updated: 2026-07-17 -Purpose: Defines how agents should work in this early PapiLab repository. +Purpose: Defines how agents should work in this early Scient repository. Doc type: Agent protocol ## What This Repo Is -This repo is the early planning and documentation workspace for PapiLab. +This repo is the early planning and documentation workspace for Scient. -PapiLab is a local-first, cloud-mirrored scientific workspace where researchers and AI agents run an entire research project together, from research question to publication-ready manuscript. The product direction is still being shaped. +Scient is a local-first, cloud-mirrored scientific workspace where researchers and AI agents run an entire research project together, from research question to publication-ready manuscript. The product direction is still being shaped. ## Current State This parent repo remains documentation-first. The maintained desktop fork now -contains the first permanent PapiLab-owned package, `@papilab/project-init`, +contains the first permanent Scient-owned package, `@scientfactory/project-init`, but the broader application architecture and first scientific vertical slice have not been built. Do not infer scientific-state, gateway, sync, cloud, or production boundaries from that narrow package. -ScientFactory is the chosen future company identity. **Scient** is the chosen -public name for both the future application and its native first-party research -agent. The current implemented application identity remains PapiLab until the -rename plan is executed and verified. In technical contexts, use **Scient app** -and **Scient agent** whenever the meaning could be ambiguous. +ScientFactory is the company and GitHub organization identity. **Scient** is +the public name for both the implemented application and its planned native +first-party research agent. In technical contexts, use **Scient app** and +**Scient agent** whenever the meaning could be ambiguous. The Scient agent is planned but not yet implemented. Architecturally, it is the owned OpenCode-derived agent itself—not an app shell around a separate OpenCode @@ -47,7 +46,7 @@ Capture durable future context, not documentation volume. Preserve consequential AI may draft documentation, but it is not the accountable owner and cannot confer acceptance. Preserve uncertainty and specific reasoning for human review. When authoritative sources conflict, surface the contradiction and route it to the owning person or document instead of smoothing it into false agreement. -Keep this repository within its PapiLab product and project boundary. Do not add company-wide finance, legal, people, customer-record, or cross-product authority here without an accepted repository-scope decision. Do not commit secrets or sensitive personal, customer, employee, or regulated data. +Keep this repository within its Scient product and project boundary. Do not add company-wide finance, legal, people, customer-record, or cross-product authority here without an accepted repository-scope decision. Do not commit secrets or sensitive personal, customer, employee, or regulated data. ## Source Documents @@ -56,14 +55,14 @@ Current important documents: - `docs/README.md` - documentation map and current repo structure. - `docs/documentation-policy.md` - rules for creating, updating, and classifying documentation. - `docs/product/PRD.md` - product direction, core capabilities, user experience principles, and technical requirements. -- `docs/product/scient-product-identity.md` - accepted future company, application, agent, external-agent, and naming vocabulary. +- `docs/product/scient-product-identity.md` - accepted company, application, agent, external-agent, and naming vocabulary. - `docs/product/product-philosophy.md` - durable product principles that guide product, architecture, design, quality, and implementation. - `docs/architecture/technology-stack.md` - current technology stack direction and open implementation decisions. -- `docs/architecture/decisions/ADR-0001-synara-opencode-foundation-and-papilab-ownership-boundary.md` - accepted initial application/runtime foundations and the PapiLab-owned scientific boundary. +- `docs/architecture/decisions/ADR-0001-synara-opencode-foundation-and-scient-ownership-boundary.md` - accepted initial application/runtime foundations and the Scient-owned scientific boundary. - `docs/planning/product-roadmap.md` - active sequence of coherent product outcomes. -- `docs/planning/first-papilab-vertical-slice-implementation-plan.md` - concrete plan and acceptance criteria for the current implementation slice. +- `docs/planning/first-scient-vertical-slice-implementation-plan.md` - concrete plan and acceptance criteria for the current implementation slice. - `docs/planning/scient-and-external-agents-implementation-plan.md` - proposed implementation plan for the Scient agent, external-agent preservation, and Scient-versus-external-agent identity isolation. -- `docs/planning/papilab-to-scient-rename-execution-plan.md` - proposed migration plan from the current PapiLab implementation identity to Scient and ScientFactory. +- `docs/planning/papilab-to-scient-rename-execution-plan.md` - historical execution and rollback record for the PapiLab-to-Scient migration. Use each document according to its metadata. The PRD and ADR-0001 are accepted direction; the roadmap is active planning; the product philosophy, technology @@ -90,7 +89,7 @@ When proposing technical direction, separate: The PRD should stay focused on product truth. Stack choices and implementation details should live in architecture documents unless they are direct product constraints. -Use **Scient** as the public name for both the future app and native agent. In +Use **Scient** as the public name for both the app and native agent. In technical or potentially ambiguous text, write **Scient app** or **Scient agent**. Use **external agent** for an independently connected product such as OpenCode, Codex, Claude, or Droid. Do not create “ScientApp” or “ScientAgent” as @@ -102,9 +101,9 @@ are project instructions, not the Scient agent product. Project-specific skills live under `skills/`. -Use `skills/product/papilab-product-stewardship/SKILL.md` for product management work, including PRD changes, feature analysis, roadmap notes, product decisions, and product research synthesis. +Use `skills/product/scient-product-stewardship/SKILL.md` for product management work, including PRD changes, feature analysis, roadmap notes, product decisions, and product research synthesis. -Use `skills/documentation/papilab-documentation-stewardship/SKILL.md` when creating, reviewing, moving, promoting, retiring, or reconciling durable documentation and project progress records. +Use `skills/documentation/scient-documentation-stewardship/SKILL.md` when creating, reviewing, moving, promoting, retiring, or reconciling durable documentation and project progress records. Project skills are workflow helpers. They should point agents back to the canonical repo documents and must not override `docs/product/`, `docs/architecture/`, `docs/documentation-policy.md`, or this `AGENTS.md` file. diff --git a/README.md b/README.md index 28bf838..0d1afdf 100644 --- a/README.md +++ b/README.md @@ -1,15 +1,15 @@ -# PapiLab +# Scient Status: Active Owner: Yaacov Last updated: 2026-07-17 -Purpose: Entry point for the PapiLab planning repository. +Purpose: Entry point for the Scient planning repository. Doc type: Repo orientation -PapiLab remains the current repository and implemented desktop identity. The +Scient is the current repository and implemented desktop identity. The repository is documentation-first, with one narrow project-initiation package -in the maintained desktop fork. ScientFactory and Scient are the accepted -future identity, but the rename has not yet been executed. +in the maintained desktop fork. The native Scient agent remains planned; its +owned source repository is `ScientFactory/scient-agent`. Start here: @@ -17,7 +17,7 @@ Start here: - [Documentation index](docs/README.md) - map of the repository's documentation areas. - [Documentation policy](docs/documentation-policy.md) - rules for document authority, status, evidence, and placement. - [Product requirements](docs/product/PRD.md) - accepted product direction. -- [Scient product identity](docs/product/scient-product-identity.md) - accepted future company, app, native-agent, and external-agent naming system. -- [PapiLab-to-Scient rename plan](docs/planning/papilab-to-scient-rename-execution-plan.md) - proposed controlled migration; target names are not yet implemented. +- [Scient product identity](docs/product/scient-product-identity.md) - accepted company, app, native-agent, and external-agent naming system. +- [PapiLab-to-Scient rename record](docs/planning/papilab-to-scient-rename-execution-plan.md) - historical migration, compatibility, rollback, and deferred-public-cutover record. - [Technology stack](docs/architecture/technology-stack.md) - proposed architecture and stack direction. - [Agent guidance](AGENTS.md) - protocol for agents working in this repository. diff --git a/docs/README.md b/docs/README.md index 8481691..f1797fe 100644 --- a/docs/README.md +++ b/docs/README.md @@ -3,11 +3,11 @@ Status: Active Owner: Yaacov Last updated: 2026-07-17 -Purpose: Maps the PapiLab documentation structure and where each kind of information belongs. +Purpose: Maps the Scient documentation structure and where each kind of information belongs. Doc type: Repo orientation This parent repository remains documentation-first. The maintained desktop fork -contains the first narrow PapiLab-owned project-initiation package, while the +contains the first narrow Scient-owned project-initiation package, while the scientific application architecture and vertical slice remain unbuilt. This structure gives product, architecture, planning, research, development, and operations material clear homes without presenting planned behavior as current @@ -20,13 +20,13 @@ Start here: - [Collaborator onboarding](onboarding.md) - ordered project journey, repository tour, and contribution-area reading routes. - [Documentation policy](documentation-policy.md) - documentation rules, metadata, statuses, and placement policy. - [Product requirements](product/PRD.md) - canonical product direction. -- [Scient product identity](product/scient-product-identity.md) - accepted future company, app, native-agent, external-agent, and naming vocabulary. +- [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. - [Product roadmap](planning/product-roadmap.md) - current sequence of coherent product outcomes. -- [First vertical-slice implementation plan](planning/first-papilab-vertical-slice-implementation-plan.md) - bounded plan for the active product slice. +- [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. -- [PapiLab-to-Scient rename execution plan](planning/papilab-to-scient-rename-execution-plan.md) - proposed controlled migration from the current PapiLab implementation identity to Scient and ScientFactory. +- [PapiLab-to-Scient rename execution record](planning/papilab-to-scient-rename-execution-plan.md) - historical migration, compatibility, rollback, and deferred-public-cutover record. - [LitRev-to-PapiLab rename execution plan](planning/litrev-to-papilab-rename-execution-plan.md) - historical intermediate identity migration, verification, and rollback record. - [Architecture](architecture/README.md) - architecture direction, future architecture homes, and decisions. - [Design](design/README.md) - future home for product design principles and UI guidance. diff --git a/docs/architecture/README.md b/docs/architecture/README.md index d211e60..7f9a7ca 100644 --- a/docs/architecture/README.md +++ b/docs/architecture/README.md @@ -3,17 +3,17 @@ Status: Active Owner: Yaacov Last updated: 2026-07-17 -Purpose: Defines where PapiLab architecture direction, future architecture homes, and decisions belong. +Purpose: Defines where Scient architecture direction, future architecture homes, and decisions belong. Doc type: Repo orientation -Architecture docs explain how PapiLab should be structured and why. They must clearly distinguish proposal, accepted direction, implementation candidate, and current implementation. +Architecture docs explain how Scient should be structured and why. They must clearly distinguish proposal, accepted direction, implementation candidate, and current implementation. Current documents: - `technology-stack.md` - current stack direction. -- `project-format.md` - future home for the PapiLab project format. +- `project-format.md` - future home for the Scient project format. - `local-first-sync.md` - future home for local-first and sync architecture. - `collaboration-model.md` - future home for collaboration architecture. - `agent-runtime.md` - future home for detailed Scient and external-agent runtime architecture; the accepted high-level ownership boundary currently lives in ADR-0001. - `security-and-permissions.md` - early security, trust-boundary, and permission principles. -- `decisions/` - accepted architecture decision records, beginning with the Synara application foundation, Scient's OpenCode-derived source foundation, external-agent separation, and the PapiLab-owned scientific boundary. +- `decisions/` - accepted architecture decision records, beginning with the Synara application foundation, Scient's OpenCode-derived source foundation, external-agent separation, and the Scient-owned scientific boundary. diff --git a/docs/architecture/agent-runtime.md b/docs/architecture/agent-runtime.md index 28dc8ef..6c441a7 100644 --- a/docs/architecture/agent-runtime.md +++ b/docs/architecture/agent-runtime.md @@ -6,10 +6,10 @@ Last updated: 2026-07-17 Purpose: Defines what should be documented about Scient-agent and external-agent execution once implementation begins. Doc type: Future home -This page will document PapiLab's agent runtime architecture when it exists. +This page will document Scient's agent runtime architecture when it exists. The accepted high-level foundation and ownership boundary currently lives in -`decisions/ADR-0001-synara-opencode-foundation-and-papilab-ownership-boundary.md`. +`decisions/ADR-0001-synara-opencode-foundation-and-scient-ownership-boundary.md`. The proposed implementation sequence and identity-isolation requirements live in `../planning/scient-and-external-agents-implementation-plan.md`. This file remains a placeholder until the first vertical slice validates a diff --git a/docs/architecture/collaboration-model.md b/docs/architecture/collaboration-model.md index 70dd70b..e57589a 100644 --- a/docs/architecture/collaboration-model.md +++ b/docs/architecture/collaboration-model.md @@ -2,11 +2,11 @@ Status: Placeholder Owner: Yaacov -Last updated: 2026-06-27 +Last updated: 2026-07-17 Purpose: Defines what should be documented about sharing and collaboration once the model is designed. Doc type: Future home -This page will document PapiLab's collaboration model when it exists. +This page will document Scient's collaboration model when it exists. Document here: diff --git a/docs/architecture/decisions/ADR-0001-synara-opencode-foundation-and-papilab-ownership-boundary.md b/docs/architecture/decisions/ADR-0001-synara-opencode-foundation-and-scient-ownership-boundary.md similarity index 72% rename from docs/architecture/decisions/ADR-0001-synara-opencode-foundation-and-papilab-ownership-boundary.md rename to docs/architecture/decisions/ADR-0001-synara-opencode-foundation-and-scient-ownership-boundary.md index ad45d18..d89101d 100644 --- a/docs/architecture/decisions/ADR-0001-synara-opencode-foundation-and-papilab-ownership-boundary.md +++ b/docs/architecture/decisions/ADR-0001-synara-opencode-foundation-and-scient-ownership-boundary.md @@ -1,9 +1,9 @@ -# ADR-0001: Synara And OpenCode Foundations With A PapiLab Ownership Boundary +# ADR-0001: Synara And OpenCode Foundations With A Scient Ownership Boundary Status: Accepted Owner: Yaacov Last updated: 2026-07-17 -Purpose: Records the decision to use the owned Synara fork as PapiLab's application foundation and the owned OpenCode fork as the source foundation for Scient while keeping external agents and canonical scientific state separately owned. +Purpose: Records the decision to use the owned Synara fork as Scient's application foundation and the owned OpenCode fork as the source foundation for Scient while keeping external agents and canonical scientific state separately owned. Doc type: Architecture decision ## Context @@ -12,39 +12,38 @@ Originally accepted on 2026-07-16. Amended by Yaacov on 2026-07-17 to name Scient and clarify that it is the owned OpenCode-derived agent itself, while external OpenCode remains separate. -The accepted future product identity also names the application **Scient**. -Until that rename is executed, this ADR uses PapiLab for the current app and -Scient for the planned agent. After cutover, precise architecture text must use -**Scient app** and **Scient agent** where the shared public name could be -ambiguous. `../../product/scient-product-identity.md` owns that naming decision. +The accepted product identity also names the application **Scient**. Precise +architecture text must use **Scient app** and **Scient agent** where the shared +public name could be ambiguous. +`../../product/scient-product-identity.md` owns that naming decision. -PapiLab needs a serious local desktop workbench and first-party agent before it can +Scient needs a serious local desktop workbench and first-party agent before it can validate a complete scientific workflow. The owned Synara fork already provides desktop, workspace, provider, process, terminal, preview, diff, and review machinery. The owned OpenCode fork already provides a capable local agent loop, model integration, tools, permissions, sessions, and file and shell execution. -The chosen name for PapiLab's first-party research agent is **Scient**. Scient -is the agent derived from the owned OpenCode fork. It is not a PapiLab wrapper +The chosen name for the product's first-party research agent is **Scient**. Scient +is the agent derived from the owned OpenCode fork. It is not a Scient wrapper around a separately operated or separately branded OpenCode engine. External OpenCode remains an independent external-agent choice in the application. Gate 1 and Gate 1.5 proved that the maintained forks build, remain isolated from the official applications, preserve reviewed upstream ancestry, and work -together for a constrained executor action. They did not create PapiLab's +together for a constrained executor action. They did not create Scient's scientific project model, agent contract, or accepted write-back path. -PapiLab must be free to adopt useful upstream changes without treating upstream +Scient must be free to adopt useful upstream changes without treating upstream compatibility as more important than the product. It must also avoid scattering scientific behavior through inherited internals when that behavior should be available to both researchers and agents. ## Decision -1. The owned Synara fork is PapiLab's initial application foundation for the +1. The owned Synara fork is Scient's initial application foundation for the desktop shell, local workspace experience, UI, lifecycle, and runtime plumbing. -2. Scient is PapiLab's first-party research agent. Scient is one owned +2. The Scient agent is the app's first-party research agent. It is one owned OpenCode-derived agent product, runtime, and codebase—not a separate agent shell that delegates to an independently identified OpenCode engine. 3. Within Scient's codebase, inherited OpenCode core and Scient-owned @@ -56,10 +55,10 @@ available to both researchers and agents. Claude, Droid, and the other inherited external-agent paths. Scient must not reuse or silently redirect external OpenCode's durable identity, configuration, credentials, subscription path, sessions, or update channel. -5. PapiLab owns the scientific project meaning, capabilities, permission scope, +5. Scient owns the scientific project meaning, capabilities, permission scope, context receipts, proposed-change lifecycle, provenance, review, recovery, and accepted state built on those foundations. -6. PapiLab scientific operations should be separated from inherited cores where +6. Scient scientific operations should be separated from inherited cores where practical so the manual UI and agents can use the same operations. Separation means clear modules and interfaces; it does not require a separate repository or process. @@ -67,21 +66,21 @@ available to both researchers and agents. preferred first integration method because they reduce unnecessary fork conflict. This is a maintainability preference, not a prohibition on core changes. -8. PapiLab may patch Synara or Scient's inherited OpenCode core when a +8. Scient may patch Synara or Scient's inherited OpenCode core when a demonstrated product, security, reliability, or runtime requirement cannot be met cleanly through an extension seam. Such patches should remain narrow and identifiable where practical. 9. A fork may progress deliberately from upstream-aligned, through isolated - PapiLab patches, to selective divergence or full PapiLab ownership. Official + Scient patches, to selective divergence or full Scient ownership. Official upstream changes remain optional reviewed inputs, not a product dependency. 10. Synara, Scient, and external-agent runtime/session databases may remain - useful execution state, but they are not canonical PapiLab scientific + useful execution state, but they are not canonical Scient scientific project state. 11. Goose remains valuable later as a source of agent capabilities and architecture lessons for Scient. Any adopted behavior becomes part of Scient rather than creating a hidden engine-switching product. A future external Goose option, if separately chosen, would remain distinct from - Scient. Goose is not on the critical path for the first PapiLab scientific + Scient. Goose is not on the critical path for the first Scient scientific project slice. ## Alternatives Considered @@ -89,22 +88,22 @@ available to both researchers and agents. ### Start A New Application Immediately This would maximize structural control but require rebuilding substantial -desktop and agent infrastructure before PapiLab could validate a real scientific +desktop and agent infrastructure before Scient could validate a real scientific workflow. ### Keep Synara And OpenCode As External Tools Only This would simplify upstream updates but limit the integration depth and product -control PapiLab expects to need. +control Scient expects to need. ### Put A Generic First-Party Shell In Front Of A Separate OpenCode Engine This would make the product/runtime boundary look replaceable, but it would -misstate the ownership decision. PapiLab intends to own and evolve the +misstate the ownership decision. Scient intends to own and evolve the OpenCode-derived agent itself. Scient is that agent; OpenCode lineage is an internal source-maintenance concern, not a second product underneath it. -### Modify Inherited Cores Without A PapiLab Layer +### Modify Inherited Cores Without A Scient Layer This would move quickly at first but risk making coding-session, provider, and engine state define the scientific product accidentally. @@ -119,16 +118,16 @@ engine state define the scientific product accidentally. configured. - Upstream OpenCode synchronization remains useful but may become more manual as Scient intentionally diverges. -- PapiLab must define a small owned boundary before scientific work is accepted +- Scient must define a small owned boundary before scientific work is accepted into project state. -- The first slice must pressure-test whether Synara can host PapiLab without +- The first slice must pressure-test whether Synara can host Scient without forcing research into coding projects, Git worktrees, or provider chats. - Exact package placement, schemas, runtime events, and storage models remain undecided until source tracing and implementation produce evidence. ## Revisit Triggers -The PapiLab ownership boundary in Decisions 5 and 10 implements the accepted +The Scient ownership boundary in Decisions 5 and 10 implements the accepted product requirement that external tools must not become canonical scientific project truth. The triggers below apply to the selection and use of Synara and Scient's OpenCode-derived source foundation, not to that ownership boundary. @@ -139,7 +138,7 @@ Revisit this decision if: - Synara's architecture prevents a coherent scientific project experience; - maintaining the fork costs more than retaining selected components in a new - PapiLab shell; + Scient shell; - Scient's inherited OpenCode core cannot support required scientific or safety behavior without broad, unstable core changes; - another source or architecture materially improves Scient's capabilities; or diff --git a/docs/architecture/decisions/README.md b/docs/architecture/decisions/README.md index a25d720..eb57cdf 100644 --- a/docs/architecture/decisions/README.md +++ b/docs/architecture/decisions/README.md @@ -3,14 +3,14 @@ Status: Active Owner: Yaacov Last updated: 2026-07-17 -Purpose: Indexes PapiLab's accepted architecture decision records and the rules for using them. +Purpose: Indexes Scient's accepted architecture decision records and the rules for using them. Doc type: Repo orientation Accepted architecture decisions should live here when decisions are made. Current decisions: -- `ADR-0001-synara-opencode-foundation-and-papilab-ownership-boundary.md` - accepts the owned Synara fork as the initial application foundation, Scient as the owned OpenCode-derived first-party agent, external OpenCode as a separate external agent, and the PapiLab-owned scientific boundary around agent execution. +- `ADR-0001-synara-opencode-foundation-and-scient-ownership-boundary.md` - accepts the owned Synara fork as the initial application foundation, OpenCode as the inherited source foundation for the planned Scient agent, external OpenCode as a separate external agent, and the Scient-owned scientific boundary around agent execution. Supporting file: diff --git a/docs/architecture/local-first-sync.md b/docs/architecture/local-first-sync.md index 08d73db..a786b01 100644 --- a/docs/architecture/local-first-sync.md +++ b/docs/architecture/local-first-sync.md @@ -2,11 +2,11 @@ Status: Placeholder Owner: Yaacov -Last updated: 2026-06-27 -Purpose: Defines what should be documented about PapiLab local-first storage and cloud sync once the design is validated. +Last updated: 2026-07-17 +Purpose: Defines what should be documented about Scient local-first storage and cloud sync once the design is validated. Doc type: Future home -This page will document PapiLab's local-first and sync architecture when it exists. +This page will document Scient's local-first and sync architecture when it exists. Document here: diff --git a/docs/architecture/project-format.md b/docs/architecture/project-format.md index 34396d7..91ffaec 100644 --- a/docs/architecture/project-format.md +++ b/docs/architecture/project-format.md @@ -2,11 +2,11 @@ Status: Placeholder Owner: Yaacov -Last updated: 2026-06-27 -Purpose: Defines what should be documented about PapiLab project structure once the format is designed. +Last updated: 2026-07-17 +Purpose: Defines what should be documented about Scient project structure once the format is designed. Doc type: Future home -This page will document the PapiLab project format when it exists. +This page will document the Scient project format when it exists. Document here: diff --git a/docs/architecture/security-and-permissions.md b/docs/architecture/security-and-permissions.md index 562fb84..d5d352e 100644 --- a/docs/architecture/security-and-permissions.md +++ b/docs/architecture/security-and-permissions.md @@ -2,35 +2,35 @@ Status: Draft Owner: Yaacov -Last updated: 2026-06-27 -Purpose: Defines PapiLab's early security, trust-boundary, and permission principles before implementation-specific architecture exists. +Last updated: 2026-07-17 +Purpose: Defines Scient's early security, trust-boundary, and permission principles before implementation-specific architecture exists. Doc type: Architecture direction ## Document Rules -This document defines security and permission principles for the future PapiLab architecture. It does not describe implemented authorization, accepted compliance posture, account architecture, sync protocol, cloud provider, or runtime sandbox. +This document defines security and permission principles for the future Scient architecture. It does not describe implemented authorization, accepted compliance posture, account architecture, sync protocol, cloud provider, or runtime sandbox. Do not use this document as institutional compliance evidence. University, hospital, enterprise, grant, or regulated-data claims must be backed by later implementation, controls, tests, policies, and operating procedures. -Use it to evaluate architecture proposals, agent-tool contracts, local-first project design, cloud mirroring, sharing, and implementation plans. Update it when PapiLab has real architecture decisions or implemented security behavior. +Use it to evaluate architecture proposals, agent-tool contracts, local-first project design, cloud mirroring, sharing, and implementation plans. Update it when Scient has real architecture decisions or implemented security behavior. ## Current State -The current repo is documentation-first. PapiLab does not yet have an implemented app, auth system, sync engine, local sandbox, project permission model, or cloud collaboration model. +The current repo is documentation-first. Scient does not yet have an implemented app, auth system, sync engine, local sandbox, project permission model, or cloud collaboration model. -The principles below are adapted from the old PapiLab_2026 security baseline, but they are rewritten for the new local-first, cloud-mirrored product direction. +The principles below are adapted from the old Scient_2026 security baseline, but they are rewritten for the new local-first, cloud-mirrored product direction. ## Security Position -PapiLab will hold sensitive research material: sources, PDFs, notes, datasets, code, analysis outputs, manuscript drafts, memory, collaborator comments, agent logs, and potentially unpublished results. +Scient will hold sensitive research material: sources, PDFs, notes, datasets, code, analysis outputs, manuscript drafts, memory, collaborator comments, agent logs, and potentially unpublished results. Security must protect the research project as the durable center of work. Local files, local structured state, cloud mirrors, shared projects, agent tools, external imports, and publication exports must not become competing trust boundaries with unclear authority. -PapiLab should be designed so future institutional security review is possible without rewriting the product foundation. That means project ownership, identity, permissions, auditability, data lifecycle, cloud mirroring, local execution, agent tooling, and external integrations need explicit boundaries from the beginning, even when the first implementation is intentionally smaller. +Scient should be designed so future institutional security review is possible without rewriting the product foundation. That means project ownership, identity, permissions, auditability, data lifecycle, cloud mirroring, local execution, agent tooling, and external integrations need explicit boundaries from the beginning, even when the first implementation is intentionally smaller. ## Sensitive Data Classes -PapiLab should assume that real projects may contain sensitive material, including: +Scient should assume that real projects may contain sensitive material, including: - unpublished manuscripts, hypotheses, results, and intellectual property, - licensed or institution-provided PDFs and source material, @@ -39,7 +39,7 @@ PapiLab should assume that real projects may contain sensitive material, includi - collaborator identities, comments, assignments, decisions, and review history, - agent prompts, context receipts, tool calls, run logs, memory, and generated artifacts. -Before implementation, PapiLab must decide which sensitive data classes are supported, unsupported, or institution-gated at each product maturity level. Unsupported sensitive data should be clearly excluded rather than accidentally accepted by silence. +Before implementation, Scient must decide which sensitive data classes are supported, unsupported, or institution-gated at each product maturity level. Unsupported sensitive data should be clearly excluded rather than accidentally accepted by silence. ## Threat Sources To Model @@ -56,11 +56,11 @@ Security design should consider at least these threat sources: ## Core Invariants -### Permission Scope Belongs To PapiLab +### Permission Scope Belongs To Scient The model does not decide what it may read, write, export, delete, share, or run. -Agent tools, local executors, cloud services, collaborators, and external integrations must operate inside permission scope enforced by PapiLab's architecture. +Agent tools, local executors, cloud services, collaborators, and external integrations must operate inside permission scope enforced by Scient's architecture. ### AI Tools Do Not Widen Authority @@ -72,7 +72,7 @@ An agent request to read a file, update evidence, edit a manuscript, run code, m Missing metadata, uncertain source identity, parser failures, low-confidence extraction, ambiguous duplicate matches, stale analysis outputs, and incomplete citation data should remain visible as uncertainty. -PapiLab should not silently invent authoritative values to make project state look cleaner than it is. +Scient should not silently invent authoritative values to make project state look cleaner than it is. ### Local Ownership Does Not Remove Trust Boundaries @@ -128,7 +128,7 @@ These areas need focused design before they become implementation commitments: - retention, deletion, portability, account closure, and institutional handoff behavior, - vulnerability disclosure, incident response, security review, and regression-test expectations. -## Policy Transfer From PapiLab_2026 +## Policy Transfer From Scient_2026 Carry forward these old-app lessons: @@ -151,16 +151,16 @@ Do not carry forward old implementation-specific assumptions as product truth: ## Open Questions - What is the first local project permission model? -- How does PapiLab distinguish project files from out-of-scope local files? +- How does Scient distinguish project files from out-of-scope local files? - Which agent actions require approval, and which can run under pre-approved scopes? - How should cloud mirroring represent device identity, project membership, revocation, and conflict state? - What is the minimum safe sandbox for local code execution? - How should sensitive project memory be scoped across projects, users, devices, and cloud mirrors? - Which sensitive data classes are explicitly supported, unsupported, or institution-gated in the first product versions? - What account, device, and organization model is needed for university or lab teams without making the first product enterprise-heavy? -- Should PapiLab support institution-managed identity such as single sign-on early, later, or only after a specific partnership requires it? +- Should Scient support institution-managed identity such as single sign-on early, later, or only after a specific partnership requires it? - What encryption and key-management posture is required for local projects, cloud mirrors, backups, exports, and shared projects? - What audit events must be durable enough for institutional review, and which logs are only developer diagnostics? - How are prompts, context receipts, agent logs, memory, and generated artifacts redacted, retained, exported, or deleted? - How should secrets, API keys, database credentials, and external connector tokens be stored, scoped, rotated, and excluded from agent-visible context? -- What is the first vulnerability disclosure and incident-response process once external users or institutions depend on PapiLab? +- What is the first vulnerability disclosure and incident-response process once external users or institutions depend on Scient? diff --git a/docs/architecture/technology-stack.md b/docs/architecture/technology-stack.md index b9bdc4b..cfaf59f 100644 --- a/docs/architecture/technology-stack.md +++ b/docs/architecture/technology-stack.md @@ -3,10 +3,10 @@ Status: Proposed Owner: Yaacov Last updated: 2026-07-17 -Purpose: Records PapiLab's current technology stack direction and open implementation decisions. +Purpose: Records Scient's current technology stack direction and open implementation decisions. Doc type: Architecture direction -This document records the current technology stack direction for PapiLab and +This document records the current technology stack direction for Scient and distinguishes that direction from the inherited scaffold currently available in the lab. @@ -23,14 +23,14 @@ material unresolved risk changes. Put product sequencing in `../planning/product-roadmap.md`, implementation work in the relevant planning document, and exact run evidence under `lab/`. -The owned Synara checkout under `desktop-app-forks/synara/` is the maintained +The owned Synara checkout under `desktop-app-forks/scient-desktop/` is the maintained application foundation. Its inherited package layout, dependencies, state model, and provider model remain implementation evidence, not automatically accepted -PapiLab architecture. +Scient architecture. ## Product Constraints -PapiLab is a local-first, cloud-mirrored scientific workspace. Local work must remain usable offline, while cloud mirroring supports backup, cross-device access, sharing, and collaboration. +Scient is a local-first, cloud-mirrored scientific workspace. Local work must remain usable offline, while cloud mirroring supports backup, cross-device access, sharing, and collaboration. The stack must support: @@ -44,12 +44,11 @@ The stack must support: The core architectural rule is: -> PapiLab owns scientific truth. Agents and infrastructure serve that truth. +> Scient owns scientific truth. Agents and infrastructure serve that truth. -`../product/scient-product-identity.md` accepts ScientFactory as the future -company and Scient as both app and native-agent name. This document continues -to use PapiLab for current implemented surfaces until the rename is executed; -technical text distinguishes the Scient agent where needed. +`../product/scient-product-identity.md` accepts ScientFactory as the company +and Scient as both app and native-agent name. Technical text distinguishes the +Scient app from the planned Scient agent where needed. ## Stack Summary @@ -58,10 +57,10 @@ technical text distinguishes the Scient agent where needed. | Product language | TypeScript | Proposed; inherited scaffold currently uses TypeScript 5.7 | | UI framework | React | Proposed; inherited scaffold uses React with Vite | | Desktop shell | Electron | Proposed first choice; present in inherited scaffold | -| Local coordinator | Bun/Node.js WebSocket server | Inherited scaffold candidate; not yet a PapiLab decision | -| Workspace tooling | Bun workspaces, Turborepo, Vite | Inherited scaffold candidate; not yet a PapiLab decision | +| Local coordinator | Bun/Node.js WebSocket server | Inherited scaffold candidate; not yet a Scient decision | +| Workspace tooling | Bun workspaces, Turborepo, Vite | Inherited scaffold candidate; not yet a Scient decision | | Cloud web app | React, with Next.js as a later candidate | Not scaffolded | -| Local database | SQLite | Proposed; inherited scaffold uses it for app/session projections, not PapiLab project truth | +| Local database | SQLite | Proposed; inherited scaffold uses it for app/session projections, not Scient project truth | | Cloud database | Postgres | Proposed; not scaffolded | | Cloud platform | Supabase | Initial default candidate; not scaffolded | | Large file storage | Object storage | Proposed; not scaffolded | @@ -69,7 +68,7 @@ technical text distinguishes the Scient agent where needed. | Application foundation | Owned Synara fork | Accepted initial foundation through ADR-0001; scientific product fit remains unproven | | External-agent layer | Synara provider contracts and service | Inherited machinery for external agents; preservation required, project-task compatibility not yet certified | | First-party agent | Scient, derived from the owned OpenCode fork | Accepted identity and source foundation through ADR-0001; Scient product/runtime not yet implemented | -| Later Scient source | Goose | Source-depth candidate for capabilities and architecture lessons; deferred until after the first PapiLab gateway | +| Later Scient source | Goose | Source-depth candidate for capabilities and architecture lessons; deferred until after the first Scient gateway | | Executor safety reference | Codex | Evaluation/reference | | Scientific runtime | Python via uv | Proposed | | Native services | Rust selectively | Deferred until needed | @@ -80,51 +79,52 @@ technical text distinguishes the Scient agent where needed. ## Actual Scaffold State As of 2026-07-17, the executable application scaffold is the owned Synara -checkout at `desktop-app-forks/synara/`. Its PapiLab identity and project-init +checkout at `desktop-app-forks/scient-desktop/`. Its Scient identity and project-init lane passed hosted CI at `2ecdbb5e` and was merged as `50294e64`. The subsequent application-foundation follow-up passed hosted CI at `f7760e97` and advanced the owned application baseline. A later maintained sync through official Synara v0.5.5 passed hosted CI at `d4b10c27` and advanced owned `main` to -`fd37cdcd`, zero commits behind tested upstream `9be46c3c`; exact provenance is -recorded in `lab/external/sources.lock.md`. -The owned OpenCode fork—the current source foundation for Scient—is at -`agent-forks/opencode/` on `dev` at `8c19505ec`, -after reviewed syncs through OpenCode 1.18.3 at official upstream -`b527f605d`. Its final hosted source-quality run passed at `865f8bde1`, and the -owned default was zero commits behind that tested upstream. Historical +`fd37cdcd`. The Scient rename then passed hosted CI at `179fa01e` and merged to +owned `main` as `d9d8992a`, based on tested upstream `9be46c3c`; exact +provenance is recorded in `lab/external/sources.lock.md`. +The owned OpenCode-derived fork—the current source foundation for the Scient +agent—is at `agent-forks/scient-agent/` on `dev` at `5ffaf9a2`, after a reviewed +sync through source version 1.18.3 at official upstream `69a80663`. Hosted +Scient source-quality run `29595488492` passed at exact head `5d232a34`, and +the owned default was zero commits behind that tested upstream. Historical Gate 1 and Gate 1.5 commits, tags, and ignored runtime evidence remain -historical records; they are not the active PapiLab implementation baseline. +historical records; they are not the active Scient implementation baseline. The scaffold currently provides: -| Scaffold area | Inspected reality | PapiLab boundary | +| Scaffold area | Inspected reality | Scient boundary | |---|---|---| -| Desktop | Electron app under `apps/desktop` | Candidate shell machinery, not accepted PapiLab product architecture | +| Desktop | Electron app under `apps/desktop` | Candidate shell machinery, not accepted Scient product architecture | | Local UI | React 19 and Vite under `apps/web` | Local workbench UI; not the future cloud web client | -| Local coordinator | Bun during development, Node-compatible build, WebSocket RPC, provider routing, terminal/filesystem/Git/browser services under `apps/server` | Runtime machinery PapiLab may wrap or borrow; not the scientific project kernel | -| Local state | SQLite through Effect SQL | Synara session/orchestration projection state; not canonical PapiLab scientific state | -| Shared contracts | Effect schemas in `packages/contracts` plus runtime helpers in `packages/shared` | Candidate provider/runtime boundary; PapiLab domain contracts do not exist yet | -| Agent integration | Existing provider adapters, including external OpenCode, plus compatibility evidence from the owned OpenCode build | Reusable external-agent machinery; Scient, its isolated identity, and the PapiLab gateway do not exist yet | +| Local coordinator | Bun during development, Node-compatible build, WebSocket RPC, provider routing, terminal/filesystem/Git/browser services under `apps/server` | Runtime machinery Scient may wrap or borrow; not the scientific project kernel | +| Local state | SQLite through Effect SQL | Synara session/orchestration projection state; not canonical Scient scientific state | +| Shared contracts | Effect schemas in `packages/contracts` plus runtime helpers in `packages/shared` | Candidate provider/runtime boundary; Scient domain contracts do not exist yet | +| Agent integration | Existing provider adapters, including external OpenCode, plus compatibility evidence from the owned OpenCode build | Reusable external-agent machinery; Scient, its isolated identity, and the Scient gateway do not exist yet | | Tooling | Bun workspaces, Turborepo, Vite, Vitest, TypeScript 5.7 | Inherited compatibility baseline, not an automatic long-term commitment | -`lab/papilab-bridge/` currently contains planning documentation only. The owned -Synara checkout now contains the dependency-light `@papilab/project-init` -package, but there are still no PapiLab-owned scientific domain contracts, +`lab/scient-bridge/` currently contains planning documentation only. The owned +desktop checkout now contains the dependency-light `@scientfactory/project-init` +package, but there are still no Scient-owned scientific domain contracts, Scient implementation, agent gateway, cloud client, sync implementation, or production build pipeline. ### Scaffold Use Rule The inherited scaffold pass and owned-fork identity pass are complete. Continue -to sync the owned Synara fork deliberately, preserve the isolated PapiLab state +to sync the owned Synara fork deliberately, preserve the isolated Scient state and updater boundary, and promote only the parts that prove useful behind a -PapiLab-owned project and agent contract. Do not restructure inherited packages +Scient-owned project and agent contract. Do not restructure inherited packages or add scientific truth to Synara state merely because the shell now carries -PapiLab identity. +Scient identity. ### TypeScript Version Baseline -Use the current stable TypeScript release for new PapiLab-owned packages when +Use the current stable TypeScript release for new Scient-owned packages when their selected dependencies support it. As of 2026-07-09, that means TypeScript 7.x, the native TypeScript compiler line announced by the TypeScript team on 2026-07-08 @@ -136,22 +136,22 @@ without a compiler upgrade first. A later TypeScript 7 compatibility spike must check the actual Effect language service, Electron, React, Vite, test, lint, and build paths before changing the inherited baseline. -TypeScript 5.7 is therefore a scaffold compatibility fact, not a PapiLab product -commitment. TypeScript 7 is a target baseline for new PapiLab-owned code, not a +TypeScript 5.7 is therefore a scaffold compatibility fact, not a Scient product +commitment. TypeScript 7 is a target baseline for new Scient-owned code, not a prerequisite for the first Synara health check. Record any durable exception in `docs/development/typescript.md` or the relevant implementation document once -PapiLab-owned code exists. +Scient-owned code exists. ## Application Architecture -PapiLab should be built as a desktop-first product with a cloud collaboration plane. +Scient should be built as a desktop-first product with a cloud collaboration plane. The local app must remain useful without network access. The cloud layer provides account identity, backup, cross-device access, project sharing, collaboration, background jobs, and web access. The current lab scaffold has this upstream shape: ```text -desktop-app-forks/synara/ +desktop-app-forks/scient-desktop/ apps/desktop apps/server apps/web @@ -160,13 +160,13 @@ desktop-app-forks/synara/ packages/shared ``` -That tree remains foreign source and should not become the PapiLab package map by +That tree remains foreign source and should not become the Scient package map by accident. Source-tracing notes and disposable adapter experiments may use -`lab/papilab-bridge/`. The first vertical-slice implementation belongs in the +`lab/scient-bridge/`. The first vertical-slice implementation belongs in the permanent location selected from source evidence during the implementation plan; do not treat the lab as its default code home. -Possible later PapiLab-owned package areas include: +Possible later Scient-owned package areas include: ```text apps/desktop @@ -193,13 +193,13 @@ where practical. Use Electron for the first desktop experiment. The inherited Synara scaffold already provides the Electron shell. -Electron is the pragmatic first choice because PapiLab needs React, local files, SQLite, subprocesses, agent CLIs, and local background services. These are all easier to integrate in Electron than in a stricter native shell during the first product build. +Electron is the pragmatic first choice because Scient needs React, local files, SQLite, subprocesses, agent CLIs, and local background services. These are all easier to integrate in Electron than in a stricter native shell during the first product build. The immediate validation question is whether the Synara-derived shell can host -a PapiLab-owned project mode without forcing scientific work into coding +a Scient-owned project mode without forcing scientific work into coding projects, Git worktrees, provider threads, or engine-owned artifacts. If it cannot, keep useful runtime components as references or donors and build a -smaller PapiLab-owned shell instead of deepening the fork. +smaller Scient-owned shell instead of deepening the fork. Tauri is not rejected. It is deferred. @@ -208,13 +208,13 @@ Tauri should be reconsidered if Electron becomes a proven blocker for memory use ## Web The scaffold's `apps/web` is a React/Vite local workbench UI used by the local -server and Electron app. It is not a scaffold for PapiLab's future cloud web +server and Electron app. It is not a scaffold for Scient's future cloud web client. Use React for the future cloud web app. Next.js remains a default candidate, but no cloud web app exists yet and it is not part of the first local scaffold pass. -PapiLab's core product model should not depend on Next.js-specific server -behavior. The eventual web app should be a continuation client of the PapiLab +Scient's core product model should not depend on Next.js-specific server +behavior. The eventual web app should be a continuation client of the Scient cloud/project model, not a separate product with separate semantics. ## Local Data @@ -223,10 +223,10 @@ Use SQLite locally. The inherited scaffold already uses SQLite for Synara app, session, orchestration, and projection state. That database must not be relabeled as the -PapiLab scientific project database. PapiLab-owned project persistence has not +Scient scientific project database. Scient-owned project persistence has not been designed or implemented. -PapiLab should distinguish: +Scient should distinguish: - global app state, such as recent projects, local settings, device identity, and local caches - per-project scientific state, such as papers, protocol records, evidence records, extraction records, manuscript state, agent runs, and sync metadata @@ -235,7 +235,7 @@ The per-project database is the more important architectural object because proj The inherited scaffold uses Effect SQL with SQLite through Bun. Do not replace that layer merely to satisfy the target stack before the scaffold baseline is -known. For PapiLab-owned project persistence, evaluate Effect SQL, Drizzle, +known. For Scient-owned project persistence, evaluate Effect SQL, Drizzle, Kysely, or a narrower owned layer after the first project-state contract exists. ## Cloud Data @@ -244,7 +244,7 @@ Use Postgres as the cloud database. Use Supabase as the initial default cloud platform candidate because it provides hosted Postgres, object storage, auth options, realtime primitives, row-level security, and local development tooling. -The architectural commitment is to Postgres and object storage, not to Supabase-specific behavior. PapiLab should avoid unnecessary dependence on Supabase-only features where standard Postgres, portable SQL, or provider-neutral object storage is sufficient. +The architectural commitment is to Postgres and object storage, not to Supabase-specific behavior. Scient should avoid unnecessary dependence on Supabase-only features where standard Postgres, portable SQL, or provider-neutral object storage is sufficient. ## File Storage @@ -274,11 +274,11 @@ Current candidates: - PowerSync for SQLite-to-Postgres local-first sync - Electric for Postgres-backed read sync and live web/cloud views -- a PapiLab-owned sync layer if vendor tools do not fit the required project model +- a Scient-owned sync layer if vendor tools do not fit the required project model Convex is not selected as the primary database or local-first sync foundation. It may be evaluated for collaboration features or realtime cloud workflows, but the current stack direction requires portable local project state backed by SQLite. -PapiLab should maintain domain-level mutation and audit semantics so the product is not locked to one sync vendor. +Scient should maintain domain-level mutation and audit semantics so the product is not locked to one sync vendor. ## Collaboration @@ -298,7 +298,7 @@ Do not use CRDTs as the whole application database. ## Versioning -PapiLab should use layered versioning. +Scient should use layered versioning. Current direction: @@ -315,16 +315,16 @@ The agent runtime is an execution layer, not the product kernel. The inherited scaffold already contains provider contracts, a provider service, session/event projections, and adapters for several coding agents. These are -runtime candidates. PapiLab does not yet have its own agent gateway, scientific +runtime candidates. Scient does not yet have its own agent gateway, scientific task contract, context receipt, run ledger, proposed-change lifecycle, or accepted write-back path. Current posture: -- Build the first PapiLab workflow through **Scient**, PapiLab's first-party - research agent derived from the owned OpenCode fork. +- Build the first Scient workflow through the **Scient agent**, the product's + first-party research agent derived from the owned OpenCode fork. - Treat Scient as one agent product, codebase, runtime identity, configuration, - release, and update channel. Do not model it as a PapiLab shell that launches + release, and update channel. Do not model it as a Scient shell that launches a separately identified OpenCode engine. - Keep inherited OpenCode core and Scient-owned capabilities and integrations identifiable inside Scient's source where practical. This is a maintenance @@ -338,12 +338,12 @@ Current posture: separately offered external Goose agent, but Scient must not become a shell that silently switches between branded engines. - Treat any Goose permissions, sessions, recipes, and tool events as research or - external-runtime inputs to normalize. They do not provide the PapiLab project + external-runtime inputs to normalize. They do not provide the Scient project boundary or canonical run ledger by themselves. -PapiLab should not commit to any agent's internal data model as the canonical project model. +Scient should not commit to any agent's internal data model as the canonical project model. -Agents should act through PapiLab-owned tools and permission policies, especially for high-impact scientific changes. +Agents should act through Scient-owned tools and permission policies, especially for high-impact scientific changes. ## Scientific Runtime @@ -406,7 +406,7 @@ The chosen auth layer must support project membership, invitations, roles, devic Open-source systems may be used as references, engines, adapters, or fork candidates. -They must not replace the PapiLab scientific kernel. +They must not replace the Scient scientific kernel. Preferred licenses: @@ -442,7 +442,7 @@ Do not choose these by default on day one: - Convex as the primary database - Git as the required sharing system - CRDTs as the entire app data model -- an agent's internal session database as PapiLab's source of truth +- an agent's internal session database as Scient's source of truth ## Validation Status And Remaining Unknowns @@ -450,11 +450,11 @@ Completed historical experiments remain evidence, not the roadmap. | Area | Proven | Not Yet Proven | Evidence Or Owner | |---|---|---|---| -| Synara-derived application | Owned fork, build, isolated PapiLab 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 | +| Synara-derived application | Owned fork, 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 | | 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) | -| PapiLab project state | Product responsibilities and trust boundary are documented | Persistence, portable local record, recovery, and first real scientific object relationship | First vertical-slice plan | -| Scient-agent and PapiLab-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 | +| Scient project state | Product responsibilities and trust boundary are documented | Persistence, portable local record, recovery, and first real scientific object relationship | First vertical-slice plan | +| 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 | @@ -487,6 +487,6 @@ Git for human-readable artifacts, not required sharing ``` Update this document when a technology role or its validation status changes. -The overall target stack remains proposed until the first PapiLab-owned local +The overall target stack remains proposed until the first Scient-owned local project and agent boundaries work. Cloud and web choices remain later proposals until their authority and sync risks are tested. diff --git a/docs/design/README.md b/docs/design/README.md index 4e8926f..ed51ba7 100644 --- a/docs/design/README.md +++ b/docs/design/README.md @@ -2,8 +2,8 @@ Status: Active Owner: Yaacov -Last updated: 2026-06-28 -Purpose: Defines where PapiLab product design documentation should live. +Last updated: 2026-07-17 +Purpose: Defines where Scient product design documentation should live. Doc type: Repo orientation Use this folder for product design principles, interaction guidance, accessibility expectations, and UI direction once those documents have real content. diff --git a/docs/design/chat-interface-ux.md b/docs/design/chat-interface-ux.md index c41c15c..708a9d1 100644 --- a/docs/design/chat-interface-ux.md +++ b/docs/design/chat-interface-ux.md @@ -2,8 +2,8 @@ Status: Draft Owner: Yaacov -Last updated: 2026-06-28 -Purpose: Captures early UX/UI notes for PapiLab chat and streaming conversation surfaces. +Last updated: 2026-07-17 +Purpose: Captures early UX/UI notes for Scient chat and streaming conversation surfaces. Doc type: Planning note ## Document Rules @@ -16,9 +16,9 @@ Add only concrete insights from product discussion, source review, prototypes, o ## Current State -PapiLab does not have an implemented chat interface yet. +Scient does not have an implemented chat interface yet. -The accepted PRD says PapiLab's product center is the durable research project, not chat. Chat should support project work, while important agent outputs should land in the relevant project surface for review and continuation. +The accepted PRD says Scient's product center is the durable research project, not chat. Chat should support project work, while important agent outputs should land in the relevant project surface for review and continuation. ## Captured Insight: Streaming Scroll Behavior @@ -26,7 +26,7 @@ Source: shadcn post shared by Yaacov on 2026-06-28. The external post has not be Core insight: in a streaming chat, preserving the reader's position is part of the product experience. The interface should follow the stream only while the user appears to be following it. -Candidate implications for PapiLab chat surfaces: +Candidate implications for Scient chat surfaces: - Keep the live response in view while the researcher is at the live edge. - Stop following when the researcher scrolls away, selects text, uses keyboard navigation, opens a link, searches, or focuses something inside the transcript. @@ -41,7 +41,7 @@ Candidate implications for PapiLab chat surfaces: ## Open Questions -- Which chat surfaces does PapiLab need first: project-wide agent chat, object-scoped chat, review chat, mobile chat, or some combination? +- Which chat surfaces does Scient need first: project-wide agent chat, object-scoped chat, review chat, mobile chat, or some combination? - What counts as the last meaningful turn in a research project: last user instruction, last review checkpoint, last unresolved agent proposal, or last opened project object? - How should chat position interact with position inside source readers, evidence views, manuscript sections, code outputs, and artifact previews? - What is the right mobile role for streaming chat: reading, review, approvals, lightweight continuation, or fuller conversation? diff --git a/docs/design/product-design-principles.md b/docs/design/product-design-principles.md index 3c6364c..5b4876e 100644 --- a/docs/design/product-design-principles.md +++ b/docs/design/product-design-principles.md @@ -2,8 +2,8 @@ Status: Placeholder Owner: Yaacov -Last updated: 2026-06-27 -Purpose: Future home for PapiLab product design principles once there are real design decisions or prototypes to document. +Last updated: 2026-07-17 +Purpose: Future home for Scient product design principles once there are real design decisions or prototypes to document. Doc type: Future home ## Document Rules @@ -12,4 +12,4 @@ This document has not been written yet. Do not use this file as current design doctrine, UI direction, product truth, or implementation guidance. -When PapiLab has real product design principles to preserve, this file should define them concisely and link to the product, planning, or design evidence they came from. +When Scient has real product design principles to preserve, this file should define them concisely and link to the product, planning, or design evidence they came from. diff --git a/docs/development/README.md b/docs/development/README.md index 882550f..acdeaff 100644 --- a/docs/development/README.md +++ b/docs/development/README.md @@ -2,11 +2,11 @@ Status: Placeholder Owner: Yaacov -Last updated: 2026-06-27 +Last updated: 2026-07-17 Purpose: Defines where development documentation should live once implementation exists. Doc type: Future home -Use this folder once PapiLab has code, commands, packages, tests, APIs, configuration, or local development workflows to document. +Use this folder once Scient has code, commands, packages, tests, APIs, configuration, or local development workflows to document. Document here when relevant: diff --git a/docs/development/typescript.md b/docs/development/typescript.md index 37d58b4..13215be 100644 --- a/docs/development/typescript.md +++ b/docs/development/typescript.md @@ -2,11 +2,11 @@ Status: Placeholder Owner: Yaacov -Last updated: 2026-06-27 -Purpose: Future home for PapiLab TypeScript conventions once implementation begins. +Last updated: 2026-07-17 +Purpose: Future home for Scient TypeScript conventions once implementation begins. Doc type: Future home -This file will define PapiLab's TypeScript conventions when the repo has TypeScript code. +This file will define Scient's TypeScript conventions when the repo has TypeScript code. The conventions below are candidates to revisit before implementation. They are not yet active coding standards because no TypeScript project structure exists in this repo. diff --git a/docs/documentation-policy.md b/docs/documentation-policy.md index 362f661..d8678b9 100644 --- a/docs/documentation-policy.md +++ b/docs/documentation-policy.md @@ -2,8 +2,8 @@ Status: Active Owner: Yaacov -Last updated: 2026-07-12 -Purpose: Defines how PapiLab documentation should be created, classified, updated, and trusted. +Last updated: 2026-07-17 +Purpose: Defines how Scient documentation should be created, classified, updated, and trusted. Doc type: Documentation policy ## Required Metadata @@ -13,7 +13,7 @@ Every durable Markdown document must place this metadata block immediately after ```md Status: ... Owner: ... -Last updated: YYYY-MM-DD +Last updated: 2026-07-17 Purpose: ... Doc type: ... ``` @@ -89,11 +89,11 @@ Do not turn root files into broad planning or architecture documents. ## Repository Scope And Connected Knowledge -This policy governs durable documentation in the PapiLab repository. The repository currently owns PapiLab product and project knowledge; it is not the unrestricted memory of the whole company. +This policy governs durable documentation in the Scient repository. The repository currently owns Scient product and project knowledge; it is not the unrestricted memory of the whole company. -Company, commercial, market, or customer material may live here when it directly informs PapiLab and is placed as product truth, planning, research, architecture, or another existing type. Company-wide strategy, finance, legal, people, customer records, and cross-product authority require a separately accepted home and authority model. +Company, commercial, market, or customer material may live here when it directly informs Scient and is placed as product truth, planning, research, architecture, or another existing type. Company-wide strategy, finance, legal, people, customer records, and cross-product authority require a separately accepted home and authority model. -A broader company memory may connect to PapiLab through links and shared conventions without living in the same repository. Connected context does not override the nearest authoritative source. +A broader company memory may connect to Scient through links and shared conventions without living in the same repository. Connected context does not override the nearest authoritative source. The current scope recommendation and unresolved structural choices live in `docs/planning/repository-scope-and-company-memory.md`. diff --git a/docs/onboarding.md b/docs/onboarding.md index 33dfa80..fc0b4f7 100644 --- a/docs/onboarding.md +++ b/docs/onboarding.md @@ -3,7 +3,7 @@ Status: Active Owner: Yaacov Last updated: 2026-07-17 -Purpose: Gives new PapiLab collaborators a deliberate reading journey through the project, its repository, and its sources of truth before task-specific work begins. +Purpose: Gives new Scient collaborators a deliberate reading journey through the project, its repository, and its sources of truth before task-specific work begins. Doc type: Repo orientation ## Document Rules @@ -14,35 +14,36 @@ Use the linked source documents as authority. Do not copy their detailed content ## Who This Is For -This guide is for anyone joining PapiLab work: product collaborators, researchers, designers, engineers, reviewers, and people working through AI agents. +This guide is for anyone joining Scient work: product collaborators, researchers, designers, engineers, reviewers, and people working through AI agents. Complete the shared reading journey before starting the contribution-area route that matches your work. The task itself should arrive separately, with its own objective, scope, authority, expected output, and validation requirements. ## Current Project State -PapiLab is a local-first, cloud-mirrored scientific workspace where researchers, collaborators, and AI agents should be able to carry a research project from its initial question to publication-ready outputs. +Scient is a local-first, cloud-mirrored scientific workspace where researchers, collaborators, and AI agents should be able to carry a research project from its initial question to publication-ready outputs. This parent repository remains documentation-first. It contains accepted product direction, evolving architecture and planning, source-backed research, quality principles, and controlled lab experiments. The maintained desktop -fork contains the first narrow PapiLab-owned project-initiation package, but it +fork contains the first narrow Scient-owned project-initiation package, but it does not yet contain the complete scientific application, vertical slice, or the development and operational workflows that the documents anticipate. -ScientFactory is the chosen future company identity. **Scient** is the chosen -public name for both the future app and its native first-party research agent. -The current implemented app remains PapiLab until the rename plan is executed -and verified. The Scient agent will be one owned OpenCode-derived agent, not an +ScientFactory is the company identity. **Scient** is the public name for both +the implemented app and its planned native first-party research agent. The +PapiLab-to-Scient rename of existing owned surfaces is complete. The Scient +agent will be one owned OpenCode-derived agent, not an app shell around a separately exposed OpenCode engine. External OpenCode and the other external-agent choices remain independent. The Scient agent has not been implemented yet; the accepted identity, ownership decision, and proposed -implementation plans are linked below. +implementation plans are linked below. The public website cutover remains a +separately deferred owner task. -The repository currently owns PapiLab product and project knowledge. It is not yet the general memory for company strategy, finance, legal, people, customer records, or cross-product authority. A proposed connected-company model is documented in [Repository Scope And Company Memory](planning/repository-scope-and-company-memory.md), but it does not change the current boundary. +The repository currently owns Scient product and project knowledge. It is not yet the general memory for company strategy, finance, legal, people, customer records, or cross-product authority. A proposed connected-company model is documented in [Repository Scope And Company Memory](planning/repository-scope-and-company-memory.md), but it does not change the current boundary. Keep that maturity boundary in mind throughout onboarding: -- accepted product direction describes what PapiLab should become; +- accepted product direction describes what Scient should become; - proposed or draft architecture describes direction that may still change; - planning documents organize possible or upcoming work without becoming product truth; - research and lab evidence can inform decisions without becoming accepted architecture or current implementation; @@ -50,11 +51,11 @@ Keep that maturity boundary in mind throughout onboarding: ## Documentation Foundation And Placeholders -The repository's documentation structure is an intentional foundation for the project, not a claim that every part of PapiLab has already been designed or built. The [Documentation index](README.md) establishes the main knowledge areas, and the [Documentation Policy](documentation-policy.md) defines how material enters those areas and becomes trustworthy. Product, architecture, planning, research, design, quality, development, and operations work should grow on top of this base instead of creating disconnected documents or competing sources of truth. +The repository's documentation structure is an intentional foundation for the project, not a claim that every part of Scient has already been designed or built. The [Documentation index](README.md) establishes the main knowledge areas, and the [Documentation Policy](documentation-policy.md) defines how material enters those areas and becomes trustworthy. Product, architecture, planning, research, design, quality, development, and operations work should grow on top of this base instead of creating disconnected documents or competing sources of truth. Many files are deliberately marked `Placeholder`. For example, the [Development](development/README.md) and [Operations](operations/README.md) documents reserve homes for workflows that do not exist yet. Other placeholder files reserve future homes within their own areas. A placeholder should explain what will belong there, why the home exists, and what it must not be used as today. It is not an accepted decision, current guidance, an implementation specification, or evidence that the described system exists. -As PapiLab matures, collaborators should build on this documentation base deliberately: +As Scient matures, collaborators should build on this documentation base deliberately: 1. Put new knowledge in the existing area or placeholder that was created to own it. 2. Add real content only when there is a decision, evidence, implementation, or operating practice to document. @@ -68,9 +69,9 @@ Do not fill placeholders merely to make the repository look complete. Their purp Read these documents in order. The order is intentional: understand the accepted product first, then its evolving principles, then learn how project knowledge is organized and governed, and finally understand how agents are expected to work inside the repository. -1. **Enter through the repository.** Read the [PapiLab repository README](../README.md) for the shortest current-state statement and the official starting links. -2. **Understand the product.** Read the [PapiLab Product Requirements Document](product/PRD.md) in full. It is the accepted product truth. Pay particular attention to its document rules, product overview, principles, research lifecycle, workspace requirements, primary journeys, non-goals, readiness criteria, and open questions. -3. **Understand the chosen identity.** Read [Scient Product Identity](product/scient-product-identity.md) for the accepted ScientFactory company name, shared Scient app/agent name, external-agent vocabulary, and current-versus-target boundary. +1. **Enter through the repository.** Read the [Scient repository README](../README.md) for the shortest current-state statement and the official starting links. +2. **Understand the product.** Read the [Scient Product Requirements Document](product/PRD.md) in full. It is the accepted product truth. Pay particular attention to its document rules, product overview, principles, research lifecycle, workspace requirements, primary journeys, non-goals, readiness criteria, and open questions. +3. **Understand the chosen identity.** Read [Scient Product Identity](product/scient-product-identity.md) for the accepted ScientFactory company name, shared Scient app/agent name, external-agent vocabulary, and implemented-versus-planned boundary. 4. **Understand the principles behind the product.** Read the [Product Philosophy](product/product-philosophy.md). It explains the long-term ownership and first-principles posture behind the work. Its status is `Draft`, so use it as evolving product guidance and do not let it override the accepted PRD. 5. **Learn the repository map.** Read the [Documentation index](README.md) to understand where product, architecture, planning, research, design, quality, development, and operations knowledge belongs. 6. **Learn how to judge what you read.** Read the [Documentation Policy](documentation-policy.md), especially its status values, placement rules, evidence rules, promotion rules, and truth rules. This is what lets you distinguish accepted direction from proposals, plans, evidence, placeholders, and implemented behavior. @@ -84,7 +85,7 @@ After the shared journey, use this map to know where to look. You do not need to | Area | Start with | What it contains and how to treat it | | --- | --- | --- | -| Product | [Product Documentation](product/README.md) | Product truth and durable product principles. This is the first place to check what PapiLab should be and why. | +| Product | [Product Documentation](product/README.md) | Product truth and durable product principles. This is the first place to check what Scient should be and why. | | Architecture | [Architecture Documentation](architecture/README.md) | Architecture direction, proposed decisions, future architecture homes, and accepted decision records. Check each document's status before relying on it. | | Planning | [Planning](planning/README.md) | Active product roadmap, implementation plans, candidate features, open product questions, and related build sequencing. Planning is not product truth or current implementation. | | Research | [Research](research/README.md) | External-source evaluations, spike reports, visual references, and research evidence. Research must be promoted before it becomes product or architecture authority. | @@ -92,7 +93,7 @@ After the shared journey, use this map to know where to look. You do not need to | Quality | [Quality](quality/README.md) | Testing, engineering, and quality doctrine. These documents define principles, not yet-complete command or CI references. | | Development | [Development](development/README.md) | A placeholder for setup, commands, package structure, APIs, and development workflows once real implementation surfaces exist. | | Operations | [Operations](operations/README.md) | A placeholder for deployment, monitoring, support, backup, release, and maintenance workflows once they exist. | -| Experimental work | [PapiLab Lab](../lab/README.md) | Controlled source inspection, forks, adapters, prototypes, and verification evidence. Nothing here is accepted architecture or current product implementation unless it has been promoted. | +| Experimental work | [Scient Lab](../lab/README.md) | Controlled source inspection, forks, adapters, prototypes, and verification evidence. Nothing here is accepted architecture or current product implementation unless it has been promoted. | | Agent workflows | [Project Skills](../skills/README.md) | Workflow helpers for agents. Skills route agents back to project authority; they do not become authority themselves. | ## Contribution-Area Reading Routes @@ -101,7 +102,7 @@ After completing the shared journey, follow every route relevant to your contrib ### Product And Product Planning -The accepted [PapiLab Product Requirements Document](product/PRD.md), accepted [Scient Product Identity](product/scient-product-identity.md), and draft [Product Philosophy](product/product-philosophy.md) from the shared journey come first. Then read: +The accepted [Scient Product Requirements Document](product/PRD.md), accepted [Scient Product Identity](product/scient-product-identity.md), and draft [Product Philosophy](product/product-philosophy.md) from the shared journey come first. Then read: 1. [Planning](planning/README.md) to understand what planning documents may and may not own. 2. [Product Roadmap](planning/product-roadmap.md) for the active sequence of coherent product outcomes. @@ -122,7 +123,7 @@ Do not infer implemented interfaces from design notes, screenshots, or placehold ### Architecture And Engineering Direction 1. [Architecture Documentation](architecture/README.md) to learn the architecture area's authority and current map. -2. [ADR-0001](architecture/decisions/ADR-0001-synara-opencode-foundation-and-papilab-ownership-boundary.md) for the accepted Synara application foundation, Scient's OpenCode-derived source foundation, external-agent separation, and PapiLab ownership boundary. +2. [ADR-0001](architecture/decisions/ADR-0001-synara-opencode-foundation-and-scient-ownership-boundary.md) for the accepted Synara application foundation, Scient's OpenCode-derived source foundation, external-agent separation, and Scient ownership boundary. 3. [Technology Stack](architecture/technology-stack.md) for the proposed stack direction, actual scaffold state, validation status, explicit non-decisions, and deferred choices. 4. [Security And Permissions](architecture/security-and-permissions.md) for the draft trust-boundary and permission principles that architecture and agent-tool proposals must respect. 5. Continue only into the task-relevant architecture documents identified by the [architecture index](architecture/README.md) or the task handoff. @@ -135,11 +136,11 @@ Complete the architecture route first when the work may influence implementation 1. [Research](research/README.md) for the research area's evidence and promotion boundaries. 2. [Source Evaluations](research/source-evaluations/README.md) for the rules governing evaluations of external systems. -3. [PapiLab Open-Source Adaptation Map](research/source-evaluations/open-source-adaptation-map.md) for the current cross-source synthesis, candidate roles, PapiLab-owned boundaries, and research prototype backlog. +3. [Scient Open-Source Adaptation Map](research/source-evaluations/open-source-adaptation-map.md) for the current cross-source synthesis, candidate roles, Scient-owned boundaries, and research prototype backlog. 4. [Open-Source Adaptation Build Strategy](planning/open-source-adaptation-build-strategy.md) for the draft path from research candidates toward controlled build experiments. 5. [Scient And External Agents Implementation Plan](planning/scient-and-external-agents-implementation-plan.md) when the work touches Scient-agent identity, external-agent preservation, or agent/runtime isolation. -6. [First Vertical-Slice Implementation Plan](planning/first-papilab-vertical-slice-implementation-plan.md) when the work touches the active PapiLab implementation slice through Scient. -7. [PapiLab Lab](../lab/README.md) for the experimental layout, promotion rule, current evidence map, and lab guardrails. +6. [First Vertical-Slice Implementation Plan](planning/first-scient-vertical-slice-implementation-plan.md) when the work touches the active Scient implementation slice through Scient. +7. [Scient Lab](../lab/README.md) for the experimental layout, promotion rule, current evidence map, and lab guardrails. 8. Read only the spike report, lab note, or source material named by the task handoff; do not read raw research chronologically and assume the newest or most detailed file is authoritative. ### Quality And Implementation Review @@ -147,7 +148,7 @@ Complete the architecture route first when the work may influence implementation Complete the architecture route first when reviewing or writing implementation. Then read: 1. [Quality](quality/README.md) for the boundary between quality doctrine and future execution documentation. -2. [Testing Philosophy](quality/testing-philosophy.md) for PapiLab's risk-based testing posture and scientific-workflow proof obligations. +2. [Testing Philosophy](quality/testing-philosophy.md) for Scient's risk-based testing posture and scientific-workflow proof obligations. 3. [Code Quality Principles](quality/code-quality-principles.md) for the engineering review bar, truth ownership, boundary quality, and root-cause expectations. These documents define the intended quality bar before complete project-specific commands, test lanes, and CI procedures exist. @@ -157,7 +158,7 @@ These documents define the intended quality bar before complete project-specific The shared journey already requires [AGENTS.md](../AGENTS.md). Then read: 1. [Project Skills](../skills/README.md) to see which repository-specific workflows exist and how they relate to project authority. -2. For product management, PRD changes, feature analysis, roadmap work, or product research synthesis, read the [PapiLab Product Stewardship skill](../skills/product/papilab-product-stewardship/SKILL.md) before acting. +2. For product management, PRD changes, feature analysis, roadmap work, or product research synthesis, read the [Scient Product Stewardship skill](../skills/product/scient-product-stewardship/SKILL.md) before acting. An agent's memory, chat history, or generated summary is not project authority. Agents and collaborators must return to the linked repository sources when making or reviewing durable claims. @@ -165,13 +166,13 @@ An agent's memory, chat history, or generated summary is not project authority. The shared journey already includes the [Documentation index](README.md) and [Documentation Policy](documentation-policy.md). Before changing a durable document: -1. When an agent will manage the documentation, have it read the [PapiLab Documentation Stewardship skill](../skills/documentation/papilab-documentation-stewardship/SKILL.md). +1. When an agent will manage the documentation, have it read the [Scient Documentation Stewardship skill](../skills/documentation/scient-documentation-stewardship/SKILL.md). 2. Open the index for the area that should own the information. 3. Read the target document in full, including its metadata and document rules. 4. Decide whether the material is product truth, architecture direction, an architecture decision, planning, research evidence, current implementation, or a future home. 5. Update the existing canonical document when it has a proper home; create a new document only when it does not. -If the material concerns company-wide strategy, finance, legal, people, customer records, or cross-product authority, read [Repository Scope And Company Memory](planning/repository-scope-and-company-memory.md) and do not create a new PapiLab folder until that broader repository scope is accepted. +If the material concerns company-wide strategy, finance, legal, people, customer records, or cross-product authority, read [Repository Scope And Company Memory](planning/repository-scope-and-company-memory.md) and do not create a new Scient folder until that broader repository scope is accepted. ## How To Reorient Before New Work @@ -187,7 +188,7 @@ Onboarding creates a shared baseline, but the repository will continue to change A collaborator is oriented when they can: -- explain what PapiLab is, who it is for, and the research lifecycle it aims to support; +- explain what Scient is, who it is for, and the research lifecycle it aims to support; - state honestly that the repository is documentation-first and distinguish planned or experimental work from implemented product behavior; - identify where product truth, architecture direction, planning, research evidence, quality doctrine, lab evidence, and agent guidance live; - interpret `Accepted`, `Active`, `Draft`, `Proposed`, `Placeholder`, `Deprecated`, `Superseded`, and `Historical` correctly; diff --git a/docs/operations/README.md b/docs/operations/README.md index a7a79f1..24647e9 100644 --- a/docs/operations/README.md +++ b/docs/operations/README.md @@ -2,11 +2,11 @@ Status: Placeholder Owner: Yaacov -Last updated: 2026-06-27 +Last updated: 2026-07-17 Purpose: Defines where operational documentation should live once operational surfaces exist. Doc type: Future home -Use this folder once PapiLab has deployment, monitoring, release, support, maintenance, backup, or incident-response workflows. +Use this folder once Scient has deployment, monitoring, release, support, maintenance, backup, or incident-response workflows. Document here when relevant: diff --git a/docs/planning/README.md b/docs/planning/README.md index fbbf0ca..959d72d 100644 --- a/docs/planning/README.md +++ b/docs/planning/README.md @@ -3,7 +3,7 @@ Status: Active Owner: Yaacov Last updated: 2026-07-17 -Purpose: Defines where PapiLab planning documents live and how they relate to product truth, architecture, design, quality, and research documents. +Purpose: Defines where Scient planning documents live and how they relate to product truth, architecture, design, quality, and research documents. Doc type: Repo orientation Use this folder for plans that guide upcoming work. @@ -15,13 +15,13 @@ 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. -- `product-roadmap.md` - active sequence of coherent product outcomes, beginning with the first PapiLab scientific project slice. -- `first-papilab-vertical-slice-implementation-plan.md` - draft source-tracing, implementation, and verification plan for the active product slice. +- `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. -- `papilab-to-scient-rename-execution-plan.md` - proposed controlled migration from the current PapiLab implementation identity to Scient and ScientFactory. +- `papilab-to-scient-rename-execution-plan.md` - historical PapiLab-to-Scient migration, compatibility, rollback, and deferred-public-cutover record. - `litrev-to-papilab-rename-execution-plan.md` - historical intermediate product-identity migration, verification, and rollback record for renaming LitRev to PapiLab. - `gate-1-5-execution-plan.md` - historical execution plan for owned source repositories, upstream synchronization, and Synara identity isolation. -- `model-access-and-routing-evolution.md` - priorities and open choices for provider-connected, bring-your-own-key, PapiLab-managed, and automatically routed model access. +- `model-access-and-routing-evolution.md` - priorities and open choices for provider-connected, bring-your-own-key, Scient-managed, and automatically routed model access. - `open-source-adaptation-build-strategy.md` - unfinished planning note for the fork/adapter/upstream strategy that turns source evaluations into a first build path. - `product-planning.md` - draft product planning after PRD acceptance, including candidate features, open product questions, and cross-document handoffs. -- `repository-scope-and-company-memory.md` - proposed boundary between this PapiLab product repository and a future connected company memory. +- `repository-scope-and-company-memory.md` - proposed boundary between this Scient product repository and a future connected company memory. diff --git a/docs/planning/first-papilab-vertical-slice-implementation-plan.md b/docs/planning/first-scient-vertical-slice-implementation-plan.md similarity index 87% rename from docs/planning/first-papilab-vertical-slice-implementation-plan.md rename to docs/planning/first-scient-vertical-slice-implementation-plan.md index 3637551..1660be1 100644 --- a/docs/planning/first-papilab-vertical-slice-implementation-plan.md +++ b/docs/planning/first-scient-vertical-slice-implementation-plan.md @@ -1,16 +1,16 @@ -# First PapiLab Vertical Slice Implementation Plan +# First Scient Vertical Slice Implementation Plan Status: Draft Owner: Yaacov Last updated: 2026-07-17 -Purpose: Defines the bounded source-tracing, implementation, and verification plan for the first PapiLab scientific project slice. +Purpose: Defines the bounded source-tracing, implementation, and verification plan for the first Scient scientific project slice. Doc type: Planning note ## Document Rules This plan operationalizes the active product slice in `product-roadmap.md` and the ownership decision in -`../architecture/decisions/ADR-0001-synara-opencode-foundation-and-papilab-ownership-boundary.md`. +`../architecture/decisions/ADR-0001-synara-opencode-foundation-and-scient-ownership-boundary.md`. It owns the immediate work sequence, boundary-trace requirements, implementation scope, and acceptance checks for this slice. It does not define the full project format, final runtime architecture, complete scientific schema, or implemented @@ -31,13 +31,13 @@ architecture decision. ## Goal -Build one permanent PapiLab-owned workflow on the maintained Synara foundation -through **Scient**, PapiLab's owned OpenCode-derived first-party agent: manual +Build one permanent Scient-owned workflow on the maintained Synara foundation +through **Scient**, Scient's owned OpenCode-derived first-party agent: manual source capture, bounded agent assistance, a visible proposal and decision, and durable reopening and recovery. The first work begins with a bounded project-initiation placement trace and a -portable PapiLab-owned initialization kernel. The remaining **First-Slice +portable Scient-owned initialization kernel. The remaining **First-Slice Boundary Trace** follows before scientific-state, UI, or executor integration. Neither trace is another numbered gate, disposable bridge, or general Synara architecture tour. Each must end with the evidence-backed decision required by @@ -46,30 +46,31 @@ the next implementation step. ## Current Execution Status Phase 1 is complete. The placement trace selected the permanent package seam, -and desktop PR #4 implemented `@papilab/project-init` with zero-write +and desktop PR #4 implemented `@scientfactory/project-init` with zero-write inspection, explicit plan/apply behavior, conservative recovery, and 43 focused tests. The package remains present on the maintained desktop `main` at -`fd37cdcd`, after the reviewed official Synara v0.5.5 sync. The owned OpenCode -baseline is `8c19505ec` on `dev`, after the reviewed OpenCode 1.18.3 sync and -review-tooltip follow-up. +`d9d8992a`, after the verified Scient rename on the reviewed official Synara +v0.5.5 foundation. The owned OpenCode-derived agent-source baseline is +`5ffaf9a2` on `dev`, after the verified `scient-agent` source-boundary rename +and reviewed sync to official upstream `69a80663`. Phase 2, the remaining first-slice boundary trace, is the next work. The owned -OpenCode checkout is Scient's selected source foundation, but Scient itself is -not yet implemented or packaged. No scientific-state store, -project-initiation UI or server RPC, PapiLab agent gateway, +OpenCode-derived checkout is the Scient agent's selected source foundation, but +the native agent is not yet implemented or packaged. No scientific-state store, +project-initiation UI or server RPC, Scient agent gateway, proposal/decision ledger, or complete scientific workflow is claimed as implemented. ## Product Slice 1. Open an existing local folder without modifying it. -2. Preview and initialize a local non-Git PapiLab project without silently +2. Preview and initialize a local non-Git Scient project without silently overwriting existing files. -3. Persist minimal, path-independent PapiLab-owned project identity. +3. Persist minimal, path-independent Scient-owned project identity. 4. Add one selected source excerpt manually. 5. Create one bounded scientific task with an inspectable context receipt. 6. Execute the task through Scient. -7. Record the action and result in a PapiLab-owned run/proposal boundary. +7. Record the action and result in a Scient-owned run/proposal boundary. 8. Return one evidence-linked note as a proposal. 9. Let the researcher inspect, edit, accept, or reject the proposal. 10. Create a non-Git recovery point before accepted state changes. @@ -86,12 +87,12 @@ not a frozen general schema. - Treat the owned Synara monorepo as the expected application-code home, while earning the exact permanent package or module placement through source evidence. Code location does not make Synara session, projection, or provider - state canonical PapiLab state. + state canonical Scient state. - If no clean Synara-hosted seam can preserve the accepted ownership boundary, the trace may recommend a separate repository or process topology. That is an escape route requiring explicit review and any necessary ADR change, not a fourth default architecture to build speculatively. -- Use `lab/papilab-bridge/` only for disposable experiments or trace material; it +- Use `lab/scient-bridge/` only for disposable experiments or trace material; it is not the default home for the permanent slice. - Prefer existing provider, extension, configuration, tool, and adapter seams. Allow narrow inherited-core changes only for demonstrated product, safety, or @@ -103,7 +104,7 @@ not a frozen general schema. adding Scient as a distinct execution target. - Keep accepted scientific state independent of Synara, Scient, connected OpenCode, and other external-agent session or projection databases. -- Keep upstream maintenance separate from PapiLab product branches and commits. +- Keep upstream maintenance separate from Scient product branches and commits. - Defer Goose, cloud, sync, collaboration, mobile, and broad product redesign. ## Project-Initiation Foundation @@ -111,8 +112,8 @@ not a frozen general schema. The first permanent implementation is a portable project-initiation kernel in the owned Synara monorepo. The source-backed placement selected in `../../lab/notes/project-initiation-placement-trace-2026-07-16.md` is -`packages/papilab-project-init`, published only as a private workspace package -named `@papilab/project-init` at this stage. +`packages/scient-project-init`, published only as a private workspace package +named `@scientfactory/project-init` at this stage. The package must not depend on Electron, React, Synara application modules, OpenCode, SQLite, a model provider, or a scientific discipline. It owns only: @@ -129,7 +130,7 @@ The universal foundation for a newly initialized project is: ```text PROJECT.md AGENTS.md -.papilab/project.json +.scient/project.json ``` Opening an ordinary folder is a zero-write operation. Initialization is an @@ -182,7 +183,7 @@ study. ### Success Criterion This phase is complete when the clean owned source baseline is selected and -PapiLab knows where the dependency-light initialization package will live, which +Scient knows where the dependency-light initialization package will live, which process will integrate its filesystem operations, which inherited project-open surfaces will call it later, and which exact kernel tasks may begin. It does not complete the remaining scientific-state or executor boundary trace. @@ -197,7 +198,7 @@ For the owned Synara and OpenCode checkouts: 2. Record local `HEAD`, branch, remotes, dirty state, and the maintained commit recorded in `../../lab/external/sources.lock.md`. 3. Inspect current official upstream heads and run each repository's maintained - PapiLab source/upstream verifier. + Scient source/upstream verifier. 4. Review upstream changes only where they touch the fixture path: project or workspace lifecycle, provider invocation, approval, runtime events, persistence, review, recovery, or reopening. @@ -242,7 +243,7 @@ The first implementation must include: 3. pure, inspectable planning with create, preserve, propose, and conflict operations; 4. deterministic rendering for `PROJECT.md`, a new root `AGENTS.md`, and - `.papilab/project.json`; + `.scient/project.json`; 5. apply-time precondition checks so filesystem changes after preview abort safely; 6. path and symlink containment; @@ -260,7 +261,7 @@ this package pull request. ### Success Criterion -This trace is complete only when PapiLab knows exactly which Synara and OpenCode +This trace is complete only when Scient knows exactly which Synara and OpenCode surfaces will host the scientific project/agent boundary, how state ownership and non-Git recovery work beyond initialization, and which exact integration tasks may begin next. @@ -275,7 +276,7 @@ unrelated subsystems deeply. Trace how a local folder becomes a Synara project or workspace, whether Git or a worktree is assumed, what identity and metadata Synara stores, and what survives -restart. Determine where PapiLab project initialization can attach without +restart. Determine where Scient project initialization can attach without turning Synara's project or orchestration projection into canonical scientific state. @@ -284,7 +285,7 @@ state. Find the smallest existing surfaces that can create or open the project, add one source excerpt, show one evidence note, inspect task context, and review a proposal. Determine how manual UI and agent-facing integration can call the same -PapiLab-owned operations without redesigning the full workbench. +Scient-owned operations without redesigning the full workbench. #### C. Scient Execution And External OpenCode Separation @@ -292,8 +293,8 @@ Trace provider discovery, session creation, working-directory selection, prompt/context assembly, permissions, approvals, tool and file events, cancellation, errors, final result, and runtime projection. Determine which existing provider/runtime events are reusable execution evidence and where the -PapiLab gateway must add scientific context and proposal semantics. Identify -where PapiLab can enforce project filesystem scope independently of generated +Scient gateway must add scientific context and proposal semantics. Identify +where Scient can enforce project filesystem scope independently of generated paths, shell commands, or model requests. Start from the existing external OpenCode adapter and the owned OpenCode source @@ -305,10 +306,10 @@ independently selectable and configured. #### D. Persistence And State Ownership Map every relevant state to its current owner, physical location, restart -behavior, and PapiLab authority. The trace note must include and complete this +behavior, and Scient authority. The trace note must include and complete this table: -| State | Current owner | Location | Survives restart? | Canonical for PapiLab? | +| State | Current owner | Location | Survives restart? | Canonical for Scient? | |---|---|---|---|---| | Application identity and settings | Synara | To trace | To trace | No | | Workspace path | Synara | To trace | To trace | Host reference only | @@ -316,7 +317,7 @@ table: | Scient session and transcript | Missing; OpenCode-derived source selected | To decide | Must for runtime continuity | No | | External OpenCode session and transcript | OpenCode/Synara | To trace | To trace | No | | Runtime events and tool logs | Scient or external agent/Synara | To trace | To trace | Evidence only | -| PapiLab project identity | Missing | To decide | Must | Yes | +| Scient project identity | Missing | To decide | Must | Yes | | Source excerpt and evidence note | Missing | To decide | Must | Yes | | Task and context receipt | Missing | To decide | Must | Yes | | Run receipt, proposal, and decision | Missing | To decide | Must | Yes | @@ -330,7 +331,7 @@ can be reconstructed without an executor session or chat transcript. At the currently recorded maintained Synara revision, the inspected `CheckpointStore` interface is Git-backed. The trace must verify that boundary -and decide whether a small PapiLab-owned snapshot, transaction, or equivalent +and decide whether a small Scient-owned snapshot, transaction, or equivalent mechanism can protect accepted state in a non-Git project. If safe non-Git recovery requires adopting worktrees or a broad core rewrite, treat that as a foundation-fit warning rather than a minor later task. @@ -338,7 +339,7 @@ foundation-fit warning rather than a minor later task. ### Known Source Starting Points Reverify these paths, relative to the owned Synara checkout, at the selected -source revision. They are starting points for the trace, not accepted PapiLab +source revision. They are starting points for the trace, not accepted Scient interfaces: - Synara project creation: `apps/web/src/lib/projectCreation.ts` @@ -352,10 +353,10 @@ interfaces: Compare only the first permanent placement needed by the fixture: -1. a clearly namespaced PapiLab package inside the owned Synara monorepo; -2. isolated PapiLab modules in the relevant Synara contracts, server, and UI +1. a clearly namespaced Scient package inside the owned Synara monorepo; +2. isolated Scient modules in the relevant Synara contracts, server, and UI areas; or -3. a hybrid with a permanent PapiLab domain/persistence package plus small Synara +3. a hybrid with a permanent Scient domain/persistence package plus small Synara integration shims and the existing provider adapter as the executor port. The hybrid is the leading hypothesis, not an accepted package design. Score each @@ -369,7 +370,7 @@ option by: - clarity for future maintainers; and - reversibility if Synara later becomes unsuitable. -If all three Synara-hosted options fail to preserve a clear PapiLab-owned state +If all three Synara-hosted options fail to preserve a clear Scient-owned state and capability boundary, record that result instead of selecting the least-bad option. The trace may then recommend external composition and identify which parts of ADR-0001, if any, must be revisited before implementation. @@ -395,7 +396,7 @@ It must record: 7. the proposed filesystem-scope enforcement boundary; 8. candidate seam comparison and selected permanent placement; 9. existing machinery to reuse unchanged; -10. surfaces PapiLab must not couple to; +10. surfaces Scient must not couple to; 11. any required Synara change, the Scient integration seam, and any proven inherited OpenCode-core gap; 12. the exact first coding backlog; and @@ -423,18 +424,18 @@ Implement in this order: 1. **Manual project lifecycle integration.** Connect the reviewed initiation kernel to the trusted local server and minimal Synara UI so a researcher can open an ordinary folder without writes or preview, initialize, close, and - reopen a non-Git PapiLab project with durable identity. Keep planning and + reopen a non-Git Scient project with durable identity. Keep planning and safety rules inside the kernel rather than duplicating them in UI or RPC handlers. 2. **Manual scientific operations.** Add and edit the source excerpt and - evidence note through PapiLab-owned operations. Persist a structured, + evidence note through Scient-owned operations. Persist a structured, inspectable relationship from the note to the exact supporting excerpt. 3. **Minimal persistence and recovery.** Persist only the fixture's project, source, note, task, context, proposal, decision, and recovery responsibilities. Make proposal application atomic or equivalently recoverable, including a deterministic crash or failure during apply. Do not freeze a complete schema. -4. **Deterministic executor.** Implement a fake at the PapiLab-owned gateway's +4. **Deterministic executor.** Implement a fake at the Scient-owned gateway's executor port. Use it to prove context, proposal, accept/edit/reject, failure, cancellation, crash-mid-apply recovery, and reopening without relying on model wording or provider state. @@ -444,10 +445,10 @@ Implement in this order: commands, and model requests must not widen that scope. 6. **Integration review checkpoint.** Stop for Yaacov's review after the deterministic boundary, recovery, and confinement tests pass. Confirm that - the gateway is genuinely PapiLab-owned before wiring in a live provider or + the gateway is genuinely Scient-owned before wiring in a live provider or changing inherited core. 7. **Scient integration.** Build and identify the owned OpenCode-derived agent - as Scient and put Scient behind the same PapiLab gateway and project + as Scient and put Scient behind the same Scient gateway and project operations. Scient is one agent/runtime, not a shell over a separately identified OpenCode engine. Keep inherited OpenCode core and Scient-owned additions internally identifiable where practical; change inherited core @@ -463,16 +464,16 @@ Implement in this order: active executor session, or reconstructing chat history. 10. **Live end-to-end smoke.** Run the controlled fixture through Scient, review the proposal, close the app, reopen it, and verify - PapiLab-owned state. If the normalized runtime event sequence adds adapter + Scient-owned state. If the normalized runtime event sequence adds adapter coverage beyond the gateway fake, sanitize it into a stable replay fixture; do not commit raw provider transcripts, secrets, or machine-specific paths. ## Repository And Change Lanes -- The PapiLab repository owns decisions, roadmap, implementation planning, +- The Scient repository owns decisions, roadmap, implementation planning, source-trace evidence, and cross-repository source pins. - The owned Synara repository hosts the real application implementation, - including permanent PapiLab-owned packages or modules, UI integration, + including permanent Scient-owned packages or modules, UI integration, canonical project persistence, gateway, review, and recovery workflow, unless the accepted trace decision invokes the external-topology escape route. - The owned OpenCode fork is Scient's source foundation. It remains unchanged @@ -484,15 +485,15 @@ Implement in this order: - External OpenCode and the other inherited external agents remain available; their broader project-task certification does not block this Scient-first slice. -- Goose remains deferred until the PapiLab gateway works through Scient. +- Goose remains deferred until the Scient gateway works through Scient. ## Acceptance Criteria - The fixture project does not require Git, a cloud service, or network science dependencies. -- Manual and agent-assisted work use the same PapiLab-owned project operations. +- Manual and agent-assisted work use the same Scient-owned project operations. - The researcher can inspect the exact project material supplied to the agent. -- The reopened evidence note retains a structured PapiLab-owned link to the exact +- The reopened evidence note retains a structured Scient-owned link to the exact supporting source excerpt, and the researcher can inspect that support without reconstructing agent prose or chat history. - Agent output remains proposed until the researcher accepts it. @@ -509,7 +510,7 @@ Implement in this order: external-agent session and projection databases. - The project reopens with its accepted note, source relationship, task, context, proposal decision, and recovery information understandable from - PapiLab-owned state. + Scient-owned state. - Deterministic tests prove system behavior; one live Scient smoke proves the real agent path without making live model wording the only evidence. - The completed slice produces an explicit decision about deeper Synara and @@ -578,12 +579,12 @@ Stop and report before widening scope if: ### Vertical Slice Done -A researcher can open a non-Git PapiLab project, add one source excerpt, edit the +A researcher can open a non-Git Scient project, add one source excerpt, edit the same project manually, delegate one bounded task, inspect the exact context, receive a proposal, inspect its structured link to the exact supporting excerpt, edit/accept/reject it, remain confined to the authorized project scope, recover safely from failure or crash-mid-apply, close and reopen the project, and -understand its scientific state from PapiLab-owned records alone. +understand its scientific state from Scient-owned records alone. After implementation evidence and Yaacov's review, promote only the architecture that the slice actually proves: diff --git a/docs/planning/idea-inbox.md b/docs/planning/idea-inbox.md index 313e469..eefe53b 100644 --- a/docs/planning/idea-inbox.md +++ b/docs/planning/idea-inbox.md @@ -2,8 +2,8 @@ Status: Active Owner: Yaacov -Last updated: 2026-07-12 -Purpose: Provides one temporary intake surface for unprocessed PapiLab ideas before they are evaluated and routed to their durable homes. +Last updated: 2026-07-17 +Purpose: Provides one temporary intake surface for unprocessed Scient ideas before they are evaluated and routed to their durable homes. Doc type: Planning note ## Document Rules @@ -47,12 +47,12 @@ is being triaged. ### 2026-07-12 — Default project workspace and built-in starting material -- Idea: Plan how a new PapiLab user's basic desktop project workspace should be +- Idea: Plan how a new Scient user's basic desktop project workspace should be set up when the app creates and works with local files and folders. - Things to remember: possible built-in starter documentation or guidance, a small set of built-in skills, a standard place for articles and PDFs, and sensible places for other common research-project material. -- Open questions: what PapiLab should create automatically; which areas should +- Open questions: what Scient should create automatically; which areas should be visible folders or files versus app-managed state; which starting material belongs to the app versus each project; and how this should work when opening an existing folder. diff --git a/docs/planning/model-access-and-routing-evolution.md b/docs/planning/model-access-and-routing-evolution.md index a2dc370..7a566e8 100644 --- a/docs/planning/model-access-and-routing-evolution.md +++ b/docs/planning/model-access-and-routing-evolution.md @@ -3,14 +3,14 @@ Status: Draft Owner: Yaacov Last updated: 2026-07-17 -Purpose: Tracks the rollout priorities and unresolved commercial choices for how PapiLab users access and select models. +Purpose: Tracks the rollout priorities and unresolved commercial choices for how Scient users access and select models. Doc type: Planning note ## Document Rules This document owns sequencing and open product choices. The accepted access requirement lives in `../product/PRD.md`; model comparisons live in `../research/source-evaluations/model-portfolio-and-provider-routing.md`; future runtime details belong in `../architecture/agent-runtime.md`. -Agent selection is a separate layer from model access. **Scient** is PapiLab's +Agent selection is a separate layer from model access. **Scient** is Scient's first-party agent; OpenCode, Codex, Claude, Droid, and other supported products are external agents. After an execution target is selected, the access source, provider, and model choices are limited to what that target legitimately @@ -23,12 +23,12 @@ Launch with all three access paths: 1. **Provider-connected access** - connect a supported official provider account or subscription where the provider permits third-party use. 2. **Bring your own API key** - the user supplies provider credentials and pays that provider directly. -3. **PapiLab-managed access** - PapiLab pays providers and gives users access through a PapiLab plan. +3. **Scient-managed access** - Scient pays providers and gives users access through a Scient plan. Start with manual model choice. Always show the selected agent, access source, provider, and model that will be used. -For PapiLab-managed access, the commercial options remain open: +For Scient-managed access, the commercial options remain open: - subscription with included usage; - credits or pay-as-you-go; @@ -43,28 +43,28 @@ Before refining the portfolio, map several relevant benchmarks across all candid This research belongs in `../research/source-evaluations/model-benchmark-map.md` and does not by itself approve a model. -### Phase 2: PapiLab-Owned Evaluation +### Phase 2: Scient-Owned Evaluation -Later, after PapiLab has concrete workflows and representative fixtures, build a replayable internal evaluation suite. It must test real PapiLab work and is required before final production role labels or automatic routing. The methodology will belong in `../quality/model-evaluation-methodology.md` when that later phase starts. +Later, after Scient has concrete workflows and representative fixtures, build a replayable internal evaluation suite. It must test real Scient work and is required before final production role labels or automatic routing. The methodology will belong in `../quality/model-evaluation-methodology.md` when that later phase starts. ## Priority 2: Recommendations And Automatic Routing Add task-aware recommendations, then an optional automatic router. The router should choose the lowest-cost eligible model expected to meet the task's quality, capability, privacy, tool, reliability, and latency requirements. -Do not enable automatic routing from external benchmark scores alone. It requires the later PapiLab-owned evaluation suite. +Do not enable automatic routing from external benchmark scores alone. It requires the later Scient-owned evaluation suite. -Routing may use provider-connected access, bring-your-own-key access, PapiLab-managed access, or an explicitly approved combination. The selected route, charging source, reason, and any fallback must be visible. +Routing may use provider-connected access, bring-your-own-key access, Scient-managed access, or an explicitly approved combination. The selected route, charging source, reason, and any fallback must be visible. ## Priority 3: Reassess Provider-Subscription Access -After real use, reconsider whether connecting consumer provider subscriptions remains reliable and worth supporting. PapiLab may later remove that path if provider terms, technical fragility, support burden, or user experience make it inferior to bring-your-own-key and PapiLab-managed access. +After real use, reconsider whether connecting consumer provider subscriptions remains reliable and worth supporting. Scient may later remove that path if provider terms, technical fragility, support burden, or user experience make it inferior to bring-your-own-key and Scient-managed access. Do not remove it silently or assume today that every provider subscription supports third-party use. ## Open Decisions -- Which official provider subscriptions can PapiLab support legitimately and reliably? -- Which PapiLab-managed billing option best matches real usage and cost risk? -- Should automatic routing use user-connected and PapiLab-managed access together? +- Which official provider subscriptions can Scient support legitimately and reliably? +- Which Scient-managed billing option best matches real usage and cost risk? +- Should automatic routing use user-connected and Scient-managed access together? - What controls, receipts, and budget limits are required before automatic routing? - When would provider-subscription access be deprecated? diff --git a/docs/planning/open-source-adaptation-build-strategy.md b/docs/planning/open-source-adaptation-build-strategy.md index 85b078d..999663c 100644 --- a/docs/planning/open-source-adaptation-build-strategy.md +++ b/docs/planning/open-source-adaptation-build-strategy.md @@ -3,7 +3,7 @@ Status: Draft Owner: Yaacov Last updated: 2026-07-17 -Purpose: Defines the current fork, adaptation, upstream-update, and divergence strategy for open-source foundations used by PapiLab. +Purpose: Defines the current fork, adaptation, upstream-update, and divergence strategy for open-source foundations used by Scient. Doc type: Planning note ## Document Rules @@ -25,12 +25,12 @@ validated. ## Current State The parent repository remains documentation-first. The maintained desktop fork -contains the dependency-light `@papilab/project-init` package, but there is no +contains the dependency-light `@scientfactory/project-init` package, but there is no implemented scientific application, canonical project-state kernel, agent -gateway, sync layer, editor, analysis runtime, or PapiLab production pipeline. +gateway, sync layer, editor, analysis runtime, or Scient production pipeline. The current practical direction is to build on owned, working foundations while -keeping PapiLab's scientific project meaning owned: +keeping Scient's scientific project meaning owned: - use the owned Synara fork as the initial application foundation for desktop, workspace, UI, provider-session, and local-process work; @@ -38,25 +38,25 @@ keeping PapiLab's scientific project meaning owned: shell: Zotero-family components for source/PDF work, Zettlr/Overleaf/Quarto for writing/export expectations, Jupyter-style tools for analysis compatibility, and ELN/RDM tools for protocol/lab/repository references; -- use the owned OpenCode fork as the source foundation for **Scient**, PapiLab's - first-party research agent; +- use `ScientFactory/scient-agent`, the owned OpenCode-derived fork, as the + source foundation for the product's first-party **Scient agent**; - preserve external OpenCode and the other inherited external-agent paths as separate choices rather than aliases for Scient; - evaluate Goose later as a source of capabilities and architecture lessons for Scient, or through a separately reviewed external-agent path; -- keep Scient and external agents behind a PapiLab-owned gateway for context, permissions, +- keep Scient and external agents behind a Scient-owned gateway for context, permissions, proposed changes, provenance, review, checkpoints, and write-back. ## First-Slice Constraints The active product sequence lives in `product-roadmap.md`, and its concrete implementation is planned in -`first-papilab-vertical-slice-implementation-plan.md`. This strategy constrains +`first-scient-vertical-slice-implementation-plan.md`. This strategy constrains that work without duplicating it: 1. Use one vertical scientific workflow to pressure-test both foundations. 2. Keep scientific operations available to manual UI and agents through a - PapiLab-owned layer where practical. + Scient-owned layer where practical. 3. Preserve project meaning independently of Synara, Scient, and external-agent session state. 4. Prefer extension seams first, but make isolated core changes when a proven @@ -76,74 +76,75 @@ labels must match the research map in 1. Prefer upstream-trackable integration through configuration, plugins, CLI, SDK, API, sidecar, wrapper, or adapter. -2. Put PapiLab-specific behavior in an add-on layer when possible, so the +2. Put Scient-specific behavior in an add-on layer when possible, so the upstream tool core remains intact. 3. Use embedded engines for bounded execution tasks, but keep accepted project - state in PapiLab-owned objects. + state in Scient-owned objects. 4. Use adapters for import, export, sync, search, or reconciliation, and keep the external format from becoming canonical. 5. Treat editor, chart, notebook, CRDT, or export-runtime state as a projection unless an architecture decision says otherwise. 6. Use a thin fork while missing integration seams can stay isolated and regular upstream merges remain valuable. -7. Move deliberately to selective divergence when PapiLab owns a changed product +7. Move deliberately to selective divergence when Scient owns a changed product surface and accepts that updates may become manual cherry-picks. 8. Treat divergent upstream updates as reference/cherry-pick source: inspect, select, and adapt useful changes manually. 9. Preserve raw upstream runtime logs when useful, but normalize accepted project - changes into PapiLab-owned records. + changes into Scient-owned records. 10. Track each source's update strategy before depending on it. ### Owned-Fork Remote Topology -PapiLab will own the writable fork of every source it may adapt directly, -including Synara, OpenCode, and Goose. This is an ownership and safety rule; it -does not mean every fork should immediately diverge from upstream. +Scient owns the writable desktop and agent-source forks it adapts directly. +Any later Goose adaptation must first receive the same owned-fork topology. +This is an ownership and safety rule; it does not mean every fork should +immediately diverge from upstream. Each active source checkout should use: ```text -origin -> PapiLab-owned fork; writable +origin -> Scient-owned fork; writable upstream -> official project; fetch-only, push disabled ``` -Before the first PapiLab source change: +Before the first Scient source change: 1. create the owned fork; 2. attach it as `origin`; 3. preserve the official repository as fetch-only `upstream`; 4. record the baseline upstream commit; 5. prove the unchanged fork builds or passes its smallest relevant smoke check; -6. make PapiLab changes in narrow, reviewable commits; and +6. make Scient changes in narrow, reviewable commits; and 7. test upstream updates on a temporary sync branch before merging them into the - PapiLab-maintained branch. + Scient-maintained branch. Keep change lanes separable where practical: - identity and packaging; -- PapiLab adapters and extension seams; -- PapiLab-owned domain UI; +- Scient adapters and extension seams; +- Scient-owned domain UI; - unavoidable upstream-core patches; and - release or updater configuration. -Synara is expected to carry visible PapiLab identity and domain UI. OpenCode is +Synara is expected to carry visible Scient identity and domain UI. OpenCode is Scient's inherited source foundation, not a separately branded engine beneath Scient. Scient therefore needs its own product, binary, configuration, session, release, and update identity while inherited OpenCode core remains traceable for upstream maintenance and attribution. The external OpenCode option retains -OpenCode identity and remains independently configured. If PapiLab later adopts -Goose-derived capabilities, they become part of Scient unless PapiLab separately +OpenCode identity and remains independently configured. If Scient later adopts +Goose-derived capabilities, they become part of Scient unless Scient separately decides to offer an external Goose agent. An upstream sync should be a deliberate operation: fetch `upstream`, create a -sync branch from the PapiLab-maintained branch, merge the selected upstream -revision, resolve conflicts without flattening PapiLab patches, run the agreed +sync branch from the Scient-maintained branch, merge the selected upstream +revision, resolve conflicts without flattening Scient patches, run the agreed smoke suite, review release/security changes, then merge through normal review. Do not update production integration directly from an unreviewed upstream head. Update strategy values: -- `no-upstream` - PapiLab owns this part. +- `no-upstream` - Scient owns this part. - `version-bump` - update directly with normal dependency testing. - `adapter-maintained` - update upstream, then repair or validate the adapter. - `thin-fork-merge` - keep the fork close enough that upstream merges remain @@ -161,9 +162,10 @@ remote topology above. The executable plan, evidence requirements, and pass/fail criteria live in [`gate-1-5-execution-plan.md`](gate-1-5-execution-plan.md). -**2026-07-11 result: passed.** PapiLab now owns public, upstream-connected -Synara and OpenCode forks; Synara has an isolated PapiLab development identity; -and the owned OpenCode build passed the constrained Synara smoke. The exact +**2026-07-11 result: passed.** The then-current PapiLab project owned public, +upstream-connected Synara and OpenCode forks; Synara had an isolated PapiLab +development identity; and the owned OpenCode build passed the constrained +Synara smoke. The exact history, checks, and documented execution-order correction are in the [`Gate 1.5 report`](../../lab/notes/gate-1-5-execution-report-2026-07-11.md). @@ -185,7 +187,7 @@ evidence, not product architecture. ## Deferred Goose Evaluation -All Goose execution work is deferred until after the first PapiLab gateway works +All Goose execution work is deferred until after the first Scient gateway works through Scient, including: - creating and attaching the owned Goose repository; @@ -200,7 +202,7 @@ through Scient, including: The completed source-depth inspection remains research input, not a current implementation commitment. -Stop relying on a forked workbench if it forces PapiLab to model research projects +Stop relying on a forked workbench if it forces Scient to model research projects as coding sessions, Git worktrees, provider chats, or engine-owned artifacts. ## Required Reviews Before Deeper Commitment @@ -216,20 +218,20 @@ as coding sessions, Git worktrees, provider chats, or engine-owned artifacts. - Security review of local file access, command execution, prompt injection, secrets, logs, and agent-readable context. - Data-boundary review proving that external engine state does not become - canonical PapiLab project state. + canonical Scient project state. - Upgrade-path review showing how upstream updates can be pulled without - rewriting PapiLab's project model. + rewriting Scient's project model. ## Open Questions - Which Synara seams should remain upstream-aligned and which should become - deliberately PapiLab-owned? + deliberately Scient-owned? - Can a stabilized Synara fork host the first science-facing slice without - leaking coding-product assumptions into the PapiLab project kernel? + leaking coding-product assumptions into the Scient project kernel? - Which OpenCode-derived modules can remain close to upstream inside Scient, and which Scient-owned capabilities require deliberate divergence? - Should Zotero Reader or Zotero Document Worker be embedded as components, or - should PapiLab build/choose simpler PDF and extraction components while using + should Scient build/choose simpler PDF and extraction components while using Zotero as a reference and compatibility target? - What is the exact minimal agent gateway event model? - Which agent actions can be pre-approved, and which require explicit review? diff --git a/docs/planning/papilab-to-scient-rename-execution-plan.md b/docs/planning/papilab-to-scient-rename-execution-plan.md index 01d61cd..25c4ff0 100644 --- a/docs/planning/papilab-to-scient-rename-execution-plan.md +++ b/docs/planning/papilab-to-scient-rename-execution-plan.md @@ -1,35 +1,59 @@ # PapiLab-To-Scient Rename Execution Plan -Status: Proposed +Status: Historical Owner: Yaacov Last updated: 2026-07-17 -Purpose: Defines the controlled future migration from the current PapiLab identity to Scient and ScientFactory. +Purpose: Preserves the executed PapiLab-to-Scient migration, compatibility contract, verification requirements, and deferred public cutover. Doc type: Planning note ## Goal -Rename the active PapiLab product and maintained product-owned implementation -to the accepted Scient identity without losing project data, confusing the -Scient app with the Scient agent, damaging Synara/OpenCode upstream lineage, -breaking external-agent connections, or rewriting historical evidence. - -This plan makes the repository ready for execution by defining the authoritative -name map, current-versus-target boundary, migration sequence, compatibility -policy, verification requirements, rollback expectations, and completion -criteria. It does not perform the rename and must not be cited as evidence that -any target identifier is already implemented. +Record how the active PapiLab product and maintained product-owned +implementation were renamed to Scient without losing project data, confusing +the Scient app with the Scient agent, damaging Synara/OpenCode upstream +lineage, breaking external-agent connections, or rewriting historical evidence. + +This document began as the execution plan and now preserves the verified +sequence, compatibility policy, rollback expectations, and closeout boundary. +The final source revisions and hosted verification are recorded in the +execution outcome and source lock; this document alone is not runtime evidence. + +## Execution Outcome + +The rename of existing owned surfaces is complete: + +- the GitHub organization and owned repositories use `ScientFactory/Scient`, + `ScientFactory/scient-desktop`, and `ScientFactory/scient-agent`; +- agent-source [PR #6](https://github.com/ScientFactory/scient-agent/pull/6) + passed hosted run `29595488492` at `5d232a34` and merged to `dev` as + `5ffaf9a2`; +- desktop [PR #12](https://github.com/ScientFactory/scient-desktop/pull/12) + passed hosted run `29595506303` at `179fa01e` and merged to `main` as + `d9d8992a`; +- the app, packages, project metadata, protocol, bundle IDs, profiles, storage, + artifacts, workflows, and current documentation use Scient naming; +- supported PapiLab app/project state has an additive migration path and remains + preserved for rollback; +- Synara and OpenCode remain named where they identify inherited upstream code, + licenses, attribution, compatibility, or external-agent behavior; and +- the public website cutover is explicitly deferred to the owner. + +The `scient-agent` repository name establishes the owned source boundary now. +It does not claim that the native Scient agent runtime is implemented. That +future product work remains governed by +`scient-and-external-agents-implementation-plan.md`. ## Authorities - `../product/scient-product-identity.md` owns the accepted company, app, agent, and external-agent names. - `../product/PRD.md` owns the broader product requirements. -- `../architecture/decisions/ADR-0001-synara-opencode-foundation-and-papilab-ownership-boundary.md` +- `../architecture/decisions/ADR-0001-synara-opencode-foundation-and-scient-ownership-boundary.md` owns the inherited application/agent foundations and canonical project-state boundary until it is deliberately renamed or superseded. - `litrev-to-papilab-rename-execution-plan.md` remains the historical execution and rollback record for the preceding rename. -- This document owns the proposed PapiLab-to-Scient migration sequence, +- This document preserves the executed PapiLab-to-Scient migration sequence, verification, rollback, and closeout criteria. ## Accepted Name Map @@ -44,7 +68,7 @@ any target identifier is already implemented. | GitHub owner | `yaacovcorcos` | `ScientFactory` | | Parent repository | `yaacovcorcos/PapiLab` | `ScientFactory/Scient` | | Desktop repository | `yaacovcorcos/papilab-desktop` | `ScientFactory/scient-desktop` | -| OpenCode-derived source repository | `yaacovcorcos/opencode` | `ScientFactory/opencode` until `scient-agent` is truthful | +| OpenCode-derived source repository | `yaacovcorcos/opencode` | `ScientFactory/scient-agent` | | Package scope | `@papilab/*` | `@scientfactory/*` | | Project metadata | `.papilab/` | `.scient/` | | Application protocol | `papilab://app` | `scient://app` | @@ -252,13 +276,13 @@ from implemented current state. - `yaacovcorcos/PapiLab` to `ScientFactory/Scient`; - `yaacovcorcos/papilab-desktop` to `ScientFactory/scient-desktop`; and - - `yaacovcorcos/opencode` to `ScientFactory/opencode`. + - `yaacovcorcos/opencode` to `ScientFactory/scient-agent`. 4. Keep official Synara and OpenCode fetch-only upstream remotes unchanged and keep both transferred forks in their official GitHub fork networks. -5. Keep the OpenCode-derived source repository named `opencode` until the - Scient agent is real enough that `scient-agent` is truthful. -6. When that threshold is met, rename through a separate reviewed topology - change while preserving official OpenCode upstream and attribution. +5. By explicit owner decision, name the owned source boundary `scient-agent` + now while stating clearly that the native agent runtime remains unbuilt. +6. Preserve official OpenCode upstream and attribution across that source + repository rename. 7. Never point writable origin at an official repository. 8. Update writable origins, source locks, workflow references, required checks, and release configuration immediately after each transfer. Verify CI before @@ -306,7 +330,7 @@ while inherited/historical names remain limited to allowlisted internal truth. Exit evidence: new projects use `.scient/`; supported `.papilab/` projects migrate safely; existing user files are not overwritten. -### Phase 5 — Establish The Scient Agent Identity +### Phase 5 — Establish The Scient Agent Identity (Deferred Product Work) 1. Build the owned OpenCode-derived runtime as the Scient agent, not as a Scient shell over a separately exposed OpenCode engine. @@ -321,8 +345,14 @@ migrate safely; existing user files are not overwritten. credentials, settings, sessions, or updates. 6. Keep external OpenCode independently selectable. -Exit evidence: the Scient app and Scient agent work together while the Scient -agent and external OpenCode coexist with isolated identity and state. +This phase was removed from the rename closeout because no pre-existing native +agent identity required migration. Repository naming and inherited-source +verification are complete; implementing and proving the native runtime remains +future product work. + +Exit evidence for that later work: the Scient app and Scient agent work +together while the Scient agent and external OpenCode coexist with isolated +identity and state. ### Phase 6 — Rename And Preserve The External-Agent Layer @@ -352,28 +382,30 @@ Exit evidence: repeatable maintenance and release verification fails on stale identity, lost adapters, unsafe migration, unreviewed divergence, or incorrect update configuration. -### Phase 8 — Run Coexistence And Recovery Proofs +### Phase 8 — Run App Coexistence And Recovery Proofs Verify on clean-install and upgrade paths: - Scient app alongside official Synara and retained PapiLab state; -- Scient agent alongside external OpenCode; -- different app and agent processes, profiles, homes, credentials, endpoints, - sessions, logs, caches, and updates; +- when the native Scient agent is later implemented, Scient agent alongside + external OpenCode; +- for existing app surfaces, isolated processes, profiles, storage, endpoints, + logs, caches, and updates; - `.papilab/` migration to `.scient/`, including interruption and rollback; - open, initialize, reopen, and recover without Git; - external-agent settings and threads round-trip unchanged; -- failure, sign-out, update, corruption, or removal of one agent does not - disable the other; and +- for future agent implementation, failure, sign-out, update, corruption, or + removal of one agent does not disable the other; and - canonical project state remains reconstructable without any agent session database. Exit evidence: automated tests plus an installed-app smoke at exact candidate heads. -### Phase 9 — Cut Over Public Surfaces +### Phase 9 — Cut Over Public Surfaces (Owner-Deferred) -Only after local and release evidence is clean: +The owner explicitly deferred the live website/deployment cutover. When it is +authorized, perform it only after local and release evidence is clean: 1. Update `scientfactory.com` content and product routes. 2. Update authentication callbacks, emails, downloads, documentation URLs, @@ -389,7 +421,8 @@ application agree on ScientFactory and Scient. 1. Update current implementation and source-lock documents with exact merged revisions and verification evidence. -2. Mark this plan Historical after verified completion. +2. Keep this plan Historical after verified closeout of the existing owned + surfaces. 3. Preserve the LitRev-to-PapiLab plan and both rename reports as history. 4. Remove only temporary branches, worktrees, archives, and evidence that are confirmed unnecessary; preserve user artifacts and required migration @@ -444,12 +477,15 @@ Pause and review if execution would require: The rename is complete only when: -- accepted product truth and current implementation both identify the company - as ScientFactory and the app/native agent as Scient; +- accepted product truth and existing implementation identify the company as + ScientFactory and the app as Scient, while reserving Scient for the planned + native agent; - technical documentation distinguishes Scient app from Scient agent; - external agents remain independently selectable and configured; - new projects use `.scient/` and supported `.papilab/` projects migrate safely; -- application and agent identity/state are isolated despite the shared brand; +- application identity/state is isolated from PapiLab and inherited products; + future Scient-agent identity/state isolation remains an implementation + requirement rather than a completed rename claim; - owned repositories, protections, workflows, packages, artifacts, and source locks use the verified final topology; - installed and upgrade-path verification passes at exact merged heads; diff --git a/docs/planning/product-planning.md b/docs/planning/product-planning.md index 2f7940c..6b1a472 100644 --- a/docs/planning/product-planning.md +++ b/docs/planning/product-planning.md @@ -2,7 +2,7 @@ Status: Draft Owner: Yaacov -Last updated: 2026-07-16 +Last updated: 2026-07-17 Purpose: Tracks current product planning after the accepted PRD, including candidate features, open product questions, and cross-document handoffs. Doc type: Planning note @@ -24,7 +24,7 @@ question. ## Current Planning Role -The PRD is now accepted as the product truth for PapiLab's identity, principles, workspace responsibilities, major capability areas, non-goals, readiness criteria, and open product questions. +The PRD is now accepted as the product truth for Scient's identity, principles, workspace responsibilities, major capability areas, non-goals, readiness criteria, and open product questions. This file now has four jobs: @@ -49,7 +49,7 @@ Keep product centrality separate from validation timing. Product centrality values: -- `Core` - central to PapiLab's product identity. +- `Core` - central to Scient's product identity. - `Important` - important to a strong product but not defining for the first coherent product shape. - `Later` - likely valuable after foundational workflows are proven. - `Idea` - captured for later thinking. @@ -98,7 +98,7 @@ This is the active feature inventory. It should stay compact. Add detail only wh | Manuscript, citations, and publishing | Section/full-draft writing, evidence rail, citation diagnostics, evidence-linked vs auxiliary citations, metadata, journal adaptation, import/export/reconciliation, publication artifacts. | Core | Early validation to early expansion | Read/review and light edit later | Design handoff: serious editor UX. Architecture handoff: citation/export model. | | Data, code, analysis, figures, and artifacts | Script or notebook-compatible work, approved execution, run records, datasets, outputs, stale-output detection, tables, figures, visual planning, artifact manager. | Core | Early validation to early expansion | Desktop first; review later | Architecture handoffs: execution, artifacts, reproducibility, project format. | | Agent delegation and safe automation | Object-scoped tasks, context receipts, project-aware tools, proposed artifacts, task queue, durable runs, approvals, retries, cancellation, recovery. | Core | Foundation to early validation | Approval later | Architecture handoffs: `docs/architecture/agent-runtime.md` and `docs/architecture/security-and-permissions.md`. | -| Model access and routing | Provider-connected subscriptions, bring-your-own API keys, PapiLab-managed access, manual model choice, and later task-aware routing. | Core | Foundation to early expansion | None first | Sequencing and commercial options: `model-access-and-routing-evolution.md`. Candidate portfolio: `../research/source-evaluations/model-portfolio-and-provider-routing.md`. | +| Model access and routing | Provider-connected subscriptions, bring-your-own API keys, Scient-managed access, manual model choice, and later task-aware routing. | Core | Foundation to early expansion | None first | Sequencing and commercial options: `model-access-and-routing-evolution.md`. Candidate portfolio: `../research/source-evaluations/model-portfolio-and-provider-routing.md`. | | Scientific skills | Built-in bounded skills for evidence extraction, drafting, citation checking, data analysis, figure creation, method guidance, journal adaptation, project mentoring. | Important | Early expansion | Approval later | Start with a tiny skill set; defer marketplace/registry mechanics. | | Project memory | Inspectable memory, source/authority/confidence/freshness metadata, pin/archive/forget, conflict/staleness handling, project continuity summaries. | Core | Foundation to early expansion | Capture and review later | Architecture handoff: memory may need its own doc after agent runtime pressure clarifies boundaries. | | Identity, sharing, collaboration, and mobile | Account/device identity, roles, permissions, invitations, shared review, comments, assignments, attribution, cloud mirror, sync/conflict states, mobile continuation. | Core | Design early, implement in phases | Read/review/capture/approval | Architecture handoffs: collaboration model, local-first sync, security. | @@ -114,9 +114,9 @@ The PRD intentionally leaves these open. Resolve them in the right document when |---|---|---| | Which source connector or import path is first? | Source intake must be real enough to prove evidence and citation workflows. | Product planning plus architecture. | | Which citation import/export/rendering paths are required first? | Citation quality is core infrastructure, but targets should not sprawl. | Product planning plus manuscript/citation architecture. | -| What parser strategy supports source-region provenance without owning parser output as the product model? | Evidence traceability depends on parsing, but parser data should not define PapiLab's canonical model. | Architecture and research. | +| What parser strategy supports source-region provenance without owning parser output as the product model? | Evidence traceability depends on parsing, but parser data should not define Scient's canonical model. | Architecture and research. | | What is the first data/code execution path? | Analysis continuity is core, but execution boundaries affect safety and product complexity. | Architecture and security. | -| How should PapiLab-managed model access be priced? | Subscription, included usage, credits, pay-as-you-go, or a hybrid create different user and cost risks. | `model-access-and-routing-evolution.md`. | +| How should Scient-managed model access be priced? | Subscription, included usage, credits, pay-as-you-go, or a hybrid create different user and cost risks. | `model-access-and-routing-evolution.md`. | | Which high-impact actions require approval first? | Agentic work needs trust without blocking all useful automation. | Product planning plus security/agent architecture. | | What cloud mirroring and collaboration semantics come first? | Local-first ownership, backup, sharing, conflicts, revocation, and restore must be coherent. | Collaboration, sync, and security architecture. | | What mobile actions are allowed first? | Mobile should continue project work without becoming a second source of truth. | Product planning and design. | diff --git a/docs/planning/product-roadmap.md b/docs/planning/product-roadmap.md index fa39d20..170c522 100644 --- a/docs/planning/product-roadmap.md +++ b/docs/planning/product-roadmap.md @@ -3,7 +3,7 @@ Status: Active Owner: Yaacov Last updated: 2026-07-17 -Purpose: Defines the current sequence of coherent PapiLab product outcomes without turning technology experiments into the product roadmap. +Purpose: Defines the current sequence of coherent Scient product outcomes without turning technology experiments into the product roadmap. Doc type: Planning note ## Document Rules @@ -16,12 +16,12 @@ own documents. Update this roadmap when the active product slice changes, when evidence changes its order, or when a slice is accepted, deferred, or rejected. -## Now: First PapiLab Scientific Project Slice +## Now: First Scient Scientific Project Slice A researcher can open a small local scientific project, add source material manually, delegate one bounded task to **Scient**, inspect the context and proposed result, accept or reject it, and reopen the project without losing its -scientific meaning or history. Scient is PapiLab's owned OpenCode-derived +scientific meaning or history. The Scient agent is the owned OpenCode-derived first-party agent; it is not a separate shell over an OpenCode engine. The slice combines: @@ -33,19 +33,19 @@ The slice combines: - one proposed evidence-linked note; - inspect, edit, accept, and reject behavior; - a recovery point; and -- close-and-reopen continuity from PapiLab-owned state. +- close-and-reopen continuity from Scient-owned state. The slice is desktop-first. It does not include mobile, cloud sync, collaboration, full PDF parsing, full citation management, a complete manuscript editor, a complete scientific schema, a notebook system, or Goose integration. The implementation plan is -[`first-papilab-vertical-slice-implementation-plan.md`](first-papilab-vertical-slice-implementation-plan.md). +[`first-scient-vertical-slice-implementation-plan.md`](first-scient-vertical-slice-implementation-plan.md). ## Next - Strengthen the evidence-to-writing path based on the first slice. -- Add scientific capabilities through the PapiLab-owned layer as real needs +- Add scientific capabilities through the Scient-owned layer as real needs appear. - Make isolated changes to Scient's inherited OpenCode core only for demonstrated runtime gaps. diff --git a/docs/planning/repository-scope-and-company-memory.md b/docs/planning/repository-scope-and-company-memory.md index 38c006a..22fb209 100644 --- a/docs/planning/repository-scope-and-company-memory.md +++ b/docs/planning/repository-scope-and-company-memory.md @@ -2,8 +2,8 @@ Status: Proposed Owner: Yaacov -Last updated: 2026-07-12 -Purpose: Recommends how the PapiLab repository should relate to a broader connected company memory without mixing product authority with company-level authority. +Last updated: 2026-07-17 +Purpose: Recommends how the Scient repository should relate to a broader connected company memory without mixing product authority with company-level authority. Doc type: Planning note ## Document Rules @@ -14,23 +14,23 @@ The current repository boundary remains defined by `../../README.md`, `../README ## Current Boundary -This repository is the PapiLab product and project knowledge workspace. It owns PapiLab product direction, architecture, planning, research, design, quality, future implementation guidance, operations guidance when real, lab evidence, and project-specific agent workflows. +This repository is the Scient product and project knowledge workspace. It owns Scient product direction, architecture, planning, research, design, quality, future implementation guidance, operations guidance when real, lab evidence, and project-specific agent workflows. -Commercial, market, customer, or organizational material may live here when it directly informs PapiLab product work and is placed in the correct planning or research surface. This does not make the repository the unrestricted memory of the whole company. +Commercial, market, customer, or organizational material may live here when it directly informs Scient product work and is placed in the correct planning or research surface. This does not make the repository the unrestricted memory of the whole company. ## Options | Model | Benefit | Main risk | | --- | --- | --- | -| PapiLab product repository only | Clearest current boundary | Company context remains disconnected unless another system links it | +| Scient product repository only | Clearest current boundary | Company context remains disconnected unless another system links it | | One company-and-product repository | Simple navigation for a small team | Product and company authority boundaries become harder to preserve | | Connected company and product repositories | One logical memory with separate authority boundaries | Requires deliberate cross-repository routing and discoverability | ## Recommendation -Use a connected company-memory model. Keep this repository as the PapiLab product branch of that memory, and create a separate company-level authority when company strategy, finance, legal, people, customer knowledge, or cross-product decisions need durable homes. +Use a connected company-memory model. Keep this repository as the Scient product branch of that memory, and create a separate company-level authority when company strategy, finance, legal, people, customer knowledge, or cross-product decisions need durable homes. -The logical hierarchy may be connected even when the underlying knowledge lives in more than one repository or system. Link to authoritative company material instead of duplicating it inside PapiLab. +The logical hierarchy may be connected even when the underlying knowledge lives in more than one repository or system. Link to authoritative company material instead of duplicating it inside Scient. ## Principles For A Future Company Memory @@ -43,12 +43,12 @@ The logical hierarchy may be connected even when the underlying knowledge lives ## Decision Needed Before Structural Change -Before adding company-level folders or moving PapiLab under a broader hierarchy, decide: +Before adding company-level folders or moving Scient under a broader hierarchy, decide: - the company-memory owner; - whether it is one repository or several connected systems; - the company-level document and decision types; - how authority and links flow between company and product knowledge; and -- how existing PapiLab history would be preserved. +- how existing Scient history would be preserved. Until then, do not create company, finance, legal, people, or customer-record folders in this repository merely to anticipate future scale. diff --git a/docs/planning/scient-and-external-agents-implementation-plan.md b/docs/planning/scient-and-external-agents-implementation-plan.md index 5e0ed2d..248c96f 100644 --- a/docs/planning/scient-and-external-agents-implementation-plan.md +++ b/docs/planning/scient-and-external-agents-implementation-plan.md @@ -9,12 +9,12 @@ Doc type: Planning note ## Goal Build the **Scient agent** as the native first-party research agent of the -current PapiLab and future Scient app while preserving every external-agent -connection inherited from the Synara application foundation. +Scient app while preserving every external-agent connection inherited from the +Synara application foundation. Scient is the owned OpenCode-derived agent itself. It is one product, codebase, runtime identity, process lifecycle, configuration, session system, release, -and update channel. Scient must not be implemented or described as a PapiLab +and update channel. Scient must not be implemented or described as a Scient agent shell that launches a separately identified OpenCode engine. Inside Scient's source, inherited OpenCode core and Scient-owned capabilities, @@ -26,7 +26,7 @@ agent, engine choice, configuration, process, or product. External OpenCode remains an independent external agent. It must never be removed, renamed into Scient, silently redirected to Scient, or used as Scient's credential and state store. A user must be able to use Scient and -external OpenCode on the same machine and in the same PapiLab installation +external OpenCode on the same machine and in the same Scient installation without either one reading, overwriting, updating, or impersonating the other. Codex, Claude, Droid, Cursor, Antigravity, Grok, Kilo, Pi, and other supported @@ -41,8 +41,8 @@ and recovery record. Agents execute bounded work behind that boundary. ## Naming Status -ScientFactory is the chosen future company identity. Scient is the chosen -public name for both the future app and its native first-party agent. In this +ScientFactory is the company identity. Scient is the public name for both the +implemented app and its planned native first-party agent. In this technical plan, **Scient** refers to the agent unless **Scient app** is stated. `../product/scient-product-identity.md` owns the accepted vocabulary, and `papilab-to-scient-rename-execution-plan.md` owns the identity migration. @@ -56,9 +56,9 @@ Until clearance is complete: `first-party-agent` so a legal rename does not require project-record, settings, or migration rewrites; - do not reuse `opencode` as Scient's durable identity; and -- do not rename the current `agent-forks/opencode/` source checkout merely to - simulate product completion. Its path records source provenance until a - separately reviewed repository-topology migration is useful. +- do not infer product completion from the owned `scient-agent` repository + name. The repository establishes the source boundary; running evidence must + establish the native product identity and behavior. ## Review Brief @@ -72,7 +72,7 @@ Review this plan against these questions: processes, storage, sessions, settings, updates, and user experience? 4. Are all inherited external agents preserved without falsely claiming that every CLI, subscription, or version is already certified? -5. Does PapiLab own scientific meaning and durable project records above every +5. Does Scient own scientific meaning and durable project records above every agent session? 6. Can Goose-derived capabilities later improve Scient without turning Scient into an engine-switching shell? @@ -90,23 +90,22 @@ It does not replace: - the accepted naming system in `../product/scient-product-identity.md`; - the accepted product direction in `../product/PRD.md`; - the accepted ownership decision in - `../architecture/decisions/ADR-0001-synara-opencode-foundation-and-papilab-ownership-boundary.md`; + `../architecture/decisions/ADR-0001-synara-opencode-foundation-and-scient-ownership-boundary.md`; - the product sequence in `product-roadmap.md`; or - the active scientific-slice plan in - `first-papilab-vertical-slice-implementation-plan.md`. + `first-scient-vertical-slice-implementation-plan.md`. The early phases constrain the first vertical slice. Later phases expand and -certify external-agent paths after Scient completes the first bounded PapiLab +certify external-agent paths after Scient completes the first bounded Scient workflow. Promote stable runtime contracts into `../architecture/agent-runtime.md` only after running implementation evidence exists. ## Decision Summary -The current PapiLab and future Scient app support two product-level agent -categories: +The Scient app supports two product-level agent categories: -1. **Scient**: PapiLab's first-party research agent, owned and evolved from the +1. **Scient**: the product's first-party research agent, owned and evolved from the OpenCode fork. 2. **External agents**: external agent products that users connect through their own installation, account, subscription, API, endpoint, or local @@ -125,7 +124,7 @@ Source lineage does not merge product identities: ## Current Implementation Truth At maintained desktop-fork revision -`fd37cdcda16ff34c3b13d098e5a35d0d1aff5096`, inspected on 2026-07-17, the +`d9d8992a62e4dda37543c214f96fc97556c798f2`, inspected on 2026-07-17, the inherited host contains a shared provider adapter contract and adapters for: - Codex; @@ -156,19 +155,21 @@ every external CLI version, subscription entitlement, account login, remote endpoint, model, or provider-specific feature currently works. Preserve the paths first, then certify compatibility honestly per agent. -The owned OpenCode checkout at `agent-forks/opencode/` is the accepted source -foundation for Scient. It currently remains an upstream-aligned owned fork. -Scient product identity, packaging, Scient-owned state isolation, and owned scientific -capabilities have not been implemented. +The owned OpenCode-derived checkout at `agent-forks/scient-agent/`, maintained +on `dev` at `5ffaf9a2dfa5b958e8f4856b94b50d26b00c6b76`, is the accepted +source foundation for the Scient agent. Its repository and +maintenance-verifier identity are Scient-owned while its current runtime +remains upstream-aligned OpenCode source. Scient-agent packaging, private state +isolation, and owned scientific capabilities have not been implemented. The following are also not yet implemented: - a Scient execution target; -- a PapiLab-owned scientific task gateway; +- a Scient-owned scientific task gateway; - durable context, run, proposal, decision, and recovery records; or - a certified external-agent compatibility matrix. -The existing `@papilab/project-init` package remains valid and agent-independent. +The existing `@scientfactory/project-init` package remains valid and agent-independent. Its portable `AGENTS.md` guidance is project instruction material, not the Scient product. @@ -177,22 +178,22 @@ Scient product. | Term | Meaning | |---|---| | Agent | A user-visible worker such as Scient, Codex, Claude, Droid, or OpenCode. | -| Scient | PapiLab's first-party, owned OpenCode-derived research agent. | +| Scient | The product's first-party, owned OpenCode-derived research agent. | | External agent | An external agent product connected through a user-owned installation, account, subscription, API, or endpoint. | | Agent connection | One configured instance of an agent, including stable identity, health, capabilities, and non-secret configuration references. | | Execution target | The Scient profile or external-agent connection selected for a task. | | Inherited Scient core | OpenCode-derived source retained inside Scient and kept traceable for selective upstream updates. It is not a separate engine or product. | -| Scient-owned additions | Scientific capabilities, tools, policies, identity, integration, and product behavior owned directly by PapiLab inside Scient. | -| Access source | How model or service access is funded and authenticated: external subscription/account, bring-your-own key, or PapiLab-managed access. | +| Scient-owned additions | Scientific capabilities, tools, policies, identity, integration, and product behavior owned directly by Scient inside Scient. | +| Access source | How model or service access is funded and authenticated: external subscription/account, bring-your-own key, or Scient-managed access. | | Model | The selected inference model, distinct from agent and access source. | The inherited source uses “provider” for several concepts. Do not begin with a repository-wide rename. Treat `ProviderKind` as compatibility vocabulary for -existing external agents while introducing PapiLab-owned execution-target and +existing external agents while introducing Scient-owned execution-target and connection contracts above it. -Do not use “PapiLab Agent” as another product name. Use **Scient**. Use -“PapiLab agent gateway” only for the PapiLab-owned execution boundary, not for +Do not use “Scient Agent” as another product name. Use **Scient**. Use +“Scient agent gateway” only for the Scient-owned execution boundary, not for the product name. Use “portable project agent guidance” for `AGENTS.md` content. ## Non-Negotiable Scient And External OpenCode Separation @@ -200,18 +201,18 @@ the product name. Use “portable project agent guidance” for `AGENTS.md` cont | Surface | Scient | External OpenCode | |---|---|---| | Product identity | Scient | OpenCode | -| Durable internal identity | Brand-neutral PapiLab first-party-agent ID | Existing external `opencode` identity | -| User choice | “Scient” with a PapiLab first-party explanation | “OpenCode” under external agents | -| Source/runtime | One PapiLab-owned OpenCode-derived agent build | User-selected or externally installed OpenCode binary/server | +| Durable internal identity | Brand-neutral Scient first-party-agent ID | Existing external `opencode` identity | +| User choice | “Scient” with a Scient first-party explanation | “OpenCode” under external agents | +| Source/runtime | One Scient-owned OpenCode-derived agent build | User-selected or externally installed OpenCode binary/server | | Process lifecycle | Started and supervised as Scient | Existing OpenCode adapter lifecycle | -| Home/config directory | Dedicated Scient location | Existing external OpenCode location and PapiLab connection settings | +| Home/config directory | Dedicated Scient location | Existing external OpenCode location and Scient connection settings | | Endpoint/password | Scient-owned internal endpoint and secret handling if needed | Existing `openCodeServerUrl` and `openCodeServerPassword` path | | Credentials | Scient-specific access configuration | User's external OpenCode/provider credentials | | Sessions/transcripts | Scient execution state, non-canonical | External OpenCode execution state, non-canonical | | Skills/plugins/tools | Scient-owned catalog and policy over its inherited core | External OpenCode-discovered catalog and policy | | Logs/cache | Scient namespace | External OpenCode namespace | | Updates | One deliberate Scient release process | External OpenCode installation/update process | -| Canonical scientific record | PapiLab project records only | PapiLab project records only when invoked for a PapiLab task | +| Canonical scientific record | Scient project records only | Scient project records only when invoked for a Scient task | Additional rules: @@ -219,7 +220,7 @@ Additional rules: - Never make Scient depend on the external OpenCode binary path, endpoint, password, home, or update setting. - Never silently migrate an existing thread from external OpenCode to Scient. -- Never let either runtime's database or transcript become canonical PapiLab +- Never let either runtime's database or transcript become canonical Scient scientific state. - Never expose a second OpenCode-branded runtime as though it were a component users configure underneath Scient. @@ -229,10 +230,10 @@ Additional rules: ## Target Architecture ```text -PapiLab project operation / task UI +Scient project operation / task UI | v -PapiLab-owned scientific agent gateway +Scient-owned scientific agent gateway - task intent and selected project context - permissions and filesystem confinement - execution-target identity @@ -252,8 +253,8 @@ one owned OpenCode-derived agent inherited adapter registry ``` The inherited generic chat host may continue to call provider services directly -during migration. The PapiLab gateway becomes mandatory for operations that -read or propose changes to canonical PapiLab project state. +during migration. The Scient gateway becomes mandatory for operations that +read or propose changes to canonical Scient project state. ## Working Contracts To Introduce @@ -280,7 +281,7 @@ External target: ### Executor port -Defines the minimum operations required by the PapiLab gateway: inspect health +Defines the minimum operations required by the Scient gateway: inspect health and capabilities, start bounded work, stream normalized events, handle approval, interrupt, and finish with a typed outcome. Scient implements this port as one agent. The external-agent bridge adapts existing provider paths. @@ -301,7 +302,7 @@ invent the complete scientific object model in this work. ### Scient internal source boundary Keeps inherited OpenCode-derived modules and Scient-owned modules identifiable -where practical. PapiLab-specific scientific capabilities should live in +where practical. Scient-specific scientific capabilities should live in Scient-owned modules or stable seams first. Core changes are allowed when a demonstrated product, safety, or reliability requirement demands them. @@ -368,17 +369,16 @@ use one coherent meaning for Scient. handoff, and maintenance behavior. 5. Add characterization tests before changing schemas or routing. 6. Record which checks require installed CLIs/accounts and which can use fakes. -7. Replace ambiguous user-facing “PapiLab agent guidance” wording with +7. Replace ambiguous user-facing “Scient agent guidance” wording with “portable project agent guidance” where it refers to `AGENTS.md`. -8. Plan the shared scratch-root rename from - `papilab-opencode-workspaces` to `papilab-agent-workspaces`. Keep exact legacy - recognition during the required upgrade window so existing previews fail - safely rather than silently. +8. Preserve `scient-opencode-workspaces` as the external OpenCode scratch root. + Give the future Scient agent a separate `scient-agent-workspaces` root; do + not relabel external OpenCode state as native-agent state. Exit evidence: a source-backed flow map and green baseline tests that detect accidental removal or reinterpretation of external agents. -### Phase 2 — Introduce PapiLab-Owned Target And Executor Contracts +### Phase 2 — Introduce Scient-Owned Target And Executor Contracts 1. Add the execution-target union above inherited `ProviderKind`. 2. Add stable connection IDs so multiple future connections do not require @@ -442,7 +442,7 @@ identity and state on clean-install and upgraded machines. 5. Reject or pause work when effective permissions exceed approved scope. 6. Keep proposed project mutations reviewable before acceptance. -Exit evidence: the first workflow can be reconstructed from PapiLab records +Exit evidence: the first workflow can be reconstructed from Scient records after Scient's session state is unavailable. ### Phase 6 — Prove Scient And External OpenCode Together @@ -450,11 +450,11 @@ after Scient's session state is unavailable. This is the first dual-path proof because shared lineage exposes accidental coupling most effectively. -1. Configure Scient and external OpenCode in one PapiLab installation. +1. Configure Scient and external OpenCode in one Scient installation. 2. Run the same bounded, non-destructive task through each target. 3. Verify different labels, IDs, processes, versions, homes, credentials, endpoints, sessions, logs, and update controls. -4. Verify both produce the minimum PapiLab proposal/provenance envelope despite +4. Verify both produce the minimum Scient proposal/provenance envelope despite different native events. 5. Verify disabling, signing out of, corrupting, or removing one path does not prevent the other from starting. @@ -495,7 +495,7 @@ and dated live-smoke evidence where credentials are required. with separate state and certification. Exit evidence: a keep/adopt/reject decision for each evaluated capability, -without changing Scient's identity or canonical PapiLab records. +without changing Scient's identity or canonical Scient records. ### Phase 9 — Complete The User Experience @@ -506,7 +506,7 @@ without changing Scient's identity or canonical PapiLab records. 4. Separate agent selection from access-source and model selection. 5. Let users select an execution target per task and explicitly set defaults. 6. Explain which subscriptions/accounts belong to external tools and which - access is managed by PapiLab. + access is managed by Scient. 7. Show handoff context and permissions before transfer. 8. Preserve accessibility, keyboard navigation, reduced motion, and clear error recovery. @@ -519,7 +519,7 @@ OpenCode without reading architecture documentation. Keep these lanes reviewable: 1. inherited Synara desktop core; -2. PapiLab desktop/domain modules; +2. Scient desktop/domain modules; 3. narrow desktop integration seams; 4. unavoidable inherited Synara core patches; 5. Scient's inherited OpenCode core; @@ -572,14 +572,14 @@ Required test layers: ## Security, Privacy, And Trust - External authentication remains owned by the external product unless an - explicit PapiLab-managed path is implemented. -- PapiLab and Scient must not scrape, duplicate, or migrate external + explicit Scient-managed path is implemented. +- Scient and Scient must not scrape, duplicate, or migrate external subscription tokens. - Project records may retain non-secret agent identity, model, access-source label, version, capability snapshot, timing, and outcome metadata. - Redact tokens, passwords, authorization headers, and sensitive environment variables from logs, receipts, exports, and crash reports. -- PapiLab computes and enforces permissions for PapiLab project work; an agent +- Scient computes and enforces permissions for Scient project work; an agent request cannot widen them. - Filesystem access remains inside the selected project and explicitly approved external paths. @@ -602,7 +602,7 @@ reproduce behavior: - proposal, decision, cleanup, and recovery outcomes; and - native session reference only when safe and useful. -PapiLab records must show whether a task was accepted, rejected, interrupted, +Scient records must show whether a task was accepted, rejected, interrupted, failed, or recovered without requiring raw native logs. ## Rollout @@ -624,7 +624,7 @@ Pause if implementation appears to require: - representing OpenCode as a separately configured engine beneath Scient; - sharing credentials, homes, endpoints, sessions, or updates between Scient and external OpenCode; -- treating an agent transcript/database as canonical PapiLab state; +- treating an agent transcript/database as canonical Scient state; - a repository-wide `ProviderKind` rename before the boundary works; - modifying every external-agent adapter before the Scient path works; - certifying every agent before the first scientific slice; @@ -647,7 +647,7 @@ Prefer narrow changes in this order: 9. Per-agent compatibility certification. 10. Goose capability/architecture evaluation. -Do not mix upstream synchronization, broad inherited refactors, PapiLab domain +Do not mix upstream synchronization, broad inherited refactors, Scient domain behavior, Scient core changes, and UI redesign in one review lane. ## Acceptance Criteria @@ -665,7 +665,7 @@ This program is complete only when: - both coexist and complete the same bounded task; - failure, sign-out, update, or removal of one does not disable the other; - existing settings and threads migrate losslessly and idempotently; -- project operations pass through PapiLab-owned context, permission, proposal, +- project operations pass through Scient-owned context, permission, proposal, review, provenance, and recovery boundaries; - project truth is reconstructable without any agent's session database; - agent, access source, provider, and model are visible and not conflated; @@ -674,7 +674,7 @@ This program is complete only when: - Scient and inherited desktop upstream updates are separately controlled and regression-tested; and - useful future Goose capabilities can be added without changing Scient's - identity or canonical PapiLab records. + identity or canonical Scient records. ## Explicit Exclusions diff --git a/docs/product/PRD.md b/docs/product/PRD.md index 12de258..1640d49 100644 --- a/docs/product/PRD.md +++ b/docs/product/PRD.md @@ -1,19 +1,19 @@ -# PapiLab Product Requirements Document +# Scient Product Requirements Document Status: Accepted Version: v1 Owner: Yaacov Last updated: 2026-07-17 -Purpose: Defines PapiLab's product direction, core capabilities, user experience principles, and product constraints. +Purpose: Defines Scient's product direction, core capabilities, user experience principles, and product constraints. Doc type: Product truth ## Document Rules -The PRD defines what PapiLab should be and why it matters. It should not define how the product is implemented. +The PRD defines what Scient should be and why it matters. It should not define how the product is implemented. -The accepted future company, application, native-agent, and external-agent -names live in `scient-product-identity.md`. PapiLab remains the current -implemented identity until the linked rename plan is executed and verified. +The accepted company, application, native-agent, and external-agent names live +in `scient-product-identity.md`. Scient is the implemented application +identity; the native Scient agent remains planned. Implementation plans, package structure, task sequencing, and framework-specific code patterns do not belong in the PRD. Those belong in planning, architecture, development, or quality docs. @@ -23,24 +23,25 @@ Open-source adaptation strategy and implementation source choices live outside t Always update the current status of a PRD item when its real product or implementation state changes. -Update the PRD whenever PapiLab's product direction changes, including adding, removing, or materially changing a feature, capability, product constraint, or user experience principle. +Update the PRD whenever Scient's product direction changes, including adding, removing, or materially changing a feature, capability, product constraint, or user experience principle. ## Chosen Forward Product Identity -ScientFactory is the chosen future company identity. **Scient** is the chosen -public name for both the scientific workspace application and its native +ScientFactory is the company identity. **Scient** is the public name for both +the scientific workspace application and its native first-party research agent. OpenCode, Codex, Claude, Droid, and other independently connected products are **external agents**. Architecture and implementation text must qualify **Scient app** and **Scient agent** whenever the shared name could obscure their separate responsibilities, state, processes, credentials, or updates. The complete accepted vocabulary and -current-versus-target boundary live in `scient-product-identity.md`; execution -is governed by `../planning/papilab-to-scient-rename-execution-plan.md`. +implemented-versus-planned boundary live in `scient-product-identity.md`; the +completed migration and compatibility record lives in +`../planning/papilab-to-scient-rename-execution-plan.md`. ## Product Overview -PapiLab is a local-first scientific workspace where researchers, collaborators, and AI agents run an entire research project together, from early project formation through publication-ready outputs. Each project brings research materials, sources, data, analysis work, writing, citations, decisions, memory, collaboration, and outputs into one durable workspace. +Scient is a local-first scientific workspace where researchers, collaborators, and AI agents run an entire research project together, from early project formation through publication-ready outputs. Each project brings research materials, sources, data, analysis work, writing, citations, decisions, memory, collaboration, and outputs into one durable workspace. The **Scient agent** is the native first-party research agent and a real project worker inside the workspace. The product should also preserve supported @@ -51,23 +52,23 @@ conversation into durable project changes. Chat should be project-native and connected to the workspace, while the project record, evidence, files, data, draft, artifacts, and review surfaces remain the product center. -The goal of PapiLab is to make scientific work faster without making it opaque. Researchers should be able to work manually, delegate safely, collaborate, preserve project history, and keep ownership of the work. +The goal of Scient is to make scientific work faster without making it opaque. Researchers should be able to work manually, delegate safely, collaborate, preserve project history, and keep ownership of the work. ## Target Users -PapiLab is built for people doing scientific and scholarly research: PhD students, postdocs, clinician-researchers, academic researchers, research assistants, and small research teams who need one durable workspace for a project from early formation through publication-ready outputs. +Scient is built for people doing scientific and scholarly research: PhD students, postdocs, clinician-researchers, academic researchers, research assistants, and small research teams who need one durable workspace for a project from early formation through publication-ready outputs. -PapiLab should organize work around the research project, not around one fixed user type. Role-specific capabilities should be added when they strengthen the shared project workflow. +Scient should organize work around the research project, not around one fixed user type. Role-specific capabilities should be added when they strengthen the shared project workflow. ## Product Principles ### Project-Centered Research -PapiLab should organize scientific work around the research project as the durable center of work. Sources, notes, protocols, evidence, data, analysis, figures, manuscripts, memory, agent actions, and collaboration should belong to one connected project record instead of being scattered across tools, files, notebooks, and chat threads. +Scient should organize scientific work around the research project as the durable center of work. Sources, notes, protocols, evidence, data, analysis, figures, manuscripts, memory, agent actions, and collaboration should belong to one connected project record instead of being scattered across tools, files, notebooks, and chat threads. ### Agentic-First, Workspace-Native, Researcher-Owned -PapiLab is agentic-first and workspace-native. Researchers should be able to +Scient is agentic-first and workspace-native. Researchers should be able to work conversationally with Scient or a selected external agent, delegate from project objects, and continue the same work through high-quality manual surfaces. Agents do real project work inside the project context: sources, @@ -78,44 +79,44 @@ Agentic-first does not mean chat-only or agent-only. Important work must remain ### Traceable Scientific Work -PapiLab should preserve the relationships that make research trustworthy. Claims, sources, source regions, extracted evidence, citations, analysis outputs, figures, tables, manuscript text, and decisions should remain connected. +Scient should preserve the relationships that make research trustworthy. Claims, sources, source regions, extracted evidence, citations, analysis outputs, figures, tables, manuscript text, and decisions should remain connected. -When support is missing, weak, uncertain, conflicting, or agent-generated, PapiLab should make that visible instead of hiding uncertainty behind polished output. +When support is missing, weak, uncertain, conflicting, or agent-generated, Scient should make that visible instead of hiding uncertainty behind polished output. Unknown data should stay unknown. Missing metadata, uncertain source identity, parser failures, low-confidence extraction, ambiguous duplicate matches, stale analysis outputs, and incomplete citation data should remain visible instead of being silently converted into authoritative-looking values. ### Local-First, Collaborative, And Versioned -PapiLab projects should be locally owned, cloud-mirrored when useful, and designed for collaborative and versioned research work. Cloud mirroring should support backup, cross-device continuation, sharing, teamwork, and collaboration without becoming the only source of truth. +Scient projects should be locally owned, cloud-mirrored when useful, and designed for collaborative and versioned research work. Cloud mirroring should support backup, cross-device continuation, sharing, teamwork, and collaboration without becoming the only source of truth. -PapiLab should support multi-user project work, including comments, suggestions, assignments, approvals, and synchronized co-editing where real-time collaboration is useful. Real-time collaborative editing should strengthen the shared project record without replacing version history, attribution, review, or recovery. +Scient should support multi-user project work, including comments, suggestions, assignments, approvals, and synchronized co-editing where real-time collaboration is useful. Real-time collaborative editing should strengthen the shared project record without replacing version history, attribution, review, or recovery. -PapiLab should work naturally with Git or Git-like versioning for project history, review, comparison, recovery, and power-user workflows. Git integration should strengthen transparency and portability, but normal collaboration should not require researchers to manage Git directly. +Scient should work naturally with Git or Git-like versioning for project history, review, comparison, recovery, and power-user workflows. Git integration should strengthen transparency and portability, but normal collaboration should not require researchers to manage Git directly. ### Connected Research Outputs -PapiLab should connect research inputs to research outputs. Manuscripts, reports, figures, tables, exports, and publication artifacts should remain connected to the sources, evidence, data, analysis, decisions, and revisions that produced them. +Scient should connect research inputs to research outputs. Manuscripts, reports, figures, tables, exports, and publication artifacts should remain connected to the sources, evidence, data, analysis, decisions, and revisions that produced them. ### Open Research Ecosystem -PapiLab should connect deliberately with useful external research tools, formats, databases, and services while keeping the PapiLab-owned project model at the center. +Scient should connect deliberately with useful external research tools, formats, databases, and services while keeping the Scient-owned project model at the center. Researchers should be able to bring work in and send work out through reference managers, citation formats, scholarly databases, document formats, data files, code environments, publishing systems, repositories, cloud drives, and open-science platforms. External integrations should extend the project workspace without defining its core shape or fragmenting the project record. -External tools should act as adapters, engines, projections, import sources, export targets, or continuation paths. They should not become the source of truth for PapiLab's scientific project model. +External tools should act as adapters, engines, projections, import sources, export targets, or continuation paths. They should not become the source of truth for Scient's scientific project model. ## Research Project Lifecycle -PapiLab should support a scientific or scholarly research project from early formation through publication-ready outputs, preservation, and future continuation. +Scient should support a scientific or scholarly research project from early formation through publication-ready outputs, preservation, and future continuation. -The lifecycle is not strictly linear. Researchers often revisit the question, sources, evidence, methods, data, analysis, figures, and writing as the project develops. A project may start from a research question, a literature gap, a clinical or applied problem, an existing dataset, data gathered before the question is settled, a protocol, a draft, or a collection of sources. PapiLab should support multiple entry points while helping the researcher turn loose material into an organized project record. +The lifecycle is not strictly linear. Researchers often revisit the question, sources, evidence, methods, data, analysis, figures, and writing as the project develops. A project may start from a research question, a literature gap, a clinical or applied problem, an existing dataset, data gathered before the question is settled, a protocol, a draft, or a collection of sources. Scient should support multiple entry points while helping the researcher turn loose material into an organized project record. Not every project needs every stage. A literature-heavy review, a computational project, a thesis chapter, a clinical report, and a multi-paper PhD project may emphasize different parts of the lifecycle. The product requirement is that the work remains connected. ### Project Entry And Initialization -Researchers should be able to open an existing local folder without PapiLab -modifying it, or explicitly initialize a portable PapiLab project after +Researchers should be able to open an existing local folder without Scient +modifying it, or explicitly initialize a portable Scient project after previewing the proposed changes. Initialization must be additive, non-destructive, repeatable, recoverable after interruption, and usable without Git. Existing user files must not be silently overwritten. @@ -137,7 +138,7 @@ For structured projects, this may become a protocol, eligibility criteria, extra Researchers should be able to bring in the materials their work depends on: papers, references, PDFs, notes, protocols, datasets, code, images, prior drafts, institutional files, and external project artifacts. -PapiLab should help organize these materials with metadata, provenance, search, and links to the project record. +Scient should help organize these materials with metadata, provenance, search, and links to the project record. ### 3. Read, Annotate, And Make Decisions @@ -147,7 +148,7 @@ These decisions may include inclusion or exclusion reasons, quality judgments, m ### 4. Build Evidence And Project Knowledge -PapiLab should help turn reading and project work into reusable knowledge: source chunks, evidence records, extracted values, claims, notes, decisions, and links between them. +Scient should help turn reading and project work into reusable knowledge: source chunks, evidence records, extracted values, claims, notes, decisions, and links between them. The project should support synthesis, comparison, contradiction tracking, uncertainty, and source-grounded answers without turning evidence into opaque chat output. @@ -155,7 +156,7 @@ The project should support synthesis, comparison, contradiction tracking, uncert Many research projects require data, code, statistics, or computational workflows. -PapiLab should support datasets, scripts, notebooks or notebook-compatible work, analysis runs, parameters, methods, outputs, and run history. Computational work should connect back to the project's claims, figures, tables, manuscript sections, and decisions instead of living in a separate analysis island. +Scient should support datasets, scripts, notebooks or notebook-compatible work, analysis runs, parameters, methods, outputs, and run history. Computational work should connect back to the project's claims, figures, tables, manuscript sections, and decisions instead of living in a separate analysis island. ### 6. Create Figures, Tables, And Artifacts @@ -165,7 +166,7 @@ These outputs should remain connected to the sources, data, analysis, evidence, ### 7. Write And Revise Research Outputs -PapiLab should support drafting and revising manuscripts, reports, thesis sections, grant-supported arguments, protocols, and other scholarly outputs. +Scient should support drafting and revising manuscripts, reports, thesis sections, grant-supported arguments, protocols, and other scholarly outputs. Writing should connect to citations, evidence, claims, figures, tables, comments, and revision history. Researchers should be able to work at both focused section level and whole-document level when needed. @@ -173,17 +174,17 @@ Writing should connect to citations, evidence, claims, figures, tables, comments Researchers should be able to turn project work into durable outputs: manuscripts, reports, figures, tables, data packages, citation files, publication artifacts, deposits, and archives. -Exported or deposited work should preserve enough provenance for researchers to understand what produced it. A PapiLab project should remain useful for revisions, follow-up papers, future grants, related analyses, and long-term scholarly memory. +Exported or deposited work should preserve enough provenance for researchers to understand what produced it. A Scient project should remain useful for revisions, follow-up papers, future grants, related analyses, and long-term scholarly memory. ### Cross-Cutting Lifecycle Work Across the lifecycle, advisors, coauthors, assistants, analysts, librarians, reviewers, and agents may all contribute to the same project over time. -PapiLab should keep those contributions attributable and folded into the project record instead of scattering decisions across email, chat, documents, notebooks, and disconnected files. +Scient should keep those contributions attributable and folded into the project record instead of scattering decisions across email, chat, documents, notebooks, and disconnected files. ## Core Project Workspace Requirements -A PapiLab project should behave as one durable scientific workspace, not as a collection of disconnected files, chats, notebooks, references, and exported documents. +A Scient project should behave as one durable scientific workspace, not as a collection of disconnected files, chats, notebooks, references, and exported documents. These requirements describe what the workspace must make possible across the project. They do not define database objects, app pages, implementation architecture, or a complete feature list. @@ -237,7 +238,7 @@ When upstream data, code, methods, or evidence change, the workspace should help The workspace should support research projects involving advisors, coauthors, assistants, analysts, librarians, reviewers, and other collaborators. -PapiLab should support comments, suggestions, assignments, approvals, attribution, shared review, synchronized co-editing, and real-time collaboration where useful. Collaboration should strengthen the project record instead of scattering decisions across email, chat, duplicated documents, and disconnected files. +Scient should support comments, suggestions, assignments, approvals, attribution, shared review, synchronized co-editing, and real-time collaboration where useful. Collaboration should strengthen the project record instead of scattering decisions across email, chat, duplicated documents, and disconnected files. Concurrent edits and contributions should produce understandable attribution, conflict, review, and recovery states. @@ -255,7 +256,7 @@ Researchers should be able to bring materials in, send outputs out, preserve pro ## Core Product Surfaces -PapiLab should have a recognizable product shape. These are the main product surfaces a researcher should be able to recognize in PapiLab, even if the final UI combines, splits, or rearranges them. They are product surfaces, not mandatory routes, tabs, database tables, or implementation boundaries. +Scient should have a recognizable product shape. These are the main product surfaces a researcher should be able to recognize in Scient, even if the final UI combines, splits, or rearranges them. They are product surfaces, not mandatory routes, tabs, database tables, or implementation boundaries. | Surface | Product responsibility | |---|---| @@ -282,11 +283,11 @@ material that produced it, from a claim to its support, from agent work to the affected artifacts, and from a changed source or analysis to the project areas that may need review. -PapiLab should maintain stable product vocabulary for durable project records and relationships without turning the PRD into a database schema. Important records include the project, protocol, source, file, source region or chunk, screening decision, extraction, claim, evidence link, dataset, analysis run, figure, table, manuscript, citation, note, agent run, proposed artifact, memory, collaborator, and export or deposit record. +Scient should maintain stable product vocabulary for durable project records and relationships without turning the PRD into a database schema. Important records include the project, protocol, source, file, source region or chunk, screening decision, extraction, claim, evidence link, dataset, analysis run, figure, table, manuscript, citation, note, agent run, proposed artifact, memory, collaborator, and export or deposit record. ## Primary Product Journeys -These journeys are not roadmap phases or implementation slices. They describe the core flows PapiLab must make coherent across product surfaces. +These journeys are not roadmap phases or implementation slices. They describe the core flows Scient must make coherent across product surfaces. - Start a project from a question, files, sources, dataset, protocol, or draft. - Use Scient or external-agent chat to ask questions, plan work, delegate @@ -301,21 +302,21 @@ These journeys are not roadmap phases or implementation slices. They describe th ## Source, Evidence, Claims, And Scientific Trust -PapiLab should make scientific support inspectable. Sources, extracted evidence, claims, citations, analysis outputs, figures, tables, and agent-generated material should remain connected so researchers can understand why a statement exists, what supports it, what weakens it, and what still needs review. +Scient should make scientific support inspectable. Sources, extracted evidence, claims, citations, analysis outputs, figures, tables, and agent-generated material should remain connected so researchers can understand why a statement exists, what supports it, what weakens it, and what still needs review. This trust layer is not only for formal systematic reviews. It should support ordinary research reading, exploratory synthesis, clinical or applied reports, computational projects, thesis work, manuscripts, and grant or proposal arguments whenever the project depends on sources, evidence, or claims. -PapiLab should support literature review and evidence synthesis workflows, including source discovery, screening, extraction into the evidence ledger, evidence-strength or quality appraisal, methodological review where relevant, and synthesis of supported, conflicting, weak, or uncertain findings. +Scient should support literature review and evidence synthesis workflows, including source discovery, screening, extraction into the evidence ledger, evidence-strength or quality appraisal, methodological review where relevant, and synthesis of supported, conflicting, weak, or uncertain findings. ### Source Records And Reading Researchers should be able to discover, import, deduplicate, normalize, read, annotate, and organize scholarly and project sources. Source records should preserve enough metadata and provenance to support citation, later review, export, and recovery. -Source import should be duplicate-safe. PapiLab should distinguish new sources, strong duplicates, and possible duplicates; preserve identity confidence where useful; require researcher review for ambiguous matches; and provide import receipts explaining what was added, merged, skipped, repaired, or left unresolved. +Source import should be duplicate-safe. Scient should distinguish new sources, strong duplicates, and possible duplicates; preserve identity confidence where useful; require researcher review for ambiguous matches; and provide import receipts explaining what was added, merged, skipped, repaired, or left unresolved. -When sources are found through database search, API search, imported query results, or external search strategies, PapiLab should preserve enough search provenance for researchers to understand where the source set came from and how it could be reviewed or reproduced. +When sources are found through database search, API search, imported query results, or external search strategies, Scient should preserve enough search provenance for researchers to understand where the source set came from and how it could be reviewed or reproduced. -When PapiLab parses PDFs, documents, tables, figures, citation contexts, or other source material, the result should remain connected to exact source regions where possible. Parser confidence, missing material, unsupported structure, and extraction failures should be visible enough for researchers and agents to avoid treating uncertain source material as settled fact. +When Scient parses PDFs, documents, tables, figures, citation contexts, or other source material, the result should remain connected to exact source regions where possible. Parser confidence, missing material, unsupported structure, and extraction failures should be visible enough for researchers and agents to avoid treating uncertain source material as settled fact. ### Source Detail And Backlinks @@ -325,9 +326,9 @@ Researchers should be able to move from a source to every project place that use ### Screening, Extraction, And Evidence Tables -PapiLab should support researcher-controlled screening and classification when a project requires it. Inclusion and exclusion decisions should preserve reasons, criteria, reviewer attribution where relevant, and enough accounting to support reporting needs such as PRISMA-style counts when appropriate. +Scient should support researcher-controlled screening and classification when a project requires it. Inclusion and exclusion decisions should preserve reasons, criteria, reviewer attribution where relevant, and enough accounting to support reporting needs such as PRISMA-style counts when appropriate. -PapiLab should support extraction schemas, extraction tables, extracted values, and evidence records. Extracted values and table cells should link back to their source support, carry enough context to be reviewed, and remain exportable for analysis, reporting, or external continuation. +Scient should support extraction schemas, extraction tables, extracted values, and evidence records. Extracted values and table cells should link back to their source support, carry enough context to be reviewed, and remain exportable for analysis, reporting, or external continuation. Agents may suggest screening decisions, extracted values, evidence links, or table updates, but high-impact evidence work must remain reviewable, correctable, attributable, and recoverable. @@ -335,45 +336,45 @@ Agents may suggest screening decisions, extracted values, evidence links, or tab Claims in notes, synthesis, manuscripts, reports, figures, tables, and other project outputs should be linkable to supporting sources, source regions, extracted evidence, data, analysis outputs, and decisions. -PapiLab should make unsupported, weakly supported, conflicting, uncertain, stale, or agent-generated claims visible. When evidence quality, risk of bias, study limitations, methodological concerns, or contradictory findings matter to the workflow, PapiLab should preserve those judgments alongside the evidence and claims they affect. +Scient should make unsupported, weakly supported, conflicting, uncertain, stale, or agent-generated claims visible. When evidence quality, risk of bias, study limitations, methodological concerns, or contradictory findings matter to the workflow, Scient should preserve those judgments alongside the evidence and claims they affect. ### Evidence-Grounded Synthesis -PapiLab should support project Q&A and synthesis grounded in project material. Answers should show their support, identify gaps or conflicts, and distinguish source-grounded statements from inference, speculation, or agent-generated language. +Scient should support project Q&A and synthesis grounded in project material. Answers should show their support, identify gaps or conflicts, and distinguish source-grounded statements from inference, speculation, or agent-generated language. Useful synthesis should be able to become durable project work: notes, evidence links, draft material, decisions, unresolved questions, or review tasks. It should not remain trapped in opaque chat history when it affects the research record. ## Data, Code, Analysis, Figures, And Artifacts -PapiLab should support the data, computation, and artifact work needed for real research projects without becoming only a notebook app, statistics package, workflow platform, or figure editor. The product requirement is continuity: datasets, code, methods, runs, results, tables, figures, captions, claims, and manuscript sections should stay connected. +Scient should support the data, computation, and artifact work needed for real research projects without becoming only a notebook app, statistics package, workflow platform, or figure editor. The product requirement is continuity: datasets, code, methods, runs, results, tables, figures, captions, claims, and manuscript sections should stay connected. -This is first-class product scope because many research projects depend on data and computation as much as literature. PapiLab should let researchers and agents work with analysis material while preserving enough provenance, reviewability, and recovery to make outputs scientifically trustworthy. +This is first-class product scope because many research projects depend on data and computation as much as literature. Scient should let researchers and agents work with analysis material while preserving enough provenance, reviewability, and recovery to make outputs scientifically trustworthy. ### Data, Tables, And Project Artifacts Researchers should be able to bring datasets, data tables, images, intermediate outputs, generated files, reports, figures, and other artifacts into the project. These materials should have useful metadata, provenance, version awareness, and links to the project questions, sources, methods, analyses, claims, and outputs they affect. -PapiLab should distinguish durable research artifacts from temporary files. Important artifacts should be easy to inspect, reuse, cite within the project, export, archive, and recover. +Scient should distinguish durable research artifacts from temporary files. Important artifacts should be easy to inspect, reuse, cite within the project, export, archive, and recover. ### Code, Notebooks, And Analysis Runs -PapiLab should support scripts, notebook import/export or notebook-compatible work, approved local code execution, analysis parameters, method notes, run logs, generated outputs, and run history. +Scient should support scripts, notebook import/export or notebook-compatible work, approved local code execution, analysis parameters, method notes, run logs, generated outputs, and run history. Researchers should be able to understand what was run, which inputs were used, what assumptions or methods were applied, what outputs were produced, and which later project materials depend on those outputs. -When needed for reproducibility, PapiLab should capture environment or dependency information at the product level without requiring one specific runtime, notebook format, package manager, workflow engine, or execution architecture. +When needed for reproducibility, Scient should capture environment or dependency information at the product level without requiring one specific runtime, notebook format, package manager, workflow engine, or execution architecture. ### Results, Methods, And Stale Outputs Analysis results should connect to the data, code, parameters, methods, evidence, tables, figures, claims, captions, and manuscript sections that depend on them. Researchers should be able to compare relevant runs and understand which outputs are current. -When upstream data, code, parameters, methods, source evidence, or extraction tables change, PapiLab should help identify results, tables, figures, claims, captions, and manuscript sections that may be stale or need review. +When upstream data, code, parameters, methods, source evidence, or extraction tables change, Scient should help identify results, tables, figures, claims, captions, and manuscript sections that may be stale or need review. Later product depth may include statistical helpers, method-assumption checks, meta-analysis helpers, larger workflow or pipeline support, and domain-specific analysis adapters where the project requires them. ### Figures, Tables, And Visual Work -PapiLab should support publication-oriented tables, static computational figures, interactive figures, editable chart specifications, diagrams, graph visuals, visual plans, and editable scientific visuals. +Scient should support publication-oriented tables, static computational figures, interactive figures, editable chart specifications, diagrams, graph visuals, visual plans, and editable scientific visuals. These outputs should remain connected to their underlying data, code, analysis, evidence, source material, captions, claims, manuscript usage, and revision history. @@ -387,25 +388,25 @@ Agent-assisted analysis work should leave bounded tasks, logs, outputs, and reco ## Manuscript, Publishing, And Research Outputs -PapiLab should support serious scholarly writing, not only generated draft text. Researchers should be able to draft, revise, comment, cite, structure, adapt, export, and reconcile research outputs while keeping claims connected to sources, evidence, data, analysis, figures, tables, and decisions. +Scient should support serious scholarly writing, not only generated draft text. Researchers should be able to draft, revise, comment, cite, structure, adapt, export, and reconcile research outputs while keeping claims connected to sources, evidence, data, analysis, figures, tables, and decisions. The writing surface should support focused section-level work and whole-document work. Manuscripts, reports, thesis chapters, grant or proposal sections, protocols, and publication artifacts should be editable by researchers directly and assistable by agents through reviewable suggestions. Citations, bibliographies, evidence rails, claim-support diagnostics, comments, suggestions, cross-references, figures, tables, and publication requirements should remain part of the same project record. Exported documents should be outputs of the project, not detached files that sever provenance. -PapiLab should distinguish evidence-linked citations from auxiliary citations. Evidence-linked citations support, weaken, contradict, or contextualize claims through source and evidence links. Auxiliary citations are legitimate for background, methods, guidelines, definitions, or context, but they should not silently satisfy evidence-support diagnostics. +Scient should distinguish evidence-linked citations from auxiliary citations. Evidence-linked citations support, weaken, contradict, or contextualize claims through source and evidence links. Auxiliary citations are legitimate for background, methods, guidelines, definitions, or context, but they should not silently satisfy evidence-support diagnostics. -PapiLab should own structured references, citation rendering, bibliography generation, metadata repair, style validation, locators, citation diagnostics, and cited-versus-uncited visibility. Models may propose citation intent, but model-written reference text should not become canonical citation state. +Scient should own structured references, citation rendering, bibliography generation, metadata repair, style validation, locators, citation diagnostics, and cited-versus-uncited visibility. Models may propose citation intent, but model-written reference text should not become canonical citation state. Manuscripts should preserve meaningful publication metadata, including title, authors, affiliations, funding, conflicts, ethics, registration, data and code availability, journal profile, and reporting profile where relevant. -PapiLab should support import, export, and reconciliation with external writing and publishing tools where researchers already work. The PRD should not require one editor engine, export format, typesetting system, or submission workflow as the product core. +Scient should support import, export, and reconciliation with external writing and publishing tools where researchers already work. The PRD should not require one editor engine, export format, typesetting system, or submission workflow as the product core. -Manuscript import and reconciliation should be honest about fidelity. PapiLab should report which content, citations, cross-references, figures, tables, metadata, comments, or formatting were preserved, downgraded, unresolved, or lost. +Manuscript import and reconciliation should be honest about fidelity. Scient should report which content, citations, cross-references, figures, tables, metadata, comments, or formatting were preserved, downgraded, unresolved, or lost. ## Agent Delegation, Review, And Safe Automation -Scient is PapiLab's first-party research agent. External agents such as +The Scient agent is the product's first-party research agent. External agents such as OpenCode, Codex, Claude, Droid, and other supported products remain separate user choices; selecting or updating Scient must not silently replace, redirect, or consume the identity, configuration, subscription, credentials, or sessions @@ -420,9 +421,9 @@ and run code, run approved local tools, create analyses and figures, update citations, identify gaps, prepare artifacts, and assist with scientific or methodological knowledge. -Agent work should be object-scoped and context-aware. A researcher should be able to delegate from a source, evidence table, manuscript section, dataset, analysis run, figure, citation, note, or project task, and PapiLab should capture the relevant project context for that work. +Agent work should be object-scoped and context-aware. A researcher should be able to delegate from a source, evidence table, manuscript section, dataset, analysis run, figure, citation, note, or project task, and Scient should capture the relevant project context for that work. -Context capture should be visible. When a researcher sends project material to an agent, PapiLab should show a context receipt describing which sources, selections, notes, figures, draft sections, analyses, tasks, or workspace state are attached. PapiLab should avoid invisible prompt stuffing that affects agent behavior without giving the researcher a way to inspect what context was used. +Context capture should be visible. When a researcher sends project material to an agent, Scient should show a context receipt describing which sources, selections, notes, figures, draft sections, analyses, tasks, or workspace state are attached. Scient should avoid invisible prompt stuffing that affects agent behavior without giving the researcher a way to inspect what context was used. Agent outputs should land as reviewable project changes: proposed edits, artifacts, evidence records, run results, comments, task updates, logs, or diffs. Proposed changes should support a clear lifecycle: propose, inspect, edit where appropriate, accept, reject, apply, checkpoint, compare, and recover. @@ -436,25 +437,25 @@ The PRD should define the user/product contract for safe automation, not runtime Agent choice, access source, provider, and model are different product decisions. A researcher may choose Scient or an external agent, then use the -access and model choices that execution target legitimately supports. PapiLab +access and model choices that execution target legitimately supports. Scient must not describe an external agent subscription as though it were a model provider credential, or describe a model choice as though it selected an agent. -PapiLab should initially support three ways to access models: +Scient should initially support three ways to access models: - connect a supported official provider account or subscription where the provider permits that use; - bring a user-owned provider API key, with provider usage billed directly to the user; and -- use a PapiLab-managed model plan, with PapiLab providing and billing for access. +- use a Scient-managed model plan, with Scient providing and billing for access. -Researchers should be able to see which access source, provider, and model a task will use. Provider-connected and bring-your-own-key access should expose the models PapiLab can support through that provider, while PapiLab-managed access should use a smaller evaluated portfolio in which each model has a clear role. +Researchers should be able to see which access source, provider, and model a task will use. Provider-connected and bring-your-own-key access should expose the models Scient can support through that provider, while Scient-managed access should use a smaller evaluated portfolio in which each model has a clear role. -Manual model choice should remain available. PapiLab should later offer automatic task routing that selects the most cost-efficient eligible model expected to meet the task's scientific-quality, capability, privacy, tool, reliability, and latency requirements. Automatic choices and fallbacks must remain visible, explainable, and subject to researcher or project controls. +Manual model choice should remain available. Scient should later offer automatic task routing that selects the most cost-efficient eligible model expected to meet the task's scientific-quality, capability, privacy, tool, reliability, and latency requirements. Automatic choices and fallbacks must remain visible, explainable, and subject to researcher or project controls. Commercial options, rollout order, model selection, provider contracts, and routing architecture belong in planning, research, and architecture documents rather than this PRD. ## Project Memory And Continuity -PapiLab should maintain inspectable project memory so work can continue across sessions, collaborators, and agent runs. Project memory should include project direction, protocol decisions, source judgments, extraction choices, writing preferences, analysis decisions, unresolved questions, collaborator decisions, and prior agent work. +Scient should maintain inspectable project memory so work can continue across sessions, collaborators, and agent runs. Project memory should include project direction, protocol decisions, source judgments, extraction choices, writing preferences, analysis decisions, unresolved questions, collaborator decisions, and prior agent work. Memory should be useful, editable, and challengeable. Researchers should be able to inspect, correct, pin, forget, distrust, or update remembered context when it is stale, wrong, incomplete, or no longer relevant. @@ -464,9 +465,9 @@ Project memory should strengthen continuity without becoming opaque authority. A ## Local-First Ownership, Collaboration, And Mobile Continuation -PapiLab projects should be locally owned and durable, with cloud mirroring used where helpful for backup, cross-device continuation, sharing, teamwork, and collaboration. Cloud services should extend the project workspace without becoming the only source of truth. +Scient projects should be locally owned and durable, with cloud mirroring used where helpful for backup, cross-device continuation, sharing, teamwork, and collaboration. Cloud services should extend the project workspace without becoming the only source of truth. -PapiLab should support multi-user project work through project membership, roles, permissions, invitations, access revocation, comments, suggestions, assignments, attribution, shared review, notifications, and synchronized co-editing where real-time collaboration is useful. +Scient should support multi-user project work through project membership, roles, permissions, invitations, access revocation, comments, suggestions, assignments, attribution, shared review, notifications, and synchronized co-editing where real-time collaboration is useful. Collaboration should preserve project history. Researchers should be able to see who contributed what, review major changes, resolve conflicts, and recover earlier states. @@ -474,17 +475,17 @@ Mobile should be a continuation surface, not full desktop parity by default. Its ## Provenance, Versioning, Recovery, And Auditability -PapiLab should preserve enough history for researchers to understand what changed, who or what changed it, why it changed, and how to recover from mistakes. This applies to sources, evidence, citations, drafts, data, code, analysis runs, figures, tables, exports, agent actions, and collaboration. +Scient should preserve enough history for researchers to understand what changed, who or what changed it, why it changed, and how to recover from mistakes. This applies to sources, evidence, citations, drafts, data, code, analysis runs, figures, tables, exports, agent actions, and collaboration. The workspace should support event history, source provenance, evidence provenance, citation provenance, analysis provenance, agent action logs, diffs, checkpoints, snapshots, rollback, version comparison, and recovery after failed or partial work. -Provenance should be useful to researchers, not only mechanically complete. PapiLab should help users inspect and recover meaningful project changes without forcing normal users to understand raw logs, schemas, sync internals, or version-control mechanics. +Provenance should be useful to researchers, not only mechanically complete. Scient should help users inspect and recover meaningful project changes without forcing normal users to understand raw logs, schemas, sync internals, or version-control mechanics. Git or Git-like workflows may support readable artifacts, review, comparison, portability, and power-user workflows, but normal collaboration should not require researchers to manage Git directly. ## External Scholarly Interoperability -PapiLab should deliberately connect with the research tools, formats, databases, repositories, and services researchers already depend on. External systems should extend the PapiLab project workspace without defining its core shape or fragmenting the project record. +Scient should deliberately connect with the research tools, formats, databases, repositories, and services researchers already depend on. External systems should extend the Scient project workspace without defining its core shape or fragmenting the project record. Researchers should be able to bring work in and send work out through reference managers, citation formats, scholarly databases, document formats, data files, code environments, cloud drives, repositories, publishing systems, archives, and open-science platforms. @@ -492,22 +493,22 @@ Interoperability should prioritize continuity: references should remain citeable ## Deferred Scope And Non-Goals -PapiLab should not try to fully replace every adjacent research tool in its first product shape. It may include reference management, writing, source screening, analysis, figures, collaboration, and export, but it should not initially become a full Zotero replacement, full Overleaf replacement, full Jupyter replacement, full ELN, full enterprise systematic-review platform, full statistics package, full workflow-pipeline platform, full repository platform, complete journal-submission system, or full mobile-parity product. +Scient should not try to fully replace every adjacent research tool in its first product shape. It may include reference management, writing, source screening, analysis, figures, collaboration, and export, but it should not initially become a full Zotero replacement, full Overleaf replacement, full Jupyter replacement, full ELN, full enterprise systematic-review platform, full statistics package, full workflow-pipeline platform, full repository platform, complete journal-submission system, or full mobile-parity product. Deferred does not mean irrelevant. These areas should remain compatible paths, integration targets, or later product expansions when they strengthen the core project workflow. -PapiLab should protect its center: the durable research project itself. Adjacent tools should extend that workspace, not pull sources, evidence, data, analysis, writing, memory, or collaboration back into disconnected systems. +Scient should protect its center: the durable research project itself. Adjacent tools should extend that workspace, not pull sources, evidence, data, analysis, writing, memory, or collaboration back into disconnected systems. ## Product Readiness Criteria Use these criteria to evaluate future product, design, architecture, and implementation decisions against this PRD: -- PapiLab's product center is clearly the durable research project, not chat, a reference manager, a notebook, a manuscript editor, or an external service. +- Scient's product center is clearly the durable research project, not chat, a reference manager, a notebook, a manuscript editor, or an external service. - Important project work has an owning workspace area, visible state, provenance, and recovery path. - Researchers can trace claims, citations, figures, tables, and outputs back to supporting sources, evidence, data, analysis, and decisions where relevant. - Agent work is object-scoped, context-receipted, reviewable, permissioned, attributable, and recoverable. - Unknown, weak, stale, conflicting, imported, or agent-generated material remains visible instead of being silently normalized into false certainty. -- External tools, formats, and services extend the PapiLab project without defining its core model or becoming its only source of truth. +- External tools, formats, and services extend the Scient project without defining its core model or becoming its only source of truth. - Deferred areas are clearly compatible paths or later expansions, not hidden requirements for the first product shape. ## Open Product Questions diff --git a/docs/product/README.md b/docs/product/README.md index 27a93b8..0be786c 100644 --- a/docs/product/README.md +++ b/docs/product/README.md @@ -3,7 +3,7 @@ Status: Active Owner: Yaacov Last updated: 2026-07-17 -Purpose: Defines where PapiLab product documentation lives. +Purpose: Defines where Scient product documentation lives. Doc type: Repo orientation Product truth belongs here. @@ -11,7 +11,7 @@ Product truth belongs here. Current documents: - `PRD.md` - canonical product requirements and direction. -- `scient-product-identity.md` - accepted future company, application, native-agent, external-agent, and naming vocabulary, with an explicit current-versus-target boundary. +- `scient-product-identity.md` - accepted company, application, native-agent, external-agent, and naming vocabulary, with an explicit implemented-versus-planned boundary. - `product-philosophy.md` - draft home for durable product principles that guide product, architecture, design, quality, and implementation; the accepted PRD governs conflicts. Do not duplicate product truth in other docs. Link to the PRD, Scient product diff --git a/docs/product/product-philosophy.md b/docs/product/product-philosophy.md index 20bba37..b7952e2 100644 --- a/docs/product/product-philosophy.md +++ b/docs/product/product-philosophy.md @@ -2,8 +2,8 @@ Status: Draft Owner: Yaacov -Last updated: 2026-07-16 -Purpose: Defines PapiLab's durable product principles across product, architecture, design, quality, and implementation. +Last updated: 2026-07-17 +Purpose: Defines Scient's durable product principles across product, architecture, design, quality, and implementation. Doc type: Product truth ## Document Rules @@ -16,16 +16,16 @@ principles as a whole. ## Long-Term Product Ownership -Build PapiLab so we can keep owning, evolving, and scaling the product as it grows. +Build Scient so we can keep owning, evolving, and scaling the product as it grows. -Prefer architecture, dependencies, design systems, and workflows that can scale technically, economically, and organizationally while remaining replaceable, inspectable, extensible, and sustainable. Use open source and third-party services when they help, but do not let PapiLab's core product behavior depend on a vendor, subscription, closed platform, or external data model that would be hard to replace or control. +Prefer architecture, dependencies, design systems, and workflows that can scale technically, economically, and organizationally while remaining replaceable, inspectable, extensible, and sustainable. Use open source and third-party services when they help, but do not let Scient's core product behavior depend on a vendor, subscription, closed platform, or external data model that would be hard to replace or control. For design and frontend work, prefer shared components, tokens, and reusable primitives over hardcoded one-off styling. If a pattern should scale across the product, make it part of the system. ## Coherence Through First Principles -PapiLab should be built as one coherent system, not a collection of isolated decisions. +Scient should be built as one coherent system, not a collection of isolated decisions. Product, architecture, design, quality, security, and implementation choices should all trace back to the same underlying principles. A choice can be local, specialized, or experimental, but it should have a clear reason, a clear scope, and a clear relationship to the rest of the product. -Coherence does not mean rigidity. PapiLab can evolve when better reasoning or evidence appears; the discipline is to understand the first principles behind a choice and change direction explicitly, reconciling with the existing philosophy instead of letting silent contradictions accumulate. +Coherence does not mean rigidity. Scient can evolve when better reasoning or evidence appears; the discipline is to understand the first principles behind a choice and change direction explicitly, reconciling with the existing philosophy instead of letting silent contradictions accumulate. diff --git a/docs/product/scient-product-identity.md b/docs/product/scient-product-identity.md index d27b5dd..c45f88f 100644 --- a/docs/product/scient-product-identity.md +++ b/docs/product/scient-product-identity.md @@ -3,7 +3,7 @@ Status: Accepted Owner: Yaacov Last updated: 2026-07-17 -Purpose: Defines the chosen company, product, agent, and external-agent naming system for the future Scient identity. +Purpose: Defines the accepted company, product, agent, and external-agent naming system for Scient. Doc type: Product truth ## Document Rules @@ -14,9 +14,11 @@ PRD owns the broader product requirements. Architecture documents own runtime and state boundaries. The rename execution plan owns migration order, compatibility, verification, and rollback. -The identity decision is accepted direction. It does not mean the current -PapiLab repositories, packages, local state, project metadata, application -identity, website, or releases have already been renamed. +The identity decision is active for the company, repositories, application, +packages, local state, and new project metadata. PapiLab remains only where +required for migration compatibility or historical truth. The public website +cutover is a separately deferred owner task, and the native Scient agent is +still planned rather than implemented. ## Decision @@ -102,9 +104,9 @@ Recommended settings groups: the category name for external agents because some agents use local binaries, endpoints, accounts, API keys, or no subscription at all. -## Target Product Namespace +## Product Namespace -The accepted target for initialized project metadata is `.scient/`. +Initialized Scient project metadata uses `.scient/`. `.scient/` is the **Scient app's project metadata directory**. It is not the Scient agent's home, session store, cache, credential location, or private @@ -113,12 +115,14 @@ agent is unavailable and must remain usable manually or through an external agent. The exact contents and versioning of `.scient/` remain governed by the project -format and implementation evidence. The current implemented package still -creates `.papilab/`; migration to `.scient/` has not yet been executed. +format and implementation evidence. The implemented project-init package +creates `.scient/project.json` and provides additive, conflict-safe migration +from supported `.papilab/project.json` projects. -## Target Technical Naming Direction +## Technical Naming -The rename plan will validate and execute these targets: +The implemented app and project-init surfaces use these names. Agent-specific +rows remain reserved for the planned native Scient agent: | Surface | Target direction | |---|---| @@ -136,49 +140,46 @@ The rename plan will validate and execute these targets: | Agent home/profile | A dedicated `scient-agent` location, isolated from the app and external OpenCode | | Agent scratch workspaces | `scient-agent-workspaces` | -These are accepted naming targets, not claims about current implementation. -Exact identifiers may change before execution if platform constraints, -availability, migration safety, or formal clearance requires it. Any material -change to the public identity returns to this document for owner review. +The Scient-agent home and scratch-workspace names remain planned until that +runtime exists. Any material change to the public identity returns to this +document for owner review. -## Repository Direction +## Repository Topology -The intended long-term topology is: +The owned topology is: | Repository role | Confirmed owner and target name | |---|---| | GitHub organization | `ScientFactory` | | Parent product and documentation repository | `ScientFactory/Scient` | | Maintained desktop fork | `ScientFactory/scient-desktop` | -| Owned OpenCode-derived source repository before the Scient agent exists | `ScientFactory/opencode` | -| Owned first-party agent repository after the Scient agent exists | `ScientFactory/scient-agent` | - -The `ScientFactory` GitHub organization was created on 2026-07-17. Repository -ownership has not yet moved there. The current OpenCode-derived source -repository must transfer to the organization as `opencode` and retain that name -until it actually builds and packages the Scient agent. A later repository -rename must preserve official OpenCode as fetch-only upstream, Git ancestry, -licenses, attribution, inherited-core traceability, and reviewed update -history. External OpenCode remains a distinct external agent regardless of -repository topology. - -## Current-State Boundary - -At acceptance time: - -- PapiLab remains the active repository and implemented desktop identity. -- The `ScientFactory` GitHub organization exists, but it does not yet own the - parent, desktop, or OpenCode-derived repositories. -- `@papilab/project-init` and `.papilab/` are the only implemented first-party - project-initiation names. +| Owned first-party agent source repository | `ScientFactory/scient-agent` | + +The `ScientFactory` GitHub organization was created on 2026-07-17 and owns all +three repositories. The agent source repository is named `scient-agent` now by +explicit owner decision, even though the native agent product is not yet +implemented. It preserves official OpenCode as fetch-only upstream, Git +ancestry, licenses, attribution, inherited-core traceability, and reviewed +update history. External OpenCode remains a distinct external agent regardless +of repository topology. + +## Current State + +After the verified rename: + +- Scient is the active parent repository and implemented desktop identity. +- `ScientFactory` owns `Scient`, `scient-desktop`, and `scient-agent`. +- `@scientfactory/project-init` and `.scient/` are the implemented first-party + project-initiation names; PapiLab inputs are accepted only by the documented + migration path. - The Scient agent is planned but not implemented. - The broader scientific project format, agent gateway, and first vertical slice remain unbuilt. - The public website and deployment have not been cut over to Scient. Do not rewrite historical LitRev or PapiLab evidence as though it occurred -under Scient. Do not describe target names as implemented until the execution -plan records verified cutover evidence. +under Scient. Do not infer a finished Scient-agent runtime from the owned +`scient-agent` repository name. ## Clearance Boundary diff --git a/docs/quality/README.md b/docs/quality/README.md index 203f931..3a431c4 100644 --- a/docs/quality/README.md +++ b/docs/quality/README.md @@ -2,16 +2,16 @@ Status: Active Owner: Yaacov -Last updated: 2026-06-27 -Purpose: Defines where PapiLab quality, testing, and engineering-standard documentation lives. +Last updated: 2026-07-17 +Purpose: Defines where Scient quality, testing, and engineering-standard documentation lives. Doc type: Repo orientation Use this folder for quality principles and testing philosophy. Verification strategy belongs here when it is discussed and accepted; execution commands and CI operations belong later under `docs/development/` or `docs/operations/`. Current files: -- `testing-philosophy.md` - draft testing doctrine for PapiLab. -- `code-quality-principles.md` - draft code quality doctrine for PapiLab. +- `testing-philosophy.md` - draft testing doctrine for Scient. +- `code-quality-principles.md` - draft code quality doctrine for Scient. Do not use this folder as: diff --git a/docs/quality/code-quality-principles.md b/docs/quality/code-quality-principles.md index 9c19fa2..140ac28 100644 --- a/docs/quality/code-quality-principles.md +++ b/docs/quality/code-quality-principles.md @@ -2,15 +2,15 @@ Status: Draft Owner: Yaacov -Last updated: 2026-06-27 -Purpose: Defines PapiLab's code quality principles before implementation-specific standards and gates exist. +Last updated: 2026-07-17 +Purpose: Defines Scient's code quality principles before implementation-specific standards and gates exist. Doc type: Engineering doctrine -This document defines the engineering quality bar PapiLab should use when code exists. It is not a command reference, style guide, lint policy, or CI plan. +This document defines the engineering quality bar Scient should use when code exists. It is not a command reference, style guide, lint policy, or CI plan. ## Core Position -PapiLab should optimize for long-term correctness, explainable ownership, and recoverable scientific work over quick local fixes. +Scient should optimize for long-term correctness, explainable ownership, and recoverable scientific work over quick local fixes. A small change is good only if it solves the real problem without making the system harder to reason about. @@ -26,7 +26,7 @@ Temporary stopgaps are allowed only when explicitly marked with scope, risk, and Do not introduce new state ownership without naming who owns truth. -For PapiLab, ambiguous truth ownership is a critical failure mode. Project files, local databases, cloud mirrors, agent logs, evidence records, manuscript state, and snapshots must not become competing sources of truth. +For Scient, ambiguous truth ownership is a critical failure mode. Project files, local databases, cloud mirrors, agent logs, evidence records, manuscript state, and snapshots must not become competing sources of truth. New code should make ownership, mutation authority, and recovery behavior explicit. @@ -100,7 +100,7 @@ Repeated issues should become infrastructure. - One-off issue: fix it locally. - Repeated issue: document the rule. - Repeated rule violation: make it executable if practical. -- Repeated agent mistake: add it to `AGENTS.md` or a future PapiLab skill. +- Repeated agent mistake: add it to `AGENTS.md` or a future Scient skill. Do not let review comments become permanent folklore. diff --git a/docs/quality/testing-philosophy.md b/docs/quality/testing-philosophy.md index 6b855d6..9c225ab 100644 --- a/docs/quality/testing-philosophy.md +++ b/docs/quality/testing-philosophy.md @@ -2,15 +2,15 @@ Status: Draft Owner: Yaacov -Last updated: 2026-07-12 -Purpose: Defines PapiLab's testing philosophy before implementation-specific commands, lanes, and CI gates exist. +Last updated: 2026-07-17 +Purpose: Defines Scient's testing philosophy before implementation-specific commands, lanes, and CI gates exist. Doc type: Testing doctrine -This document defines how PapiLab should think about tests. It is not a command reference, CI plan, coverage policy, or test framework decision. +This document defines how Scient should think about tests. It is not a command reference, CI plan, coverage policy, or test framework decision. ## Core Position -Testing exists to protect PapiLab's product invariants: scientific truth, durable project state, user control, local-first reliability, cloud consistency, agent safety, and recoverability. +Testing exists to protect Scient's product invariants: scientific truth, durable project state, user control, local-first reliability, cloud consistency, agent safety, and recoverability. The goal is not test volume. The goal is to catch real regressions early with the smallest reliable proof that exercises the actual failure mode. @@ -76,7 +76,7 @@ Mocks are acceptable for external providers, clocks, nondeterminism, and expensi Do not mock owned state, permissions, persistence, file writes, sync behavior, or agent tool boundaries when those are the actual risk under test. -## PapiLab-Specific Proof Obligations +## Scient-Specific Proof Obligations Durable scientific state must have persistence proof: save, reload, migration, failure recovery, and compatibility where relevant. @@ -92,11 +92,11 @@ Performance is part of correctness for core workflows. A feature that only works ## Model Evaluation -External benchmarks are comparative research, not release proof. Before PapiLab assigns final production model roles or enables automatic routing, it must run a replayable internal evaluation suite on representative PapiLab workflows. +External benchmarks are comparative research, not release proof. Before Scient assigns final production model roles or enables automatic routing, it must run a replayable internal evaluation suite on representative Scient workflows. That later suite should cover scientific faithfulness, citations and evidence, mathematics, data analysis, coding, tools and agents, conversation and writing, long context, and vision or document work. Runs should preserve the model and provider version, reasoning settings, prompts and fixtures, tools, attempts, scoring method, latency, and cost. -Define the detailed methodology in `docs/quality/model-evaluation-methodology.md` when real PapiLab workflows and fixtures exist. Until then, external benchmark analysis belongs in `docs/research/source-evaluations/model-benchmark-map.md`. +Define the detailed methodology in `docs/quality/model-evaluation-methodology.md` when real Scient workflows and fixtures exist. Until then, external benchmark analysis belongs in `docs/research/source-evaluations/model-benchmark-map.md`. ## Architecture Feedback @@ -112,7 +112,7 @@ Tests verify behavior. Review still judges whether the design preserves clear ow ## Candidate Testing Conventions -These conventions should be revisited when PapiLab has implementation and selected test tooling. +These conventions should be revisited when Scient has implementation and selected test tooling. ### File Organization diff --git a/docs/research/README.md b/docs/research/README.md index 45b5de3..a1f289b 100644 --- a/docs/research/README.md +++ b/docs/research/README.md @@ -2,8 +2,8 @@ Status: Active Owner: Yaacov -Last updated: 2026-07-11 -Purpose: Maps where PapiLab external research, source evaluations, and spike reports live. +Last updated: 2026-07-17 +Purpose: Maps where Scient external research, source evaluations, and spike reports live. Doc type: Repo orientation Use this folder for source-backed research that informs product and architecture decisions. diff --git a/docs/research/source-evaluations/README.md b/docs/research/source-evaluations/README.md index b75b021..eac1bbf 100644 --- a/docs/research/source-evaluations/README.md +++ b/docs/research/source-evaluations/README.md @@ -2,8 +2,8 @@ Status: Active Owner: Yaacov -Last updated: 2026-07-12 -Purpose: Maps evaluations of external sources and tools that may inform PapiLab product and architecture decisions. +Last updated: 2026-07-17 +Purpose: Maps evaluations of external sources and tools that may inform Scient product and architecture decisions. Doc type: Repo orientation Use this folder for structured evaluations of external products, repositories, papers, tools, libraries, and model answers. @@ -13,9 +13,9 @@ Current files: - `competitive-landscape.md` - current direct competitors, substitute workflows, specialized alternatives, and integration candidates. - `model-benchmark-map.md` - external benchmark coverage, meaning, limitations, and relevance across the candidate model portfolio. - `model-portfolio-and-provider-routing.md` - current candidate model portfolio, distinct model roles, and the evidence needed before selection. -- `open-source-adaptation-map.md` - cross-source synthesis of open-source systems PapiLab should study, prototype, adapt, or avoid. +- `open-source-adaptation-map.md` - cross-source synthesis of open-source systems Scient should study, prototype, adapt, or avoid. - `source-evaluation-template.md` - future home for the source evaluation template. -Document the source, what was inspected, what PapiLab can learn from it, what should be avoided, and what remains uncertain. +Document the source, what was inspected, what Scient can learn from it, what should be avoided, and what remains uncertain. Do not mix raw source capture with final architecture decisions. diff --git a/docs/research/source-evaluations/competitive-landscape.md b/docs/research/source-evaluations/competitive-landscape.md index 768cffe..7907d45 100644 --- a/docs/research/source-evaluations/competitive-landscape.md +++ b/docs/research/source-evaluations/competitive-landscape.md @@ -2,29 +2,29 @@ Status: Draft Owner: Yaacov -Last updated: 2026-07-12 -Purpose: Maps direct competitors, substitute workflows, specialized alternatives, and integration candidates against PapiLab's product scope. +Last updated: 2026-07-17 +Purpose: Maps direct competitors, substitute workflows, specialized alternatives, and integration candidates against Scient's product scope. Doc type: Research evidence ## Document Rules This document is a living source evaluation, not product truth or a roadmap. Product scope remains owned by `../../product/PRD.md`. Promote only stable product implications into product or planning documents after review. -The product descriptions below come from public vendor or project pages inspected on 2026-07-12. Gaps and strategic posture are PapiLab interpretations, not exhaustive product audits. +The product descriptions below come from public vendor or project pages inspected on 2026-07-12. Gaps and strategic posture are Scient interpretations, not exhaustive product audits. ## Comparison Lens -Compare alternatives across PapiLab's connected project lifecycle: source discovery and reading; screening, extraction, evidence, and claims; synthesis; data and computation; figures and tables; manuscripts; agent work; durable project state; collaboration; provenance and recovery; local ownership; and interoperability. +Compare alternatives across Scient's connected project lifecycle: source discovery and reading; screening, extraction, evidence, and claims; synthesis; data and computation; figures and tables; manuscripts; agent work; durable project state; collaboration; provenance and recovery; local ownership; and interoperability. ## Landscape -| Alternative | Strongest overlap | Current PapiLab interpretation | +| Alternative | Strongest overlap | Current Scient interpretation | | --- | --- | --- | | [SciSpace](https://scispace.com/) | AI literature search, paper reading, systematic reviews, and cited writing | One of the closest AI research assistants, but not presented as a local-first scientific project record spanning computation and governed agent changes. | | [Elicit](https://elicit.com/) | Search, extraction, reports, research agents, and PRISMA-oriented systematic reviews | A close AI-native competitor whose reproducible, traceable review workflow reaches beyond simple search and summarization. | | [Nested Knowledge](https://about.nested-knowledge.com/) | Search, screening, extraction, appraisal, qualitative and quantitative synthesis, and manuscript work | A particularly close competitor for evidence-to-writing and living-review workflows. | | [DistillerSR](https://www.distillersr.com/) | Enterprise evidence review, AI-assisted screening and extraction, human validation, audit trails, and regulatory workflows | A serious competitor for governed and institution-ready evidence work. | -| [Covidence](https://www.covidence.org/) | Collaborative systematic-review management | An established workflow standard for structured reviews, but narrower than PapiLab's full project lifecycle. | +| [Covidence](https://www.covidence.org/) | Collaborative systematic-review management | An established workflow standard for structured reviews, but narrower than Scient's full project lifecycle. | | [Rayyan](https://www.rayyan.ai/) | Search, screening, extraction, risk of bias, PRISMA, collaboration, and AI prioritization | A broad systematic-review competitor rather than only a screening tool. | | [NotebookLM](https://notebooklm.google/) | Source-grounded multi-document questions, synthesis, reports, and generated learning artifacts | A strong substitute for understanding a source collection, but not a structured scientific project, analysis, or reviewable-change system. | | [Consensus](https://consensus.app/) | Peer-reviewed search, full-text analysis, cited answers, and research reports | A strong discovery and evidence-synthesis alternative, but not a complete project workspace. | @@ -32,7 +32,7 @@ Compare alternatives across PapiLab's connected project lifecycle: source discov | [JupyterLab](https://jupyter.org/) and [Quarto](https://quarto.org/) | Interactive computation and reproducible publication | The strongest data-to-figure-to-publication substitute, with limited ownership of literature evidence and governed agent work. | | [Overleaf](https://www.overleaf.com/) | Collaborative LaTeX manuscript production | A dominant downstream writing tool that begins near the manuscript rather than the whole project record. | | [ResearchRabbit](https://www.researchrabbit.ai/), [Litmaps](https://www.litmaps.com/), and [Scite](https://scite.ai/) | Discovery, citation navigation, and citation-context intelligence | Specialized competitors and likely integration or acquisition channels rather than complete workspace substitutes. | -| [OpenAI Deep Research](https://openai.com/index/introducing-deep-research/) and [Gemini Deep Research](https://ai.google.dev/gemini-api/docs/deep-research) | Autonomous multi-step search and cited research reports | General research agents can satisfy an important early job, but do not by themselves provide PapiLab's durable scientific project model. | +| [OpenAI Deep Research](https://openai.com/index/introducing-deep-research/) and [Gemini Deep Research](https://ai.google.dev/gemini-api/docs/deep-research) | Autonomous multi-step search and cited research reports | General research agents can satisfy an important early job, but do not by themselves provide Scient's durable scientific project model. | | [Benchling](https://www.benchling.com/notebook) and [LabArchives](https://www.labarchives.com/products/eln-for-research) | Laboratory records, data, protocols, collaboration, permissions, and audit history | Important durable-record competitors for laboratory teams, but specialized toward experimental and institutional workflows. | ## Substitute Workflows @@ -47,13 +47,13 @@ The strongest practical competitor may be the stack researchers already assemble ## Strategic Interpretation -No inspected product presents the same complete product center as PapiLab. This is an inference from their public product surfaces, not proof that no private or emerging competitor exists. +No inspected product presents the same complete product center as Scient. This is an inference from their public product surfaces, not proof that no private or emerging competitor exists. -PapiLab's opportunity is to connect: +Scient's opportunity is to connect: `sources -> evidence -> claims -> data and analysis -> figures and tables -> manuscript -> reviewed agent changes -> history and provenance` -The competitive risk is that specialized products continue expanding across adjacent stages while general agents make one-off research reports increasingly sufficient. PapiLab must therefore prove that a durable connected project is materially better than both a polished research answer and a familiar modular stack. +The competitive risk is that specialized products continue expanding across adjacent stages while general agents make one-off research reports increasingly sufficient. Scient must therefore prove that a durable connected project is materially better than both a polished research answer and a familiar modular stack. ## Priority Follow-Up @@ -65,4 +65,4 @@ Deepen the comparison first for: 4. Zotero, JupyterLab, Quarto, and Overleaf as the incumbent modular workflow. 5. General deep-research agents as rapidly improving substitutes. -Add separate product evaluations only when a deeper inspection would change PapiLab's product requirements, first workflow, integration strategy, or competitive positioning. +Add separate product evaluations only when a deeper inspection would change Scient's product requirements, first workflow, integration strategy, or competitive positioning. diff --git a/docs/research/source-evaluations/model-benchmark-map.md b/docs/research/source-evaluations/model-benchmark-map.md index a0c3b49..41fe290 100644 --- a/docs/research/source-evaluations/model-benchmark-map.md +++ b/docs/research/source-evaluations/model-benchmark-map.md @@ -2,15 +2,15 @@ Status: Draft Owner: Yaacov -Last updated: 2026-07-12 -Purpose: Maps what external model benchmarks measure, how trustworthy they are, and how much weight PapiLab should give them. +Last updated: 2026-07-17 +Purpose: Maps what external model benchmarks measure, how trustworthy they are, and how much weight Scient should give them. Doc type: Research evidence ## Document Rules -This document owns external benchmark research across the candidate portfolio. It does not approve models or define PapiLab's internal evaluation methodology. +This document owns external benchmark research across the candidate portfolio. It does not approve models or define Scient's internal evaluation methodology. -Portfolio decisions live in `model-portfolio-and-provider-routing.md`. The later PapiLab-owned methodology will live in `../../quality/model-evaluation-methodology.md` when representative workflows and fixtures exist. +Portfolio decisions live in `model-portfolio-and-provider-routing.md`. The later Scient-owned methodology will live in `../../quality/model-evaluation-methodology.md` when representative workflows and fixtures exist. ## Portfolio Coverage @@ -28,7 +28,7 @@ Record missing or non-comparable results instead of treating absence as failure ## Required Capability Coverage -| Capability | Initial benchmarks or evidence to inspect | Why PapiLab needs it | +| Capability | Initial benchmarks or evidence to inspect | Why Scient needs it | | --- | --- | --- | | Science and health | GeneBench Pro, LifeSciBench, MedChemBench, HealthBench Professional | Scientific and biomedical reasoning. | | Citations and evidence | Identify suitable external benchmarks; do not rely on generic factuality scores | Claim support, source fidelity, and citation integrity. | @@ -53,7 +53,7 @@ For each benchmark, record: - whether results are independent, vendor-published, private, public, or contamination-prone; - known limitations and criticism; - which portfolio models have genuinely comparable results; -- relevance to concrete PapiLab use cases; and +- relevance to concrete Scient use cases; and - decision weight: `Primary`, `Supporting`, `Context only`, or `Exclude`. ## Trust Rules @@ -62,11 +62,11 @@ For each benchmark, record: - Compare several benchmarks that measure the same capability differently. - Do not combine scores from different versions or test conditions as if they were equivalent. - Treat vendor-published results as useful but lower-confidence until independently reproduced or supported. -- Prefer benchmarks that resemble real PapiLab work, expose their method, and resist contamination. +- Prefer benchmarks that resemble real Scient work, expose their method, and resist contamination. - Keep benchmark capability separate from cost, privacy, provider reliability, and product fit. ## Later Internal Evaluation External benchmarks will shortlist models and expose likely strengths. They will not determine final production roles or automatic routing. -In a later phase, PapiLab will build its own replayable evaluation suite around representative scientific projects, evidence and citation work, mathematics, data analysis, coding, tools, conversation, writing, long context, and visual documents. That suite will become the stronger release and routing evidence. +In a later phase, Scient will build its own replayable evaluation suite around representative scientific projects, evidence and citation work, mathematics, data analysis, coding, tools, conversation, writing, long context, and visual documents. That suite will become the stronger release and routing evidence. diff --git a/docs/research/source-evaluations/model-portfolio-and-provider-routing.md b/docs/research/source-evaluations/model-portfolio-and-provider-routing.md index 93147d9..39a9693 100644 --- a/docs/research/source-evaluations/model-portfolio-and-provider-routing.md +++ b/docs/research/source-evaluations/model-portfolio-and-provider-routing.md @@ -2,19 +2,19 @@ Status: Draft Owner: Yaacov -Last updated: 2026-07-12 -Purpose: Tracks PapiLab's candidate model portfolio and the distinct value each model must prove before selection. +Last updated: 2026-07-17 +Purpose: Tracks Scient's candidate model portfolio and the distinct value each model must prove before selection. Doc type: Research evidence ## Document Rules -This is a candidate portfolio, not an accepted model registry or implemented routing policy. It is adapted from a dated PapiLab_2026 review. Model names, capabilities, prices, availability, and provider terms must be rechecked before a decision. +This is a candidate portfolio, not an accepted model registry or implemented routing policy. It is adapted from a dated Scient_2026 review. Model names, capabilities, prices, availability, and provider terms must be rechecked before a decision. Access priorities live in `../../planning/model-access-and-routing-evolution.md`. External benchmark analysis lives in `model-benchmark-map.md`. Future routing architecture belongs in `../../architecture/agent-runtime.md`. ## Access Boundary -This curated portfolio applies primarily to PapiLab-managed access. Provider-connected and bring-your-own-key users may choose from the broader set of models PapiLab can support through their provider. +This curated portfolio applies primarily to Scient-managed access. Provider-connected and bring-your-own-key users may choose from the broader set of models Scient can support through their provider. ## Current Candidate Portfolio @@ -32,7 +32,7 @@ Keep all seven in consideration until the broader review is complete. Refine, re ## Selection Standard -Every PapiLab-managed model should add a real role. Compare candidates on: +Every Scient-managed model should add a real role. Compare candidates on: - scientific faithfulness and citation integrity; - mathematical and quantitative reasoning; @@ -44,7 +44,7 @@ Every PapiLab-managed model should add a real role. Compare candidates on: - latency and operational reliability; and - effective cost per successful task. -Vendor claims, single benchmark scores, and headline token prices are not enough. Use the benchmark map to understand external evidence, then select exact models and routes from PapiLab-specific use cases and later internal evaluations. +Vendor claims, single benchmark scores, and headline token prices are not enough. Use the benchmark map to understand external evidence, then select exact models and routes from Scient-specific use cases and later internal evaluations. ## Routing Direction @@ -55,5 +55,5 @@ Begin with manual choice. Later, evaluate recommendations and automatic routing 1. Recheck the seven candidates against primary sources. 2. Map relevant external benchmarks across every candidate. 3. Look for missing roles before adding more models. -4. Define the later PapiLab-owned evaluation suite. +4. Define the later Scient-owned evaluation suite. 5. Compare alternatives, then retain only models with distinct value. diff --git a/docs/research/source-evaluations/open-source-adaptation-map.md b/docs/research/source-evaluations/open-source-adaptation-map.md index 592cb32..ba71295 100644 --- a/docs/research/source-evaluations/open-source-adaptation-map.md +++ b/docs/research/source-evaluations/open-source-adaptation-map.md @@ -1,16 +1,16 @@ -# PapiLab Open-Source Adaptation Map +# Scient Open-Source Adaptation Map Status: Proposed Owner: Yaacov Last updated: 2026-07-17 -Purpose: Maps which open-source systems PapiLab should study, prototype, adapt, or integrate, and which product boundaries PapiLab must keep owned. +Purpose: Maps which open-source systems Scient should study, prototype, adapt, or integrate, and which product boundaries Scient must keep owned. Doc type: Research evidence ## Document Rules -This document is a cross-source research synthesis. It records what PapiLab can +This document is a cross-source research synthesis. It records what Scient can learn from external open-source systems, which ideas deserve prototypes, and -which boundaries must stay inside PapiLab. +which boundaries must stay inside Scient. This document does not own product truth, accepted architecture, current implementation, package boundaries, or final dependency choices. Product truth @@ -21,7 +21,7 @@ belongs in `docs/product/`. Accepted stack direction belongs in ### Update Policy Update this document when a source evaluation, prototype, license review, or -explicit product/architecture decision materially changes what PapiLab should +explicit product/architecture decision materially changes what Scient should adapt, avoid, or prove next. When a recommendation becomes accepted architecture, promote it into the relevant @@ -35,7 +35,7 @@ This is a synthesis document, not a finished per-source evaluation. Current inputs: - Yaacov's product notes and collected model-answer research. -- PapiLab's documentation policy, product documents, and proposed architecture +- Scient's documentation policy, product documents, and proposed architecture direction as of 2026-07-07. - Related scientific-tool landscape and architecture-scorecard research. - Focused data-analysis and figure-tool source scan on 2026-06-27. @@ -44,10 +44,10 @@ Current inputs: JupyterLab Desktop, Stencila, ELN/RDM tools, local-first knowledge apps, and CoCalc. - The accepted foundation decision in - `../../architecture/decisions/ADR-0001-synara-opencode-foundation-and-papilab-ownership-boundary.md`: + `../../architecture/decisions/ADR-0001-synara-opencode-foundation-and-scient-ownership-boundary.md`: use the owned Synara fork initially; build Scient as the owned OpenCode-derived first-party agent; preserve external OpenCode separately; - and keep PapiLab's scientific meaning, agent boundary, provenance, and review + and keep Scient's scientific meaning, agent boundary, provenance, and review model owned. - Current planning discussion that upstream-trackable tools, thin forks, divergent forks, reference sources, projections, adapters, and export targets @@ -84,34 +84,34 @@ links, inspected revisions, licenses, and prototype results exist. Open-source adaptation here means study, prototype, adapt, fork narrowly, integrate, or use as a reference. It does not mean adopting another product's -domain model as PapiLab's core, or copying code without a license review. +domain model as Scient's core, or copying code without a license review. The main rule is: -> PapiLab owns the scientific product core. Open-source projects provide proven +> Scient owns the scientific product core. Open-source projects provide proven > mechanisms around that core. ## Adaptation Modes -Use these labels when mapping external sources to PapiLab work. They are planning +Use these labels when mapping external sources to Scient work. They are planning and research labels, not accepted architecture. | Mode | Meaning | Guardrail | |---|---|---| -| PapiLab-owned core | PapiLab defines the durable product object, permission boundary, or scientific truth. | This cannot be delegated to an external app, engine, database, editor, or agent. | -| Upstream-trackable integration | PapiLab keeps the upstream tool mostly intact and integrates through configuration, SDK, CLI, plugin, API, sidecar, wrapper, or adapter. | Upstream updates should usually be possible through version bumps plus adapter fixes. | -| Add-on layer | PapiLab builds prompts, plugins, wrappers, adapters, UI panels, metadata capture, or commands around a tool without changing its core. | The upstream tool should remain recognizable and updateable. | -| Forked workbench prototype | PapiLab uses a fork of an existing app to move faster on shell, UI, orchestration, terminals, diffs, provider sessions, or local process management. | This is a workbench-specific use of thin fork or divergent fork. It must not own the PapiLab scientific model. | -| Embedded engine | PapiLab calls an external tool through a CLI, SDK, local service, or sidecar. | Raw engine state is preserved for inspection, but accepted changes write back through PapiLab-owned objects and permissions. | -| Adapter | PapiLab imports, exports, syncs, or reconciles with another tool or format. | The adapter translates between systems; it does not make the external format canonical. | -| Projection | PapiLab renders or edits a PapiLab object through an editor, notebook, chart, CRDT, export AST, or runtime-specific representation. | The projection can be regenerated or reconciled from PapiLab state. | -| Thin fork | PapiLab changes a small, isolated integration seam in an upstream project. | The fork should stay close enough to upstream that merging updates remains realistic. | -| Divergent fork | PapiLab materially changes the upstream project's product assumptions, architecture, data model, or UX. | Upstream updates are no longer directly mergeable; future upstream work becomes cherry-pick material. | -| Reference / cherry-pick source | PapiLab studies workflows, UX, architecture patterns, or code and manually adapts selected ideas. | No dependency or clean update path is expected. | -| Export target | PapiLab generates files, packages, deposits, or publication artifacts from PapiLab state. | Exported output is not project truth. | -| Compatibility target | PapiLab must cooperate with this tool or format because researchers already use it. | Compatibility does not mean adopting the external tool's product model. | +| Scient-owned core | Scient defines the durable product object, permission boundary, or scientific truth. | This cannot be delegated to an external app, engine, database, editor, or agent. | +| Upstream-trackable integration | Scient keeps the upstream tool mostly intact and integrates through configuration, SDK, CLI, plugin, API, sidecar, wrapper, or adapter. | Upstream updates should usually be possible through version bumps plus adapter fixes. | +| Add-on layer | Scient builds prompts, plugins, wrappers, adapters, UI panels, metadata capture, or commands around a tool without changing its core. | The upstream tool should remain recognizable and updateable. | +| Forked workbench prototype | Scient uses a fork of an existing app to move faster on shell, UI, orchestration, terminals, diffs, provider sessions, or local process management. | This is a workbench-specific use of thin fork or divergent fork. It must not own the Scient scientific model. | +| Embedded engine | Scient calls an external tool through a CLI, SDK, local service, or sidecar. | Raw engine state is preserved for inspection, but accepted changes write back through Scient-owned objects and permissions. | +| Adapter | Scient imports, exports, syncs, or reconciles with another tool or format. | The adapter translates between systems; it does not make the external format canonical. | +| Projection | Scient renders or edits a Scient object through an editor, notebook, chart, CRDT, export AST, or runtime-specific representation. | The projection can be regenerated or reconciled from Scient state. | +| Thin fork | Scient changes a small, isolated integration seam in an upstream project. | The fork should stay close enough to upstream that merging updates remains realistic. | +| Divergent fork | Scient materially changes the upstream project's product assumptions, architecture, data model, or UX. | Upstream updates are no longer directly mergeable; future upstream work becomes cherry-pick material. | +| Reference / cherry-pick source | Scient studies workflows, UX, architecture patterns, or code and manually adapts selected ideas. | No dependency or clean update path is expected. | +| Export target | Scient generates files, packages, deposits, or publication artifacts from Scient state. | Exported output is not project truth. | +| Compatibility target | Scient must cooperate with this tool or format because researchers already use it. | Compatibility does not mean adopting the external tool's product model. | | Deferred shelf | A source is valuable but not needed for the first coherent product slice. | Keep it visible without expanding the first build. | -| Avoid / do not adopt | A source or pattern is worth knowing about but should not shape PapiLab's architecture. | Usually because it would pull PapiLab away from the scientific project center. | +| Avoid / do not adopt | A source or pattern is worth knowing about but should not shape Scient's architecture. | Usually because it would pull Scient away from the scientific project center. | ### Update Strategy Labels @@ -119,9 +119,9 @@ Use these labels with source rows when the update path matters: | Update strategy | Meaning | |---|---| -| `no-upstream` | PapiLab owns this part. There is no external project to update from. | +| `no-upstream` | Scient owns this part. There is no external project to update from. | | `version-bump` | The source can usually be updated directly, with normal dependency testing. | -| `adapter-maintained` | Update upstream, then repair or validate the PapiLab adapter. | +| `adapter-maintained` | Update upstream, then repair or validate the Scient adapter. | | `thin-fork-merge` | Keep the fork close enough to upstream that regular merges remain plausible. | | `divergent-cherry-pick` | Upstream updates cannot be merged directly; inspect and adapt useful changes manually. | | `reference-only` | No dependency or fork; watch for ideas and patterns. | @@ -130,36 +130,36 @@ Use these labels with source rows when the update path matters: ## Global Fork And Borrow Strategy The accepted foundation direction is more aggressive than "study only", but -still PapiLab-boundary-first: +still Scient-boundary-first: 1. Use the owned Synara fork as the initial application foundation because it materially accelerates the desktop shell, chat, terminal, diff, provider-session, and local-process surfaces. 2. Pressure-test that foundation through the first science-facing slice while - keeping PapiLab's project state, agent gateway, source/evidence meaning, and + keeping Scient's project state, agent gateway, source/evidence meaning, and review model outside Synara's coding assumptions. 3. Treat science apps as specialized sources, not desktop bases: Zotero-family tools for sources and PDFs, Zettlr/Overleaf/Quarto/MyST for writing/export expectations, Jupyter-style tools for analysis compatibility, and ELN/RDM tools for protocol/lab/repository references. -4. Use the owned OpenCode fork as the source foundation for Scient, PapiLab's +4. Use the owned OpenCode fork as the source foundation for Scient, Scient's first-party agent. Scient is the resulting owned agent, not a shell over a separate OpenCode engine. Preserve external OpenCode as an independent external agent. Keep Goose as a deferred source of capabilities and - architecture lessons after the first PapiLab gateway exists. -5. Use PapiLab-owned forks as the writable source remotes, while preferring + architecture lessons after the first Scient gateway exists. +5. Use Scient-owned forks as the writable source remotes, while preferring upstream binaries, SDKs, CLIs, configuration, sidecars, adapters, and extensions over core modifications. An owned fork may remain upstream- - aligned. Use divergent core changes only when PapiLab intentionally takes + aligned. Use divergent core changes only when Scient intentionally takes ownership of a modified product surface and accepts cherry-pick updates. -6. Normalize Scient and external agents through a PapiLab-owned Agent Gateway: scoped context, +6. Normalize Scient and external agents through a Scient-owned Agent Gateway: scoped context, permissions, approvals, file actions, tool calls, diffs, artifacts, errors, checkpoints, and final write-back. 7. Preserve raw upstream logs as runtime evidence, but store accepted scientific - work as PapiLab project objects. + work as Scient project objects. 8. Re-evaluate any fork once the first vertical scientific workflow works. If the - fork's product assumptions fight PapiLab's project model, keep only the useful - parts and move toward a more PapiLab-owned shell. + fork's product assumptions fight Scient's project model, keep only the useful + parts and move toward a more Scient-owned shell. The matching build strategy is started in `docs/planning/open-source-adaptation-build-strategy.md`. This source map remains @@ -167,28 +167,28 @@ the research trail, not the build plan or final architecture decision. ## Truth Boundary -PapiLab should have one canonical scientific model. Everything external attaches +Scient should have one canonical scientific model. Everything external attaches to it as an adapter, engine, projection, or export artifact. | Boundary | Meaning | Examples | |---|---|---| -| Canonical PapiLab model | The durable project truth. | Project, Paper, SourceChunk, Claim, EvidenceLink, ScreeningDecision, Dataset, Analysis, Figure, Manuscript, AgentAction, Provenance. | -| Engine adapter state | Runtime-specific state that can be cached, inspected, and rebuilt from the PapiLab model. | PaperQA context stores, ASReview screening DBs, GROBID/Docling extraction outputs, executor session metadata. | +| Canonical Scient model | The durable project truth. | Project, Paper, SourceChunk, Claim, EvidenceLink, ScreeningDecision, Dataset, Analysis, Figure, Manuscript, AgentAction, Provenance. | +| Engine adapter state | Runtime-specific state that can be cached, inspected, and rebuilt from the Scient model. | PaperQA context stores, ASReview screening DBs, GROBID/Docling extraction outputs, executor session metadata. | | Editor projection | State used to render and edit a manuscript, not the manuscript truth itself. | Tiptap JSON, Plate/Slate state, Lexical state, Yjs document state. | -| Export artifact | A generated package or file derived from the PapiLab model. | Quarto project, Pandoc AST, MyST document, LaTeX/Typst output, Word export, JATS export. | -| Agent runtime log | A replayable history of tool calls, approvals, diffs, errors, checkpoints, and artifacts. | Goose sessions, Codex sessions, OpenCode sessions, PapiLab execution-run records. | +| Export artifact | A generated package or file derived from the Scient model. | Quarto project, Pandoc AST, MyST document, LaTeX/Typst output, Word export, JATS export. | +| Agent runtime log | A replayable history of tool calls, approvals, diffs, errors, checkpoints, and artifacts. | Goose sessions, Codex sessions, OpenCode sessions, Scient execution-run records. | This boundary prevents a common architecture mistake: letting the most convenient tool format quietly become the product truth. -## PapiLab-Owned Core +## Scient-Owned Core These pieces should not be copied from any external project. They are the product itself. -| Core area | What PapiLab must own | Why this cannot be outsourced | +| Core area | What Scient must own | Why this cannot be outsourced | |---|---|---| -| Scientific project graph | Projects, questions, searches, papers, source chunks, claims, evidence links, protocols, datasets, analyses, figures, manuscripts, citations, reviews, agent actions, provenance, exports. | No existing source has the full research lifecycle as one connected object model. This is the thing that makes PapiLab PapiLab. | +| Scientific project graph | Projects, questions, searches, papers, source chunks, claims, evidence links, protocols, datasets, analyses, figures, manuscripts, citations, reviews, agent actions, provenance, exports. | No existing source has the full research lifecycle as one connected object model. This is the thing that makes Scient Scient. | | Evidence model | A claim can link to exact paper regions, extracted values, screening decisions, analyses, and manuscript assertions. | Generic RAG, PDF extraction, and reference managers do not enforce scientific traceability deeply enough. | | Local project contract | A project is a real folder with readable files, local structured state, snapshot/artifact versioning that may be Git-backed, exports, datasets, figures, and logs. | This is the trust and durability spine. It must be designed around scientists, not around a generic coding repo or cloud database. | | Agent work contract | Every meaningful agent change has permissions, logs, diffs, provenance, rollback, and an explanation tied to project evidence. | Coding agents have useful mechanics, but they do not understand scientific accountability by default. | @@ -200,21 +200,21 @@ itself. This map connects the accepted PRD surfaces to the strongest source candidates identified so far. It is a working recommendation, not a final dependency list. -| PRD surface | Best source candidates so far | Current borrow mode | PapiLab-owned boundary | +| PRD surface | Best source candidates so far | Current borrow mode | Scient-owned boundary | |---|---|---|---| -| Project Home | Synara and T3 Code for workbench status, sessions, terminals, branches, diffs, previews, and provider activity; Vercel AI Elements for inspectable agent UI patterns. | Forked workbench prototype and reference. | Project status, stale-output signals, review needs, blocked work, collaborator activity, and next actions belong to PapiLab project state. | -| Scient And Connected-Agent Chat | Synara for the multi-agent workspace shell; the owned OpenCode fork as Scient's source foundation; external OpenCode and other inherited adapters as separate external choices; Goose for later capability and architecture study; Codex for safety and approval reference; Vercel AI SDK for typed model/tool streams. | Forked workbench, owned OpenCode-derived agent, external-agent adapters, and references. | Scient identity, context receipts, permissions, tool scope, proposed changes, durable AgentRun records, checkpoints, and accepted write-back belong to PapiLab. | -| Project Direction And Protocol | protocols.io, SciNote, RSpace, eLabFTW, Chemotion, Kadi4Mat, and openBIS as protocol, ELN, lab workflow, and research-data-management references. | Reference and later adapter candidates. | The project direction, protocol fields, eligibility criteria, analysis plan, and decision log are PapiLab objects. | -| Source Library And Reader | Zotero, Zotero Reader, Zotero Document Worker, Paperlib, Tropy, JabRef, CSL, GROBID, Docling, and local-first note/PDF references such as Logseq and SiYuan. | Adapter, component spike, embedded parser, compatibility target, and reference. | Source identity, duplicate confidence, source-region links, parser state, annotations, backlinks, and citation intent belong to PapiLab. | -| Evidence Ledger And Claims | ASReview for screening mechanics; GROBID and Docling for extraction; PaperQA for cited scientific QA; Lacuna for paper-grounded research-map patterns; Elicit, Rayyan, Covidence, scite, Consensus, and SciSpace as workflow references. | Embedded engines, adapters, and references. | Evidence records, claims, support links, extraction review state, uncertainty, contradictions, and unsupported-claim diagnostics belong to PapiLab. | -| Synthesis Surface | PaperQA for grounded answer mechanics; Lacuna for map-grounded literature search and survey synthesis; Elicit, Consensus, SciSpace, and scite for answer and evidence UX references. | Embedded engine and reference. | Synthesis becomes durable only when saved into PapiLab notes, evidence, claims, decisions, or draft material. | -| Draft And Manuscript Workspace | Tiptap/ProseMirror first; Plate and Lexical as challengers; Zettlr, Overleaf, Word, and Google Docs as academic writing and collaboration references; Quarto/Pandoc/MyST/Manubot for export and publishing paths. | Projection, challenger prototype, reference, and export adapter. | Manuscript structure, citations, evidence links, comments, suggestions, reconciliation state, and publication metadata belong to PapiLab. | -| Data And Analysis Workbench | Python through uv; marimo as reactive-notebook reference; Jupyter/JupyterLab Desktop, RStudio/Positron, and CoCalc as analysis-workbench references; DuckDB, pandas, Polars, Arrow/Parquet, SciPy, statsmodels, scikit-learn, and later R/tidyverse. | Embedded runtime, projection, compatibility target, and reference. | Dataset, Analysis, AnalysisRun, parameters, method notes, outputs, dependency state, staleness, and provenance belong to PapiLab. | -| Figures, Tables, And Artifacts | Matplotlib/seaborn, Plotly, Altair/Vega-Lite, Great Tables/gt, Mermaid, Graphviz, Cytoscape.js, tldraw, Excalidraw, xyflow, Inkscape, diagrams.net, and BioIcons. | Runtime projection, artifact generator, and reference. | Figure, Table, Artifact, caption, data/code linkage, manuscript usage, review state, and stale-output state belong to PapiLab. | -| Agent Runs And Review | Scient's OpenCode-derived source foundation, external OpenCode and other agents, Goose, Codex, Synara, T3 Code, and Vercel AI SDK/Elements. | Owned agent source, external-agent adapters, forked workbench prototype, and references. | AgentRun lifecycle, approvals, diffs, logs, artifacts, failures, retries, cancellation, checkpoints, and recovery belong to PapiLab. | -| Memory, History, And Decisions | Earlier PapiLab prototype patterns, Stencila provenance ideas, Goose/Codex/OpenCode runtime logs, AFFiNE/Logseq/SiYuan knowledge-workspace patterns, and targeted Hermes ideas. | Reference and normalized runtime evidence. | Scientific memory, decision history, trust metadata, provenance, snapshots, rollback, and auditability belong to PapiLab. | -| Collaboration And Mobile Continuation | Yjs/Hocuspocus for document collaboration; Yorkie as challenger; PowerSync/Electric for structured sync candidates; TinyBase, RxDB, and cr-sqlite as secondary references; OSF, Dataverse, GitHub, and GitLab for sharing/deposit expectations. | Candidate engine, adapter, and reference. | Membership, roles, permissions, attribution, conflict state, cloud mirror authority, mobile action scope, and recovery belong to PapiLab. | -| Settings, Integrations, And Export | Zotero/JabRef/CSL, Quarto/Pandoc/MyST, Typst/LaTeX/Overleaf, OSF, Dataverse, GitHub, GitLab, object storage, and cloud-drive style integrations. | Adapter and export target. | Project configuration, integration state, export/deposit records, portability receipts, and fidelity reports belong to PapiLab. | +| Project Home | Synara and T3 Code for workbench status, sessions, terminals, branches, diffs, previews, and provider activity; Vercel AI Elements for inspectable agent UI patterns. | Forked workbench prototype and reference. | Project status, stale-output signals, review needs, blocked work, collaborator activity, and next actions belong to Scient project state. | +| Scient And Connected-Agent Chat | Synara for the multi-agent workspace shell; the owned OpenCode fork as Scient's source foundation; external OpenCode and other inherited adapters as separate external choices; Goose for later capability and architecture study; Codex for safety and approval reference; Vercel AI SDK for typed model/tool streams. | Forked workbench, owned OpenCode-derived agent, external-agent adapters, and references. | Scient identity, context receipts, permissions, tool scope, proposed changes, durable AgentRun records, checkpoints, and accepted write-back belong to Scient. | +| Project Direction And Protocol | protocols.io, SciNote, RSpace, eLabFTW, Chemotion, Kadi4Mat, and openBIS as protocol, ELN, lab workflow, and research-data-management references. | Reference and later adapter candidates. | The project direction, protocol fields, eligibility criteria, analysis plan, and decision log are Scient objects. | +| Source Library And Reader | Zotero, Zotero Reader, Zotero Document Worker, Paperlib, Tropy, JabRef, CSL, GROBID, Docling, and local-first note/PDF references such as Logseq and SiYuan. | Adapter, component spike, embedded parser, compatibility target, and reference. | Source identity, duplicate confidence, source-region links, parser state, annotations, backlinks, and citation intent belong to Scient. | +| Evidence Ledger And Claims | ASReview for screening mechanics; GROBID and Docling for extraction; PaperQA for cited scientific QA; Lacuna for paper-grounded research-map patterns; Elicit, Rayyan, Covidence, scite, Consensus, and SciSpace as workflow references. | Embedded engines, adapters, and references. | Evidence records, claims, support links, extraction review state, uncertainty, contradictions, and unsupported-claim diagnostics belong to Scient. | +| Synthesis Surface | PaperQA for grounded answer mechanics; Lacuna for map-grounded literature search and survey synthesis; Elicit, Consensus, SciSpace, and scite for answer and evidence UX references. | Embedded engine and reference. | Synthesis becomes durable only when saved into Scient notes, evidence, claims, decisions, or draft material. | +| Draft And Manuscript Workspace | Tiptap/ProseMirror first; Plate and Lexical as challengers; Zettlr, Overleaf, Word, and Google Docs as academic writing and collaboration references; Quarto/Pandoc/MyST/Manubot for export and publishing paths. | Projection, challenger prototype, reference, and export adapter. | Manuscript structure, citations, evidence links, comments, suggestions, reconciliation state, and publication metadata belong to Scient. | +| Data And Analysis Workbench | Python through uv; marimo as reactive-notebook reference; Jupyter/JupyterLab Desktop, RStudio/Positron, and CoCalc as analysis-workbench references; DuckDB, pandas, Polars, Arrow/Parquet, SciPy, statsmodels, scikit-learn, and later R/tidyverse. | Embedded runtime, projection, compatibility target, and reference. | Dataset, Analysis, AnalysisRun, parameters, method notes, outputs, dependency state, staleness, and provenance belong to Scient. | +| Figures, Tables, And Artifacts | Matplotlib/seaborn, Plotly, Altair/Vega-Lite, Great Tables/gt, Mermaid, Graphviz, Cytoscape.js, tldraw, Excalidraw, xyflow, Inkscape, diagrams.net, and BioIcons. | Runtime projection, artifact generator, and reference. | Figure, Table, Artifact, caption, data/code linkage, manuscript usage, review state, and stale-output state belong to Scient. | +| Agent Runs And Review | Scient's OpenCode-derived source foundation, external OpenCode and other agents, Goose, Codex, Synara, T3 Code, and Vercel AI SDK/Elements. | Owned agent source, external-agent adapters, forked workbench prototype, and references. | AgentRun lifecycle, approvals, diffs, logs, artifacts, failures, retries, cancellation, checkpoints, and recovery belong to Scient. | +| Memory, History, And Decisions | Earlier PapiLab prototype patterns, Stencila provenance ideas, Goose/Codex/OpenCode runtime logs, AFFiNE/Logseq/SiYuan knowledge-workspace patterns, and targeted Hermes ideas. | Reference and normalized runtime evidence. | Scientific memory, decision history, trust metadata, provenance, snapshots, rollback, and auditability belong to Scient. | +| Collaboration And Mobile Continuation | Yjs/Hocuspocus for document collaboration; Yorkie as challenger; PowerSync/Electric for structured sync candidates; TinyBase, RxDB, and cr-sqlite as secondary references; OSF, Dataverse, GitHub, and GitLab for sharing/deposit expectations. | Candidate engine, adapter, and reference. | Membership, roles, permissions, attribution, conflict state, cloud mirror authority, mobile action scope, and recovery belong to Scient. | +| Settings, Integrations, And Export | Zotero/JabRef/CSL, Quarto/Pandoc/MyST, Typst/LaTeX/Overleaf, OSF, Dataverse, GitHub, GitLab, object storage, and cloud-drive style integrations. | Adapter and export target. | Project configuration, integration state, export/deposit records, portability receipts, and fidelity reports belong to Scient. | ## Source Relationship Classification @@ -222,13 +222,13 @@ This table applies the current adaptation vocabulary to the source set. It is a planning map, not an accepted dependency list by itself. Where a row reflects ADR-0001, that ADR remains the decision authority. -| Source / thing | What PapiLab takes | Relationship mode | Update strategy | +| Source / thing | What Scient takes | Relationship mode | Update strategy | |---|---|---|---| -| PapiLab scientific project graph | Projects, sources, evidence, claims, datasets, runs, figures, manuscripts, memory, provenance. | PapiLab-owned core | `no-upstream` | -| PapiLab agent contract | Permissions, context receipts, proposed changes, review, recovery. | PapiLab-owned core | `no-upstream` | -| Synara | Desktop workbench, chat shell, terminals, diffs, sessions, provider/workflow UI. | Accepted initial application foundation through ADR-0001. Keep changes isolated where useful; allow deliberate divergence when PapiLab owns the surface. | `thin-fork-merge`; move deliberately to `divergent-cherry-pick` if deeply reshaped | +| Scient scientific project graph | Projects, sources, evidence, claims, datasets, runs, figures, manuscripts, memory, provenance. | Scient-owned core | `no-upstream` | +| Scient agent contract | Permissions, context receipts, proposed changes, review, recovery. | Scient-owned core | `no-upstream` | +| Synara | Desktop workbench, chat shell, terminals, diffs, sessions, provider/workflow UI. | Accepted initial application foundation through ADR-0001. Keep changes isolated where useful; allow deliberate divergence when Scient owns the surface. | `thin-fork-merge`; move deliberately to `divergent-cherry-pick` if deeply reshaped | | OpenCode source fork | Local file read/write, shell, code edits, patches, sessions, and possibly subagents as the inherited source foundation for Scient. | Accepted source foundation for Scient through ADR-0001. Inherited core remains internally traceable, but Scient is the owned agent product. External OpenCode remains a separate external adapter path. | `adapter-maintained` initially; allow narrow, identifiable core changes and deliberate divergence for proven Scient needs | -| Goose | Broader local automation, ACP agent/server, recipes, MCP extensions, scheduling, and subagents. | Deferred capability and architecture source for Scient after the first PapiLab gateway. A future external Goose agent would require a separate decision. | `deferred`; later `reference-only`, `adapter-maintained`, or selective adaptation based on evidence | +| Goose | Broader local automation, ACP agent/server, recipes, MCP extensions, scheduling, and subagents. | Deferred capability and architecture source for Scient after the first Scient gateway. A future external Goose agent would require a separate decision. | `deferred`; later `reference-only`, `adapter-maintained`, or selective adaptation based on evidence | | Codex app-server | Sandbox, approvals, diffs, rollback, interrupt/resume ideas. | Reference / cherry-pick source. | `reference-only` | | T3 Code | Backend lifecycle, provider-instance separation, preview/process patterns. | Reference / cherry-pick source. | `reference-only` | | Aider | Git/edit discipline, repo-map and patch workflow lessons. | Reference benchmark. | `reference-only` | @@ -313,13 +313,13 @@ does not set their implementation order; the active sequence lives in | Source | Adaptation target | Why it matters | Do not adopt | Depth status | |---|---|---|---|---| -| Goose | ACP over stdio or authenticated HTTP/WebSocket, persistent sessions, recipes, scheduling, MCP extensions, provider registry, safety inspectors, hooks, and subagents. | Goose is a strong source of broader-agent capabilities and architecture lessons that may later improve Scient. Current ACP supports streaming, permission requests, cancellation, client-provided file/terminal capabilities, and session lifecycle. | Do not make Goose the product center, turn Scient into an engine-switching shell, or make Goose session state canonical. Do not rely on its working directory as a filesystem sandbox: built-in developer tools accept absolute paths, and autonomous mode is the default. | Source-depth review completed at `3c1fdd692`; implementation work is deferred until after the first PapiLab gateway works through Scient. | -| OpenCode | File/shell/edit agent behavior, LSP/code-project operations, snapshots, session protocol, CLI/TUI/server/client split, and plugin/tool architecture. | The owned fork is Scient's source foundation. PapiLab needs these capabilities and intends to own and evolve the resulting agent. | Do not expose Scient as “OpenCode for science,” treat OpenCode as a second engine underneath Scient, or let agent state define the scientific object graph. External OpenCode remains a separate external agent. | Owned-fork build and Synara compatibility smoke completed in historical Gate 1.5 work. ADR-0001 accepts Scient as the owned OpenCode-derived first-party agent; the first vertical slice must implement and validate that identity and boundary. | +| Goose | ACP over stdio or authenticated HTTP/WebSocket, persistent sessions, recipes, scheduling, MCP extensions, provider registry, safety inspectors, hooks, and subagents. | Goose is a strong source of broader-agent capabilities and architecture lessons that may later improve Scient. Current ACP supports streaming, permission requests, cancellation, client-provided file/terminal capabilities, and session lifecycle. | Do not make Goose the product center, turn Scient into an engine-switching shell, or make Goose session state canonical. Do not rely on its working directory as a filesystem sandbox: built-in developer tools accept absolute paths, and autonomous mode is the default. | Source-depth review completed at `3c1fdd692`; implementation work is deferred until after the first Scient gateway works through Scient. | +| OpenCode | File/shell/edit agent behavior, LSP/code-project operations, snapshots, session protocol, CLI/TUI/server/client split, and plugin/tool architecture. | The owned fork is Scient's source foundation. Scient needs these capabilities and intends to own and evolve the resulting agent. | Do not expose Scient as “OpenCode for science,” treat OpenCode as a second engine underneath Scient, or let agent state define the scientific object graph. External OpenCode remains a separate external agent. | Owned-fork build and Synara compatibility smoke completed in historical Gate 1.5 work. ADR-0001 accepts Scient as the owned OpenCode-derived first-party agent; the first vertical slice must implement and validate that identity and boundary. | | Codex app-server | Approval protocol, sandbox model, diff flow, interrupt/rollback/session protocol, file API, skills/MCP, Rust daemon boundary. | Useful comparator for what a trusted local executor and approval model can feel like. | Do not depend on Codex-specific assumptions as the only runtime path. | Needs direct harness comparison against OpenCode. | | Aider | Git-centered edit discipline, repo maps, patch workflow, simple terminal ergonomics. | Useful as a benchmark for file changes and rollback, even if not the main architecture. | Do not make the app Python-first or terminal-first because Aider is good. | Side benchmark, not primary source. | Recommendation: build Scient from the owned OpenCode source foundation and -defer Goose work until the PapiLab gateway works through Scient. Use a bounded +defer Goose work until the Scient gateway works through Scient. Use a bounded `goose acp` comparison later when it helps evaluate capabilities or architecture; do not use that experiment to redefine Scient as an engine-switching shell. The old `goosed` REST surface was removed upstream, and authenticated `goose serve` @@ -330,42 +330,42 @@ is relevant only to a separately reviewed process or external-agent path. | Source | Adaptation target | Why it matters | Do not adopt | Depth status | |---|---|---|---|---| | T3 Code | Desktop/backend process lifecycle, provider-instance patterns, remote/SSH/Tailscale ideas if needed, multi-surface product structure. | Gives practical patterns for a desktop agent app that coordinates backends and providers. | Do not inherit coding-product assumptions. | Needs targeted review of provider-instance and process lifecycle code. | -| Synara | Orchestration, UI/provider adapters, Effect server ideas, event-sourced orchestration, desktop/web split, worktree/Git flows. | Useful for building a reliable agent workspace that can explain what happened. | Do not copy its UI shape blindly; PapiLab needs a research cockpit. | Accepted initial application foundation through ADR-0001; scientific-product fit still needs pressure testing. | -| Vercel AI SDK | Model/provider abstraction, typed stream parts, tool-call state, approval status, UI message events, mock providers, and model I/O tests. | Useful for model plumbing and chat/event surfaces around PapiLab-owned actions. | Do not use it as the abstraction over local executors like OpenCode or Codex. Executor actions need a PapiLab-owned contract. | Candidate model I/O layer; needs a narrow harness prototype. | -| Vercel AI Elements | Tool cards, source citations, confirmations, terminal output, file trees, artifacts, plans, queue state. | Useful UI pieces for agent work inspection. | Do not let it make PapiLab a generic chat surface. | Side UI pattern source. | +| Synara | Orchestration, UI/provider adapters, Effect server ideas, event-sourced orchestration, desktop/web split, worktree/Git flows. | Useful for building a reliable agent workspace that can explain what happened. | Do not copy its UI shape blindly; Scient needs a research cockpit. | Accepted initial application foundation through ADR-0001; scientific-product fit still needs pressure testing. | +| Vercel AI SDK | Model/provider abstraction, typed stream parts, tool-call state, approval status, UI message events, mock providers, and model I/O tests. | Useful for model plumbing and chat/event surfaces around Scient-owned actions. | Do not use it as the abstraction over local executors like OpenCode or Codex. Executor actions need a Scient-owned contract. | Candidate model I/O layer; needs a narrow harness prototype. | +| Vercel AI Elements | Tool cards, source citations, confirmations, terminal output, file trees, artifacts, plans, queue state. | Useful UI pieces for agent work inspection. | Do not let it make Scient a generic chat surface. | Side UI pattern source. | Recommendation: adapt shell/process/provider ideas from T3 Code and Synara, but -keep the scientific navigation and object model PapiLab-owned. +keep the scientific navigation and object model Scient-owned. ### Desktop Base And Science-App Candidates The 2026-07-07 desktop/science-app scan did not find a better first desktop base than Synara. The science apps are still valuable, but mostly as specialized source-library, reader, writing, analysis, protocol, and research-object -references around a PapiLab-owned project kernel. +references around a Scient-owned project kernel. | Source | Adaptation target | Why it matters | Do not adopt | Current use | |---|---|---|---|---| -| Synara | Initial desktop application foundation: chat, provider sessions, terminals, previews, diffs, local process/workspace flow. | It already concentrates the workbench machinery PapiLab would otherwise have to build before testing the scientific workflow. | Do not let Synara's coding sessions, Git worktrees, or provider chats become the PapiLab project model. | Accepted through ADR-0001; the first scientific slice must validate product fit and identify justified divergence. | -| Zotero | Reference manager compatibility, library import/export, source identity, citations, PDF/annotation expectations. | Researchers already trust Zotero, and PapiLab cannot treat source/citation work as an afterthought. | Do not fork the full Zotero desktop app or rebuild Zotero first. | Adapter and compatibility target. | -| Zotero Reader / Zotero Document Worker | PDF/EPUB/HTML reading, annotations, source-region navigation, annotation processing, text extraction and rendering. | Source-region fidelity is central to PapiLab's evidence model; these components are closer to the needed reader/parser behavior than generic PDF viewers. | Do not make Zotero's reader or worker state canonical PapiLab state. | Component spike and reference after source-depth/license review. | -| Paperlib | Modern paper-library UI, metadata scraping, full-text search, paper notes, LLM paper features, writing integration. | It is a good challenge to older reference-manager UX and is close to "paper library for active writing." | Do not make PapiLab only a paper manager or copy GPL code without review. | Reference and possible adapter ideas. | -| Tropy | Research-source object modeling, custom metadata templates, annotation/transcription UX, SQLite, plugins, export. | It thinks in research objects rather than only files, which is useful for source detail surfaces. | Do not turn PapiLab into a photo/archive manager. | Reference for source/detail metadata UX. | +| Synara | Initial desktop application foundation: chat, provider sessions, terminals, previews, diffs, local process/workspace flow. | It already concentrates the workbench machinery Scient would otherwise have to build before testing the scientific workflow. | Do not let Synara's coding sessions, Git worktrees, or provider chats become the Scient project model. | Accepted through ADR-0001; the first scientific slice must validate product fit and identify justified divergence. | +| Zotero | Reference manager compatibility, library import/export, source identity, citations, PDF/annotation expectations. | Researchers already trust Zotero, and Scient cannot treat source/citation work as an afterthought. | Do not fork the full Zotero desktop app or rebuild Zotero first. | Adapter and compatibility target. | +| Zotero Reader / Zotero Document Worker | PDF/EPUB/HTML reading, annotations, source-region navigation, annotation processing, text extraction and rendering. | Source-region fidelity is central to Scient's evidence model; these components are closer to the needed reader/parser behavior than generic PDF viewers. | Do not make Zotero's reader or worker state canonical Scient state. | Component spike and reference after source-depth/license review. | +| Paperlib | Modern paper-library UI, metadata scraping, full-text search, paper notes, LLM paper features, writing integration. | It is a good challenge to older reference-manager UX and is close to "paper library for active writing." | Do not make Scient only a paper manager or copy GPL code without review. | Reference and possible adapter ideas. | +| Tropy | Research-source object modeling, custom metadata templates, annotation/transcription UX, SQLite, plugins, export. | It thinks in research objects rather than only files, which is useful for source detail surfaces. | Do not turn Scient into a photo/archive manager. | Reference for source/detail metadata UX. | | Zettlr | Local academic writing, citation workflows, Pandoc export, Markdown/math/Mermaid rendering, journal submission profiles. | It shows how a local-first academic writing surface can stay file-oriented and export-friendly. | Do not make raw Markdown the only authoring UX. | Reference and export/workflow benchmark. | | Overleaf | Collaborative LaTeX, templates, compile logs, academic expectations. | It remains the academic writing benchmark for LaTeX-heavy users. | Do not fork it as the desktop base; it is server/web-shaped and LaTeX-first. | Reference, compatibility target, export target. | -| JupyterLab Desktop | Notebook opening, file/session behavior, notebook compatibility. | Useful for analysis compatibility and desktop analysis expectations. | Do not base PapiLab on it; maintenance/security posture must be rechecked before any dependency. | Reference only. | -| Stencila | Scientific document schemas, executable-document and provenance ideas, LLM-aware document direction. | It is one of the few science-native systems thinking seriously about semantic documents plus agent/LLM authorship. | Do not adopt its schema as PapiLab truth without an ADR. | Deep reference. | +| JupyterLab Desktop | Notebook opening, file/session behavior, notebook compatibility. | Useful for analysis compatibility and desktop analysis expectations. | Do not base Scient on it; maintenance/security posture must be rechecked before any dependency. | Reference only. | +| Stencila | Scientific document schemas, executable-document and provenance ideas, LLM-aware document direction. | It is one of the few science-native systems thinking seriously about semantic documents plus agent/LLM authorship. | Do not adopt its schema as Scient truth without an ADR. | Deep reference. | | eLabFTW / SciNote / RSpace / Chemotion / Kadi4Mat / openBIS | ELN, protocol, inventory, FAIR/RDM, repository, audit, and lab workflow expectations. | These show what scientific-traceability and institutional research-data workflows require outside pure literature review. | Do not become a wet-lab ELN or RDM platform before proving the project graph. | Deferred reference and later adapters. | -| AFFiNE / Logseq / SiYuan | Local-first docs, canvas, backlinks, block references, PDF annotation links, knowledge graph and note workflows. | Useful for manual researcher workspace behavior: notes, backlinks, object links, canvas/planning, and local ownership. | Do not make PapiLab a generic PKM or Notion clone. | Reference only. | -| CoCalc | Jupyter, LaTeX, terminal, whiteboard, chat, real-time collaboration, scientific teaching/research workspace. | It proves the value of combining computation, writing, terminal, and collaboration in one scientific environment. | Do not fork or run from source as a base; MS-RSL source licensing makes it reference-only for PapiLab. | Reference only. | +| AFFiNE / Logseq / SiYuan | Local-first docs, canvas, backlinks, block references, PDF annotation links, knowledge graph and note workflows. | Useful for manual researcher workspace behavior: notes, backlinks, object links, canvas/planning, and local ownership. | Do not make Scient a generic PKM or Notion clone. | Reference only. | +| CoCalc | Jupyter, LaTeX, terminal, whiteboard, chat, real-time collaboration, scientific teaching/research workspace. | It proves the value of combining computation, writing, terminal, and collaboration in one scientific environment. | Do not fork or run from source as a base; MS-RSL source licensing makes it reference-only for Scient. | Reference only. | Recommendation: begin by stabilizing a Synara fork as the workbench shell, then immediately pressure-test it with science surfaces: import a paper, view and annotate source material, create an evidence-linked note or draft paragraph, delegate one agent task, and review the resulting project change. If Synara -cannot host that without forcing coding-product assumptions into PapiLab's +cannot host that without forcing coding-product assumptions into Scient's kernel, keep its useful pieces as cherry-pick/reference material and move toward -a more PapiLab-owned shell. +a more Scient-owned shell. Source and reference links checked for this scan: @@ -411,13 +411,13 @@ Source and reference links checked for this scan: |---|---|---|---|---| | Hermes | Checkpointing ideas, relay-auth patterns to verify, slash-command authorization ideas, and context-compression patterns. | Useful as a side-bench for selected safety and continuity mechanics. | Do not let Hermes materially shape the scientific memory/provenance architecture, and do not use it as the primary file-writing executor. | Targeted side review only. | | Goose | Safety inspectors, provider registry, recipe/session boundaries. | Useful for local agent safety and repeatable task recipes. | Do not make recipes replace scientific skills/protocols. | Needs deeper review. | -| OpenClaw | Gateway, channels, diagnostics, onboarding, app/device continuation, plugin distribution, safe media store ideas, SSRF guards, prompt-injection-safe file context. | Useful when PapiLab grows beyond desktop into cloud/mobile/channel continuity and needs hardened external input handling. | Do not make PapiLab a personal messaging assistant or center the product on chat/voice sessions. | Side-to-core later; security-specific ideas deserve targeted review. | -| AFFiNE | Local-first docs/canvas/table workspace, block composition, whiteboard/document fusion, collaboration posture. | Useful as a reference for manual planning, visual thinking, and mixed document/canvas work inside a project. | Do not make PapiLab a generic Notion/Miro alternative. | Reference only. | -| Logseq | Local-first knowledge graph, Markdown/Org storage, backlinks, PDF annotation, task and note workflows. | Useful for backlinking, annotation-to-note behavior, and researcher-owned local knowledge. | Do not make PapiLab a generic PKM graph. | Reference only. | -| SiYuan | Block-level references, Markdown WYSIWYG, PDF annotation links, export formats, local/self-hosted architecture. | Useful for block references, local note UX, and fine-grained object linking. | Do not adopt its block model as PapiLab's scientific object model. | Reference only. | +| OpenClaw | Gateway, channels, diagnostics, onboarding, app/device continuation, plugin distribution, safe media store ideas, SSRF guards, prompt-injection-safe file context. | Useful when Scient grows beyond desktop into cloud/mobile/channel continuity and needs hardened external input handling. | Do not make Scient a personal messaging assistant or center the product on chat/voice sessions. | Side-to-core later; security-specific ideas deserve targeted review. | +| AFFiNE | Local-first docs/canvas/table workspace, block composition, whiteboard/document fusion, collaboration posture. | Useful as a reference for manual planning, visual thinking, and mixed document/canvas work inside a project. | Do not make Scient a generic Notion/Miro alternative. | Reference only. | +| Logseq | Local-first knowledge graph, Markdown/Org storage, backlinks, PDF annotation, task and note workflows. | Useful for backlinking, annotation-to-note behavior, and researcher-owned local knowledge. | Do not make Scient a generic PKM graph. | Reference only. | +| SiYuan | Block-level references, Markdown WYSIWYG, PDF annotation links, export formats, local/self-hosted architecture. | Useful for block references, local note UX, and fine-grained object linking. | Do not adopt its block model as Scient's scientific object model. | Reference only. | | Earlier PapiLab prototype | Memory trust metadata, memory UI, durable agent runs, checkpoints, autonomy controls, idempotency records. | Earlier product work has valuable reliability patterns that should not be discarded. | Do not copy an older hosted persistence shape if the next product is local-first. | High value; already inventoried. | -Recommendation: build a PapiLab memory/provenance layer using earlier prototype +Recommendation: build a Scient memory/provenance layer using earlier prototype typed run/memory concepts, Goose/Codex action/session metadata, Stencila-style provenance concepts, and only small targeted Hermes ideas where they survive source review. @@ -430,7 +430,7 @@ source review. | Plate | AI-rich editor patterns, comments, diff/suggestion UX, docx import/export, polished component patterns. | It may be an important source for the writing experience, even if not the final editor base. | Do not assume Slate/Plate wins without long-manuscript and collaboration tests. | Must prototype against Tiptap. | | Lexical | Performance, accessibility, headless editor architecture, Word/HTML import lessons. | Serious fallback if Tiptap/Plate struggle with long scientific documents. | More DIY for scientific features. | Challenger prototype. | | Overleaf | Academic writing workflow, LaTeX project model, compile logs, templates, collaboration expectations. | Scientists know it; it teaches submission and LaTeX workflows. | Do not fork Overleaf or become LaTeX-first. | Reference only unless export integration. | -| Word / Google Docs | Track changes, comments, collaborative writing expectations, non-technical manuscript UX. | Many scientists live here. Export/import must respect their workflows. | Do not make PapiLab generic office software. | Product reference. | +| Word / Google Docs | Track changes, comments, collaborative writing expectations, non-technical manuscript UX. | Many scientists live here. Export/import must respect their workflows. | Do not make Scient generic office software. | Product reference. | Recommendation: use Tiptap first, prototype Plate and Lexical against the same scientific document, and keep Overleaf/Word/Google Docs as UX and export @@ -440,10 +440,10 @@ benchmarks. | Source | Adaptation target | Why it matters | Do not adopt | Depth status | |---|---|---|---|---| -| Zotero | Import/export, translators, PDF reader/annotations, collections, tags, citation insertion, CSL, group-library expectations. | Zotero is the reference manager scientists already trust. PapiLab must cooperate with it. | Do not rebuild Zotero first or fork the full Zotero product. | Core integration and compatibility target. | -| Zotero Reader / Zotero Document Worker | PDF/EPUB/HTML reader and annotator; annotation processing; PDF text extraction and rendering; structured extraction from PDFs, EPUBs, and HTML snapshots. | This is the strongest current component/reference candidate for PapiLab's source reader and source-region workflows. | Do not make the reader's annotation state or worker output the canonical evidence model. | Component spike; source-depth and license review needed. | +| Zotero | Import/export, translators, PDF reader/annotations, collections, tags, citation insertion, CSL, group-library expectations. | Zotero is the reference manager scientists already trust. Scient must cooperate with it. | Do not rebuild Zotero first or fork the full Zotero product. | Core integration and compatibility target. | +| Zotero Reader / Zotero Document Worker | PDF/EPUB/HTML reader and annotator; annotation processing; PDF text extraction and rendering; structured extraction from PDFs, EPUBs, and HTML snapshots. | This is the strongest current component/reference candidate for Scient's source reader and source-region workflows. | Do not make the reader's annotation state or worker output the canonical evidence model. | Component spike; source-depth and license review needed. | | Paperlib | Modern paper-library UI, metadata scraping, full-text search, notes, RSS discovery, writing integration, LLM paper features. | Useful pressure test against older reference-manager UX, especially for active paper writing. | Do not use it as the base product or copy GPL code without review. | Reference and possible adapter ideas. | -| Tropy | Research-source item modeling, custom metadata templates, annotation/transcription, SQLite persistence, plugins, JSON-LD/CSV export. | Useful for source-detail UX and the idea that research materials are objects with researcher-defined metadata, not just files. | Do not make PapiLab an archive-photo manager. | Reference for source/detail surfaces. | +| Tropy | Research-source item modeling, custom metadata templates, annotation/transcription, SQLite persistence, plugins, JSON-LD/CSV export. | Useful for source-detail UX and the idea that research materials are objects with researcher-defined metadata, not just files. | Do not make Scient an archive-photo manager. | Reference for source/detail surfaces. | | JabRef | BibTeX/BibLaTeX correctness, citation keys, local `.bib` durability, PDF metadata writing, citation relation views. | Important candidate for open local citation correctness. | Do not inherit Java desktop product shape. | Candidate citation reference; needs source evaluation. | | CSL ecosystem | Citation styles, bibliography generation conventions. | Required for real manuscript output. | Do not invent a private citation style system. | Required integration. | | Paperpile / Mendeley / EndNote / ReadCube | User expectations for reference workflows, institutional habits, Google Docs/Word integration patterns. | Scientists will import from or compare to these. | Do not build around proprietary assumptions. | Side reference. | @@ -457,27 +457,27 @@ and Tropy as pressure tests for modern source-library and source-detail UX. | Source | Adaptation target | Why it matters | Do not adopt | Depth status | |---|---|---|---|---| -| GROBID | Scholarly PDF extraction, TEI output, references, citation contexts, figures, tables, affiliations, PDF coordinates. | Leading scholarly parser candidate. Coordinates are critical for evidence traceability. | Do not make TEI the whole PapiLab object model. | Sidecar candidate. | -| Docling | Multi-format conversion result boundary: PDF, Word, PowerPoint, HTML, image, LaTeX, Markdown, JATS, XML, tables, page/item provenance, confidence/errors/timings, document pipelines. | PapiLab will ingest more than scholarly PDFs, and ingestion must expose what was converted, where it came from, how confident it is, and what failed. | Do not rely on it alone for scholarly references until benchmarked, and do not let Docling's internal result format become canonical PapiLab state. | Sidecar candidate. | +| GROBID | Scholarly PDF extraction, TEI output, references, citation contexts, figures, tables, affiliations, PDF coordinates. | Leading scholarly parser candidate. Coordinates are critical for evidence traceability. | Do not make TEI the whole Scient object model. | Sidecar candidate. | +| Docling | Multi-format conversion result boundary: PDF, Word, PowerPoint, HTML, image, LaTeX, Markdown, JATS, XML, tables, page/item provenance, confidence/errors/timings, document pipelines. | Scient will ingest more than scholarly PDFs, and ingestion must expose what was converted, where it came from, how confident it is, and what failed. | Do not rely on it alone for scholarly references until benchmarked, and do not let Docling's internal result format become canonical Scient state. | Sidecar candidate. | | Marker | PDF-to-Markdown benchmark. | Useful for readable agent input and fallback extraction. | Do not choose it without corpus benchmark. | Side benchmark. | | Earlier PapiLab extraction work | Existing PDF/metadata processing, artifact review, extraction confidence/failure handling. | There is previous product flow worth preserving. | Do not assume previous extraction quality is good enough for the next architecture. | Keep the flow, benchmark the engine. | Recommendation: use GROBID and Docling together. GROBID for scholarly structure; -Docling for general document conversion. PapiLab should own the evidence graph +Docling for general document conversion. Scient should own the evidence graph above both. ### Scientific QA, RAG, And Evidence Answers | Source | Adaptation target | Why it matters | Do not adopt | Depth status | |---|---|---|---|---| -| PaperQA | `Doc` / `Text` / `Context` split, citation-grounded scientific QA, cited context provenance, paper-directory indexing, clients for Crossref/OpenAlex/Semantic Scholar/Unpaywall/retractions. | Important open-source scientific RAG candidate, and its source/context split is useful for PapiLab evidence linking. | Do not treat RAG output as truth without evidence objects and review. Do not use PaperQA persistence as canonical project state. | Sidecar/reference candidate. | -| Lacuna | Research-map substrate for paper search, source-linked concept elements, research directions, cleaned markdown pages, and multi-stage deep-research synthesis. | Strong reference for search and synthesis over durable intermediate objects rather than raw PDFs or one-off chat. | Do not make Lacuna's generated map, directions, or proposals the PapiLab project graph. Do not treat generated directions as truth without source review. | Research-map reference; inspected arXiv and live site on 2026-07-09. | +| PaperQA | `Doc` / `Text` / `Context` split, citation-grounded scientific QA, cited context provenance, paper-directory indexing, clients for Crossref/OpenAlex/Semantic Scholar/Unpaywall/retractions. | Important open-source scientific RAG candidate, and its source/context split is useful for Scient evidence linking. | Do not treat RAG output as truth without evidence objects and review. Do not use PaperQA persistence as canonical project state. | Sidecar/reference candidate. | +| Lacuna | Research-map substrate for paper search, source-linked concept elements, research directions, cleaned markdown pages, and multi-stage deep-research synthesis. | Strong reference for search and synthesis over durable intermediate objects rather than raw PDFs or one-off chat. | Do not make Lacuna's generated map, directions, or proposals the Scient project graph. Do not treat generated directions as truth without source review. | Research-map reference; inspected arXiv and live site on 2026-07-09. | | Elicit | Evidence tables, structured reports, extraction and screening UX, sentence-level citations. | Best commercial benchmark for AI literature workflows. | Do not become a cloud-only Elicit clone. | Product reference. | | Consensus / SciSpace / scite | Claim synthesis, paper Q&A, citation context, support/contrast/mention framing. | Useful for answer UX and evidence relationship semantics. | Do not accept black-box synthesis without inspectable sources. | Side reference. | Recommendation: PaperQA can inspire the local answer engine, while Lacuna is a strong reference for the research-map layer that makes literature search and -survey synthesis navigable for agents. PapiLab must still make every accepted +survey synthesis navigable for agents. Scient must still make every accepted answer, direction, or synthesis land in project evidence objects, not just chat text or generated map pages. @@ -485,14 +485,14 @@ text or generated map pages. | Source | Adaptation target | Why it matters | Do not adopt | Depth status | |---|---|---|---|---| -| ASReview | Project directory persistence, screening decision DB, active-learning loop, project schema, simulation, model components, screening queues. | Leading open-source screening engine candidate, with useful boundaries between review data, decisions, and model-driven prioritization. | Do not let the model silently decide inclusion/exclusion. Do not use ASReview's DB/web stack as canonical PapiLab state. | Source candidate. | +| ASReview | Project directory persistence, screening decision DB, active-learning loop, project schema, simulation, model components, screening queues. | Leading open-source screening engine candidate, with useful boundaries between review data, decisions, and model-driven prioritization. | Do not let the model silently decide inclusion/exclusion. Do not use ASReview's DB/web stack as canonical Scient state. | Source candidate. | | Rayyan | Screening UX, collaboration, inclusion/exclusion reasons, PRISMA-like review operations. | Strong product benchmark for systematic review teams. | Do not copy SaaS-only workflow assumptions. | Product reference. | | Covidence / DistillerSR / EPPI-Reviewer / RevMan / JBI SUMARI | Institutional review workflows, risk of bias, extraction, compliance expectations. | These define what evidence teams expect. | Do not treat enterprise workflows as day-one scope. | Side reference. | -| protocols.io | Protocol authoring/execution, versionable methods, public method-sharing expectations. | Useful for protocol objects beyond literature reviews. | Do not make external protocol repositories the PapiLab project record. | Reference and later compatibility target. | +| protocols.io | Protocol authoring/execution, versionable methods, public method-sharing expectations. | Useful for protocol objects beyond literature reviews. | Do not make external protocol repositories the Scient project record. | Reference and later compatibility target. | | eLabFTW | Experiments, protocols, inventories/resources, advanced permissions, audit/signature expectations, REST API, `.eln` ecosystem awareness. | Useful for lab and institutional traceability expectations. | Do not become a full ELN or inventory/LIMS product before the project graph works. | Deferred reference and later adapter. | | SciNote | Life-science ELN workflows and experimental data organization. | Useful for understanding life-science user expectations and ELN workflow vocabulary. | Do not inherit Rails/Docker/web-server product shape. | Deferred reference. | -| RSpace | Research orchestrator/ELN/sample management, FAIR workflow, PIDs, repository and tool integrations. | Useful for how research infrastructure connects notebooks, samples, repositories, and institutional workflows. | Do not make PapiLab an institutional RDM suite first. | Deferred reference and later adapter. | -| Chemotion / Kadi4Mat / openBIS | Domain-specific ELN/RDM workflows for chemistry, materials science, FAIR data, instrument/workflow linkage, repositories. | Useful when PapiLab needs domain-aware protocol/data extensions. | Do not pull domain-specific ELN complexity into the first product core. | Deferred domain reference. | +| RSpace | Research orchestrator/ELN/sample management, FAIR workflow, PIDs, repository and tool integrations. | Useful for how research infrastructure connects notebooks, samples, repositories, and institutional workflows. | Do not make Scient an institutional RDM suite first. | Deferred reference and later adapter. | +| Chemotion / Kadi4Mat / openBIS | Domain-specific ELN/RDM workflows for chemistry, materials science, FAIR data, instrument/workflow linkage, repositories. | Useful when Scient needs domain-aware protocol/data extensions. | Do not pull domain-specific ELN complexity into the first product core. | Deferred domain reference. | Recommendation: build protocol and screening as first-class objects early. ASReview is the main open-source source; Rayyan/Covidence/etc. are UX and @@ -502,13 +502,13 @@ workflow references. | Source | Adaptation target | Why it matters | Do not adopt | Depth status | |---|---|---|---|---| -| Zettlr | Local academic writing, citation integration, Markdown/math/Mermaid rendering, Pandoc export profiles, journal/conference submission workflows. | Useful as a local-first academic writing benchmark that is closer to researchers than a generic Markdown app. | Do not make PapiLab a Markdown-only writing tool or treat file text as the only manuscript truth. | Reference and export workflow benchmark. | -| Quarto / Pandoc | Multi-format scientific publishing, citations, crossrefs, executable docs, Word/PDF/HTML/Typst/LaTeX paths, document schemas, defaults/templates/filters, export artifact DAG ideas. | Primary pragmatic export lane to test first. | Do not force users to author raw Quarto if the UX should be Google Docs-like. Do not make Quarto internals or Pandoc AST the PapiLab core. | Primary export prototype. | +| Zettlr | Local academic writing, citation integration, Markdown/math/Mermaid rendering, Pandoc export profiles, journal/conference submission workflows. | Useful as a local-first academic writing benchmark that is closer to researchers than a generic Markdown app. | Do not make Scient a Markdown-only writing tool or treat file text as the only manuscript truth. | Reference and export workflow benchmark. | +| Quarto / Pandoc | Multi-format scientific publishing, citations, crossrefs, executable docs, Word/PDF/HTML/Typst/LaTeX paths, document schemas, defaults/templates/filters, export artifact DAG ideas. | Primary pragmatic export lane to test first. | Do not force users to author raw Quarto if the UX should be Google Docs-like. Do not make Quarto internals or Pandoc AST the Scient core. | Primary export prototype. | | MyST | Scientific Markdown, JATS, citations, crossrefs, TeX/Typst export, notebook publishing. | Credible source-format and publishing challenger to Quarto/Pandoc. | Do not make source Markdown the only UX. Do not promote it before export needs are benchmarked. | Challenger export/source-format prototype. | | Manubot | Git-backed automated manuscript pipeline. | Useful for reproducible manuscript build ideas. | Not a live scientific editor. | Side reference. | | Typst / LaTeX / Overleaf | Final typesetting and academic submission expectations. | Export credibility depends on them. | Do not become typesetting-first. | Export target/reference. | -Recommendation: keep PapiLab's internal manuscript model separate from export +Recommendation: keep Scient's internal manuscript model separate from export formats. Prototype Quarto/Pandoc first, keep MyST as the challenger, and export to Word/PDF/HTML/LaTeX/Typst where feasible rather than making any one format the product core too early. @@ -517,33 +517,33 @@ the product core too early. | Source | Adaptation target | Why it matters | Do not adopt | Depth status | |---|---|---|---|---| -| Stencila | Semantic scientific document schemas, executable/provenance-aware documents, agent actions, figure workflows, and structured document-object ideas. | Valuable as a science-native schema and provenance reference for PapiLab's own document and evidence model. | Do not adopt the whole product, and do not let Stencila schemas replace the canonical PapiLab model without a deliberate architecture decision. | Deep source evaluation required. | +| Stencila | Semantic scientific document schemas, executable/provenance-aware documents, agent actions, figure workflows, and structured document-object ideas. | Valuable as a science-native schema and provenance reference for Scient's own document and evidence model. | Do not adopt the whole product, and do not let Stencila schemas replace the canonical Scient model without a deliberate architecture decision. | Deep source evaluation required. | Recommendation: study Stencila for semantic document and provenance ideas, not as an export engine peer. Any Stencila-inspired shape must be translated into -PapiLab-owned objects before it can become project truth. +Scient-owned objects before it can become project truth. ### Data, Code, Analysis, Figures, And Scientific Artifacts | Source | Adaptation target | Why it matters | Do not adopt | Depth status | |---|---|---|---|---| -| marimo | Reactive Python analysis objects, dependency DAG, stale propagation, SQL cells, app/script duality, Git-friendly notebooks, AI-native data work. | Best current analysis-workbench inspiration for PapiLab because an agent can write real Python while the UI can expose dependency state and stale outputs. | Do not make PapiLab a notebook app. Do not let marimo runtime state become the canonical `Analysis` object. | Primary analysis-workbench prototype candidate; official-doc scan done, code/license/prototype still needed. | -| JupyterLab / `.ipynb` | Kernel ecosystem, notebook import/export, notebook compatibility, scientist familiarity, extension expectations. | Researchers already have notebook projects, and many collaborators will expect notebook continuation. | Do not embed the whole JupyterLab UI as the PapiLab workspace, and do not make hidden notebook state the analysis truth. | Compatibility target, not product core. | -| JupyterLab Desktop | Notebook/file/session desktop behavior and one-click notebook opening expectations. | Useful for understanding scientist expectations around local notebook workflows in a desktop shell. | Do not use it as PapiLab's base desktop app; maintenance/security status must be rechecked before any dependency. | Reference only. | +| marimo | Reactive Python analysis objects, dependency DAG, stale propagation, SQL cells, app/script duality, Git-friendly notebooks, AI-native data work. | Best current analysis-workbench inspiration for Scient because an agent can write real Python while the UI can expose dependency state and stale outputs. | Do not make Scient a notebook app. Do not let marimo runtime state become the canonical `Analysis` object. | Primary analysis-workbench prototype candidate; official-doc scan done, code/license/prototype still needed. | +| JupyterLab / `.ipynb` | Kernel ecosystem, notebook import/export, notebook compatibility, scientist familiarity, extension expectations. | Researchers already have notebook projects, and many collaborators will expect notebook continuation. | Do not embed the whole JupyterLab UI as the Scient workspace, and do not make hidden notebook state the analysis truth. | Compatibility target, not product core. | +| JupyterLab Desktop | Notebook/file/session desktop behavior and one-click notebook opening expectations. | Useful for understanding scientist expectations around local notebook workflows in a desktop shell. | Do not use it as Scient's base desktop app; maintenance/security status must be rechecked before any dependency. | Reference only. | | RStudio / Positron | Data-science IDE layout, variables/data viewers, plots, Quarto/R Markdown workflows, AI/data assistant expectations. | Useful for researchers who think in R/Python analysis workspaces rather than coding-agent workspaces. | Do not fork a data-science IDE as the first shell. | Reference and compatibility expectation. | | CoCalc | Combined Jupyter, LaTeX, terminal, chat, whiteboard, time-travel, and scientific collaboration. | It demonstrates the value of a multi-surface scientific workbench. | Do not fork or run its source as a base; treat it as reference-only because of MS-RSL source licensing. | Reference only. | -| DuckDB | Embedded analytical SQL over local files and local project data. | Strong fit for local-first analysis: agents can query CSV/Parquet/Arrow-style data without requiring a cloud warehouse or server database. | Do not make DuckDB the project database or provenance model. It is an execution/query engine under PapiLab objects. | Add as primary local analysis engine candidate. | -| pandas / Polars | DataFrame manipulation, cleaning, joins, reshaping, exploration, lazy/eager tabular pipelines. | pandas is still the compatibility language of scientific Python; Polars is attractive for performant, lazy, agent-written pipelines over larger local data. | Do not expose library choice as the user-facing model. PapiLab should record datasets, transforms, runs, tables, and figures above the DataFrame library. | Add as initial Python data runtime set: pandas for compatibility, Polars for performance. | -| Apache Arrow / Parquet | Columnar interchange and artifact formats between Python, SQL engines, cloud, and exported datasets. | PapiLab needs durable, efficient data artifacts that can move between analysis engines and remain inspectable outside the app. | Do not make low-level columnar formats visible as the product model for normal users. | Add as preferred data interchange/artifact direction. | -| Ibis | Portable query/DataFrame expression layer across local and remote backends. | Could let PapiLab start local with DuckDB and later run similar analysis code against cloud or institutional backends. | Do not add before a real portability need appears; it can obscure the simple pandas/Polars/DuckDB story. | Later candidate after the first local analysis prototype. | -| SciPy / statsmodels / scikit-learn | Scientific algorithms, statistical modeling, hypothesis tests, predictive modeling, reusable method skills. | PapiLab agents will need a trusted baseline for common scientific/statistical tasks, not only generic Python execution. | Do not become a statistics package GUI first, and do not let agents present model output without method notes, assumptions, parameters, and provenance. | Add as core scientific Python runtime references. | +| DuckDB | Embedded analytical SQL over local files and local project data. | Strong fit for local-first analysis: agents can query CSV/Parquet/Arrow-style data without requiring a cloud warehouse or server database. | Do not make DuckDB the project database or provenance model. It is an execution/query engine under Scient objects. | Add as primary local analysis engine candidate. | +| pandas / Polars | DataFrame manipulation, cleaning, joins, reshaping, exploration, lazy/eager tabular pipelines. | pandas is still the compatibility language of scientific Python; Polars is attractive for performant, lazy, agent-written pipelines over larger local data. | Do not expose library choice as the user-facing model. Scient should record datasets, transforms, runs, tables, and figures above the DataFrame library. | Add as initial Python data runtime set: pandas for compatibility, Polars for performance. | +| Apache Arrow / Parquet | Columnar interchange and artifact formats between Python, SQL engines, cloud, and exported datasets. | Scient needs durable, efficient data artifacts that can move between analysis engines and remain inspectable outside the app. | Do not make low-level columnar formats visible as the product model for normal users. | Add as preferred data interchange/artifact direction. | +| Ibis | Portable query/DataFrame expression layer across local and remote backends. | Could let Scient start local with DuckDB and later run similar analysis code against cloud or institutional backends. | Do not add before a real portability need appears; it can obscure the simple pandas/Polars/DuckDB story. | Later candidate after the first local analysis prototype. | +| SciPy / statsmodels / scikit-learn | Scientific algorithms, statistical modeling, hypothesis tests, predictive modeling, reusable method skills. | Scient agents will need a trusted baseline for common scientific/statistical tasks, not only generic Python execution. | Do not become a statistics package GUI first, and do not let agents present model output without method notes, assumptions, parameters, and provenance. | Add as core scientific Python runtime references. | | R / tidyverse / ggplot2 | R analysis compatibility, grammar-of-graphics expectations, statistical ecosystem, collaborator workflows. | Many research groups still rely on R; ggplot2 is a major reference for chart specification and statistical graphics. | Do not make R a day-one core runtime unless the first validation scenario requires it. | Later runtime compatibility and figure grammar reference. | | DVC / DataLad | Dataset/artifact versioning, large-file management, experiment/data provenance. | Important for reproducible analyses and for projects with files too large or too changeable for ordinary Git. | Too technical for day-one normal users if exposed raw; keep as power-user adapter or internal inspiration. | Later power-user integration; keep in source map. | | Snakemake / Nextflow / Galaxy / Renku | Reproducible workflows, pipeline execution, non-coder workflow UI, cloud/HPC sessions. | Important for computational science and bioinformatics projects where analysis is a pipeline, not a single script. | Not the day-one product kernel, and not the default analysis UX for ordinary researchers. | Side shelf for workflow expansion. | -| jamovi / JASP / GNU PSPP | Friendly statistical GUI, SPSS-like workflows, classical/Bayesian analysis expectations, reportable tables/plots. | Useful reminders that many researchers want guided statistics and readable outputs, not raw code. | Do not build a separate point-and-click statistics clone; PapiLab should keep code-backed reproducibility and agent-run provenance. | UX reference for method assistant and results tables. | -| Orange Data Mining | Visual programming, data mining, ML workflow canvases, no-code exploration. | Useful for seeing how non-coders understand pipelines and model steps. | Do not make PapiLab a general visual ETL or no-code ML platform. | Side shelf only unless a visual analysis-plan workflow becomes central. | +| jamovi / JASP / GNU PSPP | Friendly statistical GUI, SPSS-like workflows, classical/Bayesian analysis expectations, reportable tables/plots. | Useful reminders that many researchers want guided statistics and readable outputs, not raw code. | Do not build a separate point-and-click statistics clone; Scient should keep code-backed reproducibility and agent-run provenance. | UX reference for method assistant and results tables. | +| Orange Data Mining | Visual programming, data mining, ML workflow canvases, no-code exploration. | Useful for seeing how non-coders understand pipelines and model steps. | Do not make Scient a general visual ETL or no-code ML platform. | Side shelf only unless a visual analysis-plan workflow becomes central. | -Recommendation: PapiLab should own `Dataset`, `Analysis`, `AnalysisRun`, `Table`, +Recommendation: Scient should own `Dataset`, `Analysis`, `AnalysisRun`, `Table`, `Figure`, `Artifact`, dependency/staleness state, method notes, and provenance. The first prototype should be marimo-inspired, but the engine stack should be plain local Python through `uv`, DuckDB for local SQL, pandas/Polars for @@ -555,20 +555,20 @@ scientific Python package baseline. | Source | Adaptation target | Why it matters | Do not adopt | Depth status | |---|---|---|---|---| | Matplotlib / seaborn | Publication-grade static figures, statistical plots, Python ecosystem defaults. | Most Python scientific plotting still lands here; agents can generate reproducible code and export static outputs. | Do not treat a rendered PNG/SVG as the editable figure truth. Keep code, data, parameters, and figure metadata connected. | Add as default static-figure runtime. | -| Plotly | Interactive, browser-native, publication-quality charts and scientific chart types. | Good fit for inspectable PapiLab artifacts and app-embedded exploratory figures. | Do not let Plotly JSON become the only Figure model; store it as one projection/export. | Add as first interactive chart runtime. | +| Plotly | Interactive, browser-native, publication-quality charts and scientific chart types. | Good fit for inspectable Scient artifacts and app-embedded exploratory figures. | Do not let Plotly JSON become the only Figure model; store it as one projection/export. | Add as first interactive chart runtime. | | Altair / Vega-Lite | Declarative chart specifications, JSON grammar, concise interactive graphics. | Best candidate for agent-editable chart specs because an agent can modify a structured grammar rather than pixel output. | Not enough alone for every publication figure or complex custom visual. | Add as primary editable/declarative chart-spec reference. | -| Bokeh / HoloViz / Panel / Datashader | Browser dashboards, widgets, large/streaming data visualization, Python-to-web apps. | Useful when PapiLab needs richer exploratory dashboards or very large visual data. | Too broad and framework-like for the first figure core. | Side shelf after Plotly/Altair prototype. | -| Observable Plot / D3 | Web-native exploratory charts and custom visualization grammar. | Useful for PapiLab's React surface when a figure or evidence view needs custom web interaction. | Do not make researchers author JavaScript to get normal scientific figures. | Side reference for web UI charts. | +| Bokeh / HoloViz / Panel / Datashader | Browser dashboards, widgets, large/streaming data visualization, Python-to-web apps. | Useful when Scient needs richer exploratory dashboards or very large visual data. | Too broad and framework-like for the first figure core. | Side shelf after Plotly/Altair prototype. | +| Observable Plot / D3 | Web-native exploratory charts and custom visualization grammar. | Useful for Scient's React surface when a figure or evidence view needs custom web interaction. | Do not make researchers author JavaScript to get normal scientific figures. | Side reference for web UI charts. | | Great Tables / gt | Publication-ready tables in Python/R with structured table parts and exportable formats. | Scientific outputs often include tables as much as figures; tables need provenance, styling, captions, and manuscript links. | Do not reduce tables to screenshots or arbitrary HTML. | Add as table-output reference. | -| Mermaid / Graphviz / Cytoscape.js | Diagrams-as-code, graph/network diagrams, evidence graphs, workflow graphs. | PapiLab will need visualizations of claims, evidence, protocols, and analysis dependencies, not only statistical charts. | Do not make graph layout output the project graph truth. | Add as diagram/graph-output references. | -| tldraw / Excalidraw / xyflow | Canvas editing, whiteboard diagrams, node-based workflows, visual planning. | Useful for protocol sketches, evidence maps, analysis flow views, and editable figure planning surfaces. | Do not make PapiLab canvas-first or treat a freeform canvas as scientific provenance. | Keep and expand as side component sources. | +| Mermaid / Graphviz / Cytoscape.js | Diagrams-as-code, graph/network diagrams, evidence graphs, workflow graphs. | Scient will need visualizations of claims, evidence, protocols, and analysis dependencies, not only statistical charts. | Do not make graph layout output the project graph truth. | Add as diagram/graph-output references. | +| tldraw / Excalidraw / xyflow | Canvas editing, whiteboard diagrams, node-based workflows, visual planning. | Useful for protocol sketches, evidence maps, analysis flow views, and editable figure planning surfaces. | Do not make Scient canvas-first or treat a freeform canvas as scientific provenance. | Keep and expand as side component sources. | | Inkscape / diagrams.net / BioIcons | SVG editing, diagram editing, open scientific icon libraries. | Useful for final figure polish and biology/chemistry illustration assets, especially as open alternatives to commercial illustration tools. | Do not rebuild Illustrator/BioRender first; integrate/export where useful. | Add as open figure-polish and icon-source references. | | napari / Fiji / ImageJ / CellProfiler / QuPath | Bioimage viewing, annotation, quantitative image analysis, microscopy/pathology workflows. | Crucial for life-science projects where figures come from images and measurements, not simple tables. | Do not make bioimage analysis part of the general first core unless the validation scenario requires it. | Domain-specific side shelf with high future value. | | RDKit / Mol* / 3Dmol.js / Biopython | Chemistry, molecular, structural-biology, and bioinformatics computation/visualization. | Important for discipline-specific figure and analysis adapters. | Do not overload the first product with every scientific domain toolkit. | Domain-specific side shelf; add when a project scenario needs it. | -| Streamlit / Dash / Shiny / Gradio | Data apps, dashboards, interactive reports, model demos. | Useful for artifact-export and "share this analysis view" patterns. | Do not make generated apps the PapiLab analysis model or primary UI. | Side reference for shareable analysis artifacts. | +| Streamlit / Dash / Shiny / Gradio | Data apps, dashboards, interactive reports, model demos. | Useful for artifact-export and "share this analysis view" patterns. | Do not make generated apps the Scient analysis model or primary UI. | Side reference for shareable analysis artifacts. | | BioRender / GraphPad Prism / OriginPro | Commercial figure/statistics UX expectations. | Scientists need modifiable figures, statistical outputs, templates, annotations, and publication polish. | Mostly commercial/reference only. | Product reference, not source-code adaptation. | -Recommendation: PapiLab needs multiple figure lanes, not one figure library. The +Recommendation: Scient needs multiple figure lanes, not one figure library. The first figure prototype should support a static Matplotlib figure, an interactive Plotly figure, an editable Altair/Vega-Lite spec, and a publication table, all linked to the same `AnalysisRun`, data inputs, parameters, captions, manuscript @@ -618,15 +618,15 @@ Official-source links checked in this pass: |---|---|---|---|---| | Yjs / Hocuspocus | Real-time collaborative document editing, shared types, awareness, persistence, WebSocket backend. | Default first candidate if Tiptap remains the editor. | Do not use Yjs as the whole project database. | Core collaboration candidate. | | Yorkie | CRDT document server, schemas, server-side document lifecycle. | Serious challenger to Hocuspocus. | Adds Go/service complexity. | Challenger prototype after conflict cases are defined. | -| PowerSync / Electric | SQLite-to-cloud and Postgres-backed sync candidates for structured project state. | Current architecture direction already points toward SQLite-to-cloud sync for non-manuscript project state. | Do not choose one before testing conflict semantics on PapiLab objects. | Primary structured-sync candidate set. | -| TinyBase / RxDB / cr-sqlite | Local-first metadata and replication experiments. | Useful fallback or reference set if the primary sync candidates do not fit PapiLab's object model. | Do not expand the first validation pass to every sync engine without a strict harness. | Secondary sync reference set. | +| PowerSync / Electric | SQLite-to-cloud and Postgres-backed sync candidates for structured project state. | Current architecture direction already points toward SQLite-to-cloud sync for non-manuscript project state. | Do not choose one before testing conflict semantics on Scient objects. | Primary structured-sync candidate set. | +| TinyBase / RxDB / cr-sqlite | Local-first metadata and replication experiments. | Useful fallback or reference set if the primary sync candidates do not fit Scient's object model. | Do not expand the first validation pass to every sync engine without a strict harness. | Secondary sync reference set. | | OSF | Open-science project sharing and external integrations. | Good model for connecting to GitHub, GitLab, Google Drive, Dataverse, Figshare, Zotero, etc. | Do not make OSF the source of truth. | Side-to-core for sharing. | -| Dataverse | Dataset repository deposit, metadata, APIs, groups, permissions, export. | Important for institutional data publication. | Do not build a repository platform inside PapiLab. | Deposit/export reference. | +| Dataverse | Dataset repository deposit, metadata, APIs, groups, permissions, export. | Important for institutional data publication. | Do not build a repository platform inside Scient. | Deposit/export reference. | | GitHub / GitLab | Versioning, review, remote backup, collaborator workflows. | Useful as optional project remote. | Do not make Git the only sync/collaboration story. | Required optional integration. | Recommendation: split collaboration into three problems: manuscript realtime editing, structured project-state sync, and cloud sharing/deposit. First define -PapiLab conflict cases, then test a narrow candidate set against those cases. +Scient conflict cases, then test a narrow candidate set against those cases. ## Secondary Sources To Revisit @@ -634,12 +634,12 @@ These are not first-core sources, but each has something worth returning to. | Source group | Why it stays on the side shelf | |---|---| -| Benchling, LabArchives, Labfolder, Labguru | Useful for lab operations, institutional expectations, inventory, compliance, and biotech workflows. Too domain-specific and commercial to define the first PapiLab core. | +| Benchling, LabArchives, Labfolder, Labguru | Useful for lab operations, institutional expectations, inventory, compliance, and biotech workflows. Too domain-specific and commercial to define the first Scient core. | | BioRender, GraphPad Prism, OriginPro | Important commercial references for figure/statistics UX. Use them to understand scientist expectations, while the open figure stack above drives adaptation and prototyping. | | Covidence, DistillerSR, EPPI-Reviewer, RevMan, JBI SUMARI, Nested Knowledge | Important for mature systematic review workflows and compliance. Revisit when review-team/collaboration/risk-of-bias depth becomes central. | | Mendeley, EndNote, Paperpile, ReadCube Papers | Important import/export and user-expectation references. Zotero/JabRef/CSL should drive the open core first. | | Google Docs, Microsoft Word | Essential UX/export benchmarks for comments, suggestions, and manuscript exchange. Not product foundations. | -| OpenAlex, Semantic Scholar, Crossref, PubMed, arXiv, Unpaywall, OpenCitations | External data/search sources and scholarly graph APIs. They feed PapiLab; they do not define the app architecture. | +| OpenAlex, Semantic Scholar, Crossref, PubMed, arXiv, Unpaywall, OpenCitations | External data/search sources and scholarly graph APIs. They feed Scient; they do not define the app architecture. | | LangGraph | Useful for explicit long-running scientific workflows. Do not make it the whole agent architecture. | | Tauri/Rust shell | Revisit after Electron/React prototypes expose a real limitation. Rust remains excellent for sidecars. | @@ -650,8 +650,8 @@ implementation sequence. Their numbering is retained only as a stable reference to the earlier synthesis. The active sequence lives in `../../planning/product-roadmap.md`. -0. Canonical PapiLab schema and event contract. - Define the first version of PapiLab-owned project objects before any tool +0. Canonical Scient schema and event contract. + Define the first version of Scient-owned project objects before any tool shootout: `Project`, `Paper`, `SourceChunk`, `Claim`, `EvidenceLink`, `ScreeningDecision`, `Manuscript`, `Analysis`, `Figure`, `AgentAction`, `Provenance`, and an event/action log. Every later prototype must read and @@ -660,15 +660,15 @@ to the earlier synthesis. The active sequence lives in 1. Agent kernel shootout. Build one local project scenario through Scient, then compare the same - PapiLab boundary with selected external-agent adapters and bounded + Scient boundary with selected external-agent adapters and bounded Goose/Codex architecture references. The scenario should import papers, create a protocol, edit a draft, run a script, update an artifact, and show - approvals/diffs/provenance through the PapiLab object and event contract. + approvals/diffs/provenance through the Scient object and event contract. 2. Evidence pipeline. Import from Zotero/JabRef, parse with GROBID and Docling, answer with PaperQA, and screen with ASReview. The pass condition is exact source traceability for - every extracted value and answer, while keeping PapiLab's Paper, SourceChunk, + every extracted value and answer, while keeping Scient's Paper, SourceChunk, EvidenceLink, and ScreeningDecision objects as the canonical state. 3. Scientific editor shootout. @@ -677,14 +677,14 @@ to the earlier synthesis. The active sequence lives in equations, stable block IDs, and export. 4. Publishing export prototype. - Map PapiLab manuscript/evidence objects to Quarto/Pandoc first and MyST as a + Map Scient manuscript/evidence objects to Quarto/Pandoc first and MyST as a challenger. Export to Word/PDF/HTML/LaTeX or Typst where feasible. Treat each - export as an artifact DAG generated from PapiLab state. + export as an artifact DAG generated from Scient state. 5. Scientific schema and provenance prototype. - Compare PapiLab manuscript/evidence objects against Stencila-style semantic + Compare Scient manuscript/evidence objects against Stencila-style semantic document and provenance concepts. The pass condition is not adoption of - Stencila, but a clearer PapiLab-owned shape for document semantics, executable + Stencila, but a clearer Scient-owned shape for document semantics, executable steps, provenance, and agent-authored changes. 6. Analysis and figure prototype. @@ -696,18 +696,18 @@ to the earlier synthesis. The active sequence lives in method notes, captions, manuscript claims, and stale-output checks. 7. Collaboration and sync prototype. - First define conflict cases for PapiLab objects: concurrent manuscript edits, + First define conflict cases for Scient objects: concurrent manuscript edits, evidence judgment changes, screening decisions, citation edits, agent actions, and artifact updates. Then test Yjs/Hocuspocus for document-like collaboration and PowerSync/Electric for structured project-state sync. Keep Yorkie, TinyBase, RxDB, and cr-sqlite as challengers or fallback references unless the - first pass exposes a real gap. Validate every synced shape against PapiLab + first pass exposes a real gap. Validate every synced shape against Scient schema before it becomes project truth. ## Current Synthesis -Current research points toward PapiLab as a local-first, cloud-mirrored scientific -workspace with a PapiLab-owned project graph; TypeScript/React product logic; +Current research points toward Scient as a local-first, cloud-mirrored scientific +workspace with a Scient-owned project graph; TypeScript/React product logic; Electron-first desktop delivery unless a real limitation appears; SQLite local project state mirrored to Postgres/object storage; the owned Synara fork as the accepted initial application foundation; Scient as the owned OpenCode-derived @@ -725,8 +725,8 @@ document-like surfaces where simultaneous editing matters. ## Non-Negotiables -- Do not let a whole-product foundation become PapiLab's source of truth. The - owned Synara fork is acceptable only while PapiLab's scientific project state, +- Do not let a whole-product foundation become Scient's source of truth. The + owned Synara fork is acceptable only while Scient's scientific project state, agent gateway, provenance, and review model stay outside inherited coding- product assumptions. - Do not let any source define the scientific object model. @@ -740,5 +740,5 @@ document-like surfaces where simultaneous editing matters. - Do not make GitHub/GitLab the only cloud/sync story. - Do not choose Rust/Tauri as a symbol of seriousness; use Rust where it solves a real subsystem problem. -- Do not rebuild Zotero, Jupyter, Overleaf, or an ELN before proving the PapiLab +- Do not rebuild Zotero, Jupyter, Overleaf, or an ELN before proving the Scient project graph. diff --git a/docs/research/source-evaluations/source-evaluation-template.md b/docs/research/source-evaluations/source-evaluation-template.md index b099b29..3b6d2a9 100644 --- a/docs/research/source-evaluations/source-evaluation-template.md +++ b/docs/research/source-evaluations/source-evaluation-template.md @@ -2,7 +2,7 @@ Status: Placeholder Owner: Yaacov -Last updated: 2026-06-27 +Last updated: 2026-07-17 Purpose: Defines what should become the source evaluation template once agreed. Doc type: Future home @@ -14,8 +14,8 @@ Potential sections to decide later: - inspection date - license - what was inspected -- what PapiLab can learn -- what PapiLab should avoid +- what Scient can learn +- what Scient should avoid - uncertainties - recommendation diff --git a/docs/research/visual-references/README.md b/docs/research/visual-references/README.md index 05a3040..7219ec0 100644 --- a/docs/research/visual-references/README.md +++ b/docs/research/visual-references/README.md @@ -2,13 +2,13 @@ Status: Active Owner: Yaacov -Last updated: 2026-07-12 +Last updated: 2026-07-17 Purpose: Maps external and historical internal UI screenshots into retrieval-friendly categories for later product-design research. Doc type: Repo orientation Visual references are grouped by the product surface or interaction they illustrate. Each category owns its own index, descriptive filenames, source context, observations, and retrieval terms. Historical LitRev material must be labeled clearly so it cannot be mistaken for current product direction. -These references are research evidence kept for later comparison and inspiration. They are not accepted LitRev design direction, selected colors, design tokens, or implementation requirements, and they do not imply permission to copy another product. +These references are research evidence kept for later comparison and inspiration. They are not accepted Scient design direction, selected colors, design tokens, or implementation requirements, and they do not imply permission to copy another product. ## Categories @@ -18,10 +18,10 @@ These references are research evidence kept for later comparison and inspiration | Agent workflows | Agent task plans, step trackers, progress states, and composer-adjacent workflow surfaces | [Browse agent workflow references](agent-workflows/README.md) | | Dashboards and settings | Administrative dashboards, configuration views, status communication, hierarchy, spacing, surfaces, and visual tone | [Browse dashboard and settings references](dashboard-and-settings/README.md) | | Dialogs and overlays | Important prompts, blocking modals, confirmations, warnings, interruptions, and other layered interactions | [Browse dialog and overlay references](dialogs-and-overlays/README.md) | -| Identity | LitRev symbol sources, adopted scaffold identity, and unselected visual alternatives | [Browse identity references](identity/README.md) | +| Identity | Historical LitRev symbol sources, adopted scaffold identity, and unselected visual alternatives | Not yet indexed | | Motion and interaction | Hover responses, transitions, animated previews, state changes, and other time-dependent interface behavior | [Browse motion and interaction references](motion-and-interaction/README.md) | -Future references should be indexed by the product surface or interaction they primarily illustrate. Visual qualities such as color may be noted inside a reference without making that image a selected LitRev palette. +Future references should be indexed by the product surface or interaction they primarily illustrate. Visual qualities such as color may be noted inside a reference without making that image a selected Scient palette. ## Adding A Reference diff --git a/docs/research/visual-references/agent-workflows/README.md b/docs/research/visual-references/agent-workflows/README.md index 1446048..5ffe08a 100644 --- a/docs/research/visual-references/agent-workflows/README.md +++ b/docs/research/visual-references/agent-workflows/README.md @@ -2,7 +2,7 @@ Status: Active Owner: Yaacov -Last updated: 2026-07-12 +Last updated: 2026-07-17 Purpose: Indexes visual patterns for agent task plans, step trackers, progress states, and workflow controls placed near a conversation composer. Doc type: Research evidence @@ -10,7 +10,7 @@ Doc type: Research evidence Use these references to compare how a long-running agent task can expose its plan without taking the user away from the conversation. Pay attention to the relationship between progress visibility, vertical space, current-step clarity, expansion controls, and the follow-up composer. -Everything here is raw research evidence. A saved reference is not an accepted LitRev task model, progress taxonomy, composer layout, interaction rule, accessibility claim, implementation requirement, or instruction to copy another product. +Everything here is raw research evidence. A saved reference is not an accepted Scient task model, progress taxonomy, composer layout, interaction rule, accessibility claim, implementation requirement, or instruction to copy another product. Images belong in `images/` and use the filename pattern `--.`. Remove or blur project-specific wording and paths before committing a reference. @@ -32,7 +32,7 @@ Images belong in `images/` and use the filename pattern `-------.`. Remove or crop identifying information before committing a reference. @@ -28,22 +28,22 @@ Images belong in `images/` and use the filename pattern `-----.`. Remove or crop identifying information before committing a reference. @@ -27,10 +27,10 @@ Images belong in `images/` and use the filename pattern `-----.` and remove or crop browser or identifying information before committing a reference. @@ -28,7 +28,7 @@ Static images belong in `images/`. Use `-- as +`5ffaf9a2dfa5b958e8f4856b94b50d26b00c6b76`. The protected `dev` +branch now requires `Scient source quality`. This establishes source and +maintenance identity only; it does not claim an implemented native Scient +runtime. + OpenCode 1.18.3 passed its workspace typecheck, 3,158 OpenCode tests, both PapiLab verifier suites, platform builds, and CLI smoke on its pinned Bun 1.3.14 toolchain. Locally, the reviewed follow-ups also passed app and @@ -88,6 +99,14 @@ upstream reconciliation and PapiLab cutover were merged through: `29567845155` and merged as `fd37cdcda16ff34c3b13d098e5a35d0d1aff5096`. +The Scient application rename was then merged through +. Exact source head +`179fa01ed39b7c62d8f8e8b89565d83434e572ce` passed hosted CI run +`29595506303` and merged to owned `main` as +`d9d8992a62e4dda37543c214f96fc97556c798f2`. The same head passed local full +tests, typecheck, lint, formatting, desktop build, release smoke, brand checks, +an exact-commit DMG inspection, and an isolated packaged-app migration smoke. + The earlier Gate 1.5 suite and compatibility smoke remain historical evidence for their recorded source pins. @@ -95,25 +114,27 @@ for their recorded source pins. Repository ownership and adaptation depth are separate decisions: -- Synara and OpenCode use owned GitHub forks as writable `origin` remotes. +- The Synara-derived desktop and OpenCode-derived agent source use + ScientFactory forks as writable `origin` remotes. - The official repository is fetch-only `upstream` and must not be a push target. -- Owning a fork does not imply immediate divergence. OpenCode remains - upstream-aligned, and PapiLab changes begin in adapters, configuration, +- Owning a fork does not imply immediate divergence. The inherited OpenCode + core remains upstream-aligned, and Scient changes begin in adapters, configuration, extensions, packaging, and isolated integration seams. - A source may move from upstream-mergeable to selective cherry-pick only after - PapiLab deliberately accepts the maintenance cost. + Scient deliberately accepts the maintenance cost. At Gate 1.5 closeout, Synara and OpenCode had writable owned `origin` remotes. Their official remotes were named `upstream`, retained their official fetch URLs, and used the literal disabled push URL `DISABLED`. The owned default branches remain protected against direct unreviewed changes, force-push, and -deletion; Synara requires its maintained quality and release-smoke checks, and -OpenCode requires the owned PapiLab source-quality check. +deletion; the desktop fork requires its maintained quality and release-smoke +checks, and the agent-source fork requires `Scient source quality`. -OpenCode was refreshed through 1.18.3 and the desktop fork through official -Synara v0.5.5 on 2026-07-17. At their exact tested heads, both owned defaults -were zero commits behind the official revisions recorded above. +The inherited OpenCode core was refreshed through source version 1.18.3 and the +desktop fork through official Synara v0.5.5 on 2026-07-17. At their exact rename +heads, both owned forks were zero commits behind the official revisions +recorded above. Later upstream movement is new maintenance work, not a retroactive failure of these tested baselines; every future sync must use the maintained fork verifiers and record a new exact pin here. @@ -121,8 +142,8 @@ verifiers and record a new exact pin here. Goose was not added to this ownership model during Gate 1.5. At inspection time, its checkout had only the official fetch-only `upstream`; no local Goose checkout is currently present. The owned Goose repository and every Goose build -or integration action remain deferred until after the first PapiLab gateway -works through OpenCode. +or integration action remain deferred until after the first Scient gateway +works through the Scient agent source foundation. ## License And Notice Snapshot diff --git a/lab/notes/README.md b/lab/notes/README.md index c66c29f..e8b9fd8 100644 --- a/lab/notes/README.md +++ b/lab/notes/README.md @@ -2,7 +2,7 @@ Status: Active Owner: Yaacov -Last updated: 2026-07-16 +Last updated: 2026-07-17 Purpose: Maps temporary inspection notes and lab decisions before promotion into durable docs. Doc type: Repo orientation @@ -17,7 +17,7 @@ integration observations, and temporary lab decisions. - `gate-1-5-evidence-manifest-2026-07-11.json` - machine-verifiable source heads, retained committed evidence, and the historical SHA-256 inventory of local evidence deleted after accepted closeout. - `gate-1-5-smoke-evidence-2026-07-11.json` - compact, committed extract of the live owned-binary compatibility result and its limitations. - `synara-gate-1-baseline-2026-07-11.md` - historical inherited-scaffold baseline, official-CLI correction run, and Gate 1 pass result. -- `synara-first-inspection-2026-07-07.md` - first source inspection of Synara as desktop base, OpenCode first-agent path, Goose integration path, and PapiLab ownership boundary. +- `synara-first-inspection-2026-07-07.md` - first source inspection of Synara as desktop base, OpenCode first-agent path, Goose integration path, and Scient ownership boundary. - `goose-source-depth-inspection-2026-07-11.md` - research input for Goose's later role, ACP surfaces, runtime-state boundary, permission risks, and first adapter recommendation. Keep notes clear about whether they are: diff --git a/lab/notes/goose-source-depth-inspection-2026-07-11.md b/lab/notes/goose-source-depth-inspection-2026-07-11.md index 1b365f5..c9eca15 100644 --- a/lab/notes/goose-source-depth-inspection-2026-07-11.md +++ b/lab/notes/goose-source-depth-inspection-2026-07-11.md @@ -2,16 +2,16 @@ Status: Draft Owner: Yaacov -Last updated: 2026-07-16 -Purpose: Records research evidence on Goose integration seams, runtime boundaries, safety gaps, and its possible later role in PapiLab. +Last updated: 2026-07-17 +Purpose: Records research evidence on Goose integration seams, runtime boundaries, safety gaps, and its possible later role in Scient. Doc type: Research evidence ## Outcome -Goose is a strong candidate for PapiLab's broader local-agent engine, especially +Goose is a strong candidate for Scient's broader local-agent engine, especially for MCP extensions, recipes, repeatable workflows, scheduling, provider choice, -and subagents. It should sit behind a PapiLab-owned gateway; it should not define -PapiLab project truth, permissions, provenance, or accepted write-back. +and subagents. It should sit behind a Scient-owned gateway; it should not define +Scient project truth, permissions, provenance, or accepted write-back. The recommended first integration is `goose acp` over stdio. It gives a local client structured, bidirectional streaming without opening a network port and @@ -21,7 +21,7 @@ current upstream removed that crate and replaced the custom-client path with ACP Goose is not a filesystem sandbox. Its working directory anchors relative paths, but its built-in file tools accept absolute paths and its shell tool runs -normal host commands. PapiLab must provide the project boundary, approval policy, +normal host commands. Scient must provide the project boundary, approval policy, and independent run receipt. ## Inspected Source @@ -52,7 +52,7 @@ provider, SDK, local-inference, test, and desktop surfaces. Important components: -| Component | Role relevant to PapiLab | +| Component | Role relevant to Scient | |---|---| | `crates/goose` | Core agent loop, sessions, recipes, extensions, permissions, hooks, security inspectors, and ACP implementation. | | `crates/goose-cli` | `goose acp`, `goose serve`, interactive sessions, one-shot runs, recipes, scheduler commands, and configuration. | @@ -60,27 +60,27 @@ Important components: | `crates/goose-providers` | Provider implementations and model streaming. | | `crates/goose-sdk` | Rust bindings layer and a reference ACP client; Python/Kotlin bindings currently expose a narrower provider surface. | | `ui/sdk` | TypeScript ACP client/types plus optional platform-specific Goose binaries. | -| `ui/desktop` | Goose's own Electron client; useful as ACP-client reference, not a UI to embed in PapiLab. | +| `ui/desktop` | Goose's own Electron client; useful as ACP-client reference, not a UI to embed in Scient. | Goose itself now uses ACP as the main separation between client UI and agent -runtime. This aligns better with PapiLab than copying Goose desktop components. +runtime. This aligns better with Scient than copying Goose desktop components. ## Integration Options | Option | Current assessment | |---|---| | `goose acp` over stdio | Recommended first spike. Local child-process lifecycle, no listening port, structured streaming, permissions, tool events, cancellation, and sessions. | -| `goose serve` over authenticated HTTP/WebSocket | Viable later when PapiLab needs a longer-lived or separately managed backend. Requires `GOOSE_SERVER__SECRET_KEY`, origin handling, lifecycle supervision, and a local network threat review. | +| `goose serve` over authenticated HTTP/WebSocket | Viable later when Scient needs a longer-lived or separately managed backend. Requires `GOOSE_SERVER__SECRET_KEY`, origin handling, lifecycle supervision, and a local network threat review. | | TypeScript `@aaif/goose-sdk` | Useful protocol/client reference and possible packaging shortcut, but the official packages bundle official binaries. An owned-fork release path would need its own package/binary provenance. | -| Direct Rust embedding through Goose crates/SDK | Deferred. It couples PapiLab more tightly to fast-moving internal APIs and adds Rust/native build complexity before the adapter contract is proven. | +| Direct Rust embedding through Goose crates/SDK | Deferred. It couples Scient more tightly to fast-moving internal APIs and adds Rust/native build complexity before the adapter contract is proven. | | `goose run` text/CLI parsing | Suitable for smoke tests or automation, but weaker than ACP for approvals, structured events, cancellation, and interactive control. | -| Goose desktop embedding | Not recommended. PapiLab already has a workbench candidate, and embedding another desktop product would duplicate UI, state, and orchestration. | +| Goose desktop embedding | Not recommended. Scient already has a workbench candidate, and embedding another desktop product would duplicate UI, state, and orchestration. | ## Capabilities Worth Reusing - ACP initialization, session creation/loading/listing/closing/forking, prompt streaming, tool-call updates, permission requests, and cancellation. -- Client-provided filesystem and terminal capabilities, which allow a PapiLab +- Client-provided filesystem and terminal capabilities, which allow a Scient client to own some tools and show native diffs or terminal output. - MCP extensions over stdio and Streamable HTTP, plus frontend-provided tools. - Recipes with parameters, response JSON schemas, extensions, retry settings, @@ -92,33 +92,33 @@ runtime. This aligns better with PapiLab than copying Goose desktop components. and observability seams. - Configurable state isolation through `GOOSE_PATH_ROOT`. -These are engine capabilities. PapiLab must decide which context is supplied, +These are engine capabilities. Scient must decide which context is supplied, which tools are exposed, which changes are proposed, and which outputs become accepted scientific state. ## Safety And Boundary Findings -1. **Autonomous mode is the documented default.** PapiLab must never inherit +1. **Autonomous mode is the documented default.** Scient must never inherit that default silently. The first adapter should require explicit approval or - a stricter PapiLab-controlled policy. + a stricter Scient-controlled policy. 2. **Working directory is not a sandbox.** Relative paths resolve from the session working directory, but absolute file paths are accepted. Shell commands run through the host shell and can address paths outside the project. 3. **Tool classification is best effort.** Goose distinguishes read, write, shell, and other operations and provides manual/smart permission modes, but - documentation states classification is interpretive. PapiLab needs its own + documentation states classification is interpretive. Scient needs its own enforceable scope checks. 4. **Hooks are helpful but not a sole security boundary.** Pre-tool hooks can block calls, yet hook execution errors are logged and treated as allow. A - failing hook must not become PapiLab's only containment mechanism. + failing hook must not become Scient's only containment mechanism. 5. **Engine state is persistent and non-canonical.** Sessions are stored in a Goose SQLite database under its data root. This is useful for runtime resume and diagnostics but must remain reconstructable or discardable relative to - PapiLab-owned records. + Scient-owned records. 6. **Some extensions write engine-specific project state.** The memory MCP can use `.goose/memory` under the working directory. Do not enable that behavior - as PapiLab project memory without an explicit adapter decision. + as Scient project memory without an explicit adapter decision. 7. **ACP is still marked experimental.** It is the strongest current seam, but the adapter must pin and test the protocol/version surface during updates. 8. **Upstream is moving quickly.** Twenty-three commits in four days removed a @@ -127,25 +127,25 @@ accepted scientific state. ## Owned-Fork Recommendation -Maintain a PapiLab-owned Goose fork even while keeping it close to upstream: +Maintain a Scient-owned Goose fork even while keeping it close to upstream: ```text -origin -> PapiLab-owned Goose fork +origin -> Scient-owned Goose fork upstream -> aaif-goose/goose, fetch-only ``` -Initially keep PapiLab changes outside Goose core where possible: +Initially keep Scient changes outside Goose core where possible: -- a PapiLab ACP adapter/client; -- PapiLab recipes and MCP extensions; +- a Scient ACP adapter/client; +- Scient recipes and MCP extensions; - packaging and pinned binary provenance; - narrowly scoped configuration defaults; and - upstreamable generic fixes. Do not rebrand or distribute Goose desktop merely because the source supports custom distributions. If Goose remains an embedded engine, its standalone UI -is not part of the PapiLab product surface. Revisit deeper ownership only if ACP, -recipes, extensions, and adapter seams cannot satisfy real PapiLab workflows. +is not part of the Scient product surface. Revisit deeper ownership only if ACP, +recipes, extensions, and adapter seams cannot satisfy real Scient workflows. Apache-2.0 permits modification and distribution subject to license and notice requirements. Goose's own custom-distribution guidance also cautions against @@ -163,18 +163,18 @@ After the owned fork exists: 5. require approval for the single harmless action; 6. capture ACP text, tool, permission, cancellation, and completion events; 7. prove that an attempted absolute-path access outside the fixture is denied by - PapiLab rather than trusted to Goose's working directory; -8. produce a PapiLab-owned run receipt independent of Goose's `sessions.db`; and + Scient rather than trusted to Goose's working directory; +8. produce a Scient-owned run receipt independent of Goose's `sessions.db`; and 9. stop the child process and verify state and credentials remain isolated. -The spike passes only if PapiLab can reconstruct what was requested, approved, +The spike passes only if Scient can reconstruct what was requested, approved, executed, produced, and rejected without treating Goose session storage as canonical. ## Recommendation Defer the owned Goose fork and ACP-over-stdio adapter spike until after the first -PapiLab gateway works through the owned OpenCode runtime. Use Goose later to test +Scient gateway works through the owned OpenCode runtime. Use Goose later to test the broader agent and automation role through that established boundary. Do not add Goose directly to Synara as an unrestricted provider and do not begin from Goose desktop or the removed REST server. diff --git a/lab/notes/papilab-rename-execution-report-2026-07-16.md b/lab/notes/papilab-rename-execution-report-2026-07-16.md index 7bc84b8..ad0e1a4 100644 --- a/lab/notes/papilab-rename-execution-report-2026-07-16.md +++ b/lab/notes/papilab-rename-execution-report-2026-07-16.md @@ -1,6 +1,6 @@ # PapiLab Rename Execution Report -Status: Active +Status: Historical Owner: Yaacov Last updated: 2026-07-17 Purpose: Records the executed PapiLab identity cutover, verification results, and remaining external cutover work. diff --git a/lab/notes/project-initiation-placement-trace-2026-07-16.md b/lab/notes/project-initiation-placement-trace-2026-07-16.md index 5618a12..af32e7f 100644 --- a/lab/notes/project-initiation-placement-trace-2026-07-16.md +++ b/lab/notes/project-initiation-placement-trace-2026-07-16.md @@ -13,7 +13,7 @@ project-initiation kernel was implemented. It records the point-in-time source baseline and placement decision; the executed outcome is recorded below. It does not complete the broader first-slice source trace or activate `docs/architecture/project-format.md`. The accepted ownership boundary remains -`../../docs/architecture/decisions/ADR-0001-synara-opencode-foundation-and-papilab-ownership-boundary.md`. +`../../docs/architecture/decisions/ADR-0001-synara-opencode-foundation-and-scient-ownership-boundary.md`. ## Selected Source Baseline diff --git a/lab/notes/synara-first-inspection-2026-07-07.md b/lab/notes/synara-first-inspection-2026-07-07.md index a226524..e59b013 100644 --- a/lab/notes/synara-first-inspection-2026-07-07.md +++ b/lab/notes/synara-first-inspection-2026-07-07.md @@ -2,7 +2,7 @@ Status: Historical Owner: Yaacov -Last updated: 2026-07-16 +Last updated: 2026-07-17 Purpose: Preserves the first technical inspection of Synara and the initial ownership plan that preceded the accepted foundation decision. Doc type: Research evidence @@ -11,7 +11,7 @@ Doc type: Research evidence The inspected source findings remain useful evidence. Body text may retain contemporary planning and Gate 1.6 language as point-in-time wording. Current foundation and sequencing decisions live in -`../../docs/architecture/decisions/ADR-0001-synara-opencode-foundation-and-papilab-ownership-boundary.md`, +`../../docs/architecture/decisions/ADR-0001-synara-opencode-foundation-and-scient-ownership-boundary.md`, `../../docs/planning/product-roadmap.md`, and the first-slice implementation plan. diff --git a/lab/papilab-bridge/README.md b/lab/scient-bridge/README.md similarity index 62% rename from lab/papilab-bridge/README.md rename to lab/scient-bridge/README.md index 139905d..2af96ab 100644 --- a/lab/papilab-bridge/README.md +++ b/lab/scient-bridge/README.md @@ -1,15 +1,15 @@ -# PapiLab Bridge +# Scient Bridge Status: Draft Owner: Yaacov -Last updated: 2026-07-07 -Purpose: Holds PapiLab-owned adapter and integration experiments connecting lab source checkouts. +Last updated: 2026-07-17 +Purpose: Holds Scient-owned adapter and integration experiments connecting lab source checkouts. Doc type: Planning note ## Purpose -This folder is for PapiLab-owned bridge code and contracts that connect upstream -tools without letting any upstream project define PapiLab's product model. +This folder is for Scient-owned bridge code and contracts that connect upstream +tools without letting any upstream project define Scient's product model. Early bridge work may include: @@ -21,7 +21,7 @@ Early bridge work may include: ## Rules -- Keep bridge code PapiLab-owned. +- Keep bridge code Scient-owned. - Prefer small, inspectable contracts over broad hidden coupling. - Record assumptions in `../notes/` when they are not ready for durable docs. - Promote stable architecture into `docs/architecture/` or ADRs later. diff --git a/skills/README.md b/skills/README.md index 9d2104f..62c1e49 100644 --- a/skills/README.md +++ b/skills/README.md @@ -2,18 +2,18 @@ Status: Active Owner: Yaacov -Last updated: 2026-07-16 -Purpose: Indexes local workflow skills that help agents work on PapiLab without becoming project authority. +Last updated: 2026-07-17 +Purpose: Indexes local workflow skills that help agents work on Scient without becoming project authority. Doc type: Repo orientation -This folder keeps PapiLab-specific agent skills together so they are easy to find when working on this project. +This folder keeps Scient-specific agent skills together so they are easy to find when working on this project. Project skills are workflow helpers. They should point agents back to the canonical repo documents and must not override `AGENTS.md`, `docs/product/`, `docs/architecture/`, or `docs/documentation-policy.md`. ## Skills -- [`documentation/papilab-documentation-stewardship/SKILL.md`](documentation/papilab-documentation-stewardship/SKILL.md) - governed documentation creation, review, placement, promotion, progress routing, reconciliation, and validation. -- [`product/papilab-product-stewardship/SKILL.md`](product/papilab-product-stewardship/SKILL.md) - product management, PRD, feature analysis, roadmap, and product decision support. +- [`documentation/scient-documentation-stewardship/SKILL.md`](documentation/scient-documentation-stewardship/SKILL.md) - governed documentation creation, review, placement, promotion, progress routing, reconciliation, and validation. +- [`product/scient-product-stewardship/SKILL.md`](product/scient-product-stewardship/SKILL.md) - product management, PRD, feature analysis, roadmap, and product decision support. ## Adding Skills diff --git a/skills/documentation/papilab-documentation-stewardship/agents/openai.yaml b/skills/documentation/papilab-documentation-stewardship/agents/openai.yaml deleted file mode 100644 index 3df6f78..0000000 --- a/skills/documentation/papilab-documentation-stewardship/agents/openai.yaml +++ /dev/null @@ -1,4 +0,0 @@ -interface: - display_name: "PapiLab Documentation Stewardship" - short_description: "Govern and maintain PapiLab project documentation" - default_prompt: "Use $papilab-documentation-stewardship to handle this PapiLab documentation request in the correct canonical home." diff --git a/skills/documentation/papilab-documentation-stewardship/SKILL.md b/skills/documentation/scient-documentation-stewardship/SKILL.md similarity index 87% rename from skills/documentation/papilab-documentation-stewardship/SKILL.md rename to skills/documentation/scient-documentation-stewardship/SKILL.md index ac5c4d1..5d99bc1 100644 --- a/skills/documentation/papilab-documentation-stewardship/SKILL.md +++ b/skills/documentation/scient-documentation-stewardship/SKILL.md @@ -1,10 +1,10 @@ --- -name: papilab-documentation-stewardship -description: Apply PapiLab's documentation policy to create, update, review, move, promote, retire, and reconcile repository documentation and progress records. Use for documentation audits, repository-scope and placement questions, AI-assisted durable knowledge capture, metadata or status changes, placeholder activation, index maintenance, conflict or drift reconciliation, and documentation resulting from product, architecture, research, implementation, or operations. Do not use for product analysis alone, code changes without documentation impact, or read-only status lookup. +name: scient-documentation-stewardship +description: Apply Scient's documentation policy to create, update, review, move, promote, retire, and reconcile repository documentation and progress records. Use for documentation audits, repository-scope and placement questions, AI-assisted durable knowledge capture, metadata or status changes, placeholder activation, index maintenance, conflict or drift reconciliation, and documentation resulting from product, architecture, research, implementation, or operations. Do not use for product analysis alone, code changes without documentation impact, or read-only status lookup. --- -# PapiLab Documentation Stewardship +# Scient Documentation Stewardship ## Core Judgment @@ -16,7 +16,7 @@ In the current documentation-first phase, repository documents are the main dura Use this skill as a workflow. Treat `docs/documentation-policy.md`, `AGENTS.md`, the relevant area index, and each document's own rules as authority. -Use `papilab-product-stewardship` for product judgment. Use both skills when product work also changes durable documentation. +Use `scient-product-stewardship` for product judgment. Use both skills when product work also changes durable documentation. ## Choose The Mode @@ -37,7 +37,7 @@ Do not edit in `review` or `plan` mode unless the user explicitly expands the re Always: 1. Inspect the worktree and preserve unrelated changes. -2. Confirm that the material belongs inside the current PapiLab repository. +2. Confirm that the material belongs inside the current Scient repository. 3. Read the complete target document, including metadata, document rules, and any update policy. 4. Read the owning area index and any canonical source the target depends on. @@ -96,7 +96,7 @@ Distinguish planned, in-progress, completed, verified, deferred, blocked, reject Before finishing, check: 1. Metadata, status, purpose, document type, content, and authority agree. -2. The material belongs in the PapiLab repository and has a real accountable owner where required. +2. The material belongs in the Scient repository and has a real accountable owner where required. 3. Placement follows the documentation policy, context is navigable, and canonical truth is not duplicated. 4. Planned, proposed, experimental, implemented, and historical material remain distinct. 5. Contradictions and uncertainty remain visible instead of being smoothed away. diff --git a/skills/documentation/scient-documentation-stewardship/agents/openai.yaml b/skills/documentation/scient-documentation-stewardship/agents/openai.yaml new file mode 100644 index 0000000..c0623ee --- /dev/null +++ b/skills/documentation/scient-documentation-stewardship/agents/openai.yaml @@ -0,0 +1,4 @@ +interface: + display_name: "Scient Documentation Stewardship" + short_description: "Govern and maintain Scient project documentation" + default_prompt: "Use $scient-documentation-stewardship to handle this Scient documentation request in the correct canonical home." diff --git a/skills/product/papilab-product-stewardship/SKILL.md b/skills/product/scient-product-stewardship/SKILL.md similarity index 81% rename from skills/product/papilab-product-stewardship/SKILL.md rename to skills/product/scient-product-stewardship/SKILL.md index 6108f1e..9ae9993 100644 --- a/skills/product/papilab-product-stewardship/SKILL.md +++ b/skills/product/scient-product-stewardship/SKILL.md @@ -1,13 +1,13 @@ --- -name: papilab-product-stewardship -description: Shape PapiLab product direction, PRDs, feature analysis, roadmap notes, and product decisions while preserving repo truth, evidence boundaries, and the distinction between product, architecture, planning, and research. +name: scient-product-stewardship +description: Shape Scient product direction, PRDs, feature analysis, roadmap notes, and product decisions while preserving repo truth, evidence boundaries, and the distinction between product, architecture, planning, and research. --- -# PapiLab Product Stewardship +# Scient Product Stewardship -Use this skill when shaping PapiLab product direction, updating product docs, evaluating product items, writing PRD material, synthesizing research input, or clarifying product decisions. +Use this skill when shaping Scient product direction, updating product docs, evaluating product items, writing PRD material, synthesizing research input, or clarifying product decisions. -PapiLab is an agent-driven workspace for scientists to keep an entire research project in one place: evidence, files, code, data analysis, citations, collaboration, and the path to a publication-ready manuscript. +Scient is an agent-driven workspace for scientists to keep an entire research project in one place: evidence, files, code, data analysis, citations, collaboration, and the path to a publication-ready manuscript. ## First Move @@ -27,7 +27,7 @@ Use the repo documentation policy to place it correctly. - Read the relevant current repo docs before proposing changes. - Do not describe planned architecture as implemented architecture. -- Keep the PRD focused on what PapiLab should be and why. +- Keep the PRD focused on what Scient should be and why. - Put stack, runtime, package, sync, database, and implementation details in architecture or planning docs. - Preserve uncertainty. Mark assumptions, open questions, guesses, and unvalidated recommendations. - Prefer clear current-state wording over polished vague language. @@ -58,7 +58,7 @@ Ask: - Will researchers need this in their real workflow? - Is this necessary now, later, or not at all? - What user workflow, product risk, or scientific-workflow gap does it solve at this step? -- What is the smallest complete version that preserves PapiLab's quality bar? +- What is the smallest complete version that preserves Scient's quality bar? - Would delaying this block agent-driven work, manual researcher work, trust, review, sync, or project coherence? - Should this exist on mobile? - If yes, is mobile meant to provide full parity, lightweight review, reading, capture, approvals, notifications, or project continuation? @@ -94,7 +94,7 @@ For most tasks, use this structure: - Do not create new durable docs unless the existing docs do not have a proper home for the material. - Do not duplicate canonical truth across files. - Do not invent commands, schemas, services, APIs, users, metrics, launch plans, or stakeholder approvals. -- Do not let generic SaaS product-management templates override PapiLab's scientific-workflow reality. +- Do not let generic SaaS product-management templates override Scient's scientific-workflow reality. - Do not make the manual workspace a secondary viewer for agent output. ## Final Check