b2894lxlx/tuanwei-java
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
68 Commits 1 Branch 0 Tags
76c9edd4be2d1b7961fea42bd0e5a31e120adfd8
Commit Graph

68 Commits

This Branch
This Branch
All Branches
Author SHA1 Message Date
weicw 76c9edd4be feat(file): 上传准入白名单 + 素材媒体大类筛选 
素材库要从「只传图片」放开到文档与音视频，后端必须先有一道类型防线：
/api/file/upload 此前对文件类型零校验，任意文件都能落到公开可读目录。

- UploadRules：image/* 按探测 MIME 放行（历史头像/图标格式多，不做后缀白名单）；
  其余按后缀白名单（pdf/doc/docx/xls/xlsx/ppt/pptx/txt/md/csv、
  mp3/wav/m4a/aac、mp4/mov/webm），再用危险 MIME 黑名单兜住 exe 改名。
  不用「扩展名必须等于探测类型」的严格比对：docx/xlsx/pptx 经 Tika 常得到
  application/zip，md/csv 得到 text/plain，严格比对会误杀正常办公文档。
- FileStorageService.store 落盘后校验，本地分支失败删除刚写的文件，不留孤儿。
- FileController 单独捕获 UploadRejectedException，把原因原样回给前端。
- FileRecordParam.mediaCategory + Mapper 展开成 image/video/audio/doc 四类条件：
  「文档」在 MIME 里没有统一前缀，只能落到 application/% | text/%。

设计取舍见 docs/adr/0004（本仓库外，tuanwei-home）。
 2026-11-01 21:03:56 +08:00
weicw 9e88c53052 fix: 数据源会话时区强制 +08:00，修复创建时间早 8 小时 
生产数据库容器（1Panel-mariadb-ZOpD）的 system_time_zone 是 UTC，而数据源 URL 写着

serverTimezone=Asia/Shanghai：JDBC 会话时区是 UTC、驱动却按 +08 解析服务端返回的字面量，

于是 timestamp 列（分类管理、文章、系统日志、审核流、AI 对话等）读出来整体早 8 小时。

数据源 URL 增加 connectionTimeZone=%2B08:00&forceConnectionTimeZoneToSession=true，

连接建立时把会话时区设为 +08:00，与 JVM 默认时区、spring.jackson.time-zone 保持一致。

用偏移量而非命名时区，避免 MariaDB 容器未加载时区表时报 Unknown or incorrect time zone。

附 sql/20261026_timezone_8h_check.sql：部署后的时区自检、分类管理核对，

以及 datetime 列历史 UTC 字面量与教师建号行的时间回填模板（默认注释未执行）。
 2026-10-26 11:09:15 +08:00
weicw 0252672997 fix(ai): 短视频/图片产物归一并转存为对外地址（禅道 #1） 
- 归一按内容识别 video_result（此前只认图片）：地址字符串、markdown 链接、
  文件对象都统一成 {url,name,type:video}，端上四个页面才取得到播放地址，
  修复「上游接口已通、我方未输出视频、复制链接为空」；
- answer 不再残留裸地址：媒体地址命中时改写成「文件名 + 链接」，
  生成记录也补上媒体直链，纯视频分支不再因正文为空而整条不入库；
- 新增 CreativeMediaRelay：上游产物在内网，端上打不开，由后端下载、
  存入本项目文件存储，下发 /api/file 对外地址（Range 续传现成）；
  失败只降级保留原地址，不影响本次生成；
- FileStorageService.storeFile 支持把磁盘文件落入本地/对象存储；
- 开发环境关闭转存（公网 demo 地址本就可直接访问），生产默认开启。
 2026-10-25 15:55:49 +08:00
b2894lxlx 5626cdd679 fix: 申报可用时间按东八区判断，写入时显式使用北京时间 
避免容器 JVM/库会话仍为 UTC 时 createTime 偏 8 小时，以及 usable 查询把刚开放的申报滤掉。

Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-10-25 12:20:04 +08:00
weicw 0a2801850d fix(sync): 班级人数与辅导员不再被空值覆盖，人数按名册兜底 
开放平台对 2025 级起的班级不返回 BJRS，对 2026 级连 FDYH 都不返回，
而 batchUpsert 用 VALUES() 直写这两列，每晚同步都会把人工补录的辅导员和
学生人数刷成 NULL；新生班级的人数因此一直空着，班级管理页首屏（2026 级）
两列全空。

- ClassInfoMapper.xml: counselor_name / student_count 改为
  COALESCE(VALUES(x), x)，平台有值仍以平台为准，给空时保留存量
- 新增 refreshStudentCountFromRoster：学生同步结束时按 gxmu_student
  全量在册统计（不过滤 status，与平台 BJRS 口径一致）回填人数，
  只补「为空或 0」的班级，名册里没学生的班级不动
- StudentSyncHandler: 学生段写完后调用兜底

开发库已用同一语句回填 728 个班级。
 2026-10-24 20:41:35 +08:00
weicw 4c2a787d81 feat(ai): 写作/生图/创意/活动策划也保存历史记录 
- ai_chat_list 新增 chat_type / params，旧数据默认 chat
- 新增 AiGenerationRecorder：成功后同事务写 list + history，末帧回传 chatId
- 聊天改为成功收尾才建行，失败/中止不再留下空记录
- 写作（含自由创作）、生图、创意助手、活动策划四处接入，软失败与断流不入库
- 历史列表只取最近 30 条（SQL LIMIT），并强制按登录用户过滤
- 修复历史排序用了不存在的 sort_number 列（多行会 NPE）
- 新增 4 个测试类：记录器规则、排序回归、创意成功/软失败、30 条上限
 2026-10-24 17:37:39 +08:00
b2894lxlx d54f559d34 fix: 审核列表与申报可见性，并统一 Docker 北京时区 
修复团支部等角色待审漏数、PageParam 对 Collection 的 IN 条件失效，以及容器默认 UTC 导致时间偏移 8 小时的问题。

Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-10-24 14:55:11 +08:00
weicw-dshsa da5c5c1e09 fix(ai): SSE 帧优先投给在途流式请求，修「生成后按钮永久不可点」 
WebSocketServer.send 原本 WS 优先：只要同一账号还有 WS 会话（问答助手页会建
连接），文稿工作台那条 /stream 的帧就全被投到 WS 上，SSE 一帧收不到——正文只能
等末帧，收尾的 __END__ 永远不来，前端 loading 不复位，生成按钮卡死。

改为 SSE 优先：ChatStreamRegistry 是按请求登记的，登记期间发出的帧都属于那条
请求；没有在途请求时 emit 返回 false，照旧走 WS。握手回执「连接成功」改由
register() 直接写给该会话，避免被派发到别的请求。

测试：补两条回归（有在途 SSE 时即使 WS 在线也投 SSE；没有在途 SSE 时仍走 WS），
ai 包 158 条全绿。
 2026-10-23 12:57:03 +08:00
weicw-dshsa 206adbff6c chore(build): 项目 JDK 固定为 17，修正 .sdkmanrc 的过期结论 
原先钉的是 JDK 8，注释里写「lombok 1.18.20 不支持 JDK 17」。实测不成立：
JDK 17 下 `mvn -o clean compile` 与 158 条 ai 测试全绿；真正炸的是 JDK 21
（NoSuchFieldError: JCTree$JCImport does not have member field 'qualid'）。

本机 sdkman 全局默认已切到 21，所以按项目固定 17，不动 sdk default。
 2026-10-23 12:57:03 +08:00
weicw-dshsa 1ae2ab580d feat(manuscript): 稿件正文增加 content_format 格式标记 
- cms_manuscript 新增 content_format（html/markdown/text），默认 html
- Manuscript 实体加 contentFormat；保存与修改时缺省按 html 落库，下游不再靠猜
- 迁移脚本幂等，并把明显是 markdown 的历史行标出来
 2026-10-22 14:37:34 +08:00
weicw-dshsa f5a89634c4 feat(file): 文件存储接入 RustFS(S3)，修正文件外链域名与路径 
文件上传从本地磁盘改为可切换的对象存储（默认 s3，type 改回 local 即退回原行为）：

- 新增 common.core.storage 包：ObjectStorage 接口 + S3ObjectStorage(minio 8.5.17)
  + NoopObjectStorage + FileStorageService + StorageConfig + StoredFile；
  key 规则沿用 file/yyyyMMdd/uuid.ext、缩略图 file/thumbnail/...，桶内结构对齐旧磁盘目录
- 读取仍走后端代理 GET /api/file/**：s3 模式下首次读取物化到本地 cache-path 再返回，
  对外 URL 不变；历史本地文件一律作废，不做回退兼容
- ConfigProperties 增加 storage 配置块，endpoint/access-key/secret-key 支持环境变量覆盖
  （RUSTFS_ENDPOINT / RUSTFS_ACCESS_KEY / RUSTFS_SECRET_KEY），配置非法时启动即失败
- FileRecordService.deleteFileAsync 改为按 path 删除，本地与对象存储同时清理
- pom 固定 okhttp3.version=4.12.0、kotlin.version=1.9.25：Spring Boot 2.5.4 默认的
  okhttp 3.14.9 与 minio 所需的 okhttp 4.12.0 冲突，会导致启动即
  NoClassDefFoundError: okhttp3/ConnectionPool

同时修正文件外链拼接（以下均为改造前就存在的问题）：

- application-prod.yml：server-url / file-server 由失效的 tuanwei-api.gxwebsoft.com
  改为生产实际域名 https://twai-api.gxmu.edu.cn（与 admin .env.production、
  uniapp request.js 一致），此前上传返回的 url 指向旧域名导致访问不到
- FileController 抽出 fileBaseUrl()，分页/列表原来漏了 /api/file 前缀
- OpenFileController 同样补 /api/open/file 前缀
- TzbcyMaterialServiceImpl 下载链接补 /api/file/download
 2026-10-21 23:11:45 +08:00
weicw-dshsa bf6813e71d feat(ai): 聊天 WebSocket 加 /api 端点与心跳，WS 不可用时退到 HTTP SSE 
生产网关在 /api 前丢掉 Upgrade 头，wss://…/chat/{userId} 到不了后端，
端上一直卡在「正在建立 WebSocket 连接…」。

- 新增 ApiChatWebSocketServer（/api/chat/{userId}），与老端点共用会话表；
  会话表改存 Session 而不是端点实例，两条路径都能收到推送
- 登记会话时关闭空闲超时（Tomcat 默认 20s，AI 首字慢时会被掐断），
  并补 @OnMessage 丢弃心跳（缺了它容器会因不支持的文本帧直接断连）
- send() 找不到 WS 会话时改投 ChatStreamRegistry，把帧送到 HTTP SSE 连接，
  推送侧仍只有 sendMessage 一个入口，三千多次调用点不用改
- prod 放开 com.gxwebsoft.ai.config 到 INFO：只保留连接/断开，推送路径仍静默
- 补 ChatStreamRegistryTest / WebSocketEndpointPathTest / AiControllerSseFrameTest

顺带补上 31eb75c 漏加的 ChatStreamRegistry.java：AiController 已经 import 它，
缺文件时 HEAD 编译不过。
 2026-10-21 19:18:02 +08:00
weicw-dshsa 31eb75cdad fix(ai): 创意助手繁忙归类补 503/50508 与流式中断，失败日志保留尾部 
线上日志（2026-10-21 18:10/18:50）显示失败节点已从出图节点移到最前面的
「问题分类器」（SiliconFlow）：503 code 50508 System is too busy，以及
requests/urllib3 read_chunked 流式读取中断。旧归类只认 50500，用户看到的是
「生成失败」而不是「生成服务繁忙」；且 briefUpstreamError 只留头部，
Python traceback 的异常类型在尾部被截掉。

- isUpstreamCapacityFailure 增补 50508 / 503 / 流式中断等模式
- briefUpstreamError 改为头 2/3 + 标记 + 尾 1/3（仍单行、仍 <900 字符）
- buildCreativeAssistantResult 在成功但无可展示内容时记 WARN（含 outputKeys
  与 photo_files 条数），让解析兜底路径下一次可诊断
- 新增 AiCreativeBusyClassificationTest（6 条）

issue 19；不恢复自动重试。
 2026-10-21 19:09:03 +08:00
weicw-dshsa f4590001d8 feat(ai): 创意助手出图链路收口——去重试、图片模式包装提示词、输出形状兼容（issue 19） 
- 删除 CREATIVE_ASSISTANT_MAX_RETRY / executeCreativeAssistantWithRetry /
  isRetryableCreativeFailure，失败即失败；日志仍带 failedNode 与上游 error。
- 图片模式（mode=image）把 user_content 包装成「【任务类型】生成图片…」意图声明，
  避免上游「问题分类器」把画面描述判成文案/脚本分支；不带 mode 的入口保持原话直送。
- outputs 形状兼容：image7 这类数组里的 markdown 图片按内容归一到 photo_files
  （{url,name,type}），findTextValue 支持 List 中的图片字符串；raw 保持上游原样。
- 测试：新增 AiCreativeNoRetryIntegrationTest(2)、AiCreativeImagePromptTest(4)、
  AiCreativeImageOutputTest(5)，删除两个重试用例；全量 148 跑 0 failures。
 2026-10-21 15:42:54 +08:00
weicw-dshsa 42655ecd83 chore(build): 用 .sdkmanrc 固定 JDK 8 与 Maven 3.9.16 
父 POM 管的 lombok 1.18.20 不支持 JDK 17，而本机 sdkman 全局默认是 java 17.0.20-tem，编译必然失败。按项目固定工具链，不改 sdk default。
 2026-10-21 12:40:13 +08:00
weicw-dshsa aed2870b27 chore(dev): 开发环境 Dify 指向公网演示实例 
只覆盖 dify.base-url，dify.apps / dataset / workflows 仍取 application.yml 默认值，避免两份配置漂移。base-url 必须带 /v1（/v1/parameters 返回缺 Bearer 的 401 JSON，/parameters 返回控制台 404）。演示实例与内网实例共用同一批应用 Key 与知识库。
 2026-10-21 12:40:13 +08:00
weicw-dshsa 1b61fe5586 feat(ai): 自由模式转创意助手，失败日志补失败节点与上游 error（issue 17 / 18） 
自由模式（issue 18）：
- docType 为空时不调「内容创作与宣传助手」——它开始节点的 doc_type 是必填 select，
  空值直接被上游判 failed（error="doc_type is required in input form"）。改为转
  「AI 创意助手」，只发它唯一的必填入参 user_content。
- ManuscriptGenInputs 增加 userContent；doc_type / Number 仍无条件带键（空串能过
  Dify 的必填校验，缺键不行）。
- 用例：AiManuscriptFreeModeRouteTest、AiManuscriptInputsContractTest。

失败日志（issue 17）：
- 稿件流程、大纲流程、executeWorkflowForResult 三处失败日志补 status + failedNode +
  upstreamError + elapsed。失败信息拆在 node_finished 与 workflow_finished 两类事件，
  入参校验类失败只有后者，只取节点事件等于没取。
- 补 event=error 与「静默断流」（没有 workflow_finished / message_end）的日志，
  两者都带 taskId，可与请求对上。
- 日志级用 error 而非 warn：生产 com.gxwebsoft 只开 ERROR。
- 用例：AiWorkflowFailureDetailTest。
 2026-10-21 12:40:05 +08:00
weicw-dshsa 9e20014cd6 fix(cms): 分类写入前校验上级分类，拦截自引用与成环 
分类是自关联结构，一旦出现「自己指向自己」或「祖先指向后代」的环，前端构建分类树时
会直接抛错，导致整个页面无法渲染（报 data error: {categoryId: x, parentId: x}）。

- ArticleCategoryService 新增 checkParentValid：顶级分类放行；修改时沿父级链向上回溯，
  父级链中不允许出现自己；带回溯深度上限兜底，避免历史脏数据造成死循环。
- Controller 的保存与更新入口都调用该校验，不通过时抛 BusinessException（中文提示）。

注：本提交同时包含这三个文件的整体重新格式化（忽略空白后实际逻辑改动为 52 行插入）。
 2026-10-13 20:00:25 +08:00
weicw-dshsa 21e49c6a1a fix(ai): WebSocket 推送静默化，并补重试与静默推送用例（issue 11 / 12） 
- WebSocketServer.sendMessage 里两行 System.out.println 删除。该方法被**每个 SSE
  事件**调用一次（大纲单次生成实测 3062 个事件，即一次请求刷 6000+ 行），而且绕过
  日志框架——既不受 logging.level 控制（生产把 com.gxwebsoft 压到 ERROR 也拦不住），
  也不进日志文件，真故障时需要的几行会被顶掉。日志改到低频的 onOpen / onClose；
  同时把 onOpen 里静默吞掉的握手回应异常改成 WARN（那是「连上了却收不到内容」的
  第一现场）。
- 新增用例：AiCreativeRetryTest、AiCreativeRetryIntegrationTest（issue 11，
  后者用本地 HTTP server 扮演 Dify，断言瞬时故障确实重跑一次、凭证失效只请求一次）、
  WebSocketServerSilentPushTest（issue 12，捕获 System.out 断言推送路径零输出）。
 2026-10-13 20:00:01 +08:00
weicw-dshsa 8406c90cf3 fix(ai): 文件上传按应用选择凭证；并入创意助手重试与失败日志（issue 11 / 14） 
同一文件内包含两块内容，无法拆分提交：

一、文件上传按应用选择凭证（issue 14，本次）
    Dify 的 /files/upload 是按应用鉴权的：实测同一张图、同一个 end user 下，chat Key
    上传得到的 file id 喂给创意助手工作流的 file-list 变量，0.2 秒即报
    Invalid upload file；用 creativeAssistant Key 上传的同一文件则 succeeded。
    而原实现只有两个分支（type 为空/0 用 chat，否则用 manuscript），从不使用创意助手
    的 Key，因此任何喂给创意助手的附件都必然失败 —— views/gxmu/creativeAssistant 表单页
    用的是同一个接口，它的附件功能同样是坏的（既有缺陷）。
    新增 app 参数按应用代号取凭证（复用 DifyProperties.AppKeys#byCode），不传时保持既有
    行为；未知代号回退旧逻辑并打 WARN。新增 resolveUploadToken。

二、创意助手出图失败的重试与可观测（issue 11，前次会话已完成验收、此前未提交）
    executeCreativeAssistantWithRetry / runCreativeAssistantOnce / CreativeRun /
    CreativeApiFailureException / creativeFailureReason / creativeFailureAnswer /
    isUpstreamCapacityFailure / isRetryableCreativeFailure / briefUpstreamError：
    上游 50500 算力不足时自动重跑一次，凭证失效、模型停用等不重试；每次失败按 ERROR
    打结构化日志（含失败节点名与上游原文截断）。
 2026-10-13 19:57:41 +08:00
weicw-dshsa f54e28cffc fix(ai): 失败态在返回体里带 status=failed，前端才能区分失败文案与正文（issue 10） 
上游工作流 failed 时，后端把 reply 置为失败文案（"生成失败，请稍后重试"）
并照常走成功路径返回（HTTP 200 / code=0），而返回体里**没有 status**：

    data = {"answer":"生成失败，请稍后重试", "conversationId":"…", "messageId":"…"}

两端前端的 isFailedPayload（读 payload.status / payload.data.status）因此
永远落空，只能把失败文案当正文渲染（实测三个 admin 页面都会这样）。
修 issue 09 时上游每次都 failed，这条是必现的。

改动：
- buildManuscriptResult 增加 failed 参数（保留三参重载，等价 failed=false，
  以免破坏 issue 08 既有测试的调用形态），失败时 put("status","failed")。
- 新增 buildActivityOutlineResult（同构），activityOutlineGen 收尾改用之。
- 两个方法都在外层作用域记录 workflowFailed：失败分支里有 continue，
  不能用分支内的局部布尔。

刻意不改的东西：
- 失败仍走 HTTP 200 / code=0。改成 code!=0 会与既有约定冲突、影响所有调用方
  的 catch 分支，本条只加一个字段即可让两端现有判定生效。
- answer 键在失败态下依然存在（issue 08 契约），只是现在有了 status 可区分。

测试：新增 AiWorkflowFailureHttpStatusTest 8/8，含反向用例——
成功态**不得**带 status（否则 isFailedPayload 会误伤正常结果），
以及「成功态正文恰好是失败文案」时唯一判据是 status。
全量 210 跑 0 失败（2 个 ServerContainer not available 为预存问题）。

验证：用桩上游（probe/stub-dify-failure.py，回 workflow_finished{status:failed}）
起第二个后端实例，实测两条链路的返回体都带 status='failed' 且
answer 仍为可读文案，前端 isFailedPayload 判定为 true —— 全链路闭合。
 2026-10-13 02:12:46 +08:00
weicw-dshsa fbc9774e19 fix(ai): 大纲链路补齐上游必填变量，资金归一化为数值（issue 09） 
活动策划大纲当时必然失败，界面只显示「生成失败，请稍后重试」。
两条根因（单变量对照实测确证）：

1. Dify 开始节点 event_funding 是 number，而实体与两端前端都是字符串，
   小程序问答助手页默认值还是中文「待定」→ must be a valid number，0.2s 即 failed。
2. event_member / tel_people 是上游必填变量，实体里根本没有字段，从不发送
   → event_member is required in input form。

实施中发现的关键事实，推翻了 issue 初稿的一条建议：
「is required in input form」检查的是键是否存在，不是值是否非空 ——

  缺 event_member 键 / null  → failed: is required in input form
  "event_member": ""        → succeeded（4752 条 message）
  "event_funding": ""       → succeeded（7268 条 message）
  "event_funding": "待定"    → failed: must be a valid number

所以「干脆不发该字段」行不通（不发 = 报 required），正确做法是键始终下发、
值空串兜底。

改动：
- ActivityOutlineInputs 补 eventMember / peopleManage / telPeople 三字段
  （snake + 驼峰别名）；eventFunding 保持 String 承载用户原文。
- buildActivityOutlineInputs：6 个上游必填变量无条件占位（空值走空白转空串，
  不能给 null —— null 会被上游当缺失）；event_type / event_location /
  people_manage / event_meme 实测非必填，保持「为空不发」。
- 新增 normalizeEventFunding：抽出首个金额并归一化为 BigDecimal。
  两个必须先处理的坑，否则静默发出错误金额（比留空更糟）：
    · 日期：'2026年4月办活动，预算5000元' 的 2026 会被当金额 → 先剔除日期
    · 单位前空格：'预算 1 万元' 只认紧邻的「万」会抽成 1 元 → \s* 容忍
  另支持 万/亿/千/百 倍率与 '3万5千' 连续降序单位相加；抽不出即降级空串。
- 前置校验抽成 validateActivityOutline，只校验主题/受众/时间三项。
  刻意不校验另外三个上游必填项 —— 上游必填不等于用户必填，加校验会把两端
  默认入参挡在门外（改前端默认值为空串后，旧校验会直接返回
  'event_funding不能为空'，比原缺陷更糟）。
- buildLoadingText 加 120 字上限：agent_thought 的思维链实测可达数 KB，
  整段塞进 loading 气泡等于把思维链推给端上。
- 去掉 isDisplayableText 之后的恒假条件（空串已被排除），并注释说明
  reply.indexOf("") 恒为 0 会误判已存在，故两道判断都不能少。

配套前端：
- uniapp 问答助手页资金默认值 '待定' → ''（未提及 != 待定）
- admin 入参类型补注释与 3 个可选键

测试：新增 AiActivityOutlineContractTest 23/23，含「凡校验放行的入参必带上游
全部必填键」的不变量用例；AiManuscriptUuidLeakTest 增至 21 条，补 loading
长度上限与真实 message_end 形状。全量 202 跑 0 失败
（2 个 ServerContainer not available 为预存问题）。

验收：probe/outline-e2e.py 走真实后端，用两端前端默认入参与 issue 原文要求的
'待定' 一档，复刻 apiRequest 回落 + formatOutlineResult + parseAssistantContent
判定，29/29 PASS。
 2026-10-13 00:37:15 +08:00
weicw-dshsa a8c8dd8643 feat(dify): 全部迁移到内网实例，统一为单份配置 
VPN 打通后开发机可直连内网，原先「默认公网 + prod 覆盖内网」的双份配置
已无必要，且两套 Key/知识库 ID 完全不通用（实测互打一律 401），
留着只会造成误用。公网那套整体移除，回退到 git 历史取。

- application.yml：base-url 与 8 个应用 Key、全部知识库密钥/ID 改指内网；
  原默认值来自公网，其注释同步改写
- application-dev.yml / application-prod.yml：删除 dify 覆盖段。
  YAML map 是按键合并而非整体替换，保留一份与默认值相同的覆盖
  只会在将来漏改时混出「一半内网一半公网」的状态
- DifyProperties：默认 baseUrl 改内网，类注释同步

修复一个上线起就坏的接口：

- admin 端「竞赛历史」文档列表按 challenge-cup 取库，而该 ID
  b342f096-… 在**公网实例上也返回 404**（公网真实的挑战杯库是
  7c812029-…，从未登记），故该接口一直不可用。改指内网「竞赛案例」
  库（181d58e3-…，145 篇），实测已能列出文档。对外路径保持
  /challenge-cup/documents 不变，以免影响 admin 端调用

清理失效的工作流变量（内网实测已从开始节点移除）：

- document-process 的 query / pdf_url，declaration 的 parse_value。
  三者配置为空串以显式丢弃 —— 直接删行会退回「按原名透传」，
  反而把 pdfUrl / parseValue 这类驼峰名发给 Dify。实体字段保留，
  不破坏 /documentProcess/upload 的入参契约（pdfUrl 仍参与
  「必须提供文件或 pdfUrl」的校验，只是不再转发）
- 注：Dify 对多传变量静默忽略，故此前不报错、功能未受影响，
  属「看着对其实无效」的配置

测试：改断言为内网值，并新增「不残留任何公网配置」「失效变量必须
配成空串」等防回归用例；变异验证（base-url 改回公网 / 空串改回生效名）
确认用例有真实判别力。Dify 相关 44 例全绿。

Refs: .scratch/dify-probe/README.md, .scratch/ai-assistant/map.md
 2026-10-12 12:37:33 +08:00
weicw-dshsa a2a83f7d9e fix(ai): 稿件/大纲链路失败态不再把标识符当正文推给端上 
这三条路径在 workflow_finished 事件只 extractAnswer、从不读 status：
工作流失败时 outputs 为空、answer 可能被填成 workflow_run_id(UUID)，
原样下发等于把内部标识符当正文推给端上（issue 03）。

- activityOutlineGen：失败先判定，推「生成失败，请稍后重试」(reset=true)
  再正常收尾
- executeWorkflowForResult：同上；最终结果失败时只回 status + 可读文案，
  不带 outputs / raw
- manuscriptGen：自查发现该方法不走通用执行、自带一份缺口，一并补齐
- socket 发送器增加 reset 字段：端上收到后丢弃失败前已累积的半截内容
- 新增 AiWorkflowFailureStatusTest 10 例：锁定「失败判定先于取 answer」
  的顺序契约与顶层/嵌套 status、大小写空白、成功不误判等边界

Refs: .scratch/ai-assistant/issues/03-other-links-raw-payload-fallback.md
 2026-09-24 04:22:29 +08:00
weicw-dshsa c598d88506 test(ai): 补端到端形状契约用例 
把 buildCreativeAssistantResult 在失败态下的**真实产出**打成一行 JSON，
供 .scratch/ai-assistant/verify-frontend-e2e.js 当输入喂给前端真实渲染函数，
验证的是「后端真实产出 → 前端真实渲染」整条链路，而非两侧各自自测。

实测产出为 {"status":"failed","answer":"生成失败，请稍后重试"}，
不含 raw / workflow_id / req_id / 上游错误栈。

Refs: .scratch/ai-assistant/issues/01-creative-assistant-raw-json-bubble.md
 2026-09-24 03:51:49 +08:00
weicw-dshsa 23a7f001cc fix(ai): 创意生成工作流失败时不再把原始报文吐给用户 
Dify 以 workflow_finished + data.status=failed + outputs={} 收场时，后端只搬运
字段、从不读 status，把一个失败结果包成 success 下发，且把整包报文塞进 raw；
前端 formatCreativeResult 取不到业务字段就落到 text || stringifyUnknown(payload)，
整段原始 JSON（含 workflow_id / task_id / req_id 与上游错误栈）进了聊天气泡。

- 新增 workflowStatus / isWorkflowFailed：失败时只回 status + 可读 answer，
  不下发 outputs / raw，不携带上游错误文本
- executeCreativeAssistant 的 workflow_finished 分支先判失败，命中则直接返回，
  不再用流式片段或 taskId 覆盖失败文案
- 失败报文顶层 answer 是 workflow_run_id(UUID)，故失败文案用固定字符串，
  不取自 answer
- 新增 AiCreativeFailureResultTest：13 个用例，样本为 issue 原文的真实失败报文

Refs: .scratch/ai-assistant/issues/01-creative-assistant-raw-json-bubble.md
 2026-09-24 03:44:08 +08:00
weicw-dshsa cbbe3b87b4 修改端口号 2026-09-22 20:35:21 +08:00
weicw-dshsa 7a90d79352 修复统一身份认证登录：补回从未提交的 gxmu.auth 配置 
线上 /api/sso/login 报「学校统一身份认证未配置，请联系管理员」，
/api/sso/available 返回 false。根因不是代码，是配置：gxmu.auth 段
只存在于本地工作区，从未进入任何一次提交。

证据：git log -S GXMU_AUTH_APPID 只命中两处，都不是 application.yml ——
LyuapAuthClientIT 里硬编码的兜底值，以及 .scratch/student-sso/README.md
第 5.1 节那句「已写进 application.yml」。而 6f04a64（新增统一身份认证登录）
的 13 个文件全在 src/main/java 与 src/test，根本没碰 resources。

后果：GxmuAuthProperties.appId 默认为 null → available() 为 false →
login() 在凭据校验处直接抛异常，请求根本到不了认证平台。

之所以单测全绿而功能全废：SsoLoginServiceImplTest 把 GxmuAuthProperties
整个 mock 掉了（getAppId 固定返回 "gxmu-app"），这类测试永远发现不了
「yml 里没这一段」。Dify 那批配置当初踩的也是同一类坑。

- application.yml 补回 gxmu.auth 段：enabled/base-url/app-id/app-secret/
  timeout-ms/allow-unknown-user，与 openplat 凭证同样处理，默认值写入
  并保留 GXMU_AUTH_APPID / GXMU_AUTH_APPSECRET 环境变量覆盖
- 新增 GxmuAuthPropertiesBindingTest：照 DifyProdProfileBindingTest 的做法
  直接绑定 yml 断言，不启动容器、不依赖数据库与 Redis。四条用例先红后绿，
  最后一条是端到端语义 —— 配置齐备时 available() 必须为 true，而不只是
  「配置字段非空」

已联网验证（真实打到 cas.gxmu.edu.cn）：available 由 false 变 true；
不存在的学号返回平台业务码「学号不存在，请确认后重试」，证明 appid 与
secret 已被平台认下。

注：TestMain / WebSoftApplicationTests 两项失败为预先存在，
已用 git stash 在改动前复现同一错误（serverEndpointExporter 的
ServerContainer not available），与本次改动无关。
 2026-09-21 19:58:48 +08:00
weicw-dshsa 8c994d9ed2 Dify 配置外置并切至内网实例 
接口地址与各应用 API Key 原先硬编码在 AiController 与
KnowledgeBaseController 中，换环境要改代码、密钥还会散落在多处。
新增 DifyProperties 统一收敛到 dify 配置节点，并补上文档中缺失的
两个应用与知识库管理接口。

- 新增 DifyProperties，外置 base-url / 8 个应用 Key / 知识库密钥，
  默认值保持公网实例，本地开发不受影响
- 生产 profile 覆盖为内网 10.100.158.15，含全部 8 个应用 Key 与
  两个知识库的独立密钥
- 新增申报书生成、智能文档处理两个工作流接口（含文件上传版本），
  接入既有的 WebSocket 流式推送与停止机制
- KnowledgeBaseController 补齐知识库增删改查、文档管理与索引进度，
  并对文档状态动作加白名单，避免路径参数被任意拼接
- 修正 AI 内容创作的 number 变量名：Dify 侧为 Number，
  变量名大小写敏感，此前一直发送小写导致该功能缺参
- 生产下显式覆盖公网知识库 ID 的密钥：YAML 的 map 按键合并而非整体
  替换，不覆盖会残留指向公网实例的死密钥

工作流变量名取自内网实例实测（probe-dify.sh），其中申报书生成与
文档处理两组变量与公网命名习惯不一致，故以配置映射承载，改名只需
改 yml 而非改代码。

新增 18 项测试，覆盖配置绑定、profile 覆盖完整性（逐项断言 8 个
Key 均已覆盖且不残留公网 Key）与入参到 Dify inputs 的映射。
 2026-09-21 19:46:49 +08:00
weicw-dshsa 3e2d7b65a6 教师同步派生登录账号 
同步教师名册时，若存在手机号则建号：手机号即 username/phone，
后六位即密码，user_code 存教工号（这是与名册之间唯一稳定的反查键，
后台用户管理页改不了——手机号可改，用它反查会在改号后断链）。

推翻 ADR-0001 中「教师不建账号」的结论，见新增的 ADR-0008。
学生仍走认领，不受影响。

只建账号、不建角色：teacher 角色由运维在后台创建，代码查不到时
静默跳过。授角色逻辑同时挂在「新建」与「账号已存在」两个分支上，
因此运维建完角色后重跑一次同步即可给全部已有账号补齐。

停用冻结带 20% 比例护栏：全量同步若因平台异常拉回部分数据，
差集会把大批在职教师误判为消失。误停用名册是数据不准（可重跑），
误冻解是安全问题（离职教师仍能登录），两侧取舍不对称，宁可漏冻结。

开关 gxmu.openplat-sync.teacher-account.enabled 默认关闭。
 2026-09-19 20:39:13 +08:00
weicw-dshsa b6c392141e 学生认领新增按学号认领（不校验姓名） 
学号已在认证平台持密码验过，属可信来源，不必再用姓名二次校验
（名册姓名与平台姓名格式不一致时会误伤）。名册无此学号、已被他人
认领仍返回 false。
 2026-09-18 23:31:01 +08:00
weicw-dshsa 6f04a64084 新增学校统一身份认证登录 
- GxmuAuthProperties 承载接入配置，认证客户端按微服务认证平台 API v2.3 调 cas.gxmu.edu.cn
- /api/sso/login 与 /api/sso/available 免鉴权放行
- 校验通过后按学号认领学生，名册外的账号默认拒绝登录
 2026-09-18 23:31:00 +08:00
weicw-dshsa 45b7a42331 移除基础配置里冗余的 redis 连接项 
这些值与 Spring Boot 的默认值一致（127.0.0.1:6379 / db 0 / 空密码），
生产环境由 application-prod.yml 覆盖，删掉不改变行为。
 2026-09-15 17:21:35 +08:00
weicw-dshsa 853f3c3f5b 新增教师名册只读接口 
教师名册来自开放平台全量同步，只用于检索与选人（教师不建登录账号，ADR-0001），
因此不提供认领类接口，也没有可写字段。

- GET /api/gxmu/teacher/page：学院/教工号/姓名/状态筛选，默认只返回启用
- POST /api/gxmu/teacher/export：导出用列表，带操作日志
- 权限拆成 gxmu:teacher:list 与 gxmu:teacher:export
- 手机号按 spec §5.2 落盘但不进任何列表接口，返回前一律清空（hideSensitive）
- 菜单与按钮权限见 sql/20260915_add_teacher_roster_menu.sql，可重复执行
 2026-09-15 17:21:32 +08:00
weicw-dshsa 582d7dfbcb 学生同步稳态只写变更行 
实测写入才是大头，不是平台拉取：9.8 万行的表上 800 行/批 upsert 要 716ms，
123 批共 88 秒；而窄读全部 (xh, row_hash) 只要 2.1 秒。

做法：
- gxmu_student 增列 row_hash，存放「平台权威字段」的 MD5 指纹
  （迁移 sql/20260915_add_student_row_hash.sql，可重复执行）
- 同步时先窄读现有指纹，只 upsert 指纹变化的行
- 窄读同时服务于停用差集，省掉原先单独的一次 selectAllXh
- deactivateByXh 顺带把 row_hash 置空，保证停用行以后重新出现时一定被重新写入

指纹规则单独成类 StudentFingerprint：它必须与 mapper 的
ON DUPLICATE KEY UPDATE 子句严格对应——往 UPDATE 里加字段却忘了加进指纹，
那一列就会静默地不再更新，这类 bug 不报错、只产生过期数据。
因此附有逐字段的测试，并由 MapperFieldWhitelistTest 守住 UPDATE 子句本身。

附带收益：未变更的行不再刷新 update_time，该字段恢复「最后变更时间」的含义；
码表修正后 nation/politics 变化会触发自动重算，正是 ADR-0006 承诺的行为。

预期学生同步 170 秒 -> 约 85 秒，其中写库 88 秒 -> 约 2 秒。
现有 98187 行 row_hash 为空，部署后第一次仍会全量写一次。
离线单测 50 个。
 2026-09-15 16:14:05 +08:00
weicw-dshsa cd54039f28 接入医科大开放平台数据同步 
新增 com.gxwebsoft.gxmu.openplat：开放平台客户端（oauth 鉴权、token 缓存与失效
重取、分页拉取）、部门/教师/班级/学生四段同步、异步编排与手动同步接口、学生认领、
学生名册查询与导出、每天 03:30 的定时任务、同步记录。

关键设计：
- 名册与登录账号分离，学生通过「认领」（手机号自动 / 学号姓名自助）关联 sys_user
- 组织数据以 sys_organization 为唯一载体，gxmu_college 废弃
- 平台无可用增量字段，只做全量拉取 + 幂等 upsert
- 上游消失只停用不删除，且只作用于同步来源的记录（避免误停用人工维护的研究生班）
- 平台权威字段按白名单覆盖，人工字段不触碰
- 码表可配置并保留原始码，码值实测存在两套编码混用，不做硬编码
- 手动同步为异步：提交返回批次号，前端轮询 /status 看分段进度

性能：
- 班级/部门由逐条 update 改为多行 upsert，班级 1584 条 41s -> 0.19s
- 码表解析加进程内缓存，学生同步由 >17 分钟不完成 -> 170 秒完成 98187 行

迁移脚本需手动执行（可重复执行）：
  sql/20260912_create_openplat_sync_tables.sql
  sql/20260912_add_openplat_menu.sql

离线单测 43 个；另有联网集成测试 OpenPlatformClientIT（需 -Dopenplat.it=true）。
 2026-09-15 15:54:49 +08:00
b2894lxlx f379291e4f 260720 2026-07-20 11:48:06 +08:00
b2894lxlx 7119dc76a9 250826 2025-08-26 21:29:55 +08:00
b2894lxlx 1a35b30c7e 250522 2025-05-22 10:28:37 +08:00
b2894lxlx bfbde8a0f5 250522 2025-05-22 10:27:57 +08:00
b2894lxlx 9139457203 240401 2024-04-01 22:11:01 +08:00
gxwebsoft 1a47ed7630 新增配件管理模块 2024-02-27 20:45:12 +08:00
gxwebsoft 349ef16c20 新增配件管理模块 2024-02-27 20:29:16 +08:00
gxwebsoft 89bcd98570 完成保养记录和厂内维修模块 2024-02-25 19:33:40 +08:00
gxwebsoft 3c22a60a1c 完成安全维保管理模块 2024-02-25 15:23:54 +08:00
gxwebsoft d72849ad50 新增采购入库功能 2024-02-05 21:48:07 +08:00
gxwebsoft 20f190410c 新增标准节、优化设备统计 2024-02-05 15:54:54 +08:00
gxwebsoft 426d0a685a 合并代码 2024-02-03 16:42:16 +08:00
b2894lxlx bfefa9a787 调整 2024-01-31 14:55:59 +08:00
b2894lxlx 2fd8b3d341 调整 2024-01-31 14:54:49 +08:00