product-boot

product-boot

概述

这是 team-boot 的 Class Boots 目录中列出的五种 class boots 之一。team-boot 会在会话开始时注入始终相关的团队上下文（章程、CDR 索引、技能注册表）；此技能会按需加载产品决策层——项目记忆中的 Accepted PDR 索引——并配合决策记录，确保新的产品选择会被记录下来（/product-specify），而不是不了了之。

读取决策和记录决策是一个闭环：现有 PDR 为工作提供参考；工作期间做出的决策则会回流到同一记录系统中。

使用时机

在匹配的任务开始时调用——先于待办事项规划和实现——让 PDR 上下文为规划提供参考。绝不要拖到会话结束时。

在以下情况调用：

• 开始产品工作（生成 PRD、定义功能、规划路线图、制定 GTM 决策）。
• 会话进行中出现产品相关议题：功能范围、用户画像定义、变现、定价或目标市场选择。
• 审查现有产品的决策背景（/product-analyze、/product-roadmap 可从已加载的索引中受益）。

核心流程

第 1 步：定位 PDR 索引

从当前工作目录开始（不要向上遍历父目录）：

1. 首选：docs/adlc/memory/pdr/pdr.md（由 /product-implement 生成；行以 | PDR 开头）
2. 回退：.adlc/memory/pdr/pdr.md（旧版布局，ADR-401 之前）

如果两者都不存在，但存在 docs/adlc/memory/pdr/PDR-*.md 或旧版 .adlc/memory/pdr/PDR-*.md 文件，则根据每个文件合成一个精简表格（ID 取自文件名；Feature-Area/Status/Title 取自 frontmatter 或首个标题）。如果目录为空或不存在，则报告 0 PDRs——绝不要编造行。

如果当前工作目录中没有本地记忆索引，且该目录位于工作区内（通过某个祖先目录中的 .gitmodules 标记识别），则读取工作区根目录下的 docs/adlc/memory/ 索引（遵循 ADR-401 双重读取顺序：优先读取 docs/adlc/memory，再回退到旧版 .adlc/memory）。

第 1b 步：读取 PDR 草稿索引

检查 .adlc/drafts/pdr/ 中是否有 frontmatter 包含 status: proposed 的 PDR-*.md 文件。这些是待澄清的 PDR 草稿。从每个文件中收集 ID / Title / Type / Status / Date。如果目录为空或不存在，则报告 0 pending drafts。

缺少上下文

如果 team-boot 本次会话没有注入团队上下文（首条用户消息中没有 Team Context & Decisions 部分——项目未配置或钩子失败）：用一行说明这一点，输出该部分标题，并添加 0 PDRs matched (no team context injected — run /team-setup) 来源行，然后继续任务，使用直接读取的 PDR 索引。绝不要将缺少注入内容视为记录集为空。恢复方法：运行 /team-diagnose。

第 2 步：注入 PDR 上下文（输出约定）

在任务答复前输出：

## PDR Context

| ID | Feature-Area | Status | Title |
|--|--|--|--|
| PDR-048 | triage | Accepted | AI triage scoring |

_Searched N PDRs, K matched._

## Drafts Pending Review

| ID | Title | Type | Status | Date |
|----|-------|------|--------|------|
| (from .adlc/drafts/pdr/) |

_N pending drafts — run /product-clarify to review._

• 从索引中呈现 ID / Feature-Area / Status / Title（完整索引还包含 Category、Date、Owner——任务与某一行匹配时，读取对应的 PDR-*.md）。
• N = 索引行总数；K = 与当前任务相关的行数。**K 必须等于所示表格的行数。**若匹配 0 行 → 仅输出该部分标题和 _Searched N PDRs, K matched._ 行，不要输出表格。0 行的表头会折叠为未渲染的单行 Markdown；绝不要输出这种表格。该部分应以 Markdown 块形式输出——标题、表格行和计数行各占一行。

第 3 步：记录产品决策

触发条件	操作
功能范围变更、纳入／排除决策	PDR → 直接写入 .adlc/drafts/pdr/
用户画像定义或修订	PDR → 直接写入 .adlc/drafts/pdr/
变现、定价、目标市场选择	PDR → 直接写入 .adlc/drafts/pdr/
台账中已有 PDR 级决策	确认已记录；若未记录，则重新提出

为本次会话检测到的每项 PDR 级决策，在 Team Context & Decisions（ID | Name | Type | Rel Status | Clarify）中新增／更新行——包括本次启动之前的决策。将每项决策同步为任务列表待办事项（草稿 → 在会话结束时运行 /product-clarify）；代码修改任务完成后，添加一条最后的待办事项，持续检查 Team Context & Decisions，直到达到 Unrecorded: 0 pending · Unclarified: 0 drafts（草稿只能通过其澄清技能，或由用户明确交接给具名的澄清或执行技能，才能从 Unclarified 中移除）。在会话结束时，提供澄清提示，列出 .adlc/drafts/pdr/ 中记录的每份 PDR 草稿（ID + 技能）；如果用户推迟澄清，则将这些行标记为已交接。

失败处理

• 索引缺失且记录缺失 → 仅输出章节标题 + _Searched 0 PDRs, 0 matched._——不输出表格——然后继续用户的任务；绝不阻塞。
• 索引行无法解析 → 跳过格式错误的行，并注明跳过数量。

风险信号

• 编造 PDR 行，或将 K 夸大到超出表格所示数量。
• 插入索引却忽略记录操作——配对才是重点。
• 沿父目录向上查找 .adlc/。

验证

• 已输出 PDR Context 表，并包含 _Searched N PDRs, K matched._ （K = 表格行数）。
• 已将检测到的 PDR 级决策添加为 Team Context & Decisions 行。