101 lines
8.5 KiB
Markdown
101 lines
8.5 KiB
Markdown
<!-- gitea-wiki-mirror:start -->
|
||
generated: true (请先修改 Gitea Wiki，禁止直接编辑本文件)
|
||
wiki_page: Business-Rules-and-Glossary
|
||
wiki_url: https://git.ilapage.cn/ila/yovision/wiki/Business-Rules-and-Glossary.-
|
||
wiki_revision: 06b68d16bf907decdaf85a813d417896f7920f4c
|
||
synchronized_at: 2026-08-13T14:06:00Z
|
||
<!-- gitea-wiki-mirror:end -->
|
||
|
||
# 业务规则与术语
|
||
|
||
## 核心术语
|
||
|
||
| 术语 | 定义 |
|
||
|---|---|
|
||
| Sense | 独立销售的视频接入、媒体、区域配置和运维产品 |
|
||
| Brain | 无界面的推理交付单元，输出观测和标准事件 |
|
||
| Bell | 独立销售的事件预警与处置产品 |
|
||
| Device | 设备根实体；通过 modality/capabilities 表达视频、雷达、门磁等能力 |
|
||
| Site | 一个客户部署中的站点边界 |
|
||
| Area | 多边形区域、警戒线及其隐私/准入策略 |
|
||
| Event | 已发生的不可变结构化事实及证据引用 |
|
||
| Alert | Bell 根据一个或多个 Event 和规则创建的处置对象 |
|
||
| ack | 明确由某人接手 Alert，不等同于消息已送达或已看到 |
|
||
| Outbox | 与本地状态同事务持久化、可重试投递的消息队列记录 |
|
||
| producer identity | Bell 为每个外部产品实例分配的机器身份 |
|
||
| 场景包 | 规则模板、升级策略、话术和报表口径的版本化配置包 |
|
||
|
||
## 工单状态
|
||
|
||
- 待确认：需求或方案等待负责人确认。
|
||
- 待实施：方案已确认，但依赖或排期尚未满足。
|
||
- 进行中：主 agent 正在工单声明的写路径内实施。
|
||
- 阻塞：出现计划外且当前无法解除的问题。
|
||
- 待验收：实现、测试和文档证据完成，等待负责人验收。
|
||
- 已完成：负责人明确验收并完成归档、关闭。
|
||
|
||
旧仓库任务的 DONE 不继承到新仓库。所有迁移项初始均为“待迁移”，必须用新代码、新测试和新验收重新证明。
|
||
|
||
## 稳定业务规则
|
||
|
||
1. Sense 与 Bell 完全独立认证；同一自然人在两个产品中是两个账户。
|
||
2. 任一产品可独立部署、升级、备份、恢复和验收，另一产品不作为启动依赖。
|
||
3. Brain 不拥有用户、Alert、通知或业务审计真相。
|
||
4. 产品集成使用机器身份和版本化契约，不共享数据库、用户会话或内部模型。
|
||
5. Bell 以 `(producer_id, source_event_id)` 保持跨重启幂等。
|
||
6. Event 不可变；误报只追加 outcome/反馈，不改写原始事实。
|
||
7. `sent`、`delivered`、`seen`、`ack` 是不同事实；无回执不能当成功。
|
||
8. 未 ack 自动升级且进程重启后续跑；并发 ack 只有首个成功者成为处置人。
|
||
9. 联系人、排班和升级策略共享主数据但分对象、分版本；投递创建时固化实际收件人、通道和解析版本。
|
||
10. 静默必须限时并自动恢复，单次不超过 4 小时。
|
||
11. 默认 16 路，按 32/64/128 横向扩展；128 路不等于单机或单 GPU 承诺。
|
||
12. 首期 S2 民办寄宿学校只做匿名规则，不启用人脸。
|
||
13. 家庭卧室、卫生间禁止摄像头，只能使用非成像传感器。
|
||
14. 摄像头凭据、客户数据、真实视频、JWT secret 和生产配置不得进入仓库、工单或 Wiki。
|
||
15. 业务预警与设备/媒体/推理运维告警使用不同通道和责任人。
|
||
|
||
## 新项目需要补充什么
|
||
|
||
以下事实必须由后续工单和负责人确认后补充：
|
||
|
||
- GoAdmin/go-admin-ui 的固定上游 commit、许可证记录和裁剪模块；
|
||
- Go、Node、Python、CUDA、PostgreSQL、MediaMTX 的精确版本；
|
||
- Sense/Bell 数据库 schema、Cookie 名称、部署域名和备份命令；
|
||
- Brain 模型、推理 FPS、硬件容量和商用许可；
|
||
- 试点最终留存期、通知供应商和验收阈值；
|
||
- 三个交付单元的正式版本与发布流程。
|
||
|
||
未确认项不得从旧代码或模板默认值推断为当前事实。
|
||
|
||
<!-- sense-mvp:start -->
|
||
## Sense MVP 业务与安全规则
|
||
|
||
- **Sense 账户**：只登录 Sense；不得接受 Bell JWT、Cookie 或用户数据。角色为系统管理员、实施/运维、站点管理员和只读用户，后端权限是最终边界。
|
||
- **安全初始化**：系统不提供默认账户、默认密码或默认签名密钥；首次管理员由仓库外一次性令牌创建。所有模式的密码仅要求至少 6 个字符，不限制字符种类并允许包含用户名。负责人已明确接受该生产密码策略的字典猜测与凭据填充风险。
|
||
- **Device**：设备不可变逻辑 ID 是后续 Profile、媒体和区域的内部引用。非视频适配器未实现时必须显示 `adapter_not_ready`。
|
||
- **摄像机凭据**：ONVIF 与 RTSP 可使用不同账号，也可显式复用；两组均只写不读，使用仓库外 32 字节密钥分别加密。密码不得进入 URL、日志、审计、工单或响应。
|
||
- **受控发现**：ONVIF Discovery 默认关闭，只有显式设置获准本机 IP 才能发送发现；不得扫描未授权网段。
|
||
- **Profile**：主辅码流按分辨率分类并使用 RTSP 凭据分别验证；脱敏 Stream URI、验证状态和时间持久化，重启后保留。至少一个 Profile 验证成功后 Device 进入 `active`；认证失败、不可达、超时与校时问题使用可定位状态。
|
||
- **自动媒体路径**：接入检查中每个验证成功的 Profile 都按 Device/Profile 幂等建立并立即对账媒体路径；首次配置使用 MediaMTX add、已有配置使用 replace，Sense 启动时从数据库恢复所有 `desired=running` 路径；路径不存在属于配置失败，不属于等待拉流。MediaMTX 不可用不回滚摄像机接入，接入结果记录“需要处理”并引导到视频服务排错。
|
||
- **MediaMTX**：保持外部进程。Sense 只停止自己启动并持有句柄的进程，最多自动重启三次；摄像机凭据只在 localhost 控制请求中瞬时组装，不持久化、不返回。
|
||
- **播放会话**：由当前 Sense 用户创建，最长两分钟；实时监看以设备名称、位置和主/子码流等业务标签供用户选择，内部 ID 只用于系统关联；`waiting` 表示等待第一个播放器触发按需拉流，不是播放失败，播放器连接后会话轮询刷新为实际状态；播放器导航必须携带有效 Sense 会话 Cookie，且 Fetch Metadata 必须表明是同源 iframe，普通 API 的 `X-Product` 边界不变；设备分页和媒体路径不以 16 路作为硬上限，页面一次只打开一路流。
|
||
- **区域版本**：坐标为 0..1 归一化值，并绑定 Device、Profile、宽高。每次发布或停用形成新版本；范围、点数、自交、退化、方向和期望版本由后端校验。Profile 分辨率变化后旧版本必须标记为需要重新校准。
|
||
<!-- sense-mvp:end -->
|
||
|
||
|
||
<!-- bell-mvp:start -->
|
||
## Bell MVP 业务与安全规则
|
||
|
||
- **独立身份**：Bell 仅接受自己的 `bell_session`；管理员管理用户、角色与规则，操作员读取事件/预警并处置，只读用户仅查询。后端权限是最终边界。
|
||
- **安全初始化**：系统没有默认用户、密码或签名密钥；首次管理员密码只通过一次性进程环境传入，密码至少 12 位且包含大小写字母和数字。
|
||
- **Event 与 Receipt**：Event 正文不可更新或删除。相同 `(producer_id, source_event_id)` 与相同 payload 返回原回执；相同键但不同 payload 返回冲突，跨进程重启仍成立。
|
||
- **合成事件**：只在 development/test 注册，使用虚构匿名 fixture，并走与未来生产者适配器相同的 Event/Receipt 服务；production 直接请求返回 404。
|
||
- **规则评估**：每个已接收 Event 都记录匹配或未匹配解释。匹配时固化实际规则快照；未匹配 Event 保持可查询，不能标成已通知或已处置。
|
||
- **Alert 关联**：同一 Event 可产生多个 Alert；同一规则与地点的多个 Event 可聚合到同一未关闭 Alert，Event 与 Alert 双向可追溯。
|
||
- **处置状态**：界面“待处理”对应新 Alert，“处理中/已看到”对应首个成功 ack，“已完成”对应记录现场结果后的 close。普通用户不需要理解 Event/Alert 内部模型，技术详情仍保留完整事实链。
|
||
- **并发 ack**：PostgreSQL 条件更新只允许首个操作员成为处置人；后来者得到真实处置人，不能覆盖。
|
||
- **close**：只有处置人或管理员可以完成；必须选择“确认有危险、误报、现场正常、无法确认”之一，可附备注。相同重复请求幂等，其他改变结果的请求被拒绝。
|
||
- **审计事实**：成功生命周期事实只追加；失败、重复和拒绝尝试写入安全审计，但不记录令牌、密码或连接密钥。
|
||
<!-- bell-mvp:end -->
|
||
|