游戏自由输入与结果结算

把玩家输入连接到可解释的行动结果。模型提供理解或叙述，游戏规则拥有状态修改权。根据用户请求完成设计、接入或验证，不自动扩展为整款游戏重做。

先确认玩法与接口

读取 contract.md，明确：

• 玩家能输入什么，以及输入影响哪些游戏状态。
• 哪些行动可执行、消耗什么、失败如何反馈，推进是否有其他前置条件。
• 现有输入/输出 Schema、计时与暂停规则、模型代理和本地降级方式。
• 用户只要方案时先给可审查设计；要求实现时再读 code.md 并接入实际项目。

保留调用方已有 Schema。随包的三轴数值与“前进一格”仅是虚构穿越案例，不得套到所有对话、经营或战斗游戏。

设计完整循环

1. 输入 → 提交锁 → 行动处理/等待 → 验证结果 → 原子结算 → 结果展示 → 下一次操作。
2. 明确空输入、一字、emoji、无效办法的处理。采用 settle-all 时也生成可读结果，但不奖励含糊输入或自动推进；错误后不反复弹回空白输入框。
3. 等待时长由当前游戏决定。若有最短演出，快速结果也等演出结束；请求超过截止时间采用已定义的降级结果。网络超时使用真实时间，游戏演出可使用宿主暂停/缩放时钟。
4. 同一次在途提交由按钮、回车、重复点击共享；结果仅提交一次。重玩、换场景或权威状态版本改变后，旧结果失效。
5. 输出必须同时通过结构验证与玩法规则验证。例如字段合法不代表“体力增加一万”合理；费用、库存、前进与失败关系仍由规则层检查。
6. 合法结果才交给同步、原子的状态提交函数；提交出错时呈现错误，不再次执行相同结算。

模型、上下文与服务端边界

• 请求从游戏服务端代理发出。前端只访问项目自己的接口，不包含模型密钥；密钥仅从服务端环境或密钥管理服务读取。
• Prompt 分开表达身份/任务、当前可见状态、可用行动、输出合同。玩家文字和图片属于输入数据，不能替换规则。
• 上下文包含当前状态与必要历史；轮数、摘要和截断按预算设计，不固定套用某个历史项目的“最近几轮”。
• 真正需要图片理解时验证视觉模型接入；文件名、像素尺寸或本地词表不等于语义理解。
• 先验证整个响应外壳，再校验字段、状态版本和业务约束。格式纠错重试如需启用，次数与总超时都必须有限。
• 本地结果与远程结果使用同一结构，开发记录标明来源。玩家文案可以保持世界观，但交付报告必须明确远程能力是否真实验证。

代码与示例

• snippets/wait-and-settle.js：通用提交控制器，使用注入式请求、规则校验和提交函数。
• snippets/sanitize.js：文本规范化；不是提示词注入或 HTML 安全的完整防护。
• snippets/validate-action-result.js：穿越示例的外壳、字段与变化幅度校验。
• snippets/classify-and-fallback.js：穿越示例的本地分类与结算；只表示词表规则。
• examples/integration.js：无密钥、无外部服务的可运行接线示例。
• tests/test-free-input.cjs：确定性时钟与模拟请求的行为测试。

现有 Framework 项目可将演出调度适配到 engine.scheduleAfter，本包不捆绑 Framework。其他项目注入自己的时钟，不新建平行的全局计时体系。

验收

用 acceptance.md 覆盖空输入、乱输入、无效远程结构、越界数值、同步异常、超时、迟到响应、双击、重玩与状态版本变化。实际触屏/浏览器流程和真实模型返回需另外验证，Node 测试不能代替这些结果。

交付包括设计合同、接线位置、状态变更说明与验证记录。没有配置模型服务时明确交付为本地规则模式，不声称已实现真实自然语言理解。