25 KiB
工作交接 · 2026-09-20（持仓管理系统，换开发机之前）
写给下一个接手的会话，也写给换了新开发机的用户本人。读完这一份就能接着干，不需要回头翻聊天记录。
阅读顺序建议：先读仓库根目录的 CLAUDE.md，再读这一份，然后读 DEVLOG.md 的开头规则与最后三条节点。本文第二节是必须先处理的事，第三节是 2026-09-20 上午从服务器只读读回的实况，其余各节是背景与办法。附录标了「可不读」。
本文里反复出现三个名字，先说清。「155」是模拟仓服务器 192.168.16.155，持仓管理系统与选股系统都跑在上面。「188」是真实仓服务器 192.168.16.188，连着真实账户，决策系统也在上面。「选股系统」指仓库 akg-factor-bridge，它每个交易日早上出一份选股计划，持仓管理系统 08:40 拉取。
一、一句话现状
持仓管理系统在 155 上运行正常，代码到提交 f6e94cf（2026-09-18 午间部署），系统自决全开，账户里两只持仓、两条网格方案、没有待确认提议。真实仓 188 仍停在 08-28 的旧版本，等 QMT 一侧，没有人动过。
从 09-21 起的主线是「选股计划排序轴换成公司质地」的上线协同。持仓管理系统这一侧的代码已经写完并复审通过，而且已经提前生效，这件事需要用户在 09-22 早上之前拍一次板，见第二节第 2 条。
二、最要紧的四件事
1. 旧开发机上有没推送的提交，换机器前必须推
2026-09-18 盘点时，旧开发机上这几处只存在于本机。
| 仓库 | 没推送或没提交的东西 | 为什么要紧 |
|---|---|---|
| 选股系统 akg-factor-bridge | 提交 9acd3fa「pms_roster 档位白名单修补」没推送 | 这是 09-17 复审退回的那一处修补。日程要求 09-21 收盘后选股系统机器拉代码，它必须先推送并过复审 |
| 决策系统 bionic_trader | 6 个「方案副本同步」提交没推送 | 四个仓库的方案文档要逐字同步，缺这几份副本就不同步了 |
| astock-kg | CLAUDE.md 有未提交修改 |
提交或放弃，二选一 |
| quant_factor_service | 「第二阶段收工记录_20260831.md」没提交 | 提交 |
在旧开发机上运行，推送前者：
cd /Users/baobao/Documents/work/project/akg-factor-bridge && git push origin main
在旧开发机上运行，推送后者：
cd /Users/baobao/Documents/work/project/bionic_trader && git push origin main
持仓管理系统仓库本身是干净的，全部已推送。
2. 工作包乙已经提前生效，09-22 早上之前要拍板
背景。 《上线与协同阶段工作方案与规格书_2026-09-17》的工作包乙，让持仓管理系统在上游计划带 rank_axis 为 quality 时按上游名次排候选，不再按自己的立场分桶重排。提交是 f5cc1b8，台账第 016 条，复审通过。方案定的上线日是 09-23 收盘后，前提是 09-22 的六处读数干净，而且特意不与选股系统 09-21 拉代码放在同一天，理由是「两处同时变化说不清」。
实际发生了什么。 2026-09-18 11:52，为了上线页面改动，在 155 执行了一次 make deploy。f5cc1b8 是 09-17 提交的，就在这次部署里。四个容器从那一刻起跑的就是含工作包乙的代码。开关 PMS_PLAN_RANK_BY_UPSTREAM 读回为 True，这是代码默认值。
到今天为止有没有影响。 没有。这项功能靠上游计划顶层的 rank_axis 自门控。选股系统机器现在停在 3d3f317，出的计划不带这个键，持仓管理系统走的还是旧的排法。
什么时候会有影响。 09-21 收盘后选股系统拉代码并重启。09-22 早上 07:10 出第一份质地序计划。持仓管理系统 08:40 拉取时会自动切到上游序。这比方案早一天，并且与上游切轴落在同一个早上。
两个选择。
- 选择甲，接受提前生效。代码已复审通过，旧计划下逐字回旧有单测钉住。代价是 09-22 两处同时变，读数说不清时要靠名册快照里的
rank_mode区分。 - 选择乙，恢复方案原意。09-22 07:10 之前在参数页把
PMS_PLAN_RANK_BY_UPSTREAM关掉。09-23 收盘后再打开，同一天按拍板点六把PMS_PLAN_TIERS改成「强传导,弱传导」。不改代码，不重启。
建议选乙。 它只是一次页面改参数，却能让 09-22 的六处读数只反映上游一处变化。
选择乙的做法：登录 155 页面，切到运维视图，在「参数设置」里改。或者在 155 上运行下面这条，预期最后打印 False。
cd /home/factor/project/tradingSystem && docker exec pms-web python -c "from app.services import param_store as ps; ps.set_param('PMS_PLAN_RANK_BY_UPSTREAM', False, 'handoff'); print(ps.get('PMS_PLAN_RANK_BY_UPSTREAM', None))"
怎么核对它到底走的哪种序。 看名册快照元数据里的 rank_mode。09-18 及更早的快照里它是空的，因为那时还是旧代码。09-21 08:40 那份应当是 quality_bucket。开关开着且上游带 quality 时是 upstream。在 155 上运行：
cd /home/factor/project/tradingSystem && docker exec pms-web python -c "
from app.services import plan_feed as pf
import json
for r in (pf.snapshot_log(limit=3).get('rows') or []):
m = r.get('meta') or {}
m = json.loads(m) if isinstance(m, str) else m
print(r.get('plan_date'), r.get('fetched_at'), 'rank_mode', m.get('rank_mode'))
" 2>&1 | grep -v INFO
顺带一条：台账 016 的「上线」一段写的是「重建镜像加 force-recreate」，复审记录说「重启进程即可」。这两句现在都不用执行了，代码已经在跑。
3. 系统自决上线一周，自动采纳为零，四只候选全部因「研判不可用」交给了人
系统自决是 09-14 傍晚全开的，设计目标是弱表态候选在研判通过后自动买试探仓。第一周的真实读数如下，来自读数表 pms_consensus_stat 与提议表。
| 日期 | 代码 | 自决的结论 | 原因原文 | 写入时刻 | 后来 |
|---|---|---|---|---|---|
| 09-15 | 300308.SZ | 交人 | 研判不可用，降级人工确认 | 09:31 | 提议过期，没人裁决 |
| 09-17 | 688778.SH | 交人 | 研判不可用，降级人工确认 | 09:31 | 人工采纳，已建仓并自动挂上网格 |
| 09-18 | 002050.SZ | 交人 | 研判不可用，降级人工确认 | 09:33 | 人工采纳，截至 09-20 未见持仓 |
| 09-18 | 300073.SZ | 交人 | 研判不可用，降级人工确认 | 09:31 | 人工采纳，截至 09-20 未见持仓 |
四只全部卡在同一处：开盘后第一轮扫描向决策系统要研判，对方不可用，按铁律二交人。研判不可用的占比按真实行算是四比四，台账线是两成以下。300073.SZ 在别的时刻被研判驳回过四次，说明研判接口平时是通的，问题集中在 09:31 前后。
下个会话要查的方向。 一，决策系统研判接口在开盘头几分钟的超时。2026-09-01 查过一次根因：推理档的思考 token 挤爆预算，修法是 188 上决策系统 .env 的三行（EFFORT 改 low、MAX_TOKENS 改 16384、REPARSE 设 1）再重建 trader_worker_pms 容器，当时写的是「待用户执行」，是否已做没有核实。二，持仓管理系统一侧的研判超时参数够不够。三，首轮扫描要不要让开开盘头几分钟，或者对「研判不可用」的新建仓候选在几分钟后自动再问一次。动决策系统之前先答三题：为什么动、动哪里、怎么回退。
同一周的其他读数（155 上 make consensus-review DAYS=6，只读）。技术面无读数占比每天低于百分之一，台账线是百分之三。「等开口」每天 1 到 9 只，台账线是 1 到 15 只。五个交易日里「放行」为零。转空离场零条。盘中确认开关 PMS_TECH_INTRADAY_CONFIRM 仍是关的，原定 09-17 复核后再定，仓库里没有见到那次复核的记录。
4. 读数表里混进了单测写的假行，会让复核读数失真
现象。 复核脚本第五张表里有一只 600000.SH，每逢部署日就「采纳 · target_price」。账户里没有这只票，评审账本里它一行都没有。
机制。 单测的假仓储装配函数 install_fakes（scripts/test_wiring.py）只替换了 pms_repo 等几个仓储，没有替换读数表仓储 consensus_stat_repo。用例调用整轮扫描 scan_and_route 时，末尾的读数落表会走真仓储。开发机上没有数据库，这一步失败后被软失败吞掉，所以一直没人发现。155 上 make test 起的一次性容器带着真实的 .env，于是每跑一次全量单测，就往真表里写一行。
证据。 四行假数据的写入时刻，与四次在 155 跑 make test 的时刻逐一对上。
| 统计日 | 代码 | 类别 | 累计轮数 | 写入时刻 |
|---|---|---|---|---|
| 09-14 | 600000.SH | auto_accept | 2 | 09-14 16:45:13 |
| 09-15 | 600000.SH | auto_accept | 10 | 09-15 11:31:00 |
| 09-16 | 600000.SH | auto_accept | 2 | 09-16 09:42:12 |
| 09-18 | 600000.SH | auto_accept | 2 | 09-18 11:53:27 |
影响。 复核脚本第六张表「研判不可用占比」的分母被假行撑大，占比被低估。09-15 显示 50%，实为 100%。09-18 显示 66.7%，实为 100%。09-24 的读数与四周复核都会读这张表。
修法（下个会话做，属代码改动）。 install_fakes 把 consensus_stat_repo 的 upsert_many 与 delete_day_kind 也换成内存桩。另外两个调用整轮扫描的测试文件 test_batch14_units.py 与 test_batch21_units.py 同样检查。再加一例哨兵：装完假仓储之后，读数仓储的写函数不是真的那个。修完在 155 上跑一次 make test，确认读数表没有新增 600000.SH 的行。
清理。 只有上表四行。删除是数据库写操作，先向用户列出要删的行并拿到同意。本周 auto_accept 类别下没有任何真实行，所以可以按「统计日加类别」删，但下手前务必先用下面的只读命令再列一遍确认。在 155 上运行：
cd /home/factor/project/tradingSystem && docker exec pms-web python -c "
from app.repo import consensus_stat_repo as csr
for r in csr.list_range(20260914, 20260930, kinds=['auto_accept','auto_decline','auto_confirm','judge_unavail']):
print(r.get('stat_date'), r.get('ts_code'), r.get('kind'), r.get('rounds'), r.get('reason'), r.get('updated_at'))
" 2>&1 | grep -v INFO
三、服务器实况（2026-09-20 09:03 北京时间，只读读回）
模拟仓 155
| 项目 | 读数 |
|---|---|
| 仓库版本 | cb73f74（文档提交），代码到 f6e94cf |
| 代码指纹 | 26510ade120c，镜像与工作树一致 |
| 容器 | pms-web、pms-worker、pms-beat、pms-ws 四个都在，已运行 45 小时，即 09-18 11:52 部署以来没动过 |
| 持仓 | 两只：300627.SZ 与 688778.SH |
| 交易方案 | 两条网格，都在运行：300627.SZ 与 688778.SH |
| 待确认提议 | 0 |
| 单测 | 904 例，09-18 部署时 ALL SUITES PASS |
关键运行参数，全部读自参数中心。
| 参数 | 值 | 白话 |
|---|---|---|
| PMS_DISPATCH_MODE | ws | 指令真的发给模拟 QMT |
| PMS_AUTONOMY | full | 持仓上的四类动作全自动 |
| PMS_OPEN_AUTONOMY | propose_only | 新建仓名义上只提议，实际由系统自决那一层先决定 |
| PMS_SELF_DECIDE | full | 系统自决全开 |
| PMS_SELF_DECIDE_TRIAL | True | 五类试探仓情形允许自动采纳 |
| PMS_SELF_DECIDE_DAILY_MAX | 3 | 每天最多自动新建仓三只 |
| PMS_STRATEGY_ENABLED | True | 策略层开着，用户 09-14 确认是有意的 |
| PMS_TECH_EXIT_AUTONOMY | full | 技术面转空自动离场 |
| PMS_TECH_INTRADAY_CONFIRM | False | 盘中确认仍关，等复核后拍板 |
| PMS_PLAN_RANK_BY_UPSTREAM | True | 见第二节第 2 条 |
| PMS_PLAN_RANK_BY_QUALITY | True | 旧的按立场分桶排，上游序生效时它退场 |
| PMS_PLAN_TIERS | 强传导 | 拍板点六建议 09-23 改成「强传导,弱传导」 |
| PMS_PLAN_TOP_N | 50 | 与选股系统入池的五十对上 |
| PMS_PLAN_THEME_CAP | 0 | 不向上游传主题限额，用上游默认每主题五只 |
| PMS_CONSENSUS_STAT_TIMES | 0935,1030,1330,1445 | 观察读数的四个检查点 |
| PMS_PROPOSAL_TTL_HOURS | 24 | 但提议最晚当天 23:59:59 失效，不跨自然日 |
| PMS_MACRO_ENABLED 与 PMS_MACRO_AUTONOMY | True 与 full | 大盘冷热这一层开着 |
| PMS_TOTAL_SCALE | 2000000 | 总规模两百万 |
155 的工作树里有几样服务器本地的东西：scripts/deploy.sh 的权限位变化、backups/、celerybeat-schedule、pms_public.pem、prof_open_scan.py。它们不挡 git pull，不要提交，也不要删。
选股系统在 155 上的仓库版本是 3d3f317，按日程 09-21 收盘后才拉新代码。
真实仓 188
仓库停在 51bd6dc（08-28），落后主干 112 个提交。只跑着 pms-web 与 pms-ws 两个容器，已运行三周。这台没有源码挂载文件，代码确实在镜像里。追平之前必须先过真实仓初始参数清单：下发模式 shadow、自主档 propose_only、新建仓关、策略层关、转空离场 propose_only、系统自决 off 与 False 与 1。任何写操作先经用户审批。
四、这一周做完了什么
按日期列，括号里是提交号。细节都在 DEVLOG.md 对应日期的节点里。
- 09-14。 观察读数包（f2d6b37，新表
pms_consensus_stat与复核脚本）、加固包（e21b73b）、文档包（b1ebb36）。盘中确认包（1ccd542，部署时开关关着）。页面收尾包（2f64274）。系统自决包（44ec6d4，评审修订 980235c，台账 015）。页面专业化包（c94787a 与 77db6b8，含文案守卫）。选股打分包（选股系统 3d3f317，持仓管理系统 de06c77）。傍晚系统自决全开。 - 09-15。 个股详情抽屉重做（e3fb0c6、9ef5e4c）。三个维度统一成基本面、技术面、择时，同一套颜色（e14c9d9）。建仓候选行不再溢出（8ff4ea3、c3de056）。持仓表操作列折叠成一枚菜单，状态列短语加悬停说明（78b6c69）。
- 09-16。 待确认提议不跨自然日失效，盘前与每轮扫描开头清扫过期提议。管理视图持仓总览加「状态 · 下一步」列。选股计划标成数据日（03e4dd5）。
- 09-17。 工作包乙，候选按上游名次排（f5cc1b8，台账 016）。这是另一个会话做的，当时没有写开发节点记录，本次在 09-20 的节点里补了一笔。
- 09-18。 个股深度评析报告改成页内排版。组合操作与纪律设置移到运维视图新页。顶栏改成单行标签加菜单（f6e94cf）。
五、还欠着什么
第二节的四件事不再重复。其余按要紧程度排。
- 用户页面验收。 09-15、09-16、09-18 三批页面改动都已部署，等用户登录 155 逐项看：顶栏单行与右上角菜单、运维视图「组合操作」页、评析报告抽屉、持仓表「⋯」菜单与「状态 · 下一步」、建仓候选行、管理视图持仓总览。
- 盘中确认开关。
PMS_TECH_INTRADAY_CONFIRM仍关。原计划 09-17 复核观察读数无异常后由用户在页面打开。 - 688778.SH 两天内两次对账修正（负 1400 股、负 200 股，都是「以下游为准冲销批次」）。这只票挂着网格，值得查一下网格成交回放与账本之间为什么会差出来。
- 真实仓准备包。 初始参数自检脚本
scripts/real_init_params.py、台账 014、追平清单。准备件可以先做，执行等 QMT 一侧。 - 系统自决的两个不阻塞项。 自动采纳的评审方应写 system 并按评审方计数。接口契约文档要补裁决请求体与预设理由接口。
- 「下一步」短语的依据。 持仓表与抽屉里的「下一步」只按三票立场与转空相位推断，没有读真实的增持门与离场纪律状态。
- 小的文档与页面欠账。
FRONTEND_TRADER_VIEW_PLAN.md第 5 节仍写着组合操作在交易员右栏。评析抽屉不能用 Esc 关闭。 - 155 读数表里两行 09-11 的遗留种子数据，要不要删等用户定。
- 八月遗留，此后没有再核实过。 公示导出的表格样式用户说「还是不对」但没有指认差异。三个口径待拍板。仓库根目录的公司原表 xlsx 是未跟踪状态。
六、本周日程里与持仓管理系统有关的几天
完整日程在《上线与协同阶段工作方案与规格书_2026-09-17》第四节，这里只摘与本仓库有关的。
| 日期 | 事情 | 持仓管理系统这边要做什么 |
|---|---|---|
| 09-21 周一 | 收盘后选股系统机器拉代码并重启接口容器，经审批，避开 07:00 到 07:30 与 08:30 到 09:05 | 先确认 9acd3fa 已推送并过复审。早上 08:40 之后顺手看一眼名册快照的 rank_mode 是不是 quality_bucket |
| 09-22 周二 | 07:15 后核首份质地序计划的六处读数，再核「两条路同一份前二十」 | 07:10 之前按第二节第 2 条的拍板结果处理开关。名册主榜行数会从六十到一百行跳到接近三百行，属预期 |
| 09-23 周三 | 原定收盘后上线工作包乙 | 若选了乙：收盘后打开开关，并把 PMS_PLAN_TIERS 改成「强传导,弱传导」，台账补一行 |
| 09-24 周四 | 08:45 后核候选序 | 在一次性容器里调候选选择函数，核 rank_mode 为 upstream、名次递增。命令在工作方案第六节 |
| 09-25 周五 | 首份带两份对照名单的周报 | 无 |
| 10-16 前后 | 排序轴四周复核 | 读数表要先清干净，见第二节第 4 条 |
七、机器、部署，以及一个新核实的事实
登录。 模拟仓：ssh -p 2280 factor@192.168.16.155，项目在 /home/factor/project/tradingSystem，页面端口 38100。真实仓：ssh -p 2280 tlai@192.168.16.188，项目在 /mnt/work/project/tradingSystem，页面端口 38200。代码服务器是 Gitea，地址 git@192.168.18.24，本仓库是 zlt/tradingSystem。
部署。 在开发机改代码并提交推送，然后在 155 上 git pull --ff-only && make deploy && make test。判收看四样：ALL SUITES PASS、make stale 指纹一致、四个容器健康、通道 ONLINE。用户认可盘中部署，通道会自动重连，不必等收盘。
新核实的事实：155 上源码是挂载进容器的。 155 的项目目录里有一个服务器本地文件 docker-compose.override.yml，内容与仓库里的 docker-compose.dev.yml 相同，它把整个仓库目录绑定挂载到四个容器的 /app。这个文件被 .gitignore 忽略，所以仓库里看不到。188 没有这个文件。它带来四个后果。
- 在 155 上
git pull之后，页面静态文件立刻就是新的，因为每次请求都从磁盘读。后端四个进程仍是旧代码，直到重启或make deploy。 make test与make stale起的一次性容器读的也是工作树。所以在 155 上「指纹一致」恒成立，它查不出「拉了代码没重启」。这道护栏只在 188 这种没有挂载的机器上才真的起作用。- 只改页面或文档时，拉代码即生效。改了 Python 必须让进程重启。
make deploy仍然是最稳的一条路，它重建镜像、重建容器、顺带建表。只重启不重建的命令是docker compose --profile sched --profile ws restart -t 30，同样要先经审批。 - 往 155 拉代码这件事本身就等于「上线了一半」。第二节第 2 条就是这么来的。以后往 155 拉代码之前，先看一眼
git log里有没有别的会话提交的、还没到上线日的改动。
四条服务器铁律（用户 2026-08-31 立的）：不重启不关机；容器的重启与重建先列命令与影响，拿到审批再做；数据库容器除审批外还要说明原因；不进无关项目的目录。155 上别人的 quant_* 容器、188 上的 bionic_trader 系列容器都不要碰。
八、工作纪律与用户偏好
纪律。
- 输出遵守
.claude/output-styles/readable-chinese.md：完整句子，一句一事，不自造缩写，术语先用白话解释。 - 每次交付附用户能亲手运行的验证命令，写明预期读数，标明在哪台机器上运行，一个命令块只放一台机器。
- 重要工作往
DEVLOG.md追加五段式节点：做了什么、动了哪些文件、部署方式、真机判收、还欠着什么。判收只写「真机见过」或「未判收」。 - 时间一律写北京时间。容器时钟是北京时间。155 宿主机的
date是 UTC。数据库时间列是 UTC，要加八小时。 - 动持仓管理系统以外的系统之前先答三题：为什么动、动哪里、怎么回退。
- 加测试文件必须同时登记进
scripts/run_tests.py的清单与例数表。改结构性的东西先对一遍那份哨兵清单。 - 改页面后三道守卫一起跑：枚举、接线、文案。模板里不写自闭合的自定义标签。
用户对页面的偏好（多次返工换来的）。
- 措辞专业，像交易系统。不出现内部设计词，例如合议、路由、交人。不自造简写。
- 同一个概念在所有地方用同一套维度与同一套颜色：基本面、技术面、择时；看多红，看空绿，中性灰，无读数虚框。
- 表格必须在中栏放得下。说明文字进悬停，不占格。不常用的操作可以折叠。
- 改完就部署，盘中重建容器可以接受。
九、新开发机开工步骤
- 旧机器上先做完第二节第 1 条的推送。
- 把旧机器上的迁移包
~/Documents/work/claude-migrate-20260918.tar.gz拷到新机器。里面是五个项目的 Claude 记忆、各仓库被忽略的.claude目录（输出风格与项目设置）、全局设置。注意持仓管理系统仓库的.gitignore第 19、20 行忽略了输出风格与项目设置，克隆下来没有它们，必须从迁移包里取。 - 新机器生成 SSH 密钥，公钥登记三处：Gitea 账号 zlt（网页上加）、155 的 factor 用户、188 的 tlai 用户。后两处是服务器写操作，先经用户同意。
- 克隆仓库，解包，必要时把记忆目录按新用户名改名。目录名的规则是项目绝对路径里的非字母数字字符都换成横线。
在新开发机上运行，克隆：
mkdir -p ~/Documents/work/project && cd ~/Documents/work/project && git clone git@192.168.18.24:zlt/tradingSystem.git && git clone git@192.168.18.24:zlt/akg-factor-bridge.git && git clone git@192.168.18.24:tlsj/bionic_trader.git
在新开发机上运行，解包：
cd ~ && tar -xzf ~/Documents/work/claude-migrate-20260918.tar.gz
在新开发机上运行，建测试环境并跑全量单测，预期最后一行是 ALL SUITES PASS，共 904 例：
cd ~/Documents/work/project/tradingSystem && python3 -m venv ~/venvs/pms && ~/venvs/pms/bin/pip install -r requirements.txt -q && ~/venvs/pms/bin/python scripts/run_tests.py | tail -2
开发机上取不到代码指纹时单测会跳过新旧判断，不影响判定。第二十四批有一例在早上 09:36 之前跑必然失败，那是用例对时钟的假设，不是代码问题。
十、新窗口的开场白
可以直接把下面这段贴给新会话。
先读 CLAUDE.md、docs/交接_2026-09-20.md、DEVLOG.md 的开头规则与最后三条节点。读完后只读核对 155 的仓库版本、四个容器状态、PMS_PLAN_RANK_BY_UPSTREAM 的当前值，然后告诉我交接文档第二节四件事各自的现状，等我拍板再动手。
附录甲（可不读）：不部署就能看页面效果的办法
docs/dev_preview/mock_preview.py 是一个只给开发机用的假后端。它托管 app/web/static 里的真页面，给顶栏、持仓表、建仓候选栏、个股详情抽屉、评析报告抽屉、运维视图「组合操作」页喂固定的假数据。其余接口一律回「预览无后端」，页面顶部会有一条错误提示，不影响看样式。
在开发机上运行：
cd ~/Documents/work/project/tradingSystem && ~/venvs/pms/bin/python docs/dev_preview/mock_preview.py
然后浏览器打开 http://127.0.0.1:38199/。地址后面加 #detail=300627.SZ 可以直达个股详情抽屉。
两个坑写在脚本开头的说明里：仓库放在 macOS「文稿」目录下时，由别的程序拉起的进程可能读不到页面文件，要先把静态目录拷出来再用环境变量指过去；页面新读了哪个接口，就得在脚本里补一个同形状的假应答。这个脚本放在 docs/ 下是有意的，代码指纹只覆盖 app/、scripts/、config/ 三个目录。
量页面布局时用浏览器的脚本控制台读元素的宽高最可靠。历次用过的宽度档位是 1920、1680、1440、1280、1180。
附录乙（可不读）：本次核对用的只读命令
在 155 上运行，读版本、指纹与容器：
cd /home/factor/project/tradingSystem && git log --oneline -1 && make stale | tail -1 && docker compose ps --format "table {{.Name}}\t{{.Status}}"
在 155 上运行，读一周的观察读数，六张表：
cd /home/factor/project/tradingSystem && make consensus-review DAYS=6
在 155 上运行，确认源码是不是挂载的：
docker inspect pms-web --format "{{range .Mounts}}{{.Source}} -> {{.Destination}} ({{.Type}}){{println}}{{end}}"
在 155 上运行，读通道状态，预期「连接 ONLINE」：
cd /home/factor/project/tradingSystem && docker compose run --rm --no-deps pms-web python scripts/ws_smoke.py status 2>&1 | head -12