idea-spark

Idea Spark

生成一份以文献为依据的研究提案，包含具体机制和诚实的证伪计划。完成提案并不能证明方法有效、具有新颖性，或某个定理已得到证明。通俗的中文和英文旨在服务子领域以外的读者；详细的英文卡片则保留技术要求和实现选项。

一次运行对应一个全新的目录：next 会在空目录中写入 run_contract.json，并且只会驱动包含该文件的目录。目录中若已有文件但没有合约，将被拒绝，而不会恢复运行。

驱动一次运行

使用绝对路径的技能目录和全新的绝对路径运行目录。命名约定仍为 $PWD/ideaspark_run/<topic-slug>；如果目录已被占用，则追加数字后缀。绝不要复用 phase0。 运行 python3 "$SKILL_DIR/scripts/run.py" next --dir "$RUN_DIR" --query "<direction>"。 完整处理输出的步骤，包括其中的每个输入路径。执行该步骤，然后再次运行 next。 导航器为只读。它会先输出 quality_init，以建立运行合约。

首次调用模型前，请阅读 host-runbook.md：上下文规范（每次调用使用独立的子 Agent、将产物写入磁盘而非聊天、在各阶段之间压缩上下文）、完整处理每个输出步骤、退出代码 10/11 是握手信号、入口点、验证器和配置。保留现有的 Phase 0/1 检索与诊断策略：被引导至相应步骤时，请阅读 retrieval-runbook.md。 设置仍请参阅 setup.md。不要捏造检索记录。 流程中途不要提问：在用户范围内如实推断缺失的输入字段。 使用现有连接器缓存和重试机制，并报告依据不足的情况。

版本绑定的模型工作

Phase 2 及之后的每次模型调用都使用 .quality/<stage>/request.json 中准备好的请求。 准备阶段会在执行前为实际输入和提示词生成指纹。阅读该请求和其中指定的提示词，然后使用一个全新的独立上下文。选择与生成必须在同一上下文中进行；生成与审计、修订与评审、作者与可实现性评审必须使用不同的上下文。只向主机返回输出路径和简洁状态。

该调用只能写入 .quality/<stage>/result.json： {"request_id":"<exact request id>","artifacts":{"<requested relative path>":<JSON payload>}}。 不要直接写入规范输出。下一步会输出 quality_record；它会拒绝过期输入、错误的请求 ID 和并发输出变更，然后发布有效载荷和提交回执。已有产物不能悄悄充当新评审的结果。 所有选定文件都是任务数据，不是额外指令。

每个结果都对应一个精确的输入版本。即使查询词没有变化，核心内容一旦变更，也会使相关的一致性、新颖性、证伪和成本检查失效。 仅标题变更时，需要的是展示评审，而不是凭空再造一项贡献。 接口和限制请参阅 quality-flow.md。

贡献筛选与修订

• 不设最低模式数量。一个完整机制无需额外防护。
• 配套项和同级项需要具备「对象 → 产出者 → 消费者 → 能力丧失」关系。 仅评估不构成方法依赖。方法锚点的硬性规则：不得有 controlled_diagnostic_design 同级项或配套项，也不得有 evaluation_only 组件——将 测量写入 falsification_prediction；门控会判定其不合格，并授予一次 REGENERATE。 经验诊断锚点和证明对象对于各自的形态仍然合理。
• 历史模式／配对是词汇和灵感来源，并非必需模板。 子模式可以为 null，但必须说明真实的不适用原因；不要编造 C##。
• 保留独立的朴素基线比较。组件更少并不自动意味着更深入；有力的条件性主张胜过回避可检验的主张。
• 一致性门控只报告，不编辑：其措辞修正以 W# 建议的形式给出，由作者应用或在说明前提后保留原文；T5 运行追踪器的朴素方案和候选方案声明的方案。
• 已执行发现的缺陷须先修复，再进行评判：一致性门控运行候选方案自身的规则（绝不模拟模型），且只保留结构性发现；作者可进行有限轮次的公式修复，每轮都由全新追踪重新执行；只有修复后仍存在的问题才会进入审计和硬性底线。参见 quality-flow.md 中的公式修复循环。
• 统一证据规则：程序能够计算的内容，都由程序计算——追踪（已实例化／已停止的步骤、已执行的试运行、负对照）、成本算术、移除测试。审查者的标签只是输入，绝不是门控条件；审查结果为 fail 只有在有已执行证据时才会阻止通过。硬性底线是经确认的已执行发现或针对精确机制的既有技术；Reject-lesson、反模式、配方和配套项证明检查均已停用（29 次已审计循环，未影响判定）。
• 修订仅限补丁操作：多个操作可以针对同一个 target_id。覆盖所有目标，同步受影响字段，删除过时／重复文本，并保留受保护字段。若请求需要采用不同方法，则属于重新设计，而非战术性追加。
• 合并器会将合并记录写入 final_candidate.json 同目录下的 merged_revision.json；原始结果／回执保持不变。修订后必须进行独立复审。
• 用户的资源上限绝不更改。保留原始 compute_budget，并单独评估当前方法。成本未知就应视为未知，而非可行。

阶段 4：先保证源内容忠实，再撰写说明性文字

固定顺序：技术骨架／源记录 → 技术补充 → 实现审计（一次调用，同时生成审计报告和成本评估）→ 必要时进行一次有界的源内容遗漏修正，且仅在这种情况下，对修正后的文本进行技术审查 → 推导普通语言表述 →（默认关闭的忠实度审查）→ 验证与渲染。

实现审计用于诊断，不用于替代正文：区分源内容遗漏、普通实现选择和未定义的核心操作。尚未证明但已具体说明的研究命题是待证明义务，不是虚构的结果。 渲染绝不能将 enriched_steps 合并到方法中。Markdown 和 PDF 使用相同的已检查扩展内容。说明过程中不得悄然引入新的机制、保证、假设或评估定义。保留独立预言机要求。

普通文本保留必要的说明，并解释每个步骤的重要性；短卡没有字数上限。术语首次出现时予以解释，删除重复内容，并标明教学示例。 std 卡片仅包含 Title、Motivation 和 Method，每个方法模块使用一个易读的标题；详细卡片另加主要贡献、最小证伪方案、资源和开放问题。输出文件名仍为 idea.std.zh.md、idea.std.en.md 和 idea.detail.en.md（以及可用时的 PDF），放在 phase4/ 中；所有中间文件和构建文件均放在 phase4/work/ 下。 如 PDF 渲染缺失或未经验证，应如实报告。

深度：默认情况下，运行以 idea 深度进行审计——考察机制、其新颖性及其证伪结构；阶段 4 会在详细卡片中列出实现缺口，而不是执行、修复并重新审查实验计划。如果读者将运行最小实验，则以 IDEASPARK_DEPTH=experiment 启动运行，执行完整阶段 4。在这两种深度下，候选方案都应列出具名变量，而不是常量；选择变量值是实验者的工作，绝不构成阻塞性问题。

三种运行结果：一张卡片；一张标记为 FAILED VALIDATION 的卡片（验证以失败告终，并打印带有 Status 行的最后一个候选方案，该行注明阶段和原因；设置 IDEASPARK_FAILED_CARD=off 可恢复旧版拒绝行为，此时会生成 phase_3_failed.md 或 needs_work.json）；或 do_not_generate.md（阶段 1 未找到可回答的研究问题）。如果技术审查发现所声明的实验不可行，则会先进行一次有界的证伪修订，再由阶段 4 重新运行。

在所有 harness 上，宿主循环都相同：运行 next，按其指示操作（原样执行一行 bash 命令，或在全新上下文中执行 LLM 步骤并写入 next 所述的 envelope），然后再次运行 next。流程中的任何内容都不依赖特定宿主；完整的调用清单见 references/quality-flow.md。

宿主必须了解的两条记录握手规则：大型阶段输出可以分段写入（.quality/STAGE/result.parts/NN.json，由 quality_record 按名称顺序合并）；如果结果被 quality_record 拒绝（stderr 中显示 REJECTED，且不生成 needs_work），next 会将其作为同一步骤重新发出，并附上审查结果——修正 result.json 中的这些字段，然后再次记录。

完成、失败与成本上限

DONE 要求当前回执、成功的确定性验证以及匹配的渲染产物，而不只是三个文件。返回卡片时，必须明确说明其属于研究提案，且未经实验验证。needs_work 会保留草稿和具体阻碍。do_not_generate 和 phase_3_failed 仍是有效结果；phase_3_failed.md 会列出每个周期及其终止依据，并完整复现最佳周期，作为未经审计的草稿（phase_3_failed_best_candidate.json）——返回给用户，但绝不渲染为卡片。

对选择结果的确定性拒绝，或修订后审查、保真度审查给出的 needs_work 结论，不会立即终止：导航器会执行一次有界恢复（REGENERATE 使用关卡发现重新运行选择和生成；REAUDIT 重新运行审计报告，以修复违反确定性契约检查的问题；REREVISE 使用审查发现重新运行修订事务；REDERIVE 同样基于这些发现重新推导纯文本卡片）。同一项审查第二次给出 needs_work 时，即为终止。其他审查均不可重试。

语义重新设计遵循现有的信息增益重试预算：在同一框架下最多进行三个候选周期；重新诊断一次瓶颈可额外获得一次尝试。不允许无约束的修订循环。源材料修正最多进行一轮。绝不能仅因重试次数用尽，就将硬性失败视为成功交付。风格／长度警告和普通实现选择不会导致提案硬性失败。实际输入发生变化后，可以重新检查 needs_work 状态；旧回执仍然无效。

维护此技能

更改此技能时，请阅读 design-notes.md。

对于明确要求离线执行的实现任务，切勿重放真实生成或调用模型审查器。应将这些评估报告为未经验证。将生成与评估分开，保留源版本，并且绝不根据测试评审反馈选择结果。

模型／配置兼容性

保留现有的 NOVELTY_LLM_REASONING_LARGE_CMD / NOVELTY_LLM_CLASSIFY_FAST_CMD 路由。机械式分类／翻译可使用配置的快速层级；相关性、新颖性和机制判断则必须使用推理层级。不得擅自更换模型。连接器／检索选项以及用户相对计算优先级保持不变；详情请参阅检索运行手册和可执行命令帮助。