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。

流程

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。

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 路由是固定质量设计，不是可选档位：

评审协议与风险触发条件见 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收据，并执行：

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 全部通过。