API Changelog Bot和Claude Opus 5
e813ea774d
changelog-filename-gate / validate (push) Failing after 1s
本单名下已有一份 changelog（看板身份三元组，PR #8048），但按内容 grep 那份已推送 文件，requirementMatched / seatsEnough / requirementMismatchReasonCode / 候选 / 座位 六个关键词全部 0 命中——AC-8 的候选面行为变化一个字都没有。 这正是 #7443 被重开的形态：按单号数文件全绿，按内容查全空。所以另写一份， 而不是让那份顶数。 行为变化（POST /admin/fleet/assignments/candidates）： TRANSFER-only 订单上，seatsEnough / requirementMatched / requirementMismatchReasonCode 由「恒空/退化」变为按 TRANSFER 需求真实判定。 修复前 AssignmentCandidateService.resolveSlotRequirement 的车型/座位锚点恒取 TRAVEL 需求：两类并存时接送机槽锚到 TRAVEL 需求的第 fleetItemIndex 项；TRANSFER-only 单上 取到 null、锚点整块退空、座位判据回退到整单 headcount，于是 5 座 SUV 反而「够」， 只剩车型一条提示（少报一半）。 两种失败出口都是 SlotRequirement.empty() 这条「仅提示不限制」的正常路径——不抛错、 不打日志。车务只看到提示不对，没有任何信号能顺藤摸瓜。这条静默属性已写进正文。 网关实测（2026-09-20 22:0x，同一次请求两辆车判定截然相反）： 7 座 SUV 蒙A-U1557 → seatsEnough=true / requirementMatched=true / reasonCode=null； 5 座 SUV 蒙P321A → seatsEnough=false / requirementMatched=false / reasonCode=SEATS。 修复前两车都会是 requirementMatched=null。这组阴性对照排除了「返回一堆候选但根本 没过滤」这个竞争解释。 取证前先补了部署缺口：开测时 fleet 停在 c35251b07，而 bf4fba5a2(#8062) 触及 fleet 却未部署，重新部署到 0/N 才开测，否则会测到旧字节。 请求契约完全不变：修法是按 requirementId 匹配式反查 kind，不是给请求补 kind 位。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>