发现于 #1002 / 本单实施过程。#1002 的裁定明确把「守卫扫描面是否扩到 src/」排除在外
(能力扩张需单独裁定),故单独记录。观察类 :#1002 落地后 src/ 已无残留,今天没有
用户能撞见的缺陷;这条记的是「下一次会不会被抓住」。
现状(基线 origin/main = 86010ff + PR #1002 )
PR #1001 为 #612 加的规则 test/docs-drift.test.ts 「product docs do not name a
retired copilot persona」,扫描面是 walkDocs('content/docs') —— 只读 .mdx。
那是维护者给 #612 划的范围,守卫忠实照做,没有毛病。
问题是同一个退役人格能在另一侧 复活,而那一侧一道门都没有:
os validate / pnpm lint 走被授权的元数据结构,卡片的 title / description
对它们只是自由文本;
test/docs-drift.test.ts 的另一条规则「documented agent names resolve to a
platform agent」扫的是围栏与脚本里的 agent: / defaultAgent: 键值 ;
test/metadata-references.test.ts 的 app AI bindings resolve to a platform agent 同样只看绑定键 (defaultAgent、stack.agents)。
三道规则都盯着「键」,而 #1002 那处是一句人话 —— 在 src/pages/home.page.ts 里活了
好几个月,六道门全绿。
PR #1002 加的 pin(test/metadata-references.test.ts 的
live UI copy does not name a retired copilot persona (#1002))只钉那一张卡片 ,
是刻意的:换一张卡片、换一个视图的 emptyState、换一条 skill 的 description,
同样的人格照样进得来。
建议(需裁定,不建议顺手做)
把人格规则的扫描面扩到 src/ 的用户可见字符串 —— 大致是 title / label /
description / help / subtitle / emptyState.*,从 objectstack.config.ts
解析后的 stack 走(而不是 grep 源文件,那样会误伤注释与豁免说明)。
需要拍板的点,正是它不适合顺手做的原因:
裸 "Copilot" 算不算违规。 文档侧 docs: align README/copilot pages with the shipped skills-only surface (#589) #611 刻意保留 AI Copilot 作为文档区名;
PR Home page still ships a card titled "Ask the Sales Copilot" — a retired persona in live UI metadata, outside every docs guard's scan surface #1002 在界面文案里把裸 Copilot 一并中性化了(方案 A 拍板精神)。两侧的界线
不同,规则要写死哪一条,是措辞面的决策。
豁免机制。 文档侧用 HISTORICAL 白名单收退役史;src/ 里是否会有同类
合法用法(例如讲退役史的注释),要先想清楚,否则白名单会从定向变成一揽子。
是只管这两个人格,还是升级成一张「退役词表」。 后者能顺带覆盖 refactor(ai): skills-only AI surface — real Actions instead of 10 fictional tools, retire the two agents #512 之外的
退役词,但要有人维护表。
关联
发现于 #1002 / 本单实施过程。#1002 的裁定明确把「守卫扫描面是否扩到 src/」排除在外
(能力扩张需单独裁定),故单独记录。观察类:#1002 落地后
src/已无残留,今天没有用户能撞见的缺陷;这条记的是「下一次会不会被抓住」。
现状(基线 origin/main = 86010ff + PR #1002)
PR #1001 为 #612 加的规则
test/docs-drift.test.ts「product docs do not name aretired copilot persona」,扫描面是
walkDocs('content/docs')—— 只读.mdx。那是维护者给 #612 划的范围,守卫忠实照做,没有毛病。
问题是同一个退役人格能在另一侧复活,而那一侧一道门都没有:
os validate/pnpm lint走被授权的元数据结构,卡片的title/description对它们只是自由文本;
test/docs-drift.test.ts的另一条规则「documented agent names resolve to aplatform agent」扫的是围栏与脚本里的
agent:/defaultAgent:键值;test/metadata-references.test.ts的app AI bindings resolve to a platform agent同样只看绑定键(defaultAgent、stack.agents)。三道规则都盯着「键」,而 #1002 那处是一句人话 —— 在
src/pages/home.page.ts里活了好几个月,六道门全绿。
PR #1002 加的 pin(
test/metadata-references.test.ts的live UI copy does not name a retired copilot persona (#1002))只钉那一张卡片,是刻意的:换一张卡片、换一个视图的
emptyState、换一条 skill 的description,同样的人格照样进得来。
建议(需裁定,不建议顺手做)
把人格规则的扫描面扩到
src/的用户可见字符串 —— 大致是title/label/description/help/subtitle/emptyState.*,从objectstack.config.ts解析后的 stack 走(而不是 grep 源文件,那样会误伤注释与豁免说明)。
需要拍板的点,正是它不适合顺手做的原因:
PR Home page still ships a card titled "Ask the Sales Copilot" — a retired persona in live UI metadata, outside every docs guard's scan surface #1002 在界面文案里把裸 Copilot 一并中性化了(方案 A 拍板精神)。两侧的界线
不同,规则要写死哪一条,是措辞面的决策。
HISTORICAL白名单收退役史;src/里是否会有同类合法用法(例如讲退役史的注释),要先想清楚,否则白名单会从定向变成一揽子。
退役词,但要有人维护表。
关联
src/最后一处残留)(控制字节扫不到 docs/ 等)—— 都是扫描面缺口,不是规则本身写错