RinCore v5.3.41

RinCore v5.3.41

★★文档与工具批次：溯源体系 / 结构总图 / 开工状态 + 工作流整顿（发布链本身是本轮验证对象）📐这一版没有改任何功能代码 —— 它是前面几轮「把项目理清楚」的沉淀落地，同时用一次真实发版来验证新工作流程是否可靠。 ━━ 一、本版带上的三份文档（此前只在 adopt 分支，未进 main）━━ | 文档 | 内容 | |---|---| | FILE-ORIGIN.md + .json（+ 工具 bin/origin） | 全量文件来源溯源：1353 个 .kt 中 UPSTREAM 778(57.5%) 与 3.1.0 逐字节一致 / MODIFIED 231 / PORTED 200 / PORTED-MODIFIED 67 / OURS 56 / DELETED 21。11 个命令：stats/modules/of/diff/restore/lost/untouched/ours/modified/ported/audit | | STRUCTURE-MAP.md（+ bin/symbols、bin/deps） | 四层索引：文件级（谁的文件）/ 符号级（26575 个符号，改动风险最高的是 UIMessagePart 140 文件、UIMessage 102、SettingsStore 84）/ 模块级（无循环依赖，app 唯一顶层，highlight/document/material3/oauth 是零跨模块依赖的叶子）/ 孤立声明初筛 | | CODE-NAVIGATION.md + EXTENSION-POINTS.md | 按「我要改 X」组织的导航（53 个路径引用逐条脚本验证，0 缺失）+ 加工具/渲染器/区/Provider/设置项/记忆档/路由的改法与必踩坑 | | 开工状态-2026-11-04.md | 下批次开工快照（版本/环境/工具链/代码画像/待办/六条纪律） | ━━ 二、工作流整顿（这才是本轮真正想验证的东西）━━ ① bin/watch —— 唯一 CI 查询入口：watch（最近 run + 自动比对是否就是本地 HEAD）/ watch <runId>（阻塞到终态，绿/红自带摘要，退出码 0/1）/ watch <sha>（按 commit 找 run 再等）。② bin/selfcheck —— 检查器自检（14 项探针）：用已知坏样本喂每个检查器，确认它真会报错（含对照：正常文件不得误报、假 sha 必须失败、watch 必须秒回）。「基线全绿」不等于「没问题」 —— 如果检查器本身失灵，全绿是假的。③ rc release 修掉一个真实隐患：旧流程是 sleep 20 后取最近一个 run 且不校验 sha —— 新 run 还没创建时会等到上一个 commit 的 run 并判定 CI-GREEN，最终表现「CI 绿了但 release 没出来」，失败点离真因很远。现改为 run_for_sha(head_sha) 定位 + wait 内二次校验 head_sha。④ 两份 AGENTS.md（工作区根 + 仓库根）：把「等 CI 只用 watch」「发版前先 selfcheck 再 audit」「验收看退出码不看输出文字」写进每次会话都会读到的位置 —— 之前这些规则写在 bin/README.md，而我不总会去翻它。━━ 三、本版确认的健康项 ━━ selfcheck 14/14；doctor 14 通过 / 0 警告 / 0 失败；audit fast AUDIT-OK；origin 1353 个 .kt；symbols 26575 个符号；deps cycles 无循环依赖；APK 79.7MB（上一版已从 85.1MB 降下来）。━━ 四、诚实边界 ━━ ①本版零功能改动 —— 全部是文档 + 工作区工具（bin/ 不随 APK 发布），所以"功能变化"这一栏是空的；②bin/ 里的工具是我的工作环境，不在仓库里、不随 APK 分发，所以这版 APK 与 v5.3.40 在功能上完全一致；③无安装实测（沙箱无设备）；④工作区仍有 archive/ 833M（旧 APK 对照基准）与 _trash/ 435M（proot 权限受限，删不掉）未处理。 ★版本纪律：5.3.40 → 5.3.41（只改第三位、不进位）。★待你验证：本版功能应与 v5.3.40 完全一致 —— 如果你只是为了新功能，可以从 5.3.40 直接跳到下一版；这一版的价值在于把「代码库为什么乱、乱在哪、怎么迁移」变成了可查询的事实。 ⑩hub=v5.3.41

本次提交

• d730c36 docs: 下批次开工状态快照 + 环境整理
• 892ed07 docs: 结构总图 + 引用关系层（deps / symbols hot,dead）
• b4c844a release: v5.3.40 — ★★性能（零功能变更，-6.58MB）+ 代码结构化（26575 个符号可检索）📐这一轮先说一件可能不像「优化」但更诚实的事：我把标准性能热点逐项实测排除了。 ━━ 一、被实测排除的方向（避免做无用功）━━ | 方向 | 实测结果 | 结论 | |---|---|---| | 函数内正则 | 145 处 Regex(，131 已在 val；HardlineCommandGuard 的 13 个安全正则已是 private val PATTERNS | 只剩 14 处低频，收益可忽略 | | SimpleDateFormat | 16 处全在低频页面（设置/日志/错误卡片），LogPage 3 处已 remember | 不在热路径 | | LazyColumn 无 key | ChatList 主列表两处都有 key + contentType；抽屉/模型列表/工具矩阵也都有 | 已是最佳实践 | | Markdown 解析 | 已是增量解析（块级 O(δ)）+ 字符预算 LRU + 跨 tick 节点复用 + 避免全量回退（v4.8.86 深度优化） | 无空间 | | Compose 内集合运算 | message 组件 7 处，但都是小集合 | 收益 < 风险 | 结论：所谓「Compose 性能十大坑」，这个项目基本都填过了。 在没有 profiling 数据的情况下改这些，是引入风险而不是优化 —— 我没做。 ━━ 二、真正的收益：死资源（可量化、零功能变更）━━ assets/ 曾占 60MB（APK 总共才 85MB）。逐个核对引用方后： | 资源 | 体积 | 判定依据 | |---|---|---| | assets/banner/ | 5.10MB | Kotlin/XML/Manifest 零引用；真实上游 3.1.1 已删除该目录 | | assets/models_dev.json | 1.48MB | ModelsDevCatalog.decode() 零调用方 —— v5.3.1 只移植了目录类与数据，依赖 ModelRegistry 重构的 ModelsDevUpdater 从未移植 | | patreon.xml | 小 | 赞助功能已删（v5.0.52），零引用 | | ic_media_creation.xml | 小 | 零引用 | 合计 6.58MB，assets/ 60MB → 54MB。 逐个确认过是活的、保留的：rin-tools/ 33.3MB（officecli 文档工具，你日常在用）、simple_dict/ 13.1MB（SimpleDictManager.extractDict() 被 AppDatabaseFactory:55 调用，FTS 分词必需）、html/ 4.2MB（mark.html + mermaid，v5.3.17 刚做过 CDN 本地化）。 为什么这算「性能」而不是「清理」：APK 体积直接影响安装时间、升级下载量、冷启动资源扫描；在「功能零变更」这条硬约束下，它是唯一可量化的收益。 ━━ 三、代码结构化：从「1353 个文件」到「26575 个可检索符号」━━ 三层索引（文件级 → 符号级 → 导航级）： | 层 | 工具 | 回答什么 | |---|---|---| | 文件级 | bin/origin | 这文件是谁的（UPSTREAM/MODIFIED/PORTED/OURS）+ 能否安全回退 | | 符号级（本轮新增） | bin/symbols | 这个类/函数在哪、属于哪个类、谁在用 | | 导航级 | docs/CODE-NAVIGATION.md | 我要改 X，先看哪几个文件 | bin/symbols 实测： symbols build # 5 秒重建 → docs/SYMBOLS.tsv symbols find saveConversation symbols uses MemoryRepository symbols stats 输出： saveConversation fun ChatService. MODIFIED ChatService.kt:1704 26575 个符号 / 1262 个 .kt，71% 有明确所属类（其余是真正的顶层扩展函数，本来就没有所属类）。每个符号带来源分类（UPSTREAM 12899 / MODIFIED 7545 / PORTED 3659 / PORTED-MODIFIED 1942 / OURS 530）→ 改一个函数之前，先知道它是原版的还是我们写的。 输出是纯 TSV，可直接 grep/awk/sort，也能被任何工具消费 —— 这就是你要的「清晰文本集」的实际形态。 第一版只索引顶层声明，find saveConversation 返回「未找到」（业务方法几乎都是成员函数）→ 索引等于不可用；加「所属类」列后才有定位价值。 ━━ 四、bin/perfscan：把这轮的排查方法固化 ━━ perfscan # 全部 perfscan assets # 体积/死资源（最可量化） perfscan hot # 热路径模式 它是清单工具不是门禁（退出码恒 0）—— 每项都给出「为什么可疑」和「零变更的改法」，由人决定改不改。刻意不做「扫出 100 条就机械全改」，那只会制造风险。 ━━ 五、诚实边界 ━━ ①APK 实际减少需 CI 产物确认 —— 6.58MB 是资源原始体积，图片本就是压缩格式，接近 1:1 但非精确。②本轮没有做运行时性能优化，因为第二节的实测排除了所有标准热点；没有 profiling 数据时改 Compose 是碰运气。③无安装实测（沙箱无设备）。④ModelsDevCatalog 类保留（注释写明「要启用必须把 json 放回来」）—— 删类会让将来移植 ModelsDevUpdater 时重写解析层。 ━━ 六、下一步（有数据再做，不猜）━━ ①冷启动：adb shell am start -W 看 TotalTime；②重组计数：Layout Inspector 的 recomposition counts，只改数字异常高的组件；③滚动掉帧：adb shell dumpsys gfxinfo <pkg> framestats，看 janky frames 集中在哪个页面。 这三项数据拿到之前，任何「Compose 优化」都是猜。 ★版本纪律：5.3.39 → 5.3.40（只改第三位、不进位）。★改动：删 5 个死资源（assets/banner/ 3 图 + models_dev.json + 2 drawable）+ ModelsDevCatalog.kt 加注释；零 Kotlin 逻辑改动（功能绝对不变）。 ★待你验证：①APK 体积应从 85.09MB 降到 ~78.5MB；②启动、聊天、文档处理一切照旧（本轮没动任何逻辑）；③bin/symbols find <任意函数名> 应能直接定位到文件与所属类。 ⑩hub=v5.3.40
• b476aff docs: 建立文件来源溯源体系（FILE-ORIGIN / CODE-NAVIGATION / EXTENSION-POINTS）
• 77da277 chore(workflow): 工作流整顿 — AGENTS.md 追加 RinCore 硬规则（等 CI 只走 watch / 发版前三检查 / 验收看退出码）
• f47ae9e release: v5.3.39 — ★★★稳定性复查 + 清历史欠账：基线全绿之下，修掉两项真问题与两处腐化 📋这次不是救火 —— 复查前 bin/audit 五组就已经全绿了。 ━━ 复查前基线（先证明「没有硬问题」）━━ | 检查项 | 结果 | |---|---| | bin/audit 五组 | AUDIT-OK | | doctor | 14 通过 / 0 警告 / 0 失败 | | rc check --all | PASS | | 接线审计（wire_audit） | 0 处断线 | | 健康审计（737 文件） | MAINIO 0 / COMPOSE-IO 0 | | WebView 渲染（26 项） | 全过 | | 单测白名单硬门禁 | 4 个测试类成功 | 没有「编译不过 / 接线断裂 / 主线程 IO / 渲染回归」这类硬问题。所以这轮做的是清历史欠账，不是补窟窿。 ━━ 一、修掉的真问题（2 项）━━ ① I-12（本轮新发现）：SubAgentRegistry 在 Koin 构造里做全表 DB 读。AppModule.kt:153 是 .also { it.restoreFromDisk() } —— Koin 单例首次注入时执行，而它内部 runBlocking { dao.getAll() } + 逐条 upsert。而首次注入点通常在 UI 侧（LocalTools 需要它）→ 冷启动后第一次打开对话可能卡在 DB 全表读上（子代理运行记录越多越明显）。 修：RikkaHubApp 启动的 IO 阶段主动 get<SubAgentRegistry>() —— 构造与恢复都在后台线程完成，之后 UI 再取时直接命中已初始化实例。语义零变化，只是把它提前到后台。 ② I-4：MemoryFileDAO.updateContentAny 死方法。v5.3.19 之后 update() 已用多形态匹配 + 迁移，它再没有被任何代码调用。删掉（含 FakeMemoryDAO 的 override），全库 0 处。 ━━ 二、修掉的两处腐化（不报错，但会误导下一轮排查）━━ ① ChatRequestFactory.kt:20 的死 import —— v5.3.22 删除旧 buildMemoryPrompt(List<AssistantMemory>) 重载时漏清。 ② MemoryFile.kt:192 的过期注释 —— 仍写着「让生成链的既有 buildMemoryPrompt(List<AssistantMemory>) 无需改动」，而那个重载早在 v5.3.22 就物理删除了。改为写明「唯一入口是 buildMemoryPrompt(List<MemoryFile>)，旧重载已删」。 为什么把注释当 bug 修：v5.3.32 抓到过一处更恶劣的同族问题 —— lastWarmAtMs[host] 的注释白纸黑字写「v5.1.12 真 bug 修复」，但代码那一行根本没动，导致后续每一轮排查都跳过它。注释腐化会主动制造「已验证」的假信号，比没有注释更危险。 ━━ 三、I-11 那四条「疑似实现回归」——我核查了，但没改（理由很重要）━━ | 测试 | 判定 | |---|---| | delete checks the version and removes the file | 测试过期 —— v5.3.19 把 deleteFile 改成软删（写 invalidated_at），物理删除走 purgeFile；软删是有意为之（可恢复/可追溯） | | changing scope of a truly missing path reports false | 测试过期 —— updateScope 已返真实行数，旧实现恒 true | | invalidating a missing path reports false | 理论上应为 false（六形态匹配全部落空 → rows > 0 为假），需实测确认 | | MemoryFileTest > keys without an input field | 疑似误标 —— editableKeys = {name,title,description,aliases}，source 不在其中，所以 source: import 会被保留，这条本应通过 | 为什么没改写断言：沙箱无 Android SDK、无 SnakeYAML 运行时 → 实跑不了。在无法实测的前提下改断言，等于用猜测制造假绿，风险远高于保留 @Ignore（至少它诚实地标记着「这条不覆盖当前行为」）。已把上述判定逐条写进 KNOWN-ISSUES 与报告，下一轮有 CI/真机环境时按此落地。 ━━ 四、⋆ 本轮新增的一条方法论（第十六个方向）━━ 「基线全绿」不等于「没问题」 —— 静态检查能覆盖的是模式（锁内挂起 / 主线程 IO / 接线断线 / 渲染回归），覆盖不了这三类： · 没人调用但存在的代码（I-4 死方法） · 注释在说谎（本轮两处） · 测试过期（I-11 三条） 这三类只能靠人工逐条对账（打开清单，一项一项追到实现）。所以「体检全绿」之后仍然有活可干，而且这些活的共同特征是：不修不会立刻坏，但会一点点把后来的人（包括我）引到错的方向。 ━━ 五、诚实边界 ━━ ①无安装实测 —— SubAgentRegistry 预热的效果（冷启动首次打开对话是否更快）需真机确认；逻辑上它把 runBlocking 从主线程移出，结构是正确的。 ②I-11 四条未落地（理由见第三节）。 ③archive/ 833M 与 _trash/ 435M 未删 —— 属你的资产/确认项，不擅自动。 ④本轮未引入任何新功能，严格限定在「稳定性 + 死代码 + 文档」。 ━━ 六、交付的文档与记录 ━━ · docs/稳定性复查-v5.3.39.md（新增，70 行）—— 基线表格 / OPEN 盘点 / I-11 核查结论 / 逐条改动理由 / 诚实边界 · docs/KNOWN-ISSUES.md（97 行）—— I-4 移出 OPEN 并进 CLOSED；新增 I-12（已修）；新增「v5.3.39 关闭条目」整节（含「注释腐化是 bug 源」教训）；OPEN 从 9 条收敛到 8 条，每条都写明「为什么不修」 · docs/RINCORE-经验教训库.md（327 行）—— 追加 v5.3.39 整节（4 条新教训） · docs/README.md —— 新报告进索引 · git：改动已 commit 并推 adopt-3.0.0 与 main ★版本纪律：5.3.38 → 5.3.39（只改第三位、不进位）。★改动 5 文件：RikkaHubApp.kt（SubAgentRegistry IO 预热）/ MemoryFileDAO.kt + FakeMemoryDAO.kt（删死方法）/ ChatRequestFactory.kt（删死 import）/ MemoryFile.kt（修过期注释）。 ★待你验证：①冷启动后第一次打开对话，是否比之前更顺（子代理记录多的账号更明显）；②子代理的历史运行记录仍能正常显示（预热只改线程，不改数据）；③其余一切应与 v5.3.38 完全一致（本轮没有功能改动）。 ⑩hub=v5.3.39

构建：gate（编译+测试）→ build（assembleRelease）→ 正式版 Release