创作者档案

解决什么问题

创作者信息散落在各平台的私信记录、表格和谈判邮件里：同一个作者在多个平台上的账号是否指向同一人、哪些条款已经签署、哪些权益即将到期，往往只能靠人工翻找。更糟的是，判断记录和业务结论混在一起——有人用分数给人“评级”，有人把风险偏好写进档案，一旦数据过期或判断口径变化，整个名单的可信度就崩塌了。

Creator Registry 只做一件事：把事实和来源沉淀为可审计的事件日志，让每一个创作者条目都能回答“这条记录是谁在什么时候基于什么授权写入的”。

核心机制

• 单元是稳定的聚合 ID：每条创作者记录对应一个匿名聚合 ID，附带经过验证的跨平台账号链接，而不是可被随意改写的描述性文本。
• 事件流是唯一事实源：所有变更通过 scripts/registry-events.py 以事件形式写入 memory/events/creators.ndjson，每条事件带有 event ID、offset、source、date 和 authorization，永不覆盖历史行。
• 提案与裁决分离：外部技能只能提交 operation: propose 的待审事件；只有具备 creator-registry 能力的 principal 才能执行 accept/reject/upsert/transition，memory-management principal 才能在明确授权下 tombstone 或擦除。
• 人工视图是投影：memory/creators/ 下的 Markdown 档案由已接受的投影状态重新生成，事实不会先出现在文档里再“补票”。
• 最小数据原则：只保留协作所需的事实字段；原始邮箱、电话、地址不得出现在事件 ID 或摘要中。

写入前需确认用户明确授权，并对自然人数据给出合法依据；处理同名账号时，仅凭名字相似不能合并，必须有跨平台验证链接或用户确认。

适用边界

这个技能不计算 STAR 分数，不判断合规与否，也不决定与谁合作——STAR gate 的产物只作为合规事件 ID 登记，不会被翻译成“安全/有风险”的标签。它同样不做进粉数对比、不推算合作效果，营销结论请交给下游技能。

另外，独立文件夹安装只能准备提案，无法追加事件或生成投影，因为缺少经过验证的 root runtime、event schema 和系统目录。首次持久化写入前必须先询问用户；即使 revision 冲突，也只能重新读取对账，不能强行覆盖。