Solar Data Substrate 2.0 不应该叫“知识库”或“记忆系统”。它应该是 Solar Compile Stack + Knowledge & Governance Fabric。
它把老板目标编译成需求，把需求编译成语义绑定，把语义绑定编译成计划，把计划绑定动作契约，把运行状态和证据编译成上下文，再由 Execution Broker 强制执行、验证、记录和回放。
这版设计把我们整个会话收敛成一个终极架构：
Solar Compile Stack
+ Solar Knowledge & Governance Fabric
+ Context Compiler
+ Execution Broker
+ Evidence / Event / Artifact Ledger
Solar 当前公开 README 已经把 Solar 定义为 long-running、evidence-driven execution fabric，并强调 intent -> contract -> PRD/plan -> TaskGraph IR -> operator binding -> lease -> dispatch -> handoff -> eval -> gate -> memory -> optimization；同时它也明确说 Solar 的价值观是 “requirements are compilable artifacts” 和 “Evidence defines completion”。这说明新版数据底座应该顺着 Solar 现有路线继续做“编译、调度、证据、治理”，而不是回到普通 RAG 或 memory plugin。
0. 总命名
建议正式命名：
Solar Data Substrate 2.0
Codename: Solar Knowledge & Governance Fabric
Core Runtime: Solar Compile Stack
一句话定义：
A local-first, evidence-native, contract-aware, event-sourced,
incrementally materialized data substrate for Solar’s autonomous software organization runtime.
中文定义：
Solar Data Substrate 2.0 是一个本地优先、证据原生、契约感知、事件溯源、增量物化的数据底座，
用于支撑 Solar 把老板意图编译成需求，把需求编译成计划，把计划编译成受控动作，
把知识编译成证据，把状态编译成上下文，把执行历史编译成可回放账本。
1. 最终架构拍板
1.1 不能再做的事
这些直接砍掉，不要保留兼容幻想：
1. 不再保留 MemPalace runtime。
2. 不再有 mempalace.search / diary_write / diary_read。
3. 不再把 Chroma / Vector DB 当长期记忆 source of truth。
4. 不再让 agent 自己随手查 memory 再自由执行工具。
5. 不再让 MCP tool schema 等同于动作治理。
6. 不再让 qmd、Obsidian、HTML、向量库抢 canonical truth。
1.2 新架构的第一原则
上下文不是回忆；
上下文是需求、语义、计划、契约、状态、证据共同编译出来的执行产物。
旧模式：
agent -> memory.search("what do I know?")
新模式：
requirement + grounded semantics + plan node + runtime state + policy + evidence
-> Context Compiler
-> Context Pack
-> Agent / Operator / Evaluator / Broker
你上传的 Super Harness 材料也明确指出：context window 只能当 cache，不能当 source of truth；长程任务应该从 Fact Store、Event Ledger、State Projection、Episodic Trace 生成 bounded context projection，而不是靠大上下文或 vector memory 硬撑。
2. 终极目标架构图
┌────────────────────────────────────────────────────────────────────────────┐
│ Boss Intent │
│ 用户只表达目标、边界、预算、偏好、审批策略 │
└───────────────────────────────────┬────────────────────────────────────────┘
▼
┌────────────────────────────────────────────────────────────────────────────┐
│ Solar Compile Stack │
├────────────────────────────────────────────────────────────────────────────┤
│ 1. Requirement Compiler │
│ NL Intent -> RequirementIR │
│ │
│ 2. GEMS Grounding Compiler │
│ RequirementIR -> GroundedRequirementIR │
│ ConceptGraph / SourceGraph / ToolingGraph / PolicyGraph / ContractGraph│
│ │
│ 3. Plan Compiler │
│ GroundedRequirementIR -> PlanIR / TaskGraph IR │
│ │
│ 4. Contract Binder + Static Verifier │
│ PlanIR -> ContractedPlanIR │
│ pre/post/effects/auth/policy/cost/approval/compensation/verifier │
│ │
│ 5. Context Compiler │
│ ContractedPlanIR + State + Evidence -> Context Pack Family │
└───────────────────────────────────┬────────────────────────────────────────┘
▼
┌────────────────────────────────────────────────────────────────────────────┐
│ Execution Broker │
│ Proposed -> Grounded -> Contract-Bound -> Preflight-Verified │
│ -> Approved -> Executing -> Observed -> Postflight-Verified │
│ -> Committed -> Recorded │
└───────────────────────────────────┬────────────────────────────────────────┘
▼
┌────────────────────────────────────────────────────────────────────────────┐
│ Solar Knowledge & Governance Fabric │
├────────────────────────────────────────────────────────────────────────────┤
│ A. Source Registry + Raw CAS │
│ B. SolarDocIR │
│ C. Runtime Event Ledger │
│ D. State Projection │
│ E. Evidence Ledger + Claim Ledger │
│ F. Solar Semantic Graph │
│ G. Action Contract Store │
│ H. Context Pack Store │
│ I. Materialized Projections via CocoIndex │
│ J. qmd/MDE Deep Reading Sidecar │
│ K. MinerU Parse Workers │
│ L. Obsidian Human Curation Surface │
│ M. HTML Delivery Projection │
└────────────────────────────────────────────────────────────────────────────┘
GEMS 论文原始方案把缺口归纳为 semantic grounding、formal action contracts、governed memory，并设计了 GEMS Graph、Action Contracts、Governed Memory、Runtime Integration 四个研究目标；这套东西天然适合作为 Solar 数据底座升级的理论底盘。 但我们的改造要比 GEMS 原案更强：GEMS 不能只是 MCP sidecar，必须进入 Solar 的强制执行控制面。
3. 与当前 Solar 的接口关系
Solar 当前已经有这些核心能力：
Requirement Compiler
Sprint Contract
TaskGraph IR
Actor / Host registry
Logical Operator DAG
Physical Operator Binding
Queue / Lease / Dispatch
Handoff / Eval / Node Verdict
Parent Gate
Accepted Artifact
Evidence ABI
Plugin framework
Event-sourced runtime
Deep Research gates
公开 README 里已经明确：Solar Harness 负责从 Boss Intent 到 Sprint Contract / PRD、Plan + TaskGraph IR、Capability Annotation、Logical Operator DAG、Physical Operator Binding、Queue / Lease / Dispatch、Handoff / Eval / Node Verdict、Parent Gate、Accepted Artifact / Experience Memory 的控制流。
新版数据底座不是替代 Harness，而是增强 Harness 的底层事实和治理面：
Solar Harness:
做调度、执行、验收、优化。
Solar Data Substrate 2.0:
做事实、证据、语义、契约、上下文、事件、投影。
接口边界：
Solar 现有层 | 新数据底座提供
-- | --
Requirement Compiler | RequirementIR schema、需求 lineage、acceptance tests
TaskGraph IR | PlanIR / ContractedPlanIR / node-level contracts
Operator Runtime | ExecutionBroker、Action lifecycle、risk-aware tool routing
Evidence ABI | EvidenceLedger、ClaimLedger、source/doc/block/event/action linkage
Plugin Framework | qmd、MinerU、CocoIndex、Obsidian、HTML renderer 插件
Event-sourced runtime | Runtime Event Ledger、State Projection、Replay Manifest
Deep Research OS | Source Registry、SolarDocIR、qmd deep-read、citation/evidence gate
Context Map plane | Context Compiler、ContextPack v3、semantic grounding
你上传材料里也点明了 replay 的真实难点：如果模型、外部 API、schema、权限、tool schema 发生 drift，replay 不能只是“重跑一次”，必须记录 model_version、prompt_projection、contract_version、concept_graph_version、tool_schema_version、input_snapshot、output_observation、policy_version、approval_event 等。
19. 90 天落地路线
Phase 0：1 周，架构清理
- 删除 MemPalace runtime 入口。
- 写 ADR-0001。
- 建 packages/solar_knowledge 和 packages/solar_compile 空包。
- 加 schema validation 基础设施。
验收：
grep 不出现 runtime mempalace.search / diary。
CI 能 validate schema examples。
Phase 1：2-3 周，Source + SolarDocIR + Evidence
- Source Registry
- Raw CAS
- Markdown -> SolarDocIR
- Evidence ABI v2
- kb search/read/toc native MVP
验收：
solar kb source add ~/Solar --type repo
solar kb ingest --changed-only
solar kb search "TaskGraph Evidence ABI"
solar kb read doc:... --section "System Architecture"
solar kb evidence resolve ev:...
Phase 2：2 周，qmd sidecar
- qmd plugin manifest
- qmd MCP adapter
- qmd_source_map
- qmd evidence normalizer
验收：
solar kb backend start qmd
solar kb index --backend qmd
solar kb search "Evidence ABI" --mode hybrid
solar kb toc doc:...
solar kb read doc:... --address "heading:System Architecture"
Phase 3：2 周，RequirementIR + Grounding-lite + PlanIR
- RequirementIR schema/compiler
- GEMS-lite registries
- GroundedRequirementIR
- PlanIR schema
- TaskGraph adapter
验收：
solar req compile --intent "升级 Solar 数据底座"
solar req ground req:...
solar plan compile --req req:...
solar plan export-taskgraph plan:...
Phase 4：2 周，Action Contracts + Context Compiler
- ActionContract schema
- Contract binder
- Static verifier
- ContextPack v3
- Context Compiler passes
验收：
solar plan bind-contracts plan:...
solar plan verify cplan:...
solar context compile --req req:... --plan plan:... --node node:... --mode execute
solar context verify ctx:...
Phase 5：2 周，Execution Broker
- Broker lifecycle
- Preflight policy gate
- Postflight verifier
- Event Ledger commit
- direct side-effect tool block
验收：
direct write action without broker blocked。
broker action lifecycle events are appended。
postflight failure triggers repair/compensation branch。
Phase 6：2-4 周，MinerU + CocoIndex + Obsidian + HTML
- MinerU parse worker
- CocoIndex flows
- Obsidian generated-only projection
- HTML renderer projection
验收：
solar kb parse ~/papers/test.pdf --parser mineru
solar kb materialize --flow all
solar kb obsidian sync --generated-only
solar kb render artifact:... --surface architecture-dossier
20. 最终产品体验
最终用户体验应该是这样：
solar boss "升级 Solar 数据底座，废弃 MemPalace，引入 GEMS-style grounding、Context Compiler、qmd、MinerU、CocoIndex、Obsidian 和 HTML 投影"
solar req inspect latest
solar req ground latest
solar plan inspect latest
solar plan verify latest
solar context inspect --node node:source_registry
solar run latest --enforced
solar dashboard
Solar 内部流程：
Boss Intent
-> RequirementIR
-> GroundedRequirementIR
-> PlanIR
-> ContractedPlanIR
-> ContextPack Family
-> Execution Broker
-> Operator Runtime
-> Observation
-> Postflight Verification
-> Event Ledger
-> Evidence Ledger
-> Accepted Artifact
-> Context Recompile
21. 最终判断
这版架构的核心不是“多接几个工具”，而是把 Solar 升级成真正的 agent execution operating system：
Requirement Compiler
让老板意图可验收。
GEMS Grounding Compiler
让需求里的词落到概念、来源、工具、策略、契约。
PlanIR
让计划从自然语言步骤变成 typed workflow。
Action Contract
让工具调用变成可验证、可组合、可治理动作。
Context Compiler
让上下文从 memory recall 变成编译产物。
Execution Broker
让 agent 不能绕过治理直接执行副作用动作。
Event Ledger
让发生过的一切可审计、可回放。
Evidence Ledger
让完成不是模型自称，而是证据通过 gate。
CocoIndex / qmd / MinerU / Obsidian / HTML
各归其位：增量物化、深读检索、文档解析、人工整理、交付阅读。
最终一句话：
普通 agent framework 让模型能做事；
Solar Data Substrate 2.0 让模型在正确上下文里，
用正确工具，按正确权限，执行正确动作，
留下正确证据，并在失败后可恢复。
这就是 Solar 的护城河。不是“又一个多 agent 框架”，而是：
需求可编译；
语义可落地；
计划可验证；
动作可治理；
上下文可审计；
执行可回放；
产物可验收。
这版设计把我们整个会话收敛成一个终极架构：
Solar 当前公开 README 已经把 Solar 定义为 long-running、evidence-driven execution fabric，并强调
intent -> contract -> PRD/plan -> TaskGraph IR -> operator binding -> lease -> dispatch -> handoff -> eval -> gate -> memory -> optimization；同时它也明确说 Solar 的价值观是 “requirements are compilable artifacts” 和 “Evidence defines completion”。这说明新版数据底座应该顺着 Solar 现有路线继续做“编译、调度、证据、治理”，而不是回到普通 RAG 或 memory plugin。0. 总命名
建议正式命名：
一句话定义：
中文定义：
1. 最终架构拍板
1.1 不能再做的事
这些直接砍掉，不要保留兼容幻想：
1.2 新架构的第一原则
旧模式：
新模式：
你上传的 Super Harness 材料也明确指出：context window 只能当 cache，不能当 source of truth；长程任务应该从 Fact Store、Event Ledger、State Projection、Episodic Trace 生成 bounded context projection，而不是靠大上下文或 vector memory 硬撑。
2. 终极目标架构图
GEMS 论文原始方案把缺口归纳为 semantic grounding、formal action contracts、governed memory，并设计了 GEMS Graph、Action Contracts、Governed Memory、Runtime Integration 四个研究目标；这套东西天然适合作为 Solar 数据底座升级的理论底盘。 但我们的改造要比 GEMS 原案更强：GEMS 不能只是 MCP sidecar，必须进入 Solar 的强制执行控制面。
3. 与当前 Solar 的接口关系
Solar 当前已经有这些核心能力：
公开 README 里已经明确：Solar Harness 负责从 Boss Intent 到 Sprint Contract / PRD、Plan + TaskGraph IR、Capability Annotation、Logical Operator DAG、Physical Operator Binding、Queue / Lease / Dispatch、Handoff / Eval / Node Verdict、Parent Gate、Accepted Artifact / Experience Memory 的控制流。
新版数据底座不是替代 Harness，而是增强 Harness 的底层事实和治理面：
接口边界：
你上传材料里也点明了 replay 的真实难点：如果模型、外部 API、schema、权限、tool schema 发生 drift，replay 不能只是“重跑一次”，必须记录 model_version、prompt_projection、contract_version、concept_graph_version、tool_schema_version、input_snapshot、output_observation、policy_version、approval_event 等。
19. 90 天落地路线
Phase 0：1 周，架构清理
验收：
Phase 1：2-3 周，Source + SolarDocIR + Evidence
验收：
Phase 2：2 周，qmd sidecar
验收：
Phase 3：2 周，RequirementIR + Grounding-lite + PlanIR
验收：
Phase 4：2 周，Action Contracts + Context Compiler
验收：
Phase 5：2 周，Execution Broker
验收：
Phase 6：2-4 周，MinerU + CocoIndex + Obsidian + HTML
验收：
20. 最终产品体验
最终用户体验应该是这样：
Solar 内部流程：
21. 最终判断
这版架构的核心不是“多接几个工具”，而是把 Solar 升级成真正的 agent execution operating system：
最终一句话：
这就是 Solar 的护城河。不是“又一个多 agent 框架”，而是：