电商配送与退货选项矩阵
一个 1-10 人的电商团队要在一个新区域开卖，最容易漏掉的不是商品，而是配送和退货到底怎么配：某个渠道其实没有配送方案、退货窗只写了大概、运费还带着另一个币种、结账页承诺的「次日达、包邮」在实际配置里根本做不到。问题不是不知道这些事，而是没有一个地方把它们按区域×渠道摆在一起逐条核对。
本技能做这件事：读一份 JSON，输出可以逐条核对的区域×渠道矩阵——每个单元格的结论、适用的配送与退货选项、无配送覆盖、无退货路径、币种不一致、时效倒置、失效/未生效、缺证据、承诺与结构化事实不一致的清单，加上只依据用户 requirements 的缺口表、责任字段、上线前人工检查表、澄清问题与 Markdown 矩阵。脚本只读一个本地 JSON，不联网、不写文件、不查承运商费率、不改结账页、不生成面单、不批退款。
输入与澄清
字段表、判定顺序与安全边界见 @references/guide.md（同目录 references/sample.json 是常规样例，references/sample-blocked.json 是重复编号、缺失、拒绝与注入的样例，两者输出分布固定）。
最少确认：as_of（必须带时区偏移）、store.default_currency 与至少一个 regions[]。
必须问清的关键点：
as_of与默认币种不能省。没有它们就无法判断生效期与币种冲突，工具会停在INPUT_INCOMPLETE，而不是猜一个当前时间或币种。- 缺失费用 ≠ 零费用。
fee缺失记MISSING_FEE并停在证据不足；fee: 0是有效的零费用，会被正常使用。 - 币种不换算。选项币种与
store.default_currency不一致记CURRENCY_CONFLICT；工具不会替你折算，也不会把不同币种相加。 - 时效区间必须完整。
min_days/max_days缺一记MISSING_TRANSIT_TIME；min_days > max_days记INVERTED_TIME_WINDOW；负数时效也是硬矛盾。 - 自提方式只有三类。
pickup_type必须是door（上门）/pickup_point（网点）/store_pickup（自提），表外值判BLOCKED；退货方式同理（door_pickup/dropoff_point/mail_back）。 - 退货窗与运费承担方是两件事。
window_days缺失或为负、fee_payer缺失或表外，都会单独记出来；缺失不会被当成「商家承担」。 - 承诺对不上先指出冲突。
promises[]里的时效/费用/退货窗只与该区域的结构化选项比对：没有选项能满足就记PROMISE_TIME_CONFLICT等，工具不替你改文案，也不替你改配置。 - 覆盖缺口要显式列出。某区域×渠道没有任何配送选项记
NO_DELIVERY_COVERAGE，没有退货选项记NO_RETURN_PATH——不说「应该没问题」。 - 没有
requirements就不判断期望。缺口表只依据你显式提供的要求；没有要求时输出明确声明，不会替你宣称「不满足客户期望」。 - 只给文件名，不要给路径或链接。
evidence_ref只接受单一文件名；含路径或链接的引用会被拒绝，输出里只保留安全化后的文件名，原引用不会回显。 - 不要填登录凭据。输入里出现密码、令牌一类字段或真实凭据形态的字符串会被整体拒绝，且不回显该内容。
执行
- 按 @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表示全部单元格可用。 - 按
matrix看每个区域×渠道的结论：READY/ACTION_NEEDED/INSUFFICIENT_EVIDENCE/BLOCKED。 - 按
no_delivery_coverage/no_return_path/coverage_gaps补覆盖；按currency_conflicts/inverted_time_windows修数据；按inactive_options决定续期或下架。 - 按
evidence_gaps与clarification_questions逐条追问；不要自行填数，也不要把缺失当成 0。 - 按
promise_conflicts处理对外文案：先改文案或配置到一致，再上线。 - 按
requirement_gaps看目标要求缺口；没有requirements时这一项为空且附带固定说明。 - 按
responsibility_fields给每个关键字段指定责任人；按human_checklist完成上线前人工核对。 - 用
human_confirm_items明确哪些决定必须由人工做（是否开卖、是否改文案、是否调政策），本工具不下判断。
运行约束
- 只读：只读取用户提供的那一个 JSON；不打开链接、不调用外部服务、不写文件、不访问任何承运商、平台或店铺后台。
- 不自动执行：不选择承运商、不改结账页或商品页、不生成面单、不批准退款、不取消订单、不联系任何人。
- 不换算币种：币种冲突只报告，不折算、不跨币种合计。
- 只推导不发明：结论只由输入中的明示事实推导；不虚构费率、时效、退货窗、运费承担方或追踪能力。
- 未知保持未知：缺失费用不按 0、缺失退货窗不按 0 天、缺失
fee_payer不按商家承担。 - 硬矛盾门禁：时效倒置、负费用、负时效、负退货窗、表外自提/退货方式、重复编号、承诺冲突都判
BLOCKED，必须先人工修正。 - 覆盖门禁：无配送覆盖与无退货路径分别列出，不静默略过。
- 要求门禁：没有
requirements时不生成任何缺口结论，并明确声明不据此判断客户期望。 - 确定性：选项按编号、单元格按
(region_id, channel)、问题按生成顺序、状态汇总按固定顺序，同一输入输出逐字节一致。 - 文件名门禁：
evidence_ref只接受单一文件名；含路径、链接或盘符的引用被拒绝，且只输出安全化文件名，原引用在任何字段都不出现。 - 提示注入逐字段检测、位置精确、低误报：覆盖备注、承诺文案等自由文本，命中时只加标记并在
injection_flagged中给出精确路径（如promises[1]/text）；检测要求「动作词 + 目标词」同句共现。 - 不可信文本先转义再入简报，命中即隐藏：
markdown_summary中所有自由文本走同一转义处理（去控制字符、折叠空白、对 Markdown 元字符加反斜杠）；命中注入的值改用固定占位「已隐藏疑似提示注入文本」。 - 隐私门禁：字段名命中
password、token、api_key一类凭据名，或字符串值具备真实凭据形态，直接拒绝处理且不回显该内容。 - 免责：输出是配送与退货配置的人工准备材料，不是承运商报价、时效承诺、结账页配置修改或法律/税务结论；真实费率、时效、可用性与消费者保护合规必须由人工核实并决定。
