constitution.md 5.1 KB
多交易所Delta中性宪章
核心原则
一、库优先架构与现实测试
追求高内聚低耦合的设计思维，编写结构良好、可复用的代码。为可复用性而设计，而非为了成为库而变复杂，避免过度设计。系统必须支持模块化、组件化、服务化架构，便于敏捷开发、持续集成和高扩展性。
核心HTTP客户端库必须维持企业级性能标准：响应时间<100ms、99.9%可用性、支持1000+并发请求。所有平台适配器必须实现统一接口，支持Ed25519（Pacifica）、EIP-191（Aster）、HMAC-SHA256（Binance）认证。代理管理必须包含负载均衡、健康检查、自动故障转移。
测试必须使用现实环境：
- 优先使用真实数据库而非模拟
- 使用实际服务实例而非存根
- 实施前必须进行契约测试
- 集成测试必须覆盖真实工作流
- 性能测试必须在生产类似环境中进行
- 所有测试必须在CI中自动运行
- HTTP客户端库必须通过TDD开发，测试先行
二、Delta中性优先
所有策略必须在任何时候都针对所有连接的交易所和账户对保持总Delta ≈ 0。除非缓解订单已在途中并已记录，否则每个资产的净敞口必须保持在±0.0005 BTC等值内。当利用率或敞口突破配置阈值时，必须立即进行重新平衡。
三、确定性市场数据摄取
系统必须维持每个交易场所的连续、低延迟订单簿访问（WebSocket主要，5秒内HTTP回退）。订单簿快照必须验证单调买卖价和深度新鲜度<2秒。任何降级的数据源必须在新交易执行前自动触发回退和警报。通用HTTP客户端必须支持实时数据流、批量请求处理和连接池管理。
四、资金保护与风险控制
每个账户必须执行可配置的头寸、杠杆和回撤上限。紧急止损路径必须在触发后30秒内取消或对冲剩余敞口。所有订单流必须携带幂等标识符和回滚计划，以防止部分失败期间的孤立敞口。HTTP客户端必须实现全面错误处理、自动重试机制和熔断器模式。
五、透明可观测性与审计
执行、对冲和清理服务必须为每个账户和交易所发出结构化日志、指标和健康信号。订单意图、成交、取消和余额快照必须通过关联ID进行端到端可追踪。历史操作必须通过持久化配置和可重放事件日志保持可重现性。HTTP客户端必须提供性能监控、SLA跟踪和实时健康检查。
运营约束
平台必须维持高频信号评估（≤8秒循环），同时保持每次迭代计算在配置预算内。网络访问必须在需要时通过批准的代理路由，而不破坏延迟承诺。HTTP客户端代理池必须支持地理合规、IP轮换和自动故障转移。
敏感凭据必须在静态时保持加密，轮换程序必须每季度演练。交易日志的数据保留必须满足最少90天重放要求。HTTP客户端必须支持多种认证方式的安全存储和自动轮换。
API响应缓存必须考虑数据新鲜度要求，批量请求处理必须包含并发控制和错误隔离。连接池管理必须优化资源利用率并防止连接泄漏。
工作流程与质量门槛
规划产物必须在开发开始前明确将功能映射到这些原则。规格必须声明敞口限制、数据源和测试矩阵。计划和任务必须安排对冲、订单清理、可观测性改进以及HTTP客户端库性能验证的TDD覆盖。
拉取请求必须包含证据（日志、测试输出或仪表板），显示对原则一至五的持续合规性。任何偏差都需要在合并前记录缓解措施。HTTP客户端库的更改必须包含性能基准测试和向后兼容性验证。
新的平台集成必须完整实现数据接口（价格、订单簿、K线、交易历史）和操作接口（订单创建、修改、取消、批量操作），包括WebSocket实时数据流和全面的错误处理。
治理
本宪章取代交易堆栈的先前流程指导。修正案需要维护者共识、对保障措施影响的文档以及对依赖模板的更新。版本控制遵循SemVer：主要版本用于原则删除/不兼容治理，次要版本用于新原则或重大范围增加，补丁版本用于澄清。
合规性审查必须至少每月进行一次，检查敞口报告、健康警报、测试覆盖率变化以及HTTP客户端库性能指标。偏差必须记录修复负责人和时间线。库的发布必须遵循语义版本控制，包含完整的变更日志和迁移指南。
版本: 1.3.0 | 批准: 2025-09-27 | 最后修订: 2025-09-28