「多少个 action」需要一个产品口径：文档写 13，注册进 stack 的是 26

[yinlianghui]

Found while working #729（PR #1010）。#729 自己在「补充」一节里点出了这个数字可疑但刻意未断言；PR #1010 因此既没有改它、也没有让守卫覆盖它。单独立单把这个决策拎出来。

事实

在 origin/main（acc37e65）上实测三个不同的数：

口径	数
src/actions/*.actions.ts 文件数	6（campaign / case / contact / global / lead / opportunity）
README.md:60 与 docs/STATUS.md:17 宣称	13
pnpm build 摘要 / dist/objectstack.json 的 actions 长度	26

13 既不是文件数也不是注册数 —— 它更像「动作族」的计数（log_call / log_meeting / schedule_meeting 这类一次定义、绑到 5 个对象上的动作，在产物里注册 5 次）。#592 增加事件模型后这个差距被进一步拉大。

为什么这不是「改个数字」就完事

三个数各自都是真的，只是回答的问题不同：

• 读者问「我能用多少种动作」→ 族计数（13 那一类）；
• 读者问「装进环境后注册了多少条元数据」→ 26；
• 开发者问「我要改哪几个文件」→ 6。

README 那句话（「Plus 6 AI skills, 5 dashboards, 24 flows, 13 actions, 9 datasets…」）里其余每一项都是注册数，只有 actions 混了另一种口径 —— 这本身就是读者会被误导的地方，无论最终选哪个口径。

要定的事

1. 面向 marketplace 读者的 action 计数取哪个口径？
2. 定下后，README + docs/STATUS.md 两处一起改到该口径；
3. 如果取的是注册数，PR fix(metadata,docs): align the protocol declaration and the inventory counts with the stack (#728 #729) #1010 新增的 product docs state the metadata counts the stack registers (#729) 守卫加一条 actions 规则即可（该守卫的期望值是运行时从注册 stack 现读的，不需要硬编码），从此不会再漂；如果取的是族计数，则需要先让「族」在源码里成为一个可数的东西（否则任何守卫都只能对着一个手工数字断言，等于把漂移搬个家）。

倾向注册数：它与同一句话里其余所有数字口径一致，且是唯一能被守卫机械核对的口径；族计数若确有产品价值，更适合换一种写法表达（例如「6 组动作，覆盖 5 类对象」）而不是继续写成一个孤零零的 13。

相关：#1011（docs/STATUS.md 同处也写 13）。

Filed unassigned —— 这一单需要维护者拍板口径后才好动手，建议打 needs-user-decision。