lint.yml 的头部注释说「三条 object-ui/* 规则设成 error」，实际已经是四条 #3261

Activity

1. xuyushun441-sys

   added

   pm:queue

   pm:dispatched

   on Aug 3, 2026
2. xuyushun441-sys

   self-assigned this

   on Aug 3, 2026
3. xuyushun441-sys commented on Aug 3, 2026

   

   xuyushun441-sys

   on Aug 3, 2026 – with Claude

   ContributorAuthor

   More actions

   认领:PM 循环第 4 轮
   会话:session_01NVPjPzmmAJ2Ngtvgg5MSRa(objectui 分片 PM,账号 xuyushun441-sys)
   分支:claude/issue-3261-lint-yml-comment-drift
   Worktree:objectui-issue-3261

   裁定:走「不再手工维护那个数字」,而不是把三改成四

   本单给了两条路,我定第一条(可否决):注释改成不点数、不逐条枚举的写法。

   理由与 #3212 完全同构,而且 #3212 刚刚在同一天证明了这一点 —— 那一页的工作流数量,文档写 11、issue 写 12、实际 13,三个数互不相同。手工维护的枚举必然漂移,而过期的枚举读起来仍然像权威。把三改成四只是把下一次漂移推迟到第五条规则加进来的那天。

   content/docs/guide/ci-cd-pipeline.md 新加的 lint.yml 一节已经刻意避开了这个数字(写的是「the rules eslint.config.js sets to error」),所以文档侧不会再跟着错 —— YAML 注释应当与它对齐,而不是自己再维护一份。

   但有一条更值钱的可选项,请先评估

   本单自己提了:「如果这份清单确实有价值,就加一条断言把它钉在 eslint.config.js 上,让它自己不会漂。」

   请先花几分钟判断可行性:能不能加一条测试,断言 lint.yml 的注释(或某处清单)与 eslint.config.js 里实际设为 error 的 object-ui/* 规则集合一致?

   • 若可行且不笨重 → 那才是这类漂移的终点,优先做这个(清单保留 + 机器守着),与 Docs:ci-cd-pipeline.md 的工作流清单与 ci.yml 一节仍与实际不符(11 vs 12、两个工作流没被记录、五个任务名里三个不存在) #3212 补反向断言、console preview-samples 的 tool 样例仍带三个已退役的 ToolSchema 键(category / active / requiresConfirmation) #3257 加样例守卫是同一思路,本轮已经有两个成功先例;
   • 若不可行或代价过大 → 退回第一条路(注释去掉数字与枚举),并在报告里说明你评估的结论。

   两种都可以交,但不要跳过这个评估就直接改注释。

   边界

   ⛔ 只动 .github/workflows/lint.yml 的注释(以及可能新增的一个测试文件)。不改任何 workflow 的实际行为,不改 eslint.config.js 的规则等级 —— 本单是让说明追上现实,不是改现实。

   注:那四条规则实测为 no-synthetic-event-trigger(:59)、no-try-catch-around-hook(:65)、no-dynamic-import-in-test-hook(:98)、no-inline-spec-config(:111),开工请自行复核行号。

   ---

   Generated by Claude Code
4. github-merge-queue

   added a commit that references this issue on Aug 3, 2026

   docs(ci): stop lint.yml's header comment hand-counting the object-ui …

   ...

   This issue will close once commit 7d20309 is merged into the 'main' branch.

   7d20309
5. xuyushun441-sys

   closed this as completedin #3273on Aug 3, 2026
6. xuyushun441-sys commented on Aug 3, 2026

   

   xuyushun441-sys

   on Aug 3, 2026 – with Claude

   ContributorAuthor

   More actions

   PM 验收:ACCEPT — PR #3273,已入合并队列

   项	结果
   PR targets main、Fixes objectstack-ai/objectui#3261	✅
   改动范围	✅ 2 个文件:.github/workflows/lint.yml 注释 + 新增守卫测试
   工作流行为 / 规则等级	✅ 零改动(硬边界被遵守)
   CI	✅ 12 绿 + 2 skipped,零失败

   我要求的评估做了,而且给的是否定结论加替代方案

   我要求先评估"能不能加断言把清单钉在 eslint.config.js 上"。它把那个方案真的建出来并 sabotage 测过,然后拒绝了它,理由我完全认同:

   eslint.config.js 本身就是那份清单,每条规则旁边就写着它自己的 ADR / issue。在 workflow YAML 里再放一份拷贝,是第二个没有任何机制强制同步的产物;而且那会让今后每个加规则的人为了让一条红测试变绿而去改工作流散文。

   这是本轮我最想看到的一种回答:先例(#3212 / #3207 / #3257 都加了守卫)不等于这里也该加同款。它没有照着套。

   它把守卫指向了注释的断言而不是清单

   三条,层次分明:

   1. 枚举不许回来 —— 数字或规则名重新出现就红(即 lint.yml 的头部注释说「三条 object-ui/* 规则设成 error」，实际已经是四条 #3261 本身的回归);
   2. eslint.config.js 确实还有 object-ui/* 设为 error —— 否则注释描述的是一道没有东西可守的门;
   3. 本工作流确实还跑在 pull_request 上、且没有 paths-ignore 掉 .ts/.tsx —— 这条价值最高:它正是 lint never ran on PRs, and turbo skipped 7 packages — three error ratchets were inert #2923 之前那个「规则全部空转」的状态,而注释把那段当历史在讲。一旦回到那个状态,注释就从史实变成谎言,而且没有任何其它东西会报红。

   设计上还有一处对的取舍:加第五条 error 规则,测试刻意保持绿(sabotage 案例 F)。加规则不该需要改工作流散文 —— 守卫守的是"不许再手工计数",不是"清单必须同步"。

   最值得记的一条:sabotage 抓到了它自己守卫里的真 bug

   案例 A2 —— 把计数跨注释换行写(也就是 #3261 原文的真实形态:sets three 结尾、下一行以 # 开头接 `object-ui/*` rules)。它第一版正则用 [^.\n] 连接,跨不过中间那个 \n# ,于是对着 #3261 本身的原文静默通过。

   它自己发现了,改成先剥 # 前缀、把注释拍平成一行再匹配,然后重验。

   这正是 sabotage 验证存在的全部理由:一个对着它本该抓住的缺陷原文都能通过的守卫,等于没有。如果只跑"改一行版本"的 sabotage,这个洞会带着一条看起来很扎实的测试一起合进 main。

   另外严重性判断也对:严重度是通过 import 已求值的 flat config 得到的,而不是扫文本 —— 因为 severity 有四种写法('error' / 2 / ['error', {…}] / [2, {…}])、且这些规则分散在四个 files 作用域不同的配置对象里。扫文本会给出与 ESLint 不同的答案。

   changeset:不加,判断正确

   一条 CI 注释加一个仓内守卫测试,不改任何已发布包的行为或 API —— 按 AGENTS.md 这甚至不算 shipped code。

   越界发现 #3274,已入队

   同一条注释的第三段还有第二个手工维护的数字:「the 7,724 warnings repo-wide are 81% no-explicit-any」,而 scripts/check-lint-coverage.mjs:30 还独立存了一份同样的数字。同一族缺陷,而且漂得更快(每加一个 any 它就更旧一点,且没有任何东西会响)。

   它没有顺手修,理由站得住:修它要碰 .github/workflows 围栏之外的文件,而只去掉两份拷贝中的一份,会把"两边都过期但一致"变成"两边互相矛盾" —— 那更糟。

   而且 #3274 里它明确建议不要给这个数字加钉扎断言(那要在测试里跑全仓 ESLint),只建议两处一起去数字、保留数量级论证。同一天里对同一类问题,一处推荐加守卫、一处推荐不加,并各自给了理由 —— 这个分寸是对的。

   ---

   Generated by Claude Code
7. akarma-synetal

   added 2 commits that reference this issue on Aug 4, 2026

   docs(ci): stop hand-maintaining a repo-wide warning count in two plac…

   ...

   a069a30

   docs(ci): 去掉 check-lint-coverage.mjs 头注里的 object-ui 规则点数,并把守卫扩到该文件 (o…

   ...

   4028adf
8. akarma-synetal

   added a commit that references this issue on Aug 17, 2026

   docs(ci): drop the fourth hand-copy of the object-ui ratchet list, an…

   ...

   492223d