focalpoint 0.1.0__tar.gz

focalpoint-0.1.0/.gitignore

@@ -0,0 +1,5 @@
+.DS_Store
+__pycache__/
+*.pyc
+data/
+fpms/narratives/task-*.md

focalpoint-0.1.0/0-external-baseline/ARCHITECTURE.md

@@ -0,0 +1,151 @@
+# Architecture Baseline
+
+## 总体架构
+
+```
+GitHub / Notion / Telegram
+        │
+        ▼
+Adapters / Sync Layer
+        │
+        ▼
+FounderOS Cognitive Core
+  - local graph
+  - summaries
+  - focus
+  - alerts
+  - compression
+  - bundle assembly
+        │
+        ▼
+Founder / Agent
+```
+
+## 设计立场
+
+FounderOS 不拥有完整业务事实。
+
+FounderOS 拥有的是“认知层状态”：跨工具关系、压缩记忆、焦点、提醒、上下文编排。
+
+## 本地存什么
+
+本地 SQLite 或本地文件只保存以下内容：
+- `node_ref`
+  - `node_id`
+  - `source`
+  - `source_id`
+  - `source_url`
+- `cognitive_fields`
+  - `why`
+  - `summary`
+  - `next_step`
+  - `owner_override`（仅当外部没有统一 owner）
+- `graph`
+  - `parent_id`
+  - `depends_on`
+- `runtime`
+  - `focus_list`
+  - `stash`
+  - `last_alerts`
+- `compression`
+  - `compressed_summary`
+  - `last_compressed_at`
+  - `no_llm_compression`
+- `sync_cache`
+  - `cached_title`
+  - `cached_status`
+  - `source_synced_at`
+  - `source_deleted`
+
+## 不本地重复存什么
+
+默认不把以下内容作为本地主事实源：
+- 外部工具的任务主状态
+- 外部正文全文
+- 外部评论全文
+- 外部附件
+- 外部审计全历史
+
+需要时可以缓存，但缓存只用于：
+- 降级读取
+- token 裁剪
+- 最近一次同步快照
+
+## 读路径
+
+1. 选择当前 focus。
+2. 读取本地认知层数据。
+3. 对 focus 及其近邻节点实时拉取外部快照。
+4. 本地认知层与外部快照合并。
+5. 组装 L0 / L_Alert / L1 / L2。
+6. 注入 Agent prompt 或返回 Founder 查看。
+
+## 写路径
+
+### 写本地
+
+FounderOS 直接写本地认知层：
+- why
+- summary
+- depends_on
+- parent
+- focus
+- alerts dedup
+- compressed_summary
+
+### 写外部
+
+FounderOS 只在以下场景写回外部：
+- append comment / report
+- write decision summary
+- 明确授权的状态同步
+
+默认策略：
+- comment 写回可以先做
+- status 双向同步后做
+- 永远不要默认覆盖外部正文
+
+## 同步策略
+
+- 常规轮询：15 分钟
+- focus 实时刷新：开启
+- 同步失败：读取缓存并标记“可能过时”
+- 外部删除：本地保留认知层，但标记 `source_deleted=true`
+
+## 核心模块
+
+- `adapters/`
+  GitHub / Notion / Telegram 连接层
+- `sync/`
+  轮询、缓存、状态映射、降级
+- `graph/`
+  cross-tool parent / dependency
+- `memory/`
+  summary / why / compressed_summary
+- `attention/`
+  focus / stash / alert dedup
+- `bundle/`
+  Context Bundle 组装
+- `writeback/`
+  comment / summary 写回外部
+
+## 最重要的不变量
+
+1. 外部工具状态是事实源，本地镜像不是。
+2. 本地 graph 与 cognitive fields 是 FounderOS 的核心资产。
+3. 缓存丢失可以重建，graph 与 why 不可以随意覆盖。
+4. 外部写回失败不影响本地认知层一致性。
+5. Adapter 不可用时，系统降级但不应完全不可用。
+
+## v1 只做哪些外部工具
+
+- GitHub: 任务与代码执行主状态
+- Notion: 文档与方案上下文
+- Telegram: Founder 交互入口与提醒触达
+
+## 暂不做
+
+- 双向强一致状态同步
+- 多人协作权限系统
+- 外部工具全文镜像仓库
+- 通用 RAG 平台

focalpoint-0.1.0/0-external-baseline/PRODUCT-BASELINE.md

@@ -0,0 +1,77 @@
+# Product Baseline
+
+## 一句话
+
+FounderOS 是外部工具之上的认知层与控制层。
+
+它不负责替代 GitHub、Notion、Telegram；它负责把这些工具里的信息变成 Agent 和 Founder 都能直接工作的“认知工作台”。
+
+## 核心问题
+
+我们要解决的不是任务 CRUD，而是以下问题：
+
+1. Agent 跨 session 后，无法快速恢复对项目与决策脉络的理解。
+2. 信息分散在多个工具里，Agent 和 Founder 需要手动拼接上下文。
+3. 外部工具能存事实，但不能表达跨工具因果链、依赖关系和注意力优先级。
+4. 长周期项目会被遗忘，缺少跨工具的主动提醒和异常上报。
+5. Founder 需要的是控制能力，不是再维护一套新的任务系统。
+
+## 产品边界
+
+| 能力 | 外部工具负责 | FounderOS 负责 |
+|------|-------------|----------------|
+| 任务主状态 | GitHub Projects / Issue / Notion DB | 读取、映射、缓存，不作为主事实源 |
+| 文档正文 | Notion / GitHub / 外部文档系统 | 摘要、压缩、上下文抽取 |
+| 评论与讨论 | GitHub / Telegram / Notion comments | 跨工具聚合、决策提炼、必要时写回 |
+| 跨工具依赖 | 无统一承载者 | FounderOS 本地维护 |
+| why / summary / focus | 外部工具通常没有统一模型 | FounderOS 本地维护 |
+| Anti-Amnesia / Heartbeat | 单工具局部提醒 | FounderOS 跨工具提醒 |
+| Founder 控制入口 | Telegram / Agent 对话 | FounderOS 负责解释、校验、编排 |
+
+## 数据归属
+
+### 外部工具是事实源
+
+以下信息默认以外部工具为准：
+- title
+- status
+- assignee / owner（如果外部已有）
+- 正文内容
+- 评论历史
+- 原始更新时间
+
+### FounderOS 是认知源
+
+以下信息由 FounderOS 自己维护：
+- cross-tool parent / dependency 关系
+- why
+- summary
+- next_step
+- focus / stash / alert dedup
+- compressed_summary
+- sync cache 与 stale 标记
+- Founder/Agent 的决策摘要
+
+## 关键原则
+
+1. 外部工具优先，不重造轮子。
+2. FounderOS 只存外部工具存不了、算不出来、拼不起来的东西。
+3. 外部状态可以缓存，但缓存不是事实源。
+4. 写回外部是能力，不是前提。
+5. 本地认知层必须可审计、可回滚、可降级。
+
+## 非目标
+
+- 自建新的任务管理 UI
+- 自建新的文档编辑器
+- 自建新的聊天系统
+- 把所有业务状态重新迁移进本地数据库
+- 在 v0/v1 做多 Office 自动化公司操作系统
+
+## v1 成功标准
+
+- Founder 能在 5 分钟内看到跨工具全局状态与重点风险。
+- Agent 能围绕焦点任务自动组装跨工具 Context Bundle。
+- 关键依赖和 why 不再散落在多个工具里只能靠人脑记忆。
+- 外部工具短暂不可用时，系统可降级为缓存读取而不瘫痪。
+- Founder 不需要为系统再维护一套平行任务数据。

focalpoint-0.1.0/0-external-baseline/README.md

@@ -0,0 +1,48 @@
+# External-First Baseline
+
+这组文档定义 FounderOS/FPMS 的当前主线：
+
+**外部工具是事实源，FounderOS 是认知层与控制层。**
+
+旧文档不删除，但从现在开始，凡是与本文件夹冲突的内容，**以本文件夹为准**。
+
+## 这组文档解决什么问题
+
+我们不再优先解决“如何自研一个项目管理系统”。
+
+我们优先解决的是：
+- Agent 跨 session 的认知连续性
+- 跨 GitHub / Notion / Telegram 的上下文组装
+- 跨工具因果链、依赖链和焦点管理
+- 关键提醒、Anti-Amnesia 和中途校验
+- Founder 的自然语言控制与审计
+
+## 这组文档不做什么
+
+- 不重写 GitHub / Notion 的任务和文档 UI
+- 不自建完整任务录入和看板系统
+- 不把 FounderOS 做成新的知识库或聊天工具
+- 不要求先做完 standalone FPMS 再验证价值
+
+## 文件说明
+
+- `README.md`
+  这组文档的入口与优先级说明
+- `PRODUCT-BASELINE.md`
+  产品边界、问题定义、能力归属、非目标
+- `ARCHITECTURE.md`
+  外部工具为事实源时的系统设计
+- `ROADMAP.md`
+  外部优先路线下的分阶段交付计划
+
+## 文档优先级
+
+1. 本文件夹中的文档
+2. `/2-requirements/PRD-cognitive-engine.md`
+3. 其他历史文档（仅供参考）
+
+## 一句话定义
+
+FounderOS 不是新的项目管理工具。
+
+FounderOS 是架在外部工具之上的认知层与控制层：它连接事实、压缩历史、组装上下文、分配注意力，并帮助 Founder 与 Agent 做出更好的决策。

focalpoint-0.1.0/0-external-baseline/ROADMAP.md

@@ -0,0 +1,96 @@
+# Roadmap
+
+## 路线原则
+
+我们不先做一个完整的 standalone FPMS，再去接外部工具。
+
+我们从第一阶段就按“外部工具为事实源”实现。
+
+## Phase 0 — 文档与模型收口
+
+目标：统一产品边界和数据归属。
+
+交付物：
+- 本文件夹 4 份基线文档
+- 统一术语：FPMS = cognitive layer，不再定义为 project management engine
+- 统一数据归属表
+- 统一同步与降级策略
+
+验收：
+- 新 agent 只读本文件夹即可理解当前主线
+- 与旧文档冲突时有明确裁决规则
+
+## Phase 1 — GitHub-first Cognitive MVP
+
+目标：先围绕 GitHub 建立最小认知闭环。
+
+交付物：
+- GitHub Adapter
+- 本地 node_ref + graph + summary/why 存储
+- focus + heartbeat + L0/L1/L2 bundle
+- comment 写回能力
+- 缓存降级能力
+
+验收：
+- 给定一个 GitHub issue，FounderOS 能拉状态、补 why、建立依赖、组装 context
+- GitHub 短暂不可用时，仍能用缓存继续工作
+- Founder 可以通过 Telegram/Agent 查看重点任务与风险
+
+## Phase 2 — Notion Context Integration
+
+目标：把文档上下文接进来，而不是只看任务状态。
+
+交付物：
+- Notion Adapter
+- 跨 GitHub / Notion 的 context merge
+- 决策摘要与文档压缩
+- cross-tool dependency 支持
+
+验收：
+- 焦点任务的 context 中同时出现 GitHub 状态和 Notion 决策材料
+- Agent 可以解释“现在做什么”和“为什么这么做”
+
+## Phase 3 — Telegram Control Layer
+
+目标：让 Founder 真正通过自然语言控制，而不是手动翻工具。
+
+交付物：
+- Telegram 交互协议
+- 告警推送
+- shift_focus / explain / summarize / report
+- 中途校验与退出上报
+
+验收：
+- Founder 用 Telegram 就能看到重点风险、切换焦点、收到异常上报
+- Agent 的关键发现能推送给 Founder，而不是留在某个工具角落里
+
+## Phase 4 — Writeback and Reliability
+
+目标：把系统从“只读认知层”升级成“有限闭环认知层”。
+
+交付物：
+- comment / summary 写回外部
+- 状态映射配置化
+- 重试队列与离线恢复
+- Assembly Trace 可观测性
+
+验收：
+- 退出上报可稳定写回 GitHub / Notion
+- 网络抖动时请求不丢失
+- 可以解释某次 context 是如何被组装出来的
+
+## 明确不做的顺序
+
+以下事情不应排在前面：
+- 自建任务管理 UI
+- 自建完整状态机并要求所有业务迁移进来
+- 先做多 Office 自动化再验证单 Founder 工作流
+- 先做全量本地知识库再验证 context bundle 价值
+
+## 当前推荐优先级
+
+1. GitHub-first cognitive MVP
+2. Notion context integration
+3. Telegram control layer
+4. 写回与可靠性
+5. 多 Office 与更高层自动化

focalpoint-0.1.0/1-vision/PRD-goals.md

@@ -0,0 +1,52 @@
+# 3. 目标
+
+## 3.1 核心目标
+
+本系统要解决的不是"项目管理软件"的问题，而是"AI Agent 如何在跨 Session 场景下持续、高效、可控地管理复杂项目群"的问题。
+
+### G1. 跨 Session 认知连续性
+
+Agent 每次唤醒时，能在**秒级**（而非分钟级）恢复对所有项目的全局认知——包括当前状态、关键卡点、待办优先级和近期决策脉络。消除"每次对话从零开始"的根本瓶颈。
+
+### G2. 最小充分上下文注入
+
+系统根据当前任务自动组装**最高信噪比**的认知包（Context Bundle），精准推送给 Agent。不多不少——既不因信息缺失导致错误决策，也不因冗余加载浪费注意力和算力。
+
+### G3. 确定性与概率性解耦
+
+所有可由规则稳定计算的工作（状态流转、依赖冒泡、死锁检测、投影生成）由底层脊髓引擎确定性完成，**系统正确性不依赖 LLM**。大模型仅负责业务理解、策略判断和自然语言输出。
+
+### G4. 全局视图始终准确
+
+任何节点的状态变更，自动沿依赖图谱向上冒泡，保持全局看板、项目摘要和父节点状态**近实时一致且可重建**。无需人工维护，无需 Agent 逐层手动更新。
+
+### G5. 分形可扩展
+
+从原子任务到跨业务线的战略目标群，系统使用统一核心 Schema 与同一套引擎。结构应随业务增长保持可控扩展，避免因节点层级和依赖关系增长而导致复杂度失控。
+
+### G6. 次用户（人类监督者）体验
+
+人类监督者无需学习任何命令或语法：
+- **自然语言交互**：说人话即可下达指令和查询
+- **全局可见性**：随时掌握所有项目的进展、风险、卡点
+- **数据主权**：系统数据可审计、可导出、可回滚；叙事内容以 Markdown 保存，结构化状态以 SQLite 管理，关键变更可通过 Git 或事件日志追踪
+
+### G7. 成本可控（FinOps）
+
+系统级 token 管理开销（Context Bundle 组装 + 全局投影）占单次 Agent 调用总 token 的比例可量化、可优化。避免因项目管理上下文无节制膨胀导致 API 成本失控。
+
+### G8. 可恢复性
+
+所有全局视图、焦点列表与认知包都必须可由事实源重建。系统在任意时刻都可恢复到一致状态——派生视图损坏不影响数据完整性，重建即可修复。其中，结构化状态与关系以 SQLite 为事实源，叙事历史以 Markdown 为事实源；所有摘要、投影与认知包均为派生物，不构成第二真相源。
+
+## 3.2 非目标（v1 不做）
+
+| 非目标 | 原因 |
+|--------|------|
+| 可视化仪表盘（Dashboard） | v1 聚焦 Agent 内部认知引擎；人类监督通过自然语言 Tool Call 实现，无需独立 UI 层 |
+| 多人协作 / 权限管理 | v1 限定为单 Agent + 单人类监督者场景，不引入 RBAC、并发控制或多用户同步机制 |
+| ~~外部工具集成~~ | ~~已移入核心目标~~。认知引擎从第一天就通过 Adapter 集成 GitHub/Notion/Telegram，详见 PRD-cognitive-engine |
+| 自动化工作流引擎 | 认知引擎仅负责认知层（因果链、Context 组装、记忆压缩），不内建触发-动作规则链或工作流编排层 |
+| 自然语言解析器 | 完全复用宿主 Agent（OpenClaw）的 LLM Tool 解析能力；认知引擎不重复构建 NLP 层 |
+| 多 Agent 协调 | v1 设计为单 Agent 架构；多 Agent 协调、状态同步与冲突解决机制留待后续版本 |
+| 自动决策代理 | 认知引擎可主动告警（如卡点、超期），但不自动执行业务决策或替用户推进项目。业务决策权保留给人类监督者或宿主 Agent 策略层 |

focalpoint-0.1.0/1-vision/PRD-philosophy.md

@@ -0,0 +1,90 @@
+# 2. 设计哲学：向人类认知学习
+
+## 2.1 人类 Context 管理机制及启示
+
+人类能在有限工作记忆下处理复杂任务，不是因为记得多，而是因为具备高效的认知压缩、注意力分配和外部记忆协作能力。本系统借鉴其中最有效的机制，将其转化为 Agent 可执行的系统能力。
+
+| 人类机制 | 原理 | 可借鉴度 | 系统设计启示（认知引擎系统级补偿） |
+|----------|------|----------|-------------------------------|
+| **分块（Chunking）** | 工作记忆 4-7 块，每块可压缩复杂概念 | ✅ 完全映射 | 每个节点是一个认知块，一句话摘要即可恢复对该节点的认知 |
+| **叙事（Narrative）** | 故事比清单好记 10 倍，天然携带因果链 | ✅ 完全映射 | Context 以时间线叙事体组织，保留因果链和决策背景，绝不用无序 bullet |
+| **遗忘（Forgetting）** | 主动过滤噪音，是功能不是 bug | ✅ 机制模拟 | 已 Done 且无入度依赖的节点自动降权冷冻，保持工作区 Index 纯净 |
+| **周期回顾（Rehearsal）** | 周会/复盘对抗遗忘曲线 | ✅ 机制模拟 | Heartbeat = 系统替 Agent 开的「数字周会」，主动揪出风险项 |
+| **外化（Externalization）** | 承认记不住，借助笔记/日历/看板 | ✅ 完全映射 | 本地文件系统（SQLite+MD）+ 全局概览 = Agent 的外化「数字白板」 |
+| **关联触发（Association）** | 线索触发记忆链，一环拉出一长串 | ⚠️ 系统代偿 | Agent 无直觉，靠底层 DAG 图计算引擎实现确定性关系推导补偿 |
+| **聚焦（Focus）** | 任何时刻只深度关注一件事 | ✅ 机制模拟 | 焦点节点加载 100% 全量上下文，其余物理降级为一句话摘要 |
+| **联想打包（Bundling）** | focus 时大脑自动拉入相关背景 | ⚠️ 控制反转 | 摒弃 Agent 主动检索。由脊髓引擎将 parent/依赖方拼装打包，直接喂给 Agent |
+| **视觉分辨率（Foveal）** | 注视点高清，周边模糊但画面完整 | ⚠️ 机制模拟 | 焦点=中央凹（全量），近景=周边视觉（摘要），全局看板=整体大盘永不丢失 |
+
+## 2.2 大模型与人类大脑的关键差异
+
+设计不应只学习人类认知的优点，也必须正视 Agent 与人类在记忆机制上的根本差异。
+
+| 维度 | 人类（碳基大脑） | 我们的智能体系统（LLM + 底层基建） |
+|------|-----------------|----------------------------------|
+| Session 内记忆 | 极有限（4-7 chunks） | 极强（1M+ window），且通过多分辨率受控 |
+| 跨 Session 记忆 | 持续存在，模糊但不消失 | 通过本地文件与数据库图谱实现物理持久化 |
+| 检索方式 | 关联触发，潜意识自动浮现 | 摒弃工具摸黑搜索，采用确定性主动推流（DCP）极速注入 |
+| 遗忘 | 自动、智能、情绪加权 | 基于图谱入度规则与时间衰减的强制冷冻 |
+| 压缩 | 无意识自动完成 | 需要显式设计（如小模型异步跑批处理压缩） |
+| 背景意识 | 模糊但持续在线 | 通过三层分辨率（焦点/近景/背景看板）强行构建 |
+| 聚焦 | 自动、直觉驱动 | 需要底层状态机（Deadline/卡点）进行中断与强制调度 |
+
+### 核心洞察
+
+1. **人类有持续的背景意识，LLM 要么全知要么全盲。** 系统必须用「多分辨率眼球模型」弥补这个根本差异。
+2. **人类天生知道"现在最该关注什么"，LLM 没有这个直觉。** 必须通过底层心跳或显式指令强制分配注意力。
+3. **人类的注意力像眼球——注视点高清，周边模糊，但整体画面永不丢。** 系统需要「全量叙事 / 状态摘要 / 一句话标题」的连续分辨率梯度，而非「加载或不加载」的二元开关。
+4. **人类 focus 时大脑自动联想打包，LLM 不会。** 必须由底层代码（脊髓）代为完成图谱遍历，构建好「认知包（Context Bundle）」直接推给 LLM，绝不能让 Agent 浪费算力去自己 Pull。
+
+## 2.3 硅基 vs 碳基：系统的独特优势
+
+> 注意：这里的优势不单指 Agent（LLM），而是指「LLM 大脑 + 结构化底层系统」的完整混合体。
+
+| 维度 | 人类（碳基） | 智能体系统（硅基混合体） |
+|------|-------------|------------------------|
+| 回忆精度 | 模糊、会变形、会自我编造 | 100% 精确，写下即可万次无损读取 |
+| 并行逻辑 | 极弱（心算超过 3 步必错） | LLM 极弱，但底层代码状态机可 100% 严谨地瞬间完成几十个节点的级联冒泡 |
+| 结构化处理 | 费劲，极度消耗精力 | 机器天然擅长遍历 DAG，对 YAML/SQL 读写如飞 |
+| 情绪偏差 | 焦虑与疲惫会扭曲判断 | 纯粹基于权重和 Deadline 数学规则执行 |
+
+### 终极推论：为什么少数精准 Chunk 胜过海量原始数据
+
+人类只有 4-7 个 chunk 就能完成极其复杂的任务。不是因为记得多，而是因为**每一块都是精准的、高度抽象的**。
+
+外科医生做手术时脑子里不是整本解剖学教科书，而是精确到这一刀需要的那几个关键信息。Agent 应该追求同样的精准度。
+
+**这个类比可以精确展开：**
+
+| 维度 | 外科医生（人类认知） | 认知引擎（Agent 认知） |
+|------|---------------------|------------------------|
+| 手术前 | 阅读完整病历、影像、化验报告 | 底层脊髓引擎遍历完整图谱、依赖链、历史日志 |
+| 手术中脑子里有什么 | 只有这一刀的关键坐标：切入点、避让神经、止血位 | 只有当前任务的认知包：焦点节点全量 + 依赖摘要 + 风险标记 |
+| 手术中脑子里没有什么 | 不会回想昨天的晚餐、不会翻阅教科书第3章 | 不会加载已归档节点、不会塞入无关项目的历史 |
+| 关键信息从哪来 | 护士递器械、麻醉师报数据——**被投喂，不是自己找** | 脊髓引擎打包推送——**DCP，不是 RAG Pull** |
+| 全局画面 | 余光看监护仪（心率、血压、血氧）——模糊但持续在线 | 背景看板（全局概览）——一句话状态，永不丢失 |
+
+**为什么这种"精准提纯"在百万 Token 时代反而更重要：**
+
+1. **注意力是零和博弈。** Transformer 的 Softmax 注意力权重总和恒等于 1。塞入的 token 越多，每个关键 token 分到的注意力权重越低。这是数学，不会因为窗口变大而消失。无关信息不是中性背景板——它是物理层面的认知干扰弹。
+
+2. **"找得到"不等于"想得清"。** 模型能在 1M token 里找到一根针（检索），不代表它能在 1M token 的噪声里完成多步因果推理。检索和推理是完全不同的认知任务，后者对信噪比的要求高几个数量级。
+
+3. **延迟是物理墙。** Agent 的核心是高频 OODA 循环（感知→思考→行动→观察）。每次循环的 TTFT（首字延迟）与输入长度正相关。塞满 1M 意味着每次思考前要等几十秒——系统瘫痪。
+
+4. **成本是线性的。** 输入 token 成本与长度线性相关。Agent 每天执行上百次循环，无差别塞满 vs 精准提纯，年成本可能差 100 倍。
+
+5. **1M 是仓库容量，不是工作台面积。** 长上下文的真正价值在于"可访问全集"（低频精读一本厚书），不在于"每次循环都把全集塞进大脑正中央"。真正送进推理核心的，仍然是小而精的认知包。
+
+**因此，系统的使命是：**
+
+> 在当前任务下，以最小必要上下文，提供最高信噪比、可推理、可执行的认知包。Memory 系统的本质不是存储——存储已经不稀缺了——而是**注意力分配**。
+
+## 2.4 设计原则
+
+1. **控制反转（IoC）** — Agent 是被投喂者，不是检索者。数据找人，而不是人找数据。所有依赖梳理、状态冒泡、卡点打包，全由确定性底层系统算好，直接以极简格式推给 Agent。
+2. **最小充分上下文（Minimum Sufficient Context）** — 每次只注入当前任务恰好需要的信息量，不多不少。1M context 是仓库容量，不是工作台面积。优化目标是每个 token 的信息密度，不是总量上限。注入量按任务难度弹性伸缩（最小 5k → 20k → 200k → 500k → 1M），当大预算精度不够时逐级缩减、聚焦信噪比。具体分级见 SYSTEM-CONFIG。
+3. **精准胜于全面** — 结构化精准 Context 永远优于泛泛 RAG 碎片，无论窗口多大。Context window 增长的红利应用于更深度的思考，而不是囤积更多冗余。
+4. **抽象是系统的生命线** — 节点摘要质量 = 系统效率上限。必须有机制持续将冗长旧日志压缩为一句话背景。
+5. **分形自相似（Fractal）** — 从原子任务到公司战略目标，全部采用同一套 Schema，无限嵌套，降低系统解析复杂度。
+6. **算力与模式解耦（Brain-Spine Model）** — 绝不用概率模型做确定性算术题。概览大盘与执行链路物理隔离；死锁拦截与状态流转交由底层代码（脊髓）瞬间完成，大模型（大脑）仅负责业务策略的阅读与战术输出。