constitution.md 3.5 KB
多交易所Delta中性宪章
核心原则
一、库优先架构与现实测试
Specify中的每个功能必须首先作为独立库存在。任何功能都不得直接在应用程序代码中实现，必须首先抽象为可重用的库组件。
测试必须使用现实环境：
- 优先使用真实数据库而非模拟
- 使用实际服务实例而非存根
- 实施前必须进行契约测试
二、Delta中性优先
所有策略必须在任何时候都针对所有连接的交易所和账户对保持总Delta ≈ 0。除非缓解订单已在途中并已记录，否则每个资产的净敞口必须保持在±0.0005 BTC等值内。当利用率或敞口突破配置阈值时，必须立即进行重新平衡。
三、确定性市场数据摄取
系统必须维持每个交易场所的连续、低延迟订单簿访问（WebSocket主要，5秒内HTTP回退）。订单簿快照必须验证单调买卖价和深度新鲜度<2秒。任何降级的数据源必须在新交易执行前自动触发回退和警报。
四、资金保护与风险控制
每个账户必须执行可配置的头寸、杠杆和回撤上限。紧急止损路径必须在触发后30秒内取消或对冲剩余敞口。所有订单流必须携带幂等标识符和回滚计划，以防止部分失败期间的孤立敞口。
五、透明可观测性与审计
执行、对冲和清理服务必须为每个账户和交易所发出结构化日志、指标和健康信号。订单意图、成交、取消和余额快照必须通过关联ID进行端到端可追踪。历史操作必须通过持久化配置和可重放事件日志保持可重现性。
运营约束
平台必须维持高频信号评估（≤8秒循环），同时保持每次迭代计算在配置预算内。网络访问必须在需要时通过批准的代理路由，而不破坏延迟承诺。敏感凭据必须在静态时保持加密，轮换程序必须每季度演练。交易日志的数据保留必须满足最少90天重放要求。
工作流程与质量门槛
规划产物必须在开发开始前明确将功能映射到这些原则。规格必须声明敞口限制、数据源和测试矩阵。计划和任务必须安排对冲、订单清理和可观测性改进的TDD覆盖。拉取请求必须包含证据（日志、测试输出或仪表板），显示对原则一至六的持续合规性。任何偏差都需要在合并前记录缓解措施。
治理
本宪章取代交易堆栈的先前流程指导。修正案需要维护者共识、对保障措施影响的文档以及对依赖模板的更新。版本控制遵循SemVer：主要版本用于原则删除/不兼容治理，次要版本用于新原则或重大范围增加，补丁版本用于澄清。合规性审查必须至少每月进行一次，检查敞口报告、健康警报和测试覆盖率变化。偏差必须记录修复负责人和时间线。
版本: 1.2.0 | 批准: 2025-09-27 | 最后修订: 2025-09-28