预约服务爽约风险准备包
排班表上写着「周三 9 点，李女士，空调清洗」。到了周三早上才发现：她其实一直没回确认、提醒短信到底发没发出去没人知道、备用备件还在仓库、而这条预约有没有跟另一位客人撞车也没人核过。预约存在从来不等于已经准备好，而这些事实散在聊天记录、短信后台和排班表里，从来没有人逐条对过。
本技能做这件事：读一份 JSON，输出到期前可以逐条核对的人工准备板——每条预约的结论、今日人工确认清单、不可联系清单、未发送的确认草稿、前置准备缺口、备案时段表与责任人。脚本只读一个本地 JSON，不联网、不写文件、不联系客户、不改期、不取消、不收款、不写入日历。
输入与澄清
字段表、判定规则、状态优先级与安全边界见 @references/guide.md（同目录 references/sample.json 是常规样例，references/sample-blocked.json 是触发阻塞与拒绝的样例，两者输出分布固定）。
最少确认：as_of（必须带时区偏移）与 appointments[]。
必须问清的关键点：
as_of不能省。没有它就无法判断预约是否已过期，工具会停在INPUT_INCOMPLETE，而不是猜一个当前时间。- 预约存在不等于已确认。
customer.confirmed缺失时记UNKNOWN_CUSTOMER_CONFIRMATION并追问；不会因为排班表上有这条就当成已确认。 - 联系同意是三态，只有显式
true才可能生成动作。contact_consent为false的预约进不可联系清单，任何草稿都不会生成；为null时先追问同意情况。 - 未知提醒状态不算已发送。
reminders[].state只有sent/delivered才算已发证据；unknown（或写错的值）记为UNKNOWN_REMINDER_STATE并追问。整份reminders缺失或为空记NO_REMINDER_EVIDENCE。 - 预约时间已过不等于客户爽约。过期只写
WINDOW_IN_PAST与一条「需人工决定处理方式」，本工具不判定爽约，也不产生任何客户信用结论。 - 同一责任人时段重叠会被拦下。两条预约若属于同一
owner且时窗重叠，双方都记OWNER_DOUBLE_BOOKED并阻塞；工具不替你改期，只标出来。 - 模式取值固定。
mode只能是on_site/in_store/remote；缺失记未知，取值非法直接阻塞（INVALID_MODE）。 - 只给文件名，不要给路径或链接。提醒回执一类的引用只接受单一文件名；含路径或链接会被拒绝，输出里只保留安全化后的文件名，原引用不会回显。
- 不要填登录凭据。输入里出现密码、令牌一类字段或真实凭据形态的字符串会被整体拒绝，且不回显该内容。
- 未知就是未知。确认状态、同意、提醒、前置准备、政策知情、责任人或时区缺失一律标未知并追问，不默认为已完成。
执行
- 按 @references/guide.md 的字段表整理输入 JSON。第一次使用建议先用 @references/sample.json 跑一遍，确认输出结构后再换成自己的预约。
- 用 Python 3.9+ 执行本包脚本（无第三方依赖、不联网）：
python3 "<skill-directory>/scripts/run.py" "<input.json>"，Windows 可用py -3。 - 先看顶层
status：REJECTED表示输入疑似含凭据（已拒绝且未回显）；INPUT_INCOMPLETE表示缺as_of或没有预约；BLOCKED表示至少一条预约确定阻塞；GAPS_FOUND表示没有确定阻塞但存在待办或未知；READY表示全部预约已就绪。 - 看每条预约的
status：READY/ACTION_NEEDED/WAITING_ON_CUSTOMER/INSUFFICIENT_EVIDENCE/BLOCKED。 - 按
today_confirmation_list逐条处理今日动作（只列真正需要动作的预约；WAITING_ON_CUSTOMER不会出现在这里）。 contact_actions全部是DRAFT_NOT_SENT的未发送草稿，由人工决定是否发出。- 按
do_not_contact排除不可联系的预约；preparation_gaps补齐前置准备。 - 用
standby_windows看出哪些预约已有备案时段、哪些未备案、哪些备案时段与预约本身重叠。 - 看
owner_conflicts与clarification_questions：前者是责任人时段冲突，后者按Q-01顺序原样发给对应责任人确认。 - 用
human_confirm_items明确哪些结论必须由人工确认，本工具不下判断。
运行约束
- 只读：只读取用户提供的那一个 JSON；不打开链接、不调用外部服务、不写文件、不访问任何日历、短信或预约系统。
- 不接触客户：不联系客户、不发提醒、不改期、不取消、不收款；只输出准备状态与未发送草稿。
- 不判定爽约：过期预约只记
WINDOW_IN_PAST，不输出任何爽约、信用或黑名单结论。 - 同意门禁：只有
contact_consent显式为true的预约才可能生成contact_actions；显式false进do_not_contact；未知先追问。 - 提醒单调：
state不在sent/delivered内一律视为未知，未知永远不当已发送。 - 不猜测：确认状态、同意、提醒、前置准备、政策知情、责任人、时区、备案时段缺失一律保持未知并转成待确认问题，不默认为已完成。
- 确定性：预约按编号、待办按编号与原因、问题按编号、状态汇总按
APPT_STATES全部显式固定，同一输入输出逐字节一致。 - 文件名门禁：回执类引用的
basename只接受单一文件名；含路径、链接或盘符的引用被拒绝，且只输出安全化文件名，原引用在任何字段都不出现。 - 提示注入逐字段检测、位置精确、低误报：覆盖备注、服务名等自由文本，命中时只加标记并在
injection_flagged中给出精确路径（如appointments[0]/notes）；检测要求「动作词 + 目标词」同句共现。 - 不可信文本先转义再入简报，命中即隐藏：
markdown_summary中所有自由文本走同一转义处理（去控制字符、折叠空白、对 Markdown 元字符加反斜杠）；命中注入的值改用固定占位「已隐藏疑似提示注入文本」。 - 隐私门禁：字段名命中
password、token、api_key一类凭据名，或字符串值具备真实凭据形态，直接拒绝处理且不回显该内容。 - 免责：输出是预约到期前的人工准备材料，不是爽约判定、客户信用评价或收入结论；是否改期、取消、收费或终止服务由经营者依预约政策与当地规定人工决定。
