R1.06.2ungoverned accretion设计
无治理的系统会退化为组件堆
别名: 组件堆 · 无治理堆积 · catalog entropy · 库膨胀
概念解释
没有人定期问「这是新原语，还是旧件的换皮」时，库的规模会跟着页面数涨，而不是跟着任务种类涨。每次新增在局部都说得通——这一页的卡片圆角差 2 像素、那一页的空态插画不同——叠在一起却变成无法检索的目录。这个过程叫无治理堆积（ungoverned accretion）：不是一次爆炸，是一串未被拦截的合理添加。它描述的是库在无人守门之后的形态，不是谁有权走进门，也不是门槛设得太高把人逼走。
堆的判据是：找一个已有能力，比再做一遍更慢。
机制
每一个新名字都占用检索、文档、主题适配和缺陷面。调用方选择组件时，面对的是一份选项清单；清单变长，匹配成本上升。当「搜完仍不确定该用哪个」的时间超过「在业务仓库里写一个够用的」，理性选择就是绕开目录再造一个。新的这一份又进入目录——如果目录来者不拒——于是搜索空间再次变大。堆积是正反馈：局部合理的加法，在没有「合并 / 拒绝 / 降为变体」的裁决时，会把目录的信息密度稀释到不可用。
治理在这里不是礼仪，是给加法配上减法或归并。没有归并，组件数是页面数的影子，不是职责数的影子。
边界
项目第一个月允许快增：职责边界还在动，过早冻结目录会把错误骨架留下来。堆积判据适用于目录已经被当成「可检索的公共面」之后。营销活动站、一次性运营页，本来就可以是用完即弃的集合，不必按产品库的治理强度来管。反过来，把产品主路径的控件按活动页的方式无限追加，几个季度后就会出现「四个按钮、三个对话框、两套表格」并存且无淘汰规则。开源展示型目录故意做全，那是样品间，不是运行中的产品契约。
怎么落地
- 给每个组件标注调用点数和最后一次被修改的日期。调用点为 0 或 1、且超过一个季度无修改的，进入合并或删除候选，而不是继续展示为推荐。
- 新增请求必须声明「它替代谁 / 它与谁是变体关系 / 它为什么不是现有件的参数」。三项都空的，按堆积处理，不按新原语处理。
- 每个季度做一次目录减法：合并只差装饰的重复件，删除无调用点的名字。
- 验证：抽一个中等常见任务（日期选择、筛选条、空态），让未参与过该库的工程师在文档站里找出「该用的那一个」并开始调用。十分钟内找不到唯一答案，或找到三个看起来都能用的名字，目录就已经是堆。把候选清单里 0–1 调用点的条目数画成趋势，曲线上升就是堆积仍在发生。