tokenOwner 把令牌放在 URL query 参数里（?access_token=…）。query 参数会进入 HTTP 访问日志 / 反向代理日志，属于公认的凭据泄露反模式；gitcode v5 API 本身支持 Authorization: Bearer <token> 头（本仓库自身工具链也是这么调的）。建议改走 header 传令牌，避免令牌被日志侧录走。

兜底表达式 sanitize(cfg) ?? { address: cfg.address.trim() } 有隐患：sanitize 只在 address 为空/非字符串时返回 null，此时兜底会写一个只有（空）address 的文件，并静默丢掉 branch / directory / lfs。当前 PUT 路由已先拦空地址，但这是导出函数，任何未来调用方传入脏 address 都会得到「字段被悄悄丢弃」而非报错。建议改成显式抛错（或归一化后再写），避免静默丢字段。

if (!cfgRes.ok) throw new Error(...) 在 try/catch 之外：handleSave 由 onClick 直接调用（未 await 的 async 函数），这里的 throw 会变成 unhandled promise rejection——setError 不会触发，弹窗零反馈，用户只看到「连接数据仓」按钮点了没反应。unconfigured 首次配置路径很容易踩到：地址含 FORBIDDEN_ADDRESS_CHARS（引号/$/;/&/|，例如从文档粘贴的带弯引号 URL）时 PUT 返回 400，静默失败；cfgRes.json() 在非 JSON 错误响应上同样裸抛。建议把这段落进下方 try/catch（或单独 catch 后 setError 再 return）。

loadLakeConfig() 只读新键 cannbot-insight-lake-config，但存量用户的偏好存在旧键 cannbot-insight-cannbay-config（上一版 saveCannbayConfig 写入）——PR 描述与文件头注释声称的「localStorage 降级为存量预填源（保存即迁移）」实际不会发生：升级用户打开设置页表单为空，地址/分支/目录需要全部重填（服务端 lake-config.json 此时还不存在，没有别的迁移源）。clearLakeConfig() 也只清新键，旧键永久残留，与「清旧键防复活」的注释不符。建议 loadLakeConfig 新键 miss 后回落读旧键，clearLakeConfig 同时移除两个键。

嵌套 rootDir 兜底分支把 baseline 硬编码为 false：nestedRe 的 (baseline\/)? 可选组能匹配 <rootDir>/baseline/<sid>/，但命中后 push 的 loc 是 { root: rootDir, baseline: false }——locationPath 解析成 <rootDir>/<sid>/（错误位置）。后果：materializeSession 对该会话报「Session folder not found in lake」，uploadFolder 的 staleLocs 清理也指向错误路径。旧版单根路径对 <rootDir>/baseline/<sid>/ 与普通位都正确识别（rootDir 不含 / 时走多根正则同样正确），这是嵌套 directory + baseline 组合的回归。建议按 rootLevel/rootBaseline 同款方式分别判定两种形态，或循环里记录 m[2] 是否命中 baseline 段。