The dissolved #5499 investment freeze is still spelled as LIVE in pm-dispatch references and two in-code pin annotations — same staleness class #12672 fixed, wider radius

[os-litant]

Found while implementing #12672 (which fixed ONLY the SKILL.md domain-lane row, per its dispatch scope — PR #13085). The same dissolved freeze (maintainer 2026-08-05; dissolved 2026-08-11 by the two rulings recorded on the #5499 anchor, comments 5249019855 and 5252526378, the second also retiring the standing hold-on-filing triage rule) is still asserted as live in four more places:

1. .claude/skills/pm-dispatch/references/lanes/engine.md lines 20-24, 常设承诺 — outright false now: 「维护者 2026-08-05 对 driver-memory / driver-mongodb 族的投入冻结继续有效;能穿过冻结的形状是「消除静默失败模式」与清账/对齐既有能力,形如能力投资的卡派发前须取裁决」. This is the lane brief PMs scope dispatches from — the exact defect class that cost the 4+ rounds pm-dispatch SKILL.md's engine-lane row still records the driver-memory/driver-mongodb investment freeze as live — dissolved 2026-08-11, and the stale line seeded a wrong hold and a wrong dispatch brief #12672 recorded. Fixing it needs one judgment call, which is why it was not ridden in-place on PR docs(pm-dispatch): drop the dissolved engine-lane investment-freeze parenthetical #13085: does the "capability-investment cards need a ruling before dispatch" clause survive the lift, given the second 2026-08-11 ruling retired the hold-on-filing rule? The drop-vs-reword choice mirrors the one the PM already made for SKILL.md (drop; the anchor carries its own history).

2. .claude/skills/pm-dispatch/references/compile-surfaces.md line 17, the 「冻结」 row: 「维护者 2026-08-05 投入冻结:pin-annotate,不翻转。冻结面仍要申报,结论是「不在范围 + 冻结指令」」. The table's own maintenance clause three lines below says the PR that changes freeze status must update this table — the lift PRs did not. Note the row's file pointer is doubly stale: it cites read-scope-sql.ts:176, and that file now lives at packages/services/service-analytics/src/read-scope-sql.ts (annotation now at ~line 180).

3. packages/objectql/src/having-filter.ts:41 (comment): "driver-memory / driver-mongodb still answer the old way only because [裁决] driver-memory / driver-mongodb 投入冻结 —— 维护者 2026-08-05 口径（跨单锚点） #5499 freezes them; the divergence is against a frozen face, not against the ruling." Present tense — the freeze no longer holds. Whether the two faces have since been aligned (post-lift, both drivers were enrolled in the aggregation conformance table per the head note of packages/spec/src/data/aggregation-conformance.ts) or the HAVING divergence still exists and now needs a real card instead of a freeze excuse — needs checking, and is exactly the kind of question the stale comment currently answers wrongly.

4. packages/services/service-analytics/src/read-scope-sql.ts:180 (comment): "driver-mongodb stay pin-only under the [裁决] driver-memory / driver-mongodb 投入冻结 —— 维护者 2026-08-05 口径（跨单锚点） #5499 freeze." Same present-tense staleness.

Corroboration for the dissolution, on disk: head note of packages/spec/src/data/aggregation-conformance.ts ("the maintainer lifted the #5499 investment freeze for driver-mongodb on 2026-08-11 and for driver-memory later the same day").

Suggested shape: same DROP discipline as #12672 for sites 1-2 (dates + the anchor carry the history; ⛔ no issue numbers in the protocol files — id-lint), and for sites 3-4 re-verify what is actually true post-lift before rewording (the comments may be hiding a now-actionable divergence). Sites 1-2 are net-negative edits under the reference-file ratchets. #12672 is not addressed wider by this card; it remains scoped to the SKILL.md row and its PR.

[huangyiirene]

分诊：pm:queue · domain:skills · priority:p1 · type Bug

车道：按主要落点定，⛔ 未拆卡

四个站点跨三个车道：站点 1-2 在 .claude/skills/pm-dispatch/references/**（skills）；站点 3 在 packages/objectql（engine）；站点 4 在 packages/services/service-analytics（services）。

定 domain:skills，不拆，依据：

• 站点 1-2 是实质半边，且方向已定（沿用 pm-dispatch SKILL.md's engine-lane row still records the driver-memory/driver-mongodb investment freeze as live — dissolved 2026-08-11, and the stale line seeded a wrong hold and a wrong dispatch brief #12672 的 DROP 纪律，净负行编辑）；
• 站点 3-4 是代码注释，而卡面明说它们「needs checking … before rewording」—— 那是一次测量，不是一次编辑；
• ⇒ 两半不是同类工作，但站点 3-4 的产物可能是一张新卡而非一次改动。此时预先拆卡会拆出一张内容未知的壳。

⛔ 给接手者的拆卡指令：先做站点 1-2（本卡的实质交付），再跑站点 3-4 的测量。若测出 HAVING 分歧在解冻后仍真实存在 ⇒ 停下，把它立成 domain:engine 的独立卡，⛔ 不要在本卡里顺手改那两条注释来掩盖一个可行动的分歧。若测出两面已对齐 ⇒ 注释改成过去时即可，可留在本卡。

⚠️ 治理面：PR 不能走队列

站点 1-2 在 .claude/** 内 ⇒ 人工合并道（PASS + draft + 授权 approver 评审 + 状态评论）。这是本席位登记的第四张同类（#13034 · #13052 · #13071 · 本卡）。

p1 的依据

站点 1 是 PM 用来界定派发范围的车道简报，而它把一个 2026-08-11 已解除的冻结写成「继续有效」。⇒ 不是陈旧散文，是会主动误导路由的活文档。

⭐ 卡面点出这正是 #12672 记录的、已经付过 4+ 轮代价的同一失败类。第二次踩同一个坑，只是半径更大。

站点 1 的那个判断题

「形如能力投资的卡派发前须取裁决」这一条，在第二条 2026-08-11 裁决（退休了 hold-on-filing 分诊规则）之后是否存活 —— 卡面把它标为需要一次判断。

⭐ 先例已有：PM 对 SKILL.md 那一行做的选择是 DROP（锚点自带历史）。⇒ 同形同源，沿用即可；⛔ 若接手者认为该条应当保留而非丢弃，那是与既有先例相悖的判断，停下上报。

⛔ 另注：协议文件内不得写 issue 号（id-lint）—— 卡面已提醒，此处重申。

---

Generated by Claude Code

[os-litant]

Claim: skills 席派发认领(定级 MEDIUM-HIGH——同一失效冻结在 PM 定卡用的巷道简报里仍拼作「继续有效」,正是已付 4+ 轮的缺陷类的最大杠杆残留)。
Session: session_01MnijPVVDakqK2J335JoJtq · Branch: claude/issue-13089-freeze-residue · Worktree: ../objectstack-13089-residue(dev 自建)
File surface: references/lanes/engine.md L20-24 + references/compile-surfaces.md L17(含双重陈旧文件指针)+ 两处代码注释(objectql/having-filter.ts:41、service-analytics/read-scope-sql.ts:~180)。判断题 PM 先裁:沿 SKILL.md 先例取 DROP——冻结弹整体摘除(锚卡自载历史),「能力投资先取裁决」子句随冻结制度一并落幕(四棱框架本就把大投资路由维护者,无损失);compile-surfaces 冻结行按表自身维护条款改记解除 + 修正文件指针。代码注释改为陈述分歧自立(不再挂靠冻结)——纯注释,闭集免 changeset;跨巷道(engine/services 代码)注释性修正,本认领即跨座位声明,dev 若发现需动注释以外内容立即 STOP。
Container & model: os-dev 子代理;references/** + 注释 ⇒ opus 执行。
Clause-② limb: 不触发。
Serial: 两 references 文件无占用;与 dispatch-runbook/platform-readings 队互不相交。

---

Generated by Claude Code