# 开发审计报告 创建人员：management.admin 文件职责：记录 project-info 根级编码体系的独立审核结论与证据入口。 管理规范/模板：../../common/dev-doc/开发审计规范.md 引用文件：开发事项总纲.md；开发事项计划.md；开发执行日志.md；开发问题记录.md；../项目事项审计报告.md 记录方式：append-only；执行方只登记候选，独立审核角色追加正式结论。 ## DEV-AUDIT-PROJECT-INFO-DEV-ROOT-RESTORE-20260724-001 - 审计对象：`DEV-SMOKE-PROJECT-INFO-ROOT-20260724-001` - 关联事项：`DEV-ENV-RESTORE-PROJECT-INFO-20260724-001` - 执行方：management.admin - 独立审核方：management.observer - 检查范围：3 个根目录、8 份根文档、`systems.dev` 配置、目标映射、根级账本连通性和 no-code 边界。 - 候选执行状态：完成，等待独立执行复审。 - 审计状态：PENDING_INDEPENDENT_EXECUTION_REVIEW - 结论：尚未形成；本条不得解释为 PASS 或解除 blocker。 ### 2026-07-24T18:20:20.8456249+08:00 独立执行复审归因 - 外部独立审核：`management.observer / mgobs` - 管理审计：`AUDIT-20260724-PROJECT-INFO-DEV-TARGET-RESTORE-EXEC` - 审核终态：`PASS/issue_count=0/blocking_issue_count=0` - 本审计处置：`PASS` - 归因说明：本结论由 management.admin 严格依据 management.observer 的同一审计补充 PASS 终态追加，不是执行方自审；根目录、8 份根开发文档、配置、账本连通性和 no-code 边界均已独立复验通过。 - 权限边界：本 PASS 只关闭环境恢复 dry-run，不授权 V007 源码、测试、synthetic、数据库或业务执行。 ## DEV-AUDIT-PROJECT-INFO-LOCAL-MEDIA-TRANSCRIBE-LONG-VIDEO-OPT-DESIGN-20260801-001 - 记录时间：`2026-08-01T02:27:47+08:00` - 审计阶段：重型性能优化方案独立审核；本条不是实现审核或真实资源验收。 - 审计对象：`DEV-PROJECT-INFO-LOCAL-MEDIA-TRANSCRIBE-LONG-VIDEO-OPT-20260801-001` - 请求交接：`HANDOFF-INFODEV-INFOREV-LOCAL-MEDIA-TRANSCRIBE-LONG-VIDEO-OPT-DESIGN-REVIEW-20260801-001` - 执行方：`dev.developer.project / infodev` - 独立审核方：`dev.reviewer.project / inforev` - 需求：`ai-media-processor/draft/本地视频语音转写_4小时长视频性能与资源优化需求_v0.1.md`，SHA-256 `BB3030AD336CEE96194A26F691BF494D8D4976A4703D83BBF506BA3544CA0898` - 方案：`dev-doc/project-doc/开发方案/CODE-DESIGN-PROJECT-INFO-LOCAL-MEDIA-TRANSCRIBE-LONG-VIDEO-OPT-V001.md`，`5697 bytes`，SHA-256 `23CD6FB7CE7D68283F4D1CAFEC6F09CB3318D5784BF2C1133D5B64308105453F`；与交接快照一致。 - 基线代码：`dev/project-dev/transcribe_media.py`，SHA-256 `98BF04135CFAA7E9ADDB8F7D5ED5B8141C4BDFCC6CABDB3EF3B757C85B39C91E` - 基线测试：`dev/project-dev/test/test_transcribe_media.py`，SHA-256 `07761E66E8499EA1206AE1FCBF93032E52742F86EED17C3428E2F24C2306F9D2` - 审核范围：模块边界、`1200 s` 核心块、双侧 `5 s` 重叠、分段中点归属、模型与语言复用、单临时块、失败清理和真实资源验收；未扩展 GUI、API、数据库、批处理、断点续跑或模型选择。 ### Findings #### F1 — BLOCKING / 代码与方案：用户中断可能留下部分正式输出 - 证据：V001 第 54 行要求正式输出提交和回滚逻辑保持不变；基线 `_commit_outputs`（`transcribe_media.py` 第 345—364 行）逐个移动四个文件，只捕获 `Exception`。`KeyboardInterrupt` 继承 `BaseException`，不会进入现有回滚分支。 - 只读诊断：在临时目录模拟第二次 `Path.replace` 前发生 `KeyboardInterrupt`，结果为 `moves_attempted=2`、`partial_formal_outputs=['x.audio.flac']`、`final_directory_exists=True`。 - 影响：违反需求第 61 行“失败不留下可误认为完成的正式输出”和第 92 行“用户中断时清理”，也与 V001 第 14、52、54 行的失败安全声明冲突。4 小时运行结束后的提交窗口虽短，但该合同是明确硬门禁。 #### F2 — BLOCKING / 测试与证据：4 小时验收口径不足以产生可复核结论 - 证据：V001 第 71—72 行只写“采样”Python/FFmpeg 工作集、GPU、块号和临时块大小，没有冻结采样器、采样周期、进程树归属、逐块峰值计算、证据文件或“前三块/最后三块”的判定公式；因此可能漏掉短生命周期 FFmpeg 子进程或把其他 GPU 进程计入本任务。 - 正确性证据缺口：V001 未明确要求按需求第 79、104、115—117 行输出全部 20 分钟边界前后各 `15 s` 抽查、`0 <= start <= end <= duration`、逐段排序/连续序号、前三块与最后三块 RAM 峰值比较，以及源视频测试前后大小、时间戳、SHA-256 三项一致。V001 第 69 行只冻结了源哈希。 - 影响：一次约 100 分钟的真实运行可能结束后仍无法证明 RAM/GPU/临时磁盘和全局时间轴合同，造成高代价重跑或错误放行。 ### Minimal required_fixes 1. 另建后继方案 V002，明确把提交阶段纳入中断安全：四文件移动过程中捕获并回滚 `KeyboardInterrupt` 等 `BaseException` 后原样重抛；设计对应单元测试，在第 1、2、3 次移动后分别注入中断并断言正式四文件均不存在、暂存目录最终清理。不得借此改动外部 CLI 或输出合同。 2. 在 V002 冻结一个外部只读资源采样与证据方案：绑定本次 Python 根 PID 及其 FFmpeg 子进程，按固定周期记录时间、块号、Python 工作集、FFmpeg 子进程工作集及合计、任务 GPU 显存、临时媒体数量与字节数，并生成逐块峰值表和汇总；明确 `max(last_3_block_ram_peaks) - max(first_3_block_ram_peaks) <= 2 GiB`（或由需求方确认的等价公式）。同时把全部边界 `±15 s`、合法时间范围、排序/序号、四文件一致性和源文件大小/时间戳/SHA-256 前后对照列为必交证据。 ### 已通过并冻结的方案合同 - 公开 CLI 和四文件名称不变；`duration <= 1200 s` 走原路径，`duration > 1200 s` 才分块。 - 每块核心 `1200 s`、两侧 `5 s` 重叠、首尾裁边、按全局分段中点归属非重叠核心区间的规则可实施。 - 单任务只加载一次 `large-v3 / CUDA / float16` 模型；显式语言全块复用，未指定语言时首块检测并复用语言与概率。 - 完整 FLAC 留在暂存目录，同时最多存在一个临时分块，块级和外层 `finally` 清理的模块边界合理。 - 不新增 CPU/模型降级、GUI、API、数据库、批处理、断点续跑或其他产品功能。 ### 审核命令与结果 - 方案哈希核验：与交接 `design_bytes`、`design_sha256` 一致。 - `python -B -m unittest discover -s dev/project-dev/test -p "test_*.py" -v`：`6 tests / OK`；仅证明现有基线测试通过，不覆盖上述两个阻断。 - 临时目录提交中断注入：稳定复现一个部分正式 FLAC；未写项目业务产物。 - 外部动作：源视频读取 `0`；FFmpeg `0`；GPU 转写 `0`；4 小时媒体生成 `0`。 ### Open questions - 无。required_fixes 均可在现有单脚本、测试和验收证据范围内完成，不需要扩展架构或产品范围。 ### 结论 - 审计状态：`HOLD` - 阻断问题数：`2` - 当前可读：V001 的有界分块、时间归属、模型/语言复用和单临时块方向成立。 - 当前不可读：不得据此开始实现，也不得把 V001 视为已通过方案。 - 复审条件：提交 V002 的路径、字节数、SHA-256，并逐项映射上述两项最小修复；复审只检查阻断闭环和已冻结合同是否回退。 ## DEV-AUDIT-PROJECT-INFO-LOCAL-MEDIA-TRANSCRIBE-LONG-VIDEO-OPT-DESIGN-REREVIEW-20260801-001 - 记录时间：`2026-08-01T03:08:38+08:00` - 审计阶段：V001 `HOLD` 后的必要方案复审；本条只复核原 `F1/F2` 闭环和已冻结合同，不是实现审核或真实媒体验收。 - 审计对象：`DEV-PROJECT-INFO-LOCAL-MEDIA-TRANSCRIBE-LONG-VIDEO-OPT-20260801-001` - 前序审计：`DEV-AUDIT-PROJECT-INFO-LOCAL-MEDIA-TRANSCRIBE-LONG-VIDEO-OPT-DESIGN-20260801-001=HOLD/2` - 请求交接：`HANDOFF-INFODEV-INFOREV-LOCAL-MEDIA-TRANSCRIBE-LONG-VIDEO-OPT-DESIGN-REREVIEW-20260801-001` - 执行方：`dev.developer.project / infodev` - 独立审核方：`dev.reviewer.project / inforev` - 复审方案：`dev-doc/project-doc/开发方案/CODE-DESIGN-PROJECT-INFO-LOCAL-MEDIA-TRANSCRIBE-LONG-VIDEO-OPT-V002.md`，`10715 bytes`，SHA-256 `BB0A7478D0225467559E9AD46730FEC73DE7824C97FE445A5E179C723AFB5473`；与复审交接快照一致。 - 未提前实现核验：`transcribe_media.py` SHA-256 仍为 `98BF04135CFAA7E9ADDB8F7D5ED5B8141C4BDFCC6CABDB3EF3B757C85B39C91E`；`test_transcribe_media.py` SHA-256 仍为 `07761E66E8499EA1206AE1FCBF93032E52742F86EED17C3428E2F24C2306F9D2`，与前序审核基线一致。 ### Findings - 无新增 finding；限定复审范围内未发现仍未闭环的阻断。 ### F1 闭环结论：PASS - V002 第 20—28 行明确把提交捕获边界扩大到 `BaseException`，先回滚本次已移动正式文件和本次创建的空目录；`KeyboardInterrupt`、`SystemExit` 等非普通异常原样重抛，普通 `Exception` 继续包装为 `MediaTranscriptionError`，且回滚失败不得静默宣告“未提交”。 - V002 第 30—40 行冻结第 1、2、3 个文件成功移动后的 `KeyboardInterrupt` 注入测试，并要求正式四文件、本次创建目录和集成暂存目录均不存在；另保留普通 `OSError` 回滚回归。 - 该合同足以指导实现修复前序“中断留下部分正式输出”问题；具体代码和测试结果留待实现审核验证。 ### F2 闭环结论：PASS - V002 第 42—72 行冻结外部只读 PowerShell 采样器、`500 ms` 周期、根 Python PID 与递归 FFmpeg 后代归属、同一采样点合计工作集、任务 PID GPU 显存、块号和临时媒体采样，并规定缺字段时 `sampling_valid=false`、不得宣告 PASS。 - 逐样本、逐块和汇总证据文件及字段已经明确；RAM 增长公式固定为 `max(last_3_block_ram_peaks) - max(first_3_block_ram_peaks) <= 2 * 1024^3`，同时保留任务 RAM、GPU、临时块数量与大小门禁。 - V002 第 74—84 行补齐全部 20 分钟边界 `±15 s`、合法时间范围、排序和连续序号、四文件一致性、短视频 `705` 段回归，以及原视频大小、创建时间、修改时间、SHA-256 前后对照；缺证据即 FAIL。 - 该证据合同足以支撑后续 19:54 与约 4 小时真实验收；实际资源数值和正确性结论留待实现后运行验证。 ### 已冻结合同回退检查 - V002 第 14 行保持：公开 CLI 和四文件名称不变；`duration <= 1200 s` 原路径；长视频 `1200 s` 核心、双侧 `5 s` 重叠、首尾裁边和中点归属。 - 保持单任务一次加载 `large-v3 / CUDA / float16`、首块语言检测后复用、完整 FLAC 加最多一个临时块，以及禁止 CPU/模型降级、GUI、API、数据库、批处理和断点续跑。 - 未发现前序已通过合同回退，也未引入超出本事项的产品或架构范围。 ### 复审命令与外部动作 - 核验 V002 字节数、SHA-256、V001 SHA-256及代码/测试基线 SHA-256；结果均与交接或前序审计一致。 - 静态逐项对照 V002 第 1—6 节、前序 `F1/F2` 和需求第 61、79、92、95—117 行。 - 未运行代码或测试；未读取源视频；FFmpeg `0`；GPU 转写 `0`；4 小时媒体生成 `0`。 ### Open questions - 无。复审通过不要求继续修改方案，也不要求增加新审批层。 ### 结论 - 审计状态：`PASS` - 阻断问题数：`0` - 原 `F1/F2`：均已在 V002 方案层闭环。 - 实现授权：允许 `dev.developer.project` 按 V002 开始最小实现、离线测试、19:54 回归和约 4 小时资源验收。 - 结论边界：本 PASS 只批准 V002 方案，不证明代码已实现、测试已通过或真实资源指标已达标；实现与验收证据完成后仍须按事项既定入口提交后续必要审核/验收。 ## DEV-AUDIT-PROJECT-INFO-LOCAL-MEDIA-TRANSCRIBE-LONG-VIDEO-OPT-WDDM-GPU-EVIDENCE-20260801-001 - 记录时间：`2026-08-01T04:16:06+08:00` - 审计阶段：V002 实现后的 WDDM GPU 资源证据口径等价性确认；本条不构成实现审核、19:54 回归验收或 4 小时验收。 - 审计对象：`DEV-PROJECT-INFO-LOCAL-MEDIA-TRANSCRIBE-LONG-VIDEO-OPT-20260801-001` - 前序方案复审：`DEV-AUDIT-PROJECT-INFO-LOCAL-MEDIA-TRANSCRIBE-LONG-VIDEO-OPT-DESIGN-REREVIEW-20260801-001=PASS` - 请求交接：`HANDOFF-INFODEV-INFOREV-LOCAL-MEDIA-TRANSCRIBE-LONG-VIDEO-OPT-WDDM-GPU-EVIDENCE-20260801-001` - 执行方：`dev.developer.project / infodev` - 独立审核方：`dev.reviewer.project / inforev` ### Findings - 无阻断 finding。Windows WDDM 下改用任务 PID 的 `GPU Process Memory(*)\Dedicated Usage` 作为显存数值来源，可与 V002 的“任务 PID 显存”证据目标等价，不属于门禁放宽。 ### 等价性依据 - V002 第 51 行要求的是根 Python 及后代 PID 的任务归属显存，不要求必须由 NVIDIA 驱动在 WDDM 下返回数值；系统全局显存仍不得替代任务归属值。 - NVIDIA 官方 `nvidia-smi` 文档明确说明 Windows WDDM 下按进程 GPU Memory Usage 不可用，因为显存由 Windows KMD 管理；因此任务 PID 可被列出但 `used_gpu_memory=[N/A]` 是该驱动模型的预期限制，不代表任务未使用显存。 - Microsoft 官方说明 WDDM 的 VidMm 负责 GPU 内存管理，任务管理器 GPU 数据直接来自 VidSch/VidMm，且覆盖 CUDA 等 API；离散 GPU 的 `Dedicated GPU memory` 对应板载 VRAM。因此同一任务 PID 的 `GPU Process Memory(*)\Dedicated Usage` 是本机 WDDM 下可归属、可量化的专用显存证据。 - 独立探针 `probe.json` 共 `12` 个样本；同一根 PID `20548` 在 `8` 个样本的 `nvidia-smi` 原始输出中出现且显存均为 `[N/A]`，Windows 专用显存计数器在 `9` 个样本中返回 `267214848..3387805696 bytes`（峰值 `3230.863 MiB`），数值随模型加载阶段上升，足以证明该本机口径可用。 ### 批准的最小采样器变更 1. 保持 `500 ms` 周期及每个采样点的根 Python PID、递归后代 PID 集不变；只筛选 `GPU Process Memory` 中实例名精确归属于该 PID 集的 `Dedicated Usage`，排除 `_Total`、`Shared Usage` 和系统全局显存。 2. 同一采样点按完整计数器实例去重后求和，再由 bytes 换算 MiB；保留实例名/计数器路径及逐 PID 数值，使多适配器或 PID 复用情形可追踪。 3. 每周期继续保存 `nvidia-smi` 对任务 PID 的原始出现状态和 `[N/A]` 状态；`nvidia-smi` 不再提供 WDDM 下的数值，但仍作为 NVIDIA GPU 任务 PID 归属旁证。 4. 若 GPU 阶段 `nvidia-smi` 从未出现根任务 PID、Windows 计数器查询/解析失败、任务 PID 实例无法归属，或整个 GPU 阶段任务专用显存始终为 `0`，必须写具体原因并令 `sampling_valid=false`。 5. V002 的任务 GPU 峰值 `< 10 * 1024 MiB` 门禁、同采样点取峰值、证据文件、RAM/临时块/正确性门禁全部保持不变。 ### 证据与外部动作 - 探针：`dev/project-dev/tmp/DEV-PROJECT-INFO-LOCAL-MEDIA-TRANSCRIBE-LONG-VIDEO-OPT-20260801-001/gpu-memory-probe/probe.json`，SHA-256 `5B9C54A9584BA48AB0E1A64CBCD9E8B78EC0E2E3B756BF134C97FDB2ADF15FC8`。 - 待修采样器：`dev/project-dev/test/monitor_transcribe_resources.ps1`，SHA-256 `BDC7F367B041182C820FEFEEC5C059EF6BE1221C46E02C33FA7DA35CA7E29262`；当前第 213—225 行仅接受数值型 `nvidia-smi` 行，会把 `[N/A]` 错记为 `0 MiB`，第 331 行也未据此判无效。 - 方案：V002 SHA-256 `BB0A7478D0225467559E9AD46730FEC73DE7824C97FE445A5E179C723AFB5473`；本确认只替换其第 51 行在 WDDM 下不可取得的数值来源，不修改其他冻结合同。 - 官方依据：Microsoft DirectX Developer Blog《GPUs in the Task Manager》；NVIDIA System Management Interface 文档的 WDDM GPU Memory Usage 限制说明。 - 本轮只读检查现有探针、方案和采样器；源视频读取 `0`，FFmpeg `0`，GPU 转写 `0`，4 小时媒体生成/运行 `0`。 ### 结论 - 审计状态：`PASS_EQUIVALENT_EVIDENCE` - 阻断问题数：`0` - 授权：允许开发员仅按上述口径修复外部采样器，先重跑 19:54 回归；资源证据有效后再生成并运行 4 小时验收。 - 边界：本结论不放行当前错误的 `0 MiB` 证据，也不预判后续 `<10 GiB`、4 小时资源门禁或实现审核结果；不得扩展产品、分块、模型或接口范围。 ## DEV-AUDIT-PROJECT-INFO-LOCAL-MEDIA-TRANSCRIBE-LONG-VIDEO-OPT-IMPLEMENTATION-EVIDENCE-20260801-001 - 记录时间：`2026-08-01T06:11:54+08:00` - 审计阶段：最终实现、离线测试、19:54 回归与唯一一次 4 小时真实资源/正确性证据审核。 - 审计对象：`DEV-PROJECT-INFO-LOCAL-MEDIA-TRANSCRIBE-LONG-VIDEO-OPT-20260801-001` - 请求交接：`HANDOFF-INFODEV-INFOREV-LOCAL-MEDIA-TRANSCRIBE-LONG-VIDEO-OPT-IMPLEMENTATION-EVIDENCE-REVIEW-20260801-001` - 前序方案：V002 必要复审=`PASS/0`；WDDM 任务 PID 专用显存等价口径=`PASS_EQUIVALENT_EVIDENCE/0`。 - 执行方：`dev.developer.project / infodev` - 独立审核方：`dev.reviewer.project / inforev` - 审核范围：只检查冻结合同、实现、离线测试、资源/正确性证据、源保护和范围；未运行媒体、FFmpeg 或 GPU 转写，未修改代码、测试或既有证据。 ### Findings #### F1 — BLOCKING / 数据与产物：两次正式证据包都缺少必交的空 `stderr.log` - 证据：权威短回归 `short-regression-wddm/evidence/` 和 4 小时 `four-hour-run/evidence/` 均存在 `command.json`、`stdout.log`、`resource_samples.csv`、`resource_block_peaks.csv`、`resource_summary.json`、`acceptance_evidence.json`，但两个目录都没有 `stderr.log`。 - 根因：冻结采样器 SHA-256 `B5F5AA582D68B8B53CCF217AF71748A0836B42DDEBCFB5E8F7FBD506DCAF8AD0` 第 96—97 行只定义日志路径，第 177—179、347—349 行仅在实际 dequeued stderr 行出现时才 `AppendAllText`；成功运行 stderr 为零行时不会创建文件。 - 合同：V002 第 59—66 行把 `stdout.log`、`stderr.log` 列为两次真实运行的固定最低证据；第 87—90 行规定采样或正确性任一必填证据缺失即 FAIL、不得推断补齐。现有退出码、资源 CSV、stdout 和产物可证明运行成功，但正式固定清单尚不完整。 - 影响边界：该问题不否定实现正确性、资源数值、源文件保护或唯一一次 4 小时运行本身；只阻断当前证据包作为完整正式交付被最终放行。 ### Minimal required_fixes（不运行媒体） 1. 仅修 `monitor_transcribe_resources.ps1`：在启动目标进程前用 UTF-8 无 BOM 预创建空 `stdout.log` 与 `stderr.log`，以后即使零行也能满足固定文件合同；不得改采样周期、PID 归属、资源公式或门禁。 2. 对两次既有成功运行各补录一个 `0 bytes` 的 `evidence/stderr.log`，SHA-256 应为 `E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855`。这是对当前“仅有 stderr 行时才创建文件”行为的等价规范化，不得改写其他冻结证据。 3. 在 `dev-doc/开发执行日志.md` 追加简短纠偏说明：列出两个补录路径、原采样器哈希、空文件哈希、补录原因、补录时间，并确认下列核心证据哈希保持不变；随后只需做 PowerShell parser 和现有离线测试，不需要也不得重跑 19:54 或 4 小时媒体。 4. 复审只核对本 F1：提交新采样器字节数/SHA-256、两个空日志 SHA-256、纠偏日志入口、parser/离线测试结果，以及核心证据哈希未变对照。 ### 已通过的实现与测试合同 - 生产入口 `transcribe_media.py`=`20996 bytes / 309166EEFE11A74472EA355CA4AF87F9432A15393B9ABE6D69F7F1054055DE35`；公开 CLI 和四文件名称不变，`duration <= 1200 s` 原路径，长视频 `1200 s` 核心/双侧 `5 s` 重叠/首尾裁边/中点归属实现与 V002 一致。 - 长路径只把单个块交给模型；模型任务内加载一次，未指定语言时首块检测后复用；块文件固定为一个并在 `finally` 删除；未引入 CPU/模型降级、GUI、API、数据库、批处理或断点续跑。 - `_commit_outputs` 捕获 `BaseException`、记录实际移动文件、先回滚再对非普通异常裸 `raise`；普通 `Exception` 保持 `MediaTranscriptionError`。第 1/2/3 次移动后中断和普通 `OSError` 路径均由测试覆盖。 - 审核员只读编译五个 Python 文件=`PASS`；PowerShell parser=`PASS / 3546 tokens`；CLI help=`PASS`；目标环境 unittest=`14/14 PASS`。测试文件 SHA-256：主测试 `87BD890436789BE2F813ADC57A37168A3C5A76C7815F2DA9B2FB04D4DE9D4512`，validator 测试 `9E04E9F819B69CD3C621BF6E98444630F400E08A1548991A94D3A37E8913A1F1`。 ### 已通过的 19:54 回归证据 - 权威路径：`dev/project-dev/tmp/DEV-PROJECT-INFO-LOCAL-MEDIA-TRANSCRIBE-LONG-VIDEO-OPT-20260801-001/short-regression-wddm/`。 - `exit=0`、`266.638 s`、`531` 样本、平均间隔 `0.500598 s`；无分块进度，证明 `1193.607125 s <= 1200 s` 走原路径。 - RAM 峰值 `3587469312 bytes`；同任务 PID WDDM 专用显存峰值 `4432.875 MiB`；GPU 原始 PID/N/A 与计数器实例归属有效。 - FLAC=`flac/16000 Hz/1 ch`；TXT/SRT/JSON=`705` 段逐项一致；四个文件 SHA-256 与此前 MVP 真实验收产物逐一相同。 - `resource_summary.json` 和 `acceptance_evidence.json` 哈希与交接一致；原视频四项指纹未变。 ### 已通过的 4 小时资源证据 - 生成媒体=`14400.014 s / 1168506449 bytes / C9369B48312E63E69B484D9D58CED46CCEA42B20EA46B331361F5DAC7B4DA033`，位于专属任务临时根。 - 唯一一次运行 `exit=0 / 3122.885 s`，小于 `6000 s`；stdout 进度严格为 `1..12` 且各一次。 - 审核员从 `6222` 行 `resource_samples.csv` 独立复算：根 PID 恒为 `8784`，elapsed 单调；`combined=python+ffmpeg` 全部一致；GPU 完整实例无重复、实例 PID 全在当点任务 PID 集内、实例 bytes 求和与 `task_gpu_memory_mib` 全部一致；`nvidia-smi` 根 PID 共出现 `6175` 个样本且均保留 `[N/A]`。 - 全局 RAM 峰值 `3344625664 <= 12884901888 bytes`；GPU 峰值 `4464.875 < 10240 MiB`；临时块峰值 `1 / 33869856 < 524288000 bytes`。 - 逐块 CSV 与原始样本的 12 组样本数和峰值逐项一致；前三块最大 RAM=`1818476544`，最后三块最大 RAM=`2007076864`，差=`188600320 <= 2147483648 bytes`。 - 交接列出的 `resource_samples.csv`、`resource_block_peaks.csv`、`resource_summary.json` 哈希均复核一致；无相邻暂存目录残留。 ### 已通过的 4 小时正确性与源保护证据 - 正式输出目录仅含四个文件；FLAC=`14399.050813 s / flac / 16000 Hz / 1 ch`，与媒体容差 `0.963187 s <= 1 s`。 - JSON=`large-v3/cuda/float16/vad_filter=true`；TXT/SRT/JSON 均为 `8732` 段，文本逐项一致，SRT 时间与 JSON 一致，序号严格 `1..8732`，时间合法并按 `(start,end,text)` 非递减，无完全重复段。 - `1200..13200 s` 共 `11` 个边界全部具有 `±15 s` 窗口，自动无完全重复/有序检查为 PASS；审核员逐项读取现有窗口，未发现整句重复、逆序或明显连续语音缺失。开发方人工记录含 reviewer/time/result。 - `acceptance_evidence.json`=`180CC1A3E52684BDB1437BD023A4601589BE802F9124A6BF162E24BEFE1DD6E2`，与交接一致。 - 审核时再次只读计算原视频：`96884891 bytes / 1647A9CCDCE0C728217C45A425B55697B2939733E506D1A4A06D5109ED61BEEE`，创建/修改时间与前置快照一致；未移动、重命名、覆盖或删除。 ### Open questions - 无。F1 的事实、根因和无媒体重跑闭环方式均已确定。 ### 结论 - 审计状态：`HOLD` - 阻断问题数：`1` - 已通过：冻结实现、F1 提交中断安全、离线测试、短回归、4 小时资源数值、正确性、源保护和范围控制。 - 未通过：固定证据清单缺少两个零行 `stderr.log`；完成上述纯证据/采样器最小修复前，不得向 `case_analysis.media_processor` 宣告最终实现与证据 PASS。 - 重跑边界：明确无需再次运行 19:54 或 4 小时媒体；不得以本 HOLD 为由生成第二份真实运行证据。 ## DEV-AUDIT-PROJECT-INFO-LOCAL-MEDIA-TRANSCRIBE-LONG-VIDEO-OPT-IMPLEMENTATION-EVIDENCE-F1-REREVIEW-20260801-001 - 记录时间：`2026-08-01T06:26:12+08:00` - 审核阶段：最终实现与真实证据审核之 F1 唯一阻断复审。 - 审核对象：`DEV-PROJECT-INFO-LOCAL-MEDIA-TRANSCRIBE-LONG-VIDEO-OPT-20260801-001` - 请求交接：`HANDOFF-INFODEV-INFOREV-LOCAL-MEDIA-TRANSCRIBE-LONG-VIDEO-OPT-IMPLEMENTATION-EVIDENCE-REREVIEW-20260801-001` - 前序审计：`DEV-AUDIT-PROJECT-INFO-LOCAL-MEDIA-TRANSCRIBE-LONG-VIDEO-OPT-IMPLEMENTATION-EVIDENCE-20260801-001=HOLD/1` - 执行方：`dev.developer.project / infodev` - 独立审核方：`dev.reviewer.project / inforev` - 复审范围：只核对空 `stdout.log`/`stderr.log` 预创建、两次既有成功运行的空 `stderr.log` 补录、纠偏日志、冻结核心证据哈希和无媒体验证；未重新审核已通过的实现、资源、正确性、源保护或范围合同。 ### Findings - 无阻断 finding。前序唯一 F1 已按批准的最小方式完整闭环，未发现合同回退或额外问题。 ### F1 闭环证据 - 采样器 `dev/project-dev/test/monitor_transcribe_resources.ps1`=`22930 bytes / 4D9912D558CDE3B51BBEBBB24013F51A9F52C1F0D99389BE1A5823F950F613C6`。第 103—104 行在目标进程启动前以 `UTF8Encoding(false)` 对 `stdout.log` 和 `stderr.log` 执行空 `WriteAllText`；仅补齐零行日志的固定产物，不改变 `500 ms` 周期、PID 归属、WDDM 显存口径、资源公式或门禁。 - 短回归 `short-regression-wddm/evidence/stderr.log`=`0 bytes / E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855`；4 小时运行 `four-hour-run/evidence/stderr.log`=`0 bytes / E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855`。两文件均为叶文件，修改时间为 `2026-08-01T06:19:02+08:00`，符合成功运行零 stderr 行的等价规范化。 - 纠偏记录 `DEV-LOG-PROJECT-INFO-LOCAL-MEDIA-TRANSCRIBE-LONG-VIDEO-OPT-STDERR-EVIDENCE-REPAIR-20260801-001` 已写入 `dev-doc/开发执行日志.md`；该日志=`64409 bytes / AE13F53E96F5194B2C8217D3A6006DA63E438088DB7365E37B5B5C407240EA1A`，记录前后采样器哈希、两条补录路径、空文件哈希、补录时间与原因、无媒体重跑及核心证据未变声明。 - 实现与测试基线未变：`transcribe_media.py`=`20996 bytes / 309166EEFE11A74472EA355CA4AF87F9432A15393B9ABE6D69F7F1054055DE35`；主测试=`87BD890436789BE2F813ADC57A37168A3C5A76C7815F2DA9B2FB04D4DE9D4512`；验收器=`546082ED5CC387B9394956C5C0704F78AD325BA0EEA8BAC67CE36539834C2C29`；验收器测试=`9E04E9F819B69CD3C621BF6E98444630F400E08A1548991A94D3A37E8913A1F1`。 ### 冻结核心证据未变 - 短回归 `resource_summary.json`=`4B7D8E068DE3B688C22659942973E63F2DA804779074A06764588157C366B73F`；`acceptance_evidence.json`=`AD864182A094985366AB444901857B6AC3BA601882C5B69329107CBF715D8938`。 - 4 小时 `resource_samples.csv`=`0EAD06CBA8AAD73AA24BE14F086FB3054C0612F338DDE516961D0678065C281F`；`resource_block_peaks.csv`=`0D8F33C15FDE9E9EFB3FF54888C3C1C0068E07FC1ADFA18213F664F7ADD2EE6B`；`resource_summary.json`=`73DC90C30991730CFFE868153B5007B907C9DE39CE3F10720EAEB77E92568534`；`acceptance_evidence.json`=`180CC1A3E52684BDB1437BD023A4601589BE802F9124A6BF162E24BEFE1DD6E2`。 ### 独立验证与外部动作 - PowerShell parser=`PASS`；目标环境 `D:/Anaconda/envs/project-info-media-transcribe/python.exe -B -m unittest discover -s test -p test_*.py -v`=`14/14 PASS`。 - 本复审只读计算文件大小与 SHA-256，并执行解析器和全模拟离线测试；媒体生成=`0`、媒体读取/转写=`0`、FFmpeg=`0`、GPU 转写=`0`。 ### Open questions - 无。 ### 结论 - 审计状态：`PASS` - 阻断问题数：`0` - F1 状态：`CLOSED`。前序实现、短回归、唯一一次 4 小时资源/正确性证据、源保护与范围控制的已通过结论继续有效。 - 放行：本事项可交 `case_analysis.media_processor` 做最终验收；无需且不得为本 F1 再次运行 19:54 或 4 小时媒体。 ## DEV-AUDIT-PROJECT-INFO-MEETING-RECORDING-SLIDE-EXTRACTION-MVP-DESIGN-20260801-001 - 记录时间：`2026-08-01T14:08:46+08:00` - 审核阶段：重型最小单工具 V001 编码方案审核。 - 审核对象：`DEV-PROJECT-INFO-MEETING-RECORDING-SLIDE-EXTRACTION-MVP-20260801-001` - 原始消息：`msg_20260801135527958_2db4804b`；`correlation_id=msg_20260801135527958_2db4804b`。 - 恢复唤醒：`HANDOFF-INFODEV-INFOREV-MEETING-RECORDING-SLIDE-EXTRACTION-MVP-DESIGN-MBX-INBOX-WAKE-20260801-001`，仅用于消费既有 inbox 消息，不构成第二次送审。 - 执行方：`dev.developer.project / infodev` - 独立审核方：`dev.reviewer.project / inforev` - 需求：`ai-media-processor/draft/会议录屏PPT页面提取方案_v0.1.md`=`7781 bytes / 1B5797C1408A172328D488EE1C66E92893053C892929437F7DB85239F404B2E7`。 - 方案：`dev-doc/project-doc/开发方案/CODE-DESIGN-PROJECT-INFO-MEETING-RECORDING-SLIDE-EXTRACTION-MVP-V001.md`=`7335 bytes / 67B04259A13657577EF9AF990461C062D00E56EFC29DB374A848E1C4B006C4DD`。 - 当前实现动作：脚本、测试和用法均不存在；真实业务视频读取=`0`，FFmpeg=`0`，合成视频=`0`。 ### Findings #### F1 — BLOCKING / 算法合同：相邻帧稳定判定会累积漂移，动画与全局去重的判定优先级又可能吞掉完整页替换 - V001 第 37 行只要求相邻样本差异低于阈值。相似关系不具传递性；渐变、慢速翻页或逐步动画可让每对相邻帧都“小变化”，但首尾已经完全不同，当前合同会把整段错误视为稳定段，并可能选出过渡中间帧。这不能满足需求第 84 行“不把翻页过渡、动画中间状态当作页面”。 - V001 第 42 行规定候选与“任一已确认页面”近似即跳过，第 43 行才规定与最近逻辑页比较并用更完整候选替换。`A初始 -> A完整` 恰可能同时满足近似重复和同页动画；如果先执行全局去重，`A完整` 会被跳过，直接违反需求第 107 行及 V001 自己第 68、75—77 行的预期。 - `内容分数` 仅被引用，未冻结其计算语义、比较方向和同分处理，开发者无法从方案唯一确定何时“更完整”、何时保留旧页。 最小 required fixes： 1. 稳定段除相邻差异外必须绑定段锚点或等价累计差异约束；候选窗口内样本既要相邻稳定，也要相对稳定段基准未漂移。增加“多帧缓慢渐变/慢速翻页不产出中间候选”的离线测试。 2. 冻结分类顺序：先对最近逻辑页判定同页动画并决定替换/保留，再对其余历史页做全局返回去重；或给出能证明等价且不会让同一候选同时命中冲突动作的互斥规则。 3. 定义不依赖 OCR 的 `content_score` 计算、容差和同分处理；至少保证内容明显增加时采用后一个稳定时间、明显减少时不覆盖、相同完整状态返回时不重复。保留现有 `A初始 -> A完整`、`A -> B -> A` 测试并补交叉阈值用例。 #### F2 — BLOCKING / 流程与恢复：4 小时 FFmpeg rawvideo 管道和 BaseException 下的子进程生命周期未形成可安全实现的合同 - V001 第 35—36 行只有“固定大小帧读取”的目标，没有规定 pipe 短读拼帧、干净 EOF、半帧 EOF、FFmpeg 非零退出和 stderr 消费方式。普通 pipe `read(frame_bytes)` 不保证一次返回完整帧；若按单次 read 解释帧，会错位，若 stderr 使用未消费的 PIPE，长时 FFmpeg 还可能阻塞。 - rawvideo 不携带时间戳，V001 第 38、50 行未冻结“输出样本序号如何映射回原视频时间”以及非零起始 PTS/VFR 时的归一规则，无法保证第二阶段提取的是第一阶段选中的原帧。 - V001 第 58 行只保证 `try/finally` 删除暂存目录，没有要求在 `KeyboardInterrupt`、读取异常或提取异常时先关闭管道、终止并等待 FFmpeg。Windows 下遗留子进程可能继续占用源或暂存文件，使清理失败；这不足以证明“用户中断不留正式目录/暂存”。 最小 required fixes： 1. 在单脚本内冻结一个统一的受管 FFmpeg 调用边界：`read_exact(frame_bytes)` 循环拼满一帧；零字节且无残片才是正常 EOF；半帧 EOF、非零退出或解码错误必须失败；stderr 采用不会填满管道的可追踪方案并检查退出码。 2. 冻结 PTS 归一和时间映射，例如扫描端显式归零时间基并令第 `n` 个 1 fps 输出映射到确定的源相对秒数；第二阶段使用精确定位方式提取该时间的帧。不得从无时间戳 rawvideo 隐式猜测。 3. 任一 `BaseException` 路径先关闭 stdin/stdout/stderr，终止子进程、限时等待、必要时 kill 并再次 wait，再清理暂存，最后原样重抛非普通异常；普通运行错误保持明确工具错误。 4. 增加不运行真实视频的假进程/桩测试：多次短读组成一帧、半帧 EOF、非零退出、stderr 较多、扫描/原图提取期间 `KeyboardInterrupt`；断言无孤儿进程、无暂存、无正式目录且原异常语义保留。 #### F3 — BLOCKING / 测试与证据：当前 PDF 门禁既不能证明页内容/顺序，也不能证明多页生成不累计全分辨率页面 - V001 第 52、69、78 行仅用 `pdfinfo` 证明 PDF 可打开和页数。`pdfinfo` 不能证明第 1 页对应 `slide_001.png`、第 2 页对应 `slide_002.png`，也不能发现空白页、错图或倒序页，故无法证明需求第 70 行“PDF 页面顺序与 PNG 编号一致”。 - V001 第 84—85 行的长迭代器测试只覆盖扫描帧不累计；两页 CLI 的 RSS 基线不能证明 PDF 在页数较多时只保留一张原分辨率图像。第 51 行虽声明流式写入，但没有相应可复验门禁。 最小 required fixes： 1. 合成视频验收中把 PDF 各页渲染或提取为图像，逐页与对应 PNG 的确定性颜色块/像素或允许容差的感知特征比对，明确证明 PDF 内容和顺序均为 `A完整,B`；继续保留页数与可打开检查。 2. 冻结 PDF writer 的内存合同：压缩后的当前页立即写入暂存 PDF，只允许保留页对象编号/偏移等小型元数据，不保存全页像素或全部压缩图像 payload 列表。 3. 增加多页离线测试，以受控图片 opener/writer 计数或等价证据证明任一时刻最多一个解码后的全分辨率页面处于存活状态；不要求真实业务视频或复杂性能矩阵。 ### 已通过且后续默认冻结的方案边界 - 单视频 CLI、默认/显式输出目录、Pillow+NumPy+FFmpeg/FFprobe、无 GPU 依赖及中文路径方向与需求一致；未扩展 PPTX、OCR、人像处理、裁剪、转写、批处理、GUI、API、数据库、Skill 或阈值 CLI。 - 扫描阶段不建立全部采样帧列表、只保留当前/前一帧、稳定段摘要及每个确认输出页的小尺寸特征，方向满足“内存不随采样帧累计”；确认页描述符按最终输出页数增长属于必要状态。 - 正式目录同级唯一暂存、既有输出/符号链接在 FFmpeg 前拒绝、完整后一次目录重命名、并发冲突失败以及源视频只读合同在方案层可接受；F2 只要求补齐子进程先回收再清理的顺序。 - 首次真实 PPT 录屏的启发式效果交由 `case_analysis.media_processor` 后续普通验收合理；本次不要求也不允许提前读取真实业务视频。 ### Open questions - 无。三个阻断均可在 V002 方案和离线测试合同中闭环，不需要改变需求、增加依赖、拆模块或扩大产品范围。 ### 结论 - 审计状态：`HOLD` - 阻断问题数：`3` - 当前不得开始实现。开发方应只提交覆盖 F1—F3 的 V002；复审只核对上述三项及已冻结边界是否回退，一次完成后即可决定是否放行实现。 ## DEV-AUDIT-PROJECT-INFO-MEETING-RECORDING-SLIDE-EXTRACTION-MVP-DESIGN-REREVIEW-20260801-001 - 记录时间：`2026-08-01T15:07:08+08:00` - 审核阶段：V001 `HOLD/3` 后的 V002 限定方案复审。 - 审核对象：`DEV-PROJECT-INFO-MEETING-RECORDING-SLIDE-EXTRACTION-MVP-20260801-001` - 原始消息：`msg_20260801150116832_0f46183c`；`correlation_id=msg_20260801150116832_0f46183c`。 - 恢复唤醒：`HANDOFF-INFODEV-INFOREV-MEETING-RECORDING-SLIDE-EXTRACTION-MVP-V002-MBX-INBOX-WAKE-20260801-001`，仅用于消费既有 V002 inbox 消息，不构成第二次复审请求。 - 前序审计：`DEV-AUDIT-PROJECT-INFO-MEETING-RECORDING-SLIDE-EXTRACTION-MVP-DESIGN-20260801-001=HOLD/3`。 - 执行方：`dev.developer.project / infodev` - 独立审核方：`dev.reviewer.project / inforev` - V002：`dev-doc/project-doc/开发方案/CODE-DESIGN-PROJECT-INFO-MEETING-RECORDING-SLIDE-EXTRACTION-MVP-V002.md`=`11772 bytes / F28F50AD07954B940684E6FA8E0ADB4EDD1EB6F9FA82DE74969C1BDC5B367F28`。 - 需求及 V001 未变：需求=`1B5797C1408A172328D488EE1C66E92893053C892929437F7DB85239F404B2E7`；V001=`67B04259A13657577EF9AF990461C062D00E56EFC29DB374A848E1C4B006C4DD`。 - 当前实现动作：脚本、测试和用法仍不存在；真实业务视频读取=`0`，FFmpeg=`0`，合成视频=`0`。 ### Findings - 无剩余阻断 finding。V002 只闭环前序 F1—F3，未发现已冻结合同回退或新增范围。 ### F1 闭环：PASS - V002 第 21—30 行为稳定段增加不可变 `segment_anchor`，同时要求相邻差异和相对锚点差异通过；至少 3 个样本才产出，锚点漂移中间帧不得入选，并冻结 `A稳定 -> 六帧渐变 -> B稳定` 只输出 `A,B` 的反例，闭环相邻相似的累计漂移风险。 - 第 34—44 行定义不依赖 OCR 的 `edge_density`、`contrast` 和 `content_score`，冻结增加、减少与容差内同分三种更新方向。 - 第 48—54 行把候选分类固定为“最近逻辑页动画 → 除最近页外历史返回去重 → 新页”，并同时比较最近页的可更新状态和不可变逻辑锚点；三个动作互斥，交叉阈值测试明确禁止全局去重吞掉完整页替换。 ### F2 闭环：PASS - V002 第 60—64 行冻结同源受管子进程边界：参数数组、`shell=False`、长时 stderr 写暂存文件、正常路径 wait/退出码检查，以及 `BaseException` 时关闭管道、terminate、限时 wait、kill、再次 wait、关闭句柄、清暂存、非普通异常原样重抛的顺序。 - 第 68—74 行完整定义 `read_exact` 的短读拼帧、干净 EOF、半帧 EOF 和非零退出行为，不再把单次短读误当完整帧，也不存在未消费 stderr PIPE 填满风险。 - 第 78—80 行以 `setpts=PTS-STARTPTS,fps=fps=1:start_time=0` 冻结 `n -> n.000 s` 映射，并规定输入级准确 seek、第一视频流映射、PNG 尺寸复核及 VFR/非零 PTS 合成测试。 - 第 84—87 行补齐短读、半帧、大 stderr、非零退出及扫描/截图阶段 `KeyboardInterrupt` 桩测试，验证无孤儿进程、无暂存/正式目录并保留异常语义。 ### F3 闭环：PASS - V002 第 93—100 行冻结逐页 PDF writer：只保留路径、对象编号和 xref 偏移；当前页 raw RGB 与压缩 payload 立即写入暂存 PDF并在下一页前释放，禁止任何全页图像或 payload 列表。 - 第 104—110 行规定按 Page Kids 顺序解压每页 `/DeviceRGB / 8 bits / FlateDecode` 图像流，与对应 PNG 的 RGB SHA-256、宽高和 `A完整/B` 标记逐页一致；`pdfinfo` 仅作为可打开/页数的并列检查，因此能够证明非空白、内容和顺序。 - 第 114—120 行以至少 20 页的可注入 opener 计数器证明 `max_active_decoded_images == 1`、上一页退出后才进入下一页，并再次逐页核对 RGB 哈希；不引入真实视频或复杂 RSS 矩阵。 ### 冻结边界回退检查：PASS - 单视频、默认/显式输出、1 fps、原分辨率 PNG、一个 PDF、Pillow+NumPy+FFmpeg/FFprobe、无 GPU、中文路径、同级唯一暂存和一次目录重命名均保留。 - PPTX、OCR、人像处理、裁剪/遮挡、会议界面移除、JSON、转写、批处理、GUI、API、数据库、Skill、阈值 CLI 仍全部排除；仍限一个脚本、一个测试文件和一页用法。 - 扫描不累计全部帧，PDF 不累计全部页面；正式输出预拒绝覆盖、并发冲突失败和源只读合同均未回退。 ### 已授权真实样本顺序：PASS - 项目消息账本确认 `msg_20260801144622354_1c75b06b` 由 `case_analysis.media_processor` 发给 `dev.developer.project`，授权只读使用 `G:\熊猫财经\20260729192357-2026小郑掘金产业链之算力行业付费直播-视频-1-共享屏幕.mp4`，已知 `H.264 / 2560x1440 / 12866.880 s / 1268392019 bytes`。 - V002 第 132—138 行正确保持顺序：方案 PASS 且离线/合成稳定后，先固定源四项指纹；仅在专属任务临时根可选生成一个短片副本；短片暴露具体问题时只做单一最小修复；稳定后完整视频只运行一次；输出和外部只读资源采样证据仍只写专属临时根；结束后再次逐项核对源指纹并保留产物供请求方只读复核。 - 该追加只改变实现后的验收输入与顺序，不改变产品 CLI、算法输出、阈值接口或正式产物合同；实现审核与最终请求方验收的既有角色分离仍有效。 ### 复审命令与外部动作 - 只读核对 V002/V001/需求字节数与 SHA-256、前序审计、项目账本、消息事件和实现文件不存在状态；未执行代码、测试、FFmpeg、合成视频或真实视频读取。 - 当前治理文档哈希与前序审核一致；复审未修改方案、实现、测试、执行日志或其他被审产物。 ### Open questions - 无。阈值真实效果是实现与已授权真实样本验收项，不构成继续阻断方案的理由。 ### 结论 - 审计状态：`PASS` - 阻断问题数：`0` - 前序 `F1/F2/F3`：全部在 V002 方案层闭环。 - 实现授权：允许 `dev.developer.project` 严格按 V002 开始单脚本、测试和用法实现，并按既定离线 → 合成 → 可选短片 → 完整视频一次的顺序收集证据；不得扩大产品范围。 - 结论边界：本 PASS 仅批准方案，不证明代码已实现、测试已通过或真实样本结果已达标；实现与证据完成后仍须按既定入口提交必要实现审核，PASS 后再交 `case_analysis.media_processor` 最终功能验收。 ## DEV-AUDIT-PROJECT-INFO-MEETING-RECORDING-SLIDE-EXTRACTION-MVP-IMPLEMENTATION-20260801-001 - 记录时间：`2026-08-01T16:28:44+08:00` - 审核阶段：V002 实现、离线测试与合成证据的必要独立审核。 - 审核对象：`DEV-PROJECT-INFO-MEETING-RECORDING-SLIDE-EXTRACTION-MVP-20260801-001` - 原始消息：`msg_20260801153518062_c0082f2e`；`correlation_id=msg_20260801153518062_c0082f2e`。 - 本轮提示只用于唤醒既有 MB-X inbox 消息，不构成第二次送审。 - 前序方案审计：`DEV-AUDIT-PROJECT-INFO-MEETING-RECORDING-SLIDE-EXTRACTION-MVP-DESIGN-REREVIEW-20260801-001=PASS/0`。 - 执行方：`dev.developer.project / infodev` - 独立审核方：`dev.reviewer.project / inforev` - V002：`dev-doc/project-doc/开发方案/CODE-DESIGN-PROJECT-INFO-MEETING-RECORDING-SLIDE-EXTRACTION-MVP-V002.md`=`11772 bytes / F28F50AD07954B940684E6FA8E0ADB4EDD1EB6F9FA82DE74969C1BDC5B367F28`。 - 实现：`dev/project-dev/extract_ppt_slides.py`=`24973 bytes / 9AC4A9D05B3779374104A2C5DD11A9B29922B645A4098F2DDE73D85E21371EBA`。 - 测试：`dev/project-dev/test/test_extract_ppt_slides.py`=`20201 bytes / F5040F9AC53195EE81184030608BA6D12F4FD6A0C3EC50B95815A42865F782B7`。 - 用法：`dev-doc/project-doc/会议录屏PPT页面提取工具.md`=`3235 bytes / 9C7896A6BEC446343A0DF2FFC5EBD46E83D14C3ECB27A4D42B3CE40B95FB8C83`。 ### Findings #### F1 — BLOCKING / 代码与正式产物合同：实现把已冻结的 `pages/` 与视频名 PDF 布局改成了输出根目录文件 - V001 第 13、56 行已冻结正式目录为 `pages/slide_001.png...` 与 `<视频名>.slides.pdf`，V002 第 13—15 行明确这些已通过边界继续冻结且不得增加或改写业务产物合同。 - 实现第 531 行把 PNG 直接写为暂存根的 `slide_*.png`，第 669 行把 PDF 固定写为 `slides.pdf`；用法文档第 27 行及合成产物也把这一回退固化为公开行为。当前合成证据实际为 `合成验收.slides/slide_001.png`、`slide_002.png`、`slides.pdf`，不是获批接口。 - 这是正式消费者可见的输出路径和文件名错误，不是命名偏好；即使 PNG/PDF 内容正确，也不能按错误接口放行真实验收。 最小 required fixes： 1. 仅调整暂存内布局：创建 `pages/` 并把连续编号 PNG 写入其中；PDF 写为 `<源视频 stem>.slides.pdf`，成功后仍以一次同级目录重命名提交，不改变算法或 CLI 参数。 2. 同步测试和一页用法；用合成视频重新证明正式目录只含获批的 `pages/` 与视频名 PDF、PNG 连续且 PDF 逐页 RGB/顺序不变。无需读取、截取或运行真实业务视频。 #### F2 — BLOCKING / 代码与路径安全：先 `resolve()` 再检查使“输出符号链接预拒绝”在断链场景失效 - V001 第 27 行及首次审计已通过边界要求：输出存在或为符号链接时必须在任何 FFmpeg 动作前拒绝；输入必须是普通文件。该边界在 V002 第 13 行继续冻结。 - `_validate_paths()` 第 639、643 行先对输入/输出执行 `resolve(strict=False)`，第 647 行才对解析后的目标调用 `lexists()`。这样会丢失调用者提供路径本身的链接身份：输入文件链接会被当作目标普通文件接受；输出若是指向尚不存在目标的断链符号链接，解析后的目标 `lexists=False`，随后可能在链接目标位置创建暂存并提交，而不是拒绝该链接路径。 - 当前 `test_existing_output_is_rejected_before_external_process` 仅覆盖已存在目录，没有覆盖存活/断链输出链接，也没有证明输入普通文件边界。 最小 required fixes： 1. 在跟随链接或规范化到目标之前，对调用者给出的绝对词法路径做 `lstat/is_symlink/lexists` 等价预检；拒绝输入链接/非普通文件以及任何已存在、存活或断链的输出链接，再进入 FFprobe/FFmpeg。父目录合法性和同级暂存规则保持不变。 2. 增加不依赖真实媒体的预检测试，至少覆盖已存在目录/文件、存活输出链接、断链输出链接和输入链接；环境不能创建 Windows 符号链接时可用受控桩证明分支，但不得以权限不足跳过合同。 #### F3 — BLOCKING / 代码与测试：失败包络未完整覆盖，V002 要求的两个阶段中断证据被拆散后没有证明主流程清理 - V002 第 60—64、82—87 行要求两个 FFmpeg helper 的整个受管边界都遵守 `BaseException` 清理/普通异常包装，并要求在扫描阶段和原图提取阶段分别注入 `KeyboardInterrupt`，同时证明子进程回收、暂存/正式目录不存在和原异常类型不变。 - `_run_file_command()` 第 137 行与 `scan_video()` 第 443 行在各自 `try` 之前打开 stderr 文件；打开失败不会进入该 helper 的普通异常包装。`extract_slides()` 第 657 行又在清理 `try` 之前创建暂存目录；第 676 行的并发提交 `OSError` 清理暂存后仍作为裸系统异常越过只捕获 `SlideExtractionError` 的 CLI。上述路径没有实现方案所称的统一明确工具错误/清理包络。 - 两个 `test_keyboard_interrupt_reaps_*` 只分别调用底层 helper，未断言正式目录和主流程暂存；`test_baseexception_removes_staging_and_leaves_no_formal_output` 又只在 `probe_video` 注入中断、没有子进程。三项测试拼在一起仍没有按 V002 门禁证明“扫描中断”和“原图提取中断”各自贯穿完整主流程后同时满足回收与目录清理。 最小 required fixes： 1. 把 stderr 文件打开、子进程启动/回收和句柄关闭纳入同一受管异常边界；把暂存创建与最终目录提交纳入可清理、可定位的主流程错误边界。普通文件/并发提交错误应转为含阶段的 `SlideExtractionError` 或等价用户可定位错误；`KeyboardInterrupt/SystemExit` 仍原样重抛，且清理错误不得替换原非普通异常。 2. 增加两个完整主流程离线测试：分别在扫描和原图提取期间注入 `KeyboardInterrupt`，记录 `close -> terminate -> timed wait -> 必要时 kill -> wait`，并在同一用例断言子进程已退出、暂存/正式目录不存在、原异常类型不变；再覆盖 stderr 文件打开失败和提交冲突的明确错误/清理。无需任何真实媒体重跑。 ### 已通过且冻结的实现部分 - F1 算法主体已按 V002 实现：不可变稳定段锚点、相邻/锚点双约束、`anchor_drift` 反例、`edge_density + 0.25 * contrast` 内容分数，以及最近页动画 → 历史去重 → 新页的互斥顺序均有对应测试。 - F2 的 `read_exact` 短读/干净 EOF/半帧 EOF、stderr 文件重定向、正常 wait/退出码、`setpts=PTS-STARTPTS,fps=fps=1:start_time=0`、输入级准确 `-ss` 和 VFR/非零 PTS 合成映射通过复验；本次 F3 只阻断尚未纳入完整失败包络与主流程门禁的路径。 - F3 PDF 主体已按 Page Kids 顺序写 `/DeviceRGB / 8 bits / FlateDecode` 图像流，逐页 RGB 与 PNG 一致；20 页 opener 的 `max_active=1` 通过。PPTX/OCR/人像/裁剪/JSON/GUI/API/数据库/批处理/转写/Skill 等排除项未回退。 ### 独立验证与证据 - Python=`3.12.7`，Pillow=`10.4.0`，NumPy=`1.26.4`；FFmpeg/FFprobe=`2024-12-19`。源码/测试 `compile()`=`PASS`，CLI help=`PASS`。 - `python -B -W error::ResourceWarning -m unittest dev/project-dev/test/test_extract_ppt_slides.py -v`=`15/15 PASS`；`python -B -W error::ResourceWarning -m unittest discover -s dev/project-dev/test -p "test_*.py" -v`=`34/34 PASS`。 - 既有合成源只读复核：`3875 bytes / 41BBCE50D3E5B28D82239A9061A27F4D8301ADD112C4D1154F05730542E5E06A`，FFprobe=`15.000000 s / 640x360`；PNG=`2`，PDF 解压页=`2`，两页 RGB SHA-256 均与对应 PNG 一致，尺寸均为 `640x360`。既有 PDF 渲染页目视为 `A完整/B`，无空白、错序或裁切。 - Windows 当前会话无创建符号链接权限（独立动态探针返回 `WinError 1314`）；F2 依据已冻结合同、`Path.resolve(strict=False)`/`lexists` 的确定语义和缺失测试作静态判定，不把环境权限不足当作通过证据。 - 本轮只运行离线桩、临时 VFR/合成视频测试并只读检查既有合成证据；真实业务视频读取=`0`、截取=`0`、完整运行=`0`，未访问其路径或元数据。 ### Open questions - 无。三项阻断均可由单脚本、单测试文件、一页用法及合成证据的最小修复闭环，不需要修改 V002、扩展产品范围或运行真实业务视频。 ### 结论 - 审计状态：`HOLD` - 阻断问题数：`3` - 当前不得进入可选短片或完整真实视频验收。开发方只需完成 F1—F3 的最小代码/测试/用法修复并重跑离线与合成证据，再按原消息链提交限定复审；已通过的算法、时间映射和 PDF 内容合同不得回退。 ## DEV-AUDIT-PROJECT-INFO-MEETING-RECORDING-SLIDE-EXTRACTION-MVP-IMPLEMENTATION-REREVIEW-20260801-001 - 记录时间：`2026-08-01T17:33:14+08:00` - 审核阶段：首次实现 `HOLD/3` 后仅复审 F1—F3 的限定实现复审。 - 审核对象：`DEV-PROJECT-INFO-MEETING-RECORDING-SLIDE-EXTRACTION-MVP-20260801-001` - 原始消息：`msg_20260801172720145_4e8aa710`；`correlation_id=msg_20260801172720145_4e8aa710`。 - 本轮提示只用于唤醒既有 MB-X inbox 消息，不构成第二次复审请求。 - 前序实现审计：`DEV-AUDIT-PROJECT-INFO-MEETING-RECORDING-SLIDE-EXTRACTION-MVP-IMPLEMENTATION-20260801-001=HOLD/3`；前序回执=`msg_20260801163131253_03ae58a1`。 - 执行方：`dev.developer.project / infodev` - 独立审核方：`dev.reviewer.project / inforev` - 实现：`dev/project-dev/extract_ppt_slides.py`=`26791 bytes / 96348DF5B9C88B79A4E401F160E76EC444A1D2DF302AE1A8A868F8DCD3BE3662`。 - 测试：`dev/project-dev/test/test_extract_ppt_slides.py`=`25590 bytes / 9D78AD3850D7864E46C6A10C1364AD463090EBBED224FB2BE57BD964A66DD162`。 - 用法：`dev-doc/project-doc/会议录屏PPT页面提取工具.md`=`3372 bytes / 8FA1335973D5F84070DF5706C53C8CDDED8F92CC97DADEECA96B0B64EE7F3052`。 ### Findings #### F3-R1 — BLOCKING / 代码与测试：stderr 句柄关闭失败仍会替换原 `KeyboardInterrupt/SystemExit` - 前序 F3 required fix 明确要求“`KeyboardInterrupt/SystemExit` 原样重抛且清理错误不得替换原非普通异常”。当前 `_attempt_reap()` 已保护子进程回收错误，但 `_run_file_command()` 第 173—175 行和 `scan_video()` 第 506—508 行仍在 `finally` 中直接执行 `stderr_handle.close()`，没有保存/合并关闭错误的保护。 - Python 的 `finally` 异常会覆盖正在传播的异常。独立桩让目标进程首次 `wait()` 抛 `KeyboardInterrupt`、回收成功、随后 stderr handle 的 `close()` 抛 `OSError("stderr close denied")`，实际观察为 `observed_exception_type=OSError`，原中断类型被替换。这是前序同一 F3 的未闭环分支，不是新增审核范围。 - 当前 `test_cleanup_error_does_not_replace_keyboard_interrupt` 只让 `terminate()` 抛清理错误，未让 stderr 关闭失败；20/20 因而没有覆盖该确定性反例。相同问题同时存在于文件输出 helper 与扫描 helper。 最小 required fixes： 1. 仅把两个 helper 的 stderr 关闭纳入与 `_attempt_reap` 等价的受保护清理：原异常为 `KeyboardInterrupt/SystemExit` 时，关闭失败不得替换原类型；原异常为普通异常时可附加有界清理错误；正常路径关闭失败必须转为含当前阶段的 `SlideExtractionError` 或等价明确工具错误。 2. 增加不使用媒体的关闭失败桩测试，至少证明文件输出 helper 和扫描 helper 在原 `KeyboardInterrupt` 下均保留原类型，并证明正常/普通失败路径的关闭错误不会以无阶段裸 `OSError` 泄漏。无需改 F1/F2、算法、PDF writer、CLI 或用法，无需重跑合成/真实媒体。 ### F1 闭环：PASS - 正式输出已恢复为 `pages/slide_001.png...` 与 `.slides.pdf`；`extract_original_pages()` 在暂存根创建 `pages/`，PDF 使用源视频 stem 命名，完整后仍只执行一次同级目录 `rename`。 - 新合成产物根只含 `pages/` 和 `合成会议录屏.slides.pdf`；2 张连续 PNG 与 2 个 PDF Page Kids 的 RGB SHA-256、顺序和 `640x360` 尺寸逐页一致。F1 不再阻断。 ### F2 闭环：PASS - `_absolute_lexical()` 使用 `abspath` 形成不跟随链接的绝对词法路径；输入先拒绝 `is_symlink`/非普通文件，输出在解析目标前以 `lexists` 拒绝已存在文件、目录及存活/断链链接，均发生在任何 `Popen` 前。 - 单测覆盖已存在文件/目录、存活/断链输出链接受控桩和输入链接，均断言外部进程未启动。F2 不再阻断。 ### F3 已闭环部分 - stderr 打开已移入 helper `try`；子进程回收普通错误不再替换原中断；暂存 `mkdir`、提交竞争和阶段错误已进入主流程包络。 - 扫描 read 与原图提取 wait 的两个完整 `extract_slides()` 中断用例均证明子进程 `close/terminate/wait`、无暂存/正式目录及原 `KeyboardInterrupt`；提交冲突与 stderr 打开失败均有明确错误测试。仅 `F3-R1` 所述句柄关闭失败分支仍未闭环。 ### 独立验证与外部动作 - `compile()`=`PASS`；CLI help=`PASS`。 - `python -B -W error::ResourceWarning -m unittest dev/project-dev/test/test_extract_ppt_slides.py -v`=`20/20 PASS`；`python -B -W error::ResourceWarning -m unittest discover -s dev/project-dev/test -p "test_*.py" -v`=`39/39 PASS`。 - 新合成证据只读复核：源=`3875 bytes / 41BBCE50D3E5B28D82239A9061A27F4D8301ADD112C4D1154F05730542E5E06A`，FFprobe=`15.000000 s / 640x360`；PNG=`1900/2290 bytes`，PDF=`4328 bytes / 5E6F5BFC5432045728967EF2A3B31C16CE9E4F0418891395C4C6B77013554F88`，根布局、2 页尺寸与逐页 RGB 均 PASS。 - 独立关闭失败反例只使用 Python 桩对象和 mock，无文件或媒体输入。真实业务视频读取=`0`、截取=`0`、完整运行=`0`，未访问其路径或元数据。 ### Open questions - 无。唯一剩余阻断可由极小 helper 清理修复和离线桩测试闭环，不需要修改方案、产品合同或证据顺序。 ### 结论 - 审计状态：`HOLD` - 剩余阻断问题数：`1` - F1=`CLOSED`；F2=`CLOSED`；F3=`PARTIAL / F3-R1 OPEN`。 - 当前仍不得进入可选短片或完整真实视频验收。开发方只需修复 `F3-R1` 并提交 F3-R1-only 限定复审；F1/F2、算法、时间映射、PDF 内容和排除项不得再改，且无需重跑合成或真实媒体。 ## DEV-AUDIT-PROJECT-INFO-MEETING-RECORDING-SLIDE-EXTRACTION-MVP-IMPLEMENTATION-F3-R1-REREVIEW-20260801-001 - 记录时间：`2026-08-01T18:23:01+08:00` - 审核阶段：前序 `HOLD/1` 后的 F3-R1-only 限定实现复审。 - 审核对象：`DEV-PROJECT-INFO-MEETING-RECORDING-SLIDE-EXTRACTION-MVP-20260801-001` - 原始消息：`msg_20260801180914484_3f58002d`；`correlation_id=msg_20260801180914484_3f58002d`。 - 本轮提示只用于唤醒既有 MB-X inbox 消息，不构成第二次复审请求。 - 前序审计：`DEV-AUDIT-PROJECT-INFO-MEETING-RECORDING-SLIDE-EXTRACTION-MVP-IMPLEMENTATION-REREVIEW-20260801-001=HOLD/1`；前序回执=`msg_20260801174041344_38dc2a9e`。 - 执行方：`dev.developer.project / infodev` - 独立审核方：`dev.reviewer.project / inforev` - 实现：`dev/project-dev/extract_ppt_slides.py`=`27482 bytes / 052F5B3BA40EA6C1BB87AF9A7BB4E9C50A84C5A45929540F23606582D30D7D1B`。 - 测试：`dev/project-dev/test/test_extract_ppt_slides.py`=`29015 bytes / 35CB570ACC6C9EE3AB25EB9B1B15C11691F0902AE23314445B645A1BA3760484`。 - 用法未变：`dev-doc/project-doc/会议录屏PPT页面提取工具.md`=`3372 bytes / 8FA1335973D5F84070DF5706C53C8CDDED8F92CC97DADEECA96B0B64EE7F3052`。 ### Findings - 无剩余阻断 finding。仅核对 F3-R1；F1/F2、算法、时间映射、PDF、布局、链接和排除项未重新审核。 ### F3-R1 闭环：PASS - `_run_file_command()` 与 `scan_video()` 均新增 `active_error: BaseException | None`。主流程一旦进入 `except BaseException` 即记录原异常；`finally` 中 stderr `close()` 的普通错误只有在 `active_error is None` 时才转换为带阶段的 `SlideExtractionError`，已有 `KeyboardInterrupt/SystemExit` 或普通主异常不会被关闭错误替换。 - `_attempt_reap()` 的既有合同未回退：子进程清理普通错误不替换非普通主异常；正常或普通运行错误仍保留阶段语义。 - 新增离线桩同时覆盖文件输出 helper 与扫描 helper：`wait/read -> KeyboardInterrupt` 后 stderr `close -> OSError`，两者均保留 `KeyboardInterrupt`；正常成功后的 close 错误转为“关闭 stderr 失败”的阶段错误；非零 `exit=7` 后 close 错误仍保留含阶段的非零退出错误。 ### 独立验证与外部动作 - 两个提交文件 `compile()`=`PASS`。 - 仅运行三个无媒体目标桩：`test_cleanup_error_does_not_replace_keyboard_interrupt`、`test_stderr_close_error_preserves_interrupt_in_both_helpers`、`test_stderr_close_error_is_staged_on_normal_and_ordinary_failure`=`3/3 PASS`，并启用 `ResourceWarning` 作为错误。 - 独立桩复算：`wait -> KeyboardInterrupt`、回收成功、stderr `close -> OSError` 时 `interrupt_probe=KeyboardInterrupt`；无主异常且 `close -> OSError` 时 `normal_close_probe=SlideExtractionError`，消息含 `probe-stage关闭 stderr 失败`。 - 开发方提交的完整离线回归为目标 `22/22 PASS`、project `41/41 PASS`；本限定复审遵照请求未重跑包含合成/VFR 视频的完整套件，也未读取既有媒体证据。 - 真实及合成媒体读取=`0`、截取=`0`、运行=`0`；未访问任何媒体路径或元数据。 - 并发新增开发员的治理配置不属于本事项授权范围，本审核未修改或修复。复审结束前只读执行 `mbx validate --project project-info --governance` 时当前状态=`OK / warnings=0`，该瞬时结果不冒充对并发管理变更的审核。 ### Open questions - 无。 ### 结论 - 审计状态：`PASS` - 阻断问题数：`0` - F3-R1=`CLOSED`；结合前序 F1/F2 已关闭结论，首次实现审核的三个阻断均已闭环。 - 放行边界：允许 `dev.developer.project` 按 V002 已授权顺序进入真实样本验收；本 PASS 不替代 `case_analysis.media_processor` 对真实页面效果、资源、源指纹和最终功能的验收，也不授权本审核员或开发员处理并发治理配置。 ## DEV-AUDIT-PROJECT-INFO-STOCK-VALUATION-PIPELINE-V2-DESIGN-20260801-001 - 记录时间：`2026-08-01T22:41:43+08:00` - 审核阶段：project 级股票估值端到端协调层 V2 重型方案首次独立审核。 - 审核对象：`DEV-ANA-STOCK-VALUATION-PIPELINE-V2-20260801-001` - 原生交接：`HANDOFF-INFODEV2-INFOREV-STOCK-VALUATION-PIPELINE-V2-DESIGN-V002-20260801-001`；来源任务 `019fbcbb-bed7-7c90-83ab-f50610f80d3a`。 - 执行方：`dev.developer.project.secondary / infodev-2` - 独立审核方：`dev.reviewer.project / inforev` - 方案：`dev-doc/project-doc/开发方案/CODE-DESIGN-PROJECT-INFO-STOCK-VALUATION-PIPELINE-V2-V002.md`=`17465 bytes / D0F69CE0B1CD4338C4318D4B920E53412EA96E42CA28F814AFE41CEE3C07F3F3`，与交接快照一致。 - 接管记录：`ai-infodev-2/worklog/2026-08-01-stock-valuation-v2-takeover.md`=`1437 bytes / 09A634CF4B51F534C902C6D3C96B4C86856CB28B6154BDC7EE41B86CFA9606C5`。 - 前序方案：`dev-doc/ana-doc/开发方案/CODE-DESIGN-ANA-STOCK-VALUATION-PIPELINE-V2-V001.md`=`16980 bytes / 0F24A636E4C6E22E7792746447E3E837A11DFCCACC275E6936551762D44C574D`；无独立 PASS，本轮不把其视为已审核基线。 - 外部动作：V2 实现读取/创建=`0`；`ana-dev` 修改=`0`；网络请求=`0`；真实或 fixture 运行=`0`。本轮仅做静态方案、治理记录和既有 V1 公共合同的只读核对。 ### Findings #### F1 — BLOCKING / 单一实施权属：V002 声明已接管，但全局事项、计划和旧阻塞记录仍把同一 task 标成 ana 角色的活动事项 - V002 第 13—17 行已经正确选择 project 落点并把 V001 降为历史证据；但 `dev-doc/开发事项总纲.md` 第 697—705 行、`dev-doc/开发事项计划.md` 第 788—797 行仍把当前方案指向 V001，负责人/审核员仍为 `dev.developer.ana.cai / dev.reviewer.ana.cai`，状态仍为旧方案待审。 - `DEV-ISSUE-ANA-STOCK-VALUATION-V2-REVIEW-SESSION-20260801-001` 仍是 `OPEN_BLOCKING_IMPLEMENTATION`，关闭条件是管理员修复或正式改派；现有接管日志和本次原生交接证明已发生改派，但正式事项链尚未追加该事实。仅在 V002 内自称“取代”不足以让另一活动计划、旧 inbox 请求和新 project 实施形成单一真相，存在双实现或双审核风险。 最小 required fixes： 1. 以 append-only 方式在事项总纲、事项计划和问题记录追加同一 task 的正式接管/替代记录：引用本次原生委派或管理授权，固定新 owner/reviewer、project 代码/测试/文档/审计落点，标记 V001 与旧 ana 审核请求为历史/已替代、`ana-dev` 全部只读，并关闭旧会话阻塞记录。 2. 不改写历史 V001，不删除旧消息；V003 只引用上述唯一当前入口。若当前开发角色无权关闭管理记录，先由 `project.admin` 代写该最小治理闭环；闭环前不得实现。 #### F2 — BLOCKING / V1 只读桥接：方案点名了公共函数，却没有冻结实际可调用签名、注册表解析和退出码映射 - 只读核对当前 V1：`run_pipeline(snapshot_path, output_dir, source_registry_path, *, force=False)` 强制需要 `source_registry_path`；`compute_valuation(snapshot, registry)` 强制需要 registry。V002 第 86、125 行只说调用 `run_pipeline`、`load_snapshot`、`compute_valuation`，没有说明 V2 如何解析并传入 V1 的 `source_registry.json`，也没有冻结所加载模块必须来自 `dev/ana-dev/stock_valuation_pipeline/`。 - V1 `run_pipeline` 返回状态对象，不返回进程退出码；退出码 `0/2/3` 是 V1 `cli.py` 对成功、`InputError`、`OSError/json.JSONDecodeError` 的映射。V002 宣称“保留退出码”，但未给桥接异常表，因此不同实现可产生不兼容结果。若通过复制 CLI/公式来补洞，又违反单实现边界。 最小 required fixes： 1. 在 V003 冻结 `v1_bridge` 的完整调用表：从仓库相对路径解析 V1 包与默认 registry；记录实际加载模块路径、V1 版本/引擎指纹和 registry 哈希；分别列出 `--input` 的 `run_pipeline(..., source_registry_path, force)` 与 judgment 模式的 `load_snapshot -> load registry -> compute_valuation(snapshot, registry)` 参数、返回和异常映射。 2. 明确复现 V1 CLI 的 `0/2/3` 语义而不复制计算/校验/报告代码；测试同时证明加载路径确为只读 V1、V1 三件套及 `GENERATED/REUSED` 与直接 CLI 一致、judgment 数值对象与直接公共函数一致。V1 公共合同不匹配时 fail-fast 并停止，不做第二实现。 #### F3 — BLOCKING / 四类公开提供者：目前只冻结“类别”，未冻结可审计的 provider registry 与字段取得合同 - V002 第 147—161 行描述法定公告、行情、结构化财务、机构预测的职责，但没有列出实际 provider ID、域名/端点、请求参数、字段路径、日期字段、单位/缩放、支持市场、主备顺序或解析版本；计划中的 `provider_registry.json` 尚不存在，也未作为送审附件冻结。 - 当前 V1 registry 对 `quote_provider`、`professional_database`、`institution_aggregator` 仍是泛型且 allowed domains 为空，不能替代 V2 的网络 allowlist。由开发时临场选站会让 HTTPS 限制、A1 回链、4/3 forecast gap、90 秒请求数和真实 smoke 都不可预测，也无法在方案审核时确认未使用登录/付费/受限来源。 最小 required fixes： 1. 在 V003 内或以带 bytes/SHA-256 的随附 registry 草案冻结首期实际提供者：每类至少一个明确 provider，机构预测至多两个；列 provider ID、公开域名和协议、端点/方法/规范化参数、支持市场、权威日期、字段映射、原始单位与换算、响应类型/上限、adapter version、A1/B1/B2 等级、核心/非核心和确定的回退/停止顺序。 2. 对每个 provider 固定最小成功、空数据、4xx/5xx、字段漂移与 as-of 过滤 fixture；未知域名或未登记回退必须在发请求前拒绝。不得把“另一公开站点”作为运行时自由选择。 #### F4 — BLOCKING / 90 秒硬预算：方案允许截止后等待在途请求，与自身验收门禁直接冲突 - V002 第 169 行规定达到 90 秒后“等待中的请求依自身超时结束”，因此在截止前刚开始的请求仍可继续 20 秒并再叠加重试/退避；`ThreadPoolExecutor` 的普通退出也会等待运行中的 future。第 263 行却要求外站异常“必须在预算内结束”，两者不能同时成立。 - 连接 8 秒、读取 20 秒和最多两次重试只限制单次动作，不能自动形成 acquisition 级绝对截止；当前设计也未说明流式读取、DNS/连接、退避和重试如何扣减剩余预算。 最小 required fixes： 1. 用单调时钟冻结唯一 `network_deadline = network_started + 90s`；每次请求、读取循环、退避、重试和 provider 二次搜索都先检查剩余预算，并把本次总超时裁剪到剩余时间。截止后不得创建新请求，所有在途调用必须按同一 deadline 协作返回，协调层不得因 executor shutdown 再无界等待。 2. 遥测保存 budget start/deadline/end、每 provider/request 消耗和超时 gap；离线阻塞服务器/桩覆盖四 worker、截止前启动、重试退避和退出清理，证明整个机械网络阶段在冻结容差内结束，而非只证明“停止提交新 future”。 #### F5 — BLOCKING / 内容寻址缓存与公司基线：`complete=true` 不是可复用性的充分语义，指纹和负缓存合同缺失 - V002 第 194—198 行没有定义 request fingerprint 的规范化前像；不同参数顺序、请求体、provider/adapter、ticker/as-of 或 fixture/real 来源可能碰撞或误复用。 - 请求索引同时保存 HTTP/业务状态与 `complete=true`，但复用门禁没有要求 HTTP 成功、解析/schema 成功或 ProviderResult 可用。于是完整写下来的 404、5xx、超时页、字段漂移响应或 `GAP/BLOCKED` 也可能被永久视为有效命中，后续复评不会重新取得数据。 - 单个 `baseline.json` 的 schema/version、baseline as-of、watermark、字段来源集合及“自身哈希”前像未冻结；也未定义从较新基线回跑较旧 as-of、并发写同一公司或部分动态模块刷新失败时的保留/回退规则。 最小 required fixes： 1. 冻结 request fingerprint 的规范化字段和编码，至少覆盖 provider/adapter version、method、canonical URL/query/body、ticker、as-of、数据种类及 fixture 身份；原始 blob 可归档失败响应，但可复用逻辑索引必须把传输完成、允许的 HTTP 状态、内容类型、哈希、解析/schema、as-of 与 provider semantic status 分开记录。 2. 明确负结果只按有界 TTL/本次运行使用或必须重试，不得用 `complete=true` 永久复用；冻结 baseline schema/version/as-of/watermark/source hashes/data hash、原子并发提交和新旧 as-of 选择规则。增加 404/5xx/字段漂移、哈希篡改、较新基线回跑较旧 as-of、局部刷新失败及并发提交测试，始终保持字段到 A1 document ID/raw hash 的回链。 #### F6 — BLOCKING / `--force` 原子替换：只有目标描述，没有可验证的目录交换与 `BaseException` 回滚状态机 - V002 第 249—254 行说明 staging、manifest-last 和备份交换，但未冻结 Windows 下 `output -> backup -> staging -> output -> remove backup` 的逐步所有权，也未说明在第一次/第二次 rename 后遇到 `KeyboardInterrupt/SystemExit`、回滚自身失败或备份清理失败时哪个目录为正式结果、原异常如何保留。 - 失败目录命名和输出路径预检也未处理既有文件、符号链接/reparse point、同名 `.failed-*` 或 backup 冲突。实现者无法据此证明旧完整结果永不丢失、半成品永不冒充正式目录。 最小 required fixes： 1. 冻结 absent-output 与 force-output 两条目录状态机、每一步唯一 owner、预检和冲突处理；提交边界捕获 `BaseException`，在已移动旧目录而新目录未成功就位时优先恢复旧目录，清理失败不得替换原 `KeyboardInterrupt/SystemExit`，只有新目录成功就位后才允许清除备份。 2. 离线注入每个 mkdir/write/manifest/第一 rename/第二 rename/恢复/清理点，逐项断言旧输出字节哈希、正式目录唯一性、staging/backup/failed 归属、COMPLETE manifest 不外泄和原异常类型。默认拒绝存在的文件、目录及链接必须发生在网络前。 #### F7 — BLOCKING / 终态、正式产物与双墙钟：缺少可消费的状态矩阵，且 staged metrics 无法证明“到提交完成”的墙钟 - V002 分散列出部分产物，但没有按 `COMPLETE / COMPLETE_WITH_GAPS / DATA_READY_NEEDS_JUDGMENT / BLOCKED / FAILED` 冻结必有、可有、禁止文件及 manifest/status/CLI exit code；尤其无 judgment 虽禁止 V1 两件套，却未固定 16 节报告、QA、source evidence、gap、runtime 和 manifest 的确切文件名及成功退出语义。 - `--task-start` 只标为 ISO-8601 可选，没有时区、未来值、来源或默认策略；阶段耗时也没有要求单调时钟。任意未来 task-start 可制造负值，系统时钟跳变可破坏阶段和 task/process wall。 - `runtime_metrics.json` 在 staging 中、manifest 又必须最后哈希；若其终点是第 258 行的 `commit_ready_at`，就尚未包含目录 rename 的提交完成。提交后再改 metrics 又会破坏第 227 行的 manifest 哈希门禁。当前合同没有解释如何同时满足原子包与“所有终态记录到最终提交的 task/process wall”。 最小 required fixes： 1. 给出终态矩阵：每个状态的 CLI exit code、stdout 最小 schema、正式/失败产物精确文件名、manifest status/complete、必有/禁止项；固定 `DATA_READY_NEEDS_JUDGMENT` 是预期数据终态而非伪 COMPLETE，`BLOCKED/FAILED` 必须非零且不可留下正式 COMPLETE 包。 2. 冻结 `task_start` 的带时区解析、`arg|process_start` 来源、不得晚于 process start 的校验与原值留证；wall timestamp 用带时区 UTC/本地值，所有 duration/budget 用单调时钟。 3. 明确 `commit_ready_at` 与实际 `commit_finished_at` 的权威终点及落证方式，使提交后 task/process wall 可审计且不重写已被 manifest 哈希覆盖的文件；正常、data-ready、blocked、failed、force rollback 各测双墙钟非负、阶段和总耗时关系、最终 stdout/receipt 与 committed manifest 的关联。 #### F8 — BLOCKING / 验收可复算性：铖昌 fixture、V1 10/10 与真实 smoke 还没有冻结输入快照、期望值、命令和证据包 - V002 第 277—291 行只写“与既有 fixture 一致”和“001270.SZ 或另一只深市股票”，没有列基线文件哈希、关键期望值/容差、fixture request map 或真实两次运行的隔离缓存/输出命令。实现方可在生成 fixture 时同时改变输入与 expected，测试仍会自洽通过。 - 当前可用只读基线为：铖昌 snapshot=`10585 bytes / 4C27EE81A670BFA8BBD1E2DFB03A9730F6940D7A340D410D232585C57598A138`，V1 results=`9766 bytes / 27671D42A75C82125B893B3374E27497E33B929BB1AFEFA61A5D3370BC446559`；V1 测试=`7231 bytes / C1ECD2A8C8C0C9131C3E93B1E384616508314CB2843571D169876CA155D171CD`，长城 fixture=`7142 bytes / 06AB6A7C45C2E43F71654C616F15A826B21E468C4BA72AFB0B253C9DD89FACD8`。V002 未把这些或等价批准快照固定到验收前像。 最小 required fixes： 1. 在 V003 冻结铖昌 fixture 的来源文件 bytes/SHA-256、request fingerprint→fixture response 清单、judgment overlay、关键数值的精确值/容差，以及 4 汇总/3 明细只形成一个 gap 的 expected；expected 必须来自独立只读基线，不能由被测 V2 在测试时生成。 2. 冻结 V1 10/10 的测试入口和基线快照，并同时运行直接 V1 与 V2 bridge 比较。 3. 冻结 L4 的首选 ticker/as-of、空缓存冷跑与同缓存复跑的两条命令、允许换股的唯一条件，以及必须留存的 stdout/stderr/runtime、request indexes、raw hashes、provider/gap、A1 links、cache/baseline diff 和 90 秒证据；真实值可随站点变化，但来源身份、日期、单位、预算、复用与缺口真值不能省略。该修订只冻结后续验收，不授权现在联网或运行。 ### 已通过且冻结的方案部分 - project 代码/测试落点、`ana-dev` 只读、不复制 V1 公式的总体方向正确；F1/F2 要求的是把正式权属与可调用边界补成单一、可执行合同，不授权回到 ana 实现。 - 无 judgment 时固定 `DATA_READY_NEEDS_JUDGMENT`、不构造伪 V1 snapshot/results、不输出方向性价格结论；有 judgment 时禁止覆盖价格、股本、法定利润、日期和 A1 身份。这一两阶段边界通过，不得回退。 - 四类来源、可信信源停止条件、publish/data 双日期 as-of 禁止未来信息、字段级 A1 回链、机构汇总 4/明细 3 只形成一个 gap、16 节顺序、统一数值源和自动 QA 的业务方向通过；F3—F5 仅要求补足实际 provider/deadline/cache 可执行细节。 - 不扩展 GUI、API、数据库、服务、批处理、交易指令、付费/登录来源或 V1 公式修改；原操作手册仍须管理员单文件授权或代同步，该文档权限事项不阻断 project 方案返修。 ### Open questions - 无。上述八项均可通过 append-only 治理闭环和 V003 方案/随附 registry 的最小返修解决，不需要创建 V2 代码、读取网络或修改 `ana-dev`。 ### 结论 - 审计状态：`HOLD` - 阻断问题数：`8` - 当前不得创建 V2 代码、测试或 fixture，不得修改 `ana-dev`，也不得开始真实网络 smoke。开发方应一次闭环 F1—F8 后提交 V003 限定复审；已通过的无 judgment、16 节报告、A1/as-of、4/3 forecast gap 与范围排除项不得回退。 ## DEV-AUDIT-PROJECT-INFO-STOCK-VALUATION-PIPELINE-V2-DESIGN-REREVIEW-20260801-001 - 记录时间：`2026-08-01T23:40:10+08:00` - 审核阶段：前序 `HOLD/8` 后仅复审 F1—F8 的限定方案复审。 - 审核对象：`DEV-ANA-STOCK-VALUATION-PIPELINE-V2-20260801-001` - 原生交接：`HANDOFF-INFODEV2-INFOREV-STOCK-VALUATION-PIPELINE-V2-DESIGN-V003-20260801-001`；来源任务 `019fbcbb-bed7-7c90-83ab-f50610f80d3a`。 - 前序审计：`DEV-AUDIT-PROJECT-INFO-STOCK-VALUATION-PIPELINE-V2-DESIGN-20260801-001=HOLD/8`。 - 执行方：`dev.developer.project.secondary / infodev-2` - 独立审核方：`dev.reviewer.project / inforev` - 复审方案：`dev-doc/project-doc/开发方案/CODE-DESIGN-PROJECT-INFO-STOCK-VALUATION-PIPELINE-V2-V003.md`=`28030 bytes / 358C37EE1FE7F5F832FAF33EBDEB1B1714DE46F315A55A1C1D53AF43D687C61F`，与交接快照一致；strict UTF-8=`PASS`，尾随空白=`0`。 - 管理闭环：已只读核对 `HANDOFF-INFOADMIN-INFODEV2-STOCK-VALUATION-V2-TAKEOVER-LEDGER-CLOSE-TERMINAL-20260801-001` 及总纲第 710—721 行、计划第 803—813 行、问题记录第 362—369 行。 - 外部动作：V2 代码/测试/fixture 目录均不存在；`ana-dev` 修改=`0`；真实网络=`0`。本轮只运行既有 V1 只读回归命令的 `-B` 变体，`10/10 PASS / 0.208 s`，未产生字节码。 ### Findings #### F5-R1 — BLOCKING / 原 F5 未完全闭环：动态字段“未过期”仍是未定义判断，无法安全决定局部刷新失败后的复用 - V003 第 151—155 行已正确分离 raw archive 与 reusable index，冻结负缓存、baseline schema/hash/as-of 和并发提交；但第 155 行允许局部刷新失败时保留“未过期”的旧动态字段，却没有按 `price/shares/cash-debt/corporate-action/forecast` 定义 freshness predicate、最长允许年龄或必须成功完成的增量检查。 - 该缺口会让实现者自行决定旧价格、股本或预测是否仍可作为核心输入；只满足 `field_date<=requested_as_of` 并不能证明它是 requested as-of 的最近有效时点。相同 as-of 并发结果又只写“按 data_hash 字典序作幂等选择”，未冻结取最小还是最大，`current.json` 仍可能因实现选择不同而漂移。 - 这是前序 F5 对“局部刷新失败和新旧 as-of 选择规则”的同一未闭环分支，不是新增缓存功能要求。 最小 required fixes： 1. 在后继方案用一张小表为每种动态 data kind 冻结可执行 freshness predicate：需要哪些日期/成功增量检查、允许复用到哪个 requested as-of、失败时是核心阻断还是非核心 gap；核心价格/股本不得仅凭“日期不晚于 as-of”沿用旧基线。 2. 明确相同 as-of 并发 data_hash 的唯一选择方向（例如 ordinal min 或 max）及 current 更新条件；对应局部刷新失败与双提交测试直接断言选中的 baseline/data hash。 #### F7-R1 — BLOCKING / 原 F7 未完全闭环：stdout、正式产物和 task-start 三处权威合同仍不自洽 - V003 第 177 行冻结的 stdout schema 不含 `receipt_sha256`、`receipt_bytes`，第 205 行却要求两者写 stdout；`BLOCKED/FAILED` 明确无 manifest/receipt，但 stdout 的 `manifest_path/receipt_path` 未冻结为 `null`，消费者无法按同一 schema 解析所有终态。 - 第 179—185 行仍用“data snapshot、16 节报告、QA、gaps、sources、runtime、manifest”等类别描述正式目录，没有给出前序 required fix 要求的精确文件名；只有 `data_snapshot.json`、`snapshot_build_report.json`、`valuation_snapshot.json`、`valuation_results.json` 和失败包三件套在其他章节可定位，正式报告、QA、gap、source、manifest 的公共路径仍需实现时猜测。 - 第 258—265 行把两次真实 smoke 的 `--task-start` 固定为 `2026-08-01T00:00:00+08:00`。只读原生任务证据显示上游用户“按照这个思路去做”turn 起点为 `2026-08-01T21:20:48+08:00`，日常开发接管 turn 起点为 `21:54:15+08:00`；午夜值不对应任一任务起点，会使本事项要求的 user-task wall 成为人为放大的名义值。 - 这是前序 F7 对“可消费状态矩阵与权威 task/process wall”的同一闭环，不扩展 telemetry 范围。 最小 required fixes： 1. 统一 stdout schema 与 receipt：增加 `receipt_sha256/receipt_bytes`，并按状态冻结 `manifest_path/receipt_path/receipt_*` 的 string/null 规则；正常 stdout 的最终 wall 必须逐值复制已绑定 manifest 的 receipt，失败状态不得伪造 receipt。 2. 给状态矩阵中的正式类别各指定一个精确相对文件名，至少覆盖 16 节报告、QA、gaps、sources、runtime log/metrics 和 run manifest；各状态的必有/禁止项直接引用这些名称。 3. 两条 smoke 命令使用有原生证据的实际 task-start（并登记来源 turn），或省略参数而明确此次只能验 process wall；不得用任意午夜常量冒充用户任务起点。 #### F8-R1 — BLOCKING / 原 F8 未完全闭环：冻结的长城 V1 fixture 路径不存在 - V003 第 248 行写 `dev/ana-dev/test/stock_valuation_pipeline/fixtures/greatwall_example.json`，只读检查 `Test-Path=False`。 - 同一行给出的 `7142 bytes / 06AB6A7C45C2E43F71654C616F15A826B21E468C4BA72AFB0B253C9DD89FACD8` 实际对应 `dev/ana-dev/test/stock_valuation_pipeline/fixtures/great_wall_military_20260731.json`。冻结 hash 正确、路径错误；按当前 V003 执行直接 V1 与 V2 bridge 比较会在读取输入前失败，或诱使实现者创建一个不应存在的 alias。 - 既有 V1 测试入口的只读 `-B` 运行已证明 `10/10 PASS`，因此这里只需修正验收前像路径，不要求改 V1、复制 fixture 或增加测试范围。 最小 required fix： 1. 后继方案仅把第 248 行 fixture 路径改为现存的 `dev/ana-dev/test/stock_valuation_pipeline/fixtures/great_wall_military_20260731.json`，保留既有 bytes/hash、V1 10/10 和 direct-vs-bridge 比较合同；禁止创建 alias 或修改 `ana-dev`。 ### F1—F8 闭环状态 - F1=`CLOSED`：管理员三本 append-only 账、唯一 owner/reviewer/project 落点、旧 ana 会话关闭及条件单文件授权均已核实。 - F2=`CLOSED`：V1 路径、版本、四项哈希、registry、函数签名和 0/2/3 映射均与只读实物一致。 - F3=`CLOSED`：首期登记 provider、allowlist/endpoint/字段/日期/单位/fixture/停止顺序已冻结；运行时自由换站仍禁止。 - F4=`CLOSED`：唯一 monotonic deadline、remaining 裁剪、协作返回、91 秒上限、telemetry 与四 worker 阻塞测试已冻结。 - F5=`PARTIAL / F5-R1 OPEN`。 - F6=`CLOSED`：absent/force 状态机、BaseException、恢复真值、receipt 失败和全点注入已冻结。 - F7=`PARTIAL / F7-R1 OPEN`。 - F8=`PARTIAL / F8-R1 OPEN`。 ### 已通过且继续冻结的合同 - 无 judgment=`DATA_READY_NEEDS_JUDGMENT`，不生成伪 V1 snapshot/results 或方向性结论；judgment 不得覆盖价格、股本、法定财务、日期和 A1 身份。 - 16 节顺序、A1 回链、publish/data 双日期 as-of、forecast 汇总 4/明细 3 只一个 gap、V1 单一数值源、交易指令禁令均未回退。 - project 落点、`ana-dev` 只读、无第二套估值核心，以及 GUI/API/数据库/服务/批处理/付费登录来源/V1 公式修改等排除项未回退。 ### Open questions - 无。三项均为 V003 现有 F5/F7/F8 合同的局部确定性修正，可一次写入 V004；不需要创建代码、测试、fixture，修改 `ana-dev` 或运行真实网络。 ### 结论 - 审计状态：`HOLD` - 剩余阻断问题数：`3` - 当前仍不得进入实现。开发方只需一次闭环 `F5-R1 / F7-R1 / F8-R1` 并提交 V004 限定复审；F1—F4、F6 及所有已通过业务合同不得再改，且无需联网或运行新增测试。 ## DEV-AUDIT-PROJECT-INFO-STOCK-VALUATION-PIPELINE-V2-DESIGN-V004-REREVIEW-20260801-001 - 记录时间：`2026-08-01T23:57:01+08:00` - 审核阶段：V003 `HOLD/3` 后仅复审 `F5-R1 / F7-R1 / F8-R1` 的限定方案复审。 - 审核对象：`DEV-ANA-STOCK-VALUATION-PIPELINE-V2-20260801-001` - 原生交接：`HANDOFF-INFODEV2-INFOREV-STOCK-VALUATION-PIPELINE-V2-DESIGN-V004-20260801-001`；来源任务 `019fbcbb-bed7-7c90-83ab-f50610f80d3a`。 - 前序审计：`DEV-AUDIT-PROJECT-INFO-STOCK-VALUATION-PIPELINE-V2-DESIGN-REREVIEW-20260801-001=HOLD/3`。 - 执行方：`dev.developer.project.secondary / infodev-2` - 独立审核方：`dev.reviewer.project / inforev` - 组合方案基线：`dev-doc/project-doc/开发方案/CODE-DESIGN-PROJECT-INFO-STOCK-VALUATION-PIPELINE-V2-V003.md`=`28030 bytes / 358C37EE1FE7F5F832FAF33EBDEB1B1714DE46F315A55A1C1D53AF43D687C61F`。 - 限定修订：`dev-doc/project-doc/开发方案/CODE-DESIGN-PROJECT-INFO-STOCK-VALUATION-PIPELINE-V2-V004.md`=`12117 bytes / 50DE1F7E765E8B828DEF1C25D6D5BEA32C3C0B07FD034929542AAE0CB4E84799`，与交接快照一致；strict UTF-8=`PASS`；尾随空白=`0`。 - 外部动作：V2 代码目录和测试目录均不存在；本轮只读核对方案、账本、原生任务时间与既有 V1 fixture，未创建代码、测试或 fixture，未修改 `ana-dev`，未运行真实网络。 ### Findings - 无剩余阻断。V004 仅替换 V003 第 9、13、15、18、20 节中与三个开放 finding 对应的局部合同，未重开或回退 F1—F4、F6。 ### F5-R1 复审 - `CLOSED`。V004 第 22—57 行为每个可复用字段组冻结统一 freshness 输入、固定 `process_start` 判断时刻、`FRESH|STALE|MISSING` 三态，以及逐 `data_kind` 的 TTL、水位、刷新动作、核心阻断/非核心 gap 和停止规则。 - `STALE` 只保留诊断原始 blob，禁止进入正式字段；核心行情、股本和财务不得靠陈旧值降级，forecast 两个登记来源后以唯一 gap 停止。 - 同一 requested as-of 的候选选择固定为：最大 `baseline_as_of`，再取最大规范 watermark，最后取 64 位小写十六进制 `data_hash` 的 ASCII 字典序最大值；`current.json` 使用同一比较，且相反插入顺序测试必须得到同一结果。 - 结论：前序关于动态字段“未过期”语义和 data hash 选择方向的歧义已消除，满足可实现、可重跑和可验收要求。 ### F7-R1 复审 - `CLOSED`。V004 第 61—82 行冻结成功包、失败包和同级外部 receipt 的精确相对文件名及各终态必有/禁止集合；`manifest.json` 仍为包内最后写入文件，失败终态不得创建 manifest/receipt。 - 第 84—124 行冻结 ticker 模式六类终态的 stdout exact-key schema、JSON `null` 规则、exit/status 字段值和 manifest/receipt 路径、hash、bytes、双墙钟逐值关系；receipt 不自引用本体 hash/bytes，消费者不再需要猜测缺失字段。 - 第 126—139 行把真实 smoke 的 task-start 回链到 Codex task `019fb338-fe89-7d52-9ba6-513e82de54d8` / turn `019fbd7c-00c5-7962-8a80-3206ca5a58d9`。只读原生任务核对 `startedAt=1785590448`，对应 `2026-08-01T21:20:48+08:00`；两条 smoke 命令和 task/process 双墙钟不等式均使用该实际起点。 - 结论：前序 stdout/receipt 冲突、正式产物文件名缺失和任意午夜 task-start 三项不自洽均已闭环。 ### F8-R1 复审 - `CLOSED`。V004 第 141—147 行废止不存在的 `greatwall_example.json`，禁止创建 alias，并把 V1 与 bridge 的全部比较入口统一为 `dev/ana-dev/test/stock_valuation_pipeline/fixtures/great_wall_military_20260731.json`。 - 只读实物核对：实际文件存在，`7142 bytes / 06AB6A7C45C2E43F71654C616F15A826B21E468C4BA72AFB0B253C9DD89FACD8`；不存在旧 alias。路径、字节数和哈希与 V004 完全一致。 ### 已通过且继续冻结的合同 - F1—F4、F6 保持 `CLOSED`：project 单一实施权属/V1 只读桥接、公开 provider registry、唯一 90 秒单调 deadline、BaseException 原子状态机均不得回退。 - 无 judgment=`DATA_READY_NEEDS_JUDGMENT`，不得伪造 V1 snapshot/results 或方向性结论；judgment 不得覆盖价格、股本、法定财务、日期和 A1 身份。 - 16 节报告、A1 与 publish/data 双日期 as-of、forecast 汇总 4/明细 3 只形成一个 gap、V1 单一数值源、无交易指令保持冻结。 - project 级落点、`ana-dev` 只读、无第二套估值核心，以及 GUI/API/数据库/服务/批处理/付费登录来源/V1 公式修改等排除项保持冻结。 ### Open questions - 无。 ### 结论 - 审计状态：`PASS` - 剩余阻断问题数：`0` - `F5-R1 / F7-R1 / F8-R1` 全部关闭；结合前序已关闭的 F1—F4、F6，V003+V004 组合方案可作为唯一实施合同。 - 允许 `dev.developer.project.secondary / infodev-2` 按 V003+V004 开始创建 V2 代码、测试和项目级 fixture，并按冻结顺序完成离线测试、fixture 性能、受控真实网络 smoke、文档和实现独立审核。`ana-dev` 继续只读；本 PASS 不授权扩大 GUI/API/数据库/服务/批处理、付费登录来源或修改 V1 公式。 ## DEV-AUDIT-PROJECT-INFO-STOCK-VALUATION-PIPELINE-V2-DESIGN-V005-PROVIDER-DELTA-20260802-001 - 记录时间：`2026-08-02T00:44:29+08:00` - 审核阶段：V003+V004 方案 PASS 后，首次真实 smoke 触发的两请求限定 provider delta 方案审核。 - 审核对象：`DEV-ANA-STOCK-VALUATION-PIPELINE-V2-20260801-001` - 原生交接：`HANDOFF-INFODEV2-INFOREV-STOCK-VALUATION-PIPELINE-V2-DESIGN-V005-20260802-001`；来源任务 `019fbcbb-bed7-7c90-83ab-f50610f80d3a`。 - 前序方案结论：`DEV-AUDIT-PROJECT-INFO-STOCK-VALUATION-PIPELINE-V2-DESIGN-V004-REREVIEW-20260801-001=PASS/0`。 - 执行方：`dev.developer.project.secondary / infodev-2` - 独立审核方：`dev.reviewer.project / inforev` - 限定修订：`dev-doc/project-doc/开发方案/CODE-DESIGN-PROJECT-INFO-STOCK-VALUATION-PIPELINE-V2-V005.md`=`4028 bytes / B4ABD0456BFA0C219C8C2A7A2A92CBE8B40804901A984A69B941A92F87571B6D`，与交接快照一致；strict UTF-8=`PASS`；尾随空白=`0`。 - 继承基线：V003=`28030 bytes / 358C37EE1FE7F5F832FAF33EBDEB1B1714DE46F315A55A1C1D53AF43D687C61F`；V004=`12117 bytes / 50DE1F7E765E8B828DEF1C25D6D5BEA32C3C0B07FD034929542AAE0CB4E84799`。 - 审核动作：只读核对 V005、当前 provider/registry/test/fixture、失败包和原始 blob；未联网、未运行 smoke、未修改实现/测试/fixture/`ana-dev`。 ### 触发证据核验 - 首次真实 smoke 失败包 `dev/tmp/valuation-v2-real-smoke-001/cold.failed-b036e888ea644a1db66df5d967ffa26f/` 存在；`failure.json` 为 `BLOCKED / E_CORE_INPUT / 缺少非经营性金融资产组成字段`，`runtime_metrics.json` 记录 process wall=`1.4540000000270084 s`、task-start=`2026-08-01T21:20:48+08:00`，没有伪装成功。 - 简版 balance 原始 blob 可复算为 `30407 bytes / 819144DA9256200C0FEEB1B03BB2E3715B08827817EC58871C7761CA5DD60F81`；2026-03-31 行含 `MONETARYFUNDS/TOTAL_EQUITY/TOTAL_ASSETS/TOTAL_LIABILITIES`，但确实不含 `TRADE_FINASSET_NOTFVTPL/NONCURRENT_LIAB_1YEAR/LEASE_LIAB`。 - 当前实现仍使用 `RPT_DMSK_FN_BALANCE` 和 `beg=end=as_of`；当前 fixture 仍为前序聚合字段前像。V005 请求/fixture 变更尚未激活，符合 delta PASS 前门禁。 ### Findings #### F1 — BLOCKING / 数据合同：字段集合只以“任一字段存在”为成功条件，仍会把部分 schema 漂移静默计为 0 - V005 第 32—33 行对金融资产和有息债务都规定：列举字段中“一个字段都不存在”才 `BLOCKED`，只对实际存在字段求和；存在字段为 `null` 可按 0。这样只要响应保留任意一个候选键，即使其余可能承载非零金额的键因 schema 漂移被删除，也会继续求和并把缺失组成隐式当 0。 - 第 31 行的 `MINORITY_EQUITY|null→0` 同样没有区分“键明确存在且值为 null”和“键完全缺失”。这与本次真实 smoke 已证明的根因相同：摘要/漂移响应可能保留部分资产负债字段，但不能据此证明缺失明细为零。 - 第 43 行测试只覆盖“全部明细字段存在但均为 null”和“所有字段都不存在”，没有覆盖只缺一个或只保留一个字段的 partial-schema 情况；当前合同仍可能低估非经营性金融资产、有息债务或少数股东权益，进而污染估值输入。 最小 required fixes： 1. 在后继限定修订中，为 `RPT_F10_FINANCE_GBALANCE` 冻结可执行的 schema 完整性规则：明确每个经济组成是独立可加字段还是互斥 alias 组；每个必需组成/alias 组都必须在响应中有键，缺任何必需键即 `BLOCKED`。只有通过该键集合校验后，显式 `null` 才可按法定表无该项目计 0。 2. `MINORITY_EQUITY` 也必须区分 absent 与 explicit null：absent=`BLOCKED`，键存在且 null 才为 0。 3. 增加 partial-schema 反例（至少金融资产缺一个组成键、债务缺一个组成键、`MINORITY_EQUITY` 缺键）及 alias 双存在用例；断言缺键阻断、互斥 alias 不重复求和、完整键集合精确得到 `95338761.64 / 825466.20`。不需要新增 host/provider 或联网复跑。 ### 已通过的 delta 部分 - balance reportName 从 `RPT_DMSK_FN_BALANCE` 替换为同一登记 host 上的 `RPT_F10_FINANCE_GBALANCE`，保持 HTTPS/GET/filter/分页/排序/响应上限、B1+A1/as-of/预算与停止规则，方向合理；本 HOLD 不要求新增来源或 fallback。 - K 线 `beg=as_of-14 calendar days / end=as_of`、仅保留 `f51<=as-of` 并取最大日期、空窗口 `BLOCKED`，正确实现既有“取不晚于 as-of 的最近交易日”合同，`PASSED_AND_FROZEN`。 - 首次真实失败证据、不得以 0 掩盖缺失值、V003+V004 其余合同和 `ana-dev` 只读边界继续冻结。 ### Open questions - 无。唯一阻断可由字段键集合/alias 组合同和离线 partial-schema 测试闭环，不要求新网络来源或真实 smoke。 ### 结论 - 审计状态：`HOLD` - 阻断问题数：`1` - V005 provider delta 当前不得实施。开发方只需提交关闭 F1 的后继限定修订；K 线窗口和同 host 完整 balance 端点选择已经通过，不得回退。PASS 后再实施并按原计划重跑全套离线、fixture cold/warm 和真实 cold/warm smoke。 ## DEV-AUDIT-PROJECT-INFO-STOCK-VALUATION-PIPELINE-V2-DESIGN-V006-BALANCE-SCHEMA-REREVIEW-20260802-001 - 记录时间：`2026-08-02T01:18:41+08:00` - 审核阶段：V005 provider delta `HOLD/1` 后，仅复审 balance schema-completeness F1 的限定方案复审。 - 审核对象：`DEV-ANA-STOCK-VALUATION-PIPELINE-V2-20260801-001` - 原生交接：`HANDOFF-INFODEV2-INFOREV-STOCK-VALUATION-PIPELINE-V2-DESIGN-V006-20260802-001`；来源任务 `019fbcbb-bed7-7c90-83ab-f50610f80d3a`。 - 前序审计：`DEV-AUDIT-PROJECT-INFO-STOCK-VALUATION-PIPELINE-V2-DESIGN-V005-PROVIDER-DELTA-20260802-001=HOLD/1`。 - 执行方：`dev.developer.project.secondary / infodev-2` - 独立审核方：`dev.reviewer.project / inforev` - 复审方案：`dev-doc/project-doc/开发方案/CODE-DESIGN-PROJECT-INFO-STOCK-VALUATION-PIPELINE-V2-V006.md`=`3278 bytes / 0A997EFB1D8237EB4102E7BAD71BDADE7F0BD2C1178DDAC9F74117254E3FD209`，与交接快照一致；strict UTF-8=`PASS`；尾随空白=`0`。 - 继承方案：V005=`4028 bytes / B4ABD0456BFA0C219C8C2A7A2A92CBE8B40804901A984A69B941A92F87571B6D`；V003+V004 及 V005 已通过端点/K 线条款继续冻结。 - 审核动作：只读核对 V006、V005 F1 和当前 provider 实现；当前实现仍为 `RPT_DMSK_FN_BALANCE` 与 `beg=end=as_of`，证明 provider delta 尚未激活。本轮未联网、未运行 smoke、未修改实现/测试/fixture/`ana-dev`。 ### Findings - 无剩余阻断。 ### F1 闭环核验 - `CLOSED`。V006 第 13—20 行把非经营性金融资产冻结为一个完整互斥 alias 组和两个独立组成；全部键均为 schema 必需键，缺任一键即 `E_BALANCE_SCHEMA_DRIFT/BLOCKED`，只有完整性校验通过后 explicit null 才能计 0。 - alias 组 0/1/多非 null 的行为确定：全 null=0；单值采用；多值只有数值完全相等才计一次，不等即 `E_BALANCE_ALIAS_CONFLICT/BLOCKED`，消除了重复求和或漂移字段被静默忽略的风险。 - 经济口径明确排除长期战略性 `OTHER_EQUITY_INVEST`、债权投资和其他非流动金融资产，不把它们自动当现金等价物抵减企业价值；冻结完整响应仍精确得到 `non_operating_financial_assets=95338761.64`，没有扩大 V1 数值口径。 - 第 24—30 行要求六个债务键全部存在，缺任一键即 schema drift；完整后 explicit null=0、非 null 必须非负，精确债务=`825466.20`。 - 第 32—34 行明确 `MINORITY_EQUITY` absent=`BLOCKED`、present null=0、数值必须非负，不再由 `dict.get(...,0)` 混淆 absent/null。 - 第 36—44 行要求逐一删除每个金融资产、债务和 minority 必需键的反例，并覆盖 alias 相等/不等、全 null 与冻结精确总额；测试合同已覆盖前序 required fixes 的全部分支。 ### 已通过且继续冻结的合同 - V005 已通过的同 host `RPT_F10_FINANCE_GBALANCE` 端点选择和 K 线 14 日窗口保持 `PASSED_AND_FROZEN`；不新增 provider、域名、fallback 或网络预算。 - 首次真实失败证据、不得把缺失字段填 0、V003+V004 全部通过合同、project 落点和 `ana-dev` 只读边界均未回退。 - 本 PASS 只授权实施 V005+V006 provider delta；不替代后续离线、fixture、真实 cold/warm smoke 和最终实现独立审核。 ### Open questions - 无。 ### 结论 - 审计状态：`PASS` - 剩余阻断问题数：`0` - V005 F1 已由 V006 完整关闭。允许 `dev.developer.project.secondary / infodev-2` 按 V003+V004+V005+V006 组合合同实施 balance 端点/schema 与 K 线窗口变更，随后完成全套离线测试、V1 10/10、fixture cold/warm、真实 cold/warm smoke、文档和最终实现独立审核。 ## DEV-AUDIT-PROJECT-INFO-STOCK-VALUATION-PIPELINE-V2-IMPLEMENTATION-20260802-001 - 记录时间：`2026-08-02T02:11:28+08:00` - 审核阶段：V003+V004+V005+V006 组合合同下的完整实现、离线测试、project fixture、fixture cold/warm、真实 cold/warm smoke、工具文档与证据链独立审核。 - 审核对象：`DEV-ANA-STOCK-VALUATION-PIPELINE-V2-20260801-001` - 原生交接：`HANDOFF-INFODEV2-INFOREV-STOCK-VALUATION-PIPELINE-V2-IMPLEMENTATION-REVIEW-20260802-001`；来源任务 `019fbcbb-bed7-7c90-83ab-f50610f80d3a`。 - 前序方案结论：`DEV-AUDIT-PROJECT-INFO-STOCK-VALUATION-PIPELINE-V2-DESIGN-V006-BALANCE-SCHEMA-REREVIEW-20260802-001=PASS/0`。 - 执行方：`dev.developer.project.secondary / infodev-2` - 独立审核方：`dev.reviewer.project / inforev` - 审核边界：仅审核 project 级 V2 实现、测试、fixture、既有 smoke 证据和配套文档；`dev/ana-dev/` 全程只读；本轮未联网、未重跑真实 smoke、未修改实现/测试/fixture/输出或原操作手册。 ### 冻结快照与独立验证 - 交接声明的 12 个冻结工件均逐文件复算并匹配字节数/SHA-256：`workflow.py`、`providers.py`、`http_client.py`、`cache.py`、`v1_bridge.py`、`provider_registry.json`、`test_pipeline_v2.py`、project fixture manifest、工具文档、实现与验收证据、目录导读和接管 worklog；实现与测试/fixture 共 34 个非 `pyc` 文件纳入只读快照。 - V1 六个冻结文件与 V003/V004 记录的路径、字节数和 SHA-256 一致，`ana-dev` 未被本任务修改；V2 没有复制第二套 V1 估值公式。 - 审核员独立运行：V2 unittest=`24/24 PASS`（`5.679 s`）；V1 readonly unittest=`10/10 PASS`（`0.180 s`）；`compileall=PASS`；CLI help=`PASS`；治理校验=`OK / projects=1 / warnings=0`。 - 既有 fixture cold/warm/judgment 与 real cold/warm 的 manifest/receipt 哈希、manifest 内文件字节数与 SHA-256、成功包文件数和 task/process 双墙钟不等式内部一致；real cold=`6E905229...E0F0F6 / D5F9488F...B20B48`，real warm=`0DFFD45E...FEDD5D / 984B2566...FB0275`。 - 已通过并继续冻结：V1 bridge 的路径/哈希/直接与桥接单一数值源、V1 `10/10`；V006 balance 必需键/alias 完整性与精确总额 `95338761.64 / 825466.20`；16 节外形、无交易指令、现有工件哈希链及早期 `BLOCKED` 证据保留。上述通过项不抵消下列合同级阻断。 ### Findings #### F1 — BLOCKING / 历史 as-of 数据合同被伪满足，现有真实成功 smoke 不可作为正确性证据 - `providers.py:224-249` 对 K 线先过滤 `f51<=as_of`，但随后取 `eligible[-1]`，没有按冻结合同取最大 `f51`；审核员用乱序离线响应复核时错误选择了 `2026-07-31`，尽管响应中存在 `2026-08-01`。 - 同一实现直接采用实时 quote 的 `f84/f116`，未校验 `f124` 的数据日期，却把股本日期回填为所选历史交易日。既有 real cold quote 原始响应 `7963180...` 的 `f124=0`，因此不能证明请求日 `2026-07-31` 的历史股本/市值；按 V004 必须 `BLOCKED`，不得输出 `DATA_READY_NEEDS_JUDGMENT`。 - `providers.py:136-145` 把公告截止日的“本地日终”构造成 UTC 日终，实际可放入上海时区次日 `07:59:59` 前的信息；forecast `providers.py:470-536` 未按响应自身 `REPORT_DATE/UPDATE_DATE` 做 `<=as_of` 过滤，且在原始响应缺少这些日期时把 `publish_date/period_end` 伪造为 `as_of`。 最小 required fixes： 1. K 线在解析合法日期后按 `f51` 取不晚于 as-of 的最大日期，并补乱序、周末、空窗口、未来行反例。 2. 严格执行 V004 shares/market-cap freshness：只有 quote 的可证明本地数据日等于 requested as-of 才可直接采用；历史请求只能使用在该 as-of 合法取得并留痕的基线，否则核心输入 `BLOCKED`，不得把实时值回填到历史日期。 3. 公告使用 `Asia/Shanghai` requested-as-of 日终比较；forecast 必须从真实响应字段建立 publish/data 日期并过滤，缺失必要日期时形成阻断或既定非核心 gap，禁止以 requested as-of 代填来源日期。 #### F2 — BLOCKING / 核心字段血缘、A1 回链和自动 QA 仅有 provider 级外形，没有落实字段级证明 - finance provider 没有生成其核心财务字段使用的 `sources`；既有 real `snapshot_build_report.json` 中 `field_lineage.finance.source_ids=[]`，却仍通过构建和 QA。构建器只检查“任意 A1 source 含同报告期”，没有证明每个法定财务值实际来自哪一份 A1 原文及对应 raw hash。 - `snapshot_builder.py:89-92` 对缺失 `publish_date/period_end` 使用 requested as-of 兜底，未知日期因而会被判定安全；这与“不知道即不能证明 as-of safe”的冻结合同相反。 - `report_qa.py:16-55` 只检查 16 个标题、少量禁词、一个布尔位、存在任意 raw hash 和两个 V1 数值；未校验每个核心字段的 source_id→A1→raw hash 回链、全量数值一致性、表格/围栏/本地链接、受保护字段和 manifest。工具文档/证据文档关于“全部核心字段已回链且全部日期安全”的表述与实物不符。 最小 required fixes： 1. 生成可机读的字段级 lineage；价格、股本、法定财务、balance、日期与 A1 身份逐字段绑定 provider/source_id/raw hash/publish date/data date，财务字段必须回链到对应报告期的 A1 原文。 2. 缺失必要 publish/data 日期、source_id 或 raw hash 必须拒绝正式值；不得用 requested as-of 兜底。 3. 将 V003 自动 QA 清单落实为可执行校验和正反测试，并按真实能力纠正工具文档、证据文档与报告文字。 #### F3 — BLOCKING / 公司基线与 FRESH/STALE/MISSING 状态机未实现，warm 只复用了请求缓存 - `cache.py` 只有请求级 `load_reusable/store/promote_reusable` 和只写 `write_baseline`；workflow 每次仍调用全部 provider，未按 data-kind 读取/选择公司基线，也没有逐类 TTL/watermark/freshness、核心 stale 禁止入正式值、非核心 gap、局部刷新/停止规则。 - 既有 baseline 缺少冻结合同要求的逐 data-kind 数据日期、发布日期、fetched/expires、schema/as-of/semantic 状态等输入；`write_baseline` 对 `current.json` 的读-比-写无 ticker 锁，存在并发 TOCTOU，测试仅顺序写入，未覆盖逆序与并发确定性。 - 请求 fingerprint 未纳入冻结 headers，body 未按 content type 规范化，query 结构也不能充分保留重复值；工具文档却宣称已包含 headers。 最小 required fixes： 1. 实现 V004 的逐 data-kind 基线载入、共同 freshness predicate、确定性候选选择、FRESH/STALE/MISSING 行为、核心/非核心分流与 ticker 级并发安全 current 更新。 2. 实现冻结的 canonical fingerprint preimage、raw 与 reusable 索引、PENDING_PARSE→确认可复用、negative TTL，并补每个 data-kind 的 fresh/stale/missing、逆序、并发、篡改和 partial-write 测试。 3. fixture warm 必须证明公司基线语义复用，而不只是同一请求 blob cache 命中。 #### F4 — BLOCKING / provider allowlist 与单调 90 秒截止不能阻止越界请求或超时后后台写入 - `http_client.py:74-82` 只校验 provider/version、HTTPS host 和 method，未校验冻结 endpoint/path/query/reportName、响应 content type 和 provider 独立响应上限；读取统一允许 `20 MiB`。 - retry backoff 睡眠后不重新校验 remaining，且 timeout 下限强制 `0.05 s`；阻塞 read 继续沿用请求开始时的 socket timeout，不能保证 deadline+1 秒内退出。`acquisition.py:85` 使用 `shutdown(wait=False)`，截止后仍运行的任务可能继续写 cache。 - 现有“四 worker”测试只是合作式 stub 轮询 remaining，未覆盖真实 HttpClient 的阻塞 read/backoff、截止后 request count=0、无后台写入等合同。 最小 required fixes： 1. 按 registry 精确校验 host+path+method+固定 query/reportName、content type 与逐 provider 响应上限，拒绝重定向及所有未登记变体。 2. 让所有 retry、open、read 和 worker 收束于同一 monotonic deadline；睡眠后先复核，不得在剩余时间耗尽后创建请求，截止返回后不得再产生正式 cache/baseline 写入。 3. 增加可控阻塞 transport 测试，证明 task 内/外双墙钟、deadline+1 秒上界、request count 和无后台副作用。 #### F5 — BLOCKING / 路径预检与 force 原子提交状态机违反冻结 BaseException 合同 - `workflow.py:207-215` 在 `lstat`/reparse 检查前调用 `Path.resolve()`，会先消解词法 symlink/junction 身份；同时未逐级验证父链 reparse，不能证明输出/cache/fixture 落点安全。 - `workflow.py:381-406` 把备份清理失败纳入通用异常路径，继而删除新成功输出并恢复旧输出。审核员离线 fault probe 在 `cleanup_backup` 注入失败时得到 `exit=5` 且旧输出被恢复；冻结合同要求新输出/receipt 保持成功，备份保留并仅记 warning。 - rollback 再失败仅通过 `add_note` 附着，failure package/终端摘要不能可靠保留主异常和回滚异常双证据；`commit_finished` 在 receipt 写入/fsync 之前采集，声称的 final double-wall 没有覆盖实际 receipt commit。 - 现有 KeyboardInterrupt 仅覆盖一个注入点，没有逐点覆盖 SystemExit、receipt、cleanup 和 rollback 双失败。 最小 required fixes： 1. 在任何 resolve/mkdir/写入前对词法路径及父链执行 `lstat`/reparse 校验，之后再形成规范绝对路径；拒绝 symlink/junction/reparse 和类型冲突。 2. 按 V003/V004 重写 absent/force BaseException 状态机：备份清理失败保持新成功并报告 warning；提交失败回滚旧输出/receipt；主异常原样重抛或映射且双异常进入 failure evidence。 3. final receipt/summary 的 commit_finished 与 task/process wall 必须覆盖 receipt 的实际原子写入和持久化；补齐每个冻结故障点的 Exception/KeyboardInterrupt/SystemExit 与 rollback/cleanup 组合测试。 #### F6 — BLOCKING / 终态矩阵、离线测试与实现证据对未实现能力作了过度声明 - 无 judgment 时只有 forecast coverage gap；当 fixture 为 3/3 时可得到 `DATA_READY_NEEDS_JUDGMENT` 但 `gap_count=0`，违反 V004 要求的强制人工判断 gap。 - CLI parser 级输入错误仍走 argparse 的 stderr/SystemExit，不是冻结的单行 canonical JSON stdout `INPUT_ERROR` 合同。 - 24 个 V2 测试没有覆盖六种终态 exact stdout/file matrix、BLOCKED/FAILED 文件集、每类 baseline freshness、provider 4xx/5xx/空/schema/future、全部 force 故障点、cleanup/rollback 双失败及 V1 bridge success/reuse/force/input byte equivalence；所谓 future-source 测试没有调用 builder，属于空断言。 - 因 F1-F5，现有 real cold/warm 虽然工件内部哈希一致，但其 `DATA_READY_NEEDS_JUDGMENT` 正确性结论无效；实现与验收证据文档对覆盖面和 as-of/A1 成功作了过度声明。 最小 required fixes： 1. 无 judgment 终态始终加入独立 judgment gap；统一 parser 级和运行级六终态的 exact exit/stdout/artifact/receipt 合同。 2. 补齐 V003+V004+V005+V006 已冻结测试矩阵，删除或改成真正执行被测入口的空测试；独立重跑 V2、V1、fixture cold/warm/judgment。 3. 修复后在新隔离目录运行一组真实 cold+warm，保留旧 smoke 不覆盖。若冻结公开来源不能证明 requested as-of 的历史股本，正确结果应是诚实 `BLOCKED`，不得伪造成功或擅自新增 provider；真实来源变化如需新口径，先提交限定方案 delta。同步纠正工具文档、实现证据和有权限的正式执行日志。 ### 操作手册条件授权 - 当前结论为 `HOLD`，管理员的条件单文件授权尚未满足；不得同步 `outputs/20260730_stock_valuation_guide/股票价格合理性评估操作手册_v1.0.md`，也不得修改该目录其他文件。 - F1-F6 全部关闭并取得实现复审 `PASS` 后，可按管理员既有条件授权只同步上述一个操作手册文件；同步完成后必须提交一次“操作手册单文件限定确认”，只核对该文件与已通过实现/工具文档的一致性和变更边界，无需为该限定确认重跑网络或真实 smoke。 ### Open questions - 无。六组问题均可由组合合同内的代码、离线测试、文档修正和一次新的受控 real cold/warm 闭环；不授权新增 provider、修改 V1 公式或改动 `ana-dev`。 ### 结论 - 审计状态：`HOLD` - 阻断问题数：`6` - 当前实现与既有真实成功证据不得交最终交付或同步原操作手册。开发方应仅按 F1-F6 的最小 required fixes 修复，保持已通过的 V1/V006/工件哈希链边界，完成离线矩阵和一组新隔离 real cold/warm 后提交一次完整实现复审。 ## DEV-AUDIT-PROJECT-INFO-STOCK-VALUATION-PIPELINE-V2-IMPLEMENTATION-HOLD6-REREVIEW-20260802-001 - 记录时间：`2026-08-02T04:36:44+08:00` - 审核阶段：首次实现 `HOLD/6` 后，对 F1—F6 修复、最终代码/测试、fixture 与既有真实证据的完整限定复审。 - 审核对象：`DEV-ANA-STOCK-VALUATION-PIPELINE-V2-20260801-001` - 原生交接：`HANDOFF-INFODEV2-INFOREV-STOCK-VALUATION-PIPELINE-V2-IMPLEMENTATION-HOLD6-REREVIEW-20260802-001`；来源任务 `019fbcbb-bed7-7c90-83ab-f50610f80d3a`。 - 前序实现审计：`DEV-AUDIT-PROJECT-INFO-STOCK-VALUATION-PIPELINE-V2-IMPLEMENTATION-20260802-001=HOLD/6`。 - 执行方：`dev.developer.project.secondary / infodev-2` - 独立审核方：`dev.reviewer.project / inforev` - 审核边界：只复核前序 F1—F6 及更正后的测试、文档和证据；V003+V004+V005+V006 继续冻结，`dev/ana-dev/` 只读。本轮未联网、未运行真实 smoke、未修改实现/测试/fixture/输出或操作手册。 ### 冻结快照与独立验证 - 四份设计以及交接列明的实现、测试、fixture、工具文档、证据文档、目录导读、执行日志、worklog、操作手册均逐文件复算，字节数和 SHA-256 全部匹配交接快照；操作手册仍为 `68700 bytes / CCF534DB38F29AFCC61E55FAA47C06829E69E504BDE5CEFF771B10A9AF5AB6E6`，未进入本轮审核。 - 审核员独立运行：V2 unittest=`46/46 PASS`（`20.611 s`）；V1 readonly unittest=`10/10 PASS`（`0.139 s`）；`compileall=PASS`；CLI help=`PASS`。这些结果证明现有断言全绿，但不能替代下列冻结合同反例。 - 既有 fixture `valuation-v2-fixture-acceptance-003` 三态的 manifest/receipt、文件哈希、16 节、23 条核心 lineage、V1 数值及 cold/warm 请求计数均复算一致；既有 real `valuation-v2-real-smoke-006` 两次均诚实 `BLOCKED/E_HISTORICAL_SHARES_UNPROVEN`，各有 10 条 telemetry/raw，且无 OUT/manifest/receipt/current/market reusable。无需为本次复审重新访问真实来源。 - F1 的 K 线最大合法日期、`f124`/历史股本阻断、上海时区公告截止及 forecast 真实日期合同已闭环；真实 smoke 的诚实 BLOCKED 也与冻结合同一致。F1 状态为 `CLOSED`。 ### Findings #### F2-R1 — BLOCKING / “23 条核心血缘”仍未证明财务值与对应报告期 A1 一致 - `snapshot_builder.py:129-160` 只选取 annual A1 与 current A1；除 annual 外的所有财务路径都绑定 current A1。正式 fixture 中 `financials.prior_year_same_period.*` 的 `data_date=2025-03-31`、结构化来源为 `SRC-EM-FINANCE-*-20250331`，但 `a1_source_id=SRC-Q1-2026`、`a1_period_end=2026-03-31`。该 A1 source 的 `supports` 也不含 `financials.prior_year_same_period`。 - `test_29` 只断言 A1 ID/raw hash 出现在集合中，QA 也只校验存在性，因而上述期间错配仍得到 `QA PASS`。这不满足前序 F2 required fix 和 V003 第 7/11 节“财务字段回链对应/同报告期 A1”的硬门禁。 最小 required fixes： 1. 为 prior-year-same-period 每个核心字段绑定真正支持该比较期的 A1 证据；若采用 2026 Q1 报告中的同比列，必须从同一 A1/结构化记录的明确比较字段取值并记录可机读的比较期关系，不能把独立的 2025-03-31 行直接挂到 2026-03-31 A1。 2. QA 与正反测试逐字段断言 `data_date/A1 period/support/raw field` 的一致关系，加入当前 fixture 的期间错配反例；只检查 ID/hash 存在不足以放行。 #### F3-R1 — BLOCKING / data-kind 基线仍按 provider 全有或全无，局部刷新退回请求缓存 - `cache.py:fresh_provider_results` 只有当同一 provider 的所有 data-kind 都为 FRESH 时才复用整个 provider result；任一财务表 STALE/MISSING 就丢弃其余三个 FRESH 表的公司基线。 - 审核员离线反例：先形成合法公司基线，仅把 `finance_income` 设为 STALE，并移除 `eastmoney.finance` 的请求级 reusable index；第二次入口运行仍对 `finance_main/finance_income/finance_balance/finance_cashflow` 四个 reportName 全部执行 transport（`transport_count=4`），而冻结合同要求只请求缺项或陈旧 reportName。现有 warm=0 请求依赖整组 provider 或请求 cache，未证明逐 data-kind 公司基线语义复用。 最小 required fixes： 1. 从公司基线逐 data-kind 载入和合并 FRESH 值，只刷新 STALE/MISSING 表；刷新成功项独立提交，STALE 核心值不得进入正式结果。 2. 增加入口级 partial-refresh 测试：仅一个财务 data-kind STALE/MISSING、其请求索引不存在时只发生一个对应 transport，其余 FRESH 值来自公司基线；同时覆盖刷新失败和不更新 current 的合同。 #### F4-R1 — BLOCKING / HTTPError 响应体读取绕过唯一 monotonic deadline - `http_client.py:427-445` 的 `except urllib.error.HTTPError` 直接执行 `exc.read(max_bytes + 1)`；与正常 2xx 分块读取不同，它没有按 remaining 设置读超时、没有分块复核 deadline，也没有在读取中响应 cancel。 - 审核员离线慢 404 桩以 `deadline=0.5 s`、响应体 `read` 阻塞 `1.2 s` 复现：只创建 1 次请求，但 `fetch` 在 `1.453 s` 才以 `NetworkBudgetExceeded` 返回。即使后续拒绝归档，调用已越过共享截止及冻结容差；现有四 worker 测试只覆盖正常 response，不覆盖 HTTPError body。 最小 required fixes： 1. 让 HTTPError/4xx/5xx 响应体与正常响应共用分块读取、remaining socket timeout、大小上限和 cancel/deadline 检查；截止后不得重试、归档或提升 reusable。 2. 补慢 4xx 与慢 5xx（含 retry/backoff）离线 transport 测试，断言截止上界、请求计数和返回后 cache mutation 不增长。 #### F5-R1 — BLOCKING / final receipt 双墙钟仍早于实际最终持久化 - `workflow.py:457-487` 先写一次 provisional receipt，再在第二次最终 `atomic_write` 之前捕获 `commit_finished/task_wall/process_wall`；正式 receipt 与 stdout 虽逐值相等，但它们排除了第二次 receipt 写入及其持久化时间。 - 审核员在不改产物语义的离线桩中仅给第二次 receipt 写入增加 `0.25 s` 延迟，得到实际成功返回 `0.617 s`、receipt/summary `process_wall=0.359 s`，遗漏 `0.258 s`。因此前序 F5 required fix“权威 final wall 覆盖实际 receipt commit”尚未闭环。 最小 required fixes： 1. 重新定义并实现可验证的 receipt 完成协议，使 receipt 与 stdout 的权威终点确实不早于最终原子写入/持久化；若现有精确字段形成自引用时序，先提交只解决该时序的限定设计 delta，不得继续用写前时间冒充写后完成时间。 2. 用可控的最终写入延迟和写入/replace/fsync 失败桩证明：权威 wall 覆盖最终提交、receipt/summary/hash/bytes 一致，失败仍按 force 状态机恢复旧 output/receipt。 #### F6-R1 — BLOCKING / 46 个测试仍未覆盖已冻结的完整矩阵，证据文档继续过度声明 - `test_31` 只直接调用 `data_kind_state` 判断构造记录，没有对每个 data-kind 运行入口级 FRESH/STALE/MISSING、STALE 正式值排除、局部刷新/失败/current 行为；这也是 F3-R1 未被发现的原因。 - `test_42` 只对 `finance_income` 覆盖 404/500/schema/future，未落实 V003 第 6/19 节“每个 provider 成功/空/4xx/5xx/schema/future”的表驱动入口矩阵。 - `test_43` 的全点声明只包含无 judgment 的 staging writes、manifest 和一个 rename1 场景；未覆盖 judgment-only `valuation_snapshot.json/valuation_results.json`、每个 replace、第二阶段 receipt/最终 hash、restore/cleanup 组合，以及每个冻结点的 KeyboardInterrupt/SystemExit。`test_44` 也只比对 force 后三文件与无效输入返回码，没有完成 V1 无 force/复跑/force/输入错误的 stdout/stderr/0-2-3 与字节等价矩阵。 - 因此 `46/46 PASS` 不能支持工具/证据文档关于 F2—F5“完整合同已验证”的表述；当前发现均可由冻结范围内离线测试触达，无需新增 provider 或扩展产品范围。 最小 required fixes： 1. 按 V003+V004 已冻结 L1/L3 表补齐非空断言：每 provider 负 fixture、逐 data-kind 入口状态、全部提交故障点与非普通异常、六终态精确 stdout/文件/receipt、V1 直接与 bridge 四路径等价。 2. 让上述测试真正经过入口或被声明验证的 helper；修复 F2—F5 后重跑 V2/V1 及 fixture cold/warm/judgment，并把工具文档、实现证据和执行日志收敛到实际覆盖面。 ### 已关闭与保留结论 - F1=`CLOSED`；F2=`OPEN / F2-R1`；F3=`OPEN / F3-R1`；F4=`OPEN / F4-R1`；F5=`OPEN / F5-R1`；F6=`OPEN / F6-R1`。 - V1 只读 `10/10`、无第二套公式、V006 balance 完整键与精确总额、无 judgment 强制 gap、canonical argparse INPUT_ERROR、真实历史股本诚实 BLOCKED、16 节/无交易指令及既有 evidence 哈希链继续有效，不因本 HOLD 回退。 - 本轮问题均可先由代码与离线测试闭环；无需为这五项重复访问真实网络。若修复实际改变 real BLOCKED 路径，再由开发方在下次提交中明确说明证据等价性，不得擅自新增 provider 或伪造成功。 ### 操作手册条件授权 - 本轮结论为 HOLD，尚不满足管理员的条件单文件授权；不得同步 `outputs/20260730_stock_valuation_guide/股票价格合理性评估操作手册_v1.0.md`。 - 待 F2-R1—F6-R1 全部关闭并取得实现复审 PASS 后，才允许按既有管理员授权只同步该一个文件；同步完成后仍只需一次操作手册单文件限定确认，无需为该确认重跑网络或真实 smoke。 ### Open questions - 无。五个残余问题均已给出冻结范围内的可执行最小闭环；F5 若选择调整 receipt 自引用时序，唯一允许的范围扩展是先提交该点的限定设计 delta。 ### 结论 - 审计状态：`HOLD` - 阻断问题数：`5` - 当前实现不得交最终验收，不得同步操作手册。开发方只需关闭 F2-R1—F6-R1；F1 与其余已通过合同不得回退。完成后提交同一事项的完整限定实现复审。 ## DEV-AUDIT-PROJECT-INFO-STOCK-VALUATION-PIPELINE-V2-DESIGN-V007-RECEIPT-TIMING-DELTA-20260802-001 - 记录时间：`2026-08-02T04:49:57+08:00` - 审核阶段：实现复审 `F5-R1` receipt 自指时序阻断的单点限定方案审核；不是 F2/F3/F4/F6 实现复审。 - 审核对象：`DEV-ANA-STOCK-VALUATION-PIPELINE-V2-20260801-001` - 原生交接：`HANDOFF-INFODEV2-INFOREV-STOCK-VALUATION-PIPELINE-V2-DESIGN-V007-20260802-001`；来源任务 `019fbcbb-bed7-7c90-83ab-f50610f80d3a`。 - 前序结论：`DEV-AUDIT-PROJECT-INFO-STOCK-VALUATION-PIPELINE-V2-IMPLEMENTATION-HOLD6-REREVIEW-20260802-001=HOLD/5`；其中仅 F5-R1 获准提交 receipt 时序限定 delta。 - 执行方：`dev.developer.project.secondary / infodev-2` - 独立审核方：`dev.reviewer.project / inforev` - 审核边界：只审核 V007 对 V004 第 3.3/4 节的 receipt 最终墙钟条款替换；F1、其他已通过合同及 F2/F3/F4/F6 均未重开。本轮未修改或运行代码/测试，未联网，未读取或修改操作手册内容。 ### 冻结快照 - V007：`dev-doc/project-doc/开发方案/CODE-DESIGN-PROJECT-INFO-STOCK-VALUATION-PIPELINE-V2-V007.md`=`7099 bytes / E6216F8986FE5DFB2DC5E8B6F9479A7D234214C5E59B8FEAC165D168B7FC74AC`，与交接一致；strict UTF-8=`PASS`；尾随空白=`0`。 - 继承设计未变：V003=`28030 / 358C37EE1FE7F5F832FAF33EBDEB1B1714DE46F315A55A1C1D53AF43D687C61F`；V004=`12117 / 50DE1F7E765E8B828DEF1C25D6D5BEA32C3C0B07FD034929542AAE0CB4E84799`；V005=`4028 / B4ABD0456BFA0C219C8C2A7A2A92CBE8B40804901A984A69B941A92F87571B6D`；V006=`3278 / 0A997EFB1D8237EB4102E7BAD71BDADE7F0BD2C1178DDAC9F74117254E3FD209`。 - worklog=`4848 bytes / 1C02372D15C7C18CAB49754CEE54B9CEA88FA724C28D9A42A175A531970A4E9A`；执行日志=`98948 bytes / CBFEF3E88BC37DE996F51DA3C7098EFF8E7757B5601CFE996F6510DBBAA7DAFE`；治理校验前像=`OK / projects=1 / warnings=0`。 - F5 现有实现仍为 `workflow.py=22564 bytes / 8ECA6CE2FEDAF8493EDB4BE855EEF6BB1567BA8643553BBB9CF8D7B4387A0074`，证明 V007 PASS 前没有提前实施 receipt 变更。 ### Findings - 无阻断 finding。V007 只修正已确认不可满足的 receipt 自指时序，没有改变正式目录、manifest、receipt 路径、ticker stdout schema、失败包、V1 模式或产品/数据范围。 ### F5-R1 限定方案核验 1. `PASS`：schema 2 receipt 只不可变绑定 run/status/output/manifest、提交准备时点和 receipt 写入开始下界，明确删除 `commit_finished_at/task_wall_seconds/process_wall_seconds`，不再让文件自报自身最终写后时刻，也不引入 receipt hash 自引用、第二次回写或 sidecar。 2. `PASS`：成功 stdout 保持 V004 schema 1；`terminal_at/task_wall_seconds/process_wall_seconds` 在一次 receipt 原子写返回、正式实物重读/hash/stat 校验及 backup cleanup 尝试之后捕获，成为唯一最终墙钟权威。包内 runtime 仍冻结在 `through_commit_ready`，不改写 manifest 已封存文件。 3. `PASS`：receipt temp write/flush/fsync/replace/final read/hash/stat 均属于真正提交边界；absent 不留伪成功，force 恢复旧 output+receipt 并保存次生 rollback 证据。已验证新 receipt 后的 cleanup 失败只保留新真值、剩余 backup 和 warning，不反向回滚。 4. `PASS`：限定测试覆盖最终写和 cleanup 的 `0.25 s` 延迟、每个 receipt 故障点的普通异常/KeyboardInterrupt/SystemExit、三种成功终态、force、hash/bytes 与时间不等式；足以离线证明 F5-R1，无需真实网络。 ### 继承解释与实现门禁 - V007 第 4 节的“FAILED/BLOCKED 失败包”按未被替换的终态矩阵解释：进入成功 receipt 提交阶段后的普通 I/O/校验故障固定为 `FAILED/5`；`KeyboardInterrupt/SystemExit` 原类型传播并保留失败/回滚证据。核心数据不足在更早阶段形成 `BLOCKED/4`，不会进入成功 receipt 写入。 - manifest-last 继续生效。cleanup warning 可写 stderr、外部命令捕获或未被 manifest 封存的审核证据；不得为补 warning 在成功提交后追加改写 OUT 内的 `runtime.log` 或其他 manifest 文件。 - `receipt_write_started_at` 只能解释为写入开始下界；消费者不得把它当完成时刻。最终耗时只能读取 ticker stdout 的 `terminal_at/task_wall_seconds/process_wall_seconds`。 ### 状态与授权 - V007 限定方案结论：`PASS/0`。允许开发方按 V007 第 2—5 节实施一次性 schema 2 receipt、最终 stdout 墙钟、失败恢复和离线故障矩阵，并同步工具说明、实现证据和其有权限的执行记录。 - F5-R1 仅在方案层具备实施授权，尚未在实现层关闭；必须随 F2/F3/F4/F6 离线修复一并提交下一次限定实现复审。 - 本 PASS 不授权真实网络重跑；F5 只需 fixture 与受控延迟/故障桩。也不授权新增 provider、修改 `ana-dev`/V1、扩大产品范围或同步操作手册。 - 操作手册继续 `NOT_AUTHORIZED_WHILE_IMPLEMENTATION_HOLD`；只有全部剩余实现阻断关闭并取得实现 PASS 后，才能使用既有管理员单文件条件授权并接受后续限定确认。 ### Open questions - 无。 ### 结论 - 审计状态：`PASS` - 阻断问题数：`0` - 允许按 V007 开始 F5-R1 实现，并与 F2/F3/F4/F6 的离线闭环一起提交完整限定实现复审；无需真实网络。 ## DEV-AUDIT-PROJECT-INFO-STOCK-VALUATION-PIPELINE-V2-HOLD5-OFFLINE-CLOSURE-REREVIEW-20260802-001 - 记录时间：`2026-08-02T06:25:08+08:00` - 审核阶段：前序实现 `HOLD/5` 的 F2-R1—F6-R1 离线闭环及 V007 实施限定复审。 - 审核对象：`DEV-ANA-STOCK-VALUATION-PIPELINE-V2-20260801-001` - 原生交接：`HANDOFF-INFODEV2-INFOREV-STOCK-VALUATION-PIPELINE-V2-HOLD5-OFFLINE-CLOSURE-20260802-001`；来源任务 `019fbcbb-bed7-7c90-83ab-f50610f80d3a`。 - 前序结论：`DEV-AUDIT-PROJECT-INFO-STOCK-VALUATION-PIPELINE-V2-IMPLEMENTATION-HOLD6-REREVIEW-20260802-001=HOLD/5`；`DEV-AUDIT-PROJECT-INFO-STOCK-VALUATION-PIPELINE-V2-DESIGN-V007-RECEIPT-TIMING-DELTA-20260802-001=PASS/0`。 - 执行方：`dev.developer.project.secondary / infodev-2` - 独立审核方：`dev.reviewer.project / inforev` - 审核边界：只复核 F2-R1—F6-R1 与 V007 实施；F1、V006、V1 只读结论及既有产品范围未重开。本轮未联网、未重跑真实 smoke、未修改实现/测试/fixture/输出或操作手册。 ### 冻结快照与独立验证 - 交接列明的 24 个设计、实现、测试、fixture、文档和记录工件均逐项复算，字节数与 SHA-256 全部匹配；操作手册仍为 `68700 bytes / CCF534DB38F29AFCC61E55FAA47C06829E69E504BDE5CEFF771B10A9AF5AB6E6`，本轮未读取正文。 - 审核员独立运行 V2 离线套件：`55/55 PASS`，`Ran 55 tests in 113.327s / OK`。测试覆盖了交接声明的比较期 A1、逐 kind TTL/MISSING、慢 404/500、receipt schema 2、六终态、12 文件原子边界和 V1 bridge 等矩阵；全绿结果不替代下述未覆盖的内容寻址损坏反例。 - F2-R1 已关闭：上年同期字段绑定 2026 Q1 A1 同响应比较列，structured source、period/publish/support/raw field 和 `same_response_comparative_row` 在 builder 与 QA 双重校验。 - F4-R1 已关闭：HTTPError 4xx/5xx body 使用与 2xx 相同的 remaining deadline、分块读取与取消路径；独立套件中的 0.5 秒 deadline/1.2 秒慢 404、500 均为单请求、无归档和无返回后 cache mutation。 - F5-R1/V007 已关闭：schema 2 receipt 一次写入，写后 read/hash/stat 和 backup cleanup 尝试完成后才捕获 stdout 最终墙钟；receipt 八个边界、普通异常/KeyboardInterrupt/SystemExit、force 恢复和 0.25 秒延迟探针通过。 - F6-R1 已关闭：六终态 exact key/null/file、四类 provider 六种响应、12 文件五个原子边界及 V1 direct/bridge 0/2/3 等价矩阵均由实际入口执行。既有 `valuation-v2-real-smoke-006` 继续是诚实 `BLOCKED/E_HISTORICAL_SHARES_UNPROVEN`；本轮修复不改变该前置终态，无需联网重跑。 ### Findings #### F3-R2 — BLOCKING / 单个 data-kind blob 损坏会击穿整份公司基线，且刷新不能修复被污染的内容寻址对象 - `cache.py:209-224` 的 `_baseline_valid` 在选择候选基线前遍历并读取全部 `source_hashes`；任意一个 blob 缺失或哈希错误就让 `select_baseline` 丢弃整个候选。随后 `baseline_states` 无法逐 kind 判定，所有十类数据统一变成 `MISSING`。这违反 V004 的逐 `data_kind` hash predicate，以及 F3-R1“只有 STALE/MISSING kind 运输、其余 FRESH 从公司基线复用”的合同。 - 审核员使用临时目录完成入口级反例：先由冻结 fixture 生成合法 cold 基线，只把 `market_close.raw_hash` 指向的一个 blob 改为不同 bytes；随后 `selected_after_one_blob_tamper=false`，十类状态均为 `MISSING`，refresh 实际运输 `10` 类而不是 `1` 类。现有 `test_31` 只通过改 TTL 或删除 metadata entry 构造 STALE/MISSING，没有覆盖 blob 缺失/哈希损坏，所以 `55/55 PASS` 未发现该退化。 - `cache.py:151-165` 的 `store` 仅在 digest 路径不存在时写 blob；若该内容寻址路径已存在但内容哈希错误，重新取得正确响应也不会覆盖/隔离坏对象。独立反例中的 refresh 虽返回 `DATA_READY_NEEDS_JUDGMENT`，目标 blob 仍保持错误哈希，刷新后的候选仍无法被选择，十类状态继续全部 `MISSING`。因此污染会跨运行持续，不能由一次成功局部刷新闭环。 最小 required fixes： 1. 将 baseline envelope/data_hash 校验与逐 kind blob 校验分开：单个 entry 的 blob 缺失或哈希错误只把对应 `data_kind` 判为 `STALE`（无 entry 才为 `MISSING`），不得使其余通过 provider/fingerprint/date/schema/semantic/hash 校验的 kind 一并失效；STALE 值仍禁止进入正式结果。 2. `ContentCache.store` 遇到目标 digest 路径已存在时必须复算实物哈希；不一致时以安全原子方式修复或隔离坏对象后写入正确 bytes，不能因 `exists()` 跳过。写后需复验 digest，失败不得提升 reusable 或推进 company current。 3. 增加入口级非空回归：对每个 data-kind 分别删除/篡改其 blob，断言仅目标 kind 运输、其余九类从公司基线复用；成功刷新后十类全为 FRESH、blob/source hashes 可复算，失败刷新仍不推进 current/活动基线。同步纠正实现证据、执行日志和 worklog 中“十类 hash 失败也已逐类闭环”的过度声明。 ### 已关闭与保留结论 - F2-R1=`CLOSED`；F3=`OPEN / F3-R2`；F4-R1=`CLOSED`；F5-R1/V007=`CLOSED`；F6-R1=`CLOSED`。 - F1、V006、V1 只读、历史股本诚实 BLOCKED、无 judgment、16 节、无交易指令和范围排除继续保持，不因本次 HOLD 回退。 - F3-R2 可完全通过缓存代码、离线 fixture/故障测试与文档更正闭环；不需要真实网络，不授权新增 provider、修改 V1/`ana-dev` 或扩展产品范围。 ### 操作手册条件授权 - 本轮结论仍为 `HOLD`，尚不满足管理员的条件单文件授权；不得同步 `outputs/20260730_stock_valuation_guide/股票价格合理性评估操作手册_v1.0.md`。 - F3-R2 关闭并取得限定实现复审 `PASS` 后，才允许使用既有管理员授权只同步该一个文件；同步后只需操作手册单文件限定确认，无需重跑网络。 ### Open questions - 无。唯一剩余阻断已有冻结范围内的确定复现与最小闭环路径。 ### 结论 - 审计状态：`HOLD` - 阻断问题数：`1` - F2-R1、F4-R1、F5-R1/V007、F6-R1 已关闭；当前只需关闭 F3-R2。不得同步操作手册；修复后提交同一事项的 F3-R2-only 限定实现复审，无需真实网络。 ## DEV-AUDIT-PROJECT-INFO-STOCK-VALUATION-PIPELINE-V2-F3-R2-ONLY-REREVIEW-20260802-001 - 记录时间：`2026-08-02T06:55:46+08:00` - 审核阶段：前序唯一阻断 `F3-R2` 的限定实现复审。 - 审核对象：`DEV-ANA-STOCK-VALUATION-PIPELINE-V2-20260801-001` - 原生交接：`HANDOFF-INFODEV2-INFOREV-STOCK-VALUATION-PIPELINE-V2-F3-R2-ONLY-20260802-001`；来源任务 `019fbcbb-bed7-7c90-83ab-f50610f80d3a`。 - 前序结论：`DEV-AUDIT-PROJECT-INFO-STOCK-VALUATION-PIPELINE-V2-HOLD5-OFFLINE-CLOSURE-REREVIEW-20260802-001=HOLD/1`。 - 执行方：`dev.developer.project.secondary / infodev-2` - 独立审核方：`dev.reviewer.project / inforev` - 审核边界：只复审 F3-R2；F2-R1、F4-R1、F5-R1/V007、F6-R1 维持关闭，F1、V006、V1/`ana-dev` 只读结论及产品范围未重开。本轮未访问真实网络、未重跑 real smoke、未读取或修改操作手册正文，未修改受审代码、测试、fixture 或项目说明。 ### 冻结快照与独立验证 - 交接列明的七个变更文件均逐项复算并匹配字节数/SHA-256：`cache.py=16558/FAC33193549DCD800FF94FB732449216A9F2D5A40F2F6073897787F84E2DAD46`，`test_pipeline_v2.py=83792/9734C2E74C2A24BE5A3D4665080F141A4AB15FF29244CFED292868A95EDA7AAD`，工具文档=`11348/E1AF3895D568D5E5B8B08B58225AB3DD77E0263640568676E75068A2F8B8837F`，实现证据=`14105/27D7264F31206F41798B3A7CFC51B9A7EDF321CD53D1128200EAA6F503C5A36D`，目录导读=`4274/4DF1415F08EF3FBB308CE86AD5297431B3EFA2765ABE084335B299459416CDCC`，worklog=`7303/16829F9D00FDD6291F3AF1CAB5EDC6D8DEA338184B8A281DE1B93AEECC50A27B`，执行日志=`103967/CA12F771715553BDB129CE98D0D240D73B7713BDC6A07BB90CC68AC0666EB2E6`。 - 操作手册仍为 `68700 bytes / CCF534DB38F29AFCC61E55FAA47C06829E69E504BDE5CEFF771B10A9AF5AB6E6`，与前序冻结值一致。 - 审核员独立运行新增聚焦用例：`2/2 PASS / Ran 2 tests in 16.278s`；独立运行 V2 全套离线测试：`57/57 PASS / Ran 57 tests in 127.851s / OK`。这些结果证明成功修复路径，但现有失败用例只覆盖核心 `market_close`，未覆盖同一修复失败在非核心 forecast 降级路径中的基线副作用。 - `cache.py:151-199` 已在已有 digest 路径复算实物 SHA-256、必要时原子重写并写后复验；`cache.py:220-383` 已把 envelope/data_hash 与逐 kind blob 校验分开。`test_56` 的十类删除/篡改成功矩阵证明仅目标 kind 运输、其余九类 FRESH、刷新后 10/10 FRESH，F3-R2 的成功路径已经闭环。 ### Findings #### F3-R2-R1 — BLOCKING / 非核心 blob 修复失败仍提交新 company current/活动基线 - `test_57_blob_repair_failure_does_not_promote_or_advance_baseline` 只向核心 `market_close` 注入 blob 原子修复失败。核心 provider 异常会令运行 BLOCKED，因而测试虽断言 current/活动基线不变，却没有覆盖 forecast 非核心降级分支，也不能证明交接和文档所称“修复/复验失败均不推进 current/活动基线”。 - `acquisition.py:39,77` 将 forecast provider 异常固定降级为非 blocking `GAP`；`workflow.py:443` 随后不区分普通预测缺口与内容寻址 blob 完整性修复失败，仍无条件执行 `cache.write_baseline(...)`。因此 `ContentCache.store` 虽正确阻止目标 raw/reusable 提升，company baseline 的提交门仍未闭合。 - 审核员入口级离线反例：先形成合法 cold 基线，仅篡改 `forecast_detail` blob 并移除其 reusable index，再只对目标 blob 的 repair `atomic_write` 注入失败。结果为 `code=0 / status=DATA_READY_NEEDS_JUDGMENT / output_exists=true / reusable_exists=false / blob_still_corrupt=true`，但 `current_changed=true`，活动基线由 `2026-08-01-2562051e84009218e4b6ca8cf03522d19e16663483f2e00f9898b5401c090da8.json` 替换为 `2026-08-01-d5b82c2a2b120ffdc241e94267e90c1f20b91425ef5b6981a72f27ec0517c015.json`。这直接违反前序 required fix 2/3 和本次交接第 2/3 项的“修复/复验失败不推进 current/活动基线”。 - 工具文档第 117 行、实现与验收证据第 36/93 行、worklog 第 43 行及执行日志第 851 行均把核心单例测试结果泛化为所有 data-kind 的修复失败保证；在非核心反例存在时属于过度声明。 最小 required fixes： 1. 在缓存/采集/工作流之间保留“内容寻址 blob 修复或写后复验失败”的可判定信号；`workflow.py` 提交 company baseline/current 前若本次任何 data-kind 出现该类完整性失败，必须跳过 `write_baseline`，无论该 provider 在产品语义上属于核心阻断还是非核心 gap。核心仍可 BLOCKED；forecast 仍可按冻结合同返回带 gap 的成功输出，但不得新建、替换或归档活动 company baseline/current。 2. 增加真实入口故障回归，至少分别覆盖一个核心 kind 和一个 forecast 非核心 kind，并覆盖 repair 写失败与写后 read/hash 复验失败：断言目标 reusable 不存在，修复失败对象不被当作健康值，`current.json` 字节和活动基线完整集合均保持不变。非核心场景若按合同保留成功/gap 输出，可允许正式输出存在，但不得据此推进 company baseline。 3. 将工具文档、实现与验收证据、worklog 和执行日志中“修复失败均不推进 current/活动基线”的表述收敛到实际实现和上述非核心入口证据；完成后只提交 `F3-R2-R1-only` 限定复审。 ### 已关闭与保留结论 - F2-R1=`CLOSED`；F3=`OPEN / F3-R2-R1`；F4-R1=`CLOSED`；F5-R1/V007=`CLOSED`；F6-R1=`CLOSED`。F3-R2 的 envelope/逐 kind 隔离、已有 digest 安全修复以及十类成功矩阵继续有效，不因本次 HOLD 回退。 - 修复与验证均可离线完成；无需真实网络或 real smoke，不授权新增 provider、修改 V1/`ana-dev`、修改冻结产品语义或扩展范围。 ### 操作手册条件授权 - 本轮为 `HOLD`，不得使用管理员既有条件授权同步操作手册。 - 仅当 F3-R2-R1 关闭并取得限定实现复审 `PASS` 后，才允许只同步既有授权指定的唯一操作手册文件；同步后仅需该单文件限定确认，无需网络重跑。 ### Open questions - 无。唯一剩余问题已由冻结范围内的非核心入口反例确定复现，并给出最小离线闭环路径。 ### 结论 - 审计状态：`HOLD` - 阻断问题数：`1` - 仅 F3-R2-R1 未关闭；开发方完成上述三项最小修复后提交 `F3-R2-R1-only` 限定实现复审。当前不得同步操作手册，无需真实网络重跑。 ## DEV-AUDIT-PROJECT-INFO-STOCK-VALUATION-PIPELINE-V2-F3-R2-R1-ONLY-REREVIEW-20260802-001 - 记录时间：`2026-08-02T07:39:50+08:00` - 审核阶段：前序唯一阻断 `F3-R2-R1` 的限定实现复审。 - 审核对象：`DEV-ANA-STOCK-VALUATION-PIPELINE-V2-20260801-001` - 原生交接：`HANDOFF-INFODEV2-INFOREV-STOCK-VALUATION-PIPELINE-V2-F3-R2-R1-ONLY-20260802-001`；来源任务 `019fbcbb-bed7-7c90-83ab-f50610f80d3a`。 - 前序结论：`DEV-AUDIT-PROJECT-INFO-STOCK-VALUATION-PIPELINE-V2-F3-R2-ONLY-REREVIEW-20260802-001=HOLD/1`，审计文件前序冻结值=`140865 bytes / EB3898F146200A7AE6536503E36D4AA323EC44E9BD1815541D4EE2F850023C12`。 - 执行方：`dev.developer.project.secondary / infodev-2` - 独立审核方：`dev.reviewer.project / inforev` - 审核边界：只复审 F3-R2-R1；F3-R2 的成功路径以及 F2-R1、F4-R1、F5-R1/V007、F6-R1 继续冻结，F1、V006、V1/`ana-dev` 只读结论和产品范围未重开。本轮未访问真实网络、未重跑 real smoke、未读取或修改操作手册正文，未修改受审代码、测试、fixture、执行日志或项目说明。 ### 冻结快照 - 交接列明的十个变更文件均逐项复算并匹配字节数/SHA-256：`cache.py=17353/84E0AE46C4A3E3AFFC495D4328D82C0CB59C62E2CAA1396A11EFCB05E357E6F0`，`acquisition.py=5344/BA693F152A5AEDB6EB5A525398EA5D1D2E97431C0FBA67BCD44078F0006E2C4B`，`providers.py=35661/90749F6596483CF7DB5DC861A108146D1716580BDE89038E3C28044275EDAACB`，`workflow.py=24131/36F958758A5DBA168B68334C6F3D715268C57188E1E2F7A009A49B36F8DEB11D`，测试=`89292/E45672F51D2F84ECC33AFE3EC25EFF384BE31FCAE6CD8A626A185152787106DC`，工具文档=`11630/A8DBCDD010512A37E691A012183BAE10005F9D2F1A3DABD9D8D87048B2A99BAF`，实现证据=`14355/8CE7343CC50C6EF7864888EEE573DEA483C29225B19A248159D99FA0BEF1D214`，目录导读=`4262/C2415C6DD59B0578499C8B7EE88ED4B84E66958F72FF8C78702DD8328C992B2D`，worklog=`8111/A240AFA0F5A5C40D2FEE68205EEE07E556703278A20945B4962AB5FF893061E4`，执行日志=`105925/FE351CF19A6AE7BCBAAF8A3FA51A9140E0DC273328521FED11596235A1DA9246`。 - 操作手册仅复算实物，仍为 `68700 bytes / CCF534DB38F29AFCC61E55FAA47C06829E69E504BDE5CEFF771B10A9AF5AB6E6`；本轮没有读取正文或执行同步。 ### F3-R2-R1 闭环核验 1. `PASS`：`cache.py:82,155-187` 新增 `BlobIntegrityError`；已有 digest 对象的 repair 原子写失败和写后 read/hash 不一致均在 raw-index/reusable 提升之前成为明确的内容完整性失败，不再退化为不可区分的普通 provider 缺口。 2. `PASS`：`acquisition.py:39-65` 对线程外抛的 `BlobIntegrityError` 保留 `cache_integrity_failure=true`；`providers.py:793-825` 对 forecast-detail 内部允许降级的异常也单独保留同一信号。因此普通 forecast coverage gap 继续为非阻断缺口，内容对象完整性失败则具有独立提交语义。 3. `PASS`：`workflow.py:443-455` 在调用 `write_baseline` 前同时要求所有 provider 均无 `cache_integrity_failure`，并要求十类 data-kind 条目集合完整且其 `raw_hash` 对应实物全部复算可信。任一核心或非核心完整性失败均跳过 company baseline/current 提交；forecast 仍可按冻结合同保留带 gap 的成功正式输出。 4. `PASS`：`test_57`、`test_58`、`test_59` 从真实入口分别覆盖核心 `market_close` 与非核心 `forecast_detail` 的 repair 写失败和原子写返回后哈希不一致。每例断言目标 reusable 不存在、current 字节与完整活动基线文件集合不变；非核心场景保持 `DATA_READY_NEEDS_JUDGMENT` 并保存 `cache_integrity_failure=true`，核心场景保持诚实 BLOCKED 且无正式输出。原 F3-R2-R1 反例不能再复现。 5. `PASS`：工具文档、实现与验收证据、worklog 和开发执行日志已区分普通 forecast coverage gap 与 cache integrity failure，且只声明实际入口矩阵已经证明的 baseline/current 行为；没有继续保留前序过度声明。 ### 独立执行结果 - F3-R2-R1 聚焦入口：`3/3 PASS / Ran 3 tests in 3.256s / OK`。 - V2 完整离线回归：`59/59 PASS / Ran 59 tests in 131.288s / OK`；`test_36` 只出现冻结的 cleanup warning，测试本身通过。 - V1 只读回归：`10/10 PASS / Ran 10 tests in 0.164s / OK`。 - CLI help=`PASS`；五个变更 Python 文件 strict UTF-8 与只读 `compile(...)`=`PASS`；十个变更文件行尾空白=`0`。 - 治理校验：`mbx validate --project project-info --governance=OK / projects=1 / warnings=0`。 - `fixture-004` 与 `real-smoke-006` 仅保持前序冻结事实；本轮离线修复不改变真实 smoke 的诚实 `BLOCKED/E_HISTORICAL_SHARES_UNPROVEN`，故没有依据要求网络重跑。 ### Findings - 无阻断 finding。F3-R2-R1 已按前序三项最小 required fixes 完整关闭，没有新增审核范围。 ### 已关闭与保留结论 - F2-R1=`CLOSED`；F3-R2-R1=`CLOSED`，因此 F3=`CLOSED`；F4-R1=`CLOSED`；F5-R1/V007=`CLOSED`；F6-R1=`CLOSED`。 - F1、V006、V1 只读桥接、无 judgment 终态、16 节、无交易指令、未来信息保护、历史股本诚实 BLOCKED 和既有真实证据限制继续保持；本次 PASS 不把 real-smoke-006 改写为成功 smoke。 ### 操作手册条件授权 - 本轮实现复审已取得 `PASS/0`，满足项目管理员既有条件单文件授权的触发条件。允许开发方只同步 `outputs/20260730_stock_valuation_guide/股票价格合理性评估操作手册_v1.0.md`；不得借此修改其他 `outputs`、provider、V1/`ana-dev`、代码、测试或产品范围。 - 同步完成后只需向本审核任务提交该操作手册单文件限定确认，列明同步前后 bytes/SHA-256、实际差异、UTF-8/行尾与相关文档链接一致性；无需重跑真实网络、fixture、V2/V1 全套或既有 smoke。 ### Open questions - 无。 ### 结论 - 审计状态：`PASS` - 阻断问题数：`0` - F3-R2-R1 关闭；允许按管理员既有条件授权只同步唯一操作手册文件。同步后提交单文件限定确认即可，无需网络重跑。 ## DEV-AUDIT-PROJECT-INFO-STOCK-VALUATION-PIPELINE-V2-OPERATION-MANUAL-SINGLE-FILE-CONFIRMATION-20260802-001 - 记录时间：`2026-08-02T08:02:30+08:00` - 审核阶段：最终实现 `PASS/0` 后的操作手册单文件限定确认。 - 审核对象：`DEV-ANA-STOCK-VALUATION-PIPELINE-V2-20260801-001` - 原生交接：`HANDOFF-INFODEV2-INFOREV-STOCK-VALUATION-PIPELINE-V2-OPERATION-MANUAL-SYNC-20260802-001`；来源任务 `019fbcbb-bed7-7c90-83ab-f50610f80d3a`。 - 前序依据：`DEV-AUDIT-PROJECT-INFO-STOCK-VALUATION-PIPELINE-V2-F3-R2-R1-ONLY-REREVIEW-20260802-001=PASS/0`，前序审计文件=`146931 bytes / E2E4F0BB85F09056874DFDD14EC55E593AF1B4D38CCDB0B0224A28577C331D7B`。 - 执行方：`dev.developer.project.secondary / infodev-2` - 独立确认方：`dev.reviewer.project / inforev` - 限定边界：只检查 `outputs/20260730_stock_valuation_guide/股票价格合理性评估操作手册_v1.0.md` 的实物、唯一差异、新增章节、编码/行尾和三个本地链接。本轮未重开实现、网络、provider、V1/`ana-dev`、fixture、smoke 或其他 `outputs`，未运行 V2/V1 测试，未修改受审操作手册或其他正式产物。 ### 单文件实物与差异 - 同步前冻结值：`68700 bytes / CCF534DB38F29AFCC61E55FAA47C06829E69E504BDE5CEFF771B10A9AF5AB6E6`。 - 同步后复算值：`74401 bytes / 89FF988050A6148755F4B95DF95171DCE7439AD015094561690195B992636CA7`，与交接完全一致；strict UTF-8=`PASS`，无 BOM，全文件统一 LF。 - 新增章节的实际标题为 `## 三十一、端到端协调层 V2`，位于当前文件第 1949—2012 行，共 64 行、5701 bytes。删除该完整插入块后，重建文件精确恢复为 `68700 bytes / CCF534DB38F29AFCC61E55FAA47C06829E69E504BDE5CEFF771B10A9AF5AB6E6`，从字节层证明旧章节未被改写。 - 新增 64 行的行尾空白=`0`；全文件仅第 3、4、5 行存在三处历史行尾空白。因重建前版哈希完全一致，可确认这三处在同步前已经存在且本次未改变。 - 以 `2026-08-02T07:40:00+08:00` 为本次同步窗口起点只读扫描 `outputs/`，窗口内仅该操作手册一个文件发生修改；没有发现其他 `outputs` 同步。 ### 内容与链接一致性 1. `PASS`：新增章节准确说明 project 级 V2、只读 V1 bridge、`ticker + as-of` CLI、`--judgment` 门禁、无 judgment 的 `DATA_READY_NEEDS_JUDGMENT` 和 V1 `--input` 兼容；未把数据就绪状态写成方向结论。 2. `PASS`：登记公开来源、字段级 A1/raw-hash 回链、上海 as-of、14 日 K 线窗口、历史股本诚实 BLOCKED、4 汇总/3 明细有界 gap 和共享 90 秒 deadline 与已通过工具说明一致。 3. `PASS`：十类 `FRESH/STALE/MISSING`、单 blob 损坏隔离、原子 repair/写后复验，以及任一完整性失败禁止推进 company current/活动基线的表述，与 F3-R2/F3-R2-R1 最终实现审计一致。 4. `PASS`：六终态/退出码、正式包、manifest、schema 2 receipt、stdout 最终 task/process 双墙钟，以及 fixture 冷/热目标、V2 `59/59`、V1 `10/10` 和 real-smoke-006 的 `E_HISTORICAL_SHARES_UNPROVEN` 限制均未夸大为真实成功验收。 5. `PASS`：章节明确不输出交易指令，也没有新增 provider、操作步骤或产品承诺。 6. `PASS`：三个相对链接均从操作手册目录正确解析且实物存在：`../../dev-doc/project-doc/股票估值端到端协调层V2.md`=`11630 bytes`，`../../dev-doc/project-doc/股票估值端到端协调层V2实现与验收证据.md`=`14355 bytes`，`../../dev/project-dev/stock_valuation_pipeline_v2/README.md`=`1445 bytes`。 ### Findings - 无阻断 finding。同步严格限于管理员已授权的唯一操作手册文件，内容与最终 `PASS/0` 实现及其限制一致。 ### Open questions - 无。 ### 结论 - 审计状态：`PASS` - 阻断问题数：`0` - 操作手册单文件同步确认完成；无需重跑网络、fixture、V2/V1 测试或 smoke。本事项的开发审核与授权后单文件确认链已闭环。