roleplay-card-authoring

Imported from a86582751/dsh-nexttavern (preset/skills/roleplay-card-authoring/SKILL.md). Install upstream with npx skills add a86582751/dsh-nexttavern --skill roleplay-card-authoring. Copyright stays with the author.

读卡 / 写卡工作流

角色扮演的第一阶段是「读卡」或「写卡」。此后系统不再把整张原始卡放入上下文——卡片被分类写入各栏目，按栏目角色注入。

玩家无需知道工具、游标、哈希或覆盖率。普通的“读取这张角色卡，准备开始角色扮演”即可启动下述完整导入；“导出角色卡”默认导出当前选中分支最新保存的全部角色设定为 Markdown。读卡/导出是管理操作，不当成剧情扩写。缺少卡片时只请玩家提供附件；不能拿旧卡或参考卡代替。临时失败使用相同参数有限重试，校验缺项补齐，无法恢复时用普通语言说明未完成，不排查服务器代码或绕过校验。

一、卡片栏目（分类目标）

上传小说后改编新卡

上传小说是创作资料，不能把整本小说交给角色卡导入流程，也不能把全文放进核心设定、世界书或常驻上下文。普通原创写卡先走互动问卷和十二项检查，不读取小说笔记或小说向量；导入现成卡也只走导入流程。rp_source_status 和资料库 list 都是只读查看，绝不切换到研究模式。只有用户明确选定原著并成功 rp_source_begin(source_path)（或在资料库 attach 后明确继续改编）才开始小说改编；之后重新生成或重写复用已有阅读笔记与向量。改编尚未完成时不能把模型刚生成的草稿伪装为现成卡导入来绕过门槛；完成原著研究与 rp_source_finish 后，生成的完整 Markdown 可正常导入。用户明确放弃改编并决定改走普通原创或现成卡流程，先 rp_source_close(mode:'authoring')，再继续。首次登记或原文真正变化才冻结 TXT；支持 UTF-8、GB18030、带 BOM 的 UTF-16，自动识别结果需要核对。程序保留完整文本与来源哈希，章节分段不丢卷首、空行或超长段落。

1. 沿用后文的互动问卷与十二项创作标准。先确认玩家角色、改命起点、想改变的命运、原著还原程度与剧透边界；已知答案不重问。对“我要当纳兰嫣然逆天改命”，重点找退婚前后的可改变选择、她与云岚宗及萧炎等人的关系、角色各阶段真实知情范围。只把这作为研究问题，不能靠模型记忆替代用户上传原文。

2. 精读沿 rp_source_status 恢复未读位置和分页阅读目录；已有分段笔记时优先 rp_source_notes 复用，只从 nextSegment 补未完成分段；首次阅读沿 rp_source_read 顺序读取完整分段。每个尚无笔记的分段读后用 rp_source_note 记录原著事实（facts）、改编机会和条件（implications）、疑问/矛盾/待查人物（questions），并附该段可核对的原句（evidence）。不要只复制一句话充当阅读理解；事实笔记应保留人物动机、关系变化、时间/能力限制和事件因果。记录完成后原文工具历史会变成短回执，需要时可再次读取。中断后从实际进度续读，不谎称全书已读。

   粗颗粒度执行顺序：复用相同问卷、原文、索引、笔记、草稿检查和导入工具，不另建一套流程。按下面的循环研究，不把覆盖率清单当成理解小说的替代品。

   • 准备：必须已配置并测试可用的小说语义模型。ADAPTATION_COARSE_MODEL_REQUIRED 表示本轮结束，保留资料，待玩家配置或改选精读。用 status 查看目标、关系 frontier 和分布式抽样坐标。作品陌生或目标含糊时，可选 web_search/web_fetch 查公开简介来提出偏好问题；网页只提供低信任线索，不认证原著事实、不下载小说。无网络时用目录和原文抽样了解作品。调用一次索引 wait，由程序等完整索引并通知结果，不循环 status。
   • 先追主角纵向经历：调用 rp_source_research(action:"character-map", entity:主角姓名) 查看姓名及候选别名在全书的分布、首末出现和各阶段回读坐标。地图不返回原文，不代表读过；按坐标 read 后才能认证。对照前、中、后期的目标、知情、关系、能力，记录变化的促因、行动和后果。不能用十条最相似片段代替成长经历；插叙的文本顺序也不是事件时间。
   • 再扩展关系网：query 一次是一轮，首轮一个种子，后续从读到的原文选最多三个值得追查的人物、组织、地点或事件。每词默认最多十个约千字符原文包；hits_per_query、context_chars、round_budget 可按需调整，默认七轮预算不是必须凑满的次数。用 keyword 补专名和别名，用 semantic/hybrid 查不同表达。根据已读事实保存带引用的 edges[{from,relation,to,citations}]，让程序更新 frontier；不要仅为填满五个类别反复给同一段换标签。
   • 每批读完立即整理并确认：程序合并重叠，正文通过只读 evidence context 交付，工具回执提供 packet ID；未交付的坐标不能引用、不能算已读。优先用 append 原子追加 1–8 条事实，按工具 schema 填写 certainty:"verified-original"，不传 id。人物事实要有 entity/topic；因果链每个 action 都要有其自己的 citations。save 用于单条兼容或 unknown 编辑。原句从已交付正文逐字复制，不拼接被截断的句子、不猜位置；失败按具体字段修复，不反复试猜结构。
   • 避免原文持续占用上下文：完成一整包的理解、疑点记录和必要事实保存时，在最后一次成功的 verified append/save 顶层传入该批已经整理完的 source_packet_ids，取得 researchCheckpoint。即使不是每一段都与改编有关，也应在审阅后确认已完成的整包；仍需对照的包暂不确认。单句引用不会自动确认整包；失败、unknown 笔记不能替代确认。程序会回收已确认的原文上下文，资料仍保留，可用 entries 恢复思路，必要时再显式 read。
   • 补缺再写卡：从原文和人物阶段变化提出新问题继续 query/read，检查抽样是否只集中开篇或热门人物。全局区间、主角专题、因果链及真实 semantic/hybrid 查证满足后再 finish；未知项保留来源入口。语义回退关键词不能冒充完成语义核查，粗模式也不能自称已通读或保证无遗漏。

3. rp_source_search 支持 keyword / semantic / hybrid。关键词用人名、别名、势力与事件组合；语义适合找表达不同的相关情节。小说研究模型是独立的全局选择，与剧情记忆模型不继承；供应商目录仍共用；精读未明确选择时关键词流程仍可用，粗颗粒度则必须先配置小说语义模型。语义依赖已配置的共享 Embedding 接入，rp_source_index(action=status) 查独立原文索引；action=index 主动首次建库或补缺，由程序自行分批入队，不依赖剧情自动语义索引开关，成功向量不重复编码、失败/未知不自动重试。全部原文段 covered 且 pending/running/failed/unknown 均为 0 时，索引策略为 completed；向量仍可查询。若 status 明确 stale=true，先在面板查看当前 fingerprint；后台在线模型或未开启本地自动修复时，实际语义／混合查询会显示全局自定义确认，取消不重建且相同请求短期去重，不能由 agent 直接调用 rebuild 或通过其他工具绕过确认。程序拒绝过期指纹、正常或已修复索引的再次重建。一般重试失败、清空与全量重建在「长文本转角色卡」面板由玩家明确操作。玩家已手动暂停或清空时不能擅自恢复。建库可与顺序阅读并行。读完且保存分段笔记后，调用 rp_source_index(action=wait)：程序等待完整索引，最长 15 分钟并响应取消；不要循环 status、不要重复提交 index。然后对研究疑问用 semantic/hybrid 查证并回读原文。语义命中只是定位，不能算全章阅读，更不能当模型已核验的事实。精读未选择小说模型时明确采用关键词流程；粗颗粒度必须先配置模型。 小说 TAB 的两个全局默认选项互不替代：新导入/关联自动准备索引只影响新绑定，有兼容索引就复用并补缺重试；活跃本地自动修复只处理当前查询的 stale 或已存索引格式损坏，不批量重建、不恢复手动暂停。均默认关闭。在线重建始终由玩家确认。

4. 写卡阶段精读按 rp_source_notes 分页或关键词取研究笔记；粗颗粒度按 rp_source_research(entries) 读取已核实底稿与私有 unknown，关键细节用对应 search/query/read 回到原文复查。先统一世界基础、人物关系和改命分歧，再编写完整卡。未来原著事件是条件路线、威胁和可能后果，不是扮演中已经发生的正史，也不能让开场人物提前知道未来。 写卡遇到剧情前后矛盾、解释含糊、关键点缺失、伏笔/设定不清或人物关系性格模糊时，必须主动回到 notes，再用 keyword/semantic 定位并 read 原文，必要时对照前后段，保存证据笔记后才能继续写卡。不能凭印象、预训练知识或单次语义命中补全；原文无法解答时明确写“原文未说明”或“矛盾未消解”，把改编推演与原著事实分开标注，不编造证据。查询次数按实际疑点和复杂度决定，不用固定次数代替核查质量。

5. rp_source_finish 是正式写卡前的程序门槛：精读要求所有分段有证据笔记；粗颗粒度要求全局区间与抽样、主角专题和关键因果链的原文证据，并且有可用模型、完整索引和至少一次真实 semantic/hybrid 查缺补漏。未就绪时程序等待，未核查时拒绝；不要先写卡再补检索。已完成索引保留 completed，向量仍可查询。索引只证明程序覆盖，不保证语义理解正确，仍需主代理按实际疑问审阅。随后照常生成完整 Markdown，运行 rp_card_draft_check 的十二项检查，按用户已授权范围交付或激活。参考卡仅作结构参考，不补写原著事实。

完成 Markdown 和 rp_card_draft_check 后，本轮用普通最终回复交付文件链接并结束；可以文字说明下一步，但不要用 ask_user_question 追问“是否立即开始/导出”而把序幕接进研究或写卡轮。模式与偏好问卷仍照常使用。用户已明确授权直接导入或开玩时，按该授权继续，不另加确认。

研究资料重启可恢复；同一对话工具栏的重新生成/改写世界线共享完整原文、阅读笔记与索引，不能从头重读或重建。独立新对话可先 status，再用 rp_source_library(action=list) 找已登记原著，按 asset_id 与 library_revision 执行 attach；重新 begin 同一文件也会自动匹配。原文哈希、解码与阅读分段一致时复用笔记和断点；向量还必须匹配完整模型配方（包含编码预算）。当前卡修改/删除笔记是私有覆盖，不能据此声称已经改正其他卡的基线。多引用原著的破坏性索引操作需玩家在面板确认；finish/close 持久暂停本对话请求，其他仍在阅读的引用可继续索引。研究向量空间与剧情记忆分离；资料和笔记保留以便复读，但不注入后续角色扮演、不参与剧情窗口预算、不作为正式导演笔记。嵌入模型只检索相似片段，不承担事实判定或自动总结。用户停止改编时必须显式调用 rp_source_close(mode:'authoring') 回到普通原创写卡，或 rp_source_close(mode:'roleplay') 回到已激活卡片正文；两者都会退出研究，保留资料但绝不带入原创卡或 RP 正文。

叙事与回复规则应承载作者的创作方法：视角、镜头、细节密度、节奏、人物知情边界，以及单次回复如何展开。 不要把这一栏目理解成要求角色卡作者添加繁琐的安全声明。日志隐藏、权限隔离、 来源保真、分支与记忆维护等属于系统责任，不能拿来替代作者创作方法或凑满检查清单。

二、模块化人设格式（参考示例）

系统内置两张参考卡，写新卡时选择与目标最相关的一张按需读取：

• 龙女卡：__NEXTTAVERN_PRESET__/reference/模块化卡格式示例-暴躁龙女皇.md，用于人物关系与剧情驱动力参考。
• 《雾港第十三声钟》：__NEXTTAVERN_PRESET__/reference/steam-tide-full-card.md，用于完整分栏、多角色、世界书、状态与正文美化协同参考。它是系统随附的完整卡，不依赖上传会话存活。 参考结构与创作方法，不照搬人名、背景、秘密、剧情或玩家设定。不得把参考卡作为读卡缺项的补丁。

行动建议只在系统独立决策卡展示。 写新卡时，状态栏只设计时间、地点、人物、资源等当前事实，不写“可以试试/下一步/活动建议”区、A/B/C 列表、行动占位符或点击填入按钮，也不要求正文末尾再输出建议。参考卡中的旧版状态栏活动建议规则不沿用。若题材需要特殊的选择原则，写入剧情指引，供独立决策卡参考，不另建展示区。导入已有卡时仍原样保存作者来源，旧行动区由程序兼容隐藏，不改写导入原文。

标准交付模块（题材无关；章节可调整名称，语义不能遗漏）：

1. 整体概述：标题、类型、基调、玩家身份、核心体验、起始目标与可玩钩子。
2. 核心设定：常驻世界背景、特殊种族、基础规律、核心威胁及长期矛盾。仅保留每轮推理必须知道的完整基础。
3. 世界书·势力：组织的目标、资源、关系、秘密和可检索关键词。
4. 世界书·地点/物品/术语：重要场景的感官描写、用途、可互动线索、关联条目和关键词；详细低频资料在这里。
5. 人物设定：玩家与每个主要 NPC 分节；每人具有基本信息、个人小传、外貌衣着、性格、萌点、特质/能力、语言风格与台词、喜好憎恶、动机、秘密、关系与行为逻辑。玩家未授权的身份细节可留为可选项。
6. 剧情指引：多条可能路线、触发条件、推进节点、风险与可能结局；玩家可偏离，不写成已经发生的正史。
7. 文风特化：完整创作要求和真正的示例段落，包含节奏、感官、句式及对话；不是风格关键词列表，不是剧情历史。
8. 叙事与回复规则：作者的视角、镜头语言、细节密度、节奏、人物知情边界、单次回复如何展开。不要拿“不泄漏日志、正确归档、尊重分支”等程序兜底事项充数。
9. 开场剧情：可以直接玩的完整第一幕，以尚待玩家决定的行动收束；不提前走完路线。
10. 状态栏：字段含义、初值、变化依据、范围/单位、更新规则与开场一致。简单卡可以使用字段/文本状态栏；需要组件化外观时再提供完整 HTML 模板和配套 CSS。状态组件的 CSS 和 HTML 都归状态栏，不能混入正文纯 CSS 栏。HTML 与 CSS 可以分别使用已闭合的代码围栏，但必须留在同一个状态章节/assignment 中。核对字段、HTML、CSS 和更新规则均无行动建议区；下一步选择统一使用独立决策卡。
11. 正文 HTML/CSS 美化与正则：正文标记约定、配套 HTML 片段、纯 CSS、可解析的 regexRules JSON（match/replace，必要 flags）；至少两条有实际匹配示例的规则。没有交互需求可明确 JS 无需配置，不塞占位脚本。

背景简单的题材也应有适量可用的地点、关系网络和状态；不为凑栏目硬造世界末日。完整指每项可直接使用，不是统一字数或无限扩写。

三、读卡流程（导入已有卡）

上传卡就是唯一事实来源。导入已有卡时禁止读取参考卡，也禁止用硬盘里的旧卡、示例卡或先前会话产物来猜测、补全、纠正本次上传卡。 参考卡只用于「从点子创作新卡」。

A. 建立持久、可审计的规范化原文

1. 对 docx/pdf 调用 anydoc 时，必须传 outputFilePath。先在当前会话工作区内建立持久目录（例如工作区下的 .dsh-card-imports/<本次导入标识>/），再把输出写到该目录的绝对路径；不得写 /tmp，不得只依赖会被截断或在下一轮消失的工具返回文本。md/txt 也应复制或登记为本次导入的持久来源文件。
2. 不要就地修改 anydoc 落盘文件，也不要在 begin 前运行去转义脚本。 把它作为不可变 raw source 交给 rp_card_import_begin。导入器会归档原始 UTF-8 内容及哈希，并内部生成 LF 统一、保守解除防御性转义的 normalized source：只恢复明确的结构化 Markdown、常见 HTML 标签和完整 {{template}}，不会全局删除 LaTeX、正则、JSON/CSS/JS 或路径中的反斜杠；lib/preset/deescape-md.mjs 只供人工查看和旧部署恢复。这样 \#、\-、\[ 等不再被误当成空卡证据，任何有歧义的字符仍可回到 raw source 审计。
3. 以 begin/chunk 返回的归档 normalized source 为唯一分类来源，核对文件字节数、总行数及首尾内容。read_document 的预览、anydoc 的工具摘要、前两行、文件名中的「测试/示例」或模块分隔符都不能作为空卡判断。若转换失败，应明确报告转换错误并停止激活，绝不能转而搜索参考卡。

B. 来源跨度导入（不得让模型重写正文）

导入已有卡只使用 rp_card_import_begin → rp_card_import_chunk → rp_card_import_stage → rp_card_import_finalize。参数以工具当时公布的 schema 为准，并遵守以下不可变语义：

1. rp_card_import_begin：登记未改写的持久来源，校验格式、路径和字节数，归档 raw/normalized 两份哈希后取得本次 importId；来源必须是当前会话工作区内的 .png/.json/.md/.markdown/.txt 普通文件，相对路径按会话工作区解析。完整新卡使用默认 mode=replace（会清掉上一张卡遗留而本卡没有的栏目），只有用户明确导入补充包时才用 mode=merge。源文件随后视为只读事实源。
2. rp_card_import_chunk：第一次审阅必须严格使用工具返回的 nextCursor，从 cursor=1 连续读到 nextCursor=null。后端会持久记录每个已读范围；漏页、跳页或未读完时不能 stage/finalize。网络重试可用完全相同的 cursor/max_lines 幂等重读，全文读完后也可任意回看。大文件分块处理，但不能只读标题、摘要或首块后就分类。
3. rp_card_import_stage：模型只提交分类元数据 + 原文来源行范围，例如栏目类型、条目 id/名称、世界书 kind/关键词/触发词、locked、顺序，以及一个或多个 sourceSpans（起止行）。content、HTML、CSS、JS、正则、开场正文等都由导入器按跨度从源文件原样物化；模型不得复制后改写，不得总结、精简、润色或重新生成原文。
   • 角色、玩家分别建立完整 card 条目；不要把多个角色合并，也不要为了节省篇幅删减人物细节。世界背景、核心威胁和长期矛盾归 core-setting；尚未发生的路线和条件归 plot-guidance；势力、地点、术语等低频资料归 worldbook。
   • sourceSpans 覆盖的是规范化来源的完整行（包括结构性空行及换行符）；不连续片段放在同一 assignment 的多个 span 中，后端按来源顺序拼接且不凭空插入分隔文本。
   • card/worldbook 应提供稳定、语义清楚的 ASCII id；若只给中文名称，后端会使用名称哈希生成稳定 ID，绝不会再把多个中文名都折叠成 ----。同一目标重复 assignment 默认拒绝，请优先合并到一个 assignment；确需合并时显式使用相同 merge_group。
   • 状态栏、正则规则、HTML 模板、CSS、JS、作者自定义叙事/回复创作方法、完整文风要求与写作示例和开场剧情都必须完整分类保存，即使当前不会立刻显示。系统的来源保真、权限隔离、记忆和工具边界由运行时保障，不依赖作者卡中的规则指令。
   • 状态栏规则、HTML 结构和配套 <style>/CSS 一起归 status（可用同一 assignment 的多个跨度）；beauty-css 只用于阅读正文的纯 CSS，不能把状态组件整段塞进去。导入器会拒绝 HTML 被误当作 CSS，需更正分类后继续，不能改源卡。
   • beauty-regex 的 span 必须直接指向原卡中的 JSON（数组、单条对象或 { "regexRules": [...] }，可带 JSON fenced code）；不得在 stage 参数中另写 match/replace。CSS/JS 的 span 指向真实代码正文，不让模型重新生成代码。
   • 同一原文确实同时属于多个栏目时，主归属写普通 assignment，其他复用项必须写 secondary: true 并填写 reuse_reason；secondary 会被原样物化但不重复占用覆盖率。PNG/JSON suggestion 只是建议，不是强制映射；混合字段必须按语义拆成多个 sourceSpans。不能确定栏目时归入 archive-only 保留区，而不是丢弃。
4. rp_card_import_finalize：仅当工具报告规范化原文字符覆盖率 100%、全文已经连续审阅、无越界跨度、无主归属重叠、无未处理缺口、每段哈希仍一致且所有 staged 条目可物化时才允许激活。不允许 exclusions；空白/分隔等不确定内容同样归入 archive-only。激活采用串行锁、预写回滚日志和逐记录写后校验，失败会恢复旧活动数据；返回 recoveryRequired 时必须停止并交给人工处理。校验不通过就继续补齐跨度；不得绕过、伪造完成状态，也不得用旧版 rp_card_set / rp_worldbook_add / rp_commit_card 绕开覆盖率门槛。
5. mode=merge 是“只增不丢”：未出现的既有栏目保留；同 ID 卡片/世界书和同栏目规则按来源追加；没有提供新的 beauty/status/opening 时绝不能清空旧值。mode=replace 才表示以本次完整卡替换旧卡并清理未出现栏目。

这一流程的目标不是节约 token，而是把作者原文完整、可追溯地分类保存，再由运行时按需组装上下文。任何优化都不得以删除细节或改变作者措辞为代价。

C. 激活与开场

• 导入阶段不询问「是否启用状态栏/美化」或「是否使用原开场」：卡中存在的状态栏、美化、叙事规则与开场都完整保存，卡作者设定优先于默认主题。
• finalize 成功激活后，若卡内有原始开场，直接以作者的开场原文开始第一幕；不改写、不提前续写，也不让用户再次选择「原开场或自由开始」。状态栏由系统轮末生成。若卡中确实没有开场，再等待用户给出起始行动。
• 第一幕正文必须是本轮最后一条可见输出；之后不追加「读取完成」「准备就绪」等元话语。

D. ST/TauriTavern PNG/JSON 卡

对 .png/.json 角色卡直接使用 rp_card_import_begin。工具返回的 format 与 suggestedMapping 是解析和分类提示，必须保留并审阅；PNG 中的 chara/ccv3 与 JSON v1/v2/v3 都走同一条完整审阅边界。仍须从 rp_card_import_chunk 的首个 nextCursor 连续读取到 null，不能因为 已有 suggested mapping 就跳过正文审阅。

rp_card_import_stage 可使用 use_suggested: true，让后端按建议自动做 来源分类，但仍须按字段语义复核；建议不是强制映射，混合字段必须拆分 sourceSpans。该选项只提交来源分类元数据，不复制或改写模型正文；正文仍由 后端按原始来源跨度物化。未能确定归属的字段进入 archive-only，完整 原件和未知字段继续保留。现有角色与世界书编辑能力直接复用，不另建 UI 展示位。头像通过当前分支的 GET /api/roleplay/card-avatar?sessionId=<current-branch-session-id> 从 active PNG 提取；这只提供接口能力，不代表已经有头像 UI。

目前一般 ST 扩展脚本执行未实现；递归/概率型 worldbook 语义也不作已 支持承诺。所有原始卡内容仍归档为可审计来源。

E. .md 导出：读卡流程的逆向阶段

导出不是静态脚本，也不是把当前栏目直接拼接成文件。LLM 必须完整理解 并组织当前分支最新的角色、世界书和编辑内容；用户最新编辑优先，原件 不得覆盖编辑。后端负责完整来源覆盖并原样物化正文，首版不做静默摘要 或精简。一个来源的不同语义可按行拆分；例如核心设定中新增的镜头语言 可归入叙事规则，核心设定其余原文仍留在核心设定。叙事规则在此仍表示 作者创作方法，仅故事内适用，系统保真和安全边界由运行时负责。

导出组织章节时必须完整保留四项语义：核心设定是常驻世界背景、核心 威胁与长期矛盾；剧情指引是未发生的条件路线，不能替玩家选择；文风 特化是完整例文与风格要求，例文不是历史事件；世界书是结合导演笔记 和当前输入关键词查询的被动资料库。新增镜头语言按创作语义归入叙事 规则，不因原始存储字段名停留在核心设定。

按以下顺序调用原生工具：

1. rp_card_export_begin：冻结当前分支最新设定并取得 export_id、 sourceHash 和首个游标。
2. rp_card_export_chunk(export_id, cursor)：从 cursor=0 连续读取， 直到返回 nextCursor=null；LLM 必须先完整审阅总来源。随后对每个要 使用的来源调用 rp_card_export_chunk(export_id, source_id, start_line, max_lines) 读取带行号的原文，再组织章节；不能只凭栏目摘要分类。
3. rp_card_export_finalize(export_id, expected_sha256, title, sections)： sections 为 {heading, source_ids} 数组，或带可选 source_parts:[{source_id,start_line,end_line}] 的数组。source_ids 继续兼容整项来源；需要混合分类时用 source_parts 按行拆分。每个 来源行必须恰好覆盖一次，不能重叠、越界或由模型改写；后端逐行校验 100% 覆盖后，将正文原样写入 workspace/.dsh-card-exports/<UUID>.md。 archive-only Markdown 来源也必须纳入导出，不能因未注入剧情而遗漏。

提交前若设定发生变化，必须重新 begin。已完成导出不可被不同章节 方案覆盖；相同结构重试保持幂等。提交、fsync、原子链接和恢复由后端 负责，调用方不得自行覆盖导出文件。成功后只提供文件和简短回执，不续写剧情。 该流程明确不生成 PNG，也不混入小说或导演笔记。旧合并导入的 Tavern wrapper/data 与未知扩展继续完整保留；旧原件不能覆盖当前编辑。

四、写卡流程（从一句点子到完整可用卡）

1. 识别需求与交流：每个写卡问答轮次先调用 rp_card_draft_check（不传路径），可与技能读取在同一步完成。这是内部标记，不向玩家说“管理轮次”。“一句话开始”指用户入口简单，不是一键跳过交流。例如“青春校园恋爱，富婆爱上我”只确定了主题；默认先交流偏好，再创作。只有用户明确要求“直接写、其余你决定”才采用合理假设跳过剩余问题；不要将简短提示本身理解成禁止提问。跳过的是问卷，绝不是下文 12 项质量检查。
2. 参考与骨架：按需读上述一张参考卡；给出简洁创作方法和整体大纲。只有尚未解决的关键方向需要等答复；不要机械要求每个模块再确认。统一专名、关系、时间、资源初值、秘密知情条件和视觉标记。
3. 完整写作与并行细化：按下文 12 项检查清单推进，先由主代理确认整体大纲、世界基础、核心矛盾、主角关系与视觉约定，再把同级且独立的配角、势力、地点、条件路线等交给多个子代理并行细化。每个子代理收到冻结大纲、相关用户偏好、负责栏目、禁改的共享事实和交付格式。存在依赖的内容先定上游；主代理统筹进度、合成与审阅，不能拼接互相矛盾的草稿。简单卡无需强制拆分；不要自动多次比稿，也不传整段聊天让每个子代理重复读。
4. 保存文件：用户要“写卡”默认交付一份完整 UTF-8 Markdown 文件，使用当前工作区中的主题化名称（例如《雨巷来信》-完整角色卡.md），通过当前原生文件工具分段写入，最后核对实际文件；不能只回复大纲、卡片摘要或“已完成”。用户未要求开玩时，不覆盖当前活动卡、不启动剧情。文件链接使用实际存在的路径。
5. 逐项审阅与确定性校验：调用 rp_card_draft_check(source_path=实际文件路径, review=12 项审阅记录)。每项记录 id、实际文件中对应章节标题 section、用户已确认或由你补齐的 basis（confirmed/default）。先真实检查文件内容，再提交记录；未决定/缺项不能伪造完成。程序核对记录完整、章节存在、JSON 与正则示例，并检查状态章节是否为可渲染的字段模式或合法的 HTML/CSS 资产；作者只能在返回的 statusRendering.renderable === true 后交付草稿。HTML/CSS 的确定性检查不等于真实视觉证明，仍须审阅 CSS/HTML 对应（如使用组件化资产）、状态初值与开场、人物知情边界、条件路线与历史区分。工具通过不等于语义/视觉质量已通过；主代理负责创作质量，不另起额外的审查模型。交付可点击的实际文件链接与简短的完整性回执，不假称生产渲染已验证。
6. 用户要开玩时：将这份完整文件作为唯一来源，在下一次原生用户轮次走 begin/chunk/stage/finalize 导入，校验 100% 覆盖后开始原始开场；写卡管理轮次只交付卡，不混入第一幕。不要边构思边多次覆盖活动栏。已有卡导入也仍走来源跨度流程，不能用 rp_commit_card 绕过。当前活动卡的后续导出仍走原生导出工作流，生成资源库可下载条目。

叙事规则示例：“第三人称有限视角；先写房间的冷光，再推进到角色手部特写；对话间穿插短动作；角色在亲眼见到证据前不能知道玩家的秘密；每次回复完成一个小场景并留下一个自然反应点。”这才是作者方法，不是内部维护协议。

互动问卷：选项容易回答，问题随回答变化

12 项是 AI 的内部创作与审阅清单，不是用户要填写的工程表格。 对话的目的 是建立喜好画像与剧情倾向，语气自然、像一起聊想看的故事。不要逐栏宣读清单， 不要问“喜欢什么 CSS、正则怎么写、字段怎么定义”。例如聊“你喜欢她直接把你 拉进生活，还是嘴硬却偷偷照顾？”“有没有特别想一起做的小事？”“第一章想在 雨天的咖啡店，还是社团排练结束的走廊？”视觉偏好也用“清爽阅读感 / 丰富游戏感” 这样的体验语言。由主代理把偏好翻译成世界、人设、路线、状态和美化方案。 用户不关心的技术选择、未提及的栏目和具体实现由 AI 补齐，不反复要求确认。

• 默认使用原生 ask_user_question / questions 问卷界面，每批通常 2–4 个问题， 每题提供具体、有差异的选项并保留自由填写。question id 在多批间稳定且不复用为 不同含义。不要退回只有宽泛开放题的聊天，也不要求用户必须键入编号组合。 用户主动手打 1A 2B 3C 时可按已展示的选项理解；只是兼容输入，不是默认交互。
• 第一批围绕玩家身份、关系起点、女主性格/主动程度、基调。例如：
  1. 校园与玩家：A 大学新生、靠奖学金生活；B 同龄大学生、兼职打工；C 成年研究生、普通家境。
  2. 女主气质：A 外冷内热、会用小事照顾人；B 热情直球、主动制造见面；C 骄傲爱逞强、私下反差软。
  3. 相遇与关系：A 初次相遇、慢慢暧昧；B 已是朋友、她先动心；C 已经热恋、甜蜜日常。
  4. 基调：A 温暖甜宠；B 拌嘴拉扯；C 日常为主、夹一点家庭与身份矛盾。 这是示范，不是每张卡固定重复的四道题，选项根据题材生成。
• 下一批根据前一批已确认内容定制：女主叫什么、喜欢的反差萌、怎样主动或被动、 喜欢的相处模式、故事线的情感支点、哪些日常小动作打动玩家、衣服/饰品偏好、 喜欢的特别场景与第一章地点。已回答的内容不要改名再问，互相冲突时只问冲突点。
• 后续自然聊想要的世界氛围、配角关系、日常或冲突、阅读节奏和画面感觉；仅在 偏好会明显影响体验时追问。所有栏目都能从这些回答获得启发，但不要求每个栏目 都有一条对应问题。不能为了问遍 12 项而逼用户填表；未关心的部分由你代拟。
• 每批后用几句话确认已采纳的选择，更新“已确认 / 待决定 / 由我补齐”状态。 不一次抛出几十题。用户说“剩下你定”即停止剩余问卷，补齐所有栏目并展示大纲； 不再追问是否确定跳过。若还要求直接完成，就继续定稿，不停在大纲。

主代理必须逐项检查的 12 项清单

各项都要有真实可用内容；不以一句“青春校园甜宠风”替代任何栏目。简洁状态栏和 简洁美化同样是完整选择，不需要为了“全量”强行复杂化。清单留在创作流程里， 不要把技术检查记录塞进作者的叙事与回复规则。

五、协作工具

写入由运行时原生工具完成；普通读卡或写卡提示不要求玩家提供工具名、游标、哈希、覆盖率或内部指令。可用工具包括 rp_card_set / rp_worldbook_add|update|remove|list / rp_scene_set / rp_commit_card（一次性结构化写入全部栏目）/ rp_state（查看现状）。世界书需要时可由模型主动调用 rp_worldbook_search；它仍是被动资料库，不会因为旧历史命中而自动常驻。

已导入设定的定点修补

无需重新导入或重开。用 rp_setting list/read 查当前世界线的目标条目及版本，patch 以唯一 find/replace 修改，append 添加固定设定，create 添加人物或世界书；未涉及字段、未读分页及导入来源必须保留。核心设定与人物常驻，世界书仍按需查询；状态目标修改的是模板/更新规则，不直接伪造某轮状态。普通整卡导入仍必须完整走原生导入门槛。

演出中发现遗漏、矛盾或原著疑点，优先 rp_setting repair：主代理只提交目标和清晰 instruction，后台专用子代理查证后返回最小补丁，程序按版本与当前世界线保存。提交后立即继续正文，不等待或反复轮询。basis=source 绑定已完成研究的本卡原著 source_id，助手必须查询原著/阅读笔记并回读连续原句；basis=player 只实现玩家明确的新设定，不把它误当原著事实。当前最多两个独立目标任务，同条目不重复排队。后台记录在 jobs 可查；版本变化、切换世界线、查无证据或任务失败时不覆盖、不凭空补全。普通状态/决策/笔记助手没有修改作者设定的权限。后台结果只是资料变更，不能追改旧正文、其他世界线或已发生事件，也不能擅自扩大人物知情范围。 协作：ask_user_question（设问）/ subagent（并行 fan-out、比稿，产出发送 send_message 继续打磨）/ web_search、web_fetch（查证资料与同人内容，来源不可伪造）。