architect-boot

architect-boot

概述

这是 team-boot 的 Class Boots 目录中展示的五个 类引导 之一。team-boot 会在会话开始时注入始终相关的团队上下文（章程、CDR 索引、技能注册表）；此技能则按需加载架构决策层，即项目记忆中的已接受 ADR 索引，并附带一条记录建议，将新的架构选择引导至 /architect-specify，避免其不了了之。此引导不会写入文件：它会建议使用记录技能，由用户运行该技能。

读取决策和记录决策是一个循环：现有 ADR 为工作提供参考；工作过程中做出的决策则通过记录技能回流到同一套记录系统中。

何时使用

开始符合条件的任务时立即调用——在规划待办列表和开始实现之前——以便 ADR 上下文为规划提供参考。 切勿推迟到会话结束时再调用。

在以下情况下调用：

• 开始架构工作（系统设计、生成 AD.md、跨子系统重构、依赖项变更）。
• 会话进行中出现架构性决策：选择技术栈、选择模式，或出现“我们选择 X 而不是 Y”的情况。
• 审查或验证架构，且需要了解决策背景。

对于技术选型，还应调用 tech-radar-boot——雷达上下文应为 ADR 提供参考。

核心流程

步骤 1：定位 ADR 索引

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

1. 首选：docs/adlc/memory/adr/adr.md（由 /architect-implement 生成；行以 | ADR 开头）
2. 后备：.adlc/memory/adr/adr.md（旧版布局，旧版）

如果两者都不存在，但存在 docs/adlc/memory/adr/ADR-*.md 或旧版 .adlc/memory/adr/ADR-*.md 文件，则根据每个文件合成精简表格（从文件名获取 ID；从 frontmatter 或首个标题获取 Sub-System/Decision/Status）。如果目录为空或不存在，则报告 0 ADRs——绝不编造表格行。

如果当前工作目录中没有本地记忆索引，且该目录位于某个工作区内（通过祖先目录中的 .gitmodules 标记检测），则读取工作区根目录的 docs/adlc/memory/ 索引（应用双读取顺序：先读取 docs/adlc/memory，再回退到旧版 .adlc/memory）。

步骤 1b：读取 ADR 草案索引

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

上下文缺失

如果 team-boot 本次会话未注入团队上下文（首条用户消息中没有“团队上下文与决策”部分——项目未配置或钩子失败）：用一行说明此情况，输出章节标题，并附上 0 ADRs matched (no team context injected — run /team-setup) 来源行，然后继续根据直接读取的 ADR 索引执行任务。绝不要将缺少注入内容视为记录集为空。恢复方法：运行 /team-diagnose。

步骤 2：注入 ADR 上下文（输出约定）

在任务回答之前输出：

## ADR Context

| ID | Sub-System | Decision | Status |
|--|--|--|--|
| ADR-001 | lanes | Workflow lanes over flat queue | Accepted |

_Searched N ADRs, K matched._

## Drafts Pending Review

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

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

• 从索引中呈现 ID / Sub-System / Decision / Status（完整索引还包含 Date、Decision Makers、File——当任务与某一行匹配时，阅读对应的 ADR-*.md 文件）。
• N = 索引行总数；K = 与当前任务相关的行数。K 必须等于所显示的表格行数。 匹配 0 行时 → 只输出章节标题和 _Searched N ADRs, K matched._ 行，不输出表格。0 行的表头会折叠为未渲染的单行 Markdown；切勿输出此类表头。以 Markdown 块形式输出该章节——标题、表格行和计数行各占一行。

第 3 步：建议记录架构决策

触发条件	操作
技术栈选择、“我们选择了 X 而不是 Y”	ADR → 建议使用 /architect-specify（先加载 tech-radar-boot 上下文）
模式选择、结构性重构	ADR → 建议使用 /architect-specify
台账中已有 ADR 类决策	确认建议是否已显示；如果没有，则重新显示

对于检测到的每项决策，在可见回复中输出一行：

_Suggested capture: <decision name> → run /architect-specify._

绝不要自行编写草稿（或任何文件）——用户运行 /architect-specify 时，它会写入 .adlc/drafts/adr/ 草稿，之后由 /architect-clarify 对其进行把关。

为本次会话检测到的每项 ADR 类决策，在 团队上下文与决策 中添加或更新行（ID | 名称 | 类型 | 相关性 | 状态 | 澄清），包括本次启动前的决策。将每项决策同步为任务列表待办事项（对于已存在的草稿，在会话结束时建议依次运行 /architect-specify → 对应的澄清技能）；执行代码修改任务后，添加一项末尾待办，持续检查团队上下文与决策，直到 未记录：0 项待处理 · 未澄清：0 份草稿（草稿只能通过其澄清技能，或用户明确移交给指定的澄清或执行技能，才能从“未澄清”中移除）。在会话结束时，给出澄清提示，列出每项尚未捕获的决策（ID + 捕获技能），以及 .adlc/drafts/adr/ 中每份已捕获的 ADR 草稿（ID + 澄清技能）；如果用户推迟澄清，将这些行标记为已移交。

故障处理

• 缺少索引且缺少记录 → 仅输出章节标题 + _已搜索 0 份 ADR，匹配 0 项。_，不输出表格，然后继续用户的任务；绝不阻塞。
• 索引行无法解析 → 跳过格式错误的行，并注明跳过数量。

危险信号

• 编造 ADR 行，或将 K 虚增到超出表格所示数量。
• 添加索引，却忽略捕获建议——配对才是重点。
• 自行编写草稿（或任何文件）——启动流程只提供建议； /architect-specify 负责写入。
• 向上遍历父目录以查找 .adlc/。
• 有雷达上下文可用时，记录技术选择 ADR 却不包含该上下文。

验证

• 已输出 ADR 上下文表，并包含 _已搜索 N 份 ADR，匹配 K 项。_ （K = 表格行数）。
• 已将检测到的 ADR 类决策添加为团队上下文与决策中的行。
• 未写入任何文件；每项检测到的 ADR 类决策都附有 _建议捕获：… → 运行 /architect-specify。_ 一行。
• 技术选择决策已通过 tech-radar-boot → /architect-specify 处理。