P07 · YBO Studio——应用架构附录(Level 2)
1. 范围
本附录为 P07-studio.md FR-01–FR-26 设计 Studio 应用:浏览器 PWA、其模块、校验流水线、部署客户端、文档生成、虚拟船模拟器、生产模式、权限、存储与同步。它仅涉及软件——不含芯片,亦无自身的总线时序。每个 schema 对象、护栏与错误代码均定义于 X02-config-schema.md,本文仅按章节引用,绝不重新定义;每个总线载荷均为 X01-ybo-can-protocol.md §4。实现技术栈(语言、PWA 框架、PDF 引擎)为 (t),列于 §12。
| 参与方 | 负责 | 绝不做 |
|---|
| Studio(本附录) | 编辑器、执行 X02-config-schema.md §9 的校验引擎、版本链、签名、部署客户端、文档生成器、模拟器、生产模式、本地存储、同步客户端 | 定义 schema 对象(X02-config-schema.md §1);运行时控制;单独裁定 HD 馈线 / >25 A 决定(P07-studio.md §1) |
Hub deployd(P03-hub-design.md §7) | 部署的事实来源:签名、version_id 与 schema 主版本检查、逐节点 CFG 片段、原子提交或回滚、保留 N = 10 (t) 个版本(P07-studio.md §5) | 编辑 bundle;信任 Studio 的校验结果 |
独立模式 AIR-GW(P05-air-gateway-design.md §7) | 仅对自身承担 Hub 角色:验证并存储自己的片段、绑定表回读、保留 3 个 (t) 版本(X02-config-schema.md §2) | 配置任何其他节点 |
Mate 云端(P08-mate-data-model.md §2/§4) | 备份每个已部署版本(P08-mate.md FR-29)、云端副署、config 中继主题、交付包存储 | 充当实时状态或活动版本的事实来源 |
2. 应用架构
+-----------------------------------------------------------------------------------------------+
| Browser PWA (installable, service worker, offline-first) |
| +--------------+ +--------------------+ +--------------------+ +--------------------+ |
| | Editors |-->| Validation engine |-->| Document generator | | Virtual boat | |
| | inventory, | | schema -> semantic | | wiring PDF, as- | | simulator | |
| | assignment, | | -> plausibility | | built, handover, | | fabricated CAP + | |
| | presets, | | G-01..G-13 (X02) | | CSV, JSON, numbers | | STATE, faults, | |
| | bindings ... | | findings E-* / W-* | | and revisions | | same pipeline | |
| +------+-------+ +---------+----------+ +---------+----------+ +---------+----------+ |
| | | | | |
| +------v---------------------v------------------------v------------------------v----------+ |
| | Project store (IndexedDB-class, section 10): projects, immutable versions, capability | |
| | cache, schema fragments, templates, generated documents, audit queue, backup queue | |
| +------+-------------------------+----------------------------------------+---------------+ |
| | | | |
| +------v-------+ +-------------v-------------+ +----------------------v---------------+ |
| | Signer | | Deploy client | | Sync client | |
| | user key, | | HTTPS boat LAN | Mate | | cloud backup, countersignature, | |
| | manifest, | | relay | BLE / local AP | | audit mirror, template feed; | |
| | bundle.sig | | (standalone AIR-GW) | | queued while offline | |
| +--------------+ +----+-------------+--------+ +------------------+-------------------+ |
+--------------------------|-------------|---------------------------------|--------------------+
| | |
HTTPS (boat LAN) | | BLE / local AP | HTTPS + mTLS MQTT relay
or Mate relay v v v
+-----------------------+-----+ +---+---------------------+ +-------+-----------------------+
| HUB deployd (P03 annex s7) | | AIR-GW standalone | | Mate cloud (P08 annex s4) |
| verify sig / version / major| | Hub role for itself: | | config relay, backup of every |
| -> CFG fragment per node | | verify + store own | | version, countersignature, |
| -> commit, or atomic | | fragment, binding table | | handover-pack store |
| rollback; N = 10 kept | | read-back, 3 versions | | |
+--------------+--------------+ +-------------------------+ +-------------------------------+
| YBO-CAN CFG BEGIN / DATA / END / STATUS (X01 s4.7): node verifies, ACKs, echoes hash
v
CORE-S / CORE-M / CORE-HD / SENSE / KEY / AIR-GW (system mode)
3. 模块
| 模块 | 职责 | 输入 | 输出 | 离线行为 |
|---|
editors | 回路清单、分配、预设、按类型的块、绑定、场景、报警规则、AC 策略,依 X02-config-schema.md §3–§6;部署前列出未分配回路与未使用通道(P07-studio.md FR-01) | 草稿、能力缓存、模板 | 带 JSON 指针的草稿对象 | 完全可用 |
capability_registry | 通过 Hub 节点表(CFG CAP,X01-ybo-can-protocol.md §4.7)发现节点,或由 simulator 伪造;缓存能力块与 capability_hash(X02-config-schema.md §8) | Hub 节点表、DIAG 第 3 页 | nodes[] 骨架、提供给 editors 的逐通道限值 | 提供缓存的能力块,并标注其上报时间 |
validator | §4 流水线;编辑时对触及对象增量运行,签名前完整运行 | 草稿、能力缓存、载流量表、X01-ybo-can-protocol.md §6 公式 | 发现项列表、validated 标志 | 完全可用(所有表均已缓存) |
version_chain | 不可变版本、语义差异(回路、预设、绑定、规则——P07-studio.md FR-18)、previous_version_id、rollback_of | 已校验 bundle、上一版本 | 差异视图、manifest 字段 | 完全可用 |
signer | 规范化 JSON、SHA-256、使用用户密钥的 ECDSA P-256 (t)(X02-config-schema.md §2) | manifest + bundle | bundle.sig、副署请求 | 本地签名;副署排队 |
deploy_client | §5 状态机,经 HTTPS(船上局域网)、Mate 中继或 BLE / 本地 AP(独立模式 AIR-GW) | 已签名 bundle、目标 | 逐节点状态、已确认版本 | 局域网与 BLE 路径可用;中继路径排队 |
doc_generator | §6 受控工件 | 已确认版本、DIAG 版本信息、模板、i18n 资源 | 带编号与修订号的 PDF、CSV、JSON | 完全可用 |
simulator | §7 虚拟船 | 任意 bundle、脚本化故障集 | 伪造的 CAP、STATE、ALARM、AUDIT 时间线 | 完全可用 |
production_mode | §8 模板、船体清单、EOL 导出 | 基础与选配模板、船体列表 | 构建清单、EOL 导出 | 完全可用;清单同步排队 |
template_library | 经验证、带版本的船型模板(P07-studio.md FR-07);用户模板在 P7-4 之前仅保留在本地 | 云端模板源 | 预填充的草稿 | 仅缓存版本 |
audit_logger | 每次部署、回滚、覆盖与角色变更(P07-studio.md FR-26) | 来自所有模块的事件 | 供 Hub auditd-ybo 与 Mate audit_record 使用的记录 | 按序排队 |
sync_client | 备份、审计、副署、模板源、会话刷新 | 队列 | 云端状态 | 链路恢复时按 §10 顺序回放 |
identity | Mate 账户、角色上下文、离线会话令牌 | Mate 认证 | 供 editors 与 validator 使用的角色 | 有界离线会话 (t)(P7-3) |
4. 校验流水线
阶段与代码见 X02-config-schema.md §9。阶段 1 + 2 在每次编辑后对触及的对象增量运行;签名前的完整运行是唯一会设置 validated 的运行。Hub deployd 在收到时重复执行阶段 1–3(P03-hub-design.md §7),因此被篡改的客户端无法绕过护栏。
| 顺序 | 检查 | 依赖 | 结果 |
|---|
| 1 | 阶段 1 模式:由 X02-config-schema.md §3 生成的 JSON Schema draft 2020-12 (t);*_ref 解析 | — | E-SCH-*、E-REF-01 阻止并终止流水线 |
| 2 | G-08 能力块存在且 schema 主版本受支持;设计时 capability_hash 与缓存比对(E-CAP-01) | 1 | 阻止;后续检查跳过该节点 |
| 3 | G-13 安装模式,随后 G-03 映射规则(馈线、>25 A、HD 评审、充电/双向) | 2 | 阻止 |
| 4 | G-06 类型与能力匹配;G-07 脉冲限值;G-02 回读输入;G-09 AC 输入角色 | 2 | 阻止 |
| 5 | G-01 关键绑定与场景关键回路关断;G-05 自动化白名单;G-11 AC 策略 | 3–4 | 阻止 |
| 6 | E-ALM-01 规则容量;按 nvm_target 编译绑定表并与 nvm_bytes 比对;E-PRM-01 角色与锁定规则 | 4 | 阻止 |
| 7 | 阶段 3 合理性:G-04 载流量;G-10 RS-485 轮询周期;YBO-CAN 总线负载(X01-ybo-can-protocol.md §6);输入数量预算(P04-ac-interface.md §6);未分配 / 未使用清单 | 4 | G-04 与 G-10 阻止(存在最大脱扣跳线时为 W-PR-01);其余为警告 |
| 8 | G-12 上游保护、W-CH-01 照明不在 CORE-S 上、W-CFG-01 保留字段 | 4 | 仅警告;警告打印在 PDF 上 |
发现项模型:{code, severity, pointer, message_key, params, override}——pointer 是指向草稿的 RFC 6901 JSON 指针,severity ∈ {error, warning},override ∈ {none, installer}。代码为 X02 代码集;护栏发现项以 E-G-nn / W-G-nn (t) 携带其 id。仅在零错误时启用部署操作;每条警告须逐条确认,确认记录随审计条目一起保存并出现在 PDF 上。
安装商锁定在三层执行:(1)editors 对 owner 将 permissions.installer_locked[] 指针渲染为只读;(2)当已锁定指针与上一已确认版本不同且会话角色不是 installer 时,validator 触发 E-PRM-01,并拒绝船主对 protection*、critical、default_state、ac_policy、pulse、coil 的任何修改(X02-config-schema.md §7);(3)Hub 再校验时将 signature.key_id 与该船的授权签名者列表及该密钥登记的角色比对 (t)。覆盖仅限安装商,写入 permissions.overrides[],且每次覆盖都是一条审计记录。授权模型本身仍待定(OPEN-QUESTIONS.md P7-1)。
5. 部署流程
| 状态 | 事件 | 下一状态 | 动作 |
|---|
draft | 完整流水线运行,零错误 | validated | 发现项随草稿保存;警告等待确认 |
validated | 任何编辑 | draft | 触及对象的发现项作废 |
validated | 语义差异已展示并显式确认(P07-studio.md FR-18) | signed | version_id = 上一版本 + 1,设置 previous_version_id;对 bundle_hash 签名;请求副署或排队 |
signed | 目标可达(局域网上的 Hub、Mate 中继在线、经 BLE / 本地 AP 的 AIR-GW) | deployed-pending | 发送 bundle;审计条目 deploy_started |
signed | 中继目标不可达 | queued | 保留在备份队列中;局域网与 BLE 路径绝不排队 |
queued | 链路恢复 | deployed-pending | 重新检查:previous_version_id 必须等于 Hub 当前版本,否则退回 validated 进行变基(§10) |
deployed-pending | Hub committed:每个节点 STATUS 结果为 0 且回显哈希 = manifest.node_hashes[node_ref](X01-ybo-can-protocol.md §4.7) | confirmed | 版本生效;生成文档;备份并记审计 deploy_confirmed |
deployed-pending | 任一 STATUS 结果为 1–7,或某节点在其 END 帧后 5 s 内无响应 | rolled back | Hub 原子中止并保留上一已知良好版本;Studio 显示节点 id 与原因,提供一键回滚(P07-studio.md FR-20) |
deployed-pending | Studio 期限 T 已过而 Hub 未给出裁定 | deployed-pending(显示超时) | 轮询 Hub 部署资源;Hub 的裁定仍具权威性,到达时进行对账;用户可请求回滚 |
confirmed | 用户选择回滚到任一保留版本 | signed | 设置了 rollback_of 的新版本,走完整流水线(X02-config-schema.md §2) |
时序:Hub 在 2 s (t) 内确认 HTTPS 请求,否则 Studio 以相同的 bundle_id + version_id 重试两次(幂等)。总线上每个节点在 100 ms 内 ACK,并在 END 后上报 STATUS;仅当所有节点在 5 s 确认窗口内确认时 Hub 才提交(X02-config-schema.md §9)。Studio 自身的期限 T = 5 s + 传输估算,按每个 DATA 帧 60 B、全总线 ≤200 帧/s 计算(X01-ybo-can-protocol.md §4.7);46 节点、每片段 4 KB (t) 的 bundle 约为 ≈16 s + 5 s ≈ 21 s (t)。在 deployed-pending 期间,每个节点依据 Hub 转发的 STATUS 进度渲染为 pending;在 committed 之前不将任何节点显示为完成(PRODUCT-PLAN.md §1 控制面原则)。此后的逐节点确认会再次核对 DIAG 第 3 页片段哈希与 HB 配置哈希字节是否与 node_hashes 一致,不一致则在 UI 中将该节点标记为 config mismatch。
独立模式 AIR-GW 路径:状态相同;传输为 BLE(Web Bluetooth (t))或经 HTTPS 连接网关的本地 AP;网关验证签名与 schema 主版本,存储片段,写入绑定表并返回其 CRC-32 回读(P05-air-gateway-design.md §7);confirmed 要求回读 CRC 与 Studio 的编译结果一致。n2k_switch 目标在该 bank 实例出现 PGN 127501 时确认;静默的 bank 保持 pending,并作为警告列于接线 PDF 上。
6. 文档生成
| 工件 | 内容 | 数据来源 | 编号 / 修订 (t) |
|---|
接线 PDF(P07-studio.md FR-16) | 通道列表、端子图、上游保护、电缆清单、绑定表、已确认的警告、来自 G-12 的 "UPSTREAM PROTECTION NOT DECLARED" | 仅已确认版本 | <hull_id>-WD-<version_id>;修订号 = version_id |
| 竣工 PDF(FR-17/22) | 接线 PDF 加节点 UID、固件版本与来自 DIAG 第 3 页的片段哈希、EOL 例外 | 已确认版本、DIAG、EOL 导出 | <hull_id>-AB-<version_id> |
| 交付包电气部分(FR-17) | 与 Mate 的 handover_pack 同一链条(P08-mate-data-model.md §2.3):doc_number、revision、effective_date、config_version_id | 已确认版本;Mate 合并登记与实时状态 | <hull_id>-HO-<version_id> |
| 安装商签署的配置报告(P7-2) | 安装商姓名、日期、bundle_hash、node_hashes、已确认的警告、覆盖 | 已确认版本、permissions.overrides[] | <hull_id>-CR-<version_id>;格式待定(OPEN-QUESTIONS.md P7-2) |
| CSV 电缆清单、N2K 设备列表、构建清单 | 机器可读导出(P07-studio.md §5) | 已确认版本、Hub N2K 发现、§8 | 携带同一编号与 bundle_hash |
规则:工件仅从 confirmed 版本生成,并携带 bundle_hash、node_hashes 以及生效日期 = Hub 提交时间;从同一版本重新生成的结果除生成时间戳外逐字节一致(黄金测试,§11);版式模板随 manifest.studio_build 定版,模板版本记录在文档元数据中,因此后来的模板绝不改写先前的修订。每页页脚打印文档编号、修订号、bundle_hash 的前 16 个十六进制字符 (t) 与页数。语言:每个项目从首发语言集中选择一种文档语言(OPEN-QUESTIONS.md P7-6;英文始终可用);固定的安全字符串以英文和文档语言同时打印;SI 单位、区域数字格式、字体嵌入、PDF/A-2b (t)。
7. 虚拟船模拟器
| 领域 | 模拟 | 不模拟 |
|---|
| 节点 | 按类别与型号的能力块(X02-config-schema.md §8)、节点 ID、1 s (t) 的 HB、DIAG 第 3 页哈希回显、连续丢失 3 次 HB 后节点丢失 | 能力块之外的硬件型号差异 |
| 命令生命周期 | CMD → ACK ≤100 ms → 以可配置的回读延迟给出 STATE(默认 200 ms (t),可注入至 5 s 及以上);X01-ybo-can-protocol.md §4.2 的每个 ACK 结果代码,包括 rejected_critical_wireless、rejected_locked、rejected_rate | 低于 20 ms (t) 的 STATE 间隔;总线仲裁 |
| 脉冲通道 | 来自 CFG 的脉宽、≥12 s 再次动作间隔、重试前先读取、already_at_target、max_conduction_ms 切断(原因 9)、不匹配 N = 3 (t) → ALARM 代码 4 | 继电器机械特性;辅助触点抖动 |
| 绑定、场景、按键 | 手势 → CMD、驾驶台锁定、联锁组、连续丢失 3 次 HB 后点动释放、场景步骤延时 | 无线距离、配对、电池 |
| 报警规则 | 阈值、去抖、迟滞、mismatch、wire_break、heartbeat_lost;"Hub 关闭" 开关用以证明 survives_hub_loss | 传感器物理特性 |
| 部署与故障 | 完整的 §5 状态机,可注入 STATUS 1–7 NACK 与逐节点静默;脱扣(原因 4–6)、检测到旁路、bus-off、节点丢失、Hub 丢失、云端丢失 | NVM 磨损;热降额;压降(OPEN-QUESTIONS.md P7-5) |
演示数据集为一个标准 bundle 加一条脚本化事件时间线(hull_id = DEMO-01 (t)),在 template_library 中定版,并由 Mate 演示模式原样使用(P08-mate.md FR-30、PRODUCT-PLAN.md §P7);模拟器运行与实际相同的 validator、signer 与 doc_generator 代码路径,因此一次虚拟部署会生成真实文档,且每页标注 "SIMULATED" (t)。
8. 新造船生产模式(P07-studio.md FR-22,(t))
| 步骤 | 对象 / 工件 | 规则 |
|---|
| 1 基础型号 | 经验证的模板(vessel.boat_type_template、template_version) | 由安装商验证;自带一次护栏运行 |
| 2 客户选配 | 选配叠加层:按 id 新增或替换 channels、bindings、scenes、alarm_rules | 叠加层在没有自身安装商覆盖的情况下,绝不降低基础通道的 protection*、清除其 critical 或更改其 default_state (t) |
| 3 每船体清单 | {hull_id, base_template, template_version, options[], version_id, operator, eol_ref},由 manifest.build_manifest_ref 引用(X02-config-schema.md §3) | 带版本;每船体每已部署版本一份清单 |
| 4 部署 | 按 §5 部署到该船体的 Hub;硬件尚不存在时部署到 simulator 以完成设计签核 | 模拟部署绝不满足步骤 5 |
| 5 EOL 检查导出 | JSON + CSV 列表:每通道 CMD 后的预期 STATE 与脱扣测试、每节点 HB / DIAG 版本与哈希、每个绑定按键 → STATE、通信(总线负载、节点数);记录的例外 {check, reason, by, at} | 例外必须为零,或每条均由生产操作员确认;结果以操作员密钥签名 |
| 6 移交 | 带 eol_ref 的竣工与交付包(§6) | 同一版本链;不是 ERP 或 PLM(PRODUCT-PLAN.md §P7) |
9. 安全与权限
| 项目 | 规则 |
|---|
| 角色 | 仅 installer 与 owner(P07-studio.md FR-23、X02-config-schema.md §7);运行时角色(crew、charter_guest 等)是 Mate 授权(P08-mate-data-model.md §2.3),在此仅以 permissions.runtime_exposure 出现 |
| 锁定字段 | permissions.installer_locked[] JSON 指针,在 §4 的三层中执行;默认锁定集 (t):所有 protection*、critical、default_state、pulse、coil、ac_policy、hd_engineering_review |
| 用户签名密钥 | ECDSA P-256 (t),在浏览器中生成为不可导出的 WebCrypto 密钥 (t),绑定到账户;key_id 位于 manifest.signature;新浏览器生成新密钥,由账户在重新认证后授权;旧密钥对过往版本的验证仍然有效 |
| 船舶密钥 | 每船 128 位总线密钥由 Studio 在调试时生成,用各设备密钥包裹后经 CFG ASSIGN 下发(X01-ybo-can-protocol.md §7);总线密钥、Air 密钥与 Wi-Fi 凭据在节点之外仅存在于加密备份内(P07-studio.md FR-20) |
| 加密备份 | AES-256-GCM (t),密钥由用户口令派生;云端仅存储密文;口令丢失意味着重新调试(由持有当前总线密钥的 Hub 执行 ASSIGN) |
| 副署 | Mate 在线时对 bundle_hash 签名(cloud_countersignature);Hub 接受无副署的 bundle,Studio 将请求排队(X02-config-schema.md §2) |
| Hub 信任 | Hub 依据其授权签名者列表验证 signature,拒绝 version_id ≤ 当前值、未设置 rollback_of 的 schema 主版本降级(E-MAN-03),并重新校验(§4);签名者列表在认领 / 调试时下发,仅可由签名 bundle 更改 (t) |
| 审计 | 每次部署、回滚、覆盖、警告确认与角色变更一条记录:谁(账户、key_id)、做什么(version_id、bundle_hash、差异摘要、逐节点结果)、何时、结果——送至 Hub auditd-ybo(P03-hub-design.md §7)并镜像为 Mate audit_record;在 Hub 或云端确认接收前绝不在本地删除 |
| 会话 | 离线会话上限 30 d (t)(P7-3);过期阻止签名,绝不阻止查看 |
| 供应链 | 每个发布版本的 SBOM、签名发布、依赖扫描、首次欧盟销售前的漏洞接收机制(P07-studio.md §6、COMPLIANCE-MATRIX.md §2) |
10. 数据存储与同步
| 存储 | 内容 | 规则 |
|---|
| 本地存储,IndexedDB 类 (t) | 对象存储:projects、versions(不可变 bundle + .sig)、capabilities、按主版本的 schema_fragments、templates、documents、audit_queue、backup_queue、session | 每项目预算 ≤200 MB (t);versions 在未备份时绝不编辑或删除;草稿在签名前仅存于本地 |
| Hub | 已部署版本 + 最近 N = 10 (t) 个(P07-studio.md §5) | 活动版本的事实来源 |
云端备份(P08-mate-data-model.md §4 config) | 每个已部署版本(P08-mate.md FR-29);最近 10 个 (t) 热存以供一键回滚,更早的冷存 (t);每船一个加密备份 blob | 绝不覆盖:已存储的 version_id 若带有不同的 bundle_hash,即为硬冲突,标记并记入审计 |
| 冲突 | 两个客户端编辑同一船体:Hub 首先确认的版本胜出;另一草稿的 previous_version_id 已过时,必须变基——对象级三方合并,冲突按指针列出;protection*、critical、default_state 与 ac_policy 绝不自动合并 | 变基后的草稿回到 draft 并重新运行完整流水线 |
| 导出 | 签名 bundle JSON + .sig;项目归档(bundle、文档、模板、能力缓存);CSV 电缆清单;N2K 设备列表;构建清单;加密备份 | 任何导出均携带 bundle_hash;加密备份是唯一含密钥的导出 |
| 导入 | 验证签名与 schema 主版本;对更早的主版本运行迁移脚本(X02-config-schema.md §2);导入的版本在重新校验前为只读 | 导入绝不在未经 §5 部署的情况下成为活动版本 |
| 重连时的同步顺序 (t) | 1 审计队列,2 副署请求,3 备份版本,4 文档,5 模板源与会话刷新 | 按序回放,对 version_id 与审计序号幂等 |
11. 验证
| 测试 | 方法 | 通过判据 |
|---|
Schema 语料库(P07-studio.md §9 M4–5) | 有效、无效、降级、超出能力与含未知字段的 bundle 通过阶段 1 | 每个无效 bundle 均被拒绝并给出指针级发现项;无有效 bundle 被拒绝;未知可选字段给出 W-CFG-01 |
| 护栏套件 | G-01–G-13 每项一个通过与一个失败夹具,加 E-ALM-01、E-PRM-01、E-CAP-01、E-MAN-03,按 §4 顺序运行 | 每个违规均被阻止;每次安装商覆盖均记入审计;顺序依赖得到遵守 |
| 部署与回滚,Hub | 带 Core 与 Sense / Key EVT 单元的 Hub 台架;注入 STATUS 1–7 与节点静默 | 所有节点在其 END 帧后 5 s 内确认;任一 NACK → 原子回滚且回读一致;UI 绝不将未确认节点显示为完成 |
部署,独立模式 AIR-GW | BLE 与本地 AP 部署;N2K bank 存在与不存在 | 绑定表 CRC 回读一致;不存在的 bank 保持 pending 并列于 PDF 上 |
离线 PWA(P07-studio.md §9 M10–11) | 48 h 无网络船厂场景,随后重连 | 本地部署、备份与审计按 §10 顺序同步且无冲突 |
| 模拟器一致性 | 同一 bundle 与脚本在 simulator 与演示船上运行 | 5 s 窗口内状态序列一致;发现项一致 |
| PDF 黄金测试 | 从固定版本重新生成每个工件;排除生成时间戳后哈希比对 | 逐字节一致;每页均有编号、修订号与 bundle_hash |
| 性能 (t) | 46 节点 bundle(X01-ybo-can-protocol.md §6 最坏情况) | 完整流水线 ≤2 s (t);增量运行 ≤200 ms (t) |
安全(P07-studio.md §9 M12) | 被篡改、重放、降级的 bundle;船主对锁定指针的尝试;伪造的 key_id | 全部由 Studio 与 Hub 各自独立拒绝;审计完整;产出 SBOM |
12. 可桌面决定的事项
| 决策 | 建议 | 理由 | 冻结门槛 |
|---|
| 客户端技术栈 | 带 service worker 的 TypeScript PWA;框架与 PDF 引擎在原型启动时选定 | 离线优先需求(P07-studio.md FR-24)与确定性 PDF 输出驱动此选择 | M4 原型启动(PRODUCT-PLAN.md §4) |
| 护栏发现项代码 | 携带 X02 护栏 id 的 E-G-nn / W-G-nn | Studio、Hub deployd 与 PDF 共用一个代码命名空间 | Studio schema 冻结(P07-studio.md §10 第 6 项) |
| 部署期限 T | 5 s + 按 60 B × 200 帧/s 的片段传输估算;4 KB 片段假设 | 在不削弱 5 s 节点窗口的前提下,让 UI 对大 bundle 保持诚实 | Hub EVT 部署台架(M6–7) |
| 用户密钥存储与恢复 | 每浏览器一个不可导出的 WebCrypto 密钥;账户在重新认证后授权新密钥 | 密钥绝不离开客户端;符合 X01-ybo-can-protocol.md §7 "绝不导出" 规则 | M12 前的安全评审 |
| 文档编号与 PDF 配置 | <hull_id>-<WD/AB/HO/CR>-<version_id>;PDF/A-2b;页脚 16 位十六进制哈希 | 修订号等于版本链;面向验船师的归档格式(P7-2) | 验船师确认(P7-2) |
| 模拟器默认值 | 200 ms 回读延迟;DEMO-01 船体;"SIMULATED" 水印 | 真实而不掩盖 5 s 窗口;Mate 演示共用一个数据集 | Mate v1 范围冻结 |
| 会话、本地预算、备份分层与同步顺序 | 30 d 会话;每项目 ≤200 MB;10 个热版本,其余冷存;审计 → 副署 → 备份 → 文档 → 模板 | 在浏览器配额内覆盖越冬船厂作业;回滚保持一键;审计完整性优先 | P7-3 关闭;云端 beta 进入 M10 |
| 默认安装商锁定集与叠加层规则 | 锁定所有保护 / 关键 / 默认状态 / AC 策略指针;叠加层不得削弱它们 | 在不阻碍编辑器的前提下,为 P7-1 待定的责任立场兜底 | P7-1 关闭 |
13. 变更记录
| 日期 | 变更 | 参考 |
|---|
| 2026-08-31 | 初版附录:应用架构、模块表、校验顺序与发现项模型、含 Hub 与独立路径的部署状态机、受控文档、模拟器范围、生产模式、安全、存储与同步、验证 | PLAN-029 |