Runtime Entry
启动与运行时入口
负责配置加载、数据库初始化、进程模式、日志与守护流程，不承担策略判断本身。
输入配置、环境变量、网关初始化
输出可运行的 runner / monitor 进程
项目展示 / engineering case study
risk-control-hub
面向 vn.py / CTP 期权账户的风险监控与执行中枢，把 retrace、STM、监控和部署约束收束成一个真实可运行的工程系统。
量化风控工程
交易系统架构
可观测性设计
问题定义
它解决的是“真实账户风控闭环”，不是一个营销型量化页面。
页面、工作流、状态持久化和部署入口都服务于同一件事：把一个正在运行的期权账户风险控制系统解释清楚。
如果策略逻辑、执行状态、监控面板和部署入口互相脱节，那么任何一个“看起来能跑”的页面都不足以证明这是真正可交付的系统。
这个仓库把账户真实持仓、触发条件、执行工作流、Web 监控、Docker 项目检查和部署验证连成一条可追溯路径，重点不是“信号漂亮”，而是“边界不失真”。
真实约束
围绕真实账户持仓运转，不能把本地推断结果当成事实来源。
不是在做
不是普通的 K 线策略宣传页，也不是只展示指标卡的 SaaS 仪表盘。
关键难点
同一项目里同时收敛风控逻辑、执行链路、监控可视化和部署治理。
对招聘有价值
更能体现系统边界意识、异常处理思路和工程判断，而不是单点编码速度。
- 兼顾 `retrace` 与 `STM` 逻辑，不把复杂度藏在空泛的 facade 层后面。
- 监控视图不是附属 demo，而是运行时和策略状态的读取界面。
- 部署入口、worktree、merge 流程被纳入工程规则，减少“本地能跑”与“可交付”之间的断层。
系统边界
系统被刻意拆成四个边界清晰的层：入口、策略域、监控层、部署镜像。
这页不是讲“模块很多”，而是讲每一层为什么存在，以及为什么不能混在一起。
Strategy Domain
策略与执行域
处理 `retrace`、`STM`、净义务、订单推进、暂停保护等核心业务规则，把业务事实建模成明确的工作流。
输入Tick、Position、Order、Trade 事件
输出决策、快照、告警、执行指令
Monitoring Surface
监控与文档读取层
Flask 页面读取数据库与快照，不直接承载策略逻辑；它的职责是把系统正在发生什么解释给操作者看。
界面策略总览、Docker 监控、文档入口
语义状态读取而不是“再实现一遍策略”
Deploy Mirror
部署镜像与闭环规则
主分支之外的部署镜像保证“合并到 main”与“真正可部署”是两件被分别验证的事情，避免功能分支即交付的错觉。
唯一入口`deploy/deploy-main.ps1`
目标让部署验证成为工程规则，而不是口头承诺
核心工作流
从真实持仓到订单推进，中间不是黑箱，而是一条可解释的事件链。
这页刻意用状态与步骤表达，而不是放一大段业务术语，目的是让面试官能在一分钟内判断我是否真的理解系统流向。
账户持仓是真值
不依赖“本地估算剩余量”做最终判断，所有 workflow 都围绕真实账户状态推进。
先解锁，再触发
`trigger_arm_ratio` 先建立隔离带，避免还没形成有效回撤时就进入平仓流程。
Retrace 与 STM 分工
`retrace` 负责回撤平仓，`STM` 处理净义务与价格簇；两者协作但不混写成一团。
订单推进可追踪
`QUEUE → TAKER`、撤单重挂、双活保护、缺盘口暂停，都是显式状态，不是隐藏副作用。
暂停与退出有条件
完成条件、价格回落退出、残留活动单处理都被纳入 workflow，不留“靠经验看”的灰区。
Retrace 触发语义
价格先进入隔离带，再按 `lowest_price → trigger_price` 关系判断是否启动回撤平仓。
Direct Rise 兜底
从未 retrace 触发过的 symbol 可以走直接上升触发路径，防止单边风险被遗漏。
STM 候选筛选
按 `base_bid_1`、价格簇和 MAD 护栏选择可执行候选，而不是把所有腿一股脑打出去。
可观测性
监控页面不是摆设，它承担的是“把系统现在正在发生什么说清楚”。
因为这份展示页不放真实截图，我用纯 HTML/CSS 把监控页最关键的语义重构出来：组合、状态、事件、Docker 项目摘要。
monitoring intent
- 同一个首页里能从组合总览切到合约详情，再进到触发逻辑和执行状态，说明前端不是“好看”而是“可解释”。
- 状态快照、事件流和数据库读取被拆开处理，监控层负责读取和呈现，而不是再实现一次业务逻辑。
- Docker 项目监控页把运行容器、账户标注和定时摘要汇总成项目级视角，方便值班和排障。
- stale 快照保留、文档页面、导航切换这些细节体现的是操作层设计，而不是单纯“有个页面”。
组合总览
6 个 risk bucket / 2 个正在推进 / 1 个 SPECIAL
账户上下文
variant: prod-a · front stale threshold · socket push
RETRACE
IF2505-C-3300 · lowest / trigger / source
STM
cluster split · eligible candidates · fillable volume
Orders
QUEUE → TAKER · active order · pending cancel
Docker
running containers · account labels · project digest
最近事件
08:45
bucket 进入 SPECIAL，过滤后 planned_volume 小于 fillable_volume
WARN
08:46
触发逻辑更新，lowest_price 被新 tick 刷新
INFO
08:47
撤单重挂后旧单仍活跃，双活保护触发暂停
HIGH
08:48
Docker 汇总已推送，项目页显示账户名称退化提示
OPS
为什么这很重要
一个有价值的监控界面，应该能让操作者回答四个问题：现在在跟踪什么、为什么触发、执行到哪、哪里需要介入。
工程判断
比“写了很多代码”更重要的，是我在哪些地方刻意立规矩。
面试里真正能区分水平的，通常不是某个 API 会不会写，而是能不能在系统边界最容易失真的地方做出稳定的判断。
账户真实持仓是唯一真值
订单回报和成交回报只用于推进状态，不把“本地剩余量推断”当成事实，降低状态漂移带来的错误决策。
部署入口必须唯一
Docker 部署统一走 `deploy/deploy-main.ps1`，避免“在哪个目录执行 compose 都行”这种会制造偶发事故的习惯。
功能改动必须在 worktree 闭环
把实现、验证、merge、cleanup 收束到独立 worktree，避免在主工作区上边做边试，留下不可信的交付状态。
领域服务不靠 facade 掩盖复杂度
上层直接调用具体服务/基础设施，让复杂度暴露在正确的位置，而不是用 coordinator 名字把问题藏起来。
质量证明
质量不是一句“测过了”，而是一整套能证明自己没在自欺欺人的证据链。
这个仓库对测试、merge、deploy 和 cleanup 都有强约束，这种“让流程替我防错”的倾向，本身就是工程成熟度的一部分。
test surface
| 层 | 验证对象 | 意图 |
|---|---|---|
| Workflow | `retrace` / `STM` / state workflow | 确认触发语义、执行推进、暂停与退出条件 |
| Persistence | 快照 roundtrip、state repository | 防止运行时重启后状态不可恢复 |
| Web | monitor、docs、docker page tests | 证明读取层能正确解释后端数据与页面结构 |
| Deploy | Dockerfile、compose、deploy script | 把“可部署”从口头描述变成脚本化检查 |
双活保护
撤单重挂后旧单仍活跃就暂停，宁可显式告警，也不接受静默超量平仓。
缺盘口暂停
关键盘口字段连续缺失达到阈值就暂停 workflow，避免在数据残缺时继续下单。
stale 快照保留
当 Docker daemon 暂不可达时保留最后成功快照，而不是把页面清空成误导性“全正常”。
verification ladder
01
本地测试
先在功能 worktree 里跑对应测试，确认修改没有破坏预期行为。
02
合并到 main
非只读任务默认不以“功能分支通过”为完成，而要进入主分支闭环。
03
同步 deploy-main 并跑部署检查
运行时改动需要把目标提交同步到 `.worktrees/deploy-main`，并通过 `docker compose config`、服务启动和容器内关键环境变量检查。
收尾
如果你希望看到的不是“我做了个页面”，而是“我能把一个高风险系统讲清楚并做成可交付工程”，这就是最合适的样本。
这页已经接入当前作品集站点，同时保留独立 deck 的叙事节奏，方便在站内外都作为完整项目案例阅读。
risk-control-hub shows how I think about real systems.
它展示的不只是量化风控领域理解，也包括：如何给工作流定边界，如何把监控做成解释界面，如何让 merge / deploy / cleanup 变成工程流程的一部分。
Python 系统设计
量化风控工程
Flask 监控界面
Docker 部署治理
Workflow / 状态机
测试与验证意识