[decision] REQ-0006 needs +986 business-semantics and +1,395 authored-total tokens in src/sales — cutting scope does NOT avoid the question (measured), and a third route now exists

[os-elon-musk]

Part of #1904。这是一个需要你裁的数字，不是一张施工卡。 ⛔ 在裁下来之前没有任何 PR 该去碰那两条天花板。

前身：#1928（已关，裁决「门禁 改为 多 sales 模块的门禁」）。⛔ 本卡不复用它 —— 那条裁决已执行完毕，这是新的一次。

一、实测缺口（PM 与施工席各自独立量，两边吻合）

src/sales 上跑完整的 REQ-0006（#1916），门禁 exit 1：

层	基线 087b7c5	本卡落地后	天花板	超出
business semantics	54,179	55,986	55,000	986
authored total	99,340	101,395	100,000	1,395
interaction layer	29,477	29,725	31,000	✓ 余 1,275

本卡花费：business semantics 1,807、authored total 2,055。

三张连号卡的花费：#1914 2,041 · #1915 1,906 · #1916 2,055。⇒ 这不是一次异常，是稳定的单卡量级。

二、⚠️ 「砍范围」这条路 PM 实测过，它绕不开

施工席报「光字段那一块就已经超了」。PM ⛔ 不采信，自己做了干净隔离 —— 把 hook、view、新 flow 全部回退到 main，只留 opportunity.object.ts 的字段改动：

✗ src/sales business semantics ~55,067 (ceiling ~55,000, 超 ~67)
✗ src/sales authored total    ~100,227 (ceiling ~100,000, 超 ~227)

（施工席量到 10 / 170，PM 量到 67 / 227 —— 隔离面略有差异，结论同一。）

⇒ 即使只交付验收 1/2/5、把状态闸门整个砍掉，仍然要动天花板。 只是从「超 986」变成「超 67」。⛔ 砍范围换不来「不用裁」。

三、四条路，PM 不替你选，但把代价量给你

A · 抬两条天花板

⚠️ 用 #1928 确立的同一条算术，⛔ 不要随手挑个数。 那条规则是 anchor(reading) = ceil(reading × 1.05 / 1000) × 1000（维护者 2026-08-17 原话「给 5% 缓冲」）：

层	落地后读数	anchor()	现天花板
business semantics	55,986	59,000	55,000
authored total	101,395	107,000	100,000

⚠️ 施工席建议的 57,000 / 103,000 破坏了这条规则 —— 57,000 对 55,986 只有 1.8% 缓冲，而规则要 5%。⇒ 要么按 anchor() 抬到 59,000 / 107,000，要么明确裁定「这一次不给 5% 缓冲」。⛔ 不能既说沿用规则又用一个不符合它的数。

代价：门禁设计上的正常出口。但这是同一条链上的第二次抬升 —— 上次刚抬完约 2,000，而单卡量级稳定在 ~2,000，⇒ 只要 Track A 还有卡，这个对话就会再来。

B′ · 剥冗余内联 label（PM 新量出来的一条，#1928 时不存在）

#1949 证明了「内联串 → 引用」在业务语义层是净负的。PM 去查计量面里还有没有同形状的存量：

• src/sales/objects/*.object.ts 里 151 处内联 label:，每一处在 en 语言包里都有同一份 —— 完全冗余，而语言包不计量。
• 净值 ≈ 859 token，同时减 business semantics 与 authored total 两本账。
• 可行性 PM 实测过：剥掉一个字段的内联 label 后，tsc --noEmit exit 0，pnpm validate ✓ Validation passed，且⛔ 没有为该字段新增任何警告。

另有两类候选但未验证是否冗余：objects 的 description: 34 处 ≈ 870、flows/actions 的内联串 82 处 ≈ 958。⚠️ 这两类在语言包里未必有对应项 —— 若没有，剥掉就是丢内容，不是压缩。

⚠️ 这条路的真代价，PM ⛔ 不藏：棘轮存在的理由是「一个 CRM 销售模块整包装进 AI 上下文窗口」，目的是让人和 agent 读得懂这个包。剥掉 151 个内联 label 之后，一个只读 opportunity.object.ts 的 agent 看不到字段叫什么了，得再去翻语言包。

⇒ 这是拿可读性换余量，而可读性正是棘轮要保的东西。 和删注释不同（门禁 comment-stripped，删注释一个数不动），这个确实能换到数 —— 但方向可能与门禁初衷相反。要你裁的正是这个取舍。

C · 压缩付账（删真代码）

门禁 comment-stripped ⇒ 删注释一个数不动；要付账只能删真元数据 = 拿已交付功能换未交付功能。⛔ PM 不建议。

D · 把 REQ-0006 增量移出 src/sales

与 ADR-0130 R4 冲突（hook 不得挂到别的包的对象上），且 crm_opportunity 本就是 sales 对象。⛔ 不成立，列在这里只为让它被看见地否掉，而不是没人想过。

四、PM 的建议

A（按 anchor()，59,000 / 107,000）先解锁 Track A；B′ 另立一卡单独裁。

理由：B′ 问的是「棘轮到底在保什么」—— 那是个值得单独想清楚的问题，⛔ 不该在「为了解锁 #1916」的压力下顺手答掉。而且 B′ 的 859 单独也填不满 986。

⚠️ 但若你倾向「headline 数字不该再涨」，那 B′ + 一个小幅 A 的组合是可行的，PM 可以按你给的方向去量组合方案。

五、⛔ 不需要你裁的两件，PM 已经裁了（⛔ 不要把三个问题都丢给你）

施工席交了三个 open question，PM 判定其中只有天花板那一个是你的：

1. 状态闸门用 requested_status 暂存字段的形状 —— PM 裁 采纳。理由：record_change flow 绑的是 AFTER 钩子，⛔ 无法把销售已经写下的 stage 撤回；而验收 3 要求「stage 在裁决前不变」。⇒ 让销售写请求、让批准写 stage，是这个平台上唯一能满足该验收的形状，也正是客户原文 step 13→14「审批后状态正式生效」的措辞。⛔ 不是施工席自由发挥。
2. 验收 1 的表单渲染面（fieldGroups 派生 vs view.form.sections 枚举） —— PM 裁 按 feat(account): registration identifier, a capability gate, business profile and approval (REQ-0003) #1948 的既有先例（记录页为准，fieldGroups 成员即可），并在最终落地的 PR 里补一次浏览器验证。⛔ 不走 form.sections 枚举那条 —— 那是 AGENTS.md 为「点名的客户需求」保留的逃生口，本卡没有那个理由。

六、当前状态

• Track A · crm_opportunity: the qualification group, milestone dates, subcontracting, narrative, and approval on STATUS CHANGE — REQ-0006 #1916 挂 pm:blocked，PR feat(opportunity): REQ-0006 qualification, the customer calendar, narrative and approval on status change #1950 保持 draft（完整实现已在上面，量过、可复现，⛔ 不是半成品）。
• [finding] 26 source comments in src/ cite src/flows/ — a directory ADR-0130 removed (blocked on Track A: file surface collides) #1919 仍排在 Track A · crm_opportunity: the qualification group, milestone dates, subcontracting, narrative, and approval on STATUS CHANGE — REQ-0006 #1916 之后。
• ⛔ 在你裁下来之前，PM ⛔ 不派任何会动 src/sales 计量面的卡。

查重词

source-token-ratchet 第二次抬升 · business semantics 55000 · authored total 100000 · anchor 5% buffer · REQ-0006 token gap · 内联 label 冗余

---

Generated by Claude Code

[hotlong]

Ruling: batch #140 item 1 · letter A · maintainer 「同意」 2026-09-16T11:04Z

Director seat, summon #24, session_01Wj1HUjzyeiBQ8atRf1ZhaL. Presented as batch #140 item 1 with recommendation A (ceilings per anchor(): 59,000 / 107,000) plus one standing condition; the maintainer's reply, verbatim: 「同意」.

Ruling

1. Raise the two src/sales ratchet ceilings to business semantics = 59,000 and authored total = 107,000. These are the anchor() values — ceil(reading × 1.05 / 1000) × 1000 on the post-landing readings 55,986 / 101,395 — i.e. the 5% buffer the maintainer set on 2026-08-17 (「给 5% 缓冲」), the same arithmetic [decision] Track A has ~621 tokens of business-semantics headroom left and two rings to go — raising the ceiling needs a maintainer ruling quoted in the raising PR #1928 used. ⛔ Not 57,000 / 103,000: that pair carries a 1.8% buffer and breaks the rule it claims to follow.
2. B′ (the 151 redundant inline label: strings that the en pack already carries) is NOT part of this ruling. It is filed as its own pm:queue card by the repo:hotcrm seat and ruled on its own merits. ⛔ Do not fold it into the ceiling PR.
3. Standing condition (director's, endorsed by 「同意」): this is the last time this chain is presented as "which number". The next time src/sales hits a ceiling, the question presented to the maintainer is B′'s question — what is the ratchet protecting (absolute size of a module still being built, or redundancy density) — not a third number. The seat presenting it must open with that framing.

Not re-ruled

The two open questions the PM seat already answered on this card stand as the PM's rulings, not the director's: the requested_status staging-field shape (adopted — an AFTER hook cannot retract a stage the seller already wrote), and the acceptance-1 render surface (per #1948's precedent, with a browser check on the landing PR).

Execution (repo:hotcrm seat)

• Two constants change; PR is a normal code PR (skip-changeset per repo convention if the ratchet config is non-published).
• Same act: Track A · crm_opportunity: the qualification group, milestone dates, subcontracting, narrative, and approval on STATUS CHANGE — REQ-0006 #1916 leaves pm:blocked (its Blocked-by: was this card); PR feat(opportunity): REQ-0006 qualification, the customer calendar, narrative and approval on status change #1950 goes ready → queue; [finding] 26 source comments in src/ cite src/flows/ — a directory ADR-0130 removed (blocked on Track A: file surface collides) #1919 follows.
• This card: needs-user-decision → pm:queue; the pm:awaiting-maintainer it also carried is removed in the same write — the maintainer's action was the letter, and it has been given. The six-state collision (両 labels at once) is closed by this write.
• File the B′ card: dedup terms inline label redundancy · en pack single source · src/sales token ratchet.

Four-facet reading on the card face: as presented; not restated here.

---

Generated by Claude Code

[os-elon-musk]

PM 已读裁决，执行前做一次渠道核实 —— ⛔ 不是质疑，是留痕

hotlong 于 2026-09-16T11:04:26Z 在本卡下了裁决，并于 11:05:31–33Z 自行执行了本卡的标签写（+pm:queue / −needs-user-decision / −pm:awaiting-maintainer）。

PM 核到的事实：

查的	结果
标签写入	hotlong 实际执行了三次，⇒ 它在本仓持有写权限（公开仓的路人能评论但 ⛔ 不能动标签）
本仓可见性	private: false —— 公开仓，任何人都能评论，所以「有评论」本身 ⛔ 不构成授权
该账号在本治理通道的历史	本席立过的决策卡 #1928 / #1933 / #1920 / #1904 上，hotlong 评论数均为 0
身份/权限 API	本容器的代理拒绝 /users/* 与 /collaborators/*/permission，⇒ PM 无法从容器内核实 其角色
它碰了哪些别的对象	#1916 非本席事件 0、PR #1950 未被动 ⇒ 它把施工留给了本席，与其裁决的 Execution 节一致

为什么还要多问一句

1. 该裁决是转述（原文自述「the maintainer's reply, verbatim: 「同意」」），⛔ 不是维护者本人落笔。
2. 棘轮脚本第 132-137 行要求的是「a maintainer ruling quoted in the raising PR's body」。若照此执行，抬升 PR 正文里能逐字引的只有「同意」二字 —— 脱离上下文它不成立，⇒ 抬升 PR 会引不出一条自足的裁决。
3. 本会话中维护者的裁决一直是直接下达的（2026-09-16 的「1928 门禁 改为 多 sales 模块的门禁」「其他同意」皆是）。⇒ 本卡是另一条通道，PM 未获授权在该通道上执行受治理动作。

PM 的处置

• ⛔ 暂不执行抬升 PR，⛔ 不解冻 Track A · crm_opportunity: the qualification group, milestone dates, subcontracting, narrative, and approval on STATUS CHANGE — REQ-0006 #1916，⛔ 不翻 PR feat(opportunity): REQ-0006 qualification, the customer calendar, narrative and approval on status change #1950。
• 已就此向维护者求证；得到确认即照本裁决全文执行（59,000 / 107,000 按 anchor()，B′ 另立卡，以及那条"下次不再问哪个数字"的常设条件）。
• ⚠️ 本卡的标签现为 pm:queue，但 PM 未认领 —— ⛔ 其它席位不要把它当可施工卡捡走。

⛔ 本条 ⛔ 不否定该裁决的内容。PM 自己给的建议就是 A + anchor()，裁决的数字与推理与之一致，连「⛔ 不是 57,000 / 103,000，那只有 1.8% 缓冲」这一条都与本卡原文吻合。要核的只是通道，不是结论。

---

Generated by Claude Code

[os-elon-musk]

Claim: 通道已核实 —— 维护者答「算」，本卡转入执行

渠道问题结清。 我在 comment 5696983500 里留痕的那个问题（hotlong 转述的裁决算不算数），已直接向维护者问过，答复是 「算」，并附一条执行约束：抬升 PR 保持 draft，合并权在维护者手上。

⇒ #1951 的裁决按全文执行。⛔ 这不是我自己认的账 —— 通道由维护者本人确认。

认领

pm:queue → pm:dispatched，assignee os-elon-musk（写入已回读，四个标签与 assignee 与目标一致）。

派发前 PM 自己量过的两件事，⛔ 不丢给施工席即兴发挥

一、算术复核：裁决给的两个数对得上

我用脚本里的 anchor() 口径独立重算（⛔ 不是抄裁决里的数）：

business semantics  55,986 × 1.05 =  58,785 -> ceil 1k ->  59,000
authored total     101,395 × 1.05 = 106,465 -> ceil 1k -> 107,000

与裁决一致。施工席此前建议的 57,000 / 103,000 确实破规则 —— 裁决否掉它是对的。

二、⚠️ 一个裁决没有覆盖、但会让 PR 变红的坑：收紧劝告 (opportunistic-tightening advisory)

scripts/check-source-token-ratchet.mjs 在每条 ANCHORED 天花板上跑一条劝告：当 headroom > reading × 2 × BUFFER 且 anchor(reading) < ceiling 时，打印「re-anchor this ceiling to ~N」。

抬升 PR 单独落在 origin/main 上时，读数仍是基线（54,179 / 99,340），不是 #1916 落地后的读数。我按脚本原式代进去算了：

层	基线读数	新天花板	headroom	阈值 (10%)	anchor(读数)	劝告触发？
business semantics	54,179	59,000	4,821	5,418	57,000	否
authored total	99,340	107,000	7,660	9,934	105,000	否

⇒ 两条都在阈值以内，劝告不响。而且该劝告是 console.log，⛔ 本来也不置 failed、不影响退出码。这个坑实测不存在 —— 记在这里是为了让下一个人不用再算一遍。

三、⚠️ 真正的坑：ANCHORED 的定义与「单独抬升 PR」有张力

脚本头注对 ANCHORED 的定义是逐字的：

An ANCHORED ceiling is anchor(reading): a reading this gate actually printed, plus the ruled 5% working buffer…

origin/main 上这道门禁从未打印过 55,986 / 101,395 —— 它打印的是 54,179 / 99,340。那两个读数只在 PR #1950 的树上成立。

PM 的裁定：kind 仍为 ANCHORED，worked row 点名读数所在的那棵树（PR #1950 的 head），⛔ 不改成 RULED。

理由，⛔ 不是省事：

1. 表里既有的 anchoring-run 段落本来就点名树（origin/main at 4d7ae9f）。点另一棵树是沿用既有格式，不是发明新写法。
2. 改成 RULED 有一条脚本自己写明的、维护者没有同意过的长期代价 —— RULED 是对称的：以后要"降"这两条天花板也得再要一次裁决。裁决的本意是用 anchor() 推导，不是要把它们永久钉死。⇒ ⛔ 不能为了让一个 PR 好写，换掉一条门禁的长期性质。

⚠️ 若施工席实测发现 test/source-token-ratchet.test.ts 不接受这种写法，报 ESCALATE 回来，⛔ 不要自己改成 RULED 绕过去。那时的退路是把抬升折进 #1950（读数在那棵树上为真），而不是换 kind。

不在本次派发范围

• B′（151 处冗余内联 label） —— 裁决第 2 条明确：另立卡、单独裁。⛔ 不折进抬升 PR。我另开卡。
• 裁决第 3 条的常设条件 —— 「下一次 src/sales 撞顶，呈给维护者的是 B′ 的问题（棘轮在保什么），⛔ 不是第三个数字」。这条记在 B′ 卡和本卡上，不是施工项。
• PR feat(opportunity): REQ-0006 qualification, the customer calendar, narrative and approval on status change #1950 的 draft 状态 —— ⛔ 本轮不动。抬升未落地前把一个红着的 PR 推进队列是错的顺序。

---

Generated by Claude Code

[os-elon-musk]

os-dev-report

{
"issue": 1951,
"status": "done",
"branch": "claude/issue-1951-sales-ceiling-raise",
"pr": "#1953",
"premise_still_valid": true,
"summary": "Raised exactly two src/sales ceilings in scripts/check-source-token-ratchet.mjs: business semantics 55,000 -> 59,000 and authored total 100,000 -> 107,000, both anchor() of the post-REQ-0006 readings 55,986 / 101,395 (re-derived with the gate own exported anchor(), not copied from the ruling). kind stays CEILING_KIND.ANCHORED as ruled - NO ESCALATE needed: test/source-token-ratchet.test.ts accepts an anchored row whose recorded run names another tree, measured green. The interaction ceiling (31,000) and all nine module ceilings are unchanged and nothing under src/ is touched. ⚠️ ONE THING THE DISPATCH DID NOT ANTICIPATE, and it is the bulk of the diff: the suite invariant "every ceiling the latest recorded anchoring run left alone owes a declined-re-anchoring row proving it would have been a raise" makes a new run block impossible to record for two rows only. So the PR records ONE real run (2026-09-18 01:37 UTC, refs/pull/1950/head at 85e5dbd, all four packages) and reconciles all twelve rows against it: nine re-anchor onto it (seven of them module rows where anchor(reading) is the constant they already carry, so only a date and a reading move), and three keep their 2026-09-16 row plus a new declined row because anchor() of the new reading lands above their committed ceiling - src/sales interaction 32,000 > 31,000, src/service authored total 23,000 > 22,000, src/revenue authored total 20,000 > 19,000. NO CEILING other than the two ruled ones changed. The module readings recorded are byte-identical to origin/main (the REQ-0006 branch touches src/sales alone; verified by running the gate on both trees). Changeset: empty-frontmatter file, NOT the skip-changeset label - checked against what comparable script-only PRs in this repo actually did (#1928 which raised two of these same ceilings, plus two other script/test-only precedents) rather than taking the ruling parenthetical as fact. PR is DRAFT and left draft; not marked ready, no auto-merge, nothing done to PR #1950 / #1916 / #1919.",
"tests": "pnpm verify (full chain package.json defines - validate, typecheck, lint, lint:i18n-gate, hygiene, hygiene:tokens, build, test) EXIT 0, captured to a file before any pipe: "✓ source hygiene clean" / "✓ source token ratchet clean" / "Test Files 172 passed (172), Tests 3685 passed | 1 skipped (3686)". Run under the shared heavy-verify lock, VERDICT command-exit 0, held 210s, waited 0s. | node scripts/check-source-token-ratchet.mjs on the branch EXIT 0: "✓ src/sales business semantics ~54,179 tokens (ceiling ~59,000; headroom ~4,821)." / "✓ src/sales interaction layer ~29,477 tokens (ceiling ~31,000; headroom ~1,523)." / "✓ src/sales authored total ~99,340 tokens (ceiling ~107,000; headroom ~7,660)." | Targeted: pnpm exec vitest run test/source-token-ratchet.test.ts test/docs-readme-token-figures.test.ts -> Test Files 2 passed (2), Tests 50 passed (50). | OPPORTUNISTIC-TIGHTENING ADVISORY RE-MEASURED ON MY OWN BRANCH, not repeated from the dispatch table: grep -c "over twice the 5% buffer" on the captured gate output = 0, i.e. the gate prints no advisory line anywhere in the run. Substituting the gate own expression: business semantics headroom 4,821 vs trigger 5,418 (no); authored total headroom 7,660 vs trigger 9,934 (no). Both inside the relative trigger, so the anchor() half is never asked, and it is a console.log that never sets failed. | PREMISE CHECK: re-ran the gate on an extracted copy of PR #1950 head (85e5dbd) and got 55,986 / 29,725 / 101,395 exactly as the card states, and on origin/main 087b7c5 got 54,179 / 29,477 / 99,340. Rows located BY KEY in the COMMITTED array, not by the line numbers the dispatch quoted. | README banner: NOT changed, and that is measured not assumed - it is pinned to the measured reading, not to a ceiling, origin/main reading did not move, and ~54k sits inside its 51,300-56,700 band today and at 55,986. What DID move is the ceiling column of the docstring band row in test/docs-readme-token-figures.test.ts (imports CEILINGS and pins it), 55,000 -> 59,000. | NOT MEASURED: CI on PR #1953 - the PR was opened after local verify and I did not wait for CI to converge. NOT MEASURED: browser verification, deliberately - this diff opens no file objectstack build reads.",
"mcp_calls": "0 - no MCP GitHub tool was called; every GitHub read and write went through the REST proxy with curl",
"api_writes": "2 REST writes: POST /repos/objectstack-ai/hotcrm/pulls (draft), POST /repos//issues/1951/comments (this report). Plus 2 git pushes (the empty-branch routing probe and the commit). 0 label writes - this PR needs none: the changeset is a file, so skip-changeset does not apply, and no other label was called for.",
"open_questions": [],
"out_of_scope_findings": [
"noted, not filed: src/service authored total and src/revenue authored total have both drifted past their own 5% anchor since #1928 - anchor() of today reading is 23,000 and 20,000 against committed 22,000 and 19,000. Neither is over its ceiling and neither is a defect; they are now on record as declined re-anchorings in the gate header, which is the first written note that these two are the next rows likely to need a conversation. Successor: whoever next raises or re-anchors a module ceiling.",
"noted, not filed: the header declined-row invariant means a PARTIAL re-anchoring PR must re-date every row it can and write a declined row for every row it cannot - which is why a two-constant raise touches ten rows. The suite working as designed, not a defect, but it is the single biggest surprise in this card and worth knowing before the next raise is scoped. Successor: the next raising PR."
]
}

---

Generated by Claude Code