用途：为手机上的资金类应用提供规格化领域知识，适用于钱包、支付、托管与签名、交易生命周期、KYC/AML 门控及离线对账等场景。它不是框架知识，而是金融领域特有的设计约束。
主要能力与要点： 一、余额有三种状态：confirmed（服务器已确认，并标注时间）、pending（本地乐观展示，需标注）、unknown（未连上服务器，绝不能把旧值当现值显示）。每个余额必须附“截至何时”。 二、幂等键必须比进程活得久：在意图离开界面前生成，并与意图在同一次持久化写入中保存；键属于用户意图而非尝试次数；服务器契约需说明幂等窗口时长，短于重试退避等于没有幂等。 三、密钥绝不进入 JavaScript 内存：签名发生在平台安全硬件（Keychain/Secure Enclave、Keystore/StrongBox）中；助记词或私钥绝不放 JS 变量；非托管意味着不可恢复，须在创建密钥前告知；签名确认需解码展示实际签名内容。 四、交易是状态机并需写下来：至少包括 drafted、submitted、accepted、settled、rejected、unknown，unknown 是真实状态，不可猜、不可盲重试、不可显示为失败；每个非终态需有超时与负责方；终态不可被迟到的重试队列重新驱动。 五、设备时钟不得用于排序金融事件：排序来自服务器或服务器签发的逻辑时钟，设备时间只作观测元数据。 六、对账是功能而非错误路径：重连后以服务器视图为准，差异须显式呈现不可静默覆盖；对账需幂等可恢复；服务端未收到的本地待发意图应重新询问用户而非自动发送。 七、被阻断账户是设计状态：KYC/AML 状态包括未验证、审核中、已验证、受限、冻结，各自有真实界面说明用户能做什么；限制或冻结须在下一操作生效；冻结理由不入 UI；重新验证状态存于服务器端。 八、系统在后台截图：余额、账号及密钥类信息在进入后台时需遮蔽；提供时可检测录屏与截图；剪贴板内容需过期处理。 九、需建模的实体：意图、交易、余额快照、对账运行、验证状态、密钥引用、限额，并注明各自非显而易见之处。
适用场景：移动端钱包、支付、托管、非托管签名、KYC/AML 与离线对账应用的设计与评审。
限制：适用范围止于手机端自身问题；支付范围与 PSP 机制、账本完整性与复式记账、链上预言机与 MEV、金融应用商店政策、框架性能均不在本包范围内，需另寻对应评审工具。具体安装命令与使用步骤暂未提供。