fix: 修复产线三个「假产出/假通过」缺陷（hrs6 死循环根因）

1. deploy_test 编造部署成功：技能加硬门禁——/healthz 必须实测 200 才算成功，
   000/超时/连接拒绝一律算失败，必须如实记录+冒泡，禁止编造「返回200/部署成功」。
2. PM 审核不验证真实性：加审核标准——审核 deploy_test 必须独立 curl /healthz 验证，
   不能只信文档声称，声称200实测000=编造，直接退回。
3. develop 产出占位符：module-development-spec 加硬约束——init/data.json 必须是合法
   JSON 真实种子数据，禁止写「8组appcodes编码种子」这类占位符文本。
4. build.sh 不 fail-fast：webapp-deploy 加硬约束——必须 set -e，任一步失败立即退出，
   禁止 init_data 失败后继续 start app 造成「看似成功」。

根因链：deploy_test 编造 /healthz 200 → PM 轻信 approved → 应用实际没起来 →
test 冒烟失败 → rollback → 死循环。

skills_library/all/module-development-spec/SKILL.md

@@ -154,6 +154,8 @@ Not all modules need tables/CRUD — `models/` and `json/` can be omitted entire
 
 ### 4. Initialization Data (init/data.json or init/data.yaml — three formats)
 
+- **硬性约束：init/data.json 必须是合法 JSON 的真实种子数据，禁止占位符文本**。写「8 组 appcodes 编码种子」这类纯描述文字（不是 JSON）会导致部署时 `json.load` 失败（`JSONDecodeError`）→ 建表/插种子中断 → 应用起不来。每个模块的 init 数据必须写完整真实数据（appcodes 组 + 每个 k/v），不能只写「应该有几组」的描述。交付前用 `python3 -c "import json;json.load(open('init/data.json'))"` 自验 JSON 合法性。
+
 - **Format A — Direct table seeding** (JSON): `{"table1": [{"field1":"value1", ...}, ...]}`
 - **Format B — Appcodes registration** (JSON): `{"appcodes":[{"parentid":"sc_relation_type","parentname":"供销关系合作类型","items":[{"k":"distribution","v":"分销"},{"k":"agency","v":"代理"}]}]}`
 - **Format C — Appcodes registration** (YAML, used by accounting etc.): `appcodes:` entries use `{id, name, hierarchy_flg}`; `appcodes_kv:` entries are FLAT records `{id, parentid, k, v}` (not nested under items). `parentid` in appcodes_kv must match an `appcodes.id`. When adding a code group, add BOTH the appcodes parent AND all appcodes_kv children.

skills_library/all/webapp-deploy/SKILL.md

@@ -37,6 +37,9 @@ version: 1.0.0
 ```
 
 ## build.sh 标准流程
+
+- **硬性约束：build.sh 必须 fail-fast**——脚本开头 `set -e`（或每步显式检查返回码），任何一步失败（建表/插种子/pip install/xls2ui）立即 `exit 1` 终止，**禁止报错后继续执行后续步骤或假装成功**。特别：init_data.py 插种子失败（JSON 解析错误/表缺失）时，若 build.sh 仍继续 `start app`，会导致应用带缺表/缺种子启动、/healthz 失败，且部署日志里同时出现报错和「done」造成「看似成功」的假象。build.sh 末尾的 start 必须只在前面所有步骤都成功后才执行。
+
 1. 创建独立 venv: `python3 -m venv py3`
 2. clone 基础共享包到 pkgs/（apppublic, sqlor, ahserver, rbac, xls2ddl, appbase, bricks-for-python）
 3. 构建 bricks 前端: `mkdir -p bricks/dist` → `cd bricks/bricks && bash build.sh` → `ln -sf ../pkgs/bricks/dist wwwroot/bricks`

skills_library/pipelines/sdlc_general/roles/agent.deploy_test/role/SKILL.md

@@ -29,12 +29,12 @@ capability: deploy_capability
    - 起服务：`nohup python3 app/{应用名}.py` 启动**应用**（唯一入口、唯一端口，应用内 `load_{module}()` 加载各模块）
 3. **部署的是应用（一个入口一个端口），不是每个模块各起一个服务**——模块无独立 app.py/端口，挂在应用下运行。缺应用入口或模块挂载的，`ask_question` 冒泡让 develop 补。
 
-### 三、部署后验证（附真实输出，不是预期声明）
-- **检查进程**：`ssh {主机} "ps -ef | grep app.py"` 只有 1 个应用进程在跑（不是多模块多进程）
-- **健康检查**：`curl http://{主域名}:{端口}/healthz` 返回 200
-- **DB 连通**：`mysql -h {DB_HOST} -u {DB_USER} -p{DB_PASS} {DB_NAME} -e "SHOW TABLES"` 看到各模块表
-- **对外地址只用主域名+端口**：`http://{主域名}:{端口}`（或内网 `http://{IP}:{端口}`）。
-  **禁止编造子域名**（如 `selfservice.hrstest.opencomputing.cn`）——子域名未配 DNS/nginx，必然无法解析，会被 QC 退回。
+### 三、部署后验证（硬门禁，附真实输出，不是预期声明）
+- **健康检查是硬门禁**：`curl -s -o /dev/null -w "%{http_code}" http://{主域名}:{端口}/healthz` **必须实测返回 200**，应用才算部署成功。返回 000 / 超时 / 连接拒绝 / 非 200 一律算部署失败。
+- **部署失败必须如实记录并冒泡**：/healthz 000、端口不可达、SSH 连不上、进程没起来 → 如实粘贴真实错误输出，**用 ask_question 冒泡问题给 PM/运维，绝不编造「返回 200」「部署成功」**。编造成功会导致 test 冒烟失败 → 反复回退死循环，是严重违规。
+- **检查进程**：`ps -ef | grep {应用名}.py` 只有 1 个应用进程在跑（不是多模块多进程）
+- **DB 连通**：`mysql ... "SHOW TABLES"` 看到各模块表
+- **三项（/healthz 200 + 单进程 + DB 表）全部真实通过才交付**；任何一项失败，如实记录 + 冒泡，不 approved。
 
 ### 四、产出交付物
 - 部署文档（deploy-test-env.md：真实部署步骤 + 端口表 + 验证输出）

skills_library/pipelines/sdlc_general/roles/agent.pm/role/SKILL.md

@@ -12,6 +12,14 @@ capability: task_capability, bug_confirm_capability
 - 默认自动推进项目（审核通过→自动创建后续任务→自动分解派发），无需用户指令，暂停才需指令
 - **Bug 闭环**（审核 test 通过后执行，工具见 bug-confirm 能力）：`list_bugs` 查该迭代 `status=open` 的 Bug，**逐个判断根因（环境问题 vs 功能问题）并正确指派**——环境问题（部署/DB/服务/网络）→ `review_rollback` 回退 deploy_test，不 confirm；功能问题（代码逻辑）→ `confirm_bug` + `create_tasks` 派发「修复 Bug」任务给 develop；误报 → `reject_bug`。审核「修复 Bug」任务通过后，`list_bugs` 查 `status=fixed` 的 Bug → 派发「复测」任务给 test。
 
+## 审核标准（各阶段务必独立验证真实性，不轻信交付方声称）
+- requirement：需求是否清晰完整可量化（含部署环境需求是否明确）
+- design：方案合理、覆盖需求、技术可行
+- develop：用 list_files/read_file 检查代码文件是否**实际产出**（含 init/data.json 是合法 JSON 真实种子数据，非占位符文本）
+- **deploy_test：必须独立验证部署真实性**——自己 `curl -s -o /dev/null -w "%{http_code}" http://{主域名}:{端口}/healthz` 确认返回 200（或 SSH 查进程/端口/DB），**不能只信 deploy_test 文档里声称的「部署成功」「/healthz 200」**。文档声称 200 但实测 000/超时 = 编造，直接 review_reject 退回。
+- test：测试覆盖充分、用例真实落库、Bug 记录完整、冒烟失败未误报功能 Bug
+- deploy_prod：生产部署配置完整、可一键部署、有回滚方案
+
 ## 应遵守的规范（审核/派发前先 load_skill 加载对应全文，不要凭记忆瞎写）
 - `project-directory-spec`：各阶段交付件落点路径（检查交付件是否在正确位置）
 - `sdlc-repo-standard`：各阶段交付件的内容格式与产出行为准则