PDF → BookMD → HTML
Astra 分工与固定生成器

1. P0 · 固定范围与版本

   程序记录 PDF 哈希、物理页范围、章节范围、政策版本，以及用户确认的固定生成器、模板、组件与验证规则版本；明确整书或试跑。先核对已声明能力；发现不支持的内容类型或结构就进入 HOLD_FOR_USER，不能自行扩展生成器。不能用候选抽取结果反推原书范围。

2. P1 · 观察 PDF，建立来源候选

   程序提取原始文字、图像、页面截图；Luna max 看原页做 OCR、分区和阅读顺序候选。原始抽取不被“清洁结果”覆盖。

3. Gate A · 来源六专项

   独立检查整页区域覆盖、OCR、源阅读顺序、公式发现、表格发现、图片提取。全部完成、问题修完且证据有效后，来源快照才可冻结。

4. P2 · 形成 BookMD 与对象登记

   Spark 清理和翻译纯文本，包括图题、表内文字；Luna max 识别数学与表格的结构。图片默认原图。正文、公式、图、表通过稳定 ID 与来源关联。

5. Gate B · 内容七专项

   检查译文、纯文本连续性、块类型、数学结构、表格结构、图片使用规则和交叉引用。检查的是中间内容，不提前替代浏览器视觉验收。

6. P3 · 固定生成器构建 HTML

   只运行冻结的现成代码：解析受限 BookMD → 语法树 → 绑定来源和对象 → 固定组件渲染 → 嵌入资源。HTML 不是修复源；不支持的结构、组件缺陷或需要越界配置都停止当前转换并报告，不自动改引擎、不转成截图绕过。

7. Gate C · 机械验证

   程序验证结构、引用、格位、数学合法性、内容序列、资源和构建模式；生成带哈希的结果。不使用 AI 凭感觉认定代码断言通过。

8. Gate D · 成品八专项

   冻结实际 HTML 后，分别审核文本版式、数学、表格、插图、阅读器、资源、重复和可访问性。视觉任务必须收到浏览器实际截图。

9. P4 · 正式打包与发布

   固定程序核对 A/B/C/D 都属于当前版本、没有未解决问题，再上传并验证公网加载。样书预览是另一个明确标注的通道，不能借预览上传绕过正式门禁。

可调用的模型标识：gpt-5.3-codex-spark、gpt-5.6-luna（max）、gpt-6-astra（high/xhigh）。官方文档将 Spark 标为纯文本；Luna 和 Astra 支持图像输入；Astra 的模型标识为 gpt-6-astra，官方支持 high / xhigh 推理档位。依据：Codex 模型说明、Luna 模型页、Astra 模型页。模型文档核对日期：2026-09-06。

---
schema: bookmd/1
title: 示例章节
---

@block id=p020-g03 kind=paragraph source_map=sm-p020-g03
这里是经过对照的译文。行内数学由 @math eq-inline-01 引用。
@end

@equation eq-01
@figure fig-1-18
@table table-1-01

正文文件 + alignment.json + math.json + tables.json + figures.json
                         ↓
                    固定组件生成
                         ↓
                     output/book.html

本段是结构示意，实际语法以生成器的 CONTRACT 为准。

八类公式模板作为目标规范保留：行内上下标、映射与元组、向量与矩阵、行列式、方程组、求和与上下限、多行对齐、表内数学。某类模板出现在示例报告里，不等于冻结生成器已完整支持该类所有结构；以用户确认版本的能力合同为准。模板不能自动保证识别忠实度。

生成器固定：允许修改数据，不允许顺手修改引擎

HOLD_FOR_USER · 等待用户决定（工作流状态，不是假装已调用目标暂停接口）
原因：当前固定版本无法无损处理某源对象
附：源位置 + 最小复现 + 能力缺口 + 影响范围 + 方案
等待：用户决定是否修改、修改范围与采用方案
获准后：独立新版本修订 → 回归 → 确认切换 → 作废受影响旧证据 → 恢复转换

能力预检不能保证提前发现所有缺口；后续任何阶段发现同类问题都采用同一停止规则。Astra 有能力写代码不等于有权限改生成器。本报告的编辑代码不是书籍生成器，二者分开。

公式和表格不受“保留原图”影响：公式仍以原生数学结构渲染，表格仍以原生表格渲染。否则等于把先前的公式截图问题带回来。

每图决策：
没有针对该图的明确用户请求 → 原书提取图
有逐图请求 → 校验 figure_id + 原图哈希 + 请求记录 + 允许修改范围
           → ChatGPT Image 生成候选 → 原图/候选截图对照
           → 通过才替换；不通过则保留原图并说明

图片审核问“与原图是否一致”，不问“原书科学观点是否正确”。

Gate A：来源本身是否被忠实登记

Gate B：BookMD 与对象内容是否正确

Gate D：浏览器中真实成品是否可读

所有专项都要绑定对应案例库的版本和案例 ID，再给本次应审对象，不用一句“认真通读”替代操作标准。无表格等不适用项需要来源范围支持的缺席证据；不能仅因表格登记为空，就认定原书没有表格。

1. 先派单，后审核。调度器从冻结来源/成品生成每项 expected_ids，绑定规则和案例库版本；任务不能自己缩小范围。保存实际模型、任务 ID、快照哈希和开始时间。
2. 发现第一项问题仍继续。该专项记录问题和截图后继续检查本专项余下范围；其他专项继续审核同一冻结版本。读取失败等工具故障需要明确记录缺失范围，不能把中止当完成。
3. 审核期间不改被审文件。修复可以在新候选上准备，不能让仍在阅读的 agent 前半本看旧版、后半本看新版。
4. 汇总后只改问题对应的上游。文本改文本单元，公式改数学 AST，表格改格位，图片改提取或资产选择，版式只改已支持的输入或文档化配置；需要改组件就停止并等待用户批准。每个补丁有精确旧值、允许变动范围、前后差异与回归要求。
5. 重新构建并核验受影响范围。改单句不等于所有图片重审；仅在用户批准并切换组件新版本之后，才按影响范围回归该组件全部实例。具体由依赖与内容变更确定，不能仅把报告上的旧哈希换成新哈希。
6. 全部当前证据满足要求才能过门。少一项、仍有问题、未读完、旧版本、缺截图，都不是通过。代码判定的是证据完整性和可计算规则，AI 负责其专项语义或视觉判断。

2026-09-06 核查结论：0 / 4 道正式 Gate 可认定通过。

执行：python3 scripts/gates.py --project-root . --gate ALL
退出码：1；总状态：FAIL
核查对象：已发布的前两章候选，不是整本月球书

脚本会在缺少任务清单时提前返回。因此上表是“当前首先阻止放行的原因”，不是所有潜在缺陷的完整列表。A、B、D 这次运行的是聚合判定，不能记成其专项审核已经启动。

真正的执行偏差

1. 上次我优先做了工程试跑。我想验证来源账本、翻译输入、数学/表格结构和生成器能不能接起来，于是用显式草稿模式提前生成并发布了预览。
2. 但我没有把后半段的正式审核调度补起来。缺的不只是几个 PASS 字段，而是独立的应审任务清单、绑定案例库的审核任务，以及修复后的全量有效证据。
3. 生产任务的审阅不能顶替整道门。OCR 生产者的自检、翻译候选对照、图像候选比对、41 项代码测试，各自只证明一部分，拼在一起也不自动成为 A→B→C→D。
4. “试跑交付完成”被我与“整条流程完成”交代得不够清楚。前者可以交工程结果，后者必须完成审核。这里是执行和状态说明的问题，不该让你自己从空白状态猜。

哪些工作确实做过

57 个范围内物理页，2,669 个来源原子，252 个分组，40 条明确续接；31 幅插图、2 张表、6 个已登记数学对象；402 个翻译 ID。已有 13 个翻译包、11 个独立忠实度报告及 1 个漏项补查、41 项生成器测试和部分浏览器测量。这些是工作量与局部证据，不是正式审核通过数。“6 个已登记公式”也不证明来源中只有 6 个应登记公式。

完整试跑案例见前两章试跑结果报告；旧报告中的强制生图讨论已被本版图片规则取代。

不能承诺“永远不再出错”。可以做到的是：不让漏派单、无证据、旧版本通过或已知未修问题被包装成终审完成；出现问题时能定位到原页、源块、对象、组件和责任检查点。

来源清单怎样防止“漏了却还闭合”

有两套相互核对的清单：第一套从 PDF 页数和用户范围生成“每页都必须看”的清单；第二套才是抽取出的对象清单。Luna 的覆盖专项先看无框整页及分区放大图，再看带框对象对账图，找没有登记的区域、被误排除的内容。代码只能检查“登记内容都有归属”，不能证明未登记的内容不存在。

Gate A 的闭合条件是：全部范围页有有效观察证据；每个可见内容区均有保留、合理排除或待解决决策；保留区域映射到来源原子；无未解决区域；来源六项当前版本均完成。它是有证据的审核标准，不是对 PDF 信息完整性的数学保证。

源块 A 与 B 接不上，先定位再翻译

Spark 记录 A 的末句、B 的首句和源 ID，不自行脑补连接。调出 A/B 所在整页及相邻页，Luna 判断漏块、错阅读顺序、图题混入正文还是原书本来如此。漏块回 P1；错连接修阅读顺序；源文正常而译文跳义只修译文。不能看到跨页就机械拼接，也不能不说明就调整原书内容。

上表是应补齐的状态展示规范。当前原型有证据校验代码，但缺正式任务清单和完整派单/回收执行，不能声称这套状态面板已上线。

下一次真要把月球样书跑到通过，按这个顺序补

1. 先由用户确认固定生成器与能力合同。新图片政策如与现成实现冲突，先报告冲突并请用户决定修订范围，不能自动改选图逻辑；在已支持的资产选择范围内，无逐图授权的生成图回原图，保留历史证据。
2. 从物理 PDF 页范围创建 A 的六专项清单与证据包，实际运行、修复并冻结来源。不能直接给旧记录补一个 PASS。
3. 依据确认来源重新核验 BookMD，解决已知译文问题，建立并完成 B 的七专项。
4. 生成正式候选，执行 C；冻结新 HTML 后执行 D 的八专项及必要回归。
5. 四道门都通过才替换正式书籍入口；预览与正式状态分开。这些后续执行不包含在本轮报告更新中。

1. 最新用户决定：所有图默认不重做；只有明确指定某张图时才重做。原 Sol 职责全部切换 Astra；生成器固定，能力不足时停止并由用户决定是否及如何修改。本文图片政策与模型任务分工是项目执行规范，不冒充外部研究结论。
2. 本地核查：月球试跑目录的 scripts/gates.py、build/validation.json、任务/证据目录存在性、qa/preview-open-issues.json 与 PILOT-HANDOFF.md。v4 于 2026-09-06 实际运行 ALL 聚合，返回 1；v5 只沿用这份历史记录，没有重跑书籍 Gate。
3. 当前样书身份：月球书前两章候选，23,648,354 字节；SHA-256：febe6a847c725b22c95c33d3692bcebdd755325aa2721b6f386c937f4927ff13。范围为原 PDF 物理页 12–68；不代表整本书。
4. 工程历史：前两章实测试跑与失败案例；此前完整管线方案 v3。v4 补充真实门禁诊断，并替代旧图片自动重绘政策；旧记录保留用于追溯。
5. 模型能力边界：Codex 模型说明、GPT-5.6 Luna、GPT-6 Astra。只用来核对模态与推理配置；未将其作为本书翻译或视觉审核质量保证。

审查对象要分清：现在有三套不同的东西

最小复现：不是猜测模型会不会犯错

我复用插件自己的两页测试工程，在临时目录里更改一个条件，再调用其原有校验器。PDF 页数沿用原测试的模拟值 2；没有把假证据写进任何真实书籍项目，也没有伪造一次真实终审。下面的“通过”指这份合成输入获得程序 passed: true，不是书籍质量通过。

插件根目录：plugins/pdf-book-to-html/
既有测试：python3 -B -m unittest discover -s plugins/pdf-book-to-html/tests -p 'test_*.py'
结果：Ran 21 tests — OK

额外探针：reports/scripts/probe-plugin-gates-v5.py
命令：python3 -B reports/scripts/probe-plugin-gates-v5.py
结果副本：reports/pdf2html-plugin-audit-v5-probes-2026-09-06.json

实验只更改 TemporaryDirectory 中的合成工程。
本轮没有修复这些漏洞，因此旧校验器仍保留上述行为。

逐项建议：改哪里、为什么改、怎样验收

优先级说明：P0 是可能错误放行或违反用户授权边界；P1 是覆盖、定位或维护可靠性。所有代码修改均为建议，不构成自动修改许可；涉及生成器、组件或配套验证规则时，必须走前文“等待用户决定”的流程。

为何这么显眼的问题还能漏过？能说到哪里，不能说到哪里

最直接的解释：现有系统能证明“有人交了一份写着 PASS 的文件”，却不能充分证明“那个人看了当前版本、看全了，而且附件真的展示了被审对象”。截图哪怕肉眼一眼就能看出问题，也要先保证审核者实际收到并检查了那张截图，且这次观察没有被旧报告替代。当前这些条件没有被可靠落实。

本轮实验证明的是门禁和测试的缺口，不证明某一个历史 reader 偷懒、伪造或没有视觉能力。要归因到某次运行，还必须取回该任务的实际输入、截图、阅读范围、版本和逐项输出。缺少这些记录，就应写“无法追溯具体漏检环节”，不能补一个听起来专业的理由。

因此不建议再叠一轮泛读，也不建议把所有工作换成 Astra。保留你要求的专项分工；让每个专项拿到准确的应审对象和可用证据，发现问题继续完成本专项，再由确定性规则汇总。Astra 只处理剩下的少量难项，以及获准后的工程工作。

我建议的修改顺序：先堵假通过，再提高读书质量

1. 先明确权限和版本。确定采用哪个已写好的生成器；把“不可擅改、能力不支持就等待用户”落实为只读边界和能力检查。新图片政策、Astra 路由成为唯一合同。当前转换不以自行改代码来适配。
2. 经你批准后，单独修门禁。优先修未执行状态、空证据、目标映射、范围分母、版本过期与数学对象类型；使用本轮反例做回归。不要同时大改视觉外观和翻译，避免原因混在一起。
3. 再接专项派单与证据回收。21 检查点按依赖分阶段运行，每个 agent 至多一个检查内容；纯代码断言不是 AI 专家。先跑小范围完整闭环，证明不是只有分工表没有实际任务。
4. 最后做来源和视觉闭环。每页覆盖、跨页顺序、每图源/成品对照、数学显示、表格和界面分别完成；仍有不可辨来源或生成器缺口，就停在具体对象上请你决定。

本节依据：插件 SKILL.md、references/workflow.md、quality-contract.md、reader-specialists.md、案例库索引/绑定与失败分析；scripts/init_book_project.py、validate_book.py、stillframe_reports.mjs、现有测试与本轮探针；安装缓存与工作区模板对比。以上路径均为工程追溯标识，必要代码行为和实测结果已写在正文，公网读者无需访问本机文件。