@my-life-buddies/buddy-creator-skill 1.6.0

package/references/methods.md

@@ -0,0 +1,98 @@
+# methods
+
+## 6. 03 方法：通过具体场景了解怎样判断
+
+方法访谈按“提炼候选 → 用案例校准 → 检查是否充分”循环推进。方法、基础案例和举一反三案例都不设固定总数：简单任务少问，复杂任务按真实缺口增加，不能为了凑数继续问。决策优先级、信息取舍、调整机制与边界判断作为覆盖维度，融入实际场景。
+
+进入方法阶段时告诉创作者：“我们先从你的具体做法聊起，复杂的地方再补案例；你觉得够了，随时说‘先到这里’，我会整理已有内容并标出待补。”这不是每轮重复征求继续许可。动态目标和收口记录见 [方法访谈协议](methods-protocol.md)。
+
+### 6.1 方法候选
+
+从已确认的 01/02 按当前任务提出不重复、有来源的判断假设，尽量写成“当……时，优先……；除非……”。一次展示一个，创作者可认可、改写或拒绝。
+
+| 创作者反馈 | 下一动作 | 能否收敛当前候选 |
+| --- | --- | --- |
+| “符合我的做法”且对象明确 | 保存对该规则的认可及原话 | 可以 |
+| 提供前提、例外或明确替代做法 | 按原意修订；新内容若只是忠实整理，不再重复索要应用许可 | 可以；模型额外推导仍需校准 |
+| “这完全不是我的方法”，未给替代 | 标记拒绝，保留原话 | 可以，转下一候选 |
+| “不太对”，未说明哪里 | 只问差异：“这条判断里，哪一点和你的做法不一样？” | 不可以，缺少可执行修正 |
+| “为什么这么理解” | 解释所依据的来源及假设性质 | 不认可、不拒绝，保留当前位置 |
+| “不知道”“先放着” | 保留未决，可看其他候选 | 不能算 accepted |
+
+本案例所依据的方法获认可后，就可以用场景验证，不必等其他独立候选全部处理。后续案例揭示新方法时可继续登记、逐条校准。全部被拒时，从创作者的一次真实处理经历重新提炼；如果仍没有做法，不制造 accepted 规则来推进。
+
+### 6.2 按需选择基础场景
+
+场景只描述“谁、发生了什么、提出什么需求”，先不提供 AI 处理答案。人物服从 01 的目标用户。AI 构造的情境须标明是校准情境，不能写成创作者真实发生过的案例。
+
+尽量让同一个用户的经历连续下去，用刚才的实际回答引出受阻或边界情况，不每问都另编一个人和一套背景。专家讲真实案例时直接问实际处理，如“你当时怎么回她的？”；只有取舍含义确实需要核对时才先说明理解。场景具体后不再叠加辅助例子。需要改动条件时明确说明是假设及改了哪一点；按最能验证当前缺口的顺序推进，不在基础场景首问里给专家预选做法。“责任边缘”等名称供内部覆盖判断，不逐题念给专家。
+
+| 可选观察角度 | 要了解的判断 | 什么回答已够用 | 还缺关键内容时怎样问 |
+| --- | --- | --- | --- |
+| 初次求助 | 面对信息不完整的求助，先判断什么再行动 | 从当前回答与已确认材料可提取关键判断、下一步及理由 | 真实经历问“你当时怎么回她的？”，假设场景问“你先怎么回她？”；仅缺输入时补“给建议之前，你还得先弄清哪件事？” |
+| 行动受阻 | 理想方案做不到时，保留什么、调整什么 | 能明确本情境里的取舍或调整，以及依据 | 带入当前实际限制后问“你会把这套做法简化成什么样？” |
+| 责任边缘 | 仍可帮助到哪里，什么条件下要停止 | 是否继续、可处理的范围或停止条件、判断依据 | 带入具体求助后问“她追着问你该怎么办，你会怎么回她？”；已有回答则只补尚缺的范围或停止条件 |
+| 明确越界 | 明确不在职责内的要求怎样处理 | 明确不继续承担什么，并能说明与既有边界的关系 | 说明具体越界要求后问“你会怎么跟她说？”；不让专家复述抽象责任定义 |
+
+“关键判断、动作与理由”可以来自已经确认的规则，不要求创作者每题都重复。若回答只是“看情况”“因人而异”，尚不能确定实际做法；只追其中真正影响下一步的一点。这里不要求设计收费、周期交付或完整转交流程。
+
+创作者对具体场景给出的充分、明确处理意见可作为其场景答案保存，保留原话。模型整理加入了原话没有的条件或推论时，新增部分必须另行校准。仅输入非空文字、说“为什么”或“我不知道”，不能自动把场景标为 confirmed。
+
+上表是观察角度，不是四道必问题。一个案例可以覆盖多个维度；已确认材料足够就复用。场景不适用时换一个符合真实任务的场景；维度本身不适用则记录具体理由和依据，不强造故事。新增 M/E 编号须说明与已有案例不同的关键缺口，不能给同一问题换编号规避次数限制。
+
+### 6.3 按需举一反三
+
+对应基础场景有效确认后，按尚未验证的迁移能力构造拓展：例如现实约束变化、原则冲突、边界或风险变化。不限于三个，也不要求每类各一道；每个只改变一个关键条件，其他背景保持一致。已有确认已覆盖迁移判断时，不再重复出题。
+
+这时展示一份根据已确认规则推导的“可能处理方式”，让创作者能判断具体执行是否合理，不能只列原则或写“从可控制的操作中选一项”。先读取对应基础案例及已确认依据的正文；已有的具体做法要保留下来，不把它们概括掉后再让创作者重新提供。
+
+处理方式通常写成 2—4 个短步骤，按本场景需要覆盖：
+
+- **第一步怎么开始**：谁在什么时点，使用什么已有信息，对哪个对象做什么。确实缺关键输入时说清要取得哪一项，不笼统写“了解情况”。
+- **具体怎么执行**：给一个当前约束下能实施的操作，交代顺序或示范一句实际说法。例如“把这周的一项真实进展写成‘做了什么／结果是什么’两行”，而不是“优化表达”。
+- **做不到时怎么调整**：按已知限制提出替代动作或停止条件，不假设原本不具备的资源突然可用。条件分支用“如果”表达，不把假设写成新发生的事实。
+- **怎样知道是否落实**：观察实际行动或产物，如是否完成一顿尝试、是否留下两行记录；后续调整依据是什么。执行完成不能偷换成健康、收入或其他效果已经改善，也不能凭空增加提醒、自动追踪或定期服务承诺。
+
+这是写作时的检查项，不是要求创作者回答四道题。已有依据够用就直接整理；简单案例可以少于四步，不能为凑完整结构编造用量、频次、渠道、能力或结果。构造拓展情境仍只改变一个关键条件；不得为了让方案好做而同时换商家、作息或设备。
+
+正文先用日常说法说明这是根据已有方法推出来的建议，再展示具体动作，最后只问一个确认问题。通常用 180—320 字把场景和做法讲清，简单案例可更短，必要时可展开；这是写作参考，不是字数门槛。宿主使用 `delivery.mode: booklet`，并以 `confirmationObjectIds` 绑定当前场景；不把多项执行步骤写成多个采访问题。场景 markdown 保存同一份具体做法，之后的方法手册也保留关键操作，而不是只在对话里举例、入册时又缩回原则。
+
+**同一约束下的表达示例**
+
+假设创作者在基础案例中已经提出“浓汤、酱料不拌饭”和“夹菜时先沥去表面的油汁”，拓展时仅新增“办公室不能存放自备食物”。可展示：
+
+> 办公室不能存放食物，其他外卖限制保持不变。我会先取消自备食物这一步，沿用你已经提过的操作：
+>
+> 1. 下一餐先试“浓汤、酱料不拌饭”，从一个明确动作开始。
+> 2. 如果餐品已经拌好，就改试“夹菜时先沥去表面的油汁”，不要求商家配合改单。
+> 3. 这餐后让用户说清“做到了”或“卡在哪一步”，再决定保留哪个动作、怎样调整。
+>
+> 我按你前面说的做法，试着排了这个安排。你看，这样处理合不合适？
+
+这个示例说明怎样保留已有具体动作，不是通用饮食方案或效果结论；其他项目应使用它自己的真实依据。模型新增的执行顺序、分支和观察方式仍需创作者校准，不能写成已经确认的经验。
+
+- 明确认可对应处理方式：确认这一场景。
+- 提供明确修改：更新对应条件或动作；不顺势重写其他方法。
+- 仅否定、提问、不确定：解释或追问一个缺口，不算确认。
+- 与既有规则冲突：引用相关两处表达，问清是否存在适用条件或例外；不能自行决定哪条作废。
+
+同一缺口最多三次回答；同一案例累计四次后整理，仅关键缺口且最新回答有实质新增才延长到最多六次。换条件、换措辞和切换案例后回来都不重置该目标计数；连续两次没有新增提前停止。达到任一边界后保留具体待补，可以处理其他独立场景，不要求逐个补齐无关的执行细节。不能把次数耗尽等同于充分，也不能持续新增相似案例来无限延长。
+
+
+### 6.4 何时停止
+
+每校准一个方法或案例，就检查已有材料是否足以支持当前搭子的实际任务：
+
+- 判断：关键输入、优先级、条件与例外能否指导取舍。
+- 行动：能否说清下一步、顺序、理由和可观察的反馈。
+- 调整：重要限制变化、执行受阻或原则冲突时，能否合理迁移。
+- 边界：适用范围、停止条件和无法处理的情况是否明确。
+
+这些是 Agent 的检查角度，不是追加给用户的四道题。每个判断引用已确认内容；不适用的角度说明理由。缺口会改变实际做法才值得追加案例，只有措辞、装饰细节或重复证明就收口。复杂任务可覆盖多条方法和多个任务分支；不要先固定一长串题目再要求逐个答完。
+
+两种结束方式必须区分：
+
+1. **Agent 判断充分**：简要说明已覆盖哪些关键判断，以及为什么继续问的新增价值已很低；登记 sufficient，直接整理五章并展示待确认版本。仍有待校准目标、冲突或关键缺口就不能写充分。
+2. **创作者主动结束**：“先到这里”“够了，整理吧”等明确结束意愿立即生效。不追加“最后一个案例”，不要求解释理由。登记 user_stopped，保留全部未验证目标和缺口，生成有范围说明的五章供确认。叫停不等于认可未展示内容，也不自动确认整册。仅采用已确认内容，不把待补当作搭子已经具备的能力。
+
+用户只想暂停整项创作时沿用 paused；只跳过某个问题不等于结束整个方法阶段。含糊的“差不多”按上下文判断，不能无证据推断叫停。已收口后，只有用户主动提出续谈才恢复；保留历史问题、证据和次数。后续开发严格遵守本版范围，不能把未验证的推导实现为已获认可的方法。

package/references/opening.md

@@ -0,0 +1,14 @@
+你可以把「搭子」想成一个学会了你那些经验和办法的 AI 伙伴。别人来问事情时，它也能用你的思路帮一把。比如帮新人写周报、陪人练面试，或者一起照顾阳台上的花。
+
+我们会边聊边把它做清楚，分四步：
+
+1. **定义**：先聊你想帮谁，帮他们解决什么事。
+2. **知识**：把你平时用的经验、资料找出来，没写成文件的也可以直接讲。
+3. **方法**：拿几个具体情况聊聊，看你会怎么判断、怎么处理。
+4. **服务**：商量别人怎么开始体验，之后能一直得到哪些帮助。
+
+聊完，会留下四本手册和一张服务模式图，后面开发搭子时就有据可依。你熟悉的那些做法，也就能慢慢变成别人遇到事情时用得上的帮助。
+
+整理的内容会放在旁边的预览里，哪里写得不对，随时告诉我。
+
+你现在最想做个什么搭子？

package/references/preview-panel.md

@@ -0,0 +1,66 @@
+# Booklet 面板检查与一次性重开提示
+
+Booklet 面板让开发者边聊边查看已经整理的内容和当前进度。开发者可能误关，也可能选择只用对话；关闭面板不等于暂停创作。提醒只提供便利，不是继续采访或确认手册的前置条件。
+
+## 1. 何时检查，怎样判断
+
+首次创作沿用 SKILL.md 的打开流程。接续同一作品、进入下一册、准备展示手册或收到界面相关反馈时，优先使用宿主实际可用的面板/浏览器标签页查询能力，检查这个 workspace 的 `preview.url`。不逐轮反复查询，不启动后台轮询或定时提醒。
+
+- **open**：找到对应 URL 的已打开面板或标签页。后台标签页、暂未聚焦或最小化仍算打开，不因用户在聊天就提醒。
+- **closed**：宿主对相关面板/浏览器提供的完整清单中确认没有该作品界面，或开发者明确说自己关闭了它。匹配完整项目入口，允许同入口的 hash 路由；不能把其他作品的 Booklet 当成本作品。
+- **unknown**：宿主不能查询界面，或只能看到前台窗口、部分标签页、查询失败。保持未知，不说“你关闭了面板”，也不据此主动询问重开。
+
+预览 URL 存在、HTTP 请求成功、预览进程运行、曾调用打开工具都不能证明界面现在开着；事件连接断开也不能证明关闭。查询能力必须来自实际宿主工具，不猜测 API，不为检查而打开、切换或刷新面板。
+
+## 2. 提醒只发生一次
+
+面板状态与提醒结果保存在当前 workspace 的 `preview-panel.json`，通过下述命令读写，不修改 `state.json`，不增加采访回答次数、作品 revision 或确认记录。每个作品最多一次主动询问；换宿主、恢复项目、切换阶段或再次关页都不重置。不同作品各自记录。
+
+使用实际 Python 和技能目录，JSON 通过文件或安全标准输入传入：
+
+```text
+<Python路径> <技能目录>/scripts/buddy.py preview-panel --workspace <已保存目录> --input <JSON文件>
+```
+
+| JSON 请求 | 用途 |
+| --- | --- |
+| `{"action":"status"}` | 读取提醒状态；默认 unknown / not_offered，读取本身不创建记录 |
+| `{"action":"observe","visibility":"open","source":"host_inventory"}` | 保存实际宿主查询结果；visibility 可为 open、closed 或 unknown |
+| `{"action":"observe","visibility":"closed","source":"user_report"}` | 开发者明确说关闭了界面 |
+| `{"action":"observe","visibility":"unknown","source":"unavailable"}` | 无可用查询能力，不做关闭推断 |
+| `{"action":"offer"}` | 刚确认关闭后，持久登记本次提醒资格；仅返回 shouldAsk=true 时可提出一次问题 |
+| `{"action":"respond","response":"declined"}` | 开发者明确拒绝；accepted 表示明确要求打开，ignored 表示后续输入没有回应面板问题 |
+
+`offer` 只接受两分钟内记录的关闭观察。过期时不沿用旧状态询问，需重新实际检查。工具不自行检测浏览器；host_inventory / user_report 必须有真实依据。`canOffer` 是候选状态，不等于可以直接发问，最终以 `offer.shouldAsk` 为准。
+
+`offer` 在返回前把 reminder 保存为 offered。相同请求重试、回执丢失或下一轮还没处理回复时都不会再给询问资格。不能删记录、改成 not_offered 或重新记录 closed 来恢复资格。记录损坏时保留现场，不主动询问，也不重建为空白；仍可响应开发者主动要求打开界面。
+
+## 3. 怎样询问而不打断采访
+
+仅在已确认 closed、reminder 尚未用过且 `offer.shouldAsk=true` 时，提出下面这类简短提示，把作用和以后主动打开的说法一次讲清：
+
+> Booklet 面板现在没有打开。需要我重新打开，方便你边聊边查看已整理的内容和进度吗？不需要也可以继续聊。之后想打开时，直接说“请帮我重新打开 Booklet 面板”就行。
+
+优先通过宿主独立的非阻塞界面询问入口发出。它是界面操作问题，不是采访目标；不新增 targetId/gapId，不把面板答复写进知识或方法。不在 `delivery.text` 后拼接第二个未保存的采访问题，不把界面操作当作手册确认。
+
+没有独立询问入口时，在自然停顿处单独给出这条界面提示，保留原采访待答内容；这一条不再附新采访问题。开发者继续回答原问题时立即接着创作，不要求先答面板问题，也不重发原问题。这是仅针对界面维护的旁路，不改变正常 turn_begin / turn_finish 的采访闭环。
+
+| 后续输入 | 行为 |
+| --- | --- |
+| 明确同意重开，或直接说“请帮我重新打开 Booklet 面板” | 记录 accepted，按下一节实际打开；无需再次确认 |
+| 明确拒绝、不需要、别再提醒 | 记录 declined，继续原创作，不再询问或重复提示口令 |
+| 回答原采访问题、谈其他内容或没有回应 | 不打开、不追问。下一条无关输入到来时记录 ignored；尚无新输入时保留 offered，同样不会再次提醒 |
+| “可以”“继续”等同时可能回答采访问题或确认正文的含糊回复 | 不推断同意重开，不追加澄清面板问题；按原采访语境处理，面板提醒保持已使用 |
+
+纯面板请求或答复走本旁路，不创建采访回合；同一消息也含真实采访答案或修订时，完整原话仍按正常协议保存，只将其中实际采访意图用于目标、次数和确认。保留原问题与版本绑定，不能用“好，打开吧”确认手册。用过一次提醒后，包括同意重开又再次关闭，也不主动再问；开发者后续明确要求打开始终有效。
+
+不等待固定时长判定“默认同意”，不追问“看到提示了吗”，不反复说“你随时可以打开”。主动打开的口令已包含在第一次提示中；开发者主动问起界面时可再说明。
+
+## 4. 实际重新打开
+
+1. 沿用当前 workspace 与真实预览入口，先查看面板是否已打开。已打开则按开发者明确请求定位/聚焦它，不创建重复标签页；无法查询时不声称已关闭，仍可按明确请求调用打开工具。
+2. 预览服务需要恢复时执行 `open --workspace <原目录> --no-browser`，复用当前身份；遵循 recovery.md，不换 creation-key、不新建作品、不重置进度。该调用只恢复服务，不代表已经打开界面。
+3. 用宿主实际提供的工具打开或定位 `preview.url`，优先原侧边面板。根据真实回执/查询记录 open；仅排队、失败或不能验证时保留 unknown，如实说明结果并提供可用入口，不声称成功。
+4. 继续原采访或调用方流程。打开面板不重问开场、不重放旧确认、不把旧 delivery 当作新的用户答案。面板状态和历史提醒独立，不因打开成功重新获得提醒资格。
+
+无法打开或端口冲突时说明实际原因，保留内容和原问题。没有面板仍可通过主对话或实际可读文件展示待校准内容；不能因为缺少面板跳过正式展示与确认。

package/references/recovery.md

@@ -0,0 +1,46 @@
+# 中断与恢复
+
+升级后若返回 PREVIEW_UPGRADE_REQUIRED，旧版预览服务还占用原地址。宿主应核对返回错误所指作品的 preview-server.json、健康端点身份及实际进程后，仅重启这个作品专用的旧服务，再 open 原工作区。不能杀死未知进程、改固定地址或重置面板提醒；重启服务不表示自动重新打开开发者已关闭的面板。
+
+此文件说明 Buddy Creator Skill 1.6.0 的 Python 项目恢复范围；不使用旧版 sessionId、workToken、LangGraph 检查点或 Node 启动器。
+
+| 情况 | 处理方式 |
+| --- | --- |
+| 同一条输入的提交响应丢失 | 用原 clientKey 和原 raw 重试 turn_begin；同一身份不能换原话 |
+| 已保存输入，宿主撰写中断 | 用 turn_continue 读取已有工作和 context，继续同一 turnId，不重新输入旧答案 |
+| turn_finish 返回具体校验错误 | 修正本轮 patch 或 delivery 后重新提交；保留原输入与已保存来源，不创造确认 |
+| 不清楚 finish 是否成功 | 先 turn_continue 或 status 查看实际回执；已成功回合不能换正文重放 |
+| 用户明确暂停 | 保存 paused；停止提问，已保存内容可在下一次 open 恢复 |
+| 纯答疑 | 保存用户问题和解释，保留原待答对象；解释不算采访回答，不借机推进 |
+| 用户修订已有内容 | 只改受影响对象；保留旧版本和原话，原确认及依赖受影响时重新校准 |
+| 资料只取得片段 | 保存 partial 和真实缺口，不把来源标为完整可用；补齐后用新 operationId 导入 |
+| 用户换宿主继续 | 使用同一个 workspace；先 open，再读取保存的 delivery、原话和目标。保留 gapId、缺口次数、无新增记录及目标总次数，不重置 |
+| 已收口后主动补充 | 用有本轮原话依据的 interview.resolutions 解决具体缺口并修订；只有明确针对该目标的续谈要求才用 interview.reopen |
+| 所有独立目标均无法推进 | 保存具体缺口及恢复条件，使用 delivery.blocked；不能假装用户暂停或重新盘问耗尽的细节 |
+| 四册已确认、小挂件尚未完成 | 读取 context.widgetDesign.phase，继续当前清单、原型或设计验收，不重开四册 |
+| 全部设计已确认但成果文件生成失败 | 保留确认，处理具体错误后 finalize；原型资源问题先 widget_render 恢复 |
+| 重启时所有必需设计及成果均已完成 | open/status 返回 creator_complete；结束 Skill，按调用方说明继续下一阶段，不重问采访 |
+| 已完成手册缺失、被修改或不对应当前确认版本 | 返回 finalize_required；先恢复真实成果，不直接交给下一阶段 |
+| 手册交付后开始技术讨论 | 退出 Skill，按调用方流程处理；不登记成 Creator 的 explanation 或采访回合 |
+
+重试只恢复实际保存的操作；本地程序无法恢复宿主从未发送的消息、从未提交的标注意见或外部工具内部进度。不要声称仍有未实际启动的后台任务。
+
+## 预览连接
+
+界面关闭与服务断开分别处理。接续时先按 [面板检查与重开](preview-panel.md) 查询本作品界面；确认关闭后最多主动询问一次，未回应或拒绝都不再追问，也不自动拉起。提醒保存在独立的 preview-panel.json，恢复、换宿主和服务重启不重置。用户明确说“请帮我重新打开 Booklet 面板”时直接恢复原入口；状态未知不猜测关闭。
+
+同一项目保存固定的本机预览入口。再次 open 优先复用原入口并启动缺失的预览进程，不能为了恢复随意删掉端口与身份记录。页面只监听本机 127.0.0.1，内容与事件接口只读。页面已加载时可重试读取更新；预览进程退出时，需要宿主重新 open 启动后刷新原地址，浏览器本身不能重启程序。
+
+若固定端口被其他进程占用，说明真实冲突，不停止身份未知的程序，也不承诺旧 URL 会自动跳到新端口。具体错误依据返回值处理。预览只负责显示已保存进度和公开草稿，不能修改内容或代替用户确认。本轮登记为 working 后 120 秒没有新的实际更新，页面显示“本轮还未完成”，避免无限播放像是在持续思考的动画；这不代表原输入丢失。
+
+## 工作目录与历史
+
+新项目不继承其他作品，但可以通过 `open --context` 接收显式背景；背景不会变成采访回答或确认。已有项目补入背景不清空原话、产物和确认；已经开始的采访按原进度继续。仅展示过通用开场、尚无回答时可按宿主协议保存相关的新开场，旧展示记录仍保留。此前 Python 无 Node 试用版项目可通过 `open --workspace` 原路径接续，保留预览端口与身份。原 Python 预览进程仍可用时可复用，不需要为升级搬动项目。新建默认使用当前创作目录下的 buddies/；同一 creation-key 已在原 buddies-no-node/ 匹配到项目时复用该目录，不重复创建。
+
+本版本不自动迁移旧 Node 0.x 工作目录或其 SQLite/LangGraph 检查点；需要参考旧作品时只导入创作者选择的资料，不改写原项目。所有新内容由 Python 工具写入本项目的 state.json 与归档、历史、成果目录。宿主不能直接修改 state.json 绕过版本、证据或确认校验。
+
+本版本没有旧版 interviewCycleId 重置接口。用户大幅改变定位、人群或核心任务时，先保留原话、评估受影响内容；若需要重做整个访谈，基于用户明确改向另开独立项目，保留原项目，不以重建项目规避暂停、责任边界或确认。
+
+1.0.0 与 Python 试用项目仍可读取；只 open 不改写状态。首次新提交以历史真实回答初始化缺口记录，原有关闭状态和确认继续保留。仍在等待回答的旧问题不需要重新问，按当前 host-guide 提交 assessment。
+
+完整操作字段见 [宿主调用协议](host-guide.md)。

package/references/service.md

@@ -0,0 +1,76 @@
+# service
+
+服务册确认后进入 [小挂件交互设计](widgets.md)，复用 S07 的展示方式选择和自定义组件说明，继续清单、原型和设计验收。服务册确认不等于新项目创作结束。
+
+## 7. 04 服务：两种模式，两种对话节奏
+
+进入服务设计时先简短解释平台固定模式，并承接疑问。此时答疑不计作服务访谈回答，不提前采访价格或承诺。创作者理解后选择智能规划或逐项讨论；已有选择在续作时保留。
+
+### 三个阶段的含义与生成底线
+
+- **获客期：先免费体验。** 让新用户实际感受搭子的帮助。体验多久、包含什么以及何时结束，由创作者定义；可包含 7 天每天跟进、答疑、记住进度和修改方案。不限定一次结果，不把持续跟进判为违规。具体工具、主动触达与真人服务仍按创作者约定和真实能力说明，成本建议不是平台禁令。
+- **付费期：订阅后持续使用。** 已购服务期间与 AI 搭子的对话不限次数，不设每日／每月消息配额，不用“合理使用”或结果、工具额度变相限制普通对话。真人咨询可单独约定次数、时长与响应安排；不把真人额度写成搭子额度。
+- **维持期：暂不订阅，也能基础聊天。** 免费体验结束未订阅，或已购服务到期未续费时，保留历史和最基础的双向对话，如日常交流、普通问题答疑和已有结果解释。不能只留静态历史、关闭聊天或每次只提示付费。不自动包含付费交付和真人服务，已购期未结束仍继续履约。
+
+这三条同时适用于智能和逐项模式。蓝图的 conversationLimit 固定为 unlimited，humanConversationLimit 单独说明真人服务，maintenanceContract.basicConversation 为 true，allowedQuestions 写明可回答的基础问题。免费范围校验使用 freeScopeAgreed，excludedSteps 可为空，不强制制造排除项。规则更新不改写历史原话或认可；旧草案中的错误限制应按已有意见修订并重新展示，不能继续用旧平台规则拒绝用户。
+
+### 7.0 订阅时长由创作者定义
+
+采用单档订阅制，不限定按月。创作者可选择 14 天、8 周、3 个月、1 年等明确时长；用正整数与天／周／月／年记录，不把一个月折算成固定 30 天。没有时长信息时保留待定并只问这一项，不能从“每周一次交付”推断成按周订阅。智能模式可以提出有依据的周期建议，须标为建议、展示并待确认。
+
+订阅周期、交付频率、价格和额度分别记录。例如“订阅 8 周，整个周期 199 元，每周交付一次，共 8 次”；还要明确工具、真人对话及本人复核的额度按哪段时间计算；付费期 AI 对话不限次数。已有信息不重复问。到期、续费、停付边界及恢复订阅都按已购的实际周期描述，不能固定说月底或下个月；到期前继续兑现已购服务。
+
+仅仅把周期改长不代表可以等比例涨价、加交付或扩大额度。修改周期时核对受影响约定，依据实际表达更新蓝图、动线与手册，再展示对应版本确认。旧版默认“monthly”不等于创作者已选按月；有明确原话或对应版本确认的月度方案继续保留，历史产物不因规则更新被静默改写。
+
+### 7.1 智能规划：先给完整建议，再围绕意见修订
+
+基于 01 定义、03 方法、02 知识的优先级，生成可讨论的完整服务草案，已有确认内容原样保留。价格、交付、工具及真人额度可提出具体建议并标明建议性质，AI 对话固定不限次数；不得虚构创作者产能、外部能力或用户效果。
+
+第一次展示后，可以说：“这版先让用户按约定免费体验，再通过订阅持续使用；付费期和搭子聊天不限次数，暂不订阅也能基础聊天。你最想先看哪一部分？”开场是在选择讨论入口，不要求逐个重填已有字段。
+
+| 用户输入 | 采访动作 | 收敛方式 |
+| --- | --- | --- |
+| “为什么建议每周一次” | 只解释当前方案和依据 | 回答后停下，保持蓝图，不追加新采访问题 |
+| “免费部分不太对” | 只问一个能确定修改方向的问题 | 得到具体替代后修改，不重问全套免费内容 |
+| “免费只帮他改一篇周报” | 明确修订相关范围，检查上下游一致性 | 成功保存后说明修改，标出需要重新确认的内容 |
+| “这个免费设计可以” | 在目标摘要与原话中记录对免费部分的局部认可 | 不改变蓝图的正式确认状态，不当作整套蓝图确认 |
+| “整套蓝图按现在这版确认” | 校验完整性、版本和确认范围 | 通过后正式确认蓝图，生成服务手册 |
+| “免费体验也要每天跟进、答疑和修改方案” | 采用明确要求，已有时长则直接整理；只有不明确时才问体验结束条件 | 更新免费内容、结束条件及相关动线，不按一次结果规则拒绝 |
+
+智能模式只有遇到具体未决问题才追问，不能因为内部有字段就自动逐字段采访。创作者没有主动选修改点时，也不要求其逐项批准所有建议；清楚展示整套草案后，可以明确确认整套，但真实产能或能力依据的缺口仍不能由模型补造。
+
+智能模式中的普通局部认可用于校准讨论，不等同于逐项模式的阶段确认。正式确认使用 [宿主协议](host-guide.md) 的 turn_finish.patch.confirmations，绑定先前实际展示的对象、版本和本轮原话，并满足对应门槛；口头回复“已认可”本身不能更新正式确认状态。
+
+### 7.2 逐项讨论：按服务决定推进
+
+下表是对话主题顺序；正式九类业务门槛仍沿用主方案。每一项先读已有原话和上游材料，已明确的内容直接整理展示，只问缺口。
+
+| 顺序 | 需要做出的决定 | 最低完整条件与何时收敛 | 典型追问 |
+| --- | --- | --- | --- |
+| S01 第一次免费体验 | 免费体验多久、得到什么帮助 | 来的情境、必要输入、处理步骤、体验结束条件、服务范围、之后值得继续的事明确；展示后确认 | 尚无范围时：“她刚来的这段免费体验，你愿意先帮她做到什么程度？” |
+| S02 订阅服务 | 用户为什么会反复回来 | 来的原因、输入、判断、行动、结果、反馈、下一轮更新相互连贯；展示后确认 | “体验完以后，她还想继续找你，你觉得接下来最能帮上她的是什么？”；已有回答只补实际缺口 |
+| S03 服务方式 | 主要是随时帮助、周期结果还是约定交付或工具次数；AI 对话始终不限次数 | 创作者明确选择；均是单档订阅，时长由创作者自定义，不产生新计费档位 | 只在用户不理解或尚未选择时解释和询问 |
+| S04 节奏、交付与价格 | 一次订阅多长、该周期内得到什么、多少、多少钱 | 订阅时长、对应正数价格、交付频率、数量、额度与工具范围明确，完成确认 | 只问当前缺的一项，如“一次订阅，你想定多长时间？”；周期已定则问“这四周一共收多少钱，你有想过吗？”，沿用实际周期 |
+| S05 停止付费后 | 历史之外还允许问什么 | 保证基础对话，明确可回答的普通问题；不能只留历史或付费提示 | “她要是哪次不续了，再回来问问题，你还愿意让搭子帮她聊哪些？”；基础对话始终保留 |
+| S06 续费依据 | 用户看见什么值得继续 | 1—3 项具体变化、成果或下周期目标 | “这一段快结束时，她能看到什么，会觉得接着用还有帮助？” |
+| S07 呈现与本人复核 | 纯对话或组件，是否创作者本人参与 | 有组件则描述展示、使用与更新；有复核则给真实产能 | 按缺口分别问；如已选择复核，只问约定时间范围内可复核多少关键结果 |
+| S08 四种用户经历 | 体验后订阅、不订阅、续费、不再续约 | 每种均覆盖何时发生、继续或停止什么、怎样告诉用户，并逐种确认 | 使用下一节的具体情境提问 |
+| S09 整体确认 | 三阶段、五动线、服务约定一致 | 全部门槛满足，创作者确认当前蓝图，整理九章手册 | 只回到实际未决内容，不重跑已确认主题 |
+
+S01 信息够用时直接出候选，不提前问价格或续费；S02 保留上轮未被推翻的有据内容，不从头重新问。各项存在多个缺口时，一次只问一个，不能将整行内容抛给用户填写。用户主动说清周期、价格、本人不咨询也不复核时，直接记录；到 S07 若只缺呈现方式，就问“你设想她平时怎么用——直接在对话里说，还是还需要别的东西配合？”，不再问是否真人参与。仅说“不做咨询”而复核尚不明确时，不能把两者混为一谈。
+
+缺少真实产能时，不能把“创作者复核”写成已承诺服务。创作者可以明确取消本人复核或稍后补充；运行时保留相应未决状态，不能替他作决定。
+
+### 7.3 四条动线的情境问法
+
+四组情境，每组覆盖三个决定——何时发生、接下来继续或停止什么、怎样自然地告诉用户。“恢复订阅”是平台默认能力，不生成第五组问题。三个决定是覆盖要求，不是必须重复问满三轮。
+
+先带入已确定的用户和服务，再问当前尚缺的一个决定。日常说法、短句即可；不规定开头、段落、问号数量或字数，也不先抽象问一遍再用例子重问一遍。需要语境时主动补上，用户已经理解时直接接着讨论。工具的 transition 模式只标识服务路径采访，仍绑定一个 T. 目标。
+
+以已确认“每周复盘写作、按月订阅”的搭子为例，第一轮可以问：
+
+> 假设小林回来做这次订阅的最后一次复盘，你会怎么跟她聊要不要再订一段？
+
+服务周期、频次和能力取自当前搭子的已确认内容，临时情境明确是假设，不能把本示例中的按月订阅强加给其他创作者。后续仅在尚未明确时，分别讨论继续或停止的服务范围、向用户传达的内容。对话围绕这次用户经历连续展开，不突然跳去问一个没有语境的配置项。
+
+已有回答清楚覆盖同一条动线后续决定时，直接整理这些内容供确认，不换种说法让用户再答一次；四组、每组三个决定的覆盖要求保持不变。只有创作者明确确认对应路径后，该路径才完成。

package/references/widgets-protocol.md

@@ -0,0 +1,83 @@
+# 小挂件协议
+
+仍用 host-guide 的 turn_begin → turn_finish → 实际展示 → presentation_record。共用 evidence、dependencies、unresolved 和确切版本确认。全部用户可见文字写“小挂件”。以下字段是宿主内部协议，不交给开发者填表。
+
+新建工作区自动写 widgetDesignVersion:1；缺少该字段的旧项目不追加阶段。旧项目明确追加时，turn_finish 的 patch 可含 `enableWidgetDesign:{evidence:[本轮真实inputRef]}`。不能手写状态或批量补造确认。
+
+context.widgetDesign.phase 为 booklets / catalog / prototype / acceptance / complete；旧项目为 legacy。stage 仍保持原四册阶段，不能修改 catalog.json 增加第五册。designQuestion 是 delivery 的非空字符串，记录当前一个设计缺口；只有四册已确认且启用新流程时有效，不占 D/K/M/S 等采访计数。question、designQuestion、confirmationObjectIds 三选一；纯 explanation 不携带三者。
+
+## 共用产物结构
+
+小挂件产物包含 id、stage:"interaction"、kind、title、markdown、data、evidence、dependencies、unresolved。不要传 hash，工具会计算。markdown 需与 data 一致，说明实际设计与待确认内容；unresolved 非空禁止确认。
+
+### widget-catalog
+
+固定 id=widget.catalog。data 为 `{widgets:[清单项],noWidgetsReason?:非空文本}`。空数组必须有理由并单独展示确认。
+
+清单项的字段全部必需：
+
+| 字段 | 形状 |
+| --- | --- |
+| id | 小写字母开头，后接小写字母/数字/连字符，不重复，最长 40 位 |
+| name / purpose | 名称与具体用途，非空文本 |
+| bookletRefs | 实际使用的已确认章节 Ref 数组（非空） |
+| creationTrigger | 创建与出现在对话中的条件，非空文本 |
+| initialContent | 初始数据与缺项提示，非空文本 |
+| updateRules | 从对话补充/修改后如何更新展示，非空文本 |
+| instancePolicy | 更新已有实例与新建实例的条件，非空文本 |
+| conversationSummary | 对话摘要显示的信息及与展开页关系，非空文本 |
+| fields | 非空数组，每项严格为 `{key,label,source,emptyText}`，四项非空字符串，key 不重复 |
+| readInteractions | 不重复数组，值限 tabs / filter / collapse / detail，可空；对应预设切换、筛选、折叠、只读详情 |
+
+清单 dependencies 引用实际使用的章节，至少一个章节 Ref；建议合并各项 bookletRefs。不要自动写入示例项目或默认业务字段。
+
+### widget-prototype
+
+固定 id=`widget.<清单项id>.prototype`。只能在当前清单有效确认后提交。
+
+data 严格为：
+
+```text
+{
+  widgetId: 清单项 id,
+  itemHash: 从 context.widgetDesign.items 复制的当前单项 hash,
+  rendererVersion: 4,
+  design: {accent: 六位十六进制颜色, layout: list|cards|timeline|ledger|checklist|changes,
+           icon: 固定图标名, conversationTitle: 对话中的搭子名称,
+           titleSize: 16到20的整数, screenWidth: 320到500的整数,
+           screenHeight: 568到1100的整数},
+  states: [initial状态, partial状态, updated状态]
+}
+```
+
+三态按 initial、partial、updated 顺序。每态严格含 `id,label,userMessage,buddyMessage,summary,overview,sections`，文本均非空。overview 严格含 `eyebrow,title,subtitle,metrics`；metrics 为零到三项的数组，每项严格为 `{label,value}` 非空文本。可选 `overview.progress:{value,max,label}`，value、max 是有限数字（不能是布尔值），max > 0 且 0 ≤ value ≤ max，label 非空；仅在数据支持时使用。概览标题和指标最大 20pt，普通正文仍为 16pt。
+
+sections 为非空数组，每项严格含 `id,title,rows`，分组 ID 不重复；rows 非空，每行含 `label,value` 非空文本，可附 `caption`、`icon`、`status`、`detail`。caption/detail 为非空文本，detail 仅在清单允许 detail 时可用。status 严格为 `{label,tone}`，label 非空，tone 限 neutral / pending / positive / changed，表达只读状态。design.icon 和行内 icon 均只能用固定图标：route / ticket / wallet / bag / activity / document / bed / train / coffee / pin / check / clock / info / arrow / chevron / close / signal / battery / plus。根据内容选择图标；不能附加事件或操作。缺项用可理解的提示，不编造数据。用多个 section 展示预设分类或日期；切换/筛选只在已提供分组间选择。
+
+版本 4 的 changes 布局允许行带 `change:{before,after}`，两项均为非空文本，且该行必须有 status，tone 限 pending 或 changed。pending 显示原安排与建议调整，changed 显示调整前与调整后；这是只读对照，不允许附加 action、确认或采纳控件。其他布局、早期版本不能带 change。
+
+rendererVersion 参与原型版本计算。新建或视觉改版使用 4；旧版 1、2、3 仍按原有模板逐字节渲染和恢复，不自动升级。版本 4 延续 3 的克制配色，增加各类专属卡片预览与展开结构：timeline 日期条、cards 凭条、ledger 账本、checklist 分类索引、changes 前后对照，list 保留普通列表。预览从同一份 states 提取，不生成额外业务事实。版本 3 沿用版本 2 数据结构，预算展示概览指标、物品用一行统计，其余直接进入内容；对话卡片不含指标区。版本 1 的 design 不含 icon/conversationTitle，layout 仅 list/cards/timeline，状态不含 overview，行仅 label/value 和可选 detail。维护已使用的渲染模板时如改变可见样式、交互或 SVG 表达，必须增加版本并要求重绘与重新确认，不能用资源修复悄悄改变旧设计。
+
+dependencies 包含这一清单项的全部 bookletRefs，不引用 widget.catalog 整体 hash，以免无关清单变动使所有原型失效。渲染器由清单项读取标题与阅读控件；data 不允许 html、script、action、事件处理器或任意可执行代码。
+
+turn_finish 成功提交原型时自动生成工作区 widget-assets/<原型hash>/ 下的 index.html、style.css、app.js，以及 chat-initial.svg、expanded-initial.svg 等六张示意图。Booklet 页面嵌入两视图并提供三态选择，卡片上的去查看可以打开展开页；阅读操作不写业务状态。
+
+资源恢复用 `{operation:"widget_render",objectId:"widget.<id>.prototype"}`，只重新生成当前有效设计，不新增回合、不改变确认。只读 status 不自动修复文件。原型 HTML 可用 `?view=chat|expanded&state=initial|partial|updated` 查看具体视图；完整长内容以可滚动 H5 为准，SVG 是首屏示意。版本 2、3、4 的 SVG 使用内嵌 XHTML 与同一套组件样式，需在支持 foreignObject 的浏览器中查看；不要宣称它兼容所有矢量编辑器。
+
+### widget-acceptance
+
+固定 id=`widget.<清单项id>.acceptance`。当前原型已确认后才可提交。data 严格含 `widgetId,itemHash,prototypeHash,reviews`。prototypeHash 为当前原型 hash。
+
+reviews 对象的五个键全部必需，值为非空观察记录：booklet-fit、reading-order、chat-consistency、conversation-update、read-only。分别描述需求覆盖、阅读体验、两视图一致性、数据从对话逐步更新、无输入及业务写操作的证据；不是布尔值打勾。实际问题写 unresolved，不能为通过门槛删除问题。
+
+dependencies 保留本项全部 bookletRefs，并加入当前原型的准确 Ref。自动结构/资源检查由工具单独计算，不接受宿主伪造 pass；人工判断通过下一轮开发者真实确认登记。
+
+## 确认顺序
+
+1. 保存清单，delivery 使用 confirmationObjectIds:["widget.catalog"]、confirmationScope:"object"；展示清单内容再登记实际展示。
+2. 开发者回复后用本轮 inputRef 确认清单。可在同一轮生成原型并请求原型确认（这是不同对象）。未确认清单不能提交原型。
+3. 实际打开/展示两视图三态和版本后再登记 presentation_record。开发者下一轮回复可确认原型；不能把清单的“ok”用于原型。
+4. 整理验收记录，请求验收对象确认；原型确认的回复不能替代尚未展示的验收记录。
+5. 所有当前对象有效确认后工具自动生成交付；finalize 不能绕过流程。开发者反馈设计修改时只更新相关产物并展示新版。
+
+prototype / acceptance 请求确认与确认入库时都会检查真实原型资源。多个同阶段对象可合并确认，但只涵盖确实展示过且开发者认可的范围。设计讨论与答疑不改原采访计数。

package/references/widgets.md

@@ -0,0 +1,99 @@
+# 小挂件交互设计与验收
+
+四册固定为定义、知识、方法、服务，共 27 章。四册全部有效确认后进入本阶段，不增加第五册，不重开已经完成的采访目标。所有面向开发者的表达统一为“小挂件”；协议字段和工程目录可保留 widget。
+
+小挂件是开发者前置确定样式与框架的只读 H5。搭子在真实用户对话中创建实例、逐步补充和更新数据，复用已确认模板，作为对话 UI 的补充。Creator 在本阶段产出的是设计和示例原型，不接通生产数据，也不冒充已上线功能。
+
+Booklet 页面集中展示清单、原型、验收与进度，不单独展示共用阅读规范卡片。只读、尺寸、字体等规范由 Skill 和渲染器执行，具体要求保留在本文与验收检查中。
+
+## 1. 依据四册提出清单
+
+读取四册已确认版本，尤其是核心任务、长期沉淀的内容、方法结果和服务交付。复用 S07 与 service.blueprint 中的 experienceMode、customComponentDescription；已说清的功能不重新询问。选择 conversation 也不能自动跳过本阶段；仍需提出有依据的建议，让开发者明确确认需要哪些小挂件，或明确不需要。
+
+按阅读任务归类，避免每个内容字段都拆成一个小挂件，也不要套用固定的饮食或计划示例。每项说明：
+
+- 名称、用途、对应 Booklet 章节；为什么需要集中展示。
+- 何时创建、何时在对话里展示；首次生成时有哪些数据，哪些缺项需提示。
+- H5 展示字段、数据来源、对话逐步补充和更新规则。
+- 同一内容何时更新原实例、何时新建实例；摘要卡片与展开页如何同步。
+- 可用的阅读操作及其作用；开发者可以补充、删除、合并或调整建议。
+
+保存清单为 widget.catalog，在 Booklet 页面展示说明，主对话留下一个清单确认请求。没有明确回复不能视为确认。开发者确认不需要时，保存 widgets:[] 和实际 noWidgetsReason，同样先展示、再凭真实回复确认；不得因为未回应就跳过。
+
+## 2. 清单确认后形成原型
+
+以清单中各项的 itemHash 为版本依据，生成对应小挂件原型。新原型使用 rendererVersion:4，由随附渲染器输出，不要求开发者填写 JSON 或编写 H5。原型中的例子须来自已知需求或明确标成示例，不冒充真实用户数据。
+
+先确定每项的阅读重点，再选择版式。不同小挂件保留共同的色彩与字体，但要在对话卡片和展开页形成可辨认的结构差异，不只换标题、图标或颜色：
+
+| 阅读任务 / 布局 | 对话卡片 | 展开页 |
+| --- | --- | --- |
+| 按日期阅读安排 / timeline | 日期预览条 | 编号日期导航与时间轴 |
+| 核对独立事项 / cards | 关键事项与状态摘要 | 分组凭条或事项单，说明与主信息分开 |
+| 看金额与明细 / ledger | 关键金额与预算口径 | 账本式金额对齐、分隔线和有依据的比例 |
+| 按成员或类别找物品 / checklist | 分类索引 | 左侧分类，右侧物品与只读准备状态 |
+| 看建议或变更前后 / changes | 一条明确标记状态的前后对照 | 变更前后并列，附时间、依据和待确认/生效状态 |
+| 无以上特征的资料 / list | 简洁主题与摘要 | 普通分组列表 |
+
+布局依实际任务选择，不将旅行案例内容套入其他搭子。changes 的 before/after 必须有原型内容依据；建议仍标待确认，不用视觉对照冒充已生效。交付前并排比较各项卡片与展开页：去掉标题后是否仍能看出阅读任务差异。若仍难分辨，先调整信息组织，而非堆叠装饰。
+
+同一搭子使用一致的强调色、圆角和留白。默认用白底与单一强调色，依据开发者偏好调整；不要用渐变、图标底座、胶囊标签和阴影堆出设计感。展开页先呈现主题与必要背景，随后进入分组内容；预算可保留关键金额，其他任务不强行套三列指标。对话卡片以类型、主题、任务预览、简短摘要和轻量查看入口为主，不给所有类型都附加同一套指标。导航使用清楚的选中标识；状态优先直接写在内容旁，句子已经表达的状态不再重复加标签。待补充、估算、已核实、已更新须有实际依据。比例条只用于有明确数值和分母的场景，不为装饰编造进度。图标与准备状态仅供阅读，不能像待勾选的控件。
+
+每个小挂件须展示：
+
+1. **对话中的样式**：保留触发它的用户消息、搭子回复、摘要卡片、标题、关键信息、“去查看”入口。卡片跟随对话列宽度；摘要与展开页引用同一份数据。
+2. **展开后的样式**：在对话背景上拉起带遮罩的圆角 H5 页，固定关闭与标题区，内容区纵向滚动；保留必要阅读导航。
+3. **三种数据状态**：initial 首次生成（缺项可理解）、partial 逐步补充、updated 对话修改后的新内容。每态都有两视图；对话消息须说明数据怎么变来，不能用小挂件里的“保存/修改”触发。
+
+视觉参考：用户提供的两张示意图分别代表“对话摘要卡片”和“展开阅读浮层”。保留两层关系、清晰标题、适当留白和内容分组。饮食内容、绿色、叶子装饰是参考案例，不是每个搭子的必选样式。技能包不依赖原作者本机的附件路径。
+
+绘制前查看随包参考：[对话摘要卡片](../assets/widget-reference/conversation.png)、[展开阅读浮层](../assets/widget-reference/expanded.png)。图片中的内容只作视觉参考，不能写成当前项目默认数据。
+
+### 统一只读边界
+
+允许：预设条件筛选、日期/分类/标签切换、展开折叠、滚动/翻页、拉起和关闭只读详情浮层。这些操作只改变本地阅读视图，不修改任何业务数据；嵌套浮层同样遵守。
+
+禁止：输入框（包括自由文本搜索）、表单、富文本编辑、添加/删除/替换记录、保存/提交、打卡/勾选完成、评分和其他业务写入。不得把写操作包装成筛选或确认按钮。需要修改时用提示“如需修改内容，请回到对话中告诉搭子”；由用户在对话中提出 → 搭子更新数据 → 原小挂件和摘要同步呈现。该提示不是自动发送消息的按钮。
+
+Booklet 上的示例状态切换是开发者审阅工具，与真实用户 H5 的能力分开。Booklet 本身仍只读，所有创作确认在主对话登记。
+
+### 尺寸与字体
+
+采用屏幕逻辑尺寸；网页按 viewport 的 CSS px 与逻辑 pt 一一对齐，不按物理像素或 devicePixelRatio 再放大：
+
+- 展开页宽度 = 屏幕宽度 − 32pt，左右各 16pt。
+- 展开页高度 = 屏幕高度 × 65%，内容超出时在内部上下滚动。
+- 标题建议 16pt / Medium，最大不超过 20pt；正文 16pt / Regular。
+- 393 × 852 的示例画布对应 361 × 553.8 的展开页（图示可标约 554）。标题和关闭保持可见，正文不能被遮挡。
+
+本版渲染器固定上述尺寸与字体约束，提供六类布局、任务相关的卡片预览、概览指标、前后对照、比例条与预设阅读控件。检查三态的空缺提示、长文本、摘要密度与类型辨识度，不能只检查信息最完整的一态。若需求超出当前原型能表达的范围，保留 unresolved，说明具体缺口并继续调整；不能把没有实际绘制的复杂图表或交互说成已实现。生产 H5 的文件封装和数据协议在后续工程阶段按平台实际约定实现。
+
+在 Booklet 页面检查实际生成的 HTML 两视图三态及 SVG 示意图后，展示确切版本并请求原型确认。生成成功或自动检查通过不代表开发者已看过；只登记真实展示。开发者反馈修改时生成新版，重新展示受影响的小挂件；不要连带重做四册和其他未变化原型。
+
+## 3. 设计验收与完成条件
+
+原型有效确认后，整理逐项验收记录，写明检查现象和依据，不只写“通过”。页面分开展示：
+
+| 检查类型 | 要求 |
+| --- | --- |
+| 自动检查 | 清单与数据结构、只读控件集合、逻辑尺寸与字体约束、两视图三态资源是否存在且与当前版本一致 |
+| 需求与内容 | 是否覆盖 Booklet 中真正需要集中展示的内容，初始缺项是否清楚 |
+| 阅读体验 | 分组、层级、长文本、滚动、折叠和详情是否易读；操作后能返回上下文 |
+| 对话一致性 | 卡片与展开页含义一致，三态示例清楚展示逐步补充和修改结果 |
+| 只读边界 | 小挂件及所有详情层没有输入、编辑、提交、打卡等业务动作；修改路径在对话中 |
+
+将后三类及相关观察写入 widget-acceptance 的 reviews，未解决的问题留 unresolved。宿主自动检查不能替代开发者体验判断。先在页面和主对话展示验收记录，再根据开发者下一条真实回复确认该版本。发现问题回到原型修改，原验收随原型依赖失效；同一轮不能修改和确认同一对象。
+
+新项目只有四册、当前清单、各项当前原型和验收都有效确认，原型资源和导出文件完整且校验一致，未暂停、没有待完成回合，才返回 creator_complete。已明确确认空清单时不制造多余原型或验收。四册在这之前可随时查看，页面不得称整个创作已完成。
+
+交付包含 BUDDY_MANUAL.md、四册、服务模式图、WIDGET_DESIGN.md、widgets/catalog.json、各项原型数据、可阅读 HTML/CSS/JS、两视图三态 SVG、设计验收及来源/版本记录。设计验收通过不等于生产 H5 注册、会话数据接入或端到端功能验收通过。
+
+## 4. 版本、恢复和面板
+
+- context.widgetDesign 提供 phase、当前清单、每项 itemHash、原型、确认状态、验收和资源检查。按此恢复当前步骤，不重问全套内容。Booklet 内容版本独立使用 bookletRevision；主对话多了一条原话不代表四册变更。
+- 原型按单个 itemHash 绑定清单项，不依赖整张清单 hash。清单变化先确认清单；未变的项保留原确认，变了的项需要新原型及验收。原型仍绑定实际使用的章节，Booklet 变化需重审相应设计；纯视觉调整不撤销四册。
+- 没有 widgetDesignVersion 的旧作品沿用原流程，读取或升级不自动追加本阶段。开发者明确要求追加后，通过 enableWidgetDesign 和本轮原话证据开启，不直接编辑 state.json，也不能关闭新项目必需流程。
+- 原型文件缺失或被改动时先 widget_render 重新生成同一声明版本，保留原话和确认，再 finalize；导出缺失用 finalize 恢复。若设计本身要变，提交新原型，不使用修复命令偷换已确认设计。
+- 所有阶段沿用 [一次性面板提醒](preview-panel.md)。是否需要重开以真实界面查询为准，不因进入小挂件阶段重置提醒资格。未回应或拒绝后不再询问。
+
+详细字段及调用顺序见 [小挂件协议](widgets-protocol.md)。