From a22875573dbd3987f389efbe7dde42ef3b37ab34 Mon Sep 17 00:00:00 2001 From: zlt Date: Fri, 31 Jul 2026 11:30:22 +0800 Subject: [PATCH] =?UTF-8?q?gp=5Fhybk=20=E8=A1=8C=E4=B8=9A=E6=BA=90?= =?UTF-8?q?=E5=AE=9E=E6=B5=8B=E9=80=9A=E8=BF=87(prefix=E5=86=99=E6=B3=95);?= =?UTF-8?q?=20count=E8=AF=AD=E4=B9=89=E5=86=99=E6=B8=85=E6=A5=9A;=20?= =?UTF-8?q?=E6=94=B6=E5=B0=BE=E6=96=87=E6=A1=A3?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- README.md | 2 +- UPSTREAM_PLAN_API.md | 20 ++++++++++++++++++++ app/services/industry.py | 7 +++++-- 3 files changed, 26 insertions(+), 3 deletions(-) diff --git a/README.md b/README.md index 572b925..ac4eede 100644 --- a/README.md +++ b/README.md @@ -207,7 +207,7 @@ QMT ──trade/order_update──▶ pms-ws ──落 pms_qmt_inbox──▶ |---|---|---| | 1 | ~~ws 通道的账本侧改造（清单 4~6）~~ | ✅ 2026-07-29 | | 2 | ~~上游选股计划接入（`/plan`）~~ | ✅ 2026-07-31：候选池独占来源、交易日龄硬校验、盘前昨收兜底、ST 剔除、PMS 侧主题限额、页面抽屉与探活脚本。口径与实测记录见 `UPSTREAM_PLAN_API.md` | -| 3 | **行业硬拦截开闸** | 数据源换成 `gp_hybk`（199 库行业板块表，三级 884*，每票只认 bk_code 最小的主行业；`gp_stock_category` 作废——无 `stock_code` 列）。代码写法与 database 均做了自适应/显式报错。**待验证**：`PMS_SECTOR_SOURCE=gp_hybk` 后查 `GET /api/industry` 看 `probe.form` 与 `ready`，再看 `/api/positions` 的 `sector` 有没有填上。详见 `UPSTREAM_PLAN_API.md` §8 | +| 3 | ~~行业硬拦截开闸~~ | ✅ 2026-07-31：`PMS_SECTOR_SOURCE=gp_hybk`（199 库，三级 884*，每票只认 bk_code 最小的主行业），实测 `ready=true`、代码写法 `prefix`。**这是 PMS 第一次有可用的行业源。**待账本重建后回看 `PMS_SECTOR_MAX_RATIO=40%` 对三级粒度是否偏松（参考项目三级用 20%）。详见 `UPSTREAM_PLAN_API.md` §8 | | 4 | **账本重建**：清账后账本为空，需对端持仓就绪后 `POST /api/ops/reconcile?apply_fix=true` 以下游为准补回 | 阻塞：等 QMT 侧按真实成本价重建模拟持仓（`QMT_SIDE_S3_CLOSEOUT.md` §5） | | 5 | **ws 通道联调收尾**（协议 §9 S3） | 阻塞：`trade_no` 格式不合 §5.5（`QMT_SIDE_S3_CLOSEOUT.md` §1，这条挡住切 ws） | | 6 | 上游计划的剩余待确认口径 | 等上游：`UPSTREAM_PLAN_API.md` §4 剩 5 条 + §7.3 新增两条（同一 `date` 计划不幂等、档位规模与文档不符） | diff --git a/UPSTREAM_PLAN_API.md b/UPSTREAM_PLAN_API.md index ebd31ce..06cd5e1 100644 --- a/UPSTREAM_PLAN_API.md +++ b/UPSTREAM_PLAN_API.md @@ -508,3 +508,23 @@ curl -s http://127.0.0.1:38100/api/industry | python3 -m json.tool 看 `status.probe.form` (认出来的代码写法) 与 `status.ready`。ready=true 之后再看 `/api/positions` 里持仓票的 `sector` 有没有真填上。 + +### 实测结果 (2026-07-31, 已通) + +```json +{"source": "gp_hybk", "ready": true, "level": "l3", + "probe": {"form": "prefix", "error": null, + "columns": ["bk_code", "bk_name", "gp_code"]}} +``` + +- **代码写法 = `prefix`** (`SH600000`)。表里就是前缀式, 三种写法的自适应第二轮命中。 +- 列与参考实现完全一致; `gp_hybk` 确实在 `DB_MYSQL_URL` (199/db_gp_cj) 那个库里, `.env` 不用改。 +- **行业集中度硬拦截自此真正生效** —— 这是 PMS 第一次有可用的行业源。 + +`status.count` (= `cached_today`) 是**按需查询的日缓存计数**, 不是"表里有多少条"。账本空、 +还没下过命令时它就是 0。这跟 `gp_stock_category` 时代那个恒为 0 的假 count 是两回事 +(那个统计的是另一张表, 跟数据源通不通毫无关系)。hint 里已经把这句写死, 免得再被误读。 + +> 提醒: 行业源通了以后 `PMS_SECTOR_MAX_NAMES=4` / `PMS_SECTOR_MAX_RATIO=40%` 才真正开始 +> 拦人。参考项目在**三级**上用的阈值是 20%。40% 是当初按"二级或更粗"的粒度定的, 三级粒度下 +> 偏松 —— 等账本重建、有真实持仓分布之后再回头看这个数, 现在不动。 diff --git a/app/services/industry.py b/app/services/industry.py index 7a4656a..e7a352f 100644 --- a/app/services/industry.py +++ b/app/services/industry.py @@ -137,11 +137,14 @@ def status() -> dict: return st st["probe"] = {k: pr.get(k) for k in ("form", "error", "columns", "tried")} st["level"] = level() - st["count"] = sum(1 for v in _hybk["data"].values() if v) + st["cached_today"] = sum(1 for v in _hybk["data"].values() if v) + st["count"] = st["cached_today"] # count 沿用旧字段名, 含义见 hint if pr.get("form"): st["hint"] = (f"gp_hybk 可用 (代码写法 {pr['form']}, 取 {st['level']} 级 " f"bk_code {industry_repo.LEVEL_PREFIX[st['level']]}*, " - f"每票只认 bk_code 最小的那个主行业); 本日已缓存 {st['count']} 只") + f"每票只认 bk_code 最小的那个主行业); " + f"本日已解析 {st['cached_today']} 只 —— 这是**按需查询的日缓存计数**, " + f"0 只表示今天还没查过任何票 (账本空/没下过命令), 不是查不到") else: st["ready"] = False st["hint"] = ("gp_hybk **用不了** —— 行业约束按未配置停用。" + str(pr.get("error"))