Skip to content

[PM seat] domain:engine — 🟢 os-elon (session_019yDEhPBC3tcGkW9bkce1HM) · 本任期 24 落地 · 在飞 1 (#9350) · 队列 0 · 队列中 PR#10302 · 阻塞 4 #6367

Description

@hotlong

本贴是 domain:engine 座位的唯一权威登记。 索引 = label:pm:seat,总入口 #4604

本车道 2026-08-19 由 engine-core + metadata + drivers 三车道合并而成(维护者裁决见 #9854)。#6019 / #6020 已关闭并留迁入审计评论。合并请求卡:#9912

单写手规则:只有在任座位 PM 编辑本贴正文;接管/移交 = 改正文 + 一条审计评论。读取边界:接管者读本正文 + 仅读晚于其最后一次编辑的评论。

⛔⛔ 本贴是缓存,缓存会过期 —— 包括这一行

pm:* 标签与卡片自己的评论才是状态。 把本贴任何一条当成开着的卡之前,打开那张卡、把评论读到底

⭐⭐⭐ 本任期最贵的教训:PM 六次「量错了对象」

六次都不是算错,而是测了一个看起来相关、实际回答另一个问题的东西。这是本贴留给下一任最有用的一段:

我读的 我以为它答 它实际答 代价
退役车道标签 队列几张 合并前的车道几张 数小时空报「队列 0」,被维护者抓到
gh-readonly-queue/* ref 谁在队列里 队列此刻在测哪一个 把排队中的 #10006 误判为卡死,已动手去强推,被 422 拦下
PR 的 updated_at dev 报告了没 PR 最后被推动的时间 报「两个 dev 静默 8 小时」,实际两个都早已报告 —— 报在 issue 线程
merge-tree | grep 'changed in both' 有几处冲突 有几个文件两侧都动过 派了一整轮解冲突,而真冲突从头到尾是 0
Test Core 分片红 → 「main 进了东西」 谁引入的 (被 #10060 证伪:它没并 main 也红) 差点往错的方向找修复
卡号 grep 提交标题找 squash 这张卡落地了吗 标题里恰好写了卡号的提交有哪些 两次误判「未落地」(#9984→PR #9995#9864→PR #10094)

规则:一个测量在被当作答案之前,必须能说出它在否定情形下返回什么。 六次我都只见过肯定情形,就把它当成了通用读法。这与本贴关于控制量的老规矩是同一条,只是作用在平台事实而非代码探针上。

反面样板(本任期最好的一次收尾):#10134 的合并前置条件是「无法从仓内确认 branch protection」。解法不是推断,而是把 PR 本身变成实验:workflow 只在 head 分支被删,所以若该 context 是 required,这张 PR 会停在 Expected;它报了 clean 并被队列接受 ⇒ 不是 required。合并后 main 上又跑起一代新队列,从另一侧确证。⇒ 当一个事实读不到时,先问「什么样的观察会因它而不同」。

一、当前 PM

🟢 os-elon · session session_019yDEhPBC3tcGkW9bkce1HM · 本任期 2026-08-19 ~00:3xZ 起。当前:在飞 0 · 队列 0(2026-08-20 ~09:0xZ)。

二、继承台账

本任期已落地 —— 23 张,1 次返工,2 次补丁轮次

PR squash
#9735 #9768 ca19ee81f
#9476 #9780 6a5e6adf1
#9638 #9786 52fbba6db
#9719 #9797 1258dcaee
#9770 #9812 2a9752cf0
#9469 #9816 91c4ff5c7
#9261 #9817 855591fe7
#9781 #9818 88a4c7af5
#4716 #9825 1408ae337 — object 门 2 → 7 条规则
#9836 #9847 cfe1c4902
#9851 #9853 fb62bd19e — 落下可复跑的闸门基准
#9905 #9920 ae555f429 — 基准增 --mode per-rule / --mode closure
#9688 #9987 b73550752
#9849 #9975 90f4d5dc3
#9359 #9986 21995d73b
#9984 #9995 477fd59f5
#9859 #10040 5302c7548 — object 门真实形状 BEFORE 基线
#9281 #10006 907c11d2c
#9974 #10093 4639cec4d — 未限定范围的批量更新按形状拒收
#9960 #10060 c766ec360deletePackage 三形状收敛为单一声明类型
#9612 #10058 6f5a44976按软件包自身闭包校验包的写入
#9864 #10094 a38408af3 — 双内核对重复注册达成一致并出声
#10134 #10143 5a2ce6c0d — objectui pin 是决定,发版不再扫描 objectui main

#9701 / #9390 交付后无 PR 关闭。⚠️ #9984#9864 的提交标题只带 PR 号、不带卡号,按卡号 grep 找不到 —— 见上表第六行的教训。

返工 1 次:#9853 的类型债棘轮 +19,在作者端修好,⛔ 未抬基线
补丁轮次 2 次:#9974 的 CI 红(以因果证明结案,未改一行代码);#9960check:type-source-resolution 红(在作者端修好,⛔ 未加宽注册表)。

在飞 —— 0 张

阻塞中

本任期立的卡(findings)

内容 为什么值得看
#10091 sys_attachment更新动词根本没注册授权钩子(只有 insert/find/delete),而明确抄自它的 sys_comment 四个都有 #9974 修的洞更大:那是「守卫判错对象」,这是「没有守卫」。⚠️ 首项交付应是「是不是故意的」(附件是否本就不可更新)
#10106 deliveredInbox 超时返回短值:一处把超时报成「消息从未送达」,另一处期望 0 因而因错误理由通过 假绿那半边不是「把超时喊响」能修的。⛔ 已禁止「只是把 5 秒改大」
#10121 eslint . 间歇性在 migrations/registry.ts 栈溢出(6795 行 / 528 KB,按流程只增不减) ⚠️ #10124 已用「调大解析栈」止血,但本卡故意保持开着 —— 那买的是几个月余量,而且下一次会撞在贡献者自己的机器上。真问题(哪个构造在递归)未答
#10142 ADR-0082 附录仍点名一个已被 #10143 删除的步骤 docs/adr/** 是 governed surface,#10143 刻意没碰,免得为一条陈旧子句把 PR 变成维护者专属合并
#10062 / #10063 / #10064 dev 立:published src 从 dev-only 依赖 type-import · 提升门无法说出写入的包(#9612 的缩窄在那里永不触发)· 拒收的 path 用闸门私有下标定位 #10063 尤其:「照那个形状读会编译通过、类型干净,并产出一个看起来在工作、实则永不触发的缩窄」
#9873 dispatch-gates 无法为 scripts/** 点名 check:type-check-debt ⭐ PM 补注 5338592920:这是刻意的逐耦合手工维护设计,不是疏漏

✅ 本任期核销

⚠️ 继承自三张旧贴 —— 未经逐条核实,动手前必须重读卡片

hold 堆规模

全仓 pm:on-hold = 79;本车道 = 18:#9350 · #9276 · #9236 · #9167 · #8924 · #8753 · #8740 · #8722 · #8414 · #8006 · #7880 · #7877 · #7611 · #6009 · #5930 · #5180 · #4220 · #3166,加 #9613(#9612 落地可关)。

⚠️ 这 18 张的 updated_at 全部落在 2026-08-19 07:28–07:29Z ⇒ 今早已有全量扫描走过。再扫全堆低产出;有增量的问题是窄的:07:28Z 之后落地的东西解锁了哪些 hold

三、热文件串行队

当前:空(在飞 0)。

⚠️ 区域放行只能来自对方卡的实际改动行程 —— 有 PR 就读 diff,没有就申报 UNKNOWN。⛔ 永不从「它名字里那个符号的地址」推。

并发编辑上限 3,认领评论里做区域级申报。纪律四条:认领时申报区域 · 开 PR 前先并 main · 每有同侪落地后再并一次 · 让队列仲裁。

四、说明

📌 岗位说明版本化于 .claude/skills/pm-dispatch/references/lanes/engine.md。⛔ 本贴不复制、不摘抄 —— 读那里。

平台事实 —— 已实测,⛔ 不要重新推导

  1. 裸 GitHub HTTP 一律 403(GH_TOKEN/GITHUB_TOKEN 存在但为;无 gh CLI)。只有 mcp__github__* 可用。⇒ scripts/pm/check-half-states.mjs 永久 401。⚠️ 同源:GET /repos/.../branches/main/protection 也是 403,所以 branch protection 读不到 —— 但可以用 PR 的 mergeable_state 反推(见 24)。
  2. git push/fetch/ls-remote 是通的 —— 只有 API 层被封。
  3. 子代理能到达 GitHub(自开 PR、自贴报告)。
  4. 远端分支删除不可用(四次指数退避全败,而 ls-remote 同时是活的)。
  5. ⚠️ list_issues 的多标签过滤是 OR 不是 AND,且不返回 assignees ⇒ 车道列表不是认领检查,交集只能本地算。
  6. ⚠️ pull_request_read method=get_status 只显示遗留 commit status(Vercel),不是 check runs —— 用 get_check_runs;其分页有 bug(page=2 返回空),用足够大的 perPage
  7. ⛔⛔ refs/heads/gh-readonly-queue/* 回答的是「队列此刻在测哪一个」,不是「谁在队列里」。 排队等待的 PR 一条都不给,空结果不是「没进队」的证据。
  8. ⭐⭐ auto-merge 与队列成员资格不跨越 draft 转换。 在 draft 状态下开 auto-merge,转 ready 时会被清掉 —— 这就是本任期 feat(objectql,plugin-audit): refuse an unscoped multi-UPDATE on the shape, not by accident (#9974) #10093 / fix(core): both kernels agree a duplicate plugin registration supersedes, and say so out loud #10094enable_pr_auto_merge 报成功却从没进队」的真因。⇒ 正确顺序:先 draft:false,再 enable_pr_auto_merge
  9. ⭐⭐ 订阅 subscribe_pr_activity 后,pull_request.enqueued / pull_request.closed{outcome:merged} 事件会直接推来 —— 入队与落地都不必再探,也不必用定时器轮询。⚠️ 事件是 best-effort,仍应留一个长兜底检查点。
  10. ⚠️ 422 要读它说了什么。 update_pull_request_branch已入队 PR 返回 422 并点名 merge queue(可作成员判别);但 expected head sha didn't match current head ref另一回事 —— GitHub 的 PR 记录与分支 ref 不同步(本任期 feat(lint,metadata-protocol): judge a package write against its own closure #10058 实测:API 停在 112c3ffc3、ref 已是 d4c72dbcc,新 head 因此从未跑过 CI,90 分钟未自愈)。解法:让 dev 并新 main 再推一次,真实提交会强制重新同步。
  11. ⚠️ enable_pr_auto_merge 返回空字段签名,零诊断价值,且返回 success 不等于进队(见 8)。它是幂等的。
  12. ⚠️ API 会截断长 issue 正文(meta-field-write-inert: an accepted field PUT never reaches the object — a runtime-created field is stored valid=true and is absent from fields forever #7893 的「Decision Required」整段落在未返回的那半)⇒ 派发令要让 dev 自查正文截断。
  13. ⚠️ issue_read get_comments 在长卡上会超输出上限 —— 从尾部分页读。
  14. ⚠️ actions_list 在本仓会超输出上限(单次 46 万字符),且 branch=main 只返回 push 事件 —— 合并走队列,main 的真实 CI 历史在 merge_group 里。
  15. ⚠️ GitHub 的 job 日志尾部会落在 post-job cleanup 段内,失败任务自己的输出在更前面且常常取不到。⇒ 逐 PR 定根因的成本被这件事显著抬高。
  16. post_turn_summary / status_detail 不可靠(一个班次内两次确认为假)。
  17. ⚠️ 座位 roster 横跨至少三个 GitHub 账号 ⇒ 跨账号交接是常态。get_sessionnot found账号作用域,不是死亡信号
  18. ⚠️ 共用登录使 assignee 字段失声 —— 认领评论里的 session ID 是唯一判别符。分诊的 assignee 是收件箱路由,不是认领⚠️ 同源后果:PR 上的 actor 也分不清是维护者还是别的 agent。
  19. git fetch A 之后再 git fetch B 然后读 FETCH_HEAD,读到的可能是 A。git ls-remote origin 'refs/heads/<pattern>'打印控制量(claude/* ≈ 217–229 条)。⚠️ 已合并分支会被自动删除,⛔ 不能当探针控制量。
  20. dev 的报告发在 issue 线程,不是 PR。 PR 的 updated_at 早于报告时间(实测两次)。⛔ 永不用 PR 时间戳判断 dev 是否回报。
  21. git merge-tree | grep 'changed in both' 数的是共同修改的文件,不是冲突。 只有 ^<<<<<<< 是冲突标记。实测两次:同一输入 ^<<<<<<< = 0、changed in both = 2。
  22. git diff A..B -- <paths> 两点式会把你自己的新增打印成删除,读起来像 main 删了你的工作。只有按 merge-base 锚定才回答得了「main 动了我的面没有」。
  23. squash 必须按 sha 或 PR 号记,⛔ 不能靠卡号 grep 提交标题。 实测两次:docs(validation-rules): the multi-value required callout still says the non-empty half is "declared but not yet enforced" — false since #9476 landed, and it tells authors to work around it #9984 落在 PR docs(validation-rules): required-means-non-empty is enforced, not pending #9995core(finding): duplicate plugin registration throws on LiteKernel and silently overwrites on ObjectKernel — a fourth instance of the two-kernel semantic split #9864 落在 PR fix(core): both kernels agree a duplicate plugin registration supersedes, and say so out loud #10094
  24. ⭐⭐ branch protection 读不到,但可以用 PR 反推。 一个 required context 若不报,PR 会是 blocked(Expected — waiting for status)且队列不收;若 PR 报 clean 并被队列接受,该 context 不在 required 集。⚠️ 删 workflow 的 PR 尤其适用:pull_request 跑的是 head 分支的 workflow 文件,所以该 context 在合并前就已从这张 PR 上消失,而影响只限于这张 PR。合并后再看 main 是否仍有新一代队列在跑,即从另一侧确证。ci(release): the objectui pin is a decision — stop resolving objectui main at release time #10143 实测两侧皆通。

本任期新增的方法论

未决,已上报维护者(⛔ 非本席可闭)


迁移注记:2026-08-19 由 #6019(engine-core)+ #6020(drivers)+ 本贴(metadata)三合一;请求卡 #9912

Metadata

Metadata

Assignees

No one assigned

    Labels

    domain:enginepm:seatPM seat registry issue - single-writer body, index = this label

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions