# Ba Generation V7

> 基于 TOGAF 的严谨业务架构生成器。适用于从战略理解、价值流、活动与干系人、业务能力、流程架构到内容汇编的完整设计；采用机器门、专业评审和差量复核，输出 JSON 与 Markdown。全流程在 Claude 原生 Agent/Sub-Agent 能力内闭环，不调用外部模型 CLI/API。

- Skill: `yslicn/ba-generation-v7` (Agent Skill, multi-file: 83 files)
- Install (CLI): `npx skillmds@latest add yslicn/ba-generation-v7`
- Raw SKILL.md: https://api.skillmd.com/api/skills/yslicn/ba-generation-v7/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: yslicn (https://skillmd.com/u/yslicn)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/yslicn/ba-generation-v7

---


# BA Generation v7

目标只有一个优先级顺序：先保证业务架构质量与可追溯性，再优化运行时间和 token。任何执行优化只要削弱语义判断，就必须回退。v7 只提供一套正式机制，不存在 strict/lean 选择。

## 不可违反的边界

1. 全流程使用当前 Claude 会话与原生 fresh Sub-Agent；禁止调用 OpenCode、`claude -p`、其他模型 CLI/API、个人配置、认证文件或本机日志。
2. `scripts/` 仅使用 Python 标准库或项目自带代码；不得要求用户安装本机依赖。
3. JSON artifact 是唯一事实源；Markdown 是投影。所有提交、评审、返工、锁定、编译和发布通过 `scripts/ba_runtime.py`。
4. 主 Agent 负责编排与机器门，不代写 Reviewer 的意见或凭证。Reviewer 使用 fresh context，且不能看到同轮另一 Reviewer 的输出。
5. 不为省 token 删除方法论判断、证据约束、可追溯关系或机器校验。

## 最小上下文契约

开始只读本文件。随后仅加载当前 Stage 必需资料：

- 命令与状态：`reference/runtime_commands.md`
- 评审、返工、计量：`reference/v7_execution_protocol.md`
- 当前阶段：`stages/stage_XX_*.md`
- 当前角色：对应 `agents/*.md`；Reviewer 只读 role-specific review kit
- 方法论：按阶段文件列出的具体 `methodology/*.md`
- JSON 字段不确定时：`reference/stage_json_contracts.md` 或相应 schema

不要预读全部阶段、全部 Agent、全部 schema 或历史迁移文档。

模型输入只能来自四类对象：当前Stage Contract、runtime生成的当前工作包、该工作包点名的方法论条款、Reviewer Kit。正式JSON是唯一事实源；工作包/kit都是绑定源hash、可重建、不可反写的临时投影。禁止把上游MD、历史评审正文、归档件或完整workspace作为“保险上下文”。确需追溯时按`工作包→相关正式JSON路径→证据原文`逐层展开，并把实际可见文件登记到context manifest。

## 流程

```text
00 范围确认
→ 01 战略理解
→ 02A 价值状态模型 → 02B 价值流
→ 03 价值流阶段、活动与干系人
→ 04A 场景基线 → 04B 场景模型 → 04C 原始能力需求 → 04D 能力聚合
→ 05父级L1/L2设计冻结 → 05A子级流程骨架 → 05B流程架构（full_ba 才执行）
→ 06 汇编、编译、发布
```

每个关口统一执行：

1. 先编译当前Gate的Consultant Checklist（常规最多8项/4 KiB；04D因含10项不可替代硬规则，专用上限12项/8 KiB）并作为工作输入；Consultant完成一次提交前预检后产出目标 artifact，runtime执行schema、规则、引用、覆盖和不变量校验。不得因紧凑上限截断当前版本的权威硬规则。
2. 生成不超过32 KiB的 role-specific decision kit。Reviewer只回答2个方向检查并提交最多5个重大 finding，不从零重做或总结 artifact。
3. 按关口 Reviewer 路由评审；任一 `REVISE` 则形成整改指令，只修改 findings 指向路径及其影响面。
4. 第二轮只派发给提出 open finding 的责任 Reviewer，核验原 finding 与影响路径一次；其他角色不重复评审。04D及当前Stage05的完整系统性索引仍须由该责任Reviewer在差量轮重跑，不能把旧的错误retain当成已关闭哨兵。
5. 评审通过后，用户确认关口展示摘要与 metrics，然后停止等待用户确认。普通定点评审的查询预算为首轮最多10次、差量轮最多8次，必须批量读取路径；04D `regression_guard_index`与Stage05 `stage05_regression_guard_index`是穷尽阻断目录，不受该次数和early-stop限制，但应使用索引的批量路径查询，禁止逐对象重复加载完整artifact。

关口状态纪律：只有 runtime 状态已经是 `user_review` 才能向用户请求决定。此时有两个并列分支：
用户批准则立即对当前 hash 执行`close-stage`；用户提出修改则把该消息视为对修订的直接授权，立即走
受控 amendment，不得先批准或锁定旧 hash。修订提交和既定 Reviewer 对新 hash PASS 后再次回到
`user_review`；用户仍可继续要求修订，只有最终接受的最新 hash 才锁定。若用户在`internal_review`
时提前给出批准，只完成当前 hash 原本缺失的 Reviewer；不得重开 Stage、不得增加 Reviewer。只要
artifact hash 未再变化，既有批准可在评审 PASS 后直接用于`close-stage`。用户批准后禁止重新分析
业务内容或发起评审；必须立即用 runtime 完成锁定和紧凑交接。

Schema、引用、覆盖、Producer–Consumer Closure 与 Domain Ownership 由 runtime 硬门负责。Reviewer不再输出10维 Completeness Backcheck；只在发现真实缺口时提交定位明确的 finding。

```bash
python3 scripts/ba_checklist.py compile --project-dir <D> --gate <G> \
  --role consultant --phase consultant_preflight
```

Reviewer Kit自动带当前角色的活跃Checklist，只报告失败项。每次封存评审自动记录`candidate_recorded`或`no_new_lesson`；major/critical finding只进入跨项目候选池，不自动激活。晋级、去重和淘汰见`reference/checklist_learning.md`。Checklist不增加模型调用或评审轮次。

Reviewer 路由是固定质量设计，不是可选档位：

| Gate | Reviewer | 目的 |
|---|---|---|
| 01 | Architect + Business Expert | 战略逻辑与行业事实 |
| 02A | Architect + Business Expert | 价值流方向、端到端反事实与状态冻结 |
| 02B | Architect | 锁定状态到阶段的投影 |
| 03 | Business Expert | 活动链与业务可运行性 |
| 04A | Architect + Business Expert | 场景覆盖与业务风险 |
| 04B | Architect | 场景分区、结构与可计算性 |
| 04C | Business Expert | 高风险需求语义与遗漏 |
| 04D | Architect + Business Expert | 聚合边界、业务服务身份、全局拓扑与可追溯性 |
| 05A | Architect + Business Expert | 流程方向、骨架、触发与交付物 |
| 05B | Architect + Business Expert | 骨架到流程明细的结构兑现、业务真实性与可用粒度 |
| 06 | Architect | 锁定来源忠实度与发布就绪 |

评审协议与风险触发条件见 `reference/v7_execution_protocol.md`。

## Stage 效率规则

- 00/01：用户提供领域专业意见、期望能力/流程或必须保留的缺口时，先逐条原文登记`user_professional_input`并用`init --professional-input-file`绑定；Stage01逐项且仅一次承接到能力假设，不允许只依赖会话记忆。研究与证据整理一次完成；Reviewer 不重新检索全量资料，只核验关键事实、推理断点和缺口。
- 02A/02B：状态模型先冻结，再派生价值流；禁止两关口重复解释同一状态语义。
- 03：按价值流生成工作包，每个 VS 由一个 fresh Worker 产出分片，主 Agent 只做骨架决策与汇总校验。
- 01—06局部修订：用户限定对象/路径且下游尚未开始时使用`begin-stage-amendment`，只改声明路径并由该Stage既定Reviewer做一次delta review；不得全量reopen。`user_review`中的修改意见直接进入该路径，不以批准旧版本为前置条件。`begin-stage03-amendment`仅作为兼容别名。Stage05在05A已锁定且05B已生成后，如同一意见必须同步Parent Design、05A与05B，使用`begin-stage05-amendment`→`submit-stage05-amendment`；它只允许语义同步和显式L4迁移，L1/L2/L3身份、成员关系及映射不可变。若上一轮Stage05修订已双PASS但用户继续要求修改，直接以上一轮已评审候选为新基线，旧候选记为superseded，不要求先确认。只有超出该边界或下游已开始才正式重开最早受影响Stage。
- 04A/04B：公共证据与规则写入一个可缓存COMMON；每个价值流只派一个fresh Worker，一次完成该价值流全部阶段。04A同时逐价值流完成六维横向支撑扫描；Stage02只识别价值流，不负责发现具体作业场景。横向支撑主题必须归属一条价值流并进入04B—04D闭环；零主题可以成立，但空扫描、漏维度或无证据结论不可成立。runtime按阶段拆解、组装并执行全域硬门。每个结果必须带逐调用receipt。
- 04C：默认每个价值流阶段一个fresh Worker，一次形成该阶段所有场景的完整分片；runtime批量校验后拆解登记。相关性筛选与诉求推导在同一语义上下文完成，不再调用独立Route模型，也不做干系人×活动文字叉乘。`stage04c-next-batch`按阶段派发，需求与RC执行双向1:N集合闭包；只有多个RC各自构成可独立建设、问责或验收的服务时才允许1→N，禁止按步骤机械拆分。治理与闭环各自独立调用并带receipt。常规评审不做盲审式全量重推，只有结构风险触发定点深查。
- 04D：采用质量优先的双向拓扑收敛。先用`scaffold-stage04d`从锁定04B/04C、Stage03领域边界及Stage01显式用户期望确定性生成正式骨架，再由Capability Consultant在单一全局视角完成DCC、RC路由、L3边界仲裁和L2分层。每个L3必须提交由真实RC/证据绑定的`service_contract`（触发、成果、消费者、验收门、问责）；服务身份与L3 pair复核以该契约hash绑定，不能靠自报布尔或模板理由。若存在旧拓扑，`topology_change_control`逐个映射旧L2/L3并由runtime复算结构变化；结构变化自动触发全量双评审。Architect与Business Expert都必须逐项审查回归索引和全局病理对象。禁止semantic profile摘要、按价值流局部定稿、逐活动镜像或用L3数量作为压缩目标。
- 04A增量修复：上游事实已存在但Stage04静默漏链时，使用append channel逐门追加04A横向主题、04B生产者场景和04C需求/RC，并在正式artifact中保持Stage02决策→04A主题/覆盖项→04B场景→04C需求/RC→04D L3闭包。04D已存在时必须先`reopen-stage04d`，禁止错误重开04C后再提交新04C。仅hash随动且业务正文不变的历史内容可走归档重验证；任何不能证明逐层不变的部分只重跑受影响语义分区。
- 04D证据与缺口纪律：骨架必须携带Stage03领域边界、架构决策原文以及Stage01能力假设/用户专业意见的`origin/source_refs/downstream_expectation`；DCC逐项保留并把真实缺口路由到最早责任Stage。`independent_process_challenge`继续进入Stage05 PDCC，不得在04D被同名或相邻能力静默吸收。Stage03 supplement必须以1.1补救目标与验收条件驱动，04D通过`remediation_objective_closure`绑定真实Stage03/04C/04D对象；runtime不自动补写业务语义。
- 05A：先冻结L1/L2父级契约；疑似复合L2须完成稳定对象、触发、结果、责任、管理节律、度量体系、消费者七维同质性测试，达到拆分阈值即由runtime拒绝。再在冻结父级内生成Final L3：替代方法必须提出实际不同的拓扑；同源分类Lane必须做variant-equivalence反切；PDCC分布式covered必须以真实handoff证明同一对象、统一问责和反馈回触发。完整能力↔流程1:1镜像、父级被子级反改、维度并集伪闭合、open+blocking诊断均由runtime拒绝。两位Reviewer须全量复核方法、L3、PDCC闭环和stage/lane/capability/compound模式，差量轮也不得跳过系统性索引；双PASS后进入`user_review`并STOP，用户以`close-stage --stage 05a`确认骨架后才允许05B。
- 05B：先用`stage05b-workpackages`按流程域分片推导，主 Agent 只汇总、去重对象并校验跨域接口；Worker不得改变锁定5A骨架。L1—L3的流程定义与流程目的每项必须为去除首尾空白后的120–200个Unicode字符；每个L3必须真分解为至少两个与父边界不同的L4。单活动提升必须有冻结上游证据，同一活动拆成多个L4时每个兄弟必须有不共享证据。05A/05B评审包使用完整对象索引与hash绑定证据路径；重复度高的完整目录可用“正式artifact路径+确定性枚举规则+对象数+展开ID摘要hash”无损编码，不以内联证据、删对象或抽样换取包大小。
- 06：从已锁定 JSON 自动汇编，不重新生成业务内容；runtime确定性生成开放事项登记，汇总未关闭评审问题、已知限制和客户待确认项，不增加模型调用。

分片遵循“不可逆判断需要的共享语义边界优先”：03、04A、04B按价值流，04C按价值流阶段，04D由Stage主Consultant保持全域语义连续性，05B按流程域。不得为了固定条数随机切批，也不得在不可逆判断前用摘要替代原始证据。单个分片失败只重跑该分片；同类契约错误必须熔断并先修协议，禁止靠新增修复脚本或批量重跑消耗Token。

03、04A、04B、04C、05B的**分片Worker**一次读取、一次生成、一次写入，只做一次本地批量自检；schema与全集覆盖交给runtime。该约束不适用于04D Stage Capability Consultant：04D必须按上一条质量优先规则保持全局语义连续性，并允许多轮本地预检与定向修订。分片Worker不输出思考过程、PASS清单或业务摘要，最终只回传`status/path/hash/counts/warnings`且不超过512字节。主Agent派发后只等待平台完成通知；禁止轮询或把正式业务内容带回长期主会话。

## Token 与时间检测

runtime以`ba_runtime.py start`开始Stage执行墙钟，在用户checkpoint结束；`close-stage`另记批准后锁定/校验/handoff墙钟。报告分别展示execution、closure及两者之和active work；用户等待不计入。重开保留历次run并累计。Stage计时是时间包络，不是假装成模型调用，也不承担Token采集。

每次Consultant、Worker和Reviewer模型调用结束后，主Agent必须立即从本次调用返回的Provider/平台元数据生成`schemas/model_call_receipt.schema.json`收据，并执行：

```bash
python3 scripts/ba_metrics.py record-call --project-dir <D> --receipt-file <receipt.json>
```

Reviewer继续使用review kit内置收据，runtime封存时自动落账，不重复执行`record-call`。平台给出usage时逐项原样记录input/cache-read/cache-write/output/reasoning token；未给出时必须使用`unavailable`并填写标准原因。禁止默认写`unavailable`、把未知写成0、用字节估算Token、读取本机日志，或用同一session总量冒充可归属的单次调用。收据必须记录真实非零时间窗；占位时间和零耗时会被拒绝。`provider`与`model`同样只能复制平台返回值；平台未暴露时写`unavailable`，禁止根据界面名称、配置或猜测填写模型。

调用前用`ba_metrics.py context`登记实际可见文件。用户checkpoint自动绑定metrics snapshot；任一模型调用usage缺失、计时异常或active事件未关闭时状态为`INCOMPLETE`并显著披露，但不篡改业务评审结论。报告覆盖范围只能声称`declared_model_events_only`：未提交收据的宿主模型调用数量不可观测，不得声称调用覆盖完整。Known Token在完全未知时显示`—`而不是0。Stage 06附全程报告。

`history + tool_output + unchanged`只作为重复上下文字节指标，不能伪装成精确浪费Token；不计算主观Productive Token或TER。预算基于历史实测做Stage/Gate软预警，只有项目显式配置的`max-bytes`可阻断。

04A—04D生成工作包时同时写`execution_cost_plan.json`。其中CRE（Context Replay Exposure）=`Σ((工作包bytes+每任务共享bytes)×计划模型轮次)`，只用于在付费运行前发现“大上下文×高轮次”拓扑，不换算Token。必须同时报告`logical_model_tasks`与`planned_provider_requests`；运行后再以receipt中的真实时间和Provider usage替换计划值，未暴露Token则保持`—/INCOMPLETE`。

## 用户关口

用户确认关口为 01、02B、03、04A、04D、05A、05B（如适用）、06。只展示：artifact Markdown 路径与摘要、Reviewer 决策和开放问题、外部意见处置状态、metrics 摘要。不要粘贴完整 artifact 或 review JSON。05A必须在生成任何05B L4、对象、服务或KPI前单独确认。

用户未批准不得越过关口。范围变更必须回到受影响最早 Stage，并由 runtime 使下游失效。

用户批准原文保存为一个短文本文件后，统一运行`close-stage`。该命令确定性生成批准凭证、
锁定、校验并写不超过4 KiB的handoff；禁止主Agent手写长handoff、重述业务基线、复读旧handoff，
或再维护一份重复的session memory。新Session只读compact handoff、当前Stage contract和runtime工作包。

## 质量基线

- 价值流必须面向干系人价值，阶段具有完成条件与可观察交付。
- 能力描述稳定的“做什么”，不退化为组织、系统、项目或活动清单。
- 流程必须有触发、输入、输出、责任与控制点，并追溯至价值流/能力。
- 关键判断保留证据、假设、不确定性和反例；缺证据不得伪装成事实。
- 发布前执行 `python3 scripts/quick_validate.py`，并确保项目 runtime 校验、评审、用户批准、metrics 报告、开放事项登记和 release gate 全部通过。