总目标

这一阶段主要是初始化代码仓库，形成项目的骨架，目标如下：

• 完成初始状态的设置，leader的职能分配
• 完成前端骨架的搭建
• 完成HTML worker 和manim worker的POC并准备接入主线

对比按工作流顺序开发来说，这三个阶段可以并行开发，能够大幅缩短开发所需的时间。

在完成这一部分之后会得到：

• 前端控制台骨架已经落地。你现在有了 frontend/manimind-console/，定位是 ManiMind 的可视化驾驶舱，用来展示阶段流、任务看板、Runtime、Context Packet、事件日志、Agent 状态、产物预览和 MVP 能力清单。文档里明确说它不是完整产品，而是先验证“项目状态、阶段流、任务看板和 Runtime 能否在一个页面里形成闭环感知”，并且要求前端不直接读写 runtime，只通过 backend API 访问状态。
• 做了“效果图 → 前端骨架 → 审查 → 修复 → 构建验证”的闭环。前端骨架对齐闭环记录.md 里写得很清楚：Pipeline Rail 改成等分布局，产物预览稳定为 2x2，Manim 播放按钮居中，缩略图高度压缩，四栏断点从 2xl 下调到 xl，并且 npm run build 已通过，首页 / 可静态生成，TypeScript 检查通过。这个已经不是“画了效果图”，而是把效果图转成了可运行前端骨架。
• 后端事件化链路也开始补上了。现在 FastAPI 应用入口已经挂了 projects、tasks、contexts、events 四类路由；其中 events.py 提供了 /events/message，可以把 worker.progress、worker.blocker、worker.result、review.decision 这类 Agent 消息写进项目级和 session 级 events.jsonl。这说明你之前路线里说的“runtime 事件链补成通讯总线”已经有了代码入口。

完成第一阶段后主要剩余问题如下：

1. 前端仍然是 mock 数据 console-demo.ts 里写死了项目状态、阶段、任务、事件、Agent、产物等数据。

2. 前端和 backend 还没有真正接线 目前 README 也明确说当前版本优先验证页面壳、布局切分、组件职责和 API 接线点。

3. Worker 执行器还没有真正成为主链路 后端能接收 worker.progress / blocker / result，但真实 Manim Worker / HTML Worker / Reviewer 还没有被统一执行器调起来。

4. Context Packet 仍偏 metadata scaffold 还不是读取真实论文、笔记、公式、脚本正文后拼出的 assembled prompt。

5. 产物预览仍是假数据 讲解脚本、分镜、Manim 动画、审核报告现在只是前端展示卡片，还没有绑定 outputs。