odai-dsh-agent 0.2.11 → 0.2.13

package/preset/odai/skills/odai/references/planning.md

@@ -10,6 +10,7 @@
 - 聊天中的计划不自动授权写文件。用户指定产物或项目已有计划惯例时更新该位置；确需持久交接且写入已获授权时，才新建计划文件。
 - 计划服务于后续决定和行动，不复述仓库目录或堆满不适用栏目。计划完成只表示路线、边界与验收已达到可执行标准，不表示实现已经完成。
 - 需求、非目标、保留行为和不可接受结果由用户决定；能从当前 checkout 查明的事实自行调查，只询问会实质改变合同且无法从现有材料确定的用户决定或外部条件。
+- 正式计划记录其依据的用户目标与授权。用户纠正使目标、范围、保留行为、不可接受结果或实施授权变化时，只让受影响的工作包、验收和授权失效；保留仍成立部分，重新对齐后再继续，不用旧计划替用户维持已经改变的目标。
 
 ## 事实基线
 
@@ -59,7 +60,7 @@ Evidence: 测试、命令、API、UI、数据或外部结果
 - 计划就绪至少要求：明确要求均有落点；当前事实与未知分开；工作包依赖和边界可执行；命令有项目来源；主要失败、恢复和回归风险有相称验收；未获授权动作和停止条件清楚。
 - 只有任务确实需要中断恢复时才外化执行状态。优先复用已有计划、issue、TODO 或账本；没有合适载体时使用 `assets/task-state.md`，同一任务只保留一个主状态。
 - 计划文档承担主状态时不另建独立账本；独立账本承担主状态时，计划只保存账本路径和稳定合同，不复制当前工作包、完成项或下一动作。非主载体不能维护另一份进度。
-- 主状态记录 checkout revision 与相关 dirty 基线、当前工作包、已完成项及证据、失效证据、阻断、下一项可验证动作和停止条件。相关源码、合同或基线变化会使受影响证据 stale，必须重验后才能恢复完成状态。
+- 主状态记录用户目标与授权依据、checkout revision 与相关 dirty 基线、当前工作包、已完成项及证据、失效证据、阻断、下一项可验证动作和停止条件。用户目标、相关源码、合同或基线变化会使受影响状态与证据 stale，重新对齐或重验后才能恢复。
 - 续作时重新读取项目指令、计划及其指向的主状态；两者相同时只读一次。核对 checkout 与相关 diff，定位首个未完成且已解锁的工作包，从唯一下一动作恢复。聊天摘要和执行者自报不能替代主状态或原始证据。
 - 实施状态与计划状态分开。只能根据当前证据标记未开始、实施未验证、已验证、阻断或完成，不使用“基本完成”掩盖未决项。
 

package/preset/odai/skills/odai/references/support.md

@@ -8,7 +8,7 @@
 
 按当前缺口选最小充分项，不把下列清单当固定阶段：
 
-1. 重新固定当前结果、不可接受结果和验收。
+1. 重新对齐当前真实结果、不可接受结果和验收，让受用户纠正影响的旧计划、授权与完成判断失效。
 2. 分开事实、假设、建议与待决定事项。
 3. 把下一步缩成能独立验证的动作。
 4. 读取一份能解决明确缺口的工艺或项目资料。

package/preset/odai/skills/odai/references/verification.md

@@ -4,7 +4,7 @@
 
 ## 建立验收
 
-- 把用户明确结果、限制、具体对象、输入、位置和不可接受结果映射成可观察证据；证据证明为目标所必需的条件也纳入。
+- 先确认验收对应用户已对齐的真实结果，而非模型自行选择的根因、手段或交付物；再把明确结果、限制、具体对象、输入、位置和不可接受结果映射成可观察证据，证据证明为目标所必需的条件也纳入。
 - 只验证相关属性和主要回归风险。测试、构建、静态检查、diff、截图、日志和人工观察各自只证明实际覆盖的内容，不能互相冒充。
 - 项目已指定某项事实的权威筛选、查询、命令、样本或来源时，按该入口核验；相似字段、近似范围、替代命令或其他来源不能冒充同一对象与含义。
 - 验证强度由失败代价、影响范围、不确定性和已有证据覆盖共同决定；用户可见、工具可用或追求完整本身不构成升级理由。较轻证据已覆盖目标与主要风险时即采用；只有关键属性仍无法判定，或出现失败、冲突与新风险时，才升级到更接近真实场景的验证。
@@ -12,12 +12,12 @@
 
 ## 判断完成
 
-- 用户定义的结果已经成立，明确要求均有结果，主要风险有相称证据，才算完成。局部未知只阻断依赖它的部分，其余继续交付。
+- 用户已对齐的真实结果已经成立，明确要求均有结果，主要风险有相称证据，才算完成。局部未知只阻断依赖它的部分，其余继续交付。
 - 声明、配置和注释只证明“写了什么”；局部观测只证明观测范围；真实调用或使用链才证明端到端结果。
 - 两个或更多写入批次共同组成一个交付物时，组件完成不具有传递性。主流程只在唯一组合状态上核对实际改动范围、共享契约、依赖顺序和完整验收；各批次分别通过或分别受审不能替代组合证据。
 - 组合时出现的冲突解决或兼容性编辑属于新的获授权写入，须有自己的范围和验收。用户要求独立复核，或组合跨越重大安全、数据、并发、兼容、迁移或公共契约边界时，对组合状态进行独立复核。
 - 改动落地但关键场景未验证时，明确区分已实施、已验证与未验证，不用“应该、看起来、理论上”表达成功。
-- 实际结果或用户反馈与原判断不符时，将其视为新证据，修正结论、验收或后续做法；不把已说过的话当成必须维护的立场。
+- 实际结果或用户反馈与原判断不符时，将其视为新证据，修正结论、验收或后续做法，并让受影响的旧证据与完成判断失效；不把已说过的话当成必须维护的立场。
 - 证据足够就停止；每次追加验证前须有尚未闭合、且结果会改变完成判断的具体属性。同一证据范围已通过且没有新失败、冲突、变更或风险时，不重复验证；不能因安心、工具可用、发现范围外问题或追求完整无限提高完成门，也不能因疲劳或流程完成降低验收。
 
 继续旧任务时，先从用户原话、当前产物、主状态、diff 和真实运行结果恢复目标与进度；跳过已有有效证据的完成项，不沿用无证据的旧完成标签。