docs: BUG-1140 and ERR-113 for the staging publish failure

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017eEAG8HD3mm8gsKXgk8uU8

docs/BUG_HISTORY.md

@@ -15181,3 +15181,18 @@
 - 相关记录：BUG-1115、BUG-1116、BUG-1117、BUG-621。
 - 复发自：无（新迁移引入，未部署）
 - 修复版本：`codex/rectification-varga-resolution-fix-20261001`（未部署）。
+
+## BUG-1140 | staging 镜像打包失败：`frontend/scripts` 下的研究脚本引用了 `frontend/tests` 的夹具
+
+- 状态：resolved（修复已推 staging；以门禁 publish 通过与 `/api/health` 部署版本为最终证据）
+- 首次发现 / 最近更新：2026-10-01 / 2026-10-01
+- 影响面：Gitea `backend-quality-gate` 的 publish 作业（`deploy/railway-web.Dockerfile` 构建阶段 `npm run build`）。validate 通过、publish 失败，未部署，staging 停在上一版。
+- 用户现象：盘型口径（BUG-1115～1117、1131）推送后 staging 不更新。
+- 触发条件：`frontend/scripts/rectification-segment-persisted-replay.ts`（盘型口径研究的 PG 持久回放 harness）`import … from "../tests/helpers/postgres-fixture.ts"`。web 镜像只复制 `frontend/src`、`frontend/scripts` 等，不复制 `frontend/tests`；`frontend/tsconfig.json` 的 include 为 `**/*.ts`，`next build` 类型检查覆盖 scripts，于是 `TS2307 Cannot find module '../tests/helpers/postgres-fixture.ts'`。
+- 根因：本地与验收机都有 `frontend/tests`，`tsc --noEmit` 与 `next build` 均通过，门禁 validate 也在完整检出上跑，没有任何一步按镜像的复制清单构建。
+- 修复：harness 移到 `frontend/tests/research/rectification-segment-persisted-replay.ts`（相对路径随之调整），Python driver `scripts/research/varga_resolution_persisted_replay.py` 指向新路径；新增 `frontend/tests/runtime-sources-no-test-imports.test.ts`：`src/` 与 `scripts/` 不得 import / `new URL` 引用 `tests/`。
+- 验证：按 `railway-web.Dockerfile` 的 COPY 清单从提交 `git archive` 出构建目录，修复前 `npm run build` 报上述 TS2307、exit 1，修复后 exit 0、`/` Static；守卫测试 2/2，且对旧 harness 文本判定为违规；移动后 harness 1 例 ±10 冒烟 `runner_exit=0`。
+- 防复发：守卫测试进 `npm test`（门禁 validate 必跑）；错误台账 ERR-113。
+- 相关记录：BUG-1115～1117、BUG-1131。
+- 复发自：无
+- 修复版本：`codex/staging-publish-fix-20261001`。

docs/research/pre_work_error_ledger.md

@@ -460,3 +460,9 @@ Prevention: 跨进程比较引擎输出（A/B、golden、缓存键）时固定 `
 `.worktrees/staging-docs` 的工作树里 `vendor/stem-branch/dist/cli.cjs` 与 `.gitea/actions/upload-artifact/dist/index.js` 早已处于「已删除未提交」状态（与主检出同款 `D`，推测被全局 `dist/` 忽略或清理脚本删掉）。纯文档提交 `12cbe6f8` 用了 `git commit -qam`，把这两处删除一起提交并推到 staging。结果门禁 run 2942（`12cbe6f8`）与 run 2945（`e0e2b382`）都因 11 条 `test_qizheng_*` 失败（`vendored 七政四余 engine is unavailable`）而红，代码拆分单被误判为可疑；且 `.gitea/**` 属于只有产品负责人能改的路径。修复：从 `e801fcf5` 逐字节恢复两个文件（blob 一致核对），本机 qizheng 16 条通过后重推。
 
 Prevention: 文档提交一律 `git add <具体路径>` 再 `git commit`，不用 `-a`；提交前看 `git diff --cached --stat`，出现文档以外的路径（尤其删除、`.gitea/**`、`vendor/**`）立即停止。「纯文档推送」若触发了门禁，先查这一次提交是否夹带了非文档文件。
+
+## ERR-113 | 本地与门禁 validate 都过、staging publish 失败：镜像不复制 `frontend/tests`，`frontend/scripts` 引用测试夹具 | observed 2026-10-01
+
+`next build` 在镜像里对 `frontend/**/*.ts` 做类型检查，而 `deploy/railway-web.Dockerfile` 不复制 `frontend/tests`。任何 `frontend/src` / `frontend/scripts` 文件引用 `../tests/...` 都会在完整检出上通过、在镜像构建里 TS2307。复现方法：`git archive <sha>` 出 Dockerfile 的 COPY 清单，按同目录布局放好（`app/frontend`、`app/{SKILL.md,assets,references,scripts,skills}`），硬链 node_modules 后 `npm run build`。
+
+Prevention: `frontend/tests/runtime-sources-no-test-imports.test.ts`；研究 harness 若依赖测试夹具，放 `frontend/tests/research/`。关联 BUG-1140。