# TASK · staging 门禁因容量合同 `false:` / `f:` 失配一直红（2026-09-16）

基线：`origin/staging` @ `8cb1877e`。最近一次含门禁路径的 staging 提交是 `1e3570b4`（其后 `8cb1877e` 为纯文档）。Gitea Independent Staging Quality Gate run `2683` / job `6103` **failure**。

## 事故实证

validate 步「Validate backend, package, frontend, and database contracts」失败。Python 快速门已通过。唯一 `not ok`：

```
not ok 1109 - append_consultation_question ignores thinking fields and enforces the physical JSON cap
location: frontend/tests/database-consultation-session-capacity.test.ts:120
Expected values to be strictly equal:
+ 'f:session_missing'
- 'false:session_missing'
```

同文件后面 `"false:invalid_question_message"`、三处 `"false:session_full"` 会被同一条夹具改写打红，只是第一条先炸。

从 `dcfc2f15`（BUG-732）起到 `1e3570b4`，staging 上每一次跑完的质量门都是 failure；中间被更新推送 cancel 的不算绿。

## 根因

`frontend/tests/helpers/postgres-fixture.ts` 的 `psql()` 对输出做：

```ts
.replace(/(^|:)false(?=:|$)/gm, "$1f")
```

`boolean::text` 是 `false`，`psql -A` 是 `f`。这条改写让既有合同（`true:f:f`、`f:grant_failed`）跨表示稳定。BUG-732 的真实库合同用了 `success::text`，却按未规范化的 `false:` 写期望值。执行方当时无 Docker，该文件 skip，带红合入。

## 决策记录

- 不删夹具的 false→f 规范化（billing / topology / report 等合同依赖它）。
- 不改 `append_consultation_question` 运行时 SQL。
- 产品授权：直接修测试并推 staging 重跑门禁。

## 硬红线

1. 不改 `.gitea/workflows/**`、不提升 `main`、不动 DNS。
2. 不改迁移、不改 RPC 签名/error_code。
3. 不顺手升级依赖、不顺手修无关 warning。
4. Bug 历史不写入姓名、出生资料、密钥。

## 任务分解

1. 五处期望值改为 `f:session_missing` / `f:invalid_question_message` / `f:session_full`。验收：源码不再出现 `"false:session_missing"` 等。
2. 夹具改写保留，加一行说明。验收：`database-billing-admin` 等既有 `f:` 断言的源码合同仍在。
3. 无 Docker 源码合同：夹具必须保留 false→f；真实库合同必须用 `f:`。验收：`consultation-session-capacity.test.ts` 新增一条，定向套件绿。
4. `docs/BUG_HISTORY.md` 连续号 **BUG-739**。关联 BUG-732。
5. 推 `origin HEAD:staging`，门禁对**本提交 SHA** 必须绿（或明确写出环境缺口）。

## 让步顺序

改期望值即可。禁止为了让测试过而拿掉夹具规范化。禁止改生产 SQL。

## 开工前置

```
git fetch origin --prune
git status -sb   # 第一行必须是独立 worktree 分支
```

BUG 编号起点：开工时最大号 **BUG-738**，本单用 **BUG-739**。