25 KiB
stepsCompleted, workflowType, status, completedAt, inputDocuments
| stepsCompleted | workflowType | status | completedAt | inputDocuments | |||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
|
epics-and-stories | complete | 2026-04-05T14:00:00+08:00 |
|
chromebox_10th_audio_driver - Epic Breakdown
Overview
This document provides the complete epic and story breakdown for chromebox_10th_audio_driver, decomposing the requirements from the PRD, UX Design if it exists, and Architecture requirements into implementable stories.
Requirements Inventory
Functional Requirements
FR1: 维护者或协作者能够仅通过 README → 索引 → 路线图 / WORK_PROGRESS 定位当前工作阶段与下一步阅读顺序。
FR2: 读者能够区分 路线图（阶段顺序）与 WORK_PROGRESS（事实与换机状态）的职责边界。
FR3: 读者能够查阅 Linux HDMI 已排除或低期望方向，并在现象分流时区分「已知不成立路径」与「需继续对照内核/用户态」的路径（引用既有分析文档）。
FR4: 维护者能够将仓库内 指定补丁 应用于与运行内核版本一致的 Ubuntu HWE 源码树，并在应用前获得 patch 预检结果（成功/失败）。
FR5: 维护者能够记录当前验证所对应的 uname -r、内核包来源与 kernel-src 树状态（含「未建源树」声明）。
FR6: 维护者在 patch 预检失败时不以强制覆盖方式掩盖失败，而转入核对或手工合并。
FR7: 维护者能够按照 OPERATION_Install_CustomKernel_Ubuntu_HWE617.md 等权威说明完成 自编内核的安装与回退；安装范围（含 unsigned、模块包完整性、相关固件/无线等）以该 OPERATION 为准，不在 PRD 内逐包枚举。
FR8: 维护者在 完整内核构建失败时，能够记录 并行度/日志位置 等可复现信息，以便重试或协作排查。
FR9: 维护者能够运行 VERIFY_PATCHES.md 或文档当前版本所钉扎的验证路径（与补丁版本、内核线一致），并得到 通过/失败 的可判读结果。
FR10: 维护者能够保存 HDMI 相关试播 的 内核日志工件，并使其可与 路线图成功标准 对照；对外分享前可按 audio_topology/COLLECT.md 等采集说明做脱敏（细则见 Non-Functional Requirements）。
FR11: 维护者或协作者能够在 不构建内核 的前提下，使用 文本级对照材料（如 patches/ubuntu-hwe-6.17/reference/）支撑讨论；无完整源码树时仍可就 reference/、补丁与 PR 进行文本级协作。
FR12: 维护者在 双源码树可用时，能够执行或引用 ChromiumOS 与 Ubuntu 树之间的对照流程（脚本或操作说明）。
FR13: 读者能够找到 ChromiumOS 5.15 与 kernel-src 的约定路径与入口说明。
FR14: 维护者能够在 WORK_PROGRESS 中更新 阶段结论、日期与阻塞项。
FR15: 协作者能够根据 WORK_PROGRESS 判断 预检是否通过或 缺哪类树/包。
FR16: 只读使用者能够使用 信息采集清单 组织 最小信息包，而不自动触发上游协同义务。
FR17: 维护者在阶段或结论变更时，能够完成 WORK_PROGRESS 与路线图的交叉引用更新。
FR18: 维护者在新增或重组主题文档时，能够按约定更新 docs/INDEX.md / REPO_INDEX.md（或等效索引），避免孤岛页；大段摘录上游文档或代码时须标明来源与许可证（与 developer_tool 许可证约定一致）。
FR19: 协作者能够从索引或脚本表定位与 HWE / HDMI 相关的 脚本及用途。
FR20: 读者能够从索引或总览中识别 Linux HDMI 主线文档与 Windows / 其他平台 文档的入口分界（本 PRD 不交付 Windows 方案）。
FR21: 维护者在 Success Criteria 所定义的验证结论已具备之后，能够准备 上游复现/对外沟通 所需材料（此前无必须完成的对外义务）。
NonFunctional Requirements
NFR1: 对外分享 dmesg / 采集前，维护者须按 audio_topology/COLLECT.md（或等效采集说明）对 序列号、MAC、账号 等可识别信息做脱敏或裁剪；默认不将未脱敏日志提交至公共 issue。例外：若 上游 / issue 在 UPSTREAM_SOF_Kaisa_HDMI_REPRO.md 等清单中明确要求某工具的全量输出，按该清单执行，并遵循最小必要与清单内说明。
NFR2: 维护者不得在仓库中提交 密钥、Cookie、个人账号口令 等机密；脚本与文档示例使用占位符。
NFR3: 面向用户/协作者的说明须与 docs/meta/DOCUMENTATION_STYLE.md 及 project-context 中的语言与入口约定一致（简体中文为主，与 BMM 配置一致）。
NFR4: 新增主题文档或改变 docs/ 导航结构时，须在同一变更或紧随提交中同步 docs/INDEX.md / REPO_INDEX.md（或等效索引）；仅修改根 README 短链且不改变主题归属时，不强制全文重链（与 FR18 配套）。
NFR5: 验证脚本在文档声明的环境基线（Ubuntu 24.04 + 与文档一致的 linux-hwe-6.17 线）且前置条件满足时，须具备可重复的通过/失败语义；其它发行版或内核线仅作类比，不声称满足 FR9 的验证义务，除非在 WORK_PROGRESS 或文档中单独记录环境与结论。
NFR6: 完整内核构建的耗时与磁盘占用不作为用户响应时间类指标；在文档与 WORK_PROGRESS 中如实记录典型量级与失败模式（如并行、空间不足）。
NFR7: 进入本仓库版本库的上游摘录（含大段文档或代码）须可追溯来源与许可证；优先以 链接 + 短引 替代长粘贴；合理使用边界按 developer_tool 与上游许可执行。
Additional Requirements
（来自 architecture.md 与棕地约定，用于 Epic/Story 分解时的技术约束。）
- 工程基底：非 Web 脚手架；初始化契约 = 目录约定、
kernel-src与uname -r对齐、PATCH=流程、验证与采集路径。 - 本机即目标机：FR9 所述验证默认在 当前目标主机 执行；CI（若存在） 仅为预检，不替代本机验证。
- 入口唯一性：可选 Python/CI 为子路径；README 与文档声明的 Bash/文档入口 为权威。
- 补丁与树：
patches/ubuntu-hwe-6.17/钉扎当前 HWE 线；新线 →patches/<新线>/独立 README/验证叙述；PATCH=单文件、顺序 0001→0002、0003 独立。 - 导航锚点：
patches/.../README、VERIFY_PATCHES.md、kernel-src/README.md、docs/INDEX.md、docs/meta/WORK_PROGRESS.md为固定锚点；audio_topology/与docs/linux-hdmi/分工明确（采集 vs 路线图/结论）。 - 实现模式：
scripts/小写连字符；VERIFY_OK仅用于约定脚本；文档与索引 同事务 更新；失败输出建议 stderr 可 grep 前缀。 - 变更防呆：补丁/本机验证相关变更应能指回 README 锚点 或等价路径。
- 双索引：默认 README →
docs/INDEX.md；已知路径用REPO_INDEX.md。 - 规划 vs 需求：
_bmad-output/为规划契约；冲突 以 PRD 为准。
UX Design Requirements
未发现 {planning_artifacts}/*ux*.md 或独立 UX 规格。本仓库主交付物为 Bash / 补丁 / Markdown，无以 UI 组件实现为主的 UX 规格；若后续新增 UX 文档，可在此节追加 UX-DR* 并回写 Story。
FR Coverage Map
| FR | Epic | 简述 |
|---|---|---|
| FR1 | Epic 1 | 入口链定位阶段与下一步 |
| FR2 | Epic 1 | 路线图 vs WORK_PROGRESS 分工 |
| FR3 | Epic 1 | 已排除路径与现象分流 |
| FR4 | Epic 2 | 补丁预检与应用 |
| FR5 | Epic 2 | 记录 uname -r 与 kernel-src 状态 |
| FR6 | Epic 2 | 预检失败不强制覆盖 |
| FR7 | Epic 3 | 自编内核安装/回退 |
| FR8 | Epic 3 | 构建失败可复现记录 |
| FR9 | Epic 4 | 钉扎验证路径与通过/失败语义 |
| FR10 | Epic 4 | HDMI 日志工件与脱敏引用 |
| FR11 | Epic 5 | 文本级 reference/ 协作 |
| FR12 | Epic 5 | 双树对照流程 |
| FR13 | Epic 5 | ChromiumOS 与 kernel-src 路径入口 |
| FR14 | Epic 6 | WORK_PROGRESS 更新阶段与阻塞 |
| FR15 | Epic 6 | 预检与缺树/缺包可读 |
| FR16 | Epic 6 | 信息采集清单、最小信息包 |
| FR17 | Epic 6 | 路线图与 WORK_PROGRESS 交叉引用 |
| FR18 | Epic 1 | 索引更新与摘录来源 |
| FR19 | Epic 1 | 脚本表可发现 |
| FR20 | Epic 1 | Linux vs Windows 文档分界 |
| FR21 | Epic 7 | 验证后上游材料（条件） |
NFR 与 Epic 关联（摘要）
| NFR | 主要 Epic | 说明 |
|---|---|---|
| NFR1 | Epic 4 | 对外分享前脱敏（COLLECT.md） |
| NFR2 | 全局 | 仓库不提交密钥；各 Epic 涉及示例时遵守 |
| NFR3 | Epic 1 | 体例与语言与 DOCUMENTATION_STYLE 一致 |
| NFR4 | Epic 1 | 导航变更同事务更新索引 |
| NFR5 | Epic 4 | 基线环境下验证语义可重复 |
| NFR6 | Epic 3 | 构建资源/失败事实记录 |
| NFR7 | Epic 1、Epic 5 | 摘录来源与许可证可追溯 |
Epic List
Epic 1：单一入口与文档可发现
用户价值： 维护者/协作者/读者能在不依赖口头交接的情况下，从根入口经索引到达路线图、工作进度与平台分界，并找到脚本与主题文档。
涵盖 FR： FR1、FR2、FR3、FR18、FR19、FR20
说明： 以「防迷路」为主交付；不依赖后续 Epic 即可单独验收（例如索引与 README 自洽）。
Epic 2：补丁与源码树对齐
用户价值： 维护者能在与运行内核一致的 HWE 树上对仓库补丁做 dry-run / 应用，并诚实记录 uname -r 与 kernel-src 状态；预检失败时走核对/合并而非强贴。
涵盖 FR： FR4、FR5、FR6
说明： 与 Epic 3、4 推荐顺序为 先对齐树与补丁，再构建/验证，但本 Epic 本身可在「已有对齐树」假设下独立完成。
Epic 3：自编内核构建、安装与恢复
用户价值： 维护者能按权威 OPERATION 完成 自编 deb 的安装与回退；完整构建失败时能留下 并行度、日志位置 等可复现信息。
涵盖 FR： FR7、FR8
说明： 恢复路径引用既有安装文档，不将 HDMI 排错与可启动性混写（与 PRD 旅程 E 一致）。
Epic 4：验证与证据链
用户价值： 维护者能在文档钉扎环境下运行 verify-* / VERIFY_PATCHES 路径，得到可判读通过/失败；并保存 HDMI 相关日志工件，对外分享遵循脱敏约定。
涵盖 FR： FR9、FR10
说明： 本机验证为权威；与架构一致——无仓库级自动化测试套件替代 FR9。
Epic 5：文本对照与双树协作
用户价值： 协作者在不构建或双树齐备两种情况下，都能用 reference/、导出/diff 脚本与路径说明，完成 ChromiumOS ↔ Ubuntu 对照讨论。
涵盖 FR： FR11、FR12、FR13
说明： FR11 可在无完整树时独立产生价值；FR12 依赖双树可用时为增强能力。
Epic 6：进度事实与协作透明
用户价值： 维护者与协作者能依赖 WORK_PROGRESS 与预检信息判断阻塞；只读者能用采集清单组织信息包而不触发上游义务；阶段变更时 路线图与进度 交叉引用一致。
涵盖 FR： FR14、FR15、FR16、FR17
说明： 与 Epic 1 互补——Epic 1 偏「静态导航结构」，本 Epic 偏「随时间变化的事实与协作」。
Epic 7：上游与对外材料（条件触发）
用户价值： 在 成功标准所定义的验证结论已具备 后，维护者能准备 上游复现/对外沟通 所需材料；此前无对外必达义务。
涵盖 FR： FR21
说明： 显式后置；不与 Epic 4 并行强制。
自然推进顺序（建议，非硬依赖）： Epic 1 → Epic 2 → Epic 3 → Epic 4；Epic 5 可与 2–4 穿插；Epic 6 贯穿；Epic 7 仅在条件满足后启动。
Epic 1：单一入口与文档可发现 — Stories
Story 1.1：根入口与主题索引链完整
As a 协作者或维护者，
I want 从根 README 经 docs/INDEX.md（及 REPO_INDEX 速查）到达路线图与 WORK_PROGRESS，
So that 我能在 ≤30 分钟内定位「下一步读什么」。
Acceptance Criteria:
Given 仅克隆仓库且未口头交接
When 我依次打开 README.md → docs/INDEX.md
Then 我能找到指向 Linux_HDMI_Audio_Roadmap.md 与 docs/meta/WORK_PROGRESS.md 的明确链接
And 链接可点击且路径存在（或重定向说明存在）
Given 需要全路径速查
When 我打开 REPO_INDEX.md
Then 我能定位 scripts/、patches/、kernel-src/ 等关键目录的说明入口
追溯： FR1；NFR3（与体例一致）
Story 1.2：路线图与 WORK_PROGRESS 职责边界可读
As a 读者，
I want 在文档中看清「路线图管顺序、WORK_PROGRESS 管事实」，
So that 我不会把阶段规划与换机/验证事实混为一谈。
Acceptance Criteria:
Given 我阅读 docs/linux-hdmi/Linux_HDMI_Audio_Roadmap.md 与 docs/meta/WORK_PROGRESS.md
When 对比两者开篇或 meta 说明
Then 至少一处明确写出：路线图 = 阶段顺序与建议；WORK_PROGRESS = 日期、内核、阻塞与换机事实
And 二者互相有交叉引用链接
追溯： FR2
Story 1.3：已排除路径与现象分流可引用
As a 读者，
I want 在现象分流时能查到「已知不成立路径」与继续对照的入口，
So that 我不重复已记录弯路。
Acceptance Criteria:
Given 我处于 HDMI 调试/无声场景
When 我按 INDEX 进入 REANALYSIS / FIX_PLAN / 路线图「已排除」相关节
Then 我能区分用户态试错 vs 内核/IPC 对照路径的文档入口
And 引用与 FR3 及 ANALYSIS_Audio 等现有分析一致，不新增矛盾结论
追溯： FR3
Story 1.4：主题文档变更时同步索引
As a 维护者，
I want 新增或移动 docs/ 下主题文档时，同一变更集更新 INDEX/REPO_INDEX，
So that 不出现孤岛页。
Acceptance Criteria:
Given 新增或重命名某主题 Markdown（OPERATION/路线图除外的小修）
When 合并请求或提交说明中列出索引变更
Then docs/INDEX.md 或 REPO_INDEX.md 中可发现新路径
And 符合 NFR4（同事务或紧随提交）
追溯： FR18；NFR4
Story 1.5：HWE/HDMI 相关脚本可发现
As a 协作者，
I want 从 INDEX 或脚本表找到 verify-* / ubuntu-hwe-* 等脚本的用途与入口，
So that 我不依赖聊天即可运行正确脚本。
Acceptance Criteria:
Given docs/INDEX.md（或文末脚本表）
When 我查找「验证」「构建」「diff」类任务
Then 至少能定位到 scripts/verify-ubuntu-hwe617-patches-runtime.sh、scripts/ubuntu-hwe-617-build.sh 等条目的说明或链到 VERIFY_PATCHES/README
And 脚本注释或 --help 与文档描述不矛盾
追溯： FR19
Story 1.6：Linux 与 Windows 文档分界可见
As a 读者，
I want 从索引或总览识别 Linux HDMI 主线与 Windows 文档入口，
So that 我不把 Windows 操作当作 Linux HDMI 交付范围。
Acceptance Criteria:
Given docs/INDEX.md 或根 README 任务表
When 我查找跨平台信息
Then Linux 与 Windows 分节或表格明确，且与 PRD FR20 一致（本 PRD 不交付 Windows 方案）
追溯： FR20；NFR3
Epic 2：补丁与源码树对齐 — Stories
Story 2.1：补丁预检与单文件应用路径
As a 维护者，
I want 对 patches/ubuntu-hwe-6.17/ 中补丁在正确树上执行 patch -p1 --dry-run 并按 PATCH= 单文件应用，
So that 应用前可判读成功/失败。
Acceptance Criteria:
Given kernel-src/ 与 uname -r 对齐（或文档声明未建源树）
When 我按 patches/ubuntu-hwe-6.17/README.md 设置 PATCH= 并对单 patch 执行 dry-run
Then 预检输出可判读成功或失败原因
And 顺序约定 0001→0002、0003 独立在 README 中可见
追溯： FR4
Story 2.2：记录 uname 与 kernel-src 状态
As a 维护者，
I want 在 WORK_PROGRESS 或约定位置记录 uname -r、包来源与 kernel-src 状态，
So that 他人能复现同一验证上下文。
Acceptance Criteria:
Given 一次补丁相关验证或构建
When 我更新 docs/meta/WORK_PROGRESS.md
Then 至少包含：uname -r、与补丁对应的内核线说明、kernel-src 已准备/未准备
And 与 FR5、NFR5 叙述一致
追溯： FR5
Story 2.3：预检失败时不强制覆盖
As a 维护者，
I want 在 dry-run 失败时不使用 patch --force 掩盖问题，
So that 我核对树版本或手工合并。
Acceptance Criteria:
Given patch -p1 --dry-run 失败
When 我查阅 patches/.../README 与 project-context
Then 流程明确禁止在未解决 dry-run 失败时 patch --force
And WORK_PROGRESS 可记录「失败原因 + 下一步」而非假成功
追溯： FR6；与 PRD api_surface 一致
Epic 3：自编内核构建、安装与恢复 — Stories
Story 3.1：自编内核安装与回退可执行
As a 维护者，
I want 按 OPERATION_Install_CustomKernel_Ubuntu_HWE617.md 完成安装与回退，
So that 我可恢复可启动状态（旅程 E）。
Acceptance Criteria:
Given 已构建或未构建 deb 的场景
When 我跟随 docs/kernel-build/ 中安装 OPERATION
Then unsigned、模块包、Secure Boot 等范围以该文档为准且与 WORK_PROGRESS 可对照
And 回退后 uname -r 与进度记录一致
追溯： FR7
Story 3.2：完整内核构建失败可复现记录
As a 维护者，
I want 在 binary-generic 等失败时记录并行度、日志路径与空间事实，
So that 重试或协作排查有据。
Acceptance Criteria:
Given fakeroot debian/rules binary-generic 或等价失败
When 我更新 WORK_PROGRESS
Then 记录含：并行相关环境变量（若适用）、日志文件路径、磁盘/错误摘要
And 符合 NFR6
追溯： FR8；NFR6
Epic 4：验证与证据链 — Stories
Story 4.1：钉扎验证路径与可判读结果
As a 维护者，
I want 运行 VERIFY_PATCHES.md 与 verify-ubuntu-hwe617-patches-runtime.sh 所钉扎的路径，
So that 我得到通过/失败与 VERIFY_OK（若适用）的明确语义。
Acceptance Criteria:
Given Ubuntu 24.04 + 文档基线内核与前置满足
When 我按 VERIFY_PATCHES 运行验证脚本
Then 退出码与输出可判读成功或失败，且与 uname -r、补丁版本一致
And 不声称 CI 替代本机验证（架构）
追溯： FR9；NFR5
Story 4.2：HDMI 试播日志工件与脱敏
As a 维护者，
I want 保存 HDMI 相关 dmesg/脚本输出，并在对外分享前按 COLLECT.md 脱敏，
So that 证据可对齐路线图成功标准且不泄露隐私。
Acceptance Criteria:
Given 一次 HDMI 试播或验证
When 我将日志保存到 audio_topology/collected/ 或约定位置
Then 可与路线图成功标准对照；若对外分享，遵循 COLLECT.md 与 NFR1
And 未脱敏不全文贴公共 issue（除非 UPSTREAM 清单明确要求）
追溯： FR10；NFR1
Epic 5：文本对照与双树协作 — Stories
Story 5.1：无树时的 reference/ 文本协作
As a 协作者，
I want 仅依赖 patches/.../reference/ 与补丁讨论 PR，
So that 无完整 kernel-src 时仍能文本级协作。
Acceptance Criteria:
Given 未检出完整 Ubuntu 树
When 我引用 reference/ 下已有 unified diff 与补丁说明
Then 能支撑代码审查式讨论（FR11）
And 与 DIFF_SUMMARY 不矛盾
追溯： FR11
Story 5.2：双树齐备时的对照与导出
As a 维护者，
I want 在 chromiumos_kernel/v5.15/ 与 kernel-src/ 可用时运行预检/diff 导出脚本，
So that 我能做 ChromiumOS ↔ Ubuntu 文件级对照。
Acceptance Criteria:
Given 双树路径满足 preflight/export 脚本前置
When 我按 docs/INDEX 与脚本 --help 执行
Then 产出可引用路径或 diff 片段，并记入 WORK_PROGRESS 可选
追溯： FR12
Story 5.3：双树约定路径与入口说明
As a 读者，
I want 在固定文档中找到 ChromiumOS 5.15 与 kernel-src 的克隆与索引入口，
So that 我能自行准备对照树。
Acceptance Criteria:
Given CHROMEOS_KAISA_AUDIO_KERNEL_PATHS.md 与 KERNEL_SRC_LINUX_HWE617_HDMI_3.5MM_PATHS.md（或等效）
When 我从 INDEX 进入
Then 路径与 WORK_PROGRESS 克隆说明一致，可定位关键文件
追溯： FR13；NFR7（摘录来源）
Epic 6：进度事实与协作透明 — Stories
Story 6.1：WORK_PROGRESS 更新阶段与阻塞
As a 维护者，
I want 在 WORK_PROGRESS 中更新阶段结论、日期与阻塞项，
So that 协作与未来的自己都能看见卡在哪。
Acceptance Criteria:
Given 阶段推进或验证结论变化
When 我编辑 docs/meta/WORK_PROGRESS.md
Then 含日期、内核/补丁标识、阻塞（若有）
And 与路线图阶段可交叉核对
追溯： FR14
Story 6.2：预检可读（缺树/缺包）
As a 协作者，
I want 从 WORK_PROGRESS 或预检脚本输出判断缺哪类树/包，
So that 我能按清单补齐而非盲试。
Acceptance Criteria:
Given 运行 preflight-chromeos-ubuntu-diff.sh 或类似预检
When 失败或部分通过
Then WORK_PROGRESS 或脚本输出能映射到「缺 ChromiumOS」「缺 kernel-src」等类别
And 与旅程 B 一致
追溯： FR15
Story 6.3：信息采集清单与最小信息包
As a 只读使用者，
I want 用 UPSTREAM_SOF_Kaisa_HDMI_REPRO.md 等清单组织最小信息包，
So that 我不自动触发上游协同义务。
Acceptance Criteria:
Given 仅对外描述问题
When 我按清单采集
Then 信息包最小必要，且不将「发 issue」列为本仓库必达（FR16）
追溯： FR16
Story 6.4：路线图与 WORK_PROGRESS 交叉引用
As a 维护者，
I want 在阶段或结论变更时更新路线图与 WORK_PROGRESS 的交叉引用，
So that 两文档不矛盾。
Acceptance Criteria:
Given 阶段跳转或重要结论
When 我更新其中任一文档
Then 另一处同步或引用更新，避免 FR2 回归
追溯： FR17
Epic 7：上游与对外材料（条件触发）— Stories
Story 7.1：验证通过后的上游材料闸门
As a 维护者，
I want 仅在成功标准定义的验证结论已具备时，准备 UPSTREAM_* 类材料，
So that 上游沟通不早于验证。
Acceptance Criteria:
Given 路线图/成功标准中「验证结论」未满足
When 评估是否启动上游 issue/投递
Then 文档明确：不将上游协同作为与验证并行里程碑（FR21、业务成功）
And 一旦准备材料，材料与 COLLECT/脱敏一致
追溯： FR21；NFR1
Final Validation（Step 4）
FR / NFR 覆盖
| 检查项 | 结果 |
|---|---|
| FR1–FR21 | 均在至少一个 Story「追溯」中出现；无遗漏 |
| NFR1–NFR7 | 在 Story 与/或「NFR 与 Epic 关联」表中体现；无遗漏 |
与 Architecture 的一致性
| 检查项 | 结果 |
|---|---|
| Starter / 初始化 | 架构为 棕地文档 + Bash + 补丁契约；无 Web 脚手架；Epic 1 Story 1.1 为 入口链文档，不要求「从模板克隆应用」，与 architecture.md 一致 |
| 数据库 / 实体 | 本仓库 无 应用数据库；不适用「逐 Story 建表」规则 |
Story 质量与依赖
| 检查项 | 结果 |
|---|---|
| 单代理可完成 | 各 Story 为文档/脚本/流程变更粒度，可由单次会话完成 |
| AC | 均含 Given/When/Then（及 And） |
| 同 Epic 内顺序 | 以 1.1→1.2… 为推荐顺序；文档类 Story 多可并行，无「必须等未来 Story 实现才能写文档」的硬依赖 |
| Epic 间 | 各 Epic 可独立交付用户价值；建议顺序见 Epic List 节，非硬依赖阻塞 |
结论
VALIDATED — epics.md 可作为实现与拆冲刺的输入；若 PRD 或架构变更，需回写 Story 与覆盖表。
BMad Create Epics and Stories（CE）工作流已完成（stepsCompleted 含 Step 4）。