最高指示：本文档由主人全权管理，模型不可染指编辑

• 学习面板UI太难看，优化（且页面无法随触摸板滚动、顶部我的sub tabs不吸顶）！另外UI-BUG：显示不出InBand所在会话【后话】

• 询问的UI也要优化，更加客制化：搞中，待优化UI细节【后话】

• 悬浮按钮挂错地方（另外评估是floating or side panel更好）【后话：低优先级】

• 数据仍刷新不充分：需建立后端的【学习工作区创建，大纲、复习卡、工件呈现、笔记什么的有变】就推送前端刷新的机制，前端仅呈现和拉取：已基本完成

• 前端刷新还是有点不及时，尤其是：进学习->建纲->激活纲，都没刷新ui（大纲与当前激活。我手动触刷新才正常）怕第二阶段反覆【后话】

• 应有专门文件收集Dvl Labels；然后是Util/包的建立【后话】

• Ctx挂载，为什么有一些在LearningService外，有一些在内？最好统一【后话】

• 纲：要不要有agent对纲、课的额外批注？（掌握情况，明文目标...），批注还涉及数据结构和ToolApi【后话】

• 纲：课可绑定工件了？状态机是否已总（total:lesson-x:in-progress）？纲的数据结构/拓扑。树状就蛮好。以及大纲总状态机。是否总确立好了【第三阶段】

• 目录结构重做；review-plan重做（以及ad hoc（挂man）的伟大思想）；tools调整；core内严厉修正与权责正确抽离子模块已完成？【第三阶段】

• 会话的active纲目应保存在会话（不过纲目进展确是得存在工作区，勿混淆）：会话latest的纲目激活事件，决定该会话的激活纲目是哪个：基本修了

• 对了，确保。看看怎么让其更轻量（不 bootup 之前少注入上下文，不打扰用户正常使用/变成）：基本上【后话】

• 优化Prompt和引导性。现在凑合能用但有时会卡卡。另外，状态机可能有卡住风险，是否需要搞一个安全逃生模式（让模型强制跳去哪里，并让工具弹窗由用户确认）【后话】

• 工具调用不跨进程，未完成的重启后被补成失败。我们的Present基本能跟随生命周期，但需要确保边角细节也完善（未完成重启后，如何智能Obtain一个已经开启且未终结的Run）【后话】

• 老注入learning快照？已改为sys-prompt/asm，说能缓解，待彻底测试一下稳健性【后话】

• 当前激活的纲目，才给这个会话的prestep快照注入其复习（筛除非当前纲目复习）【后话】

• 引导模型串行使用工具，尽量减少并行，免得错误【后话】

• 工具返回：包掉“arguments obj错误”，这个误导模型的！【后话】

• 大纲操作的工具粒度的考量，是否已更趁手？【第三阶段】

• 全局 in-banding 的清晰防冲？（所谓我“空间语义逻辑”——上课一般是“创建后立马in-band present”，上课涉及摆弄状态机；而用户单独在学习tab里搞lesson run，不应涉及状态机的摆弄，in-band与否仅是是否立刻批改）【第三阶段】

• 纲目等东西的工具update失败，要在工具返回的作为一种密封类型。另外，每 turn 检测的阻塞最好返给 AI，而不是直接抛。是否已确立？【第三阶段】

• 复习计划。怎么把课程run（课后->创建review plan）当首期review-point了？如果是因课创建的review，可以无首期review-point。不过这涉及一个更远的问题：现在是 artifact，它是只是分了类型，是把它们都看作同样的，artifact id空间共享，还是说类型决定了一切：不能把各自的artifact id串了，只能在类型下的id空间？【第三阶段】

• 学习TAB->IN-BAND->新会话，实际上不可用，全无效果【后话】

• /learn 加用户init prompt【后话】

• present | run 相关老代码耦合了。是没落实好我设计的流程，没落实以模型为主脑的系统设计理念。现在落实了？【第三阶段】

• 一次in-band present，的流程、工具view卡重做？现在是否清晰合理？【第三阶段】

• get_run_outcome tool，为什么不再是get lesson outcome（原本想是传lesson id，run可以缺省（如果只有一个run））了？让模型传入具体run的确精确了，但会不会导致模型比较累？这是不错的，但是最好的粒度吗？【第三阶段】

• 工件内：工件为什么会出现“提交按钮”然后又“完成按钮”，应改得只有一个。工件没有alert提交反馈（设个timer，好让独立窗口展示，而内置在timer前掐了。或者是submit的提交返回值来指定alert）：好像也优化了？【后话】

• fdbk可让agent不再往report中复述题干：得在Prompt中指出【后话】

• 之后可能会涉及一个场景：根据用户要求对一个课程（工件。不改大纲）的重做，怎么办呢？update binding能不能换绑嘛？整个机制也是否流畅（模型直接忽视旧的工件，新建一个工件，最后把那个工件更新绑定，旧的就变成游离工件）【后话】

• 要不要搞一个专门用来创建工件的（传入html，类型，取得工件id？那如果用这个的话，要不要直接变成允许现有的工件直接update，它就可以取代掉上面那个换绑呢？这样上面那个就变成绑定跟解绑，不用关心换绑），而不是让模型手动去搞哈希和手动放文件？也就是：所有的工件，以后最好提供edit工件的工具，统一新建写入和编辑已有。免得模型创建tmp（很容易烦他）->计算哈希->复制。这是个大流程，需要从长计议【后话】

• 打前、后端日志（后端ctx.logger，前端console.log）【后话】

• "氛围学习"、"学习工作区"的反应式正确性：基本修好了

额外说明（自看）

• 或许提醒助教模型：run的放弃不代表课程被放弃（可以重开run）。工具（present）超时不等于run被放弃（可以之后get result）...
• 模型是主脑，系统只是在生命周期、流程上辅助。状态流转（除了fsrs时间自己过，在快照被注入）一般也都是模型弄为主。prompt是在“引导模型”
• present=in-band（有且仅有这种情势）=its toolcall=run所有权占用与释放=会超时。direct不算真present。run本身是创建（hash文件夹存在）和终结（outcome在），且无需要维护的内存状态