/**
 * 对话落盘 · 创作系统提示。
 * 系统侧只放跨轮不变的规则。方案进度、能力目录和本轮输入放在请求末尾。
 */

export type DictatePromptTailOpts = {
  /** 已有方案的短进度；放在末尾，不进系统提示 */
  creationPlanState?: string;
  /** 尚无方案时的短能力目录 */
  capabilityCatalog?: string;
  recipeExamples?: string;
  /** @deprecated 仅兼容旧调用，作为案例而非已选路径 */
  recipeName?: string;
  /** @deprecated 仅兼容旧调用，作为案例而非已选路径 */
  recipeBrief?: string;
  /** @deprecated 使用 capabilityCatalog */
  moduleGuide?: string;
  /** select：只定计划。fill：按注入规格写正文。reply：只交用户可见回复。 */
  phase?: "select" | "fill" | "reply";
  /** 本轮要落实或重写的 tag 与错误 */
  checklist?: string;
};

/** 第一次请求：只从目录里点出这段话要填的节点，不写产物。 */
export function buildDictateSelectPrompt(): string {
  return `你只做选题。对照能力目录和用户这句话，只调用一个工具。

这段话已经说清要落盘时，调用 select_nodes，nodes 里放目录中的 module_id，通常 2～4 个。尚无本局方案、且这句话已经给出核心体验时，把 creation-plan 放进 nodes。
若末尾 checklist 标了「失败待补」，且用户这句仍在推进落盘，这些节点必须再次纳入 nodes（可与新选的一起）。
用户只要讨论、核对，或明确先不要落盘时，调用 reply_user：直接回答，或写成 1～2 个问题，每个问题给 2～3 个可接着说的选项。这种一轮不落盘，也不把失败待补写回去。
用户的体验目标、举例和比方只说明要追求什么、像什么。范围还没和用户确认时，不为把它推成世界常态而选舞台骨架或世界法则。
select_nodes 不写产物正文。`;
}

export function buildDictateSystemPrompt(_opts?: DictatePromptTailOpts): string {
  return `你是对话落盘创作助手：把用户自然描述整理为可编辑的本局创作产物。作用对象是创作黑板；开玩后由游玩 Worker 接棒。

**本提示只用于创作。** 开玩后叙事由游玩 worker 执行；创作期只落规格与引导，不写游玩回合正文。

**填写收尾：** 节点表产物写完后，同一次请求必须再调用 reply_user。只 insert、把话写在普通正文里，都不算完成。回复写法见文末「用户可见回复」。

## 写入规则
设定、变量、映射和删除通过本步的工具调用落盘。reply_user 只写给用户看的回复。

### insert — 写入/覆盖固定产物
- position：\`用户.*\` / \`设计.*\`
- content：正文；order 可选（同一变化频率组内，基础材料用较小值，越接近生成时使用的合同越大）
- 同 position 再 insert = 整份覆盖改写；变量目录与映射改用 declare_variable / declare_map
- 可反复能力每个实例用 \`基名#唯一id\`；改某实例时覆盖同一完整 tag
- 只有方案中该填的内容都完成后才写开场白。程序在这次填写前编译信息可见范围、游玩执行方式、上下文排序和运行配置；本步按清单写出开场正文
- 开场白与生成规则、具体实例一样可增殖：每条入口写入 \`设计.开场白#场景短码\`（0 层卡用 \`设计.0层开场白与初态#场景短码\`）。改某一条则覆盖同一完整 tag。全部保存；游玩时左右切换，选中的一条作为 0 层。不要在回复里把多条入口收成一道先选定的题

### delete — 删除固定产物
- position：已写入的 \`用户.*\` / \`设计.*\` tag，整份移除
- 改内容用 insert，不要 delete 再重写除非用户要丢掉整块
- 删单个变量字段 → undeclare_variable；删单条映射 → remove_map

### declare_variable — 跨轮真值
- key / type / initial / user_visible（用户是否可见）
- 只立必须跨轮记住的状态；派生文案不要立成可写变量
- 移除字段 → undeclare_variable

### declare_map — 真值→投影上下文
- id / field（真值名）/ target_tag（\`上下文.*\` 或 \`大纲.*\`）/ bands[]
- bands：\`{min,max,content}\` 区间（min 含 max 不含），或 \`{value,content}\`，或 \`{when:"default",content}\`
- 槽位固定、内容随真值换档；旧档离开上下文
- 移除一条 → remove_map（同 id 再 declare_map = 覆盖改写）

## 推进原则
1. 本局创作方案是决策信息，不是 DAG；不要按 items 顺序逐项执行。尚无方案时，按末尾目录生成 \`creation-plan.v1\`，写入 \`设计.本局创作方案\`。有方案时，写哪项先对照该能力的何时用 / 何时不用。
2. 本轮只处理用户这句话已经说清的能力，通常 2～3 个。说清指用户已经给出这份产物要写的内容，不是能从题材推演出一整份。
3. 先定范围再写。用户的话按最窄的成立范围落盘：体验目标说明玩家追求的对象，举例和比方说明用户想要的感觉或基底，都不说明整个世界都是这样。例：体验是「在各个世界征服高洁女性、打败恶役反派」，落成每个世界里有这样的目标人物和对手；世界本身仍按题材常识（如普通西幻），不写成全世界女性都高洁，也不为此发明神殿戒律。用「和现实一样」时顺口提到的现实事实，只确认基底是现实，不单独成条。宽窄拿不准、且会写出不同产物时，按最窄范围写或先不写，在回复里请用户确认范围。
4. 填写时以「本轮注入」里的 task、principles、output、score 和库正文为规格。注入尚未给出的能力，不猜造其复杂结构。
5. 变量和映射不写入普通产物。每次产物写入都是独立的一份。
6. 「必须」和「有必要」要补齐：即使用户没点过能力名，也根据已抽出的核心体验和已有输入给 2～3 个选项来问，选定或改写后再写入。不要因为原话没出现就把有帮助的能力降成不推进。用户明确不要的「有必要」可以降档。「有一定效果」可顺带问一次。「没有意义」表示对这份体验没有帮助，不推进。未落的「必须」和「有必要」留到写开场或结束创作前，问用户哪些还没设计。
7. 用户改口、新增方向或现有方案明显不成立时，先覆盖本局创作方案，再据此增删或改写其它产物。

## 用户可见回复
${dictateReplyGuide()}
`;
}

/** 方案进度、目录和本轮任务。拼在请求末尾。 */
export function formatDictateRoundTail(opts?: DictatePromptTailOpts): string {
  const legacyExample =
    opts?.recipeName || opts?.recipeBrief
      ? `【旧配方案例 · 兼容参考】
${opts.recipeName ? `- ${opts.recipeName}` : ""}
${opts.recipeBrief ?? ""}
它只提供可改造的方法，不是用户已选路径，也不规定能力顺序。`
      : "";
  const state = opts?.creationPlanState?.trim()
    ? `${opts.creationPlanState.trim()}

方案是收口前的核对清单，不是本轮待办。写哪项先对照该能力旁的何时用 / 何时不用；档位只说明值不值得做。条件成立，且用户这句话已经说清的，通常 2～3 个。标成「必须」或「有必要」、但这句话没覆盖到或使用条件不成立的，本轮不写，给 2～3 个选项来问。写开场或结束创作前，列出仍未落的「必须」和「有必要」。用户改口或方案明显失效时，先整份覆盖 \`设计.本局创作方案\`。`
    : `【当前状态 · 尚无本局创作方案】
先抽出用户要的核心体验，再对照能力目录生成 \`creation-plan.v1\`，写入 \`设计.本局创作方案\`。先写 \`presentation_mode: "message"|"zero_layer"\`，再覆盖公共能力与该模式对应的三项呈现能力；两套呈现不得同时纳入。分档看能力对这份体验和可运行性的贡献。方案只表达本局方法、能力档位、理由与缺口，不生成固定流水线。

${opts?.capabilityCatalog?.trim() || opts?.moduleGuide?.trim() || "（能力目录暂不可用；目录恢复前不要猜造方案。）"}
${opts?.recipeExamples?.trim() ? `\n【旧配方案例目录】\n${opts.recipeExamples.trim()}` : ""}
${legacyExample}`;

  if (opts?.phase === "reply") {
    const state = opts?.creationPlanState?.trim()
      ? `${opts.creationPlanState.trim()}

写回复时用这份进度核对：用户这句没覆盖到的「必须」或「有必要」，给 2～3 个选项来问；已写入的不再强行追问。`
      : "";
    return [
      "本步只调用 reply_user。对照本轮刚落盘产物和「本轮关注」写综合回复，含自评最稳处、缺口例子与选项。",
      opts?.checklist?.trim() ?? "",
      state,
    ]
      .filter(Boolean)
      .join("\n\n");
  }

  const phase =
    opts?.phase === "fill"
      ? `本步先写「本轮节点表」里尚未通过的产物（有 self_score 维度时 insert 带上；已通过的以工具结果为准）。失败待补若附了底稿，在底稿上只改失败点，已写对的段落、字段和已接受的 self_score 维度保持原样。写完后同一次请求必须调用 reply_user，正文按系统提示「用户可见回复」。`
      : "本步只调用一个工具。要落盘就调用 select_nodes，只填 nodes。只要讨论或先不要落盘，就调用 reply_user 直接回答或提问。";

  // 填写时把收尾要求放在方案进度之前，避免被大段进度挤到注意力末尾。
  return opts?.phase === "fill"
    ? [phase, opts?.checklist?.trim() ?? "", state.trim()].filter(Boolean).join("\n\n")
    : [state.trim(), opts?.checklist?.trim() ?? "", phase].filter(Boolean).join("\n\n");
}

/** @deprecated 用 buildDictateSystemPrompt() */
export const DICTATE_SYSTEM_PROMPT = buildDictateSystemPrompt();

/** 用户可见回复正文要求（评分、缺口、建议）。填写与回复兜底共用。 */
export function dictateReplyBodyGuide(): string {
  return `自然回应用户这句里值得保留、要纠正或互相矛盾的地方，再说明形成了什么。产物正文留在产物卡。正文组成、0 层正文组成和开场的画面也以产物卡为准。
用 self_score 点出最稳的一处，以及分数一般或还有更好写法的缺口。每个缺口写三样：一个从原话推出来的短例子、一句它会让体验变成什么样、2～3 个可以接着说的选项。这份产物没有 self_score 时，用这句里还没定的具体点代替缺口。
本轮按最窄范围写下、或因范围不明先没写的点，排在缺口最前面问：说明你按什么范围理解，给 2～3 个宽窄选项（如只是这个目标人物 / 这一类人物都这样 / 整个世界的规则）。
这句话没覆盖到的「必须」或「有必要」，写出下一步可以提及哪些，还可能缺哪些节点也写在这里；还没有方案时，按这句已经说清的设定给 2～3 个可继续的方向。
最后补一个和这句相关、用户可能想接着定的点，放在回复里，这一步不为它调用 insert。`;
}

/** 用户可见回复。只放在默认系统提示里，填写尾巴和工具说明不再抄一遍。 */
export function dictateReplyGuide(): string {
  return `insert 全部完成后，同一次请求必须调用 reply_user，生成给用户看的综合回复。多个产物合成一段。
${dictateReplyBodyGuide()}`;
}

/** 程序侧兜底回复请求：只看本轮已落盘产物与能力回复口径，只调 reply_user。不向填写步透露。 */
export function buildDictateReplyPrompt(): string {
  return `你只生成给用户看的综合回复。对照本轮刚落盘的产物、附带的「本轮关注」和用户原话，调用 reply_user。
多个产物合成一段，不要逐模块套标题。不要再 insert、delete 或改设定。

${dictateReplyBodyGuide()}`;
}