| | |
|---|
| | | - 摘要：角色 case_analysis.meeting_minutes_processor 已生成或刷新 AI 工作说明。 |
|---|
| | | - 详情： |
|---|
| | | - 角色：case_analysis.meeting_minutes_processor / 体系：case_analysis / AI：meeting-minutes / 私有空间：ai-meeting-minutes / 工作目录：. / 写范围：ana-doc/会议纪要,ana-data,ai-meeting-minutes |
|---|
| | | |
|---|
| | | ## 2026-08-04 `PROJECT-INFO-NEWENERGY-AND-VIDEO-DOWNLOADER-INIT-20260804-001` 最小计划 |
|---|
| | | |
|---|
| | | 1. 建立 `ana-doc/新能源案例/`、四个数据根和轻量行业模板。 |
|---|
| | | 2. 创建新能源调研、审核两个独立 Codex 任务并登记角色、权限和工作空间。 |
|---|
| | | 3. 创建视频下载员 Codex 任务，登记下载、校验、manifest、访问控制停止边界和与视频处理员的职责分离。 |
|---|
| | | 4. 同步 `mbx.project.yaml`、`项目配置清单.md`、父级目录导读、执行日志和变更记录。 |
|---|
| | | 5. 运行机器/人工配置一致性、UTF-8、YAML、目录和治理校验；三个新任务完成首次阅读即可关闭。 |
|---|
| | | |
|---|
| | | 计划口径：普通可逆初始化直接执行，不另设计划审计、执行授权或逐动作审核。 |
|---|
| | | |
|---|
| | | ## 2026-08-07 `DESIGN-CASE-INDUSTRY-CANONICAL-RESULT-MIGRATION-L2-20260807-001` 统一设计 |
|---|
| | | |
|---|
| | | ### 1. 标识、角色与阶段门 |
|---|
| | | |
|---|
| | | - task_id：`TASK-CASE-INDUSTRY-CANONICAL-RESULT-MIGRATION-20260807-001` |
|---|
| | | - change_id：`CHANGE-CASE-INDUSTRY-CANONICAL-RESULT-MIGRATION-L2-20260807-001` |
|---|
| | | - 风险等级：`L2` |
|---|
| | | - 设计 owner：`project.admin` |
|---|
| | | - 合并独立设计 reviewer：`case_analysis.reviewer` |
|---|
| | | - 设计状态：`FROZEN_PENDING_ONE_CONSOLIDATED_INDEPENDENT_REVIEW` |
|---|
| | | - 设计 PASS 前：只允许只读盘点、hash/路径基线、迁移映射草案和同链设计修订；禁止修改母版、建立正式稳定入口、发布、移动、重命名或删除成果 |
|---|
| | | - 设计 PASS 后：先执行军工、新能源试点；每个行业的正式发布仍须引用该行业既有独立执行/输出审核 PASS，不由本 L2 设计审核替代 |
|---|
| | | |
|---|
| | | ### 2. 行业根统一目录合同 |
|---|
| | | |
|---|
| | | ```text |
|---|
| | | ana-data/cases/<行业>案例/ |
|---|
| | | ├─ 当前成果索引.md |
|---|
| | | ├─ 核心文档/ |
|---|
| | | ├─ raw|converted|extracted|supplement|evidence/ |
|---|
| | | ├─ manifest/ |
|---|
| | | │ ├─ current_output_manifest.csv |
|---|
| | | │ ├─ promotion_ledger.csv |
|---|
| | | │ └─ legacy_case_path_map.csv |
|---|
| | | └─ 审计包/ |
|---|
| | | └─ <case_id>/<batch_id>/<run_id>/ |
|---|
| | | |
|---|
| | | ana-data/result/<行业>案例/ |
|---|
| | | └─ 当前成果索引.md |
|---|
| | | ``` |
|---|
| | | |
|---|
| | | 1. `当前成果索引.md` 是行业默认阅读入口，只引用最近独立审核接受的成果，必须写明 audit ID、内容截止时间、覆盖边界、未解决缺口和审计包入口。 |
|---|
| | | 2. `核心文档/` 是行业唯一稳定人读成果树；草稿、待审文件和活跃批次不得写入。 |
|---|
| | | 3. `审计包/<case_id>/<batch_id>/<run_id>/` 保存逐次输入、输出、证据、manifest、验收与旧版本快照，不作为普通阅读入口；旧审计血缘、路径与哈希必须可追溯。 |
|---|
| | | 4. `promotion_ledger.csv` append-only 记录 task/case/batch/run/audit、旧/新路径与 SHA-256、发布时间、操作者和回滚入口；`current_output_manifest.csv` 冻结当前核心文档 exact-set/hash；`legacy_case_path_map.csv` 记录旧逐案例路径迁移映射。 |
|---|
| | | 5. 同一行业整体研究使用长期 case 标识作元数据血缘，新增内容使用 batch/run；不得再创建用户可见的批次型稳定 case 入口。正式入口直接位于行业根，不增加 `<stable_case_id>/outputs/` 中间层。 |
|---|
| | | |
|---|
| | | ### 3. 发布与迁移合同 |
|---|
| | | |
|---|
| | | 1. 草稿先进入临时或审计过程包；独立执行/输出审核 PASS 前不得更改行业根 `核心文档/`、两份 `当前成果索引.md` 或发布账本。 |
|---|
| | | 2. PASS 后只按送审 exact-set/hash 发布；该 L0 同步不改变结论，不重复送审。任何 hash 漂移均 fail closed。 |
|---|
| | | 3. 更新稳定文件时先保存旧版本至审计包并写发布账本；发布采用 staged/CreateNew、相对链接、manifest FK 与可回滚校验，禁止无快照覆盖。 |
|---|
| | | 4. 旧逐案例目录只有在 exact-set、SHA-256、相对链接、result 跳转、manifest、审计引用、UTF-8/U+FFFD 和治理全部通过后才可收敛到 `审计包/legacy/`；无静默删除，历史审计文本不追溯改写。 |
|---|
| | | 5. 母版实施范围为 `ana-doc/案例分析规范.md`、`ana-doc/案例存储体系.md`、`ana-doc/目录导读.md` 及五行业必要导读/存储/方案入口；本设计审核 PASS 前不修改这些规范。 |
|---|
| | | |
|---|
| | | ### 4. 分行业责任与执行顺序 |
|---|
| | | |
|---|
| | | | 阶段 | 行业 | 实施责任人 | 既有独立审核 | 首个允许候选基线 | 当前硬边界 | |
|---|
| | | |---|---|---|---|---|---| |
|---|
| | | | 试点 1 | 军工 | `case_analysis.analyst.defense` | `case_analysis.reviewer.defense` | BATCH-033 已接受累计成果 | BATCH-034 未 PASS 前不发布、不移动；§38 沿原设计链改行业根，不建 `ANA-DEFENSE-INDUSTRY-001/outputs/` 稳定入口 | |
|---|
| | | | 试点 1 | 新能源 | `case_analysis.analyst.new_energy` | `case_analysis.reviewer.new_energy` | BATCH-001 已接受成果 | BATCH-002 未 PASS 前不发布、不移动，不把 DRAFT 写入行业根 | |
|---|
| | | | 阶段 2 | 半导体 | `case_analysis.analyst.cai` | `case_analysis.reviewer.cai` | 执行前只读确认最近接受版本 | 不以本设计替代行业执行/输出审核 | |
|---|
| | | | 阶段 2 | 机器人 | `case_analysis.analyst` | `case_analysis.reviewer` | 执行前只读确认最近接受版本 | 不以本设计替代行业执行/输出审核 | |
|---|
| | | | 阶段 2 | 有色 | `case_analysis.analyst` | `case_analysis.reviewer` | 执行前只读确认最近接受版本 | 不以本设计替代行业执行/输出审核 | |
|---|
| | | |
|---|
| | | ### 5. 军工既有 §38 同链纠错 |
|---|
| | | |
|---|
| | | `TASK-DEFENSE-DOCUMENT-GOVERNANCE-REORGANIZATION-20260807-001 / DESIGN-ANA-DEFENSE-DOCUMENT-GOVERNANCE-REORGANIZATION-20260807-001` 保留原登记历史，但原 `ana-data/cases/军工案例/ANA-DEFENSE-INDUSTRY-001/outputs/核心文档/` 与稳定 result case 根目标暂停。军工 owner 必须在同一 §38 设计链追加 D02 修订：正式入口改为 `ana-data/cases/军工案例/当前成果索引.md + 核心文档/ + 审计包/ + manifest/`，result 入口改为 `ana-data/result/军工案例/当前成果索引.md`；`ANA-DEFENSE-INDUSTRY-001` 仅可保留为长期 case 元数据/审计血缘，不得成为第二套用户入口。旧 34 包只读，297 份误放文档与活跃 BATCH-034 均不移动。 |
|---|
| | | |
|---|
| | | ### 6. 验收 |
|---|
| | | |
|---|
| | | - 五行业各只有一套行业根正式入口；草稿污染 `0`，重复稳定入口 `0`。 |
|---|
| | | - 当前索引、核心文档、审计包和发布账本可双向追溯；迁移 exact-set/hash 或逐文件合并/重命名映射闭合。 |
|---|
| | | - 相对链接、result 跳转、manifest FK、audit ID、UTF-8/U+FFFD、scoped diff 与 governance 全部 PASS。 |
|---|
| | | - 活跃链未通过前不发布、不移动；母版设计一次给全问题，真实 blocker 只做同链聚焦修订，不新增管理或平行审核层。 |
|---|
| | | |
|---|
| | | 计划状态：`FROZEN_PENDING_ONE_CONSOLIDATED_INDEPENDENT_DESIGN_REVIEW`。 |
|---|
| | | |
|---|
| | | ### 7. 合并独立设计审核路由纠错 |
|---|
| | | |
|---|
| | | 原 `case_analysis.reviewer / laoshen` 的机器配置 session 当前无法由 Codex 原生任务工具定位，且没有接收本 design。为保持单一、可执行的独立审核链，本 design 的唯一合并 reviewer 改为 `case_analysis.reviewer.cai / laoshen-cai / 019f8061-4d57-7a80-be13-d0a34c16287b`，计划 audit ID 仍为 `AUDIT-CASE-INDUSTRY-CANONICAL-RESULT-MIGRATION-L2-DESIGN-20260807-001`。该纠错只替换未送达的审核路由，不改变目录、发布、迁移、角色实施、活跃链冻结或行业既有执行/输出审核合同，也不形成复审或平行审核层。 |
|---|
| | | |
|---|
| | | 计划状态：`FROZEN_PENDING_ONE_CONSOLIDATED_INDEPENDENT_REVIEW_BY_CASE_ANALYSIS_REVIEWER_CAI`。 |
|---|
| | | |
|---|
| | | ### 8. HOLD/2 同链聚焦修订：原子发布与中断恢复状态机 |
|---|
| | | |
|---|
| | | - source audit：`AUDIT-CASE-INDUSTRY-CANONICAL-RESULT-MIGRATION-L2-DESIGN-20260807-001=HOLD/2/2` |
|---|
| | | - 本节只修复 `BLOCK-CANONICAL-MIGRATION-DESIGN-01_PUBLICATION_COMMIT_AND_ROLLBACK_NOT_TOTAL`；第 2—7 节已通过的行业根结构、角色分工、唯一 reviewer 路由、行业既有审核前提和 BATCH-034/BATCH-002 冻结全部保持不变。 |
|---|
| | | |
|---|
| | | #### 8.1 唯一 release 身份与无自引用哈希域 |
|---|
| | | |
|---|
| | | 1. 每次行业发布只能有一个 `release_id`。它是 `industry + task_id + case_id + batch_id + run_id + accepted_audit_id` 规范 UTF-8 序列的 SHA-256，不包含任何由 `release_id` 反向影响的 candidate 文件 hash；ledger/receipt 再把该 `release_id` 与唯一 `candidate_release_set_sha256` 绑定。同一身份和同一 hash 重跑必须幂等返回，身份相同但 hash 不同或 hash 相同但身份不同均 fail closed。 |
|---|
| | | 2. candidate release set 必须逐项冻结相对路径、类型、bytes 和 SHA-256，覆盖且只覆盖：cases 行业根 `当前成果索引.md`、`核心文档/` 当前候选代的全部普通非 reparse 文件、result 行业根 `当前成果索引.md`、`manifest/current_output_manifest.csv`。cases 索引必须内嵌当前 `release_id`。result 索引冻结为不随 release 改写的薄入口，其唯一内容合同是相对跳转 cases 索引并声明“cases 索引不存在或未闭合时无正式当前成果”；它以固定 bytes/hash 纳入每次 candidate exact-set，但不复制 release 元数据、不形成第二套正文，因此 release 切换只需要一个可变用户入口 commit point。 |
|---|
| | | 3. `current_output_manifest.csv` 枚举两份索引和候选核心文档，不枚举自身；审计包内 `release_receipt.json` 记录该 manifest 自身 bytes/SHA-256，并对“manifest 枚举域 + manifest 自身”计算唯一 `candidate_release_set_sha256`，从而闭合 current manifest 又避免自引用 hash 环。 |
|---|
| | | 4. `promotion_ledger.csv` 是 append-only 事务事件账本，明确排除在 candidate release set 之外；每行仍必须保存 `release_id/event_seq/state/prior_release_id/prior_release_set_sha256/candidate_release_set_sha256/task/case/batch/run/audit/operator/event_time/recovery_or_rollback_receipt`，不得覆盖、删除或改写既有行。 |
|---|
| | | |
|---|
| | | #### 8.2 状态、锁与唯一 commit point |
|---|
| | | |
|---|
| | | 1. 唯一状态集合冻结为 `PREPARED -> VERIFIED -> COMMITTING -> COMMITTED`；失败/恢复只允许 `ABORTED / RECOVERY_REQUIRED / ROLLING_BACK / ROLLED_BACK`。每次状态迁移先以 CreateNew 写审计包事务记录、close/flush 后再 append 一行 ledger；未知状态、跳级或同一 `event_seq` 重复立即停止。 |
|---|
| | | 2. 每个行业同一时刻只允许一个发布者持有 `manifest/.promotion.lock`。锁以 CreateNew 建立并记录 `release_id/operator/process_identity/acquired_at/lease_deadline`；只有能证明原进程不存在、lease 已过期且事务状态与现场哈希一致时才可由恢复流程接管。不得以删除锁代替恢复判定。 |
|---|
| | | 3. 候选核心文档先写入 `核心文档/.releases/<release_id>.staging/`，全量验证后以同卷原子 rename 固化为不可变 `核心文档/.releases/<release_id>/`；旧索引继续只引用旧 release 代，故准备和验证期间用户仍只能解析完整旧集。 |
|---|
| | | 4. cases 行业根 `当前成果索引.md` 的同卷 atomic ReplaceFile（首次发布为同目录 CreateNew + atomic rename）是唯一 commit point，且必须是最后一个可变用户入口切换动作。其前只允许：冻结旧快照、固化候选 release 代、验证不变的 result 薄入口、以 atomic ReplaceFile 安装候选 `current_output_manifest.csv`。首次发布可在 PREPARED 阶段以 CreateNew 建立一次固定 result 薄入口；此时 cases 索引尚不存在，薄入口按自身合同只表达“无正式当前成果”，仍是完整 prior=`ABSENT_GENESIS` 状态。cases 索引切换前用户入口仍解析完整 prior/无发布状态；切换成功后两份入口共同解析完整新 release。 |
|---|
| | | 5. cases 索引提交后，必须立即按 `release_receipt.json` 复算两份索引、候选核心文档和 current manifest；全部匹配才 append `COMMITTED`。任何发布工具和普通阅读入口只承认“cases 索引内 release_id + exact hash 闭合”的旧集或新集，不承认 `PREPARED/VERIFIED/COMMITTING` 为正式版本。 |
|---|
| | | |
|---|
| | | #### 8.3 固定发布顺序 |
|---|
| | | |
|---|
| | | 1. `PREPARED`：取得独占锁；确认行业既有执行/输出审核 PASS；冻结 prior cases 索引、prior core release、prior result 索引、prior current manifest、prior release receipt 的 exact-set/hash 到新审计包。首次发布允许 prior 明确冻结为 `ABSENT_GENESIS`，要求 cases 索引/core release/current manifest 全部不存在，result 薄入口不存在或精确匹配固定空态合同；非首次发布则所有 prior 回滚文件都必须可读且非 reparse。条件不闭合即 `ABORTED`，正式入口不变。 |
|---|
| | | 2. `VERIFIED`：用 CreateNew 生成 staging candidate、candidate cases 索引、candidate manifest 和 release receipt；result 薄入口只允许首次 CreateNew 固定空态合同或复验既有固定 bytes/hash，不得按 release 改写。验证路径逃逸、重复路径、reparse、相对链接、manifest FK、audit ID、UTF-8/U+FFFD、bytes/hash、scoped diff 和 governance；注入索引/hash/manifest/link 漂移必须被拒绝。验证失败 append `ABORTED`，不得进入 COMMITTING。 |
|---|
| | | 3. `COMMITTING`：append 状态后固化不可变候选 release 代；验证或首次 CreateNew result 薄入口；atomic ReplaceFile current manifest；最后 atomic ReplaceFile cases 当前索引。禁止把 ledger 的 `COMMITTED` 行写在 commit point 之前。 |
|---|
| | | 4. `COMMITTED`：commit point 后复算 candidate release set，append `COMMITTED`，释放锁并保留审计包、prior 快照和新 release 代。清理 staging 仅限已验证的任务专属 staging；不得删除 prior release、rollback receipt 或 ledger 历史。 |
|---|
| | | |
|---|
| | | #### 8.4 crash/reopen 判定与补偿 |
|---|
| | | |
|---|
| | | | reopen 现场 | 唯一处理 | 终态 | |
|---|
| | | |---|---|---| |
|---|
| | | | 仅 `PREPARED/VERIFIED`，cases 索引仍为 prior hash | 核对 prior exact-set 后隔离/清理任务 staging，append 补偿事件 | `ABORTED`，旧集继续正式 | |
|---|
| | | | `COMMITTING`，current manifest 已换但 cases 索引仍为 prior hash | 从审计包 atomic 恢复 prior manifest，复算 prior exact-set；候选 release 代保留或隔离 | `ROLLED_BACK`，旧集继续正式 | |
|---|
| | | | cases 索引已为 candidate release_id，但 ledger 尚无 `COMMITTED` | 复算 candidate 两索引、core release、current manifest；全匹配则只补 append `COMMITTED`，不得重写文件 | `COMMITTED`，新集正式 | |
|---|
| | | | cases 索引已切换但 candidate 任一项不匹配 | 进入 `ROLLING_BACK`，从审计包 atomic 恢复 prior manifest 和 prior cases 索引，复算 prior exact-set，再 append 补偿事件 | `ROLLED_BACK`；不匹配候选不得正式 | |
|---|
| | | | prior/candidate 事实无法判真、rollback snapshot 缺失或锁所有权不明 | 不删除、不猜测、不继续发布；保留现场和证据 | `RECOVERY_REQUIRED`，禁止迁移收敛和后继 release | |
|---|
| | | | ledger 已有相同 release_id 的 `COMMITTED` 且现场 exact hash 匹配 | 幂等返回既有 receipt，不追加第二个 commit | `COMMITTED` | |
|---|
| | | |
|---|
| | | 恢复过程只能依据审计包 receipt、现场普通文件 bytes/SHA-256、索引 release_id、ledger 事件和锁证据；不得依据目录 mtime、文件数量近似值或操作者记忆。每个 commit 边界必须有断点/重启故障注入用例，证明 reopen 只能收敛为完整 prior 或完整 candidate，不能留下混合集。 |
|---|
| | | |
|---|
| | | #### 8.5 回滚与 legacy 收敛门禁 |
|---|
| | | |
|---|
| | | 1. 已 `COMMITTED` 版本的业务回滚不是改写历史，而是以 prior accepted release 为 candidate 建立新的 `release_id`，重复完整 PREPARED—COMMITTED 流程；ledger 追加 `ROLLING_BACK/ROLLED_BACK` 及目标 prior receipt，原 COMMITTED 行永久保留。 |
|---|
| | | 2. `legacy_case_path_map.csv` 可在 staging/审计包准备，但旧逐案例目录的移动、收敛或删除只能在新 release 已 `COMMITTED`、prior rollback exact-set 可恢复、两份索引和 current manifest 复验通过、独占锁已释放之后开始。任一条件失败时 legacy 动作为 `0`。 |
|---|
| | | 3. 军工试点顺序收紧为：§38 同链 D02 行业根修订先闭合并由父设计绑定正式 heading/bytes/SHA-256；随后 D02 与本节状态机只提交本 audit 链一次聚焦复审；只有该聚焦复审 PASS 后，才允许按行业既有执行/输出审核 PASS 启动军工试点。新能源及后三行业不得越过同一父级设计 PASS。 |
|---|
| | | |
|---|
| | | - `passed_scope_reopened=NO` |
|---|
| | | - `industry_root_materialization=0` |
|---|
| | | - `publication_or_migration_execution=NOT_STARTED` |
|---|
| | | - `current_status=HOLD_2_FOCUSED_REPAIR_IN_PROGRESS_PENDING_MILITARY_SECTION38_D02_AND_ONE_FOCUSED_REREVIEW` |
|---|
| | | |
|---|
| | | ### 9. 军工 §38 D02 正式 artifact 绑定与聚焦复审就绪 |
|---|
| | | |
|---|
| | | - military task/design：`TASK-DEFENSE-DOCUMENT-GOVERNANCE-REORGANIZATION-20260807-001` / `DESIGN-ANA-DEFENSE-DOCUMENT-GOVERNANCE-REORGANIZATION-20260807-001` |
|---|
| | | - 正式 artifact：`ana-doc/军工案例/案例分析设计.md` 第 3741 行 `### 38.7 D02 行业根合同对齐与 D01-D04 合并修复（2026-08-07）` |
|---|
| | | - snapshot：`394256` bytes / SHA-256=`82DA4EAB1B0EDF27D257981A31DDDBA5786A8038A28700311BA8865EF1C1A014` |
|---|
| | | - 结构点验：§38 H2=`1`、D02 heading=`1`、§38 为全文最后一个 H2且正文延伸至真实 EOF；cases/result 两个根级 `当前成果索引.md` 精确完整路径各出现 `1` 次 |
|---|
| | | - D02 物理合同：`ana-data/cases/军工案例/当前成果索引.md + 核心文档/ + manifest/ + 审计包/`；`ana-data/result/军工案例/当前成果索引.md` 只作薄跳转；`ANA-DEFENSE-INDUSTRY-001` 仅保留长期 case 元数据与审计血缘，不创建同名稳定物理 case/result 根 |
|---|
| | | - 首次候选基线：BATCH-001—BATCH-033 已接受 `33 batches / 528 companies / 8 tracks x 66`；BATCH-034 `16` 家及其 pending 输出全部排除，原审核修复权不变 |
|---|
| | | - 当前事实：行业根正式入口、stable case/result 根、迁移、发布、移动、删除均为 `0`；旧 34 包只读，297 份误放 Markdown 保持原位 |
|---|
| | | - 顺序：本 D02 与第 8 节状态机先进入同一个父级 audit 链聚焦复审；只有父级聚焦复审 PASS 后，军工才可继续其既有 §91 原链聚焦复审；两道既有门均 PASS 且行业执行/输出审核前提闭合后才可试点执行 |
|---|
| | | - `BLOCK-CANONICAL-MIGRATION-DESIGN-01=REPAIRED_PENDING_FOCUSED_REREVIEW` |
|---|
| | | - `BLOCK-CANONICAL-MIGRATION-DESIGN-02=REPAIRED_PENDING_FOCUSED_REREVIEW` |
|---|
| | | - `passed_scope_reopened=NO` |
|---|
| | | - `current_status=HOLD_2_REPAIRS_COMPLETE_READY_FOR_ONE_EXISTING_AUDIT_CHAIN_FOCUSED_REREVIEW` |
|---|
