ch14-14 上线前披露

先定义产品场景

产品小节先看上线闭环：交易、数据、风控、钱包和运维必须一起设计，不能只列功能按钮。

源码入口

packages/deepbook/tests：测试 fixture、断言或可复现验证材料。
packages/deepbook_margin/tests：测试 fixture、断言或可复现验证材料。
packages/predict/tests：测试 fixture、断言或可复现验证材料。
crates/server/README.md：REST API、数据库查询、健康检查或指标实现。

把系统拼起来

金融应用上线前至少说明：智能合约风险、预言机风险、流动性风险、清算风险、数据延迟风险、交易失败风险和网络拥堵风险。开发者不能把模拟收益当成确定收益。

上线前披露要覆盖协议风险、oracle、清算、费用、数据延迟和运维降级。披露不是营销文案，而是把用户可能亏损、交易失败或看到延迟数据的场景提前写清。

产品落地判断

从用户动作出发写清 PTB 输入、type arguments、权限对象、签名者和预期 digest。
前端状态要区分钱包签名、链上确认、Indexer 可见和 Server API 缓存刷新。
机器人和后端服务必须有库存、价格、checkpoint lag、错误率和人工暂停阈值。
上线前为费用、滑点、oracle、清算、数据延迟和失败重试准备明确披露。

动手检查

用户完成本节场景时，最小 PTB、API 查询和 UI 状态分别是什么？
失败时应展示权限、余额、价格、oracle、清算、RPC 还是 Indexer 延迟中的哪一类原因？
这个应用 MVP 上线前还缺哪项测试、监控、暂停开关或风险披露？