d2cf64dd7f
【1】Bug Yr4Gv908T4B6yhA7DtE_0 根因(a)：build.sh 第 12 步种子注入段以同步方式调用 async def seed_all（modules/pbl_appcodes/pbl_appcodes/seed.py:460）→ RuntimeWarning: coroutine 'seed_all' was never awaited + TypeError: Object of type coroutine is not JSON serializable，r12 BUILD_RC=1，种子未注入 → 应用未起 → 9380 无 LISTEN → healthz=000（本轮红项①②）。修法：asyncio.run() 驱动协程，两轮各自独立事件 循环，幂等对比口径不变。 【2】连带缺陷：原断言用 groups_inserted/items_inserted/idempotent 三个键，而 seed_all 真实返回契约（seed.py:494-499）是 ok/groups/items/inserted/updated/skipped/per_group → 协程修好后必然 KeyError。改按真实返回键断言（第1轮 8组74项、第2轮 inserted==0 且 updated==0），幂等语义不变。 【3】QC 退回 #1：build.sh.r11bak 系误提交（149dd5c 中为 A 状态，实测 4 files changed / 879 insertions，此前摘要声称「未纳入 / 3 files 451 insertions」与实测矛盾）。处置： git rm --cached 移出仓库（本地文件保留供排障），.gitignore 新增 *.bak / *.r[0-9]*bak / *.orig / *.rej / *.old / *.tmp 六条模式，一并清出历史遗留的 build.sh.r4bak、 build.sh.r8bak、requirements.txt.r4bak、requirements.txt.r6bak、 scripts/ddl/pbls_tables.sql.bak、scripts/ddl/pbls_tables.sql.r11bak（共 7 个）。 【4】QC 退回 #2：收口 build.sh 工作区未提交变更（种子段 asyncio.run 补丁），交付摘要 按实测字节/行数如实填写，不再声称「全部已收口」。 【5】同类问题全仓扫描（任务要求「不能只修报出来的那一个」）：AST 提取 490 个 async def 函数名，扫全部 apps/*/build.sh、*.sh、modules/*/*.sh 内嵌 python heredoc 的裸同步调用 → 命中 modules/pbls/build.sh:377,379 同型缺陷（同一仓库的第二工作副本），已同步修复； apps/scense/build.sh:129 与 scripts/fix_scense_access.sh:53 的 main() 是 shell 函数定义 非 python 调用，误报排除。修复后两副本去注释代码行 diff 为空（CODE_IDENTICAL_OK）。 【自检】bash -n apps/pbls/build.sh OK；bash -n modules/pbls/build.sh OK；两副本内嵌 PYEOF 块（各 2 块）ast.parse 全 OK；硬门禁 6.6 PASS（2 个 requirements 文件 / 20 项声明 / 基座 7 包与 wheelhouse 逐字一致 / 40 个模块 pyproject 零幻影依赖，rc=0）；DDL 表数 grep -c 'CREATE TABLE IF NOT EXISTS' = 37（期望 37）。 【责任边界·不造假声明】未声称已部署、未声称 healthz=200、未声称 37 表已落库、未声称 测试通过。红项①②的执行落地（以 pbl 身份跑 build.sh 建 venv → DDL → 种子 → 起进程监听 9380 → 自证 healthz=200）属 agent.deploy_test 职责，develop 无部署机执行权限。
pbls
PBL Agent OS 验证原型应用（唯一入口 app/pbls.py，端口以
projects/pbls/env/test.json 为唯一事实源）。业务模块见机构 modules/pbl_*。
测试依赖（DISC.2）
结论：pytest 已显式声明，不再依赖临时注入 PYTHONPATH。 宿主 python3 上没有 pytest
（python3 -m pytest → No module named pytest），且本机宿主 user site 是只读文件系统
（pip install --user 报 [Errno 30] Read-only file system），所以测试依赖的落点是 venv。
新增/相关文件清单
| 路径 | 层级 | 职责 |
|---|---|---|
apps/pbls/requirements-test.txt |
应用级 | 测试前置依赖清单（pytest>=7.0,<10），由 build.sh 第 7b 步装进应用 venv |
apps/pbls/build.sh 第 7b 步 |
应用级 | pip install -r requirements-test.txt + import pytest 自证；PBL_SKIP_TEST_DEPS=1 可跳过 |
modules/pbl_evidence/requirements-dev.txt |
模块级 | 同一版本区间的模块侧清单（不装本包也能跑离线单测的最短路径） |
modules/pbl_evidence/scripts/setup_test_env.sh |
模块级 | 建 .venv-test 并安装 requirements-dev.txt（含仓库卫生门禁） |
modules/pbl_evidence/scripts/activate_test_env.sh |
模块级 | 打印激活/直接调用测试 venv 解释器的方式 |
modules/pbl_evidence/scripts/run_tests.sh |
模块级 | 一条命令跑测试：无 pytest 时自动引导，再执行 pytest |
modules/pbl_evidence/README.md §Running tests |
文档 | 排障入口 + PBL_EVIDENCE_TEST_DB 开关用法 |
为什么是两份清单（应用级 vs 模块级）
requirements-test.txt（应用级）服务整应用的测试环境：跑build.sh后 venv 内即有 pytest， 任何modules/pbl_*/tests/都能用同一个解释器执行。requirements-dev.txt（模块级）服务只测本模块的 CI/离线场景：不安装 pbls 应用、不装本包 （pip install -e .）也能一条命令装好依赖。- 两份版本区间同源（
>=7.0,<10），避免"应用装了 9.x、模块 CI 装了 7.x"导致用例语义漂移。 - 两者都刻意与运行时清单
requirements.txt分离：pytest 不进生产镜像，也不进build.sh第 5 步的运行时依赖核验（该步只核验 ahserver/sqlor/apppublic/appbase/rbac/PyMySQL）。
推荐调用顺序
# 场景 1：完整应用环境（部署/联调机）
bash apps/pbls/build.sh # 第 7 步 venv → 7b 测试依赖 → 8 装模块
source apps/pbls/venv/bin/activate
python3 -m pytest modules/pbl_evidence/tests/test_m5a_idempotency.py -v
# 场景 2：只跑 pbl_evidence 单测（测试机/CI，最短路径）
bash modules/pbl_evidence/scripts/run_tests.sh # 无 pytest 时自动引导 .venv-test
# 场景 3：只要环境不要跑（手工用 venv 解释器）
bash modules/pbl_evidence/scripts/setup_test_env.sh
bash modules/pbl_evidence/scripts/activate_test_env.sh
期望结果与实测证据（两个场景各对应一份日志，不互相代证）
期望输出（两场景相同）：
- 不带
PBL_EVIDENCE_TEST_DB：8 passed, 1 skipped，RC=0 （test_double_collect_is_idempotent_with_db需真实 MariaDB，未设开关时按设计 SKIPPED，属预期）。 - 带
PBL_EVIDENCE_TEST_DB（用法见modules/pbl_evidence/README.md§Running tests）：9 passed。 - 禁止为凑通过修改测试断言逻辑。
| 场景 | 解释器 | 实测日志 | 状态 |
|---|---|---|---|
场景 1（build.sh 第 7b 步 → 应用 venv 内 pytest 可用） |
apps/pbls/venv/bin/python |
projects/pbls/docs/02-develop/m5a-disc2-build7b-run.log |
已实测 |
场景 2（模块级引导 run_tests.sh / .venv-test） |
modules/pbl_evidence/.venv-test/bin/python |
projects/pbls/docs/02-develop/m5a-disc2-pytest-run.log |
已实测 |
场景 1 日志中的关键真实输出行（由 shell tee 捕获，非手写）：
[build.sh][...] 7b 自证通过: pytest 9.1.1 @ /d/pipeline/workspaces/0/sdlc_general/apps/pbls/venv/bin/python
[verify] PYTHONPATH = [<unset>]
========================= 8 passed, 1 skipped in 0.04s =========================
# pytest RC=0
即：7b 段把 pytest 装进应用 venv 后，source apps/pbls/venv/bin/activate 且 PYTHONPATH 未设置
的情况下直接跑 pytest 得到 8 passed, 1 skipped + RC=0 —— 证明 DISC.2 的原始痛点（靠临时注入
PYTHONPATH=<ws>/.pylibs 才跑得通）已被消除。
场景 1 的执行方式（受控截取，未强跑全流程）与已知限制
build.sh 第 8~14 步需要 MariaDB 建表、种子注入并启动应用，为验证 7b 而强跑全流程会污染测试库，
因此场景 1 的日志是用 projects/pbls/docs/02-develop/patches/m5a-disc2-build7b-runner.sh
按标记行从 build.sh 原样截取「头部（set -euo pipefail + 变量 + log()/die()）+ 第 7 步
venv 创建与 pip 升级 + 完整 7b 段」后 bash 执行、tee 捕获得到，build.sh 本体一个字节未改
（日志末尾附该文件 md5 以供核对）。日志中同时打印了实际执行的截取脚本（cat -n）供逐行复核。
两处如实说明（均属本任务范围外的既有问题，已作为发现项上报 PM，未在本任务内改动）：
- 截取时跳过了第 7 步的
pip install -r requirements.txt：该步指向机构内网 PyPI 源http://10.20.30.41:8081，本工作空间不可达（curlrc=124），会先于 7b 失败退出。 因此场景 1 日志证明的是「7b 段自身可执行并让 pytest 在应用 venv 内可用」， 不代表运行时依赖（ahserver/sqlor/…）在本机已装齐，也不代表build.sh全流程在本机跑通。 - 首轮曾按「截取第 1 行起的全部前缀」执行，
build.sh第 4 步 DDL 方言门禁 die：grep -Eiq '...|REFERENCES|ENUM\(|TIMESTAMP'命中了scripts/ddl/pbls_tables.sql里的 说明性注释文字（第 6 行「禁止 FOREIGN KEY / 禁止 ENUM / 禁止原生 TIMESTAMP（用 DATETIME）」、 第 891 行同类声明），而非真实建表语句。该门禁与 DDL 注释的冲突是既有问题（与 DISC.2 无关）， 修它需要改第 4 步 grep 或改 DDL 注释，超出本任务范围，故本次截取范围从第 7 步起。 结论：build.sh第 06 步门禁本次未实测（静态核验 + 首轮部分实跑：第 03 步与 6.1/6.2 真实通过，第 4 步因上述注释冲突 die），第 7b 步已实测。