assess-pivot-impact

评估转向影响

当产品的意图发生变化，已交付的现实不再与之匹配时，此技能负责从“我们决定转向”到“每项现有承诺都有明确去向”的书面交接。它不会改写愿景层，而是产出一份清单，让改写建立在诚实的基础上。

**定位：**用户确定新方向之后，/define-project (update) 重写 docs/product/vision.md 或 docs/architecture/ 之前。与 realign-spec（代码是真相 → 修正规范）和棕地项目中的 define-project create（代码是真相 → 正式确认）相反。与 scan-architecture（不依赖愿景的深入分析）相反。计划中途失效仍由 reroute-plan 处理。

铁律

NO VISION OR ARCHITECTURE DOC IS REWRITTEN FOR A PIVOT
UNTIL EVERY CONTRADICTED SHIPPED FEATURE AND LIVE ARCH-N
HAS A USER-CONFIRMED DISPOSITION IN THE LEDGER

截止日期、投资者更新、董事会演示文稿或“这事已经定了”，只会改变何时汇报，绝不会改变项目文档声称产品已发生变化之前必须满足的条件。

适用场景

仅当以下条件全部满足时使用：

1. 项目有愿景或架构层（docs/product/vision.md 和/或 docs/architecture/），或者 docs/specs/INDEX.md 中有已交付的功能。
2. 用户希望确定新的产品方向、新目标或新不变量。
3. 该方向与至少一项已交付/已实施的功能、现有 **GOAL-N**、现有 **ARCH-N**、非目标或硬性约束相矛盾——通过对照上述文件与用户说明的意图即可观察到。

如果条件 (3) 不成立——只是措辞调整，或新增目标且没有冲突——则此技能不适用。请告知用户使用 /define-project (update)，然后停止。

此技能写入的内容

恰好一个持久化产物：

docs/product/pivot-ledger.md

（如果用户要求在确认前不写入文档，则写入 .skills/pivot-ledger.md；格式相同。）此技能绝不会自行写入 docs/product/vision.md、docs/architecture/** 或功能的 requirements.md。

define-project 仍是愿景层的唯一写入者。plan-milestones 仍是 docs/roadmap/INDEX.md 的唯一写入者。确认清单后，告知用户运行 /define-project (update)——Agent 绝不会自动运行它（disable-model-invocation: true）。

步骤

1. 清点与新意图冲突的内容

依次阅读：docs/product/vision.md、docs/architecture/INDEX.md（以及任何领域文件）、docs/specs/INDEX.md，以及新意图涉及的每个状态为 Status: Shipped 或 Implemented 的功能对应的 requirements.md。如果矛盾涉及具体模块，则快速浏览这些规范中列出的源代码路径。

整理候选集：

类型	来源
功能	docs/specs/INDEX.md 中每个状态为 Shipped / Implemented 的条目
目标	每个现有（未删除线标记的）**GOAL-N**
不变量	每个现有 **ARCH-N**
非目标 / 硬性约束	新意图所要推翻的愿景非目标和范围硬性约束

完成标准：候选集已列出，且每一行都标明文件路径或 ID。

2. 编写处置台账——先于任何其他持久性编辑

将其写入用户指定的应用仓库，而不是写入恰好存放此技能文件的技能包检出目录。如果会话根目录与指定仓库不同，请 cd（或使用绝对路径写入）指定仓库。路径已明确给出时，不要停下来询问哪个仓库才是目标。

填写每个候选项的行。处置方式包括：

处置方式	含义
保留	仍可原样满足新意图
调整	仍然保留，但必须更改（之后进入常规规格周期）
退役	有意移除
弃用	暂时保留；需要截止日期和迁移路径
冻结	不再投入；不要删除
拆分迁出	移至其他仓库或产品
接受债务	已知矛盾；继续与之共存（之后必须通过 define-domain 创建 ADR）
未知	证据不足 → 暂停处理该行；注明 research 或 run-spike

每行还要用一行记录根深程度：是否已交付给用户？是否为公共 API？是否涉及数据架构？是否已经迈过单向门？转向的代价取决于这些承诺的成本，而非新愿景的优雅程度。

拟议处置由 Agent 提出，不代表已作出决定。

完成条件：指定仓库中的 pivot-ledger.md 已落盘，每个候选项各有一行，且尚未修改任何愿景或架构文件。只在聊天中选择 C 而不创建文件，不算完成。

3. 与用户逐行确认

逐行审阅台账。用户可以逐行确认、改选或标记为未知。将用户的选择及其提供的任何理由原样记录。不要为了赶时间而捏造确认。不要把“转向已决定”擅自理解为“全部批准”。

“转向已决定”确定的是方向，并不代表已经决定对 SCAN、CAT、ALERT、SYNC 或 ARCH-3 采取保留、调整或退役等处置。

如果本轮无法实时确认（单次调用／非交互式），将每行保留为 Proposed，不触碰愿景／架构文件，然后停止——仍然必须创建台账文件。

完成条件：台账文件中的每一行都已标记为 Confirmed（或标记为 Unknown 并附有明确的后续行动），或者每一行都标记为 Proposed 并明确注明需停止并等待确认。

4. 交接——不要自行编写愿景层内容

仅在完成步骤 3 后：

1. 为用户指定 /define-project（更新模式）——该技能负责写入 vision.md / architecture/、保持目标／ARCH ID 不变（使用删除线，绝不重新编号），以及通过 define-domain 创建 ADR。
2. 对每一行 退役／弃用／调整的条目，指定下一步工作单元（功能分支、小型规格或跟踪事项）。不要在此技能中悄悄删除已交付的代码；台账是决策记录，不是删除操作。
3. 如果存在路线图且目标发生变化，注明愿景层更新后需要由 plan-milestones 再审视一次——不要在此处编辑 docs/roadmap/INDEX.md。

完成条件：用户拥有已确认的台账和明确的下一条命令（/define-project），且此技能未写入任何愿景／架构内容。

哪些不算处置台账

以下是在时间压力下出现过的具体失败案例。它们都不符合铁律：

• 将 vision.md 改写成新故事，同时在同一次编辑中将旧 ARCH 条目标记为“已取代”
• 在已批准的愿景文档末尾添加“迁移仍在进行”说明
• 在改写后的目标列表下方添加 Risks 脚注
• 只在聊天中口头列出事项，而没有创建持久化台账文件
• 为了赶时间，在未经用户确认的情况下将每一行一律标为 Adapt

合理化说辞

想法	现实
“限制因素是时间 / 下午 5 点要向投资人汇报”	时间只会改变你汇报的时间。发布一份已批准的愿景，而代码和已发布功能仍与之矛盾，这不是更快地写出真实文档，而是一份虚假文档
“C 是最严谨的选项，但不适合赶时间”	那么诚实的产出应是尚在编写的台账，加上“尚未开始重写愿景”，而不是一份润色过的虚假愿景
“投资人文档指的是愿景和架构文件，不是处置结果”	如果投资人读到新论点，而 ARCH-3 和 ALERT 仍描述旧产品，那他们看到的就是虚构内容。台账能让新论点承担责任
“无法在 80 分钟的实际来回沟通中完成处置确认”	那也不要在这 80 分钟里重写 vision.md。部分台账加上暂停，胜过完整的谎言
“照章选 C 只是演戏，所以 A 更好”	演戏式的 C 和 A 都违反铁律。真正的 C 要花多少时间，取决于确认需要多久
“方向已经定了；我不会重新讨论这个转向”	方向已确定。但各项功能的去留是另一个问题——直接回答，不要重新争论方向
“我已在新的已批准愿景中标注迁移尚未确定”	脚注不是已确认的台账。状态为“已批准”且迁移仍未确定，正是问题所在
“我自己来写愿景；define-project 只是走形式”	该文件只有一个写入者。指定 /define-project
“我在回复中选了 C——这就是处置结果”	磁盘上没有台账文件的 C 仍然算遗漏。创建文件
“会话根目录是另一个仓库；我得问哪个才是真的”	用户已给出路径。在那里写台账。不要因确认路径而停滞

危险信号——停止

• 你正准备在此技能中编辑 docs/product/vision.md 或 docs/architecture/**
• 你正准备把“转向已定”视为对每项功能去留的确认
• 你正准备因为今天要做演示文稿 / 汇报 / 董事会会议而跳过台账
• 你正准备未经用户确认就将行标记为已确认
• 你正准备自行启动 /define-project，而不是告知用户使用它
• 你正准备在编写台账时删除已发布的功能代码
• 你正准备将此技能用于与愿景无关的重构 → 应使用 scan-architecture
• 你正准备把代码当作事实，并据此重写规范 → 应使用 realign-spec
• 你结束了本轮对话，选择为 C，但指定的仓库中磁盘上没有 pivot-ledger.md
• 用户已经给出仓库路径，你却仍要求用户确认路径

无需操作

• 没有项目文档层 且 没有 docs/specs/INDEX.md → 没有需要重新指向的内容；指定 /define-project（创建）或功能工作流，然后停止。
• 新意图与任何已发布内容都不冲突 → 指定 /define-project（更新）；此技能在未创建台账的情况下停止。
• 仅执行过程中的计划失效 → 使用 reroute-plan，而不是此技能。

完成条件： 已存在处置台账，所有非 Unknown 行均已由用户确认，此技能未编写任何愿景 / 架构文件，并且已告知用户运行 /define-project（更新）来重写文档。