docs(os-dev): capture gate exit status before any pipe, quote the gate's verdict line (#9720)

An `EXIT=$?` read after `| tail` captures tail's status, not the gate's. tail
essentially always succeeds, so the value is 0 for a green gate and a red one
alike — the reading is not merely unreliable, it is unfalsifiable: it returns
the same answer for both outcomes, so re-running never surfaces it, while it
reads as a measurement in a report.

Adds a compact discipline block to the gate-running section of the dev-agent
definition stating both halves: capture status before any pipe (redirect-then-
capture, `set -o pipefail`, or `${PIPESTATUS[0]}`), and quote a gate's own
printed verdict line rather than a bare `$?`. Records that mechanical
enforcement is measured-intractable — the trap lives in an agent's shell usage,
which no version-controlled artifact can observe — so no later round re-derives
that conclusion.


Claude-Session: https://claude.ai/code/session_01WswfK2yNYT9hNnMH6TzAwL

Co-authored-by: Claude <noreply@anthropic.com>

Author: os-support-ai

.claude/agents/os-dev.md

@@ -138,6 +138,17 @@ JSON,所以终报消息就是 JSON 本身,别无其它。
 树的绿,而且没人会察觉 —— 迟到的 commit 挪动的恰恰是过期的 **ratchet** 读数。复核后任何
 一次 push,都在新 head 上重跑并集 —— 至少 ratchet 族 —— **然后**才更新报告或 PR 正文。
 
+**门禁结果的读法:退出码在任何管道之前捕获,报告里引门禁自己印的判定行。** `EXIT=$?`
+跟在 `cmd 2>&1 | tail -40` 之后,读到的是 **`tail` 的**状态:`tail` 基本永不失败,绿门
+禁与红门禁读出来都是 `0`(实测:一次 typecheck 印着 `Exit status 2`,旁边的 `EXIT` 行
+写 `0`)。这不是「不可靠」而是**不可证伪** —— 不稳的仪器至少偶尔自相矛盾,而它对两种结
+局返回同一个值,重跑多少次都翻不出来,却在报告里读作一次测量。三种安全写法任选:先重定
+向再捕获(`cmd > /tmp/out 2>&1; EXIT=$?; tail -40 /tmp/out`)·`set -o pipefail`·
+`${PIPESTATUS[0]}`。另一半在报告侧:**引用某个门禁结果时,点名它自己印出的判定行**,永
+不引裸 `$?` —— 判定行由门禁写,`$?` 由你的管道写。⛔ 别等机械强制:陷阱在 agent 的
+shell 用法里,没有任何受版本控制的产物看得见它,已判定不可机械化 —— 这两条纪律
+就是全部的守卫。
+
 ## 标准条款住在这里,不住在你的派发词里
 
 dispatch prompt 只携带每单增量(裁决引文、裁决 / PM-机制假设分区、单卡条款、当日变动)。