夜雨聆风这轮复盘，我们越来越确定一件事：处理 RPG 里的 large program source，核心问题不是“怎么让 AI 读完更多代码”。
看到一个 20,000 行、30,000 行的 RPGLE / SQLRPGLE program，第一反应很容易是技术性的：怎么切 chunk？怎么压缩？怎么让模型总结？怎么把上下文塞进去？
但在 legacy modernization 里，真正危险的不是模型读不完。真正危险的是：模型读了一部分，然后写出一段听起来完整、顺滑、很像业务理解的总结。
这种总结最难处理。它不是明显错的。它只是证据链不够。
所以我们这轮关于 large program source 的设计复盘，核心其实是一句话：
不要把大 RPG 程序当成“大文本摘要”问题，要把它当成“证据驱动的程序理解”问题。
大程序为什么不能直接总结
RPG 大程序的复杂，不只是行数多。
它复杂在关系是分散的。
一个字段可能在 mainline 里初始化，在某个 subroutine 里被改写，在另一个 subroutine 里参与判断，最后通过参数、文件写入、message、return code 或外部 call 影响业务结果。
一个 EXSR 看起来只是内部跳转，但它可能是业务规则的核心入口。
一个 CALLP 看起来只是外部调用，但它可能决定了 flow 是否继续、是否落库、是否回滚。
一个 message/status code 可能不是错误文本，而是业务状态本身。
一个 file I/O 操作也不只是“读写文件”，它可能代表审批、冻结、出账、对账、冲正、人工处理队列。
如果我们只是按固定行数切块，然后让 AI 总结每块，routine 的 caller/callee 关系会断，field lineage 会断，error path 会断，transaction boundary 会断，message/status 的真实作用会断。最后合并出来的文档会很通顺，但不一定可靠。
这就是我们要避免的。
先保结构，再谈语义
Large program source 的第一步，不应该是写业务总结。
第一步应该是建立结构感。
我们要先知道：这个 program 有哪些入口？mainline 怎么 dispatch？有哪些 internal routines / procedures？哪些 routine 是 validation？哪些 routine 是 calculation？哪些 routine 会写文件、更新字段、commit、rollback？哪些地方会设置 message、return code、status？哪些地方调用外部程序、API、queue、report、screen？哪些路径只是 read-only，哪些路径会改变 persistent state？哪些部分已经读过，哪些只是知道它存在？
只有这些结构先站起来，后面的语义理解才有边界。
否则，AI 很容易把“我们看到一个变量名像审批状态”写成“系统执行审批逻辑”。这在现代化里很危险，因为后续 BRD、spec、Java/cloud design 都可能继承这个未经证明的说法。
Coverage 比 Summary 更重要
处理 large program 时，我们最需要的不是一个更长的 summary，而是 coverage discipline。
我们倾向于把每一段理解都标上证据状态：
indexed_only：我们知道这里有这个 routine、call、file I/O、message 或 field movement，但还没有足够语义阅读来支持强结论。
deep_read：我们实际读过这个 source window，可以用它支持某个 calculation、validation、exception、file mutation 或 flow claim。
blocked：缺 source、缺 copybook、缺 message catalog、缺外部 program、缺 runtime evidence，或者需要 SME 判断，不能继续编。
这三个状态非常关键。
它逼我们承认：知道结构，不等于理解行为。读过局部，不等于理解全局。SME 说法很重要，但也不能和 source evidence 混成一个东西。AI 推断可以作为 candidate，但不能直接变成 approved business rule。
这套 coverage 纪律，才是 large source analysis 的核心防 hallucination 机制。
防幻觉不是提示词问题
防幻觉不是靠一句“不要 hallucinate”。这句话没用。
真正有效的是把 AI 可能编故事的地方，变成流程上的硬约束。
第一，不允许无证据强结论。
任何 calculation、validation、exception、message、file update、SQL mutation、external call、flow branch、module capability seed，都必须能指回证据来源。如果只能从字段名猜，比如 APPRFLG、ERRSTS、AUTHCD，那只能写成 candidate 或 TBD，不能写成“系统审批通过”或“交易被拒绝”。字段名是线索，不是证据。
第二，保留 coverage 状态。
一个 routine 只是被看见了，不代表它被理解了。indexed_only 的 routine 不能支撑 confirmed behavior。只有 deep_read 的 source window 才能支撑强逻辑声明。blocked 的路径不能被 flow 或 module 偷偷绕过去。
第三，把不确定性显式写出来。
LLM 最容易犯的错误，是把不确定性改写成顺滑的 prose。我们反过来要求：不确定性必须有名字。缺 source，就写 pending_source。缺 SME 判断，就写 pending_sme_judgment。缺 message catalog，就写 message description unresolved。缺 copybook，就写 copybook blocker。外部 program 不清楚，就写 unresolved external handoff。dynamic call 无法解析，就写 dynamic_unresolved。field lineage 断了，就写 lineage gap。
只要 gap 被命名，它就不会悄悄变成结论。
第四，区分 observed、inferred、confirmed。
observed behavior 是源码、runtime evidence、joblog、spool、screen/report、SQL、file I/O 里直接看到的行为。
inferred rule 是根据代码结构推测出来、但还需要 SME 或更多 evidence 确认的解释。
confirmed business rule 是已经被 SME 或 approved evidence 确认，可以进入 BRD/spec 的规则。
这三类不能混。
AI 很擅长把 observed behavior 包装成 business rule。比如它看到某个状态码 H，就说“客户被 hold”。但如果没有 message catalog、control table、SME 确认或上下文证据，H 的业务含义就不能被写死。
第五，不让下游自动继承上游不确定性。
Program 里的 TBD，到 flow 不能消失。Flow 里的 TBD，到 module 不能消失。Module 里的 TBD，到 BRD/spec 不能变成需求。
这就是 carry-forward TBD 的意义。它防止幻觉在层与层之间升级。
程序分层：轻的地方轻，重的地方重
不是所有 program 都该走极端大程序流程。
现实项目里，大多数 program 没有 30,000 行。很多 program 是普通大小，只是需要 SME 快速确认它 calculate 什么、validate 什么、update 什么、call 什么。
所以我们需要 tiering。
normal_program：普通程序，默认轻量处理。重点是快速给 SME 一个可读的 review surface：calculation logic、validation logic、exception handling、message inventory、file I/O、external calls、TBD。
complex_normal_program：行数不一定爆炸，但密度高。比如 routine 多、file I/O 多、SQL 多、message/status 多、external call 多、field mutation 多。这类程序需要更多 sidecar 或更细 coverage，但仍然不要把正文写成一部百科。
large_extreme_program：真正的大程序。这里不能假装一轮读完。要拆成结构、routine cards、deep-read windows、coverage ledger，然后分批推进。
这个分层的意义是：轻的地方轻，重的地方重。
如果每个 program 都上完整大型流程，交付会被拖死。如果大程序也走轻量总结，风险会被埋掉。
每轮五个 routine，但 routine 多了要自动 loop
我们之前讨论过一个实际限制：每轮最多认真读少量 routine，比如五个。
这不是形式主义，而是为了避免模型在一个回合里混淆太多语义单元。
RPG 的 routine 往往不是现代语言里那种干净的小函数。一个 subroutine 里可能同时有字段搬运、indicator 判断、文件读写、message 设置、异常处理和外部调用。一次读太多，模型会开始做“压缩理解”。而压缩理解最容易丢的，恰好是 legacy modernization 最需要的东西：branch condition、field carrier、message trigger、status propagation、file mutation、exception closure、commit/rollback boundary。
所以 deep-read 的选择要有优先级：先看入口和 mainline dispatch，再看 validation、calculation、persistence、exception/message handling、external call boundary，最后才是普通 utility。
这意味着我们不是为了“覆盖所有代码”而读代码，而是为了支撑当前最重要的 claim。
但这里还有一个现场体验问题。
如果一个 program 只有几个关键 routine，让 SME 每轮确认一次还可以。但如果一个 RPG program 有几十个 routine，甚至 deep-read plan 里有十几轮窗口，就不能让 SME 每次都手动输入“继续”。这会非常累，也会把 SME 的注意力从业务判断拖回流程操作。
所以 routine 一多，应该切换成自动分批 loop。
自动 loop 不是一次性突破限制，也不是让 AI 一口气读完整个 source。每轮最多 5 个 routine/window 的限制仍然保留。区别只是：由 agent 按 deep-read plan 自动一轮一轮推进，直到没有可处理窗口、遇到 blocker、需要 SME 判断、需要外部资料，或者上下文接近上限。
每一轮仍然要留下 checkpoint：本轮读了哪些 routine/window、对应 source lines 是什么、哪些 coverage 从 indexed_only 变成 deep_read、更新了哪些 evidence、关闭了哪些 gap、新增或保留了哪些 blocker、下一轮候选是什么。
这样 SME 不需要参与机械推进，只需要在真正需要业务判断的时候介入。
自动 loop 不是自动编结论，而是自动执行受控的 evidence reading。
Program、Flow、Module 三层职责
Program analysis 的职责不是直接写 module 级业务结论。它负责回答：这个 program 的 entry 是什么？接收什么参数或输入？做了哪些 calculation？做了哪些 validation？如何设置 message、status、return code？读写哪些 file/table？调用哪些 internal routine 和 external program？有哪些 exception path？哪些逻辑已经 deep-read？哪些只是 indexed_only？哪些需要 SME 或其他 evidence？
Program 层的输出应该让 IT SME 一眼看到：Calculation Logic、Validation Logic、Exception Handling、Message Inventory、File I/O / SQL State Changes、External Calls、Open TBDs。
到了 flow 层，问题变了。
Flow 关心的不是“某个 program 内部所有 routine 做什么”，而是一个 business event 如何跨 program 移动。
一个 batch job 怎么启动？一个 menu option 怎么进入？一个 API request 怎么一路传下去？一个 validation failure 怎么变成 response code？一个 file update 发生在哪个节点？一个 exception 是被本地处理，还是向外传播？
所以 flow 不应该重新吞多个完整 program source，也不应该拼多个完整 program analysis Markdown。Flow 应该消费 program 层已经整理好的 compact evidence，并且保留 coverage 状态。
如果某个 flow claim 依赖的 routine 还只是 indexed_only，flow 就不能把它写成 confirmed behavior。它应该回到 program 层请求下一轮 deep-read，或者记录一个明确的 TBD / SME waiver。
再往上是 module。
Module 不是把 flow 文档再总结一遍。Module 要回答的是：这些 flows 放在一起，是否构成一个业务模块？program flow 是否覆盖主要路径？data flow 是否覆盖核心对象和字段生命周期？exception/recovery 是否足够清楚？BRD / spec 可以从哪些 evidence 写出结论？哪些地方只能作为 candidate？哪些地方必须 SME confirm？哪些地方是 source gap？
所以 module 层要做的是 source-backed assembly，而不是从代码里强行推导所有业务背景。
这三层不能混。
Program 层负责程序证据。Flow 层负责交易路径。Module 层负责业务模块边界和交付可用性。
Program 不能越级写 module conclusion。Flow 不能把未 deep-read 的 routine 当作 confirmed behavior。Module 不能把 candidate-only 或 generated draft 直接写成 BRD conclusion。
SME 不是最后盖章的人
Large RPG program 的分析不应该把 SME 放到最后当审批人。
SME 应该更早介入，而且介入点要清楚。
SME 不一定要读完整源码。SME 要看的应该是经过整理的 decision surface：这个 calculation 是否符合业务？这个 validation failure 是否真实代表 reject？这个 status code 的业务含义是什么？这个 message 是用户可见、operator 可见，还是内部 trace？这个 file update 是否真的代表落库成功？这个 exception path 是正常业务分支，还是异常恢复？这个 flow 是否漏了人工操作或 batch 后续？这个 module boundary 是否符合业务团队认知？
也就是说，SME 不是来确认 AI 写得顺不顺。SME 是来确认证据解释是否符合真实业务。
Standalone 先探索，Chain Ready 走主路由
SME 不需要一上来就理解整套 Legacy Spec Factory。
最快的上手方式，是先回答两个问题：这次只是想快速看懂一个点，还是要进入正式 downstream 链路？这次关心的是一个 program、一个 flow，还是一个 module？
对应下来，我们有两个模式。但这两个模式不是平级任选。
在实际实施阶段，大部分团队应该先用 standalone_exploratory。尤其是刚拿到一个 large RPG program、刚开始和 SME 对齐、还不知道 module boundary、还没有完整 inventory / evidence manifest / approval status 的时候，先不要急着进入正式链路。先用 standalone 把程序结构、关键 routine、主要 calculation、validation、message/status、file I/O、external call、open questions 摸出来。
Standalone 是探索和对齐模式。它的目标是快速降低未知，而不是立刻生成可交付证据。
chain_ready 是链路模式。适合正式进入 program -> flow -> module -> BRD/spec 的交付链路。它要求 inventory、evidence IDs、artifact approval、coverage gate 都更严格。缺东西不能糊过去，要明确变成 TBD 或 blocked finding。
但这里我们不建议 SME 自己直接手搓 chain_ready prompt。更好的方式，是走主路由 skill，也就是 legacy-modernization-orchestrator。它的价值就在这里：让 SME 不需要一次性记住 program、flow、module、BRD/spec 每一层的 gate，而是由路由 skill 根据当前证据状态一步步引导，判断下一步该补 inventory、program analysis、flow、module context、SME review，还是可以进入 BRD/spec。
真实工作流通常是：先 standalone，快速探索；再 SME review，确认哪些解释成立；再补 evidence、inventory、message catalog、copybook、runtime proof；最后由主路由 skill 引导，把足够稳定的部分 promote 到 chain_ready。
这个顺序很重要。它让团队既能快，又不会把探索阶段的不确定性带进正式交付链路。
Orchestrator 的便利性：让 SME 不用记住整条链
legacy-modernization-orchestrator 的设计，本质上是在解决一个很实际的问题：SME 和 BA 不应该被要求记住 20 多个 skill 分别什么时候用、每个 artifact 放在哪、每个 gate 怎么判断、哪个阶段能跳、哪个阶段不能跳。
他们真正想说的通常是：我们有一批 RPG source 和一些 notes，下一步干什么？我们有一个 program-flow seed，能不能做 BRD？我们有历史功能规格和 Visio 图，但没有完整源码，能不能先整理模块？这个 module coverage 够不够进入 BRD？这个 BRD 审完以后，是不是能推 spec？
Orchestrator 的便利性就在这里。它把“我们该用哪个 skill”这个问题，从 SME 身上拿走。
它先判断当前项目和当前 focus。一个 repo 里可能有多个 modernization project，每个 project 下面又可能有多个 capability 或 module。orchestrator 会根据用户提到的项目名、路径、CAP-*、MODULE-*、已有 artifact 或 workflow-state.yaml 来判断这次到底是在继续旧任务、切换 capability、创建新 capability，还是需要先扫描已有 artifacts 让用户选择。
它再判断当前 stage。现在手里的是 raw evidence、document-intake output、module context、inventory、program analysis、flow analysis、module package、BRD draft，还是 approved BRD 后的 disposition 阶段？不同阶段应该去的下游 skill 不一样。
然后它给出最安全的下一步：该做 document evidence intake，就不要直接写 BRD；该做 module context intake，就不要硬走 program；该补 inventory，就不要让 flow 猜 object boundary；该做 SME review，就不要直接推 spec。
换句话说，orchestrator 不是替代 program analyzer、flow analyzer、module analyzer 或 BRD writer。它是把这些 skill 串起来的工作流入口。
这个入口对 SME 很友好，因为 SME 可以用自然语言描述当前材料和目标：
我们现在有一个 AR reconciliation 的 RPG source、一个 joblog、两张 spool sample，还有 SME 对账规则 notes。我们想知道能不能先做一个 BRD draft。orchestrator 不应该直接写 BRD。它应该判断：这些材料是否需要 evidence intake？是否需要 redaction？是否已经有 inventory？是否需要 program / flow analysis？是否有 module boundary？是否只能先做 delivery_draft 或 poc_draft？哪些地方必须成为 TBD？
这种设计让流程从“用户必须知道工具怎么用”，变成“用户只要说明目标和材料，系统引导下一步”。
从开始推到 BRD：不是一把梭
从项目开始到 BRD，orchestrator 大致在帮团队做一件事：把散乱材料逐步收敛成可审阅、可追溯、可交付的 legacy BRD package。
它支持两类常见入口。
第一类是 module-first entry。
这通常发生在企业现场。团队不一定一开始就有完整源码分析，但可能已经有历史 Word、Excel、Visio、PDF、PowerPoint、Function Spec、Technical Design、Program Spec、File Spec、RAG summary、SME notes，或者业务方已经知道一个大概 module boundary。
这时不应该强迫团队从源码考古开始。orchestrator 会先看材料是否需要 legacy-document-evidence-intake 做格式归一化；如果已经有可用的 context、RAG、source metadata 或 SME fragment，就路由到 legacy-module-context-intake，把这些材料整理成 context package。这个 package 不是 approved module analysis，它只是把候选业务信号、source notes、TBD、证据强度和 BRD source eligibility 先摆出来。
然后进入 code-backed enrichment checkpoint。
如果目标是标准的、生产可用的 code-backed BRD，而不是 POC 草稿，那么只靠历史文档和 RAG 不够。orchestrator 会要求补代码证据骨架：inventory、program analysis、flow analysis，再到 module analyzer。这样 BRD 不是从“看起来像业务说明”的材料直接生成，而是从 module context + code-backed program/flow evidence 里生成。
第二类是 raw legacy evidence entry。
这通常发生在团队先拿到 IBM i source、DDS、DB2 文件、joblog、spool、screen/report、SME notes。orchestrator 会先处理 evidence intake 和 redaction gate，再进入 Layer 1 extraction：legacy-ibmi-inventory、legacy-ibmi-program-analyzer、legacy-ibmi-flow-analyzer、legacy-ibmi-module-analyzer。
等 module coverage 足够之后，再进入 Layer 2 synthesis：legacy-brd-writer。
这里的关键是，BRD 不是直接从 source 写出来，也不是从 flow summary 拼出来。BRD 应该从 approved 或至少 reviewable 的 module coverage 里来，带着 source eligibility、TBD、validation scenario seeds、traceability 和 SME review surface。
这就是“从开始推 BRD”的真实路径：先判断入口材料，再建立 context 或 evidence backbone，再补 program / flow / module coverage，再检查 BRD source eligibility，再写 BRD draft，再交给 SME review，再根据 review decision 进入 post-BRD disposition。
post-BRD disposition 也很重要。BRD approval 不是自动等于“这些都是新系统需求”。BRD 只是 legacy discovery baseline。后面还要判断 old-vs-new：哪些 legacy 行为不需要迁移，哪些属于 gap，哪些要 follow new system，哪些 legacy behavior 被明确 promote。只有被 disposition / promotion 过的内容，才适合继续进入 spec writer 或 SDD handoff。
所以 orchestrator 的价值不是把流程变长，而是让每一步都有出口和 stop condition。
材料不够，就补材料。证据不够，就补 evidence。SME 没确认，就做 review。BRD 只能做 POC，就标 poc_draft。日常交付要快，就可以走 daily_delivery / delivery_draft，但不能假装 approved。可以进入正式 BRD，就路由到 legacy-brd-writer。BRD 之后还没做 disposition，就不要直接写 spec。
这个设计对 SME 的便利性很强：SME 不需要背整条链，只需要在每一轮回答当前最小的问题。orchestrator 负责把这些回答放回正确阶段。
方法论总结
这轮关于 large program source、flow、module 的联动改动，表面上是在调整 artifact、sidecar、coverage、guideline。
但背后的方法论其实是：
第一，legacy code 不是直接翻译对象，而是证据来源。
第二，AI 的工作不是一次性读完，而是帮助建立可追踪理解。
第三，大程序不能靠 chunk summary，需要结构化拆解和 coverage discipline。
第四，program analysis 要服务 SME review，也要服务 downstream flow。
第五，flow analysis 要消费 program evidence，而不是重新吞源码。
第六，module analysis 要组装 approved flow/program/data evidence，而不是生成更大的总结。
第七，所有不确定性都要显式留下来，成为 TBD、SME question 或 blocked finding。
第八，防幻觉不是提示词问题，而是证据、coverage、TBD、SME review 和 downstream eligibility 的联合约束问题。
第九，SME 要能用 prompt 快速进入正确模式：探索先用 standalone_exploratory，交付不要手搓全链路，优先通过 legacy-modernization-orchestrator 引导进入 chain_ready。
第十，routine 多时必须考虑自动分批 loop，把机械推进交给 agent，把 SME 留给业务判断。
最后
处理 RPG large program source，最重要的不是“AI 能不能读 30,000 行”。
更重要的是，我们能不能建立一种机制，让 AI 每次只说自己有证据支持的话。
大程序可以很大。上下文可以有限。SME 时间也可以有限。
但只要我们把 program、flow、module 的职责分清，把 coverage 状态保留下来，把 unsupported claim 变成 TBD，而不是变成 prose，我们就可以稳步推进。
这才是 large program source 处理的关键：
不是读完。
是读准。
不是总结更多。
是证明得更清楚。
往期推荐：
从程序单到程序链：千万行 IBM RPG 源码的逻辑拆解方法
千万行老代码里的需求，怎么反推出来：7×24 软件工厂的需求治理（上）
跨网关接口标准化与全链路工程化落地：7×24 软件工厂系统重构（下）
附录：可复制 Prompt
下面的 prompt 不一定每次都完整使用。正文里真正重要的原则是：先 standalone 探索，routine 多了自动 loop，正式链路交给 orchestrator 路由。
A. Program Standalone 快速探索
Use Legacy Spec Factory IBM i analysis.Intent: standalone_exploratoryScope: one programProgram: <PROGRAM_NAME>Business question from SME:我们想快速确认这个 program 的主要 calculation、validation、message/status、file update 和 external call。Token rule:- Do not read or summarize the whole source at once.- Do not claim behavior from routines that are only indexed_only.- Mark missing source, copybook, message catalog, external program, or SME judgment as TBD.Please produce an SME-first review:1. Calculation Logic2. Validation Logic3. Exception Handling4. Message Inventory5. File I/O / SQL state changes6. External calls7. Open SME questions请使用 Legacy Spec Factory IBM i 分析方式。分析意图: standalone_exploratory范围: 一个 programProgram: <PROGRAM_NAME>SME 这次关心的问题:我们想快速确认这个 program 的 calculation、validation、message/status、file update 和 external call。Token 规则:- 不要一次性总结整个 source。- 不要把 indexed_only 的 routine 当成 confirmed behavior。- 缺 source、copybook、message catalog、外部 program、SME 判断的地方都标成 TBD。请输出 SME-first review:1. Calculation Logic2. Validation Logic3. Exception Handling4. Message Inventory5. File I/O / SQL state changes6. External calls7. Open SME questionsB. 具体业务问题驱动
SME question:客户额度不足时，这个 program 是直接 reject，还是会继续走人工复核？SME question:这个 batch program 什么时候写入 AR reconciliation file？失败时是否 rollback？SME question:这个 inquiry screen 是否只读？有没有任何 update / audit write / message queue side effect？C. 结论状态分类
For each major claim, classify it as:- confirmed_from_source- inferred_needs_sme_review- blocked_pending_source- blocked_pending_message_catalog- blocked_pending_external_program- blocked_pending_runtime_evidenceDo not upgrade inferred claims into confirmed claims.每个重要结论都请标注状态:- confirmed_from_source：源码可确认- inferred_needs_sme_review：推断，需要 SME 确认- blocked_pending_source：缺源码- blocked_pending_message_catalog：缺 message catalog- blocked_pending_external_program：缺外部 program 语义- blocked_pending_runtime_evidence：缺运行证据不要把 inferred claim 写成 confirmed claim。D. Routine 多时自动分批 Loop
Continue program deep-read in automatic batch loop mode.Intent: standalone_exploratoryProgram: <PROGRAM_NAME>Goal:Process all currently actionable deep-read windows needed for the SME question or downstream flow/module gaps.Loop rules:- Each loop may analyze at most 5 routines/windows.- Do not read the full source at once.- Do not ask the SME to type "continue" after each batch.- Continue automatically until there are no actionable windows, a blocker appears, SME judgment is needed, external evidence is missing, validation fails, or context is near the limit.For each loop, write a checkpoint:- batch number- routines/windows read- source line ranges actually read- artifacts or sections updated- claims newly supported- coverage changed from indexed_only to deep_read- routines still indexed_only- blockers or SME questions- next batch candidatesDo not mark chain_ready.Do not promote any routine/window to deep_read unless this loop actually read its source lines.Do not remove existing TBDs unless the loop closes them with evidence.请继续 program deep-read，进入自动分批 loop 模式。分析意图: standalone_exploratoryProgram: <PROGRAM_NAME>目标:处理当前 SME 问题或 downstream flow/module gap 所需的所有可执行 deep-read windows。Loop 规则:- 每轮最多分析 5 个 routine/window。- 不要一次性读取完整 source。- 不要让 SME 每轮手动输入“继续”。- 自动继续，直到没有可处理 window、遇到 blocker、需要 SME 判断、缺外部证据、校验失败，或上下文接近上限。每轮都写 checkpoint:- batch number- 本轮读取的 routines/windows- 实际读取的 source line ranges- 更新了哪些 artifacts 或 sections- 本轮新增支持了哪些 claims- 哪些 coverage 从 indexed_only 变成 deep_read- 哪些 routines 仍然 indexed_only- blockers 或 SME questions- 下一轮候选不要标记 chain_ready。除非本轮实际读取了对应 source lines，不要把 routine/window 提升为 deep_read。除非有证据关闭，不要删除已有 TBD。E. Flow Assembly
Use legacy-ibmi-flow-analyzer.Intent: standalone_exploratoryScope: one flowFlow slug: <FLOW_SLUG>Trigger model: <batch job | menu option | API | scheduler | screen action>Entry point: <ENTRY_PROGRAM_OR_TRIGGER>Use existing program evidence first.Do not concatenate full program-analysis.md files.Do not reread full source members unless a named gap requires targeted program deep-read.SME question:这个交易从入口到最终落库/返回 response 的路径是什么？哪些 validation、status、message、file update、exception 会改变 flow outcome？Please show:1. Trigger Context2. Transaction Call Map3. Nodes and Edges4. Cross-Program Data Flow5. Validation / Status Propagation6. Persistence Matrix7. Exception Propagation Chain8. Gaps that must route back to program analysis请使用 legacy-ibmi-flow-analyzer。分析意图: standalone_exploratory范围: 一个 flowFlow slug: <FLOW_SLUG>触发模型: <batch job | menu option | API | scheduler | screen action>入口: <入口 program 或 trigger>优先使用已有 program evidence。不要拼接完整 program-analysis.md。不要重新读取多个完整 source member；除非某个明确 gap 需要回到 program 做 targeted deep-read。SME 问题:这个交易从入口到最终落库 / 返回 response 的路径是什么？哪些 validation、status、message、file update、exception 会改变 flow outcome？请输出:1. Trigger Context2. Transaction Call Map3. Nodes and Edges4. Cross-Program Data Flow5. Validation / Status Propagation6. Persistence Matrix7. Exception Propagation Chain8. 需要回到 program analysis 补证据的 gapsF. Chain Ready 入口：走 Orchestrator
Use legacy-modernization-orchestrator.Goal:We want to move from standalone exploration toward chain-ready modernization analysis.Current scope:<one program | one flow | one module | unknown>Current question:<what the SME/team wants to validate or deliver>Available evidence:- Source/program artifacts: <paths/status or missing>- Inventory/object map: <paths/status or missing>- Flow artifacts: <paths/status or missing>- Module/context artifacts: <paths/status or missing>- SME notes/review: <paths/status or missing>- Runtime evidence/joblog/spool/screens: <paths/status or missing>Please route the next step.Do not mark anything chain_ready unless the required gates are met.If evidence is missing, tell us which analyzer or review step should run next.Carry unresolved items as TBD instead of turning them into conclusions.请使用 legacy-modernization-orchestrator。目标:我们想从 standalone exploration 推进到 chain-ready modernization analysis。当前范围:<一个 program | 一个 flow | 一个 module | 还不确定>当前问题:<SME / 团队想确认或交付的内容>当前可用证据:- Source / program artifacts: <路径/status 或 missing>- Inventory / object map: <路径/status 或 missing>- Flow artifacts: <路径/status 或 missing>- Module / context artifacts: <路径/status 或 missing>- SME notes / review: <路径/status 或 missing>- Runtime evidence / joblog / spool / screens: <路径/status 或 missing>请帮我们路由下一步。除非 required gates 已满足，不要把任何产物标记为 chain_ready。如果证据缺失，请告诉我们下一步应该运行哪个 analyzer 或 review step。未解决项请 carry forward 为 TBD，不要写成正式结论。G. Module Readiness
Use legacy-ibmi-module-analyzer.Intent: chain_readyModule: <MODULE_SLUG>Question:这些 approved flows 和 compact program evidence 是否足够支持一个 module-level BRD/spec handoff？Check:1. In-scope flows2. Program Flow coverage3. Data Flow coverage4. Persistence and critical field coverage5. Exception / recovery coverage6. BRD section 1-9 source eligibility7. Candidate-only or generated-draft claims that must remain TBD8. Blocking gaps before BRD/spec handoffDo not create business conclusions from candidate-only, generated draft, or unreviewed source-documented context.H. 每轮输出下一步
End with:- What can be confirmed now- What remains unsafe to claim- Next 1-3 evidence requests- Whether this output is standalone_exploratory or chain_ready- Whether it can feed flow/module/BRD/spec最后请输出:- 现在可以确认什么- 现在还不能安全声称什么- 下一步最重要的 1-3 个补证据请求- 当前产物是 standalone_exploratory 还是 chain_ready- 是否可以进入 flow / module / BRD / spec来源说明
本文基于我们在 2026-06-07 对 Legacy Spec Factory / IBM i large program source 分析方法的一轮设计复盘整理，原始输入为：
• 01_sources/articles/Source - Leo - Large Program Source - 2026-06-07.md
