672214c06e
重置邀请码：补 409 并发冲突自动刷新与空码保护
...
ci/woodpecker/tag/build Pipeline was successful
自审发现两个未处理的边界，都属于「提示了但页面状态不对」：
1. 并发冲突（409）
两个请求同时重置时，后端乐观锁会让其中一个返回 409。
原先只弹错误提示，页面仍显示旧码——用户以为没重置成功，
但服务端实际已是新码，导致分享出去的是失效的码。
现在收到 409 会自动重新拉取邀请信息并刷新页面状态。
2. 接口成功但未返回新码
原先 `if (code) inviteCode.value = code` 在 code 为空时静默跳过，
却照样提示「邀请码已重置」，页面继续显示旧码。
改为明确报错并 return，不谎报成功。
npm run build 与 vue-tsc 均通过。
2026-10-21 17:32:28 +08:00
4cc36658c0
修正头图绿色背景高度：pb-16 → pb-22，让渐变切到会员卡一半
...
ci/woodpecker/tag/build Pipeline was successful
之前一直调不对，根因是我把方向搞反了。
重新用构建产物里的真实数值推算（--spacing = .25rem = 4px）：
绿色切入卡片的深度 = pb - |卡片上浮| = pb - 44px
pb-16 时只有 64 - 44 = 20px，约占卡片高（86px）的 23%，
看起来就是「绿色太矮、远没到一半」。
要切到一半（43px），需 pb ≈ 43 + 44 = 87px → pb-22（88px）。
之前的错误在于：几次都想通过减小 pb 或调整 -mt 来「对齐按钮中线」，
但两者会同步移动、互相抵消，所以怎么调都是 23%。真正要改的是
pb 的绝对值，让绿色背景整体变高。
改动：pb-16 → pb-22（64px → 88px），-mt-11 保持不变。
已用真实构建产物 CSS（dist/assets/*.css）渲染验证：
切入深度 44px、占卡片 51.2%、与按钮中线差 1px，
并截图确认绿色正确覆盖到头像与姓名的下半部分。
2026-10-21 17:30:34 +08:00
c75e55c6e7
VIP 徽标改到姓名右侧，头图高度按实测重新校准
...
ci/woodpecker/tag/build Pipeline was successful
1. VIP 徽标位置
原先绝对定位贴在头像右下角，会盖住头像边缘。
改为放在姓名右侧同一行：姓名 span 用 truncate、徽标 shrink-0，
长姓名被截断时徽标仍完整显示，不会被挤压。
2. 头图（顶部绿色背景）高度
按需求应为「达到购买按钮一半的位置，上方全是背景」。
基于真实结构（hero 内无可见内容，仅绝对定位装饰）重建等价 DOM 实测：
空 hero + pb-16 + 卡片 -mt-11
→ hero 底部 Y=78、按钮中线 Y=78，差值 0px，切入卡片 50.0%
即渐变边界正好落在「兑换 CDK」按钮中线，符合要求，故维持
pb-16 / -mt-11 不变（上一版实测同样为 50.0%，本次复核确认）。
已截图确认徽标与姓名同行渲染正常（长姓名截断、徽标完整）。
npm run build 与 vue-tsc 均通过。
2026-10-21 17:25:49 +08:00
315942cfce
修正：仅 VIP 用黑金卡，普通用户恢复珍珠白
...
ci/woodpecker/tag/build Pipeline was successful
上一版误解了需求——把两种身份的会员卡都改成了 VIP 黑金色，
实际应只有 VIP 使用该专属色，普通用户保持原有浅色卡片。
改动：
- 恢复 .member-card.is-vip（黑金 + 金色描边 + 金色文字/图标/光晕）
与 .member-card.is-free（珍珠白 + 深色文字）双形态
- 模板恢复 :class="isVip ? 'is-vip' : 'is-free'"
- 暗色主题恢复 is-free 的墨绿底（白底在暗色下刺眼）
- 头像外圈与底色按身份区分：VIP 白环 + 半透明白底 + 金棕首字，
普通用户淡品牌色环 + 浅品牌底 + 品牌绿首字
- 「兑换 CDK」按钮保持金色实底，在两种卡片上都有足够对比
保留上一版正确的文案改动：普通用户显示「开通 VIP 即可不限次数」。
已截图确认两种卡片渲染正确（黑金 / 珍珠白 分明）。
npm run build 与 vue-tsc 均通过。
2026-10-21 17:17:13 +08:00
fd214d06eb
清理会员卡的 is-vip / is-free 空壳类
...
ci/woodpecker/tag/build Pipeline was successful
上一提交把两种身份的卡片样式合并为同一套后，
:class="isVip ? 'is-vip' : 'is-free'" 已无任何样式差异，
三个选择器（.member-card / .is-vip / .is-free）指向同一份声明，
属于纯冗余。
改动：
- 模板移除该动态 class
- 浅色样式块精简为单个 .member-card 选择器
- 暗色块同理，只保留 html.dark .member-card
已重新截图确认渲染与清理前完全一致，删除的确为死代码。
npm run build 与 vue-tsc 均通过。
2026-10-21 17:13:31 +08:00
48c3948c56
我的页面会员卡统一为 VIP 黑金色，普通用户提示改为引导开通
...
ci/woodpecker/tag/build Pipeline was successful
1. 文案
普通用户副标题由「免费用户」改为「开通 VIP 即可不限次数」，
直接传达价值；VIP 分支保持显示到期时间与剩余天数。
2. 卡片配色统一
原先普通用户是珍珠白卡片、VIP 才是黑金，两套样式（.is-vip/.is-free）。
现统一为 VIP 专属黑金色，两种身份同一套质感，区别只在文案与角标：
- .member-card / .is-vip / .is-free 共用同一段背景与边框
- 文字、图标、光晕规则去掉 .is-vip 前缀，直接作用于 .member-card
- 暗色主题同步合并，移除原先 is-free 的墨绿覆盖（会破坏金色统一）
3. 连带调整
- 头像占位文字统一为金棕 text-amber-800（原普通用户用品牌绿，
在黑金底上不协调）
- 「兑换 CDK」按钮加深阴影，与深色卡片底更好分离
已用无头 Chrome 截图确认实际渲染：黑金卡片、金色文字、金色按钮
层次清晰，文字无遮挡。
npm run build 与 vue-tsc 均通过。
2026-10-21 17:12:20 +08:00
0d3280fe7b
我的页面：精简普通用户提示文案 + 头图边界对齐按钮中线
...
ci/woodpecker/tag/build Pipeline was successful
1. 文案过长显示不全
普通用户的副标题原为「普通用户 · 开通后执行任务不限次数」，
在卡片的 flex-1 区域内被 truncate 截断。
改为「免费用户」，与上方姓名行组合读作「张三 / 免费用户」，
既完整显示又不丢信息（VIP 分支同步去掉冗余的 "VIP ·" 前缀，
因为 VIP 身份已由姓名旁的角标体现）。
2. 头图绿色渐变边界位置
原先 -mt-14 时，头图底色边界落在会员卡约 63.6% 高度处，
低于「兑换 CDK」按钮中线 12px，看起来切在卡片中上部。
改为 -mt-11 后边界正好对齐按钮中线。
该结论来自无头 Chrome 实测而非估算：构造等价 DOM 后测量
heroBottom / btnCenter 差值，-mt-14 → +12px（偏低），
-mt-11 → 0px（对齐）。页面上写死了这次实测数据作为注释。
另经实测确认头图的 pb 只影响上方留白、不影响对齐
（pb-14 与 pb-16 均对齐），故保留 pb-16。
卡片内边距同步由 p-4 收窄为 px-4 py-3，让三行文字更紧凑。
npm run build 与 vue-tsc 均通过。
2026-10-21 17:07:13 +08:00
0d639ea485
我的页面：头像姓名并入会员卡，去掉学校信息
...
ci/woodpecker/tag/build Pipeline was successful
原先顶部渐变区单独一块「大头像 + 姓名 + 学校 + 学院专业标签」，
对用户实际没什么用，还占掉一屏顶部空间。
改动：
- 删除顶部个人信息块（含学校名与学院/专业/班级标签）
- 头像缩为 44px 圆形，移到会员卡内 Crown 图标的位置（该图标去掉），
姓名与会员身份（VIP/普通用户）合并为同一行
- VIP 角标改为贴在头像右下角
- 顶部渐变条高度压缩：padding-top 28px→14px、pb-20→pb-16，
会员卡仍以 -mt-14 上浮叠压，视觉层次不变
顺带清理不再使用的导入与计算属性：Crown 图标、GraduationCap 图标、
profileTags（学院/专业/班级标签）。
修掉 img 的 :src 缺可选链导致的 null 类型报错。
npm run build 与 vue-tsc 均通过。
2026-10-21 16:58:24 +08:00
3b4a8df8fd
兑换弹窗购买按钮去掉图标并缩小文字
...
ci/woodpecker/tag/build Pipeline was successful
按钮在弹窗内与「立即兑换」等宽，加上图标后文字被挤得偏紧。
按需求去掉 ShoppingCart 图标（图标导入仍被页面其他两处使用，保留），
文字由 text-sm font-semibold 调为 text-xs font-medium，
并加 px-2 避免文字贴边，整体更舒展。
npm run build 与 vue-tsc 均通过。
2026-10-21 16:45:00 +08:00
5a33afa213
修复兑换弹窗购买按钮不可见，并调整左右顺序
...
ci/woodpecker/tag/build Pipeline was successful
两个问题：
1. 按钮完全看不见（严重）
上一版给「没有 CDK？立即购买」用了 cdk-goto-btn 类，但该类只在
NoRunsDialog.vue 的 scoped 样式里定义过——scoped 样式带 data-v 属性
选择器，不会作用于 ProfileView 内的元素。结果按钮没有任何背景，
而文字是 text-white，白字落在弹窗白底上等于隐形（点击仍生效）。
现在在 ProfileView 的样式块内补齐 .cdk-goto-btn 定义：
珊瑚渐变背景 + 白色文字 + 阴影 + nowrap，与外层购买入口视觉呼应。
2. 左右顺序反了
按需求改为「没有 CDK？立即购买」在左、「立即兑换」在右。
npm run build 与 vue-tsc 均通过。
2026-10-21 16:41:41 +08:00
eaafc50739
兑换 CDK 弹窗内新增「没有 CDK？立即购买」入口
...
ci/woodpecker/tag/build Pipeline was successful
原先兑换弹窗里只有「立即兑换」，没有 CDK 的用户只能关掉弹窗
再去找外层购买入口，路径绕。
改为并排两个动作：
- 立即兑换（原有，flex-1）
- 没有 CDK？立即购买（flex-1，沿用外层购买的珊瑚渐变样式）
新按钮等同于点击外层「购买 CDK 兑换码」入口：先关闭兑换弹窗，
再调用同一个 onCdkBuyClick()（弹流程说明 → 确认后跳购买平台），
避免两个弹窗叠加；购买入口未开放时提示「请联系管理员」。
npm run build 与 vue-tsc 均通过。
2026-10-21 16:37:32 +08:00
44f93a0ae9
sdau sec_js 解析增加密钥形态校验
...
ci/woodpecker/tag/build Pipeline was successful
xsgzFetchRSA 此前只判断 DK/M/E 是否非空。若 /api/sec_js 响应被截断
或格式变化，正则可能匹配到残缺值，用它加密出的密文服务端必然解不开，
最终表现为「参数解码错误，刷新页面后尝试」，难以定位真因。
新增形态校验，提前拦住并把错误指向真实原因：
- DK 盐长度 < 16 → 报「DK 盐长度异常（len=N），sec_js 响应可能不完整」
- 模数 hex 长度 < 64 → 报「模数长度异常」
- 指数非 010001/10001 → 报「指数形态异常」
阈值取保守下限（真实响应对应 32 / 258 / "010001"），
已用线上真实 /api/sec_js 验证不会误判。
测试覆盖正常与四类残缺情形。
2026-10-21 16:29:38 +08:00
8926c0b109
邀请码改为 8 位 + 支持用户重置
...
1. 增至 8 位（backed/internal/handler/invite_code.go）
字符集 31 个不变（已去掉易混淆的 0/O/1/L），
空间从 31^6≈8.9 亿提升到 31^8≈8.5 万亿。
2. 新增重置接口 POST /api/auth/reset-invite
- resetInviteCode()：复用 withUniqueInviteCode，唯一性由
invite_code 唯一索引 + 冲突重试保证（与首次生成同一套逻辑，
不做「先查后写」，并发下依然正确）
- 乐观锁：仅当库中旧码仍是本次读到的值时才替换，
避免两个并发重置互相覆盖导致其中一个返回的码实际已失效；
冲突时返回 409 提示刷新重试
- 用户当前无码时先补齐再重置，否则乐观锁条件会失效
- 记录 oldCode/newCode 便于排查
3. 前端（ProfileView）
- 邀请码行内新增重置按钮（环形箭头图标，重置中转圈）
- 点击先弹确认框，用 danger 样式并明确告知影响：
「原来的邀请码会立即失效，别人再用旧码填写将无法绑定；
已经通过旧码完成的邀请关系不受影响，积分也不会被收回」
- 成功后直接更新页面上的邀请码并提示
测试：8 位长度与字符集校验、5000 次生成无重复、
重置生成的新码格式合规、两个哨兵错误互不混淆。
2026-10-21 16:29:31 +08:00
320f21442c
填写邀请码按钮文案改为展示实际可得积分
...
ci/woodpecker/tag/build Pipeline was successful
原文案「有同学的邀请码？点此填写」只说明能填，没告诉用户填了能得什么。
改为「输入同学邀请码，立即获得 X 积分」，其中 X 复用
inviteeRewardPerInvite —— 与上方推广板块「TA 得 X 积分」同源，
保证两处展示的被邀请方积分始终一致；接口未返回该值时降级为
「输入同学邀请码，立即获得积分」，文案仍通顺。
npm run build 与 vue-tsc 均通过。
2026-10-21 16:23:55 +08:00
770b1754b4
我的页面：次数并入会员卡、兑换 CDK 统一、邀请积分并入推广板块
...
ci/woodpecker/tag/build Pipeline was successful
1. 可执行次数并入会员卡那一行
- 普通用户：显示「可执行次数 N」，右侧按钮「兑换 CDK」
- VIP 用户：仍显示「VIP 会员 + 有效期/剩余天数」，
下方额外显示「可执行次数 不限」
2. 兑换入口统一
- 原「开通 VIP / 续费」按钮改为「兑换 CDK」，既能兑 VIP 也能兑次数
- 后端本就是同一接口：handleRedeem 依据响应 data.type
（'vip' / 次数）分别处理，故后端无需改动
- 兑换弹窗标题/标签统一为「兑换 CDK」「CDK 兑换码」，
移除 redeemKind 状态（已无分支）
3. 删除下方数据三宫格
- 不再单独显示「可执行次数」格子（已并入会员卡）
- 删除「已邀请 N 位同学」格子
4. 邀请积分并入推广板块
- 在邀请卡内展示「邀请积分 N」+「免费换次数」按钮
- 原「换次数」文案改为「免费换次数」
- 积分不足时按钮禁用并显示「满 1 可换」
- 兑换弹窗内的引导文案同步指向新位置
顺带清理：移除随三宫格一起不再使用的 Users 图标导入。
npm run build 与 vue-tsc 均通过。
2026-10-21 16:15:59 +08:00
651739af1b
次数不足弹窗统一为专用组件，底部改为「邀请好友 / 购买 CDK」
...
ci/woodpecker/tag/build Pipeline was successful
原先只有打卡页有专用的「签到次数不足」弹窗，请销假页只有一条
一闪而过的红色 Toast；而且提示让用户「购买 CDK」，但请销假页内
没有任何购买或兑换入口，用户看不懂也无处可去。
新增 components/NoRunsDialog.vue（打卡/请假/续假/销假共用）：
- 标题按场景传入（签到/请假/续假/销假次数不足）
- 说明两条获取途径：邀请新用户、购买 CDK
- 底部两个动作按钮：
· 立即邀请好友 → 跳 /profile?intent=invite，进页后自动复制邀请码并提示
· 立即购买 CDK → 跳 /profile?intent=buy，进页后自动触发 CDK 购买入口
（弹出流程说明弹窗，确认后跳购买平台）
ProfileView 新增 intent 处理（onMounted 末尾）：
- intent=invite：调用已有 copyInviteCode()
- intent=buy：CDK 入口可见时调用 onCdkBuyClick() 弹说明；
不可见时提示「购买入口暂未开放」
- 处理完用 router.replace 清掉 query，避免刷新/返回时重复触发
LeaveView 两处 onError 接入 handleNoRunsError()：命中次数不足时
不再弹红色 Toast（避免误导为系统错误），改弹专用窗；请假/续假
按 submittingExtend 区分标题。
HomeView 移除内联弹窗，改用共用组件。
npm run build 与 vue-tsc 均通过（仅剩改动前已有的 Gift 未使用告警）。
2026-10-21 16:10:05 +08:00
608dee697f
置顶公告视觉增强 + 请假销假页接入公告条
...
ci/woodpecker/tag/build Pipeline was successful
1. 公告条美化（PinnedNotice.vue）
- 增加左侧琥珀色渐变强调条，提升顶部存在感
- 增加 hover 态阴影过渡，点击反馈更明确
- 卡片背景改为更通透的柠檬暖色玻璃
2. 请假/销假页接入置顶公告（LeaveView.vue）
- 引入 PinnedNotice 与 announceApi
- onMounted 中异步拉取置顶公告，失败静默降级为空列表
（不阻塞页面主体加载）
- 公告条置于页面最顶部，与打卡页位置和交互一致
（翻页、长文本横向滚动、点击查看全部）
npm run build 与 vue-tsc 均通过。
2026-10-21 13:26:22 +08:00
fab756a1ef
购买 CDK 入口更醒目 + 跳转前弹流程说明
...
ci/woodpecker/tag/build Pipeline was successful
入口视觉强化：
- 从 <a> 改为 <button>（点击先进说明弹窗，由弹窗确认后才跳转）
- 内边距 p-4→py-5、图标 11→12、标题 15px→base/extrabold、箭头 8→9
- 增加呼吸光环动画 cdk-pulse（prefers-reduced-motion 下自动关闭）
跳转前说明弹窗（新增 showCdkBuyConfirm）：
按用户要求提示完整流程——
1. 在购买平台购买卡密，需填写并牢记「邮箱」与「查询密码」
2. 支付成功后，用同样的邮箱与查询密码在平台查询 CDK
3. 回到本站，在「兑换次数 / VIP」处粘贴 CDK 兑换
并提示购买平台为独立站点、兑换码勿泄露。
跳转方式：确认后在 DOM 中创建临时 <a target=_blank> 并 click()，
而非 window.open —— 手机浏览器会把程序化 window.open 当弹窗强制
当前页打开，原生链接行为更稳定。
2026-10-21 13:10:53 +08:00
b503f44a2d
更新 hfnu 分发处的注释：IAP 路径实测不可行，应走短信登录
...
原注释声称「wecloud 网关支持标准 IAP 账密登录，单独走 IAP」，
与实际不符。实测：
GET hfnu.campusphere.net/iap/login
→ HTTP 302 → ehall.hfnu.edu.cn/amp-auth-adapter/login?service=...
即 /iap/login 不给登录表单，直接跳 ehall 单点，导致 iapLogin 第一步
getIapLT（解析 lt 表单）必然失败——与 CAS 是否授权无关。
结合 10-19 抓包分析：ehall 侧登录只产出 ehall 域 cookie
（JSESSIONID/AUTHTGC/MOD_AMP_AUTH/asessionid），无法换到
campusphere 的 MOD_AUTH_CAS；校方 CAS 也拒绝为 campusphere 域签发票据。
本次仅更正注释说明真实情况与建议路径（短信登录），行为未变。
2026-10-19 22:36:50 +08:00
adb8bb7560
hfnu 登录入口改选中平台配置的 amp-auth-adapter
...
ci/woodpecker/tag/build Pipeline was successful
平台给 hfnu 的配置（来源：cpdaily-api 的 tenant_list.json，与线上
GetSchoolDetail 实测一致）：
idsUrl = https://ehall.hfnu.edu.cn/amp-auth-adapter
appId = d7de360368c94a808225
joinType= NOTCLOUD
而通用函数 getCasValidLoginUrl 的判断只认 campusphere / wec-portal-mobile，
遇到 amp-auth-adapter 不匹配，于是回落到 WecloudUrl。实测差异：
通用函数 → https://hfnu.campusphere.net/wec-portal-mobile/client
正确入口 → https://ehall.hfnu.edu.cn/amp-auth-adapter
因为 hfnuLogin 直接复用了通用函数，等于一直在错的入口上做登录，
这也是此前"登录页解析到了、但流程走不通"的一个成因。
改动：
- 新增 hfnuLoginEntry：优先取 idsUrl 中带 amp-auth-adapter 的值，
否则回落通用逻辑（不影响其他学校）
- hfnuLogin 改用该函数
- 测试覆盖：hfnu 必须选中 amp-auth-adapter；campusphere 学校与
无 idsUrl 的学校仍走通用逻辑；nil 安全
说明：该校登录仍会卡在校方 CAS 拒绝签发 service 票据，
本次仅修正入口选择这一确定性缺陷。
2026-10-19 19:54:46 +08:00
fc90e21920
hfnu 登录补齐缺失步骤：验证码预校验、密码 base64、lt 固定值
...
ci/woodpecker/tag/build Pipeline was successful
用真实待适配账号（2606221072）测试发现，原实现虽已实现验证码 OCR，
但提交方式与页面 JS 的真实流程不符，导致服务端静默退回登录页
且不给任何错误提示——正确密码与错误密码表现完全一致，无从排查。
从登录页 JS 中发现真实流程是三段式：
1. AJAX POST /sso/code/validationCode.jsp {validateCode}
仅当返回 {"success":true} 才继续提交；
2. 密码经 base64 编码后填入 password 字段（base.encode(password)）；
3. lt 替换为页面固定值 keys="e1s1"，而非登录页上的 lt。
改动：
- 新增第 1 步：带 ;jsessionid 与 X-Requested-With 调用 validationCode.jsp，
失败即明确提示"验证码识别结果不被接受"，不再发出注定失败的提交
- 密码改为 base64 编码提交
- lt 改用固定常量 hfnuLtKey="e1s1"
- 验证码 OCR 结果只保留数字并截取前 4 位（该校为 4 位纯数字；
实测 OCR 偶发返回 5 位，会被 validationCode.jsp 判为错误）
- 登录失败时记录响应体片段，便于后续排查
验证效果：修复后正确密码与错误密码可被明确区分——
正确密码认证通过并返回 COMSYSUIATGC=TGT-...，错误密码返回
"用户名或密码输入错误"。
遗留：认证通过后仍卡在校方 amp-auth-adapter 单点跳转拒绝
（"你不具有该URL的访问权限，系统拒绝单点登录跳转"）。
已实测 10+ 个候选 service：仅 http://ehall.hfnu.edu.cn/amp-auth-adapter/loginSuccess
为"已注册"状态，其余（含 https 版本、campusphere 各入口）均为"未注册"；
换另一账号（2510421079）结果相同，判断为校方侧全局限制，
非本服务代码可解决。
2026-10-19 18:53:21 +08:00
7cbbbff3ea
按签到 H5 真实逻辑补齐时间段与更新签到判定
...
ci/woodpecker/tag/build Pipeline was successful
从线上签到 H5 拿到源码（counselor-front.campusphere.net/...
wec-counselor-sign-apps/prod/prod_v2.1.1.1357_4DnD/stu/mobile/js/app.js），
按其中实现重写判定，不再依赖推测。
H5 关键实现：
xt = { sign: 1, noSign: 2, leave: 5 } // signStatus 枚举
Rt = { noStart, running, finished } // 任务阶段
$t(): isLoop 时把 signDate.substring(0,10) 与时刻拼接，否则用时刻本身
Gt(): current > end → finished
current <= begin → noStart
否则 → running
handlerButtonClick: if (signed && !isAllowUpdate) toast("更新签到开关已关闭")
updateSign: !updateLimit || leftNum 才允许提交，否则提示"已超出最大更新次数"
对补签的结论：签到 H5 全量 JS 中不存在 supply / 补签 字样。
所谓"补签"在 H5 里就是"更新签到"——已签到后再次提交，
受 isAllowUpdate 与 updateLimit/leftNum 控制。
查寝详情另有 supplyTime 字段（实测为空串），但签到 H5 未使用它。
改动：
- SignWindow/ParseSignWindow：singleTask*（查寝，完整日期时间）优先，
否则用 rateSignDate + rateTaskBeginTime/EndTime（sign、return_register）；
解析失败一律 Parsed=false 放行，避免时间格式差异误杀
- EvalTaskPhase：复现 Gt()，含"等于开始时刻算 noStart"的边界
- SignUpdateBlocked：已签到且 isAllowUpdate=false → 拦截；
updateLimit=true 且 leftNum<=0 → 拦截（次数用尽）
- handler 在执行前先查"已签到不允许更新"，再查时间段，
两者拦截时都写 fail 状态、记日志、发 task_error 事件且不扣次数
- 时间字段实测：sign/return_register 用 rateSignDate+时刻，
sleep_check 用 singleTaskBeginTime/EndTime 完整时间
测试覆盖：两种时间格式解析、时段内/外/边界、信息缺失不拦截、
signStatus 枚举各值、次数限制、EvalTaskPhase 三态与边界。
2026-10-19 11:40:17 +08:00
154670742c
执行打卡前校验时间段，不在窗口内直接返回明确提示
...
此前完全没有时间段判断：用户在非打卡时间点执行，会把注定被学校端
拒绝的请求发出去，白扣次数且报错含义不清。
用真实用户（学号 2364400108）拉 detailSignInstance 确认字段：
rateSignDate = "2026-10-25 (周日)"
rateTaskBeginTime = "18:30"
rateTaskEndTime = "23:00"
singleTaskBeginTime/EndTime 单次任务的时间段
currentTime = "2026-10-19 11:31:21"
该任务实际打卡时段是 10-25 18:30~23:00，而当时是 10-19，明显时段外。
新增（internal/service/cpdaily/task.go）：
- SignWindow + ParseSignWindow：解析上述字段，singleTask* 存在时优先用它；
解析失败一律 Parsed=false，调用方放行，避免因时间格式差异误杀
- CheckSignWindow：明确在窗口外才返回错误；起止时刻本身算在窗口内
- ErrOutsideSignWindow + signWindowError：可 errors.Is 识别，
但 Error() 只输出用户可读文案，不暴露内部标记
接入 handler（执行打卡流程）：取到详情后、填充表单前校验；
拦截时写任务状态为 fail、记录日志、发 task_error 事件并带 outsideWindow 标记，
不扣减次数。
测试用实测真实字段值：解析正确性、时段外拦截、时段内放行、
边界（开始/结束时刻放行、结束后一分钟拦截）、信息缺失不拦截、
singleTask* 优先级。
2026-10-19 11:32:40 +08:00
b40e95d6c3
同步编辑表单图片块的过时注释（点击直接替换 → 缩略图+编辑按钮）
ci/woodpecker/tag/build Pipeline was successful
2026-10-18 22:53:46 +08:00
1ffe68eb72
打卡表单图片加「编辑」按钮，点击重新上传
...
改动前：整个缩略图区域是 @click="handleImageUpload" 的上传热区，
视觉上没有任何按钮，用户不知道点图片会发生什么（部分浏览器/WebView
点击 <img> 还会触发自身原生看图，进一步造成「点了是预览」的错觉）。
改为三态清晰渲染：
1. 上传中 → 显示 loading（优先于缩略图，替换时给出明确反馈）
2. 已有图片 → 缩略图 + 右下角「编辑」按钮（铅笔图标），点按钮才重新上传；
图片本身不再是热区，避免误触
3. 无图片 → 虚线「上传」框（按钮语义）
两套表单（新建打卡 / 编辑表单）同步修改。
调整了 v-if 链顺序：原先缩略图判断在前，导致上传中状态在有图时永不显示。
说明：本次未定位用户所见「点图片是全屏预览」的确切来源——
代码中不存在任何预览组件，HomeView 的图片仅有上述点击绑定，
推测为宿主浏览器/App 内核对 <img> 的原生行为，与本项目代码无关。
2026-10-18 22:53:03 +08:00
72dd2645ec
前端上传 OBS 显式附带 filename，避免部分环境 400
...
ci/woodpecker/tag/build Pipeline was successful
对真实 OBS 做了 5 组对照（真实用户 cookie + 真实策略 + 真实上传）：
filename=file.jpg CT=image/jpeg → 204 成功
无 filename CT=image/jpeg → 400 失败
filename=blob CT=image/jpeg → 204 成功
无 filename CT=octet-stream → 400 失败
filename=image.jpg CT=octet-stream → 204 成功
结论：file 部分必须带 filename，否则 OBS 直接 400；与 Content-Type 无关。
原代码 `obsForm.append('file', file)` 只传两个参数。浏览器对
append(name, Blob) 会按规范自动补 filename="blob"，所以多数桌面/移动
浏览器能通过；但自动补的名字无扩展名，且部分环境（老 WebView、
App 内置浏览器）不补，就会命中上表的 400 分支。
改动：
- 新增 utils/obsUpload.ts：resolveUploadFileName 优先用原始文件名
（无扩展名时按 MIME 补），无 name 时按 MIME + 时间戳生成；
非图片/未知 MIME 回退 jpg。
- HomeView.vue（任务表单上传）与 LeaveView.vue（请假上传）两处
append 均改为显式传文件名。
说明：本次未定位到用户 400 的确切链路（后端复现 return_register 得到的是
cookie_expired 而非 400），此项为消除已知的 filename 差异，
使前端行为在任何环境下都稳定。
2026-10-18 18:58:24 +08:00
91b8d7bfd4
回退 4f9027b：实测证明返校登记上传端点不存在该路径
...
用真实用户 cookie（学号 2364400108，桂林信息科技学院）实测：
/wec-counselor-leave-return-apps/stu/obsOperate/obs/getUploadPolicy → 404
/wec-counselor-leave-return-apps/stu/obs/getUploadPolicy → 404
/wec-counselor-leave-return-apps/stu/leave/obs/getUploadPolicy → 404
/wec-counselor-attendance-apps/student/attendance/getUploadPolicy → 200
/wec-counselor-sign-apps/stu/obs/getUploadPolicy → 200
4f9027b
2026-10-18 18:57:08 +08:00
4f9027bb0f
修返校登记图片上传 400：该类任务误用签到模块的上传策略
...
现象（用户 19865075523，返校签到编辑表单上传图片）：
图片上传到 OBS 失败(400)，请重新选择照片上传
根因：返校登记是独立模块，API 前缀为
/wec-counselor-leave-return-apps
但 getImageUrlPrefix 没有该分支，taskType=return_register 落到 default，
于是去 /wec-counselor-sign-apps/stu 取上传策略；拿到的是签到桶/签名，
浏览器直传到 OBS 时被拒 400。
改动：
- 新增 GetLeaveReturnUploadPolicy：
POST {leave-return}/stu/obsOperate/obs/getUploadPolicy
（路径参照同族 leave-new 模块，复用 leaveReturnPost 的 Header 与错误处理）
- 新增 GetLeaveReturnPreviewURL：
POST {leave-return}/stu/obsOperate/obs/previewAttachment
（原先同样落到 sign 的 /sign/previewAttachment，取不到预览）
并对部分学校把地址放 message 的情况做兜底
- GetUploadPolicy / GetPreviewUrl 两个 handler 均加 return_register 分支，
并接入 cookie 过期自动续期与 needReLogin 判定
- getImageUrlPrefix 补 return_register 映射并加注释，避免再次静默走错模块
诊断增强：
- GetUploadPolicy 记录 formData 的字段名与 host（不含值）；
若 formData 为空则告警并输出响应片段——因为 formData 为空会让前端
回退到自行拼装字段的旧分支，那正是历史上被 OBS 拒绝的原因
测试：return_register 前缀必须为 leave-return 模块且不含 sign-apps；
签到/查寝/请假的既有映射不变。
2026-10-18 18:51:17 +08:00
458e13b807
CAS 回调遇「参数解码错误」自动重取盐重试，覆盖 DK 轮换窗口
...
ci/woodpecker/tag/build Pipeline was successful
多个无凭证实验已确认：
- /api/sec_js 的 DK 盐每次请求都不同，且与会话无关（同 cookie 两次也不同）；
- 服务端只能从密文里还原 DK，不依赖任何会话状态；
- 用当次 sec_js 加密的密文，服务端必定能解开（返回「用户名或密码错误」而非解码错误）；
- 无/无效 CASTGC 时 CAS 直接返回 200+登录页（Set-Cookie 清除 CASTGC），
根本不会给出 ticket——所以「参数解码错误」发生时 ticket 是有效的，
失败只可能发生在 /cas/callback 的解密环节。
由此推论：取盐与提交之间若服务端轮换了 DK，就会解密失败。
官方前端对该错误的提示正是「刷新页面后尝试」，说明官方也视其为可重试的
瞬时问题，而非致命错误。
改动：
- 新增 isXsgzDecodeError：仅当响应体含「参数解码错误」时为真
（凭证错误、ticket 无效等不触发重试）；
- 命中时重新拉取 sec_js、重新加密、重新提交一次。
安全性：解码失败意味着服务端没解出内容，ticket 未被消费，
因此重试不会浪费这张一次性 ticket。
日志：重试时记录 dkChanged（两次盐是否不同），
可据此确认线上是否真的发生了轮换，为后续是否加重试次数提供依据。
2026-10-18 17:18:14 +08:00
05d9ef26b1
续期后加真实可用性校验，避免「假成功」导致无限重试
...
ci/woodpecker/tag/build Pipeline was successful
162 日志（8884 容器，v1.2.157）实证：
16:25:58 INFO 刷新cookie: 已用长期凭证续期成功 userId=1279
16:25:58 ERROR 获取表单失败 taskId=337 error="...cpdaily_cookie_expired"
续期报告成功，紧接着业务调用仍过期。
根因：refreshCookieByLongTermToken 判定成功的唯一标准是
「结果里存在 MOD_ 前缀的 cookie」。但续期走的
/imUserToken/getImUserToken 接口只校验 sessionToken 头，
**不校验 CAS 会话是否有效**；当 CASTGC/sessionToken 本身已过期时，
它仍可能返回 errCode=0，并把 jar 里那批无效 cookie 全数带回。
于是本次续期「成功」，调用方立刻重试又过期，用户只看到内部错误码。
改动：
- 新增 cpd.VerifyCookieUsable：用业务同款最小请求（拉当天任务列表）
做只读探测。三种任务类型任一能正常返回即视为有效；返回
ErrCookieExpired 才判定凭证不可用；网络等其它错误不归咎于凭证。
该探测无任何写副作用。
- refreshCookieByLongTermToken 在回写 cookie 前先跑校验，
不通过则按续期失败返回，让上层走「请重新登录」引导，
而不是发出一轮注定失败的重试。
配合上一提交（07cf121）的两处升级与 userFacingError 兜底，
现在链路上任一环节的登录态失效都会转成明确的重登引导，
不再把 cpdaily_cookie_expired 暴露给用户。
2026-10-18 16:38:55 +08:00
07cf121aac
修 cookie 自动续期后仍失效时把内部错误码暴露给用户
...
现象（用户反馈）：
获取签到表单失败: 获取当日任务列表失败: 解析任务列表响应失败: cpdaily_cookie_expired
期望：能自动续期就续期；续不了就明确引导重新登录（前端据此跳登录页）。
实际：既没提示重新登录，还把内部错误码 cpdaily_cookie_expired 直接显示出来。
根因：自动续期成功、但用新 cookie 重试仍判登录态失效时，
重新拿到的错误（仍是 ErrCookieExpired）被原样返回。
而 needReLoginSignal() 只认 ErrPasswordChanged / ErrNeedReLogin，
不认识 ErrCookieExpired，于是：
- errMsg 保持 "前缀 + cpdaily_cookie_expired"；
- needReLogin=false，前端不会引导重新登录。
这属于「续期拿到了凭证，但凭证其实无效」的情形（长期凭证过期、
学校侧强制下线等），语义上等同于必须重新登录。
改动：
1. withCookieRefresh：续期后重试仍报登录态失效 → 升级为 ErrNeedReLogin，
这是所有 withCookieRefresh 调用方的统一入口，一处修全覆盖；
2. 签到执行路径：续期后重试仍过期同样升级，并加注释说明；
3. 新增 userFacingError(prefix, err)：输出前统一兜底，
任何残留的登录态失效语义都转成「登录凭证已过期，请重新登录」，
普通错误保留原文。即使某条链路漏做升级，也不会再泄露内部错误码；
4. 「获取签到表单」与「签到提交」两处失败文案改用 userFacingError，
needReLogin 一并由它给出（前端据此跳登录页）。
测试：原始 ErrCookieExpired、多层 %w 包装、ErrNeedReLogin、
JSON 文本「未登录」均转成引导重登文案且不含内部错误码；
普通错误原样保留；nil 不触发重登。
2026-10-18 16:36:31 +08:00
8b647fc31a
CAS 链路加诊断日志，便于一次请求定位「参数解码错误」
...
ci/woodpecker/tag/build Pipeline was successful
上一轮用公开接口做对照实验，确认了服务端响应语义：
- 正确加密但 ticket 无效 → 「用户名或密码错误」（解密成功）
- 裸 ticket / 乱码密文 → 「参数解码错误」（解密失败）
- 空 ticket → 500
同时已排除代码侧原因（Go 与站点 security.js 产物逐字节一致、
chunkSize=126 一致、sec_js 禁缓存、算法自 v1.2.157 未变）。
但「参数解码错误」仍缺一处可见性：CAS 换票拿到的 ticket 本身是什么形态、
加密后几块、服务端原始响应是什么，线上日志都没有。没有这些信息，
下一次复现只能继续猜。
新增（均不含凭证本体）：
- CAS 换票成功：ticketLen / hasSTPrefix / hasSpace / service
- 加密完成：ticketLen / dkLen / encLen / blockCount
（blockCount>1 才可能出现多块空格，届时 body 是否被 URL 编码才有区别；
这条日志能一次性回答该问题）
- 登录被拒：httpStatus / message / bodySnippet（截断 300 rune）
配套 truncateForLog：按 rune 截断，不切断多字节字符。
测试覆盖短串不截断、超长加标记、中文不产生乱码、边界值。
2026-10-17 23:11:37 +08:00
392c90ec11
更正 CAS 注释的推断错误，并兼容 ticket 的三种参数名
...
上一提交 e38fd89
2026-10-17 23:08:54 +08:00
e38fd89425
修销假两个线上报错：projectId 为空、CAS 参数解码错误
...
线上（162，v1.2.160，userId=1490）实测两类报错：
提交销假失败: 缺少请假类型（projectId）
学工系统登录失败: 登录失败: 参数解码错误，刷新页面后尝试
且伴随 WARN「获取销假表单字段失败: 未找到数据」——因为 projectId 为空，
form_fields_for_add 查不到任何东西。
1) projectId 为空
projectId 是销假提交必传项，但前端销假请求体未必带（TypeWid 在列表里，
不一定回传到执行接口）。原实现直接拿 req.ProjectID 用，为空即报错。
修复：
- 为空时按 leaveId 调 leave_detail 回查补齐，补到后记 INFO；
- 回查仍拿不到则明确报「无法确定该请假记录所属的请假类型，
请返回列表刷新后重试」，而不是发出注定失败的提交。
- 同时修 XsgzFetchLeaveDetail 的解析：前端取的是
`c.value?.project?.id || c.value?.projectId`，项目 id 可能嵌在
project 对象里；原先只读顶层 projectId，现按「顶层优先、
回落 project.id」处理，项目名同样回落到 project.text。
2) CAS 参数解码错误
前端 getOAuthToken 的 body 是 `ticket=${s}` 直接拼接，**不做 URL 编码**。
我们原先用 url.QueryEscape，而密文由多块小写 hex 以**空格**连接
（实测长 ticket 分 2 块），QueryEscape 会把空格变成 '+'；
服务端按原始 body 解析时还原不回空格，逐块解密失败，
正好对应「参数解码错误，刷新页面后尝试」。
修复：改为与前端一致的直接拼接。
测试：
- 回查补齐 projectId 的两条路径（嵌套 project.id、顶层优先）；
- CAS body 保留原始空格、不得出现 '+'；
- 反例固化 QueryEscape 会破坏 ticket，说明为何不能用它。
2026-10-17 23:05:30 +08:00
9bf2d46f84
修人脸识别排队被误判为失败：识别中应继续等待
...
问题（162 服务器日志实证）：
ERROR 人脸识别被系统驳回，判定签到失败 userId=1043 message=识别中,预计等待4位
ERROR 人脸识别被系统驳回，判定签到失败 userId=1043 message=识别中,预计等待8位
「识别中,预计等待N位」是服务端识别队列的进度提示，不是失败。
但 evalFaceIdentify 里只要 recognitionProgress 非空就判 Rejected+Settled，
于是提交后的复核立刻判定签到失败，用户看到报错，实际签到可能仍在排队后成功。
根因：
if res.Progress != "" { res.Rejected = true; res.Settled = true; return }
修复：
1. 新增 faceProgressIsPending / faceProgressIsTerminalFailure 两个判定：
- 含「识别中/排队/处理中/等待」等 → 进行中，继续等待；
- 含「未通过/失败/驳回/人脸不匹配/未检测到人脸」等 → 终止失败；
- 两者皆无的未知文案 → 保守按进行中处理，不误杀（超时后仍走原有
「未出结果按成功」兜底）；
- 判定失败前先排除排队文案，避免「识别中」被误伤。
2. handler 轮询策略调整：原先固定 4 轮（0/1/2/3 秒）就收手，排队靠后
必然等不到结果。现在前 4 轮快速取结果，之后每 3 秒一轮，最长再等
90 秒；期间把最新排队提示透传给前端（queued=true），用户能看见进度。
测试：用日志里的真实文案断言不判驳回；同时保留 FRS.0036 等真实失败
文案必须判驳回；progressCode=2 无文案时仍判驳回；未知文案不误杀。
2026-10-17 21:37:07 +08:00
152878cc7c
销假填充与 normalize 打架：天气字段不再被地址污染
...
自审本轮改动时发现的不一致：销假路径先按标签用地址兜底填充，
再调用 normalizeXsgzFields，而后者对 regions 是「清空 value」。
两者叠加导致：
- 若字段名含"原因/说明"且是 regions 类型，地址先被写入、又被清空，
等于白填，且语义上互相矛盾；
- 上传类字段同样可能先被写入地址，再被 delete(value)。
请假路径的 fillXsgzFieldValues 已跳过这两类，销假这段循环没跟上。
改动：销假填充循环加 xsgzNonTextFillable 判断，与请假路径保持一致。
测试：一个同时含 regions / imageUpload / TEXT 的销假表单，
断言文本字段得到地址、地区字段为空、上传字段无 value。
2026-10-17 18:26:27 +08:00
b90a1dcd8f
xsgz 纯原始值数组改为 join(",")，并引入对拍测试防止再次误读前端规则
...
写了一个忠实转写前端 v()/pe() 的参考实现做对拍，立刻发现一处真实偏差：
前端: tags = "a,b,c" （单个键）
Go: tags[0]=a tags[1]=b tags[2]=c （三个索引键）
前端 v() 对数组是两条分支：
if (s.some(l => l && typeof l == "object")) → 按下标展开 `${i}[${p}]`
else → const l = s.map(p => p ?? "").join(","); append(i, l)
我们只有前一条分支。学校端按 tags 读字符串时拿不到值。
此前几轮反复在「方括号 vs 点号」上判断失误，根因是仅凭注释与内部一致性
推断契约。这次改为用可执行的参考实现做对拍，让差异由测试暴露而不是靠人眼。
改动：
- xsgzFlatten 数组分支按是否有对象分流：纯原始值 join(",")（空数组
与全空值不提交），含对象才按下标展开；键名规则本身不变
（对象键点号、数组下标方括号）；
- 新增 leave_xsgz_jsref_test.go：把前端 v()/pe() 转写成 jsFlatten，
用真实形态载荷（请假、销假、多字段、嵌套 map、空 fields）对拍，
双向断言「不缺键、不多键、值一致」；
- 记录一处有意差异并说明理由：前端会把 null 提交为空串，我们跳过空值，
对必填校验等价且更干净。
2026-10-17 18:25:23 +08:00
6bc7ab359c
xsgz regions 字段不再被文本值污染，且必填时能正确拦下
...
前端 Ie() 对 regions 组件的处理（studentForm-Dx5Fpjfs.js）：
s = (e[fieldId+"_regionsDetail"] ?? e[fieldId+"_detail"])
?.replace(/,/g,"，")?.trim() || ""
o.value = 选中值 ? (s ? `${选中值},${s}` : 选中值) : (s || n)
即 value 是「选中值,详情」的拼接串，详情还会把半角逗号换成全角。
本平台不提供地区选择，没有 _regionsDetail/_detail 可拼接，
此前的实现会把「请假原因」当作地区值写进 value，
学校端会收到无法解析的非法地区串。
改动：
- normalizeXsgzFields 对 regions 清空 value（置 ""，由 xsgzFlatten 跳过，
不会提交该键），避免残留脏值；
- fillXsgzFieldValues 跳过 regions（新增 xsgzNonTextFillable 统一判定
上传类与地区类），不再把文本写进地区字段。
顺带修掉一个逻辑矛盾：checkXsgzUnfilledRequired 原先对「非文本可填」类型
一律 continue，导致**必填的 regions 字段永远不会被拦下**——
请求会带着空地区发出去，然后被学校端含糊拒绝。
现在只有上传类跳过（它由 uploadFiles 承载，无 value 属正常），
regions 必填无值时正常纳入预检，明确提示用户缺哪个字段。
测试：regions 不被填入请假原因、残留 value 被清空、
必填 regions 触发预检拦下（该用例正是暴露上述矛盾的地方）。
2026-10-17 18:24:19 +08:00
bb4a1d2325
xsgz 字段提交按前端 Ie() 语义清洗：上传类去 value、多选 join 逗号
...
从 studentForm-Dx5Fpjfs.js 的 Ie() 看到字段有三条分支：
regions: value = 拼接地名
imageUpload / fileUpload / smoothSignature: o.uploadFiles = 文件列表；不设 value
其余: o.value = Array.isArray(n) ? n.join(",") : n
我们的实现只有一条路——直接写 value，导致两个偏差：
1. 上传类字段（图片/文件/手写签名）被塞了文本 value，前端根本不会这样提交，
且从未提供 uploadFiles。学校端若要求附件，行为不可预期。
2. 多选类字段若 value 是数组，xsgzFlatten 会展开成 fields[0].value[0]
/ fields[0].value[1]，学校端按 value 取字符串时读不到；
前端是 join(",") 成单个字符串。
改动：
- 新增 normalizeXsgzFields，按上述三分支净化字段定义：
上传类删除 value（本平台不代传附件，不臆造 uploadFiles），
数组 value 按前端规则 join(",")（跳过 nil 与空串）；
- 请假、销假两条提交路径都接入；
- fillXsgzFieldValues 跳过上传类字段，避免把「请假原因」写进附件字段；
- checkXsgzUnfilledRequired 不把上传类必填字段算作缺失
（它们由 uploadFiles 承载，无 value 属正常），避免误拦。
测试：三种上传类型去 value、多选 join、数组含 nil/空串、普通字段不受影响、
空输入不 panic、填充跳过上传类、预检不误拦上传类。
2026-10-17 18:23:06 +08:00
96de022871
xsgz 登录后补拉 /auth/user 拿 roleId，不再只依赖 cas/callback 响应
...
核对前端源码发现两者的获取路径是分开的：
getOAuthToken: setToken(m.data.data?.access_token) // 只管 token
getUserInfo: POST /auth/user → data.role.roleId // roleId 在这里
axios 拦截器: s.headers.roleId = JSON.parse(getCurrentRole()).roleId
s.headers.Authorization = getToken() // 原文，无 Bearer 前缀
我们原先在同一处只读 cas/callback 的 data.userInfo.roleId。
若该校响应不含该嵌套结构，RoleID 会为空，导致：
- 所有后续请求缺少 roleId 头；
- 学校端可能直接拒绝，且报错信息不会指向真正原因。
改动：
- 登录成功后主动 POST /api/auth/user 取 data.role.roleId（roleName 同步）；
- 该调用失败不阻断（slog.Warn 后沿用 cas 响应的值），保持向后兼容；
- 两者都拿不到 roleId 时才明确报错「未能获取角色信息」，
避免带着空 roleId 一路请求到被学校端拒绝；
- realName 缺失时回退 xm（国内学工系统常见字段名）。
顺带核实两处未被验证过的契约，结论是现有实现正确、无需改动：
- Authorization 头是 token 原文，不加 Bearer 前缀；
- RoleID 与前端 getCurrentRole().roleId 语义一致。
测试：/auth/user 的路径与 POST 方法、role/roleName/realName 解析、
realName 缺失回退 xm、非 0 code 必须报错。
2026-10-17 18:21:52 +08:00
7c2b9aa3a7
销假范围标记改用 leave_detail 精确查询，避免分页上限导致漏拦截
...
上一版 recordRequiresInArea 拉 50 条列表再线性查找留两条隐患：
记录超过 50 条时找不到 → 误判「不要求」→ 漏掉前端那道拦截。
核对前端源码后改为按 leaveId 精确查询（LeaveDetailView 的 ve()）：
s.listType==="apply" && (d.leaveId = s.data.id, n = await Ft(d))
c.value = { ...n }
"cancellation-apply-in-area": c.value?.cancellationApplyInArea === true
|| c.value?.cancellationApplyInArea === "是"
其中 Ft 即 studentForm 的 he → GET /leave/student_action/leave_detail。
改动：
- 新增 XsgzFetchLeaveDetail（GET leave_detail?leaveId=...，code!=0 报错）；
- recordRequiresInArea 改为「详情优先、列表回退、都失败则保守 false」，
既消除分页隐患，也保留对详情接口异常的容错。
测试：详情接口路径与参数名、bool true / 字符串「是」两种标记解析、
非 0 code 必须报错（不能静默当成空详情）。
2026-10-17 18:20:28 +08:00
ab4f29a474
销假范围强制校验对齐前端：读 cancellationApplyInArea 决定是否拦截
...
上一版（355557b）算出 inArea 就上报，但没有判断「该校是否要求在范围内」，
等于把前端的一道拦截丢了。前端源码（LeaveDetailView-BveoXCrD.js）：
const v = computed(() => a.actionType==="CANCELAPPLY" && a.cancellationApplyInArea)
if (v.value && !T?.canPosition) { warning("不在销假申请范围内，无法销假"); return }
该标记的来源也一并核实（同文件传入 StudentActionDialog 的 props）：
"application-id": c.value?.id || s.data?.id
"project-id": c.value?.project?.id || c.value?.projectId
"cancellation-apply-in-area":
c.value?.cancellationApplyInArea === true
|| c.value?.cancellationApplyInArea === "是"
顺带确认了 originalId 与 projectId 的取值与我们现有实现一致
（ToLeaveItems 的 ID=r.ID、TypeWid=r.ProjectID）。
改动：
- XsgzLeaveRecord 增加 CancellationApplyInArea（用 interface{} 兼容
bool 与 "是" 两种返回），并加 RequiresInArea() 做等价归一化；
- 新增 recordRequiresInArea：后端自行重查记录判定，不复用前端传值
（可篡改、且可能未传）；查不到时保守返回 false，不额外拦截；
- 销假流程改为：该校要求范围内且实际不在范围内 → 明确报错并拒绝提交，
与前端一致；未配置范围时 inArea 视为 true。
测试：RequiresInArea 覆盖 bool true/false、"是"/"否"、"true" 字符串、
nil、数字等输入。
2026-10-17 18:19:27 +08:00
355557b6ce
销假补上地理范围校验：inArea 此前恒为 false，学校端可能直接拒绝
...
从 sdau 线上源码（LeaveDetailView-BveoXCrD.js）拿到销假提交的真实实现：
const W = _e(r.value, I.value), // 构造 fields
H = { originalId: a.applicationId, projectId: a.projectId,
requestType: "CANCELLATION", fields: W,
cancellationApplyInArea: a.cancellationApplyInArea,
inArea: T?.canPosition || !1 , // ← 客户端地理围栏计算结果
address, longitude, latitude },
z = he(H, M.value), B = await Te(z)
前端还有一道硬拦截：
const v = computed(() => a.actionType==="CANCELAPPLY" && a.cancellationApplyInArea)
if (v.value && !T?.canPosition) { warning("不在销假申请范围内，无法销假"); return }
而我们的实现里 XsgzSubmitPayload.InArea 从未被赋值，销假请求恒传
inArea=false。若该校 cancellationApplyInArea=true，前端不会提交的请求
我们会照发，结果被学校端拒绝，用户只看到含糊的失败。
新增（均对齐前端）：
- XsgzFetchLocationRange：GET /api/leave/student_action/location_range
（前端 ve/bt，路径由源码核实）
- InLocationRange：复刻前端 c() 的围栏判断——Circle/poi 比球面距离，
Polygon/Rectangle 走射线法点在多边形内；范围为空时返回 true
（对应前端 !r.value.length 时 return true）
- 销假流程先拉范围再算 inArea；范围查询失败或无有效坐标时按不限制处理
并记日志，不让本校未配置范围的情况把功能卡死
复用 task.go 已有的 haversineMeters（注意其签名是 lat1,lon1,lat2,lon2），
未重复造轮子。
测试覆盖：空范围、圆形半径内外、poi、多边形内外、矩形、多范围任一命中、
退化多边形（<3 点）。
2026-10-17 18:18:09 +08:00
568329890b
回退 f1f79df：抓取线上前端源码证实数组下标确为方括号 fields[0]
...
上一版 f1f79df
2026-10-17 18:15:35 +08:00
f1f79dfb6c
修正 xsgz 表单数组下标：fields[0] 改为 fields.0，与 needCurlyBraces=false 语义一致
...
新增的 httptest 端到端契约测试（真发 multipart，假服务器接收）发现：
xsgzFlatten 对数组用 fmt.Sprintf("%s[%d]")，实际提交键为 fields[0].value，
而同一函数的注释、XsgzSubmitApplication 注释、以及 07b0cfa
2026-10-17 18:12:53 +08:00
00bd63cfdf
修复销假/请假 SSE 崩溃：stream writer 内误用已回收的 fasthttp RequestCtx
...
线上 v1.2.158 销假必崩，前端显示「连接失败，请检查网络」，用户误判为网络问题。
根因（162 服务器日志实证）：
SetBodyStreamWriter 的回调运行在 fasthttp 的独立写协程中，此时 *RequestCtx
已被归还复用。回调内调用 newXsgzSession(c.Context(), ...) 把该 ctx 交给
resty 的 SetContext，resty 内部走 context.WithDeadline → propagateCancel
→ parent.Done()，而 RequestCtx.Done() 直接解引用 ctx.s（server.go:2726）：
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV] fasthttp.(*RequestCtx).Done server.go:2726
此时 s 已为 nil，触发 SIGSEGV。
panic 发生在协程里，fiber 的 recover 中间件捕获不到，直接杀死整个进程，
前端 XHR 连接被掐断 → 只剩「连接失败，请检查网络」这条误导性提示。
修复：
1. 新增 streamCtx()：返回 context.WithTimeout(Background, 3min)，
脱离请求生命周期，回调内一律使用它（销假与请假两条链路）；
2. 两个回调都加 recover 兜底，即便再出现协程内 panic 也只返回
task_error 事件，不会拖垮进程。
回归测试：TestStreamCtxIsUsable 保证 ctx 具备 Done/deadline；
TestRequestCtxDonePanicsAfterReset 用零值 RequestCtx 固化崩溃机制，
解释为什么不能用 c.Context()。
2026-10-17 18:07:34 +08:00
e7c9b06056
xsgz 提交前预检必填字段，避免含糊失败
...
学校请假表单由后台动态配置，可能包含本平台无法提供值的必填字段
（如"是否离校"单选、请假类型细分下拉）。原先这类情况会直接提交，
由学校端返回业务错误，用户看到的提示不明确。
新增 checkXsgzUnfilledRequired：提交前检查所有 required 字段是否已有值
（空串/null 均视为缺失），有缺失则不发请求，直接提示
「该校请假表单还有必填项无法自动填写：X、Y，请前往学校学工系统办理」，
并写入日志。请假与销假两条路径都已接入。
新增 5 个单测覆盖：有值不报、无值报字段名、空串算缺失、
无 fieldName 回退 fieldId、非必填不报。
2026-10-17 17:46:49 +08:00
c8ff086b7b
xsgz 请假字段填充改为「标签匹配 + 必填文本兜底」，降低对字段命名的依赖
...
从 transformFields-D3I9yUm6.js 反推出 form_fields_for_add 的真实结构：
{ fieldId, fieldName, componentType, fieldType, required, options[] }
前端 transformFields 把它转成 fieldEn=fieldId / fieldZh=fieldName 后提交，
且请假原因并非硬编码字段，而是学校后台动态配置的。
原先只按「原因/事由」关键词填值，若学校把字段命名为"申请理由说明"
"补充信息"等就会漏填，导致学校端校验失败。
改为两轮策略：
1. 优先按标签命中（原因/事由/说明）；
2. 未命中时，用「必填的文本类字段」（TEXT/TEXTAREA/LONGTEXT）兜底填入请假原因。
该校表单通常只有一个原因字段，兜底可覆盖自定义命名；
选择类字段（RADIO/CHECKBOX 等）不猜测，留空由学校端校验。
新增 4 个单测覆盖：关键词命中、自定义命名、兜底逻辑、空输入不 panic。
2026-10-17 17:45:12 +08:00
07b0cfaa88
校正 sdau 提交参数序列化，严格对齐前端 toFormatFormData
...
ci/woodpecker/tag/build Pipeline was successful
重新核对前端源码发现两处与实现不符，已修正：
1. FormData 序列化格式
前端 toFormatFormData(T, needCurlyBraces=false) 的规则是：
- 嵌套/数组用**点号**展开（fields.0.value），不是方括号；
- 值为 null 或空字符串时**跳过**该键；
- 数组按下标逐个展开。
原实现把 fields 整个 JSON.stringify 成一个字符串，与前端不一致。
新增 xsgzFlatten 按上述规则摊平，并加单测覆盖（点号/跳过空值/数组下标）。
2. fields 内容必须是「字段定义 + 用户填值」
前端提交前会 forEach 把用户输入写回各字段的 value：
f.value.forEach(l => { l.value = t[l.fieldId] ... })
原实现只提交了空的字段定义。
现在先拉 form_fields_for_add，再 fillXsgzFieldValues 把请假原因等
按字段标签（含"原因/事由"）回填到 value；销假同理（含"说明/原因"）。
参数契约已逐项比对（源码原文 vs 实现）：
请假：{projectId, requestType:"LEAVE", startTime, endTime,
fields[], address, longitude, latitude}
销假：{originalId, projectId, requestType:"CANCELLATION", fields[],
cancellationApplyInArea, inArea, address, longitude, latitude}
2026-10-17 17:43:31 +08:00
4a064b53cc
sdau 销假接口实现：与请假共用 application_submit，靠 requestType 区分
...
静态分析定位到请假详情页组件链（views/leave/detail/）：
ActionPopup-CRBsBafz.js 中 handleType=CANCELAPPLY 的销假申请逻辑，
其提交函数 re 从 fieldsConfig-BzLAymBp.js 导入，即与请假同一个
application_submit 接口。
销假 payload（requestType=CANCELLATION）：
{ originalId: <原假单ID>, projectId, requestType:"CANCELLATION",
fields[], cancellationApplyInArea, inArea, address, longitude, latitude }
改动：
- service：新增 XsgzSubmitCancel / XsgzSubmitApplication（请假/销假/续假共用），
XsgzSubmitPayload 增加 originalId/inArea/cancellationApplyInArea
- service：XsgzLeaveRecord 增加 projectId 字段；ToLeaveItems 把 projectId
写入 TypeWid，供前端销假时回传
- handler：新增 executeXsgzLeaveCancel，SSE 事件流 + 落日志
- handler：ExecuteLeaveRequest 增加 projectId
- 前端：ExecuteLeaveParams 增加 projectId；销假提交时回传 typeWid
另：batch-cancel / batch-cancel-list 经确认是辅导员侧接口，学生销假不走它们。
2026-10-17 17:40:16 +08:00
becomer