nhcx-full

版本 1.9.3，构建于 2026-10-19，并已对照 NHA 的 NHCX 软件包 1.0.0 检查。

请先阅读：CORE

在进行任何操作之前，请先阅读 references/CORE.md，并在整个任务中牢记其内容。其中的说明具有约束力：请在每个步骤和每个文件中严格遵循，并在每个步骤（L1 到 L8）开始时重新阅读。其易混淆项明确了容易混淆术语的含义；遇到含义模糊的词时，以 CORE.md 为准。它还列出了基础 URL，以及每种交互的路由、捆绑包、工作流 ID 和回调。

判断所属方

此技能属于提供方：它将 NHCX 集成到医院的 HMIS 中，目标参与方负责发起请求（资格核验、计划、预授权、理赔）并接收答复。payer/ 文件夹是同一技能的支付方版本：目标参与方是保险公司、TPA 或方案系统，负责答复、立案并作出裁定。两者除了网关设计外没有任何共同点；它们的 ID（S1、A1、C1）分别编号，绝不可混用。

在 L1 探索阶段开始时、匹配任何规范之前，先判断所属方，并将其记录为 side，写入 nhcx-plan/discovery.json 和进度日志：

• provider：目标系统接收患者、保存从业人员和就诊记录、向保险公司出账，或设有提交理赔的理赔部门时，继续使用此文件及根目录下的规范、步骤和参考资料，并完全忽略 payer/。
• payer：目标系统保存成员或受益人、产品或保单及其参保信息，在理赔部门裁定理赔，或拨付资金时，到此为止，打开 payer/SKILL.md，从其自身的 L1 开始，将其作为完整技能遵循，并忽略根目录下的所有规范、步骤和参考资料。它链接的所有内容都在 payer/ 内。
• both（既接收患者又运营方案的系统）：需要进行两次集成，每一方各一次，并分别规划和记录；先处理用户要求的一方，绝不可在同一计划文件中混用两套 ID。

如无法确定，在 L1.1 之前询问用户目标系统属于哪一方。如果之后的提示发现目标其实属于另一方，则记录一条 corrected 条目，并从正确一方的 L1 重新开始。

首先检查更新

每项任务开始时，在提出问题和执行 L1 之前，以及之后每个继续此工作的提示开始时，都要检查 NHCX 软件包是否包含此技能的更新版本；如果有，则安装并使用该版本。

此检查独立于 MCP 和知识来源。 无论 L1.0 选择了哪种知识来源，检查始终读取 GitHub 上的软件包；已连接的 nhcx-docs MCP 既不能代替此检查，也不能跳过此检查，且绝不将 MCP 的 catalogue_info 版本与技能版本进行比较。技能有自己的版本：它既不是软件包的发行标签，也不是目录版本，更不是 1.0.0；仅将 skills/manifest.json 中的版本与其比较。

1. 读取软件包的技能清单。 软件包（github.com/nha-in/nhcx-package）会在 skills/ 下保存构建好的技能副本，其中 skills/manifest.json 记录其版本（提供方技能使用 version，skills/payer/ 下的付款方技能使用 companion.version），而 skills/CHECKSUMS.sha256 列出每个文件的哈希值。请从 https://raw.githubusercontent.com/nha-in/nhcx-package/main/skills/manifest.json 读取；若无法读取，则从最新发行版 zip（nhcx-package/skills/manifest.json）读取（zip 地址为 https://api.github.com/repos/nha-in/nhcx-package/releases/latest）。如果已下载软件包作为知识来源，也不能从中读取：它可能早于 main。
2. 比较软件包中的版本与此构建的 1.9.3，逐段按数字比较（1.10.0 比 1.9.2 更新）。
3. 若软件包中的版本较新：拉取并安装。 将软件包（其技能清单包含该版本的发行版 zip；若没有，则使用 main 归档 https://codeload.github.com/nha-in/nhcx-package/zip/refs/heads/main）下载到目标仓库之外的一个新建空文件夹中，并根据 CHECKSUMS.sha256 检查 skills/ 下的每个文件。然后，将加载此 SKILL.md 的文件夹，以及安装在其旁边的所有同级 NHCX 技能文件夹（nhcx-full、nhcx-coverage、nhcx-preauth、nhcx-claim、nhcx-communication、nhcx-payment、nhcx-reprocess 和嵌套的 payer/）替换为软件包中对应的副本，完整替换：不得留下旧版本的任何文件。若技能由插件管理器安装，并且插件管理器提供此版本，则通过它更新；否则以相同方式替换其技能文件夹。安装过程不得改动目标仓库中的任何内容或 nhcx-plan/。用一行话告知用户（“已将 NHCX 技能从 1.8.0 更新到 1.9.0，来源为 NHCX 软件包。”），记录日志，然后从已安装的副本重新读取此 SKILL.md 和 CORE.md，并据此继续；随后 VERSION 会根据已更改的内容重新检查已完成的步骤。
4. 版本相同或更旧： 使用此构建继续。
5. 无法访问或校验和失败： 使用此构建继续，用一行话告知用户原因，并记录原因。校验和检查失败的副本不得安装，哪怕只安装一部分也不行。

每次检查都要记录在 nhcx-plan/knowledge.json 的 skill_update 中（字段为 checked_at、source、package_skill_version、installed_version、result，其中 result 为 current、updated、unreachable 或 checksum_failed），并记录在 nhcx-plan/progress.json 中（步骤 L0，项目 skill update）。

首先确认

在发现阶段开始前、获取知识来源前、读取任何文件前，先向集成人员一次性提出 steps/L1-discovery.md 的 L1.A 部分中的问题，并等待答复：理赔是否必须从已登记的患者开始，以及是否在开始时采集成员 ID；病例创建后是否自动获取保险计划（默认方式），还是由服务台获取，是否自动刷新或手动刷新，以及按付款方和保单获取一次还是每个病例获取一次；医院需要付款方 InsurancePlan 中的哪些字段；是否在预授权页面提供福利核查和授权要求判定；是否可以在入院前提交预授权（之后在 Claim 标签页关联入院），以及患者未入院时，在预授权获批多少小时后撤销该预授权；是否需要补充文件、作为支持信息的 Aadhaar 和生物识别验证；理赔是否需要入院记录；是否在理赔前发送出院通知；服务台是通过 Refresh 按钮检查付款方的回复，还是由病例按固定间隔轮询（间隔多久）；以及服务台必须查看哪些付款方函件。将每项答复记录在 nhcx-plan/plan.json 的 decisions 下。凡是有问题需要确认，就绝不凭猜测行事。

有两项内容绝不询问，因为发现阶段会确定它们：HMIS 自带的 M1（ABHA 创建、关联和验证、患者档案中的 ABHA 标识符、ABDM 会话令牌）只要 L1.3 找到，就自动复用；只有不具备自带 M1 的 HMIS 才使用 A19. ABHA Create and Verify (ABDM M1)；以及宿主的 UI 组件（输入提示、选择器、表格、标签、卡片、折叠面板、对话框、日期选择器、文件输入框、闪现提示或 toast、带圆点徽标的标签页）会在 L1.2 中查找，并用于每个屏幕。

目标

为目标 HMIS 添加付款方侧的 NHCX 理赔功能，覆盖从保单搜索到付款的全流程，并让 NHCX 网关在应用程序内部运行。

此技能仅包含实现此目标所需的规范；SCOPE 部分列出了这些规范。它提及但未包含的规范，会标明提供该规范的技能。

要求

• 目标 HMIS 的源代码，且其构建、测试和迁移命令均可正常运行。
• NHCX 参与方凭证，供医疗机构使用：参与方代码、ABDM 客户端 ID 和客户端密钥，以及为该代码注册的加密证书私钥。
• NHCX 可访问的公共 URL，注册为参与方的 endpoint_url，并路由到应用程序的入站路径（/in/<path> 或 /v1/<path>）。
• 知识来源：nhcx-docs MCP 服务，或可下载 NHCX 软件包的网络访问（参见 KNOWLEDGE SOURCE）。ABHA 调用（A19）仅在 HMIS 没有自带 M1 时需要，此时必须使用 MCP：软件包不包含 M1。
• 受益人的生物识别认证（A18，对任何付款方均可选，对 PMJAY 则为必需）需要在服务台机器上安装已注册的指纹或虹膜设备及其 RD 服务，或者患者手机上的 ABHA 应用用于面部认证；还需要一个其会话令牌可被 ABHA 和生物识别服务接受的客户端 ID。
• 端到端测试需要：沙盒凭证、会响应的沙盒付款方，以及测试受益人。

知识来源

NHCX 事实（API 路径和标头、FHIR 配置文件和示例 Bundle、代码、工作流 ID、错误代码、上线规则）来自一个知识来源，该来源在 L1 开始时选定，并记录在 nhcx-plan/knowledge.json 中。详情见：references/KNOWLEDGE.md。

1. nhcx-docs MCP。 如果已连接 nhcx-docs MCP 服务（catalogue_info 有响应），请使用它：search_docs、get_operation、get_fhir_profile、get_fhir_example、validate_request、decode_error（不要对 NHCX Bundle 使用 validate_fhir：它只了解 ABDM 的 DocumentBundle 系列，见 references/KNOWLEDGE.md）。
2. GitHub 软件包。 否则，从 github.com/nha-in/nhcx-package/releases 下载最新版本的压缩包（nhcx-package-v<version>.zip），将其保留为 nhcx-plan/knowledge/nhcx-package-v<version>.zip，解压到 nhcx-plan/knowledge/nhcx-package/，并根据其中的 MANIFEST 进行检查。

同一个 MCP 服务还提供 ABDM 的 HIE-CM 目录。ABHA 创建与验证（M1），以及 HMIS 在 M2 下归档、此技能附加到理赔中的健康记录（D28. claim_document“来自记录”），都从该目录读取，而不是从此技能读取（包括 abdm-m2 提示词和 references/KNOWLEDGE.md 中的原子）：A19. ABHA Create and Verify (ABDM M1) 说明当 HMIS 没有自己的 M1 时应用会如何处理，并指出要通过 get 读取的 M1 流程和操作 ID；abdm-m1 提示词则是其路由器。已经有 M1 的 HMIS 会保留它：不会构建 A19，也不会向用户提问。受益人的生物特征认证在此处完整定义：A18. Biometric Authentication，以及其在场证明卡片 S18. Beneficiary Verification，因为 NHCX 软件包包含这项功能，且发送操作依赖它。

在协议相关问题上，知识来源优先于这些规范；在应用行为上，规范优先。非协议声明会标记为 REF（参考实现的选择）、PAYER（取决于付款方适配器）或 SANDBOX（仅在沙盒中观察到）；所有付款方专属值都列在 references/PAYERS.md 中。其中的 ID（例如 NHA 用例 C5）不是此技能的 ID：请写作 nha:C5。

STEPS

按顺序遵循 steps/INDEX.md。每个步骤都会在目标仓库的 nhcx-plan/ 下写入一个文件，每个子步骤和文件变更都会记录在 nhcx-plan/progress.json 和 nhcx-plan/progress.md 中（steps/LOG.md）。每次提示词结束时，无论执行了什么，都要运行报告生成器，重新生成 nhcx-plan/report.html：将每个计划文件（进度、日志、发现、映射、计划、代码、验证、试运行和端到端结果）分别放在一个自包含页面的独立标签页中，错误置顶，并带有刷新按钮；nhcx-plan/make-report.sh 和 make-report.bat 每 10 秒重新生成一次报告（steps/LOG.md）。

1. L1 发现：知识来源、目标的技术栈，以及 SCOPE 中每一项规范的状态（已找到、部分找到或缺失），并注明文件和行号。
2. L2 映射：将目标字段映射到数据库列和 FHIR 元素。
3. L3 集成规划：按照 SCAFFOLDING 的构建顺序，为此目标制定阶段、步骤和子步骤，包括 HMIS 首页、侧边栏或导航栏中的 “Claims” 条目。
4. L4 代码规划：根据目标的约定，将 SCAFFOLDING 映射到目标上，列出文件、函数及其顺序。
5. L5 编写代码：逐个文件编写，并记录在 nhcx-plan/code.json 中，同时遵循脚手架的依赖规则。
6. L6 验证代码：根据规范检查每个文件。
7. L7 试运行测试：不使用网络；使用 NHCX 和注册表的模拟对象。
8. L8 端到端测试：针对 NHCX 沙盒，按照 references/TESTS.md 中的 T 测试，分别通过界面（GUI）和命令行（CLI）逐项运行。

脚手架

references/SCAFFOLDING.md 描述了代码在目标 HMIS 中的形态。请在 L3 之前阅读，并在 L5 期间保持打开。

• 一个 NHCX 模块（nhcx/），包含 gateway/（G，进程内）、fhir/（F，纯构建器和解析器）、services/（A）、callbacks/（C）、models/ 和 migrations/（D）、screens/ 和 routes（S），以及消息 archive。
• 现有 HMIS 模块仅针对 NHCX 需要的字段进行更改：患者 ABHA（D3，通过 HMIS 自带的 M1（如有），否则通过 A19 验证或创建）、执业者 HPR id 和资质（D2）、机构 HFR id 和参与者代码（D1），以及“Claims”导航项。
• 宿主的组件。 每个屏幕都由 HMIS 自带的组件构建，即 L1.2 为每种类型记录的组件（自动补全、选择器、表格、标签、卡片、折叠面板、对话框、日期选择器、文件输入、闪现提示或 toast、带圆点徽标的标签页），因此两个不同的 HMIS 最终使用各自的组件构建相同的屏幕（references/SCREENS.md，组件套件）。只有当宿主缺少某种组件时才编写该组件，并使用宿主的设计令牌设置样式。
• ABHA 是患者标识。 通过病例的 ABHA 号码查找标记为“来自记录”的附件记录，以及与病例关联的入院记录。
• 核心规则：预授权在理赔提交后即锁定。 预授权获批且理赔已发送给付款方后，预授权将变为只读：不得增强或更改；只能取消，且仅限付款方决定理赔之前。更改请求将被拒绝，并提示“理赔已发送给付款方，因此预授权为只读状态：无法进行增强或更改。只有在付款方审核理赔期间才能取消。”；逾期取消请求将被拒绝，并提示“付款方已决定理赔；预授权不能再取消。”在入口处被拒绝的理赔从未送达付款方，因此预授权仍保持开放状态。
• 理赔一旦决定，绝不再次发送。 被拒绝的理赔将作为重新处理请求退回（工作流 36，原因 claimrejected 或 rejectiondisputed）；已批准或部分批准的理赔可以申请余额支付（release）。
• 依赖规则： 屏幕调用服务并读取模型；只有服务和回调会写入理赔表；FHIR 构建器绝不接触数据库或网关；网关对理赔一无所知；通过轮询找到的回复由同一个回调处理程序应用。
• 仓库之外： 网关配置、客户端密钥、私钥、账本和归档目录。
• 测试位于 tests/nhcx/（试运行和端到端测试），计划文件位于 nhcx-plan/。
• 构建顺序分阶段进行，从网关基础到导航项；L3 按此顺序制定计划，并省略 SCOPE 中不包含规范的阶段。

L4 会根据 L1 发现的目标自身惯例，将这些占位名称映射到目标的对应约定，无论其使用何种语言、框架和模块形式；各部分的划分及依赖方向不会改变。任何规范都不假定使用特定框架、ORM、路由器或组件库。

范围

此技能包含的规范：

• Screens (19): S1, S2, S3, S4, S5, S6, S7, S8, S9, S10, S11, S12, S13, S14, S15, S16, S17, S18, S19
• APIs (18): A1, A2, A3, A4, A5, A6, A7, A8, A10, A11, A12, A13, A14, A15, A16, A17, A18, A19
• Callbacks (10): C1, C2, C3, C4, C5, C6, C7, C8, C9, C10
• FHIR (19): F1, F2, F3, F4, F5, F6, F7, F8, F9, F10, F11, F12, F13, F14, F15, F16, F17, F18, F19
• Database (32): D1, D2, D3, D4, D5, D6, D7, D8, D9, D10, D11, D12, D13, D14, D15, D16, D17, D18, D19, D20, D21, D22, D23, D24, D25, D26, D27, D28, D29, D30, D31, D32
• Gateway (11): G1, G2, G3, G4, G5, G6, G7, G8, G9, G10, G11
• Tests (19): T1, T2, T3, T4, T5, T6, T7, T8, T9, T10, T11, T12, T13, T14, T15, T16, T17, T18, T19

基于相同来源构建的其他技能：

• nhcx-coverage：受益人保单搜索和承保资格。
• nhcx-preauth：预授权：付款方的计划、从中引用的项目、承保和授权要求检查、预授权、额度提升、取消和状态。
• nhcx-claim：出院后的索赔提交、裁定结果和状态。
• nhcx-communication：付款方查询、通知和备注，以及相应回复。
• nhcx-payment：付款通知及其确认。
• nhcx-reprocess：对已裁定或部分支付的索赔重新处理并释放余额。

VERSION

这是 nhcx-full 1.9.3 版，构建于 2026-10-19。其协议表（工作流 ID、状态、基础 URL）已对照 NHA 的 NHCX 软件包 1.0.0 核验（github.com/nha-in/nhcx-package）。

• 工作开始时记录此信息：nhcx-plan/knowledge.json 和 nhcx-plan/progress.json 的 target 中包含 skill 和 skill_version，nhcx-plan/report.html 的页眉也会显示它们。
• UPDATE FIRST 可能已在提示开始时从 NHCX 软件包安装了较新的构建；此时记录的版本是旧版本。
• 如果后续提示运行时使用的技能版本与记录的版本不同，请在继续前告知用户，将其记为一条 corrected 记录，并注明两个版本；同时根据已变更的规范重新检查已完成的步骤。
• 如 KNOWLEDGE SOURCE 所述，协议方面以更新于 1.0.0 的知识来源为准；请在 knowledge.json 中注明差异。

1.9.3 版的变更；继续处理由较早版本开始的工作时，请据此重新检查：

• S17“网络内”取代 1.9.2 版的“有效承保”规则：只要该医院曾为任意患者从某付款方获取过保险计划（D10 计划已结算为 ready），该付款方即属于网络内。D32 新增 plan_fetched_at（由 C4 设置一次；通过迁移填充此前已获取的计划对应值；刷新时永不清除）；付款方检查会在该值未设置时，从已获取的计划中填充一次，并返回 on_network 和 plan_fetched_at。界面显示一条带绿色勾选标记的内容：“网络内：该医院已从 获取保险计划。”，否则不显示内容。 Changes in 1.9.2, to re-check against when an earlier build is continued:
• S17“网络内”：只有验证结果为符合条件的付款方保单才计入；有一份时，显示一行带绿色勾选标记的“In network: this hospital holds policy(s) of with valid cover.”；否则完全不显示。
• 不允许补录预授权：S4 入院日期选择器从今天开始；保存或发送日期早于今天的新预授权时，拒绝操作并提示“The admission date cannot be before today; a pre-authorisation is not raised back-dated.”（D9、A4、S9）。付款方已有的日期可以保留。
• 每项 S4 诊断都标记为 Provisional 或 Final（D25 dx_type），并按 PMJAY 的发送方式，以 F8 diagnosis.type SNOMED CT 148006 或 89100005 发送。
• S11 出院日期选择器的最晚日期为今天；日期晚于今天时，拒绝操作并提示“The discharge date cannot be after today.”（D20）。
• 理赔的决定显示为“Final approval”，可全额或部分批准（S11、处于 Claim 阶段的 S5）；预授权保留原有标签。
• 付款：在工作流 30 中，以 paid 状态发起付款，包含所有金额，但不含 UTR；在 31 中以 cleared 状态完成付款，并包含 UTR；两者共用一个 PaymentNotice id。已付款表示状态为 cleared，或状态为 paid 且包含 UTR；没有 UTR 的 paid 通知属于已发起付款，绝不会记入账单（F13、D21、A17、C10、S12、A8）。旧的“disposition contains initiat”规则已废弃；S12 的“Initiated, UTR awaited”标签表示没有 UTR 且状态不是 cleared。
• S12 的差额按理赔的批准金额计算，绝不按申报金额计算：通知中可核算的金额（每条通知中，其 payment、TDS 和 deduction 行；否则为其 amount）等于批准金额时，差额为零；否则差额为批准金额减去可核算金额，且绝不低于 0（D21、D22、A17 payment_approved、payment_accounted、payment_shortfall）。第四个磁贴显示“Approved”（理赔的批准金额），而不是“Claimed”。

Changes in 1.9.1, to re-check against when an earlier build is continued:

• NHCX 设置页面（S19）是独立的计划阶段（L3 阶段 3，包含 D1、参与方主数据 D32 及其每日刷新），始终构建；它位于 HMIS 的机构设置下，并拥有独立的“NHCX”入口；没有 S19 或参与方主数据的构建都应补上。S19 现在与参考实现一致：参与方代码会回退到网关默认值；注册表卡片可注册端点（“Update the registry”）；密钥卡片可执行 stage、register certificate、activate、retire；另有一张卡片链接到医生和员工主数据。S17 和 S18 分别放在阶段 4 和 6。L3 会检查技能列出的每个页面是否已交付，或是否附有理由而被移除；L8 会在任何理赔测试前打开 S19。

Changes in 1.9.0, to re-check against when an earlier build is continued:

• 首先更新：每个提示词都从读取 NHCX 软件包的技能清单（skills/manifest.json）开始；如果软件包构建版本较新，则安装该版本，并对照 skills/CHECKSUMS.sha256 检查。
• 向用户显示的每个步骤、子步骤、测试和规格编号都带有名称（L3 Integration Planning、T3 ... (CLI): pass）；名称来自 nhcx-plan/names.json，并在 L1.2 中写入（LOG.md、LOGN）。 1.8.0 中的变更，继续早期构建时需重新核对：
• 这些步骤与框架无关：L1 记录主机的技术栈及按类型划分的组件，L4 和 L5 据此构建每个屏幕，L6 则拒绝重复组件。
• 如果已有 M1，则直接复用，无需询问；如果 M1 已存在，L3 会舍弃 A19 和 S13 至 S15 中新增的 ABHA。通过 ABHA 查找记录和入院信息。
• 创建病例后，plan.trigger 默认为自动触发（复用相同保单的就绪计划，否则发起请求）。项目明细、福利核验和授权要求裁定均位于预授权选项卡中，每个项目都根据付款方的保险计划进行报价（Blood 或 Ambulance 等单纯的承保福利不会作为项目）。
• 两个付款方适配器 gov 和 generic，根据参与方主数据的实体类型选择（pmjay 对应 gov，kyrocare 对应 generic）；绝不显示适配器名称。
• 保险计划请求和状态查询使用工作流 ID 1；查询答复使用 request.initiated。
• 理赔选项卡依次为 Overview、Pre-authorisation、Claim、Communication、Payments 和 Logs（按最新时间优先排序，且只有此处显示关联 ID）；付款方有新内容时，选项卡旁会显示圆点；发起预授权后才会显示 Claim 和 Payments。
• 已裁定的理赔绝不会再次发送：只有被拒的理赔才会请求重新处理，已批准理赔的余额发放则会保留。
• 核心规则：理赔一旦发送给付款方，预授权即为只读（不能增强或更改），且仅在付款方裁定理赔之前可以取消。

参考资料

• references/CORE.md：基准 URL，以及每次交互的路由、捆绑包、工作流 ID 和回调，集中于一页。
• references/KNOWLEDGE.md：NHCX 知识来源、MCP 或 GitHub 包，以及每种查询对应的问题。
• references/SCREENS.md：范围内的每个屏幕、对应路由及功能。
• references/API.md：范围内的每个 API 调用及其功能。
• references/CALLBACK.md：范围内的每个 NHCX 回调及其功能。
• references/GATEWAY.md：进程内 NHCX 网关的每个部分及其功能。
• references/FHIR.md：范围内发送或读取的每个 FHIR 资源及其用途。
• references/DATABASE.md：范围内的每个表、每行代表的内容，以及使用该表的屏幕、API、回调和 FHIR 资源。
• references/PAYERS.md：付款方适配器、各自的工作流 ID 和规则，以及 REF、PAYER 和 SANDBOX 标记的含义。
• references/OPERATIONS.md：生产环境切换，以及以多个实例运行应用程序。
• references/TESTS.md：范围内的每个端到端测试，包括 IRDAI 和 PMJAY；每项测试都通过屏幕和命令行运行。
• references/READSETS.md：实现每个屏幕、API、回调和网关部分前需阅读的其他规范。
• references/SCAFFOLDING.md：目标项目中的模块布局、各部分的内容及每份规范的归属位置。

输出

在目标代码库中：

• 按照 SCAFFOLDING 中的布局，包含 NHCX 模块和已更改的 HMIS 模块中的代码。
• tests/nhcx/ 下的测试：dry-run（L7）和端到端（L8），端到端测试包含 GUI runner 和 CLI runner（nhcx-e2e）。
• nhcx-plan/ 下的计划文件：knowledge.json、discovery.json、mapping.json、plan.json、code-plan.json、code.json、validation.json、dry-run.json、e2e.json、names.json（每个 id 的名称）、日志 progress.json 及其配套的 progress.md，以及 report.html。每次提示词结束时，都要由报告构建器（report.py 或目标语言的等效工具）重新生成 report.html，并将其 make-report.sh 和 make-report.bat 放在旁边。