FDD 主流程 step 1(规划与拆解)。覆盖两段——plan(与用户弄清需求、经 investigator 调查代码库、定出 milestone、写出 plan.md 并呈现)与 features(把 milestone 拆成 features.json 并过 coverage 闸)。中间的 contract 段交给 harness-stack:fdd-validation-contract。由 harness-stack:fdd 调用。
构建新特性的主流程编排器。契约优先的多 agent 架构——捕获一个 plan,定义可测试的断言,拆解为多个 feature,再用全新上下文的 implementer/reviewer/validator subagent 驱动一个里程碑设闸的执行循环。当一处改动触及多个文件、有多条验收标准、或跨越多个 feature 时使用。主流程分三步,分发给 fdd-planning(含 fdd-validation-contract)/ fdd-execution / fdd-validate。
为一个 plan 撰写 validation contract——把 definition of done 落成一组可测试、用户可观测的 assertion(VAL-<AREA>-NNN),带 persona 与声明的 Evidence。它是 fdd step 1(规划)里的 contract 阶段。契约通过逐 area 的 investigation subagent 与若干轮 adversarial review 构建,而非一人独写。产出 .harness-runtime/plans/<slug>/validation-contract.md,并经由 fdd init-state 播种 validation-state.json。在项目内首次使用时,还会 bootstrap 项目级约定文档 docs/user-test-patterns.md。
规范 git 工作流实践。任何代码改动都适用。在提交、开分支、解决冲突,或需要把多条并行工作线组织起来时使用。
harness-stack 框架的引导纲要(bootstrap doctrine)。在会话开始时自动加载,用以介绍 lifecycle map、golden rules,以及如何挑选正确的 harness-stack:* skill。在一次会话中首次调用任何 harness-stack:* skill 之前,先读它。
复盘一次 harness-stack 使用,把值得上报的摩擦、缺陷或建议提成 GitHub Issue 反馈给上游。在完成一项任务、用完某个 skill 后有意见或改进想法,或想为框架本身留下改进线索时使用。
FDD 主流程 step 2——执行循环。串行驱动 feature 构建:next-feature → 派 implementer → handoff 决策树 → complete。每个 feature 由交接决策树把关(核验 implementer 自验留下的证据)。静态验证 → 代码审查 → user-test 这条验证流水线在里程碑收口(fdd-validate scope=milestone)与循环跑空(scope=final)批量跑。由 harness-stack:fdd 在 features.json 通过 coverage 后调用。
FDD 的验证流水线——里程碑 / 最终批量闸。一条线性、成本递增的三级 gate:静态验证(scrutiny-validator 硬门禁 test/lint/type-check + 逐 feature scrutiny)→ 代码审查(code-reviewer,逐 feature)→ user-test(运行时断言探测)。由 harness-stack:fdd-execution 在里程碑收口(scope=milestone:加条件 security-auditor + 治理反馈 + seal)与循环跑空(scope=final:加 coverage gate + fdd gate)时调用。