shape

name	shape
description	在任务方向、需求、边界或关键系统形态还不可靠，用户只要求根因诊断，或新证据推翻既有方向时使用。接触真实代码、运行现场、用户价值和现实约束，与用户共同把请求收敛成可追溯需求、系统设计与可执行计划；适用于新 Task 初始塑形、方向变化、故障诊断、研究计划、跨模块功能、数据或状态模型、权限、公共接口、迁移、复杂修复，以及用户明确要求 shape、requirements、design、architecture、plan、implementation plan 或 root-cause analysis 的任务。方向和关键结构都清楚的低风险请求、范围明确且可在实现中追到局部根因的普通修复，以及直接实现、独立评审、完整测试或单纯讲解不触发。

shape

把请求塑造成可以诚实行动的形状

Shape 是确定需求和共同设计的过程。它负责消除那些会让后续工作走错方向或迫使执行者临场发明范围的未知：先让用户真正需要的结果和边界成立，再让系统形态、契约与后续工作路线取得足够证据。调查、需求和设计可以随着反馈往返，不把文件顺序当成僵化阶段。

用户的描述和既有计划只是入口；代码、运行现场、真实用户、现有契约和实际约束才决定当前系统是什么。能自行取得的事实先调查，只有价值、偏好、代价接受、风险承担和授权交给用户决定。结论只覆盖真正检查过的范围。

先找出当前真正不可靠的层

当前 Session 有 Active Task 时，先读它的 task.md、Task Operating Envelope、Git 意图和 Artifact Map，再核验真实对象。若本轮会形成可交接产物或改变 Task 判断，先用 longrein task work start 建立工作单元；Task Command 失败时不直接编辑 Runtime 核心文件。不要因为任务已经有 Goal 就假定根因和结构也成立，也不要因为技术方案很完整就假定它解决了用户真正的问题。

随着调查推进，始终区分：

• 事实：由代码、契约、数据或运行结果支持；
• 用户决定：用户明确选择、将约束后续价值、范围、风险或取舍；
• 专业决定：Agent 为满足用户决定和现实证据形成的根因解释、架构或实现判断；
• 开放问题：证据或决定仍不足，不能作为下游前提。

用户询问、质疑、表示没看懂或继续比较，不等于作出决定。先解释到他能够继续判断；只有明确的选择才改变任务承诺。

让现实产生足以区分路线的反馈

先沿真实入口、调用链、状态、数据、权限和消费者调查，再形成解释或方案。第一个合理原因、第一次成功实验和最先能跑的方案都只是证据，不自动成为根因或目标形态。

如果路线差异依赖尚未观察到的库行为、性能边界、数据分布、迁移结果、用户反应或失败模式，选择能区分候选解释的最小探针、重放或可丢弃原型。实验准备回答什么、实际观察到什么、它改变了哪项判断都要可说明；正式实现不借实验之名提前发生。

纯诊断默认只授权只读调查和无副作用的本地复现。会改变工作树、持久数据、外部系统状态或真实运行负载的探针，必须有来自当前请求或用户补充的明确授权；不能因为它有助于取得证据就自行扩大权限。

事实足够后，把仍有意义的差异做成用户能够反应的少量候选，说明各自得到什么、失去什么和推荐理由。候选方向已经成形、但仍藏着需要用户集中捍卫的重要决定时，可以使用 grill；Grill 改变方向后仍由 Shape 吸收结果并修订当前模型。

让决定停在正确的所有者手里

用户明确作出的价值、范围、非目标、完成条件、风险接受、兼容承诺和重要取舍，在 Active Task 中按 task 的规则记为 UD-###。Agent 的推荐、用户沉默和未确认候选不升级为用户决定。

根因结论留在诊断中并由证据取得资格，不因为它重要就冒充决定。为满足任务承诺而选择的所有权、模块边界、数据、接口、状态、失败恢复、迁移和实现顺序等关键结构判断，在相应 Shape 产物中记为 AD-###，并写明 Based on: <UD-*、事实或证据>。局部命名和机械实现选择不制造 AD-*。

新证据可以直接修订事实和 AD-*。如果专业上正确的路线必须改变 UD-* 或任务承诺，把冲突、代价和推荐交给用户；只有用户明确确认替换后才更新 Task Context。Shape 内部可以在方向与技术模型之间往返，不需要切换到另一个 Skill 才能继续调查。

Shape 的判断不会在交给 Dev 时冻结。实现会继续暴露此前不可见的事实、消费者和专业取舍；只要仍在当前用户承诺与授权内，Dev 直接按 Shape 的判断规则修订真正拥有结论的 requirements.md、design.md、contract.md、migration.md 或 Plan，补充或拆分需要独立审查的 AD-*，不另写一套只对代码生效的模型，也不为每个局部实现细节制造决定。若新路线会改变 UD-*、任务承诺、风险接受或授权边界，文档更新不能替代用户决定；停止依赖它的部分，把差异和选择交给用户。

按任务需要追到根因和系统形态

用户只要求诊断时，从具体触发、输入和状态出发，闭合实际因果链，区分根因、促成条件、影响范围、反证和未知。结论必须解释可观察故障并回到代码、日志、数据或复现证据；时间相关、看起来可疑或只解释部分症状的因素不冒充根因。纯诊断同时说明修复将触及的系统层次或边界，但在因果链和证据边界成立处停止，不自动修改代码，也不把候选修复写成已决定方案。

准备实施的任务如果仍会迫使实现者猜测关键所有权、边界、契约、状态、错误语义、迁移或施工顺序，继续完成技术塑形。非平凡架构或实现路线读取 技术塑形：从根因到可实施系统模型。纯诊断由本文件给出的因果链与证据要求收敛，不为取得诊断结论加载后续系统设计内容。结构简单且真实代码已经足以决定局部实现时，跳过技术塑形，不为形式完整制造设计。

Task Operating Envelope 决定系统需要在哪个现实范围内成立。正常负载、可信并发、平台重试、故障恢复、公共调用者和攻击面只有在项目中真实可达时才成为约束；有证据支持的 explicit exclusion 不生成锁、重试、扩展点或通用框架。现实推翻当前包络时，先修订 Context，不把新约束静默吸收进技术方案。

收敛成当前唯一有效的模型

Shape 可以收敛到两种不同终点：

• 诊断终点：因果链足以解释故障，影响和证据边界清楚，用户没有授权修改；
• 行动终点：Goal、Scope、Non-goals、Completion Evidence、Must Preserve 和相关 Operating Envelope 已可信；需求、设计和计划能够追溯，下一位不再需要猜测目标、关键结构、依赖和完成边界。

继续调查不会实质改变当前选择时就收敛；发现新的关键事实时重新打开受影响部分。存在 Active Task 时先修订真正拥有结论的当前产物：新事实用 task finding 登记，事实、假设或包络变化用 task context 增加 context_revision，用户批准的承诺变化使用 task context --decision UD-### 同时增加 scope_revision。Runtime 将结果写入 Task Timeline；任何 Skill 都不直接改写 .runtime/state.json、task.md 或 timeline.md。旧前提已经持续污染当前时间线时使用 rewind。

任务涉及代码或分支时，弄清 source_ref、working_branch 和 target_ref 的意图。现场状态与意图不一致且会改变结果时，把事实和代价交给用户确认，不从 checkout 反推承诺。

跨越多个决定或会话、当前对话不足以保存可靠探索状态时，读取 开放探索。

让需求、设计和共享计划各有一个权威来源

没有 Active Task 时在当前对话中交付，或只写用户指定的路径。当前 Session 有 Active Task，且结果需要跨轮继续、让用户打开或交接给下一位时使用：

<task-workspace>/
├── plan.md             # required：Shape 与 Dev 共享的完整路线、Phase 状态、结果和证据
└── shape/
    ├── requirements.md # required：详细需求、行为边界和可观察结果
    ├── design.md       # required：当前与目标系统模型、关键 AD 和承重关系
    ├── diagnosis.md    # 因果链需要独立交接时创建
    ├── contract.md     # 公共或跨模块契约需要成为独立事实源时创建
    ├── migration.md    # 迁移、混合版本和退出路线需要独立判断时创建
    └── evidence/       # 结论依赖可重放探针、复现或运行证据时创建

一旦持久化 Shape 工作，shape/requirements.md、shape/design.md 和根目录 plan.md 都必须存在：Requirements 按 Requirements 产物 demo 把 Task 承诺展开成后续工作能够引用的详细需求；Design 按 Design 产物 demo 保存当前模型、目标模型与关键专业决定；Shape 按 Plan 产物 demo 创建共享 Plan 的初始路线，动笔前读取 规划。独立根因遵循 Diagnosis 产物 demo，独立契约和迁移分别遵循 Contract 产物 demo 与 Migration 产物 demo。这些 Demo 是对应产物结构的唯一来源，正文只定义判断责任。

requirements.md 不复制 task.md 的 Goal、Scope 或 UD-*，而是引用它们并拥有更细的行为需求；design.md 不复制需求；plan.md 不重写需求或设计，只保存当前有效的完整路线及各 Phase 的真实状态、结果和证据。Shape 规则定义这些专业产物分别拥有什么结论，但不把它们变成只有 Shape 阶段才能修改的交接件：Shape 建立初始模型，Dev 根据实现证据持续修订源产物和 Plan；Review 独立检查代码、决定、文档与 Runtime 状态是否一致，默认不边裁决边改被审对象。只有某类关系需要被多个消费者精确引用或独立修订时，才拆出 contract.md、migration.md 等附属文件，并从所属主产物链接，避免平行事实源。持久结论依赖探针、复现或运行输出时，把可重放证据落入 shape/evidence/。

专业产物完成或发生会改变下游判断的修订后，用 longrein task artifact 分别登记路径、可信状态、确定内容和下一位读者，再用 task work finish 记录结果；阻塞时使用 task work block。不手工维护 Current Work、Artifact Map 或 Timeline。

边界

Shape 不把探针或原型包装成正式实现，不替 review 独立批准自己的结论，也不替 test 声称完整验证。范围明确的普通缺陷修复由 dev 沿错误路径追到局部根因并修复；只有诊断本身是交付物，或根因会改变方向、范围、公共契约、数据所有权或关键系统形态时才进入 Shape。方向和关键结构已经足够清楚且用户授权修改后交给 dev，Dev 仍在实现反馈中持续使用 Shape 的决定权限和产物规则；用户只需要理解已有对象时交给 walkthrough。