Files
pbf/STEP_RECORD.md
2026-04-08 19:32:25 +08:00

28 KiB
Raw Blame History

项目步骤记录

最后更新:2026-04-08 19:32 仓库:/root/sourceserver/pbf 远端:ssh://git@nas:2222/tei/pbf.git

文档规则

  • STEP_RECORD.md 必须使用中文
  • 后续新增输出文档必须使用中文
  • 后续新增审计报告必须使用中文

当前固定基线

唯一固定使用的视觉审计页面:

  • http://192.168.200.184/newpec/navsea-compare-karatsu-20nm.html

当前页面版本:

  • HTML: compare-r19-20260402-1203
  • Style: karatsu-final-style-r15-20260402-1203
  • PBF: karatsu-final-pbf-20nm-20260402-1156-fullrefresh1

当前仍使用同一张 HTML 做两个 profile

  1. 唐津 20 海里
    • style.navsea-delivery-karatsu-20nm-final.json
    • pbf-delivery-karatsu-20nm-final
  2. 九州
    • style.navsea-delivery-kyushu.json
    • pbf-delivery-kyushu-reencoded

当前结论

  • 当前主视觉问题不再优先怀疑 compare HTML 切错。
  • 当前主问题分成两类:
    • style 过滤条件写错或过宽
    • 线上仍在使用较早生成的 20nm final 瓦片,部分关键对象没有 class_code / display_code

2026-04-02 本轮关键发现

1. 航标紫色圈“又回来了”的原因

  • 问题层:nav-light-flare
  • 根因:这一层的过滤条件写得过宽,几乎所有带 light_color_code 的对象都会被套上 flare。
  • 直接表现:
    • 一些本来不该带圈的航标、浮标又被画成紫色圈
    • 例如 31300003 这类脚手架浮标不应再命中 flare
  • 现已修正:
    • nav-light-flare 只对原始样式允许的那几类灯标生效
    • 不再给普通浮标乱套圈

2. “眼睛”图标回来的原因

  • 问题层:anchor_caution_hazard_point
  • 根因不是对象丢失,而是线上旧 20nm final 瓦片里很多对象没有 class_code
  • 一旦 class_code 缺失,样式只能退回:
    • chart_icon_image = symbol-daytime-428
  • 直接表现:
    • 420 这类投锚注意危险物又被画成眼睛图标
  • 实际核对结果:
    • 用当前 builder 只重建 11/1765/820 这一张瓦片后,同一批对象已经恢复:
      • class_code = 420
    • 同时对应浮标对象也恢复:
      • display_code = 31300003
      • chart_icon_image = symbol-daytime-327

3. 为什么会出现“我们改过了,怎么又错了”

  • 之前改对的是 style 逻辑
  • 但 compare 页底下继续使用的是较早生成的 20nm final 瓦片
  • 这批旧瓦片缺少关键码值字段
  • 所以一旦样式依赖这些字段,就会退回错误兜底图标

一句话总结:

  • 这次回退不是“代码白改了”
  • 而是“新 style 压在旧 PBF 上跑”,导致修正无法完整生效

4. pパイロットステーション 丢失的原因

  • 这个对象不是 PBF 丢了。
  • 实际核对结果:
    • 原始对象在 z12/3530/1641
    • 原始层:pパイロットステーション
    • 原始 fid = 9002206
    • 分類番号 = 500
  • 当前 final PBF 里也存在对应对象:
    • source-layer = pilot_station_point
    • class_code = 500
    • chart_symbol_code = pilot_station
  • 真正问题:
    • final style 之前没有 pilot_station_point 这一层
    • 所以右侧页面虽然有对象,但完全没画出来
  • 现已修正:
    • 新增 pilot-station-points
    • 固定使用 symbol-daytime-500

当前已落地的修正

  • 已修正 nav-light-flare 过滤逻辑
  • 已上线新的 compare 页版本号显示
  • 已完成 20nm final 全量重生并切到线上
  • 当前整套 20nm final 都是当前 builder 生成的新版本,不再是只修单瓦片

2026-04-03 canonical_object_type 去日文推进

1. 本轮代码侧已完成

2. 10nm 临时副本结果

  • 临时副本目录:
    • /tmp/pbf-delivery-karatsu-10nm-canonical-20260403
  • 当前结果:
    • canonical_object_type 非 ASCII 复扫结果已经降到:
      • non_ascii_distinct = 0
  • 说明:
    • 唐津 10 海里这条可信 backend baseline 上,canonical_object_type 去日文已经跑通到 0 残留。

3. 10nm 渲染审计结果

4. 20nm 对象保真审计结果

5. 当前未收完的部分

  • 20nm 临时副本:
    • /tmp/pbf-delivery-karatsu-20nm-final-canonical-20260403
  • 已经完成过一轮旧映射 replay也完成了对象保真审计
  • 但在映射表补第二批 / 第三批尾项后20nm 全量 ASCII replay 还没有完整重新跑完并做最终非 ASCII 复扫
  • 因此当前真实状态是:
    • 10nm backend trusted baseline 已完成去日文和审计
    • 20nm object preservation 已完成审计
    • 20nm canonical_object_type 全量去日文复扫 仍差最后一步 replay + rescan

当前未完成项

  • 继续按同一张 compare 页回扫其他依赖 class_code / display_code 的细分类图标
  • 继续做热点截图复核,确认没有新的样式回退
  • 完成 /tmp/pbf-delivery-karatsu-20nm-final-canonical-20260403 的全量 replay
  • 对 20nm canonical 副本补做最终 non_ascii canonical_object_type 复扫

2026-04-04 全量 PBF 按最新逻辑重建启动

1. 本轮启动前确认

  • 已按仓库续接要求复读:
    • STEP_RECORD.md
    • PROJECT_HANDOFF_2026-03-31.md
    • NavSea_Delivery_Preflight_Audit_Spec.md
    • NavSea_Audit_Logic_And_Evolution_2026-04-01.md
  • 已确认当前远端仍是:
    • ssh://git@nas:2222/tei/pbf.git
  • 已确认当前 builder 里的“最新逻辑”包含:
    • navsea_tile_builder.pyRELEASE_CANONICAL_OBJECT_TYPE_MAP
    • delivery / final 输出会把 canonical_object_type 物化为最新 ASCII 发布值

2. 启动过程中发现的阻塞

  • 直接用脚本默认参数启动会失败:
    • RuntimeError: navsea mapping registry is empty
  • 已核实数据库当前实际存在的规则 bundle 只有:
    • bundle_id = navsea-core
  • 因此本轮全量重建统一改为:
    • --bundle-id navsea-core

3. 当前已启动的重建会话

  • 为避免 reference_tile_root 和输出目录互相清空,已先把现有瓦片集合复制到:
    • /tmp/pbf-refsets/karatsu10-delivery
    • /tmp/pbf-refsets/karatsu10-engineering
    • /tmp/pbf-refsets/karatsu20-delivery
    • /tmp/pbf-refsets/karatsu20-final
    • /tmp/pbf-refsets/kyushu-delivery
    • /tmp/pbf-refsets/kyushu-engineering
  • 当前正在运行的 builder 会话:
    • karatsu10 delivery: session 72703
    • karatsu10 engineering: session 33691
    • karatsu20 delivery: session 9519
    • karatsu20 final: session 97913
    • kyushu delivery: session 79176
    • kyushu engineering: session 88222
  • 统一使用:
    • --fid-key thisMyWorld@2026
    • --bundle-id navsea-core
  • delivery / final 口径统一附带:
    • --release-minimal
  • engineering 口径统一附带:
    • --engineering

4. 本轮目标

  • 把当前活跃的 builder 产物统一按最新逻辑重放:
    • /home/wwwroot/pbf-delivery-karatsu-10nm
    • /home/wwwroot/pbf-engineering-karatsu-10nm
    • /home/wwwroot/pbf-delivery-karatsu-20nm
    • /home/wwwroot/pbf-delivery-karatsu-20nm-final
    • /home/wwwroot/pbf-delivery-kyushu-reencoded
    • /home/wwwroot/pbf-engineering-kyushu

5. 下一步

  1. 持续轮询 6 个 builder 会话,确认没有新的运行时异常
  2. 待会话完成后复核各目录瓦片数是否回到原集合规模
  3. 如需要,再补做 canonical_object_type 非 ASCII 复扫与对象保真 / render 审计

2026-04-05 九州 compare 图标问题收口

1. 新确认的问题类型

  • 九州 profile 中出现的“红 X 变鱼礁 / 航标 icon 不对”,本轮确认不属于前一轮唐津那种:
    • 旧 PBF 缺 class_code / display_code
    • 导致样式退回兜底图标
  • 本轮在九州对应瓦片中核实到:
    • class_code
    • display_code
    • canonical_object_type
    • chart_symbol_code 这些关键字段本身是存在的
  • 因此当前九州问题的真实根因是:
    • style.navsea-delivery-kyushu.json 仍停留在较早的粗分类图标逻辑
    • 没有同步到 karatsu 20nm final 已经收好的精细图标分支

2. 危险物图标根因

  • 旧原始样式对:
    • 409
    • 420
    • 425
    • 428
    • 434 都是按 分類番号 分开画不同图标
  • 但九州 delivery 样式之前:
    • navigation_hazard_point 只吃 chart_icon_image
    • anchor_caution_hazard_pointobstruction / hazard_mark / fish_reef 又被统一压进 symbol-daytime-428
  • 所以视觉上会出现:
    • 红 X / 障碍物 / 鱼礁混成一类 icon

3. 航标图标根因

  • 九州 delivery 样式之前的 navigation_marks 图标分支太粗:
    • light_beacon 固定画 symbol-daytime-310
    • 普通 nav-marks 也没有按 display_code 细分浮标 / 灯标样式
  • 所以像 312 这类灯浮标、以及更细的 311xxx / 312xxx / 323xxx / 325xxx 都会回成粗图标

4. 已完成修正

  • 已把 src/pbf/style.navsea-delivery-kyushu.json 同步到 karatsu 20nm final 的图标口径:
    • hazard-points 改为优先按 class_code 精确分图标
    • anchor-hazard-points-428 改为优先按 class_code 精确分图标
    • nav-light-flare 改为和 display_code / minor_light 口径一致
    • nav-marks-light-beacons 改为按 display_code 细分 311xxx
    • nav-marks 改为按 display_code 细分 312/313/323/325/327/328 等图标
    • 并补上 lattice_buoy / pillar_buoy / can_buoy 的 canonical fallback
  • 已继续补上 facility_boundary_point 的设施点图标逻辑:
    • 不再固定画 symbol-daytime-520
    • 改为按 class_code 区分:
      • 505 / 510 -> symbol-daytime-505
      • 520 -> symbol-daytime-520
      • 530 -> symbol-daytime-530
      • 540 -> symbol-daytime-540
      • 550 -> symbol-daytime-550

5. 已部署

  • 已部署新的九州样式到:
    • /mnt/sda1/www/newpec/domain/style.navsea-delivery-kyushu.json
  • 已同步 bump compare 页版本并部署:
    • HTML 版本:compare-r22-20260405-0910
    • 九州 style 版本:kyushu-style-r4-20260405-0910
    • HTML 路径:/mnt/sda1/www/newpec/navsea-compare-karatsu-20nm.html

6. 继续补到的小灯图标问题

  • 新发现九州还有一类 minor_light 小灯点位图标不对
  • 代表点位:
    • display_code = 30600000
    • delivery 中当前对象属性显示为:
      • canonical_object_type = minor_light
      • chart_symbol_code = light_beacon
      • chart_icon_image = symbol-daytime-310
  • 旧原始样式中:
    • 30600000 -> symbol-daytime-303
  • 说明:
    • 这类点位不只是 style 旧逻辑问题
    • 也暴露出 builder 对部分 minor_light / light_beacon 的图标推断偏粗
  • 当前先在九州 style 层做了旧版兼容兜底:
    • nav-marks-small-lights 改为按 display_code 细分:
      • 303xxx
      • 305xxx
      • 306xxx
      • 307xxx
      • 308xxx
      • 309xxx
    • 先恢复到原始样式的图标表现

7. builder 侧已继续收口

  • 已在 navsea_tile_builder.py 中继续修正 navigation_marks 的图标生成逻辑:
    • 新增一组按旧 display_code 直接映射图标的 builder 内部表
    • 当前先覆盖:
      • 303xxx
      • 305xxx
      • 306xxx
      • 307xxx
      • 308xxx
      • 309xxx
  • 已把原始 canonical_object_type = 灯 (Lt) 的语义判断单独识别为:
    • chart_symbol_code = minor_light 不再先落到 light_beacon
  • 单瓦片验证结果已确认:
    • display_code = 30600000
    • 现在 builder 直接产出:
      • chart_symbol_code = minor_light
      • chart_icon_image = symbol-daytime-303

8. 当前已重跑的 builder 会话

  • 已重新启动:
    • kyushu delivery: session 80537
    • kyushu engineering: session 73505
  • 目的:
    • 让九州现网 compare 不只依赖 style 兜底
    • 同时把新的 builder 图标推断真正写回 delivery / engineering PBF

下一步

  1. 在固定 compare 页上复查:
    • 浮标不再被错误套圈
    • 420 不再回成眼睛图标
  2. 继续清理其他依赖 class_code / display_code 的细分类图标问题
  3. 继续完成 20nm canonical 副本的全量 replay并确认
    • canonical_object_type 非 ASCII 残留归零或收敛到明确尾项
  4. 如需上线这轮 canonical 去日文结果:
    • 先决定是否同时重放 20nm final PBF
    • 再决定是否同步部署 compare 用 style / 页面版本号

快速续接提示

下次继续时,先做这几件事:

  1. 确认页面顶部版本仍然是 compare-r18 / style-r14 / pbf-fullrefresh1
  2. 继续从博多港和中央航路这类热点回扫细分类图标
  3. 优先检查仍依赖 display_code / class_code 的对象组

2026-04-05 九州 at 规则回扫

1. 对今天几类错位的统一判断

  • 本轮重新对了原始 style.json 后,已确认今天几类错位的共同根因是:
    • 之前仍在用“归一语义字段优先”的方式补样式
    • 但原始 at 图层实际是“旧字段直驱”
  • 本轮重新钉实的规则:
    • p航行危険障害物 / p投錨注意障害物:按 分類番号
    • p錨泊地等:按 分類番号
    • p施設・境界線等 点要素:按 分類番号
    • p航路標識群 主图标:按 表示用番号
    • p航路標識群フレア:按 形状分類番号
    • p陸上構造物:按 分類番号 直接拼 symbol-daytime-*

2. 本轮已修改的 delivery / style 逻辑

  • 已修改 src/pbf/style.navsea-delivery-kyushu.json
    • anchorage-symbols 改为优先按 class_code 直出 719/720/721/724
    • nav-light-flare 改为优先按 shape_class_code 命中原始 flare 允许集合,仅在缺字段时退回旧兼容分支
    • nav-marks-harbor-lighthouses / nav-marks-breakwater-lighthouses / nav-marks-small-lights / nav-marks-light-beacons
      • 过滤条件改为优先按 display_code 前缀分层
      • 仅在缺 display_code 时退回 canonical_object_type
    • nav-marks 主层过滤同步改为排除这些 display_code 前缀,而不再只靠 canonical_object_type
    • facility-points 保持按 class_code 分图标,并补上 icon-ignore-placement
    • 补回 pilot-station-points
    • landmark-points 改为优先按 class_code 直接拼 symbol-daytime-*
    • landmark-point-fallback 只对缺 class_code 且不在已知旧图标类中的对象保留圆点兜底

3. 本轮已修改的 builder / 字段保留逻辑

  • 已修改 navsea_tile_builder.py
    • FINAL_RELEASE_PROPERTY_ALLOWLIST 新增 shape_class_code
    • --release-minimal 口径现在也会保留 shape_class_code
  • 已修改 tasks/pbf/mappings/navsea_field_name_rules_v1.yaml
    • 形状分類番号 -> shape_class_code 改为 keep_in_delivery: true
  • 目的:
    • 让 delivery PBF 重新具备支撑原始 at 规则的最小旧字段
    • 不再让 航路標識群フレア 只能靠 display_code + canonical_object_type

4. 本轮已部署版本

  • compare HTML 已 bump 并部署:
    • HTML: compare-r23-20260405-1533
    • 路径:/mnt/sda1/www/newpec/navsea-compare-karatsu-20nm.html
  • 九州 style 已 bump 并部署:
    • Style: kyushu-style-r5-20260405-1533
    • 路径:/mnt/sda1/www/newpec/domain/style.navsea-delivery-kyushu.json

5. 本轮已重新启动九州重建

  • 使用仓库虚拟环境 .venv/bin/python
    • 直接用系统 python3 会报:
      • ModuleNotFoundError: No module named 'mapbox_vector_tile'
  • 已重新启动:
    • kyushu delivery: session 6078
    • kyushu engineering: session 63691
  • 当前目标:
    • 把新的 shape_class_codeat 修正真正写回九州 delivery / engineering PBF

6. 下一步

  1. 等待九州两套 builder 完成
  2. 抽查热点瓦片,确认 delivery 内已出现 shape_class_code
  3. 在固定 compare 页继续复查今天提到的几类同源错位点

2026-04-05 九州 delivery 双用途图层整理

1. 本轮新增整理文档

2. 本轮整理目标

  • 不再只按旧样式/旧图层名字理解九州 delivery
  • 改为按两个业务目标重新归类当前实际图层:
    1. 航海用
    2. 钓鱼用

3. 本轮整理结论

  • 航海用的核心方向已明确为:
    • 危险物优先
    • 障碍物优先
    • 导助航优先
    • 净空/设施/锚地等通航约束优先
    • 水深细节退后
  • 钓鱼用的核心方向已明确为:
    • 海底地形优先
    • 水深细节优先
    • 底质优先
    • 鱼礁 / 穴 / 海底结构优先
    • 安全层只保底不抢主视觉

4. 当前建议的实施方式

  • 建议后续不要继续只维护一套 delivery style
  • 而是同一套 PBF 下拆成两个 profile
    1. delivery-navigation
    2. delivery-fishing
  • 先拆 style不急着拆数据

2026-04-07 九州 delivery 按对象属性分组整理

1. 本轮新增整理文档

2. 本轮整理目标

  • 不再按“航海用 / 钓鱼用”分
  • 改为按对象属性相同的 group 整理当前九州 delivery
  • 目标是给后续 style 重排、profile 拆分、专题层拆分打基础

3. 本轮已整理的主要 group

  • 等深线
  • 鱼礁
  • 灯塔
  • 港口灯
  • 渔网 / 渔具
  • 海上标识
  • 陆地设施
  • 桥梁 / 跨空线
  • 海底质
  • 海底危险物
  • 锚地
  • 引航 / 航海服务
  • 陆海背景与海岸线
  • 地名与定位参考

4. 本轮结论

  • 当前最值得继续细拆的 group 已确认是:
    1. 海底危险物
    2. 海上标识
    3. 陆地设施
    4. 海底质
  • 这四组最适合作为下一步 style 结构重排和多 profile 组织的主切口

2026-04-07 九州 delivery 前端图层分组消费配置

1. 本轮新增配置文件

2. 本轮配置目的

  • 给前端一个可直接消费的图层分组配置
  • 不再让前端直接理解 style 内部的全部 render layer
  • 让前端只面对:
    • 基础底图
    • 可切换业务 group
    • 航海 / 钓鱼 / 自定义预设

3. 当前配置内容

  • 已包含:
    • base_groups
    • groups
    • presets
  • 当前主要业务 group 包括:
    • 鱼礁/海底危险物
    • 海上标识
    • 锚地/引航
    • 港口与设施
    • 桥梁/净空
    • 等深线
    • 海底地形
    • 渔网/渔具
    • 海底质
    • 地名

4. 当前建议的前端消费方式

  • 前端用 group 配置驱动 UI不直接暴露底层 render layer
  • 实际切换时,通过:
    • map.setLayoutProperty(layerId, "visibility", "visible" | "none")
  • 建议用户入口只暴露:
    • 航海模式
    • 钓鱼模式
    • 自定义

5. 本轮 i18n 结构调整

  • 已把 src/pbf/layer-groups.navsea-delivery-kyushu.json 从直接写死中文 label 的结构,调整为:
    • label_key
    • description_key
    • i18n
  • 当前 key 命名已统一成:
    • pbf.group.xxx
    • pbf.preset.xxx
  • 这样前端可以:
    • 先直接读同文件内的 i18n
    • 后续再平滑迁移到统一翻译系统

6. 本轮前端配置字段扩展

  • 已继续给 src/pbf/layer-groups.navsea-delivery-kyushu.json 增加:
    • sort_order
    • icon_key
    • feature_flag
  • 当前作用:
    • sort_order
      • 控制前端菜单展示顺序
    • icon_key
      • 让前端图标系统不必写死在代码里
    • feature_flag
      • 方便做灰度、AB、权限或版本开关控制

2026-04-08 全国 delivery 候选构建与严格审计启动

1. 当前目标

  • 用户要求:
    • 生成全国范围 delivery 版本
    • 严格审计
  • 本轮采取的口径:
    • 先生成全国候选目录
    • 不直接覆盖现网旧目录
    • 先跑对象保真 + render-hit 两层严格审计
    • 审计过后再决定是否切正式目录

2. 当前确认的全国构建方式

  • navsea_tile_builder.py 已确认支持:
    • --all-tiles
  • 当前全国原始源目录文件总量是:
    • /home/wwwroot/newpec/exported_auto/tile.mapple-on.jp__newpec-mvt-20260106__z___x___y_.pbf/tiles
    • 全量文件数:79229
  • 当前旧全国目录状态:
    • /home/wwwroot/pbf65148
    • /home/wwwroot/pbf-engineering-full65148
  • 说明:
    • 旧全国 full 目录不是当前源集合的完整重放结果
    • 因此本轮不能直接把旧目录当作可交付全国版

3. 本轮全国候选输出目录

  • delivery 候选:
    • /home/wwwroot/pbf-delivery-full-20260408
  • engineering 候选:
    • /home/wwwroot/pbf-engineering-full-20260408

4. 本轮已启动的全国构建会话

  • 使用仓库虚拟环境:
    • .venv/bin/python
  • 已启动:
    • 全国 deliverysession 8644
    • 全国 engineeringsession 60378
  • 使用参数:
    • --all-tiles
    • --fid-key thisMyWorld@2026
    • --bundle-id navsea-core
    • delivery 附带:--release-minimal
    • engineering 附带:--engineering

5. 当前已观察到的风险信号

  • builder 已确认拿到的全国 tile job 数:
    • 79229
  • 但构建过程中已出现大量:
    • skipped z/x/y
  • 这说明:
    • 全国源瓦片不等于全国 delivery 可写出瓦片
    • 严格审计第一层就必须先检查文件集合与对象保真
    • 很可能会暴露出:
      • 数据库候选缺失
      • 某些原始瓦片无可输出 rows
      • 全量覆盖不完整

6. 本轮严格审计计划

  • 第一层:
    • 文件集合 / 覆盖率检查
  • 第二层:
    • 全国对象保真审计
  • 第三层:
    • 全国 render-hit 审计
  • 当前说明:
    • 现有审计脚本默认口径偏 10nm / 20nm / kyushu
    • 本轮会在全国候选目录构建完成后,按全国路径重定向运行
    • 审计输出文档仍需单独整理成中文放行报告

7. 下一步

  1. 等待全国 delivery / engineering 候选构建完成
  2. 先做全国文件集合对齐检查
  3. 运行全国对象保真审计
  4. 运行全国 render-hit 审计
  5. 输出中文严格审计报告并给出是否可交付结论

2026-04-08 delivery style sprite 统一

1. 本轮调整

  • 按用户要求,把 delivery style 的 sprite 地址统一改为:
    • http://192.168.200.184/newpec/sprite/sprite?v=111

2. 当前已修改的仓库文件

3. 当前说明

  • 仓库内源文件已完成统一
  • 线上 /mnt/sda1/www/newpec/domain/ 下的部署文件尚未在本轮同步
  • 后续如需页面立即生效,还需要再做一次部署同步

2026-04-08 全国 delivery style 草稿

1. 本轮新增文件

2. 本轮生成方式

3. 当前说明

  • 这是当前全国 delivery 候选 PBF 的配套 style 草稿
  • 当前尚未单独部署到线上公开路径
  • 当前也还没有配套的全国单屏 HTML / compare 页面

2026-04-08 全国 delivery style / HTML 部署

1. 本轮部署文件

  • 已部署 style
    • /mnt/sda1/www/newpec/domain/style.navsea-delivery-full.json
  • 已部署 HTML
    • /mnt/sda1/www/newpec/navsea-final-delivery-full.html

2. 当前可访问 URL

  • style
    • http://192.168.200.184/newpec/domain/style.navsea-delivery-full.json
  • 单页查看:
    • http://192.168.200.184/newpec/navsea-final-delivery-full.html

3. 当前说明

  • 全国版 style 现已不只是仓库草稿,已同步到线上公开路径。
  • 当前 HTML 为单屏查看入口,不是 compare 页面。

2026-04-08 磁盘风险全量快照提交

1. 触发原因

  • 用户反馈当前电脑硬盘可能存在问题
  • 为避免本地未提交代码与文档因磁盘异常丢失,本轮优先执行一次仓库内全量快照提交

2. 本轮执行前确认

  • 已按仓库续接要求复读:
    • STEP_RECORD.md
    • PROJECT_HANDOFF_2026-03-31.md
    • NavSea_Delivery_Preflight_Audit_Spec.md
    • NavSea_Audit_Logic_And_Evolution_2026-04-01.md
  • 已确认当前远端仍是:
    • ssh://git@nas:2222/tei/pbf.git
  • 已确认当前工作区包含大量:
    • 已修改代码
    • 新增 Domain 原型文件
    • 新增审计报告
    • 新增页面与 style 草稿

3. 本轮处理原则

  • 本轮目标是“先保全当前仓库进展”
  • 因用户明确要求提交所有代码,本轮采用全量暂存与提交
  • 本轮提交不额外声称:
    • 已完成新的全国审计
    • 已完成新的交付放行结论

4. 当前说明

  • 提交完成后,仓库历史中应保留一份可回溯的本地快照
  • 若后续硬盘继续异常,优先再确认远端可推送与备份介质状态