生命周期与权限边界

Read this page in English

Creator Source Package 的职责是保存人类创作者拥有的语义，不是把审批、运行时配置或发布权限塞进 YAML。当前架构明确分成四层：

Creator Source Package
→ Canonical Authoring IR
→ RuntimeBundleContent
→ ReleaseEnvelope

四层分别负责什么

1. Creator Source Package

由创作者负责审阅的 human-readable source，包括：

• 角色身份、价值观、矛盾、边界和声音；
• 用户与角色的关系及沟通前提；
• world fact、NPC 知识与剧情 dilemma；
• 角色可选择的 decision space；
• 每个决定对应的 action、world outcome 和 follow-up 意义；
• 对话、视觉意图、素材引用和 acceptance evidence。

它可以记录 provenance reference，但 provenance 字符串本身不授予权利或审批。

2. Canonical Authoring IR

由 compiler 确定性生成，负责规范化 ID、引用、typed semantics、平台 policy 和字段 provenance。它不是第二份供创作者手工维护的 YAML。

3. RuntimeBundleContent

供 generalized runtime 消费的不可变可执行内容。它只包含运行所需的最小 contract 和素材闭包，不包含“已批准”或“已激活”之类可变 claim。

4. ReleaseEnvelope

理论上负责把一个精确 bundle、runtime configuration 和允许的使用范围绑定起来，包括权利、Creator approval、asset approval、qualification、到期、撤销、quarantine 和 activation。

当前产品还没有面向普通 Creator 的完整 release workflow。历史 owner-preview artifact closure 也不能复制到另一个 package 或更广 audience 当作授权。当前本地 PoC 使用简化的 owner-only 交付边界，但仍不获得 tester、consumer 或 public scope。

为什么 YAML 里不能写“已批准”

source loader 会拒绝 approval、release、activation、provider、model、prompt、scheduler、retry、lease、transaction 和类似 lifecycle 字段。常见被禁止的概念包括：

• creator_approved、approval_status、asset_approval
• rights_status、qualification_status
• release_status、activatable、activation_state
• provider、model、prompt、temperature
• scheduler、retry、lease、idempotency_key

原因不是这些事情不重要，而是它们属于不同 authority：创作者可编辑的内容不能自行宣布自己已获批准，也不能选择运行平台的 provider 或交易机制。

编译阶段会发生什么

运行 meet-u-compile-pilot 时，系统会：

1. 安全加载七个 YAML 文件和声明的 asset；
2. 验证 closed schema、路径、ID 唯一性和跨文件引用；
3. 加载与 build target 绑定的平台 policy 和默认 locale presentation；
4. 确定性生成 Canonical Authoring IR；
5. 生成 RuntimeBundleContent，把素材复制进 content-addressed closure；
6. 返回 source、IR、bundle、compiler、policy 和 canonicalization digest。

compile result 中每次运行的 UUID 可以不同，但有效 source、compiler、platform policy、canonicalization 和 compile option 完全相同时，Canonical IR 与 RuntimeBundleContent 的 bytes/digest 应相同。编译器不会调用 LLM；AI 可以协助起草，但影响产品的生成内容必须先变成 frozen、由人类 Creator 审阅并带 provenance 的 source。

CLI 还有两个通常不需要手动设置的 identity flag：

• --source-ref 默认生成 repo://content/creator-sources/<package-id>/v<version>；任何非 canonical override 都会被拒绝。
• --idempotency-key 接受 UUID，用于 compile command lineage；省略时 CLI 生成新 UUID，它不改变 deterministic IR/bundle identity。

成功结果的关键状态仍然是：

{
  "status": "succeeded",
  "activatable": false
}

--check 会 fresh compile 并确认已有 content-addressed bundle 的目录和文件 digest 完全一致。它验证 reproducibility，不验证创作质量、权利或发布资格。

编译前与编译后仍需要的人类判断

编译前

• Creator 是否拥有或获准使用该 IP 与 source asset；
• package 是否忠实保存 Creator intent；
• 角色边界、秘密、拒绝方式和决定空间是否正确；
• outcome 是否来自角色决定和 World/GM，而不是直接执行用户文字；
• exact dialogue 与视觉候选是否适合该角色。

编译后

• source 与 compiled candidate 是否仍符合 Creator intent；
• 只有在对应 runtime surface 已实现并绑定到获批 package 后，才检查实际行为；
• acceptance case 是否覆盖关键忠实度风险；
• 精确 asset byte 是否经过 Creator review；
• 允许的 audience、数据类型、provider 和环境是什么；
• 是否具备该 scope 所需的 qualification、privacy 和 activation authority。

当前 local_owner_synthetic_preview 只解决本地 synthetic PoC 的一小部分。不要把一次成功 demo 描述成外部测试或 production release。

当前 application code 已实现普通对话、最小 turn trace 和两次手动 owner checkpoint：第一次提交角色决定、确定性结果与等待状态；第二次发布经过校验的主动回访、一张 package-approved 静态结果图、结构化 Journal 与 public-safe causal timeline。这不等于 ambient scheduling、外部通知或实时图片生成；新 package 编译成功也不表示它已被安装或运行。

当前协作中可以诚实使用的状态

这些是沟通标签，不是新的 YAML 字段：

状态	可以诚实声称什么
Draft source	人类意义仍在创作，引用可以尚未闭合
Structurally valid source	loader 接受七文件 graph 与 asset closure
Compiled candidate	当前 compiler 已生成 deterministic IR/bundle；activatable 仍是 false
Creatively reviewed candidate	人类 Creator 已审阅 source 与相关 output；compile result 自身不记录这个判断
Behaviorally evaluated candidate	独立 evaluation evidence 覆盖精确 source/bundle/configuration 与声明 scope
Release-eligible artifact	外部权利、审批、配置、qualification 与 policy evidence 绑定精确 artifact/scope
Active release	独立、获授权的 activation 操作选择了该 eligible release

当前 CLI 和本指南只直接完成前三种状态。后续状态是架构上的必要区分，不表示仓库已经有通用 production release workflow。

版本和变更

package 的目录必须与 manifest 严格对应：

content/creator-sources/<package.id>/v<package.version>/

修改任意 YAML 或声明的 asset 都会改变 source/module closure digest，并通常产生新的 bundle digest。旧的审批、qualification 或 release evidence 不能自动覆盖新 bytes。

在专用 task worktree 中尚未进入审阅的 draft 可以反复修正；一旦某个 source version 已被人类 review 或绑定到 evidence，应把该 path/bytes 当成 frozen。不要手工编辑生成的 Canonical IR 或 RuntimeBundleContent；修改 Creator source 或 compiler 后重新编译。

Creator Source Package v1 目前没有完整定义以下创作者工作流：

• 什么修改只增加 character.content_version 或 arc.content_version；
• 什么修改必须增加 package.version；
• Creator correction、rollback、revocation 和 migration 如何记录；
• 双语文案变更如何与同一语义版本绑定。

这些是重要但尚未接受的产品决定。不要静默建立自己的永久版本规则；在真实 package 需要修改或发布时，应让 product/decision owner 明确变更范围和审批对象。

权限检查清单

在描述 package 状态时，分别回答以下问题，不要合并成一个 “ready”：

问题	当前 source/compile 能否证明
YAML 是否符合 v1 schema？	能
所有引用和 asset closure 是否完整？	能
相同输入能否重现相同 bundle？	--check 能验证
创作者是否拥有 IP 权利？	不能
创作者是否批准精确角色演绎和 asset？	不能
当前 runtime/provider 是否通过 qualification？	不能
是否允许 tester/consumer/public 数据？	不能
是否已 activation？	不能；当前结果固定为 activatable: false

交接一个 compiled candidate 前，至少复核完整七文件 diff、真实 provenance、普通 compile 与 --check、status: succeeded、activatable: false、实际选中的中/英文 surface，以及仍未完成的人类 review/evaluation。需要重现时，分别记录 source、module closure、IR、bundle、compiler、policy 和 compile-options identity。