当前能力与限制

Read this page in English

本页以当前 Creator Source Package v1 loader、compiler 和 local_owner_synthetic_preview build target 为准。它用来回答“现在真的能做什么”，而不是描述未来 Creator Center 的目标形态。

Source 能力不等于 runtime 已经可用

下文大部分内容描述 Creator Source Package v1 能表达什么、compiler 会校验什么。它不代表当前 application 已经执行这些完整机制。当前 application code 支持普通 model-backed 对话、最小的 process-local turn trace 和显式的手动 owner checkpoint：第一次提交角色自主的有界决定、确定性结果与公开等待状态；第二次发布经过校验的主动回访。当 package 为已提交分支声明了可选的 progression.aftermath 回访链时，后续 checkpoint 会按 Creator 顺序逐拍走完这条链：普通拍由 checkpoint 推进——提交该拍 Creator 固定的 world event 并展示该拍的公开等待文案——再发布该拍经过校验的回访；若下一拍是决策拍（beat 携带 decision_phase），下一次 checkpoint 就是一次新的决定而不是推进——提交该拍自己的 Creator-bounded 决定，其 world event 携带所选 outcome 的 facts，该拍的回访经由所选 outcome 的回访 follow-up 传达结果。结构化 Journal entry 与 public-safe causal timeline 只随该分支最后一次回访发布，Journal 会合并该分支全部已提交的决定；package-approved 静态结果图对每个 outcome 是可选的，只在 Creator 为最终 outcome 提供了 depiction 时随终局回访一起发布。没有回访链的 package 仍然只有两次 checkpoint。主动回访发布后，后续普通对话会从持久化的当前分支重建角色已做的决定、角色已观察的结果、所选 Creator-approved 披露授权、回访原文及相关承诺；其他分支和未观察事实不会因此获得披露权限。用户在普通对话里说出的承诺可以成为持久的互惠约定（#327 第一片）：当 package 声明了 reciprocal_promise，Character Actor 可以提出一个指向已编译约定的 commitment_candidate，必须引用用户原话，并与影响证据经过同一道置信度权威；回复必须把它说成待确认，只有之后某条用户消息被 Actor 读作 commitment_operation（confirm 或 decline），约定的每个承诺才会在普通对话 join 内原子地激活或关闭。等待确认期间玩家端只显示平台提示，激活后显示 Creator 原文的 presentation_after_activation；决策窗口的 commitment_state 谓词与重新协商尚未实现。它不提供 ambient scheduling（#325 的 opt-in TimeMappingProfile 之外）、外部通知或实时图片生成。成功 compile 也不会自动把任意新 package 安装或激活到 preview。角色离开（away_accepting_deferred）期间，用户可以留字（#326）：消息被接受并排序、不产生 turn 也不调用模型，随下一次回访冻结进 followup decision 并交给 Character Actor 与回访 renderer；dialogue.away_composer_placeholder 可选地声明这段时间输入框的占位文案。

当前已经实现

严格的七文件 source package

系统会从 content/creator-sources/<package-id>/v<version>/ 加载：

source-package.yaml
character.yaml
relationship.yaml
arc.yaml
dialogue.yaml
visual.yaml
acceptance.yaml

所有 model 都是 closed schema：未知字段会失败，重复 YAML key 会失败，浮点数会失败，文件路径逃逸和 symlink 会失败。编译器还会验证 ID、事实、决定、结果、回访、视觉和 Journal 之间的引用闭包。

一个角色、一段 arc 的关系循环

一个 v1 package 绑定一个 primary_character_id 和一个 arc_id，当前可以表达：

• 一位有价值观、自我概念、矛盾、边界、知识限制、披露上限和声音约束的角色；
• 用户作为 world 之外的 remote confidant；
• 一组语义化 influence kind，而不是关键词 route；
• 可选的虚构共享背景、互惠承诺和持久关系 episode；
• Creator-bounded 的决定、角色行动、确定性 world outcome，以及每个 outcome 恰好一个主动回访；
• 可选的 branch-scoped aftermath 回访链：某个分支决定的 outcome 提交后按 Creator 顺序追加多拍公开 beat，每拍是一次 away/回访循环。普通拍有自己的 Creator 固定 world event、专属回访与公开等待文案；一拍也可以携带 decision_phase 成为决策拍——该拍的入口 checkpoint 是一次新的 Creator-bounded 决定，而不是推进（决策拍不能是链的第一拍）；
• 叙事 deadline、显式 progression checkpoint、角色沉默时仍可自主决定，以及没有安全决定时的诚实收束；
• 精确 opening、guided ordinary conversation、recovery surface、semantic-lock follow-up 和 Journal；
• 已提供的 portrait、可选的公开 discovery cover/hook/crop/fact boundary， 以及每个 outcome 至多一张、可以省略的视觉候选；
• acceptance case 与 paraphrase range，用来保存创作者期望的行为范围。

决定后的 aftermath 回访链

progression.aftermath 是 optional 字段，用来把某个 outcome 的后果拆成按 Creator 顺序、由 owner checkpoint 逐拍推进的多拍公开 beat。当前 contract 与 compiler 强制：

• 每条链用 branch_of 绑定一个分支决定的 outcome（决策拍 outcome 不能再挂链），同一 outcome 至多一条链；beats 有序且至少一拍，beat ID 跨链唯一。
• 普通拍声明 id、title、narrative_gap、world_event（committed_fact_ids，可选 npc_cause_ids）、followup_id 与 away_projection。决策拍改为声明 decision_phase，禁止声明 world_event 与 followup_id（见下节）。
• 事实划分：每个普通拍的 committed_fact_ids 必须来自该分支 outcome 的 committed facts，各拍互不重叠，并且至少留一条 fact 由 outcome 随决定立即提交——分支事实在 outcome 与各普通拍之间恰好提交一次。决策拍不从分支 outcome closure 认领 fact：它提交的是所选 outcome 自己的 facts。
• 回访对应：每个 outcome 恰好有一个 outcome 回访 follow-up；每个普通拍另外恰好占用一个专属 arc follow-up，一个 follow-up 不能服务两拍，且该 follow-up 的 outcome_id 必须等于链的 branch_of。决策拍不占用专属 follow-up——它的回访经由所选 outcome 的 outcome 回访 follow-up 发布。
• 唤醒覆盖：声明 aftermath 就必须声明 deferred follow-up，且 conversation_availability.deferred_followup.consequence_return_wake_condition 必须精确覆盖每一拍（含决策拍）编译出的 consequence phase ref（consequence-phase:<branch_of>:<beat_id>）；没有 aftermath 时禁止声明该字段。
• away_projection 是这一拍公开等待状态使用的 public 文案；Creator 的 beat title 只出现在该拍提交之后发布的材料中。visual 对每个 outcome 是可选的且至多一张；Journal 仍然只随该分支最后一次回访发布，并合并该分支全部已提交的决定。

字段的结构约束以完整字段清单为准。

决策拍：携带 decision_phase 的 consequence beat

aftermath 链中的一拍可以携带 decision_phase，成为决策拍：上一拍的回访提交、对话重新打开后，该拍的入口 checkpoint 是一次新的决定，角色在这一拍的候选 envelope 中再做一次 Creator-bounded 选择。当前 contract、compiler 与 runtime 强制：

• decision_phase 声明 id（bare id，不超过 40 个字符，与分支 decision phase 及其他决策拍的 id 不重复）、candidate_decision_ids、input_window、no_eligible_guidance 与 silence。
• 决定划分：分支 decision_phase 与全部决策拍的 candidate 集合两两互斥，并集必须精确覆盖 arc.decisions——一个 decision 只能属于一个 phase。checkpoint 只提供当前待决 group 的 envelope，不会把其他 phase 的候选混进来。
• 每个候选 decision 仍恰好指向一个 outcome，每个候选 outcome 必须至少提交一条 fact；提交决策拍时，该拍的 world event 携带所选 outcome 的 facts，回访经由该 outcome 的回访 follow-up 传达结果。候选 outcome 的 visual 可选：纯文本 outcome 合法。
• input_window 只能是 first_readiness_event 或 since_prior_decision（until_decision_horizon 会被拒绝——决策拍在触发它的回访处关闭输入）。每次决定冻结自己的半开 influence window：下界严格大于上一个已提交决定冻结的输入切点，上界含本次切点；since_prior_decision 就是把下界显式定在上一个决定的冻结边界上。每个 phase instance 至多提交一次决定，各 window 两两不相交。
• 不要（也不能）为决策拍创作以下内容：world_event 与 followup_id（facts 在 outcome 上、回访按 outcome 对应）、自己的 readiness edge（入口由 compiler 从上一拍回访的 character_observed_consequence_return 唤醒词汇派生，输入闭合固定为 on_triggering_event）、放在链首的决策拍（它需要上一拍的回访作为入口）、从决策拍 outcome 再挂出的 aftermath 链。
• runtime 侧由 release capability explicit_public_beat_checkpoint_v3 承载：release envelope 按编译顺序命名全部决策拍的 decision request group；v1/v2 envelope 遇到含决策拍的 bundle 会 fail closed，而不是加载出无法到达的内容。checkpoint 控件保持中性文案，不会在提交前披露 beat title 或候选内容。沉默与真实时间流逝不推进也不决定任何事。

有限的事实披露控制

当前 v1 source contract 可以编码、compiler 可以校验：

• 在角色层声明默认披露上限，并固定 hidden_motives_disclosed_by_default: false；
• 通过 must_not_disclose_fact_ids 禁止 ordinary 或指定 follow-up 披露某些 fact；
• 要求 follow-up 只披露角色已经观察到的 committed fact；
• 为每个 follow-up 声明 disclosure_options 的 reveal/withhold 集合；
• 防止 visual 展示 private 或未提交的 fact。

这些能力适合“这个 surface 可以知道什么”的确定边界，但还不是通用的渐进式秘密披露系统。

一次主动回访成功发布后，ordinary conversation 可以继续引用该回访已经获准公开的 outcome fact。这个授权是当前 relationship、当前已提交 outcome 和所选 disclosure option 的交集；它不会把其他 outcome 的 fact、角色未观察到的 fact 或 Creator 禁止公开的 fact 暴露给 Actor 的公开回复或 Renderer。

确定性编译与复核

当前 CLI 可以把完整 package 编译为：

Creator Source Package
→ Canonical Authoring IR
→ RuntimeBundleContent

输出目录以 bundle SHA-256 寻址。用相同输入运行 --check，可以重新编译并逐项比对已有 artifact。编译命令见快速开始。

语言能力

当前 platform policy 为 package 默认 locale 提供：

• zh-CN
• en-US

这意味着中文 package 和英文 package 都能通过同一个 generalized compiler。当前内部验证同时覆盖一份中文完整实例和一份结构不同的英文 synthetic canary。

当前模型有以下限制：

1. 一个 package version 只有一个 package.default_locale。
2. dialogue.recovery.degraded_chat.locale 和所有 dialogue.recovery.chat_only[].locale 必须等于该默认 locale。
3. opening、ordinary meaning、follow-up meaning、Journal、alt text 以及 aftermath beat 的 title/narrative_gap/away_projection 等字段没有一套完整的多 locale map；它们是该 source version 中的一份创作文案。
4. arc.progression.decision_phase.no_eligible_guidance.public_projection.text，以及每个决策拍 decision_phase.no_eligible_guidance 中的同名字段，可以包含多个 locale，但至少必须包含默认 locale。这是局部多语言文案，不是完整 package localization。
5. 当前 platform presentation catalog 不支持 zh-TW、ja-JP 等其他 locale；把这些值写进 default_locale 会在编译时失败。

因此，当前“支持中英”准确地说是：可以分别创作并编译以 zh-CN 或 en-US 为默认语言的 package。它不是在一个 package version 中自动切换完整中英文体验。真正的双语 package、共享语义与两套 Creator-approved 文案如何版本化，仍需要后续设计和 schema 支持。

当前仍不支持

通用的渐进式秘密状态机

当前没有字段可以表达：

• 秘密的多阶段 unknown → suspected → partially_revealed → fully_revealed 状态；
• “用户 probe 两次后才说”这类计数规则；
• 基于 trust、关系 episode 或对话证据自动解锁 disclosure tier；
• 跨多个 arc 累积的秘密进度；
• 角色可拒绝、试探、转移话题后再逐步披露的 typed transition graph。

可以用 fact allowlist/denylist 和 follow-up disclosure option 做有限控制，但不能只靠 meaning 或 prompt prose 假装上述机制已经被 deterministic enforcement。新增 typed disclosure contract 应作为 schema/runtime 能力单独实现并接受后，再加入本指南。

完整的多阶段剧情与世界模拟

当前 local_owner_synthetic_preview 要求 Arc Progression V1。v1 progression 有一个分支 decision phase、一个 terminal horizon edge 和一组 bounded decision，并可以为单个分支决定的 outcome 追加可选的 branch-scoped aftermath 回访链：决定提交后，该分支的后果按 Creator 顺序拆成多拍公开 beat，每拍是一次 away/回访循环。链中的一拍可以携带 decision_phase 成为决策拍，因此一段 arc 现在可以表达多个 decision phase——但只在这些边界内：每个 phase instance 至多一次决定；决策拍不能是链的第一拍；链只能从分支决定的 outcome 挂出（不能从决策拍的 outcome 再分叉）；没有决定之前的接触窗口，没有 seasons 或跨 arc 状态继承，推进只由显式 owner checkpoint 驱动。这能表达“决定之后的多拍升级和再次抉择”，但仍不是 ambient scheduling（#325 的 opt-in TimeMappingProfile 之外）、自由探索世界、连续任务树或任意 NPC simulation。

progression 在 source model 的语法层是 optional，但当前 build target 会拒绝没有 progression 的 package。对今天可编译的 package，应当把它视为必填。

自动生成或批准素材

visual.yaml 引用已经存在的文件。完整 package 若要进入 package-driven 角色画廊，需要提供公开 visual.discovery；旧 package 为兼容仍可省略该字段。 具体格式见画廊封面指南。当前编译器不会：

• 生成 portrait、discovery cover 或 outcome image；
• 训练 LoRA；
• 判断形象是否忠于 IP；
• 批准某个精确 asset；
• 因 provenance_ref 存在就推断权利或授权。

portrait 与 outcome 支持 .avif、.gif、.jpeg、.jpg、.png、.svg 和 .webp；discovery cover 只支持其中的静态 raster：.avif、.jpeg、 .jpg、.png 与 .webp。后缀比较不区分大小写，bundle 中的目标路径由 asset ID 与规范化后缀生成。

Creator Portal 中的浏览、编辑与发布

当前 Creator Portal 可以从 PostgreSQL Registry 通用地浏览 project、package、 version、immutable revision 和文件，并把选中的 revision 下载为保留原始逻辑路径与 字节的确定性 ZIP。在当前 draft HEAD 上，它可以替换一个已有的 package-local UTF-8 文本文件，并用 expected-HEAD 冲突检测追加新的 immutable revision。它还不能新增、 重命名或删除路径，不能编辑二进制或 reserved historical asset。Fang 可以显式检查任意 选中的 immutable revision；Portal 会持久化并显示 passed/failed、typed diagnostics 和 duration。检查不会阻止保存不完整的 draft，也不会移动 HEAD。Portal 仍不能完成 upload、 source ingestion 或通用 release compile。Build Preview 可以针对一个 immutable revision 和固定服务端 profile 缓存 ready 或 blocked 结果；ready 时可以下载一份 确定性、不可激活的 Preview Bundle ZIP。它不会 freeze、approve、qualify、publish、 activate 或改变 runtime/catalog/relationship。旧 Creator Workbench/Test Evidence Explorer 仍是固定内容的只读审阅面，只绑定其单独验证的 导入快照。Registry 中出现 package 不代表它已经拥有 Workbench 详情或 Test Lab 证据。

面向外部用户的运行

当前 build target 是 local_owner_synthetic_preview。现有范围只允许 owner-authored synthetic input 的本地 PoC；不包括 tester、consumer、public、remote 或第三方数据，不包括真实关系历史和外部 proactive notification。更广范围需要另行确定身份、同意、隐私、保留、删除、安全和发布控制。

当前 application code 已经实现普通对话、最小 turn trace 和显式手动 checkpoint：第一次提交角色决定、world outcome 与等待状态；随后每次 checkpoint 发布经过校验的主动回访，或在该分支声明了 aftermath 时按 Creator 顺序推进下一拍 beat；下一拍是决策拍时，checkpoint 是一次新的决定而不是推进。结构化 Journal 与 public-safe causal timeline 只随该分支最后一次回访提交，Journal 合并全部已提交决定；package-approved 静态结果图按 outcome 可选，只在最终 outcome 有 depiction 时一起发布。回访后的普通对话会继续使用这一次已提交 episode 的 branch-scoped context，但这不是多 episode 长期记忆、关系 episode evaluator，也不是任意的多阶段 arc progression：决定之后的升级只能沿 Creator 排好的 beat 链由 owner checkpoint 逐拍推进，额外的决定只出现在 Creator 排好的决策拍上，没有决定之前的接触窗口或跨 arc 状态继承。这仍然不是 ambient scheduling（#325 的 opt-in TimeMappingProfile 之外）、外部通知或实时图片生成，也不会因为某个新 package 编译成功就自动运行该 package。

任意 provenance 类型

v1 的 provenance[].role 只接受：

• historical_hybrid
• governing_product_decision
• semantic_normalization_authority
• synthetic_fixture_origin

这足以记录当前历史 normalization 和合成 canary，但还不是完整的原创手稿、授权文件、艺术素材和 Creator correction provenance vocabulary。不要为了通过 schema 而给真实来源贴上不准确的 role；遇到无法诚实表达的新来源，应先扩展并审阅 contract。

怎样确认某项能力现在可用

不要根据路线图、概念稿或一段自然语言说明，推断某个字段或 runtime 行为已经存在。判断一项内容能否写入当前 package 时，按以下顺序检查：

1. 完整字段清单中是否存在该字段；
2. 语义创作指南是否定义了它的含义和跨文件约束；
3. 本页是否把对应 runtime 行为列为当前已支持；
4. 如果只描述了未来目标，就把它明确留作开放需求，不要塞进现有 prose 字段模拟确定性机制。

遇到关系身份、角色自主性、秘密披露、Creator approval、权利、隐私、发布范围或主动消息时，应在实现前与 Meet-U 团队明确设计和授权边界。