择吉日·黄历选日（Pay Skill）
专业择日服务：给定事项 + 当事人生肖 + 日期区间，逐日全量评估，输出首选吉日、备选、务必避开清单、当日吉时与实操提示。
事实源为权威天文历算历法库的硬数据——干支、建除十二神、黄黑道值神、二十八宿、宜忌、冲煞、时辰神煞，全部独立推算得出，不采信网页黄历的单方说法；宜忌裁决上溯《协纪辨方书》官本与董公《选择日要览》原文，争议处以此为准。
一、适用与不适用
适用：搬家入宅、安床、开业开市、嫁娶订婚、出行、签约立券、动土装修。
不适用（不要硬套）：
- 需要个人八字全局、紫微斗数、奇门遁甲择时者——本服务只用到生肖（年支）与可选日柱地支，不要求完整八字。
- 医疗、法律、投资决策——择日是民俗传统，不构成任何专业建议。
- 已知当事人信息不全且无法补齐时，先按第二节向用户补齐再调用，不要用默认值蒙。
二、调用前必须先采集的信息（必读·先问后算）
铁律：不要一上来就调用。 用户第一次开口往往只说"我想下个月搬家"，信息不全就调用，等于花一次钱买一个不准的结论。一次性把下面这些问清楚，再调用。
2.1 通用必采（缺一项算不准）
| 采集项 | 为什么必须 | 对应入参 |
|---|---|---|
| 事项 | 决定整条否决链与宜忌关键词 | event |
| 希望办理的日期区间 | 逐日全量评估的范围 | start / end |
| 主事人生肖（或出生年月日） | "日支冲当事人生肖"是一票否决的第一条 | zodiac 或 birthDate |
| 主事人日柱地支（强烈建议） | 日柱冲克比只看生肖精准得多，是专业择日与"生肖党"的分水岭；有出生日期时服务端自动推算 | dayBranch，或由 birthDate 自动推 |
2.2 分事项增强采集（问到这些，结论才专业；对应话术见 2.3）
| 事项 | 还要问什么 | 用在什么地方 |
|---|---|---|
| 入宅搬家 | ① 同住人属相（老人、孩子都算）② 新居入户门朝向 ③ 灶台朝向 ④ 是否为首次入住 / 是否已装修完毕 ⑤ 有无必须避开的日子（工作日、家人出差） | 同住人被冲→否决或降级；门向灶向→太岁方／岁破方／三煞方提示 |
| 安床 | ① 使用者属相与出生年月日 ② 是夫妻床、老人床还是儿童床 ③ 卧室所在方位 | 冲使用者生肖否决；方位提示 |
| 开业开市 | ① 法人／店主属相 ② 门店门面朝向 ③ 行业类型 | 冲生肖否决；门向→三煞方提示 |
| 嫁娶订婚 | ① 新郎新娘双方属相与出生年月日 ② 双方父母属相 ③ 是登记领证还是办酒 | 双方被冲均否决；日柱双查；领证与办酒可分别择日 |
| 出行 | ① 出行人属相 ② 目的地大致方向 ③ 出行天数 | 归忌日否决；方向煞提示 |
| 签约立券 | ① 签约方属相 ② 期望签约时段 ③ 合同性质 | 五离日否决；吉时匹配 |
| 动土装修 | ① 房主属相 ② 施工方位（入户门／主墙朝向）③ 是拆改还是新建 | 三煞方、太岁方、岁破方重点提示 |
2.3 一次性问完的话术模板（通用版·按事项取用）
第一步永远是确认事项。 用户开口往往只说"我想挑个日子"，先确认属于七类中的哪一类，再套用下方对应模板——一次把该事项的清单问完，不要问一句等一句。
2.3.0 通用开场（事项未明时先用这一句）
> 想帮你挑个好日子，先确认一下：这次是要办什么事？搬家入宅、安床、开业开市、嫁娶订婚、出行、签约立券、动土装修——哪一类？
> 定下事项后我会一次性把要问的都列给你。
2.3.1 入宅搬家（move_house）
> 为了给你算准，我需要先确认几件事（越全越准）：
> 1. 希望在哪段时间搬（比如 10 月中下旬）？
> 2. 主事人（户主）的生肖；方便的话直接给出生年月日——有出生日期我能顺带算出日柱，比只看生肖准得多。
> 3. 一起住的人属相有哪些（老人、孩子都算上）。
> 4. 新房的入户门朝向和灶台朝向（大概方位就行，比如"东北""正南"）。
> 5. 有没有必须避开的日子（要上班、家人不在等）。
2.3.2 安床（bed_install）
> 安床要按使用者来算，请一次性告诉我：
> 1. 希望在哪段时间安床？
> 2. 这张床谁睡？他的生肖，方便的话给出生年月日（可算日柱）。
> 3. 是夫妻床、老人床还是儿童床（用神与宜忌侧重不同）。
> 4. 卧室在房子的哪个方位（如"正南""东北"）。
> 5. 有没有必须避开的日子。
2.3.3 开业开市（open_business）
> 开业择日要按法人／店主来算，请确认：
> 1. 计划在哪段时间开业？
> 2. 法人／店主的生肖；方便的话给出生年月日（可算日柱）。
> 3. 门店的门面朝向（如"正东""西南"）。
> 4. 行业类型（餐饮、零售、教培、美业等，影响宜忌取用）。
> 5. 有没有必须避开的日子（证照办理、装修收尾等）。
2.3.4 嫁娶订婚（wedding）
> 嫁娶要双方合参，请一次性给全：
> 1. 计划哪段时间办？是登记领证还是办酒？（两者可分别择日）
> 2. 新郎的生肖 + 出生年月日；新娘的生肖 + 出生年月日。
> 3. 双方父母的属相（用于避冲）。
> 4. 有没有必须避开的日子（亲友档期、酒店预订等）。
>
> 注：领证sign_contract（立券）与办酒wedding是两件事，若都要挑，建议分别查。
2.3.5 出行（travel）
> 出行择日要看出行人与方向，请确认：
> 1. 计划哪段日期出发？
> 2. 出行人的生肖；方便的话给出生年月日（可算日柱）。
> 3. 目的地在哪个方向（如"往南""西北"）。
> 4. 外出几天（判断归忌与返程日）。
> 5. 有没有必须避开的日子（会议、票务等）。
2.3.6 签约立券（sign_contract）
> 签约择日按签约方算，请确认：
> 1. 希望在哪段时间签？
> 2. 签约方（本人或己方主事人）的生肖；方便的话给出生年月日（可算日柱）。
> 3. 期望的签约时段（上午／下午／晚间，用于匹配吉时）。
> 4. 合同性质（买卖、租赁、合作、借贷等）。
> 5. 有没有必须避开的日子（对方档期、审批流程等）。
2.3.7 动土装修（groundbreaking）
> 动土要重点看方位煞，请确认：
> 1. 计划在哪段时间开工？
> 2. 房主的生肖；方便的话给出生年月日（可算日柱）。
> 3. 施工方位：入户门／主墙朝向（如"正北""东南"）。
> 4. 是拆改还是新建（用事轻重不同）。
> 5. 有没有必须避开的日子（物业、邻居、施工队档期等）。
2.3.8 通用兜底（事项已明但用户答不全时）
> 一时说不全也没关系，至少给我 事项 + 日期区间 + 主事人生肖，我先出结论；后面补齐出生日期（可算日柱）与朝向，我可以再算一次。
采集纪律：
- 一次把清单问完，不要问一句等一句。
- 用户只给了生肖没给出生日期：直接按生肖算，但在结论里注明"未提供日柱，按生肖精度判定"。
- 用户给了出生日期：优先传 birthDate，服务端按立春分界自动推生肖与日柱，比手填更可靠。
- 用户不愿意提供：不追问、不强迫，按已有信息出结论并标注精度限制。
2.4 采集项 → 入参对照
| 采集项 | 入参字段 | 不传的后果 |
|---|---|---|
| 出生年月日 | birthDate |
精度降到只看生肖 |
| 生肖 | zodiac |
有 birthDate 时可省 |
| 日柱地支 | dayBranch |
有 birthDate 时自动推；都没有则不做日柱冲克判定 |
| 同住人属相 | members（逗号分隔） |
只按主事人判，可能漏掉对家人的冲克 |
| 入户门朝向 | doorFacing |
无方位提示 |
| 灶台朝向 | stoveFacing |
无方位提示 |
| 性别 | gender |
不影响计算、不计入计费，仅用于称呼与嫁娶表述 |
2.5 必须如实告知用户的两个边界
- 方位（门向／灶向）只是参考提示：按传统方位学说判定太岁方、岁破方、三煞方，命中后在结论里给出
facingNotes提示，不构成一票否决——精确坐向需要二十四山与坐度实测，仅凭大方位不足以定吉凶。 - 性别不影响择日结论：传统择日不以性别取吉凶，采集性别只为称呼准确与嫁娶场景表述。
三、这是付费服务（必读）
本 Skill 为 Pay Skill（按次计费），判定与结果由后端服务返回。
- 服务地址：
https://zejiri-api.app.workbuddy.host（Agent 以环境变量ZEJIRI_API_BASE为准，缺省用此地址） - 计费接口：
GET /v1/zejiri/auspicious-days - 免费接口：
GET /v1/zejiri/events（返回支持的事项清单与当前单价，不计费）
调用后若返回 HTTP 402：这是正常计费流程，不是报错。按下列流程处理：
- 读取响应头
Payment-Needed（Base64 编码的账单，含金额、订单号、商户、截止时间）。 - 不要自行拼接支付链接、不要要求用户跳转站外网页。
- 使用支付宝官方 402 支付能力在当前对话内完成支付（如已安装
alipay-pay-for-402-service，按其流程执行；每收到一次新的 402 都重新走一遍，不复用历史支付记录）。 - 支付完成后，携带支付凭证请求头
Payment-Proof重试同一 URL（参数必须与原请求完全一致），即可取得结果。 - 若返回
502 FULFILLMENT_CONFIRM_FAILED：资源已生成但履约回执未确认，用同一 Payment-Proof 重试即可，不得让用户重复付款。 - 若返回
500 VERIFY_FAILED或订单校验未通过：保留错误信息反馈用户，不要重复发起支付。
计费单元：一次"查询 + 结果返回"为一次调用；同一资源重复请求且订单仍有效时，服务端按幂等返回，不重复扣费。性别等不影响结论的字段不计入资源标识，不会因此重复计费。
服务端验付（后端已实现，Agent 无需操作）：服务端收到 Payment-Proof 后，调用支付宝验付接口 alipay.aipay.agent.payment.verify 逐项校验凭证——active 是否为真、交易号是否与凭证一致、金额是否与本地订单一致、资源标识是否与请求一致、是否在支付截止时间之内、订单状态是否可用；任一项不通过即重新下发 402，绝不在未确认收款的情况下交付资源。验付通过后生成结果，再调用 alipay.aipay.agent.fulfillment.confirm 完成履约回执，最后才把资源返回给 Agent。响应头 Payment-Validation 中含 validated=true、交易号与资源标识，可据此核对归属。
订单持久化与幂等：订单按 out_trade_no 持久化到服务端仓储，记录金额、资源标识、支付截止时间、订单状态与履约状态；交付前以"待履约 / 已履约"状态做幂等控制，同一订单重复请求只交付一次、不重复扣费；履约确认失败可安全重试。
依赖的支付能力：对话内完成支付依赖支付宝官方 402 支付能力包（alipay-pay-for-402-service，SkillHub：@user_fdb96f95/alipay-pay-for-402-service，作者为支付宝官方）。未安装时按其提示安装即可；本 Skill 不自建支付链路、不引导任何站外交易。
四、调用参数
GET {ZEJIRI_API_BASE}/v1/zejiri/auspicious-days
| 参数 | 必填 | 说明 |
|---|---|---|
event |
是 | 事项代码，见下表；也接受中文别名（如 搬家） |
start |
是 | 起始日期 YYYY-MM-DD |
end |
是 | 结束日期 YYYY-MM-DD（区间上限 92 天，建议 ≤ 62 天） |
zodiac |
二选一 | 主事人生肖或地支：鼠/子/rat 均可 |
birthDate |
二选一 | 主事人出生日期 YYYY-MM-DD，服务端据此自动推生肖（立春分界）与日柱地支，比手填更准 |
dayBranch |
否 | 主事人日柱地支（如 未）。有 birthDate 时自动推，无需手填 |
members |
否 | 其他同住/参与成员生肖，逗号分隔，如 龙,狗。提供后按"一票否决取并集"处理 |
doorFacing |
否 | 入户门朝向：东北/正南/巽/坤 等（支持八卦与中文方位） |
stoveFacing |
否 | 灶台朝向，取值同 doorFacing |
gender |
否 | 男/女。不影响计算、不计入计费，仅用于称呼与嫁娶表述 |
limit |
否 | 返回候选数量，默认 5 |
includeRejected |
否 | true 时一并返回每日否决原因，便于解释 |
事项代码
| code | 事项 |
|---|---|
move_house |
入宅 / 移徙 / 搬家 |
bed_install |
安床 |
open_business |
开业 / 开市 |
wedding |
嫁娶 / 订婚 |
travel |
出行 |
sign_contract |
签约 / 立券 |
groundbreaking |
动土 / 装修 |
五、返回结果
JSON：result.recommendations[]（可用日，按分数降序）、result.rejected[]（includeRejected=true 时）、candidateCount、rejectedCount。
每个候选日包含：date、weekday、lunarDate、dayGanZhi、zhiXing（建除）、tianShen/tianShenType（黄道／黑道）、xiu/xiuLuck（二十八宿）、chongShengXiao/chongDesc（冲煞）、yi/ji（宜忌）、pengZuGan/pengZuZhi（彭祖百忌）、ownerRelation（与当事人生肖关系）、facingNotes（入户门／灶台朝向的方位提示）、score、warnings、auspiciousHours[]（吉时，含 branch、range、tianShen、hits）。
另有 result.owner.derivedFromBirth（出生日期推算出的年柱、日柱与生肖，便于核对）与 result.privacy（数据使用声明）。
六、结果已在服务端完成推算（Agent 不要自行重算）
服务端对日期区间内每一天全量推演：先按传统择日通则剔除不可用日（日支冲当事人生肖或日柱、黑道凶神、凶宿、月破月忌、四离四绝、四废与本命日、事项专项忌、当日忌项、参与成员被冲等），再综合宜忌、建除、黄道、吉宿、生肖合局、时令与坐向等维度加权排序，最后按当日日支逐时推算出可用的吉时。
Agent 的职责是准确转述，不是重新计算：
- 直接按返回的
score降序采纳推荐结果，不要另起一套口径、不要自造排名。 - 某日为何被弃：照
rejected[]（需includeRejected=true）与当日的warnings、ji字段说明转述，不要自己猜原因。 facingNotes的方位提示属参考项，不构成否决；输出时必须照原样注明"此项为参考提示，不否决"。- 用户追问"为什么这天不行"时，用返回结果中给出的依据作答；返回里没有的，不要杜撰。
- 用户对某日有异议时，可以换参数再查一次（如调整区间、补充成员生肖），不要手动改写服务端结论。
七、十二地支关系常识（用于向用户解释结论）
生肖 → 地支：子鼠、丑牛、寅虎、卯兔、辰龙、巳蛇、午马、未羊、申猴、酉鸡、戌狗、亥猪。
- 六合（六组）：子丑、寅亥、卯戌、辰酉、巳申、午未
- 三合（四局）：申子辰合水、亥卯未合木、寅午戌合火、巳酉丑合金
- 相冲（最忌）：子午、丑未、寅申、卯酉、辰戌、巳亥
- 相害：子未、丑午、寅巳、卯辰、申亥、酉戌
- 相刑：子卯、寅巳申、丑戌未、辰辰／午午／酉酉／亥亥（自刑）
- 相破：子酉、丑辰、寅亥、卯午、巳申、未戌
多成员时：一票否决取并集（任一人被冲即弃），优选与所有人皆成合局的"通吃日"，无通吃日时以主事人为准。
八、交付格式（直接照此输出给用户）
- 先给一个明确首选：表格列日期／星期／农历／干支·建除／值神／宿／冲煞／与当事人关系／宜项依据。
- 列出该日唯一需留意的忌项，并给补救方案（例如"忌安床"→ 安床另择日或提前完成）。
- 给 2 个备选，各一句说明适用场景。
- 单列"务必避开"：写明日期 + 原因；冲本命日必须标注"即便黄历写宜入宅也不用"。
- 附当天实操细节：吉时区间（取自
auspiciousHours）、入宅须阳搬阴不搬且日落前完成、忌空手进门（家主持米桶或水桶先行）、开火做饭等。 - 若提供了门向/灶向，单列"方位提示"：照抄
facingNotes内容，并注明"此项为参考提示，不否决"。 - 结尾一句：传统民俗仅供参考，最终以实际时间安排为准，不做"必定如何"的承诺。
建议配两张图：上部漏斗（全月天数 → 宜项筛出 → 剔除凶日 → 可用候选），下部候选表（推荐日绿色、可选用灰色、避开日红色）。
九、隐私边界
- 只传判定必需的最小信息：事项、日期区间、生肖或出生日期、日柱地支、同住人属相，以及可选的门向／灶向／性别。
- 不收集姓名、身份证号、住址、电话、门牌号等身份信息；即便用户主动提供，也不要写入入参。
- 出生日期仅用于当次推算生肖与日柱；服务端不落库、不写订单、不写日志、不留存，订单只持久化金额、资源标识与履约状态。
- 交付结论时不要复述用户的完整出生日期，只说生肖与日柱地支即可。
十、参考资料
references/donggong-jiachu.md：董公《选择日要览》逐月建除日定性原文（含每月三煞方位），裁决宜忌争议时以此为准。
免责声明：本服务输出为传统民俗与历法推算结果，属文化参考，不构成医疗、法律、投资或其他专业建议，也不承诺任何必然结果。
