NAVSEA-PBF-MULTISOURCE 阶段 B2.3：标准层与组件证据审计 RDC 完成报告 v1

日期：2026-10-12 状态：证据审计器实现 PASS；执行契约尚未冻结；全部标准层执行、NavSea 实机、ZIP 新发行均 NOT DONE。 用户上位原则：NavSea《通用解释器与标准层映射强制原则 v1》（2026-10-12）。

一、实际工作环境和文件

RDC 设备：tei-ThinkPad-X220（Linux）。仓库：/root/sourceserver/pbf-provider-pipeline-v1，分支：feature/provider-pipeline-v1，开始时 HEAD：d046d7ee0d9f2030d974d0e5435ae6571b0b4489。
参照 RDC 设备：CARBON7i（Windows）。NavSea Worktree：D:\React\NavSea-PBF-Multisource，分支 feature/pbf-multisource，HEAD 78d7ffeccc95469ef3be62701b7b805b5a50c1f8。
正式旧 CM95 1.1.0 ZIP 不变；Style 取其 resources-style.json，全量 Actual Catalog 来自 tools/visual-object-instantiation/output/cm95-current/actual-anonymous-catalog.json。
以上 Worktree 均有各自实际情况；本轮没有切换 Git 分支或 Worktree，不执行 Android 编译、安装、ADB、Jest、Codex、Git Commit/Push。
X220 先前 B2.1 的代码/报告修改保持，不做清理；CARBON7i 的 B1/B2.2 修改与大量既有未跟踪文件不触碰。

二、何以不能直接从 475 条 Mapping 升级成全部 EXECUTABLE

现行 PBF Mapping v2 renderEvidence.components[].role 为绘图角色 icon/text/line/fill，不是唯一 PRIMARY 和从属 COMPONENT 的权威关系。
visualObjectId 表示视觉组合/类别签名，不能凭名称代替每次真实 raw Feature 实例的稳定身份；多绘制 Layer 的同 Feature 关系仍需可信证据，不能通过屏幕位置邻近拼接。
原始 Style 的部分表达式含单个 ["get", field]，可以生成候选资源字段，但其他表达式或没有 resource key 的 text/line/fill 不能被直接推断为可执行 selector。
现有 NavSea Profile 显示逻辑仍含 provider_display，前端 pbf_group.json 有 13 个用户组 + base_map，但 Package 的人工标准层没有交付一份明确版本化、可校验的标准层 → Host 显示组权威映射；不能默认标准层名与 UI 组名相等。
2026-10-12 原始 Provider Style 不可改写原则高于仅靠整条 Style Layer visibility 的旧默认方案。混合 Layer 不许整体隐藏，残余不得自动转为已知；Pickup/Danger/Planning 不可从绘制资源直接推出安全判定。

三、本阶段真实新增代码

tools/provider-pipeline/mapping_execution_evidence_audit.py：只读、通用逐 Style Layer 证据审计器。输入经过验证的 Style JSON 和 Mapping JSON；输出每个 Visual Object 的候选表达式、分组件可证明情况、原始 Layer 绑定和阻塞原因，内部始终 executionAuthorized=false。审计器不改 Provider Package、PBF、Style，不产生 VerifiedVisualBindingSet，不成为运行时分类规则。
tests/test_mapping_execution_evidence_audit.py：两种结构不同的合成 Provider（字段分别为 symbol、pictogram），检验混合 Layer/UNKNOWN 保留、text component 需身份继承、相同字段相互矛盾、重复 Visual ID、错误 Style 索引，以及声明的 Style SHA-256 与实际快照不一致时 fail-closed。
docs/报告/NAVSEA-PBF-MULTISOURCE_阶段B2-3_全量Mapping逐层证据审计_v1.json：以暂存内存生成的 475 条 Mapping和既有原始 Style 快照计算出的诊断数据；它不是正式新 ZIP，也没有产品执行授权。
本报告：docs/报告/NAVSEA-PBF-MULTISOURCE_阶段B2-3_标准层与组件证据审计_RDC完成报告_v1.md。

四、实证数据与检查结论

上游完整 CM95 Actual Catalog：177,383 tiles、475 类 Visual Object、976,534 次 matched visual occurrence。使用原有人工赋值构造的 475 条 Mapping 中，329 条有 standardLayer、146 条为 UNKNOWN/AMBIGUOUS；此 Mapping 仅用于审计输入，正式旧 ZIP 仍只有 102 条 Mapping。

本阶段审计 475 个对象，总绘制组件数 820：

510 个组件具备可静态构造的候选直接资源 selector；310 个组件在当前严格 role + resource property 规则下无法证明候选。
29 个 Style Layer 在完整 475 类目录中出现多个分类或 residual；旧 102 类子集曾得出 6 个混合 Layer，是不同覆盖范围，不构成冲突。
275 个 Visual Object 含多个绘制组件，需逐实例证明主体与组件关系。274 个对象至少有一个组件的候选 selector 在严格检查下尚不可证明（注意该数量不等同于旧统计的 259 类无 resourceKey）。
329 条已分类对象仍缺标准层 → 显示组的正式发布与绑定版本；146 条属于 UNKNOWN/AMBIGUOUS 等未确认归属。
静态检查未在当前全量对象中检测到“同一字段被要求同时等于不同资源值”的显式矛盾；但不代表所有组合可达。
原 Style filter 命中、任意两组件来自同一真实原始 Feature、Pickup 的对象 Identity 和用户四档效果都未经当前审计器证明。
本轮执行授权新增量为 0；Audit 不是 Compiler。
X220 最终运行 python3 -m unittest discover -s tests -p 'test_*.py' -v：19/19 PASS、退出码 0（B2.3 新增审计测试 5、B2.1 既有 Pipeline 测试 14）。没有 Jest。审计 CLI 在校验原 Style SHA-256 后成功重建 475 条诊断 JSON；旧正式 ZIP SHA-256 没有变化。
B2.2 NavSea 导入侧测试在上一阶段 7/7 PASS；不是本轮重新执行的结果。

五、拟定通用执行 Contract 结构（候选，未经用户确认，不得视为冻结）

下面仅是待批准的接口方向，不作为现有 Package Schema 或任何 EXECUTABLE 授权：

5.1 NavSea 所有的标准显示 Catalog

独立定义 standardCatalogId、schemaVersion、catalogSha256。
明确、逐条声明 standardLayerId → allowedDisplayGroupIds 的审核关联；可把多个标准层对应到同一显示组，但必须显式说明是否允许一个标准层拆分成多个 UI 组，以及需怎样区分对象。
该 Catalog 由 NavSea 标准层/显示策略维护，不依赖 CM95、source-layer、Sprite 或某个 PBF 的层名；至少校验 Catalog 指纹与被引用版本。
未绑定的 standardLayer 只保留 Provider 原图形显示，并返回该组控制/语义能力未可用，禁止默默猜测。

5.2 Package 中的 Composite 对象/Component 身份与 selector 证据

每个 Visual Object 至少需要可审核的：已确认 standardLayer、对象身份规则（原始 Feature/有效范围）、唯一 PRIMARY 证明、COMPONENT 的父关系/同 Feature 关联，以及每个被控制的 Style Layer 独立 selector、资源输出表达式和原 Style Filter/Layer Index/Source 绑定。

同一原始 Feature 的证明不能只用屏幕距离或抽象 visualObjectId。
若其他 Component 不具自己的资源键，可以继承已经证明可在该 Layer 读取到、且来自同一 Feature 的 selector；必须先证明跨层数据字段和 filter 匹配。
审查者需明确每条证明的来源、版本、覆盖范围及其对 Display/Pickup/Danger/Planning 的能力授予范围。
ANY/ALL、不同 Style Layer selector 的合成必须根据每层真实可达证据决定，不能简单把全对象条件照搬到所有 Layer。
Residual/AMBIGUOUS/UNKNOWN/冲突对象 PRESERVE 原渲染，不自动授权查询或安全判断。

5.3 ProviderCompiler 验收门槛

Compiler 只接收并校验已冻结、版本/指纹匹配的 Package、Style、Standard Display Catalog，生成不可变 Plan；Host 的 B1 通用 selector 开关仅消费执行计划，不重新解释源数据。缺关键身份、逐层 selector、Catalog 映射、覆盖和冲突证明就降级，不允许“整体隐藏混合 Layer”这种表面通过方式。

现行 v1 Package 九文件不变。是否在 Mapping v3 或 v2 的受控扩展字段中表达组件绑定，需先按正式 ADR/RFC 比较旧消费者兼容性，再由用户确认。此处不修改 ZIP 格式/Parser/Compiler。

六、后续 B2.4 推荐顺序

将本阶段 475 条逐组件静态证据与上游原始 raw Feature 样本关联，调查什么字段、何种 raw identity 可证明 PRIMARY/COMPONENT。先只读，不自动指定父组。
单独审核并批准标准层 → NavSea 产品显示组的权威 Catalog、版本/指纹和覆盖政策；需确认像 facility_boundary_outline、fixed_fishing_gear_area 等标准层的 Host 归属，不能按名字臆测。
在上游先做一个纵向切片：原始 Style 层的逐层精确 selector + 组件身份 + residual 不变，验收原 Style 全可见等价，再推广至完整 Catalog。
完成另一种结构不同的真实 Provider（非合成测试）同 Contract 验收，再考虑打开其它 EXECUTABLE；原有 19 条及 CM95 专用鱼礁/LIGHTS05 过渡兼容路径继续维持，不做未经实机复验的清除。
完整新 ZIP 发行、真实 URL 安装与 Android/iOS 实机回归应成为独立后续门槛，不得将本阶段测试标记为产品完成。

七、边界与待裁决项

正式设计存在“旧 Profile 以整个原 Style Layer 列出 logicalGroups”和“新混合 Layer 必须按对象级 selector”的粒度差异。本阶段未替用户确认新的公开 Schema，也没有在生产侧引入双套解释规则，建议冻结新 Contract 前制定明确的迁移/优先级规则。

无 Git 发布或 Source Lock 行为。重要限制：审计器本身没有验证 177,383 瓦片来源的不可变全量清单、原始 Feature 实例稳定 ID、跨层 Style Filter 语义或真实 GPU 输出；所有相关能力均为待证事实。

9.6 KiB Raw Blame History Unescape Escape