R1.06.1contribution authority设计
需要明确谁可以新增组件
别名: 新增权限 · 贡献权限 · who may add · 写入权
概念解释
「把一个新组件写进共享库」不是往自己仓库加文件，而是改写一份被许多产品同时依赖的契约。这份写入权必须落在可指名的角色上——某个值班人、某个委员会、某条代码所有权记录——而不是落在「觉得痛的人」。这个决定点叫贡献权限（contribution authority）：谁有权把新原语送进体系。它回答的是资格，不是门槛有多高，也不是库里已经堆了多少东西。
资格含糊时，每个人都会按自己的局部痛点做一次写入。权限清楚时，拒绝也有署名，接受也有署名。
机制
共享库是多人同时阅读、少数人应当写入的结构。写入一旦发生，所有调用方的升级路径、主题切换和缺陷修复都被绑到这个新名字上。若写入权默认等于「能提交代码」，局部最优会自动发生：这个页面差一个日期选择，作者最熟自己那一页的字段，最短路径就是再做一个。决策不可定位时，没有人能对「这个名字该不该存在」负责，事后也找不到该问谁。
权限的作用是让「加入体系」从私人动作变成可审计的公共动作。被授权的人不必亲自写每一行，但必须能被叫到：接受或驳回都留下记录。没有这个定位点，后面所谓的评审、用例门槛、维护交接都没有主语。
边界
三五人、单一产品、组件总数用手数得清时，写入权可以就是那个小队本身，不必另设委员会。平台级、多品牌、库被几十个仓库依赖时，默认「能 push 就能加原语」会迅速失真。开源体系可以把写入权交给维护者投票；公司内部把写入权交给「提出需求的业务线」则把公共契约交给了局部预算。紧急热修复可以走临时通道，但临时通道必须写明到期日和转正条件，否则热修复会变成永久作者。
怎么落地
- 用一句话写清：新增原语的接受人是哪个角色，以及这个角色如何轮换。贴在贡献说明的第一屏，不要埋进会议纪要。
- 把该角色写进代码所有权文件或等价清单，使「谁能合并新组件目录」与「谁被点名」一致。
- 申请模板第一项是「你已与接受人确认资格」；未确认的请求不进入评审队列。
- 验证：分别问设计、开发和一个产品经理「谁可以往库里加一个 DatePicker」。三人给出同一可联系的名字或角色，权限才算明确。答案是「谁方便谁加」「找设计系统组看看」或互相矛盾，资格就还没有落地。