项目背景
个人同时使用 Codex、Claude、TRAE 等 AI 工具推进多个项目时，目标、进度、下一步与关键决策散落在对话、Markdown、Git 和本地目录中。工具可以继续写代码，却很难回答项目为何做到这里、离 MVP 还差什么、上次离开时发生了什么。
通用 Todo 或项目管理工具能够记录任务，但不能天然区分可信项目事实、AI 运行信号和推测结果。AI Project OS 因此从本地优先和可确认事实出发，把项目连续性而不是更多自动化作为首版核心。
用户与需求
个人 AI Builder
在一个 Dashboard 中看到多个项目的真实状态、当前里程碑和唯一下一步。
跨工具开发者
在不同 AI 编程工具之间传递同一份已确认项目事实，而不是反复解释上下文。
暂停后返回的项目负责人
通过最近一次 Context Snapshot 快速恢复已完成、剩余范围、失败尝试、决策和 Blocker。
我的角色
产品定义 / 系统设计 / AI 协作开发 / 交付验收
- 从多项目并行和 AI 会话中断问题出发定义产品目标、MVP 与版本边界
- 区分 Project State、可信 Progress、Activity Log、Context Snapshot、XP 和运行时信号的职责
- 设计 Dashboard、项目详情、暂停/恢复、协议同步、Workflow Profile 与首次接入流程
- 通过预览确认、冲突选择、事务回滚和事件幂等规则约束高风险写入
- 以单一 P0 纵切推进 AI 协作开发、自动化测试、打包、UI smoke 与证据复核
核心问题
项目状态分散且容易失真
对话、任务勾选、文件时间和代码命中都可能被误读为真实进度，需要由 Roadmap 事实与确定性规则重新计算。
暂停后无法快速恢复现场
普通日志只说明发生过什么，却不能完整保存离开时的已完成、剩余范围、失败尝试、关键决策与下一步。
跨工具接力存在双写风险
不同 AI 工具和本地应用都可能修改项目状态；若没有可移植协议、字段来源与冲突确认，更新会静默覆盖。
产品或流程方案
本地项目总览
Dashboard 从 SQLite 项目事实和确定性规则生成 Active、Paused、Completed、Archived、Continue、Near MVP 与 Needs Attention，不制造空推荐。
可信进度与唯一下一步
进度只由显式 Milestone/Task 权重和完成状态计算；Active 项目始终保留一个具体 Next Action，变更写入 Development Log。
Context Snapshot 状态闭环
暂停前先预览并确认完整 Snapshot；恢复时展示最近现场并要求新的 Next Action，历史快照不会被覆盖。
可移植协议与工作流桥接
用 .project/project.yaml 保存当前事实、status.md 镜像最近 Snapshot，Workflow Profile 只声明安全相对路径；所有冲突逐字段人工选择。
AI 在项目中的具体作用
AI RESPONSIBILITIES
AI 负责辅助
- 辅助梳理用户问题、PRD、状态模型和可验证任务切片
- 在已冻结边界内协助实现 Electron、React、SQLite 与协议读写纵切
- 生成测试候选、失败场景和交付证据，帮助发现规则与 UI 的不一致
- 通过桥接 Skill 将已确认目标、MVP、里程碑和下一步归一化为预览候选
HUMAN GATES
人保留最终决策
- AI Project OS 不自动执行外部 Skill、Hook、脚本、命令或来源文本中的指令
- 项目创建、Snapshot、协议写回、冲突裁决和 Workflow Profile 均需先预览再确认
- 代码、任务勾选、文件时间和 AI 总结不能直接改变 Progress、XP 或完成状态
- 冲突字段由用户逐项选择；文件指纹变化、取消或验证失败保持零写入
信息架构或功能架构
项目事实层
连续性层
可移植协议层
反馈与证据层
数据与技术方案
- 桌面端
- Electron Forge / React / TypeScript
- 本地数据
- node:sqlite / 事务迁移 / 事件账本
- 可移植协议
- YAML Document AST / Markdown Snapshot / 原子替换与恢复
- 安全边界
- contextIsolation / sandbox / 窄 IPC / 预览确认 / 相对路径校验
设计及开发过程
- 01
冻结产品事实边界
先定义 Project State、Progress、Snapshot、Activity Log、XP 和外部信号的职责，避免把展示原型或 AI 推测写成产品事实。
- 02
建立本地运行与领域基座
完成 Electron 安全骨架、SQLite 迁移、领域模型、可信进度、Health、推荐和 XP 幂等规则。
- 03
实现项目连续性纵切
按 P0-04 至 P0-07 建立项目收录、Dashboard、Roadmap 编辑、Development Log 与 Active—Paused—Active Snapshot 闭环。
- 04
打通跨工具协议
实现 .project 双文件读写、字段级冲突预览、Workflow Profile 和 Codex 项目首次 bridge bootstrap 接入。
- 05
补齐反馈与发布门
用事件账本完成 Task、Milestone、Achievement、撤销重做和正式归档反馈；下一阶段以真实项目完成发布验收。
当前成果
当前本地工作区已完成 P0-01 至 P0-10：从安全运行基座推进到 Dashboard、可信 Roadmap、Snapshot、.project、Workflow Profile、首次接入和 XP/Level 闭环
最终 npm run check 通过 25 个测试文件、133 项测试，并完成 Windows x64 package、packaged 双启动 runtime smoke 与生产依赖审计
隔离 packaged Electron UI smoke 输出 42 张截图，覆盖浅/深主题、1320/1000/760、键盘焦点、XP 发放—撤销—重做和正式归档
建立预览确认、字段级冲突选择、文件指纹复核、SQLite 事务回滚和 XP 事件幂等边界，失败或取消时不产生半套写入
项目限制与反思
一个可信的 AI 产品案例，不只展示已经完成的部分，也需要说明目前的边界和下一轮验证重点。
- P0-11 六个真实项目的重启恢复与发布验收尚未开始，因此当前不能表述为正式发布版本
- 现有成果来自本地代码、自动化测试、打包和隔离 UI smoke，不代表用户增长、效率提升或商业结果
- v0.1 不做父目录自动扫描、后台监听、AI 自动总结、外部 Skill 自动执行或主动项目 Agent
- P0-10 已完成验证并形成独立提交，但仍需通过 P0-11 的六个真实项目发布验收
下一步计划
- 01按 P0-11 接入至少 6 个真实项目，验证重启恢复、状态、Roadmap、Snapshot 和 XP 账本
- 02完成真实 Codex 项目的 bridge bootstrap—OS 采用—再次同步闭环验收
- 03记录真实使用中的恢复时间、冲突类型、失败案例与人工修正，而不是预设效率指标
- 04在发布门通过后再评估 v0.2 的目录扫描、执行信号和可选只读适配器