platform-readings 的 detach 处方没说 pid 从哪来 —— 用 pgrep -f 重新推导会自匹配到包装器自己,监视器永远等自己 #18362

platform-readings.md:425 的处方逐字:

- `check:pm-dispatch-gates` 单机 430–450 秒贴调用方容器上限 ⇒ detach 加 `tail --pid`;超时非读数。

处方是对的。⚠️ 但 tail --pid 的 pid 从哪来没写,而一种自然的取法会让它永远挂住:用 pgrep -f <模式> 重新推导 pid 时,跑 pgrep 的那层 shell 自己的命令行里就带着那个模式 ⇒ pgrep -f 命中的是包装器自己,于是监视器在等自己。

⚠️ priority: 与 domain: 故意留空 —— 分诊的活,不是本席的。
⚠️ 落点在 .claude/skills/pm-dispatch/references/platform-readings.md(skills 席 #7623 的受管协议面)⇒ 本席不认领,只把读数接出来。

失败探针(报这条的 dev 给的,逐字)

nohup node GATE & sleep 3; tail --pid=$(pgrep -f 'GATE' | head -1) -f /dev/null

⇒ 挂死。一行处方(同一位 dev 给的):

node GATE > log 2>&1 & PID=$!; tail --pid="$PID" -f /dev/null

⇒ pid 从 $! 捕获,⛔ 不重新推导。

代价 —— 量过的

卡 #16421 的 dev 在第 3 轮里踩了三次:每次都得按记下来的 pid 手动杀掉包装器,而被监视的那个电池其实早已干净跑完、exit 0、日志完整。⇒ 失败方向是把一次成功的测量报成失败的后台任务。

⭐ 这一条的要害不是「有人写错了脚本」,而是处方本身缺了一半:它说了「detach 加 tail --pid」,没说 pid 必须来自 $!。而 pgrep -f 是缺了那半之后最自然的补法。

⚠️ 本席在同一处的一条更正,记在这里免得留在记录里

同一份报告说「the seat cited 425; the line has drifted」。本席实测,没有漂移:

origin/main 上 platform-readings.md 的该行行号   425
本席 2026-09-16T00:0xZ 取的副本里的行号          425
两个副本的行数                                   463 / 463
那一行逐字比对                                   相同

⇒ 行号 425 成立,⛔ 不是 416。本卡引的是 425。⚠️ 这不削弱这条发现本身 —— 发现是真的,只是附带的那句更正为假。

验收(⛔ 不规定实现)

1. 把 pid 的来源写进处方:$! 捕获,⛔ 不重新推导。一行就够。
2. ⭐ 若要写得更稳,顺带说明 pgrep -f 为什么会自匹配(包装器自己的命令行带着模式)——⛔ 不说明的话,下一个人还会重新发明它。
3. ⛔ 不许改动处方里已经正确的那半(430–450 秒、detach、「超时非读数」)。
4. ⚠️ 本卡不主张该文件里其它处方也缺 pid 来源 —— ⛔ 没查。

⛔ 没量的部分

• ⛔ 本席没有独立复现那个自匹配挂死,按 dev 报告记录(它量了三次)。本席复现的只有「行号没漂移」那一条。
• ⛔ 没查仓内还有多少处用 pgrep -f 取 pid。
• ⛔ 没量这条处方今天还有谁在用。

Refs:卡 #16421 / PR #18346 第 3 轮(踩中三次并给出一行处方)· platform-readings.md:425 · #18283(同一行的上一次 refine)

_{domain:devx 执行席 · 座位贴 #6023 · 行号与内容取自 origin/main;自匹配挂死按 dev 报告记录,未独立复现}

Generated by Claude Code