设计架构（Design Architecture）
开始使用时需要声明：“Using the design-architecture skill.”
前置条件
你需要在工作树（worktree-discipline）中工作，并通过 merge-change 集成变更。
本设计所服务的需求已经存在于 SRS 中；或者 develop-change 向你提交了一个需要设计变更的架构发现。若两者皆无，先运行 grill-requirements。
从 .guardrails/config.yaml 读取 safety_class 以及各分类账路径（doc_sad、SOUP 清单 docs/architecture/soup.md）。
步骤
条目存放位置。将新的 SDD 和 LLR 条目写入本次变更自己的文件 docs/architecture/<YYYY-MM-DD>-<slug>.md，日期为创建当日。对已有条目的修订，写入定义该条目的日期文件。soup.md 保持为单一清单文件。
先读：本设计所服务的 REQ、约束本设计的控制项（RC）、CONTEXT.md（使用项目自身语言）、guidelines-file.sh ARCHITECTURE 为设计涉及路径打印出的架构指南文件（且不读其它指南文件），以及已有的 SAD 条目（SDD、LLR）。用 .guardrails/scripts/find-items.sh list --kind <PREFIX> 查找条目，用 find-items.sh show ID 读取所需条目，用 find-items.sh refs ID 查找某条目已被使用的位置。只有当这些手段无法回答问题时，才整份读取分类账文件。
分解为软件条目。每个条目都有明确定义的接口。条目语法由 check-trace.sh 校验：
SDD-…: <软件条目及其职责>. traces: REQ-…[, REQ-…]
在撰写时用 .guardrails/scripts/new-id.sh SDD（或 LLR）获取新条目 ID。每个条目至少追踪到一条需求。删除没有任何需求需要的设计条目。
对任何非平凡的设计，提出 2 或 3 种架构方案及其权衡，并优先给出你的推荐。分节呈现，写入最终 SAD 前与用户确认。若方案偏离该文件的某一条款，须指明该条款，由用户决定。
按 safety_class 缩放等级。允许逐条目覆盖；在条目文本中记录。
A：架构文档可选。SAD 保持为草图。
B：架构为必需：条目、接口与 REQ 追踪。LLR 可选；为复杂到需要它的条目撰写。
C：此外，在每个 SDD 条目下撰写低层需求（LLR），替代自由形式的详细设计散文：
LLR-…: <可直接编码的行为>. satisfies: REQ-…[, REQ-…]
可直接编码意味着工程师无需进一步解读即可实现：接口、算法、错误与失败行为、资源限制，各自作为独立可测试的 LLR。对没有父 REQ 的 LLR 标记 satisfies: derived，并送交 analyze-risks；RMF 必须对其评估。测试验证 LLR，check-trace.sh 传递性地覆盖 REQ。
说明不同等级条目之间的隔离：指明机制（进程边界、地址空间、硬件）及其为何充分。C 级条目的失效模式不得通过该机制传播。
在多单元仓库中，在消费者单元的 depends_on: 中声明跨单元依赖。依赖较低等级单元时，需在消费者配置中提供 segregated_from:，引用说明该机制的控制项或 ADR，形式为 (RC-…)、(ADR-<token>) 或 (adr: <path>)。对于 (ADR-<token>)，ADR 文件必须位于根 docs/adr/ 或消费者单元的 docs/adr/；位于提供者单元的文件会被拒绝。check-units.sh 会拒绝未引用的条目（INCOMPLETE-SEGREGATION）以及未覆盖等级差距的情况（MISCLASSED-DEPENDENCY）。
在绘制依赖边之前，先运行 grill-requirements 中的“Declaring a dependency”访谈。未完成该评估就出现在图上的依赖属于未评估的供应商。
在 soup.md 中记录 SOUP：软件依赖的每个第三方组件，含其确切版本、角色、所支持的需求，以及与安全相关的已知异常。新增或升级 SOUP 属于设计决策：对照 RMF 检查其失效模式，并为每个新危害运行 analyze-risks。
仅在决策同时满足难以逆转、脱离上下文会令人意外、且是真实权衡这三项时，才在 docs/adr/ 中撰写 ADR。示例包括技术锁定、集成模式，以及有意偏离显而易见路径。用 .guardrails/scripts/new-id.sh ADR 生成其 ID，并按 grill-requirements 在“ADRs”下所述形式撰写。
危险信号
想法 | 现实
“这个条目有用，需求可以后补” | 不追踪任何 REQ 的条目会被删除。若需求真实存在，运行 grill-requirements。
“一种架构显而易见，跳过备选方案” | 对任何非平凡的设计，呈现 2 或 3 种方案及其权衡。
“LLR 没有父需求，没关系” | 标记 satisfies: derived 并运行 analyze-risks。
“依赖只是图上的一条线” | 先运行“Declaring a dependency”访谈。
“升级库只是版本号变更” | 这是设计决策。对照 RMF 检查其失效模式。
“把这个选择记录为 ADR” | 仅在难以逆转、出乎意料且存在真实权衡时才记录。
完成条件
每个涉及的 SDD 条目都追踪到已有 REQ，且 check-trace.sh 对其报告无 UNTRACED-DESIGN 或 DANGLING-REF。
SOUP 清单与依赖清单（package.json、Cargo.toml、requirements.txt）一致：与它们做差异对比。
将实现规划移交 plan-change。