tradingSystem/docs/交接_2026-09-20.md

# 工作交接 · 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-20 更正）

2026-09-18 盘点时曾判定选股系统的 9acd3fa 与决策系统的 6 个方案副本提交「没推送」。那次没有先取远程状态，看的是过期的本地跟踪引用，结论是错的。2026-09-20 用 `git fetch` 加 `git ls-remote origin main` 直接向代码服务器核对，三处仓库本地与远程完全一致。

| 仓库 | 远程 main 的提交 | 本地与远程 |
|---|---|---|
| 持仓管理系统 tradingSystem | 本文档所在提交 | 一致 |
| 选股系统 akg-factor-bridge | 9acd3fa「pms_roster 档位白名单修补」 | 一致，领先 0 落后 0 |
| 决策系统 bionic_trader | 706a383「方案副本同步：复审记录」 | 一致，领先 0 落后 0 |

9acd3fa 是 09-17 复审退回的那一处修补。它已经在远程，09-21 收盘后选股系统机器拉代码时拿得到。它有没有过复审，仓库里没有见到记录，拉代码之前要确认。

旧机器上只剩两处没提交的小东西，都不在本仓库：astock-kg 的 `CLAUDE.md` 有未提交修改；quant_factor_service 的「第二阶段收工记录_20260831.md」没有入库。要不要提交由用户定。

教训一条：判断「有没有推送」之前先 `git fetch`，或者直接用 `git ls-remote` 问远程。

### 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。

```bash
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 上运行：

```bash
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 上运行：

```bash
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）。

---

## 五、还欠着什么

第二节的四件事不再重复。其余按要紧程度排。

1. **用户页面验收。** 09-15、09-16、09-18 三批页面改动都已部署，等用户登录 155 逐项看：顶栏单行与右上角菜单、运维视图「组合操作」页、评析报告抽屉、持仓表「⋯」菜单与「状态 · 下一步」、建仓候选行、管理视图持仓总览。
2. **盘中确认开关。** `PMS_TECH_INTRADAY_CONFIRM` 仍关。原计划 09-17 复核观察读数无异常后由用户在页面打开。
3. **688778.SH 两天内两次对账修正**（负 1400 股、负 200 股，都是「以下游为准冲销批次」）。这只票挂着网格，值得查一下网格成交回放与账本之间为什么会差出来。
4. **真实仓准备包。** 初始参数自检脚本 `scripts/real_init_params.py`、台账 014、追平清单。准备件可以先做，执行等 QMT 一侧。
5. **系统自决的两个不阻塞项。** 自动采纳的评审方应写 system 并按评审方计数。接口契约文档要补裁决请求体与预设理由接口。
6. **「下一步」短语的依据。** 持仓表与抽屉里的「下一步」只按三票立场与转空相位推断，没有读真实的增持门与离场纪律状态。
7. **小的文档与页面欠账。** `FRONTEND_TRADER_VIEW_PLAN.md` 第 5 节仍写着组合操作在交易员右栏。评析抽屉不能用 Esc 关闭。
8. **155 读数表里两行 09-11 的遗留种子数据**，要不要删等用户定。
9. **八月遗留，此后没有再核实过。** 公示导出的表格样式用户说「还是不对」但没有指认差异。三个口径待拍板。仓库根目录的公司原表 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 没有这个文件。它带来四个后果。

1. 在 155 上 `git pull` 之后，页面静态文件立刻就是新的，因为每次请求都从磁盘读。后端四个进程仍是旧代码，直到重启或 `make deploy`。
2. `make test` 与 `make stale` 起的一次性容器读的也是工作树。所以在 155 上「指纹一致」恒成立，它查不出「拉了代码没重启」。这道护栏只在 188 这种没有挂载的机器上才真的起作用。
3. 只改页面或文档时，拉代码即生效。改了 Python 必须让进程重启。`make deploy` 仍然是最稳的一条路，它重建镜像、重建容器、顺带建表。只重启不重建的命令是 `docker compose --profile sched --profile ws restart -t 30`，同样要先经审批。
4. 往 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. 各仓库的提交都已在远程，见第二节第 1 条，直接克隆即可。
2. 可选，用户 2026-09-20 表示记忆文件不必再处理：把旧机器上的迁移包 `~/Documents/work/claude-migrate-20260918.tar.gz` 拷到新机器。里面是五个项目的 Claude 记忆、各仓库被忽略的 `.claude` 目录（输出风格与项目设置）、全局设置。注意持仓管理系统仓库的 `.gitignore` 第 19、20 行忽略了输出风格与项目设置，克隆下来没有它们，必须从迁移包里取。
3. 新机器生成 SSH 密钥，公钥登记三处：Gitea 账号 zlt（网页上加）、155 的 factor 用户、188 的 tlai 用户。后两处是服务器写操作，先经用户同意。
4. 克隆仓库，解包，必要时把记忆目录按新用户名改名。目录名的规则是项目绝对路径里的非字母数字字符都换成横线。

在新开发机上运行，克隆：

```bash
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
```

在新开发机上运行，解包：

```bash
cd ~ && tar -xzf ~/Documents/work/claude-migrate-20260918.tar.gz
```

在新开发机上运行，建测试环境并跑全量单测，预期最后一行是 ALL SUITES PASS，共 904 例：

```bash
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` 里的真页面，给顶栏、持仓表、建仓候选栏、个股详情抽屉、评析报告抽屉、运维视图「组合操作」页喂固定的假数据。其余接口一律回「预览无后端」，页面顶部会有一条错误提示，不影响看样式。

在开发机上运行：

```bash
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 上运行，读版本、指纹与容器：

```bash
cd /home/factor/project/tradingSystem && git log --oneline -1 && make stale | tail -1 && docker compose ps --format "table {{.Name}}\t{{.Status}}"
```

在 155 上运行，读一周的观察读数，六张表：

```bash
cd /home/factor/project/tradingSystem && make consensus-review DAYS=6
```

在 155 上运行，确认源码是不是挂载的：

```bash
docker inspect pms-web --format "{{range .Mounts}}{{.Source}} -> {{.Destination}} ({{.Type}}){{println}}{{end}}"
```

在 155 上运行，读通道状态，预期「连接 ONLINE」：

```bash
cd /home/factor/project/tradingSystem && docker compose run --rm --no-deps pms-web python scripts/ws_smoke.py status 2>&1 | head -12
```