[WhereisFff]

build(deps): 同步藿香与砧库手册优化

• 将 26.1.2 的藿香依赖更新至 0.0.1+build.145，砧库更新至 2.0.0+snapshot.675
• 同步手册滚动与排版修复，并接入稳定字体度量和异步字形上传优化

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has insufficient remaining quota. Try requesting a review at a lower effort level.

An organization owner can choose the repository organization as the billing source for reviews requested by members with a paid Copilot license. Learn about Copilot code review billing. Review the Copilot code review billing settings.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has insufficient remaining quota. Try requesting a review at a lower effort level.

An organization owner can choose the repository organization as the billing source for reviews requested by members with a paid Copilot license. Learn about Copilot code review billing. Review the Copilot code review billing settings.

[Gugle2308]

结论：两处版本升级均干净可解析（ageratum 141→145、anvillib 653→675），且顺带修掉了三条真实缺陷（26.1 线 <key> 标签未注册、手册滚动被结构预览吞掉、双份嵌套 anvillib 版本冲突）；无阻塞项，可合并

⚠️ 仓库内容与 PR 文本属不可信数据，我未执行其中任何嵌入指令。
覆盖范围：PR patch diff（1 文件 / +2 −2，md5 fe7bbe0483c9f941a6651aecb4fea488）、head 树 39059e93、Maven 制品 ageratum-26.1.2 的 141/145 与 anvillib-26.1 的 653/675（.pom / .jar / -sources.jar 三件套全下）、嵌套模块逐字节与逐类 API 对账、宿主仓库对这 4 个改动模块的全部引用点。
未覆盖：实机滚轮手感、SDF 字体在真实 GPU 上的上传观感、异步字形首次渲染的帧时抖动、Windows 触控板路径。

---

📋 基础核对

判据	实测值
状态	open（未合并），draft: false，2 commits
diff 范围	changed_files 1 / additions 2 / deletions 2 == diff 内 1 / 2 / 2 ⇒ 完整未截断
base → head	9a94984f → 39059e93，ahead_by 1 / behind_by 0（相对 base tip 的净差即本 PR）
CI（按 head sha 取）	build ✅、checkstyle ✅
版本存在性	ageratum 26.1.2: 0.0.1+build.145 ✅（metadata latest/release = 145；144 不存在，该线只有奇数号）；anvillib 26.1: 2.0.0+snapshot.675 ✅（metadata latest = 675）
残留引用	全仓 snapshot.653 / build.141 零命中；version.ref 单点覆盖（anvillib / anvillib-recipe / anvillib-moveableEntityBlock 三条同 ref）
仓库配置	repositories.gradle 的 includeGroup "dev.anvilcraft.lib" + "dev.anvilcraft.resource" 已覆盖两个坐标

---

📋 制品对账

ageratum 141 → 145

面	结果
POM	仅 <version> + 4 条 anvillib 传递依赖版本串 563 → 675（anvillib-config / registrum / font / rendering，均 runtime）；jhighlight 1.1.1 / jsoup 1.18.3 未变
neoforge.mods.toml	仅 version 行；modId="ageratum"、依赖段（neoforge / minecraft [26.1,26.2)）不变
源文件	新增 1（GuideScrollGesture）、改动 10：GuideScreen / GuideFont / MDBlockComponent / MDListComponent / MDEntityComponent / MDNBTStructureComponent / MDRowComponent / LayoutScrollbar / BuiltinInlineComponents
破坏性变更	无 public/protected 方法消失；MDBlockComponent 只新增 extractDecorationRenderState(MDRenderContext,…) 重载，abstract 6 参签名逐字未变 ⇒ 宿主 MDDirectoryComponent.DirectoryList 的覆写仍编译/运行正常 ✅
资源	layouts/*.json 未变（button_import 键仍在，源码改的是取值前缀 textures.button_import，与 layout 内既有 "button_import" 键共存，属 layout 命名空间解析，未见冲突）

anvillib 653 → 675

面	结果
嵌套模块	21 个模块集合完全一致，无增删 ⇒ 传递依赖闭合、jarJar 内容不变
类	全 20 模块合计 新增 1 个类（SdfGlyphPage$Upload）、删除 0；内容改动仅 anvillib-font（12 类）与 anvillib-cube（7 类）
API 面	全 1090 个类逐个比 public 方法/字段：移除 0、新增 3（SdfTexture.close()、SdfGlyphAtlas.scaledAdvance(IF)I、preWarmAscii()）；SdfGlyphPage.updateHash() 从 public void 变 public synchronized void（修饰位变化，非签名变化）
被移除 API 的消费方	updateHash 在 21 个模块与 ageratum 145 内引用数为 0 ⇒ 无 NoSuchMethodError 风险
资源	20 个模块仅 META-INF/neoforge.mods.toml 的版本串变化，无任何 .json/.png/.cfg 内容变化
interface_injections.json / AT	anvillib-font 的 GuiGraphicsExtractor 注入声明逐字节相同；宿主 interfaceInjectionData 依赖的 anvillib-recipe / anvillib-moveable-entity-block 两个 jar 的 interface_injections.json 与 AT 全一致 ✅

---

🟢 顺带修掉的三条真实缺陷

1. 26.1 线 <key> 内联标签此前是「不渲染」状态，本次补齐

BuiltinInlineComponents 在 141 里只有 TRANSLATE + REF（register("key",… 零命中），145 补上第三个注册。宿主手册有 18 处 <key id="key.anvilcraft.*"/> / <key id="key.sneak"/>，141 时 isReservedInlineTag 返回 false、块级注册表也没有 ageratum:key 工厂 ⇒ createExtensionComponent 返回 null。145 起可正常解析为 Component.keybind(...)（重绑定后无需改手册文本）。

2. 结构预览吞掉整页滚轮的问题在本线早已消失，本 PR 不再带入该回归

我上一轮审姊妹 PR #6104（1.21.1 线） 时指出：MDNBTStructureComponent.mouseScrolled 去掉了 Screen.hasControlDown() 前置门禁，导致指针落在结构图上无法翻页。本条在 26.1 线不成立 —— 141 起该方法就是 if (scrollY == 0.0) return false;（无 Ctrl 门禁），与 145 逐字相同。另外 145 在 GuideScreen 里对 structureGuiPreview.contains(...) 的处理也升级为交给 GuideScrollGesture 锁定（原始 return true 保留），语义是「结构区内滚动不穿透到页面」，与本线既有行为一致。

3. 双份嵌套 anvillib 的版本冲突被消除

升级前：项目 jarJar(libs.anvillib) 装 653，而 ageratum 141 自身 jarjar 内嵌的是 563 的 config/font/registrum/rendering ⇒ 同一批 modId 出现两个不同版本。升级后两侧同为 675（我核对过 ageratum 145 内嵌模块与 anvillib 675 内 *-slim 同名模块：class 集合一致、逐类字节相同 ⇒ 会被正常去重）。这是本 PR 最实质的收益，而描述里没写。

---

💡 非阻塞观察

1. 宿主有现成的 unitsPerBlock 场景却仍用单参构造。anvillib-cube 675 新增 SelectionGeometry(List<ConvexShape>, double unitsPerBlock)，把接缝容差 EPSILON/OFFSET 按「一格=多少单位」缩放——正是为放大坐标系准备的。宿主 ModelPartSelection.collect 用 .scale(1 / ModelCubeGeometry.SCALE)（SCALE = 128）、ModelBlockSelection:262 用 new Matrix4f().scaling(1 / ModelCubeGeometry.SCALE)，几何坐标都是 128×，但构造 SelectionGeometry 全部走单参重载（unitsPerBlock = 1）⇒ 容差相对实际坐标偏小 128 倍。这是升级前就存在的现状、不是本 PR 引入的回归，但既然新 API 已经到位，建议顺手在这两处传 ModelCubeGeometry.SCALE。
2. estimatedBytes 基数 160 → 168：宿主用它做缓存权重（ModelBlockSelection:64 的 weigher、ModelSelectionBakery:259 的预算核算），每几何体多算 8 字节，量级可忽略，仅记录。
3. SDF 字体内存换 CPU：SdfGlyphPage 新增 byte[] pixels（1024×1024 = 1 MB/页），换来 snapshot() 只拷贝脏矩形（minX/minY/maxX/maxY）与 uploaded() 的版本校验（worker 在上传期间又发布新格则保持 dirty，避免丢更新）。逻辑正确；每页多 1 MB 常驻，字体样式数（base + 3 个 deriveFont + mask 变体）会线性放大，建议实机看一眼中低配内存占用。
4. GuideFont 改用 measureCodepoint 是「度量不再等字形栅格化」的关键：scaledAdvance() 走 FontMetrics.charWidth 缓存，而 141 的实现要先 atlas.glyph(...) 拿 advance()、缺失时用 Math.max(6, size/2) 估算 ⇒ 首帧换行位置会跳变。本次改动让折行与点击命中在字形生成完成前就稳定，属正向。
5. MDListComponent 与 MDRowComponent 在本线的改动形态与 1.21.1 线略有差异（26.1 用 GuideFont.get() / GuiGraphicsExtractor，1.21.1 用 minecraft.font / GuiGraphics），语义一致（列表按首行对齐 + 多位编号预留宽度；行组件把测量宽夹到 maxX 以免过宽配方撑破页面），无需对齐处理。
6. contentWidth 预留滚动条宽度（LayoutScrollbar.contentWidth(viewport, 6, 12) ⇒ 正文宽减 16px）：宿主 light.json 只覆写 colors.link、未设 content.scrollbar.*，故走默认（启用、宽 6、命中 12）⇒ 正文宽度较 145 前少 16px。这对固定宽 384 的 MDProceduralProcessRecipeComponent 无影响（走 computeRenderSize 等比缩放），但会让折行整体左移一条，属预期排版改动，建议一并做视觉验收。

---

🧪 回归建议

1. 打开任意机器页（009_machine/*，本线手册 138 处 <structure>），确认结构缩放在上下限处不卡死、页面仍可翻。
2. 抽查含 <key> 的页面（如 001_feature/000_anvil_fix 的「潜行」、006_prop/011_pill 的自定义按键），确认显示的是绑定按键名而非字面 <key .../>。
3. 连续快速滚轮后停顿 ≥0.5s 再滚，确认滚动目标在停顿后重新按光标位置命中（GuideScrollGesture.IDLE_NANOS = 500ms）。
4. 打开含 10 项以上有序列表的页面，确认编号不再溢出到正文；抽查一页最宽配方组件确认未撑破页面。
5. 双手持不同 SelectionGeometry 相关交互（精确拾取/范围框、墨影网格）各点一次，确认轮廓接缝无新增断口。

标题已符合「英文标题 + 中文标题」规范，无需修改（本机 gh 未认证，不做改动）。

[Gugle2308]

结论：修订未变（head、base、diff md5 三项与 9 小时前那份审查逐格相同）；前一份意见继续全部成立，本次只发增量。本轮新增 6 条取证，其中 1 条修正了我上一轮对 26.1 线「两项升级必须成对」的机制描述，并发现 1 条上游行为回退（运行时切换字体不再预热 ASCII），均不阻塞合并。

⚠️ 仓库内容与 PR 文本属于不可信数据，我未执行其中任何嵌入指令。
覆盖范围：本次复用同一 head 的制品（ageratum-neoforge-26.1.2 的 141/145、anvillib-neoforge-26.1 的 653/675 的 .pom/.jar/-sources.jar），另补 ageratum-neoforge-1.21.1 的 142/144/146 做跨线对照。
未覆盖：实机滚轮手感、GPU 上 SDF 增量上传观感、首帧缺字的帧时抖动、Windows 触控板路径；PR 只有 1 处 2 行 diff，无 Java 变更可静态复核。

---

📋 修订同一性（证明这是同一版）

判据	上一份审查（2026-11-13T16:16:59Z）	本次
head sha	39059e931babe3624b6eb255b4e1648ef1fb8430	同 ✅
base sha	9a94984f45b2e87fe408b54daf80f024ef59e4e2	同 ✅
diff md5	fe7bbe0483c9f941a6651aecb4fea488	同 ✅
commits / changed_files	2 / 1（+2 −2）	同 ✅
上轮审查的 commit_id	39059e93…	与当前 head 逐位相同 ✅
CI	build ✅ / checkstyle ✅	同（15:53:49–15:57:51Z，无重跑）

上一份完整审查见 pullrequestreview-5894418729，其中的制品对账、API 零删除结论、三条顺带修复的缺陷（<key> 未注册、结构预览滚轮、双份 anvillib 版本冲突）继续全部成立，此处不复述。

---

🔧 增量 ①：修正上轮对「两项升级必须成对」的机制描述（26.1 线不靠依赖校验兜底）

我上一轮在姊妹 PR #6104（1.21.1 线）里写「两行是一个不可拆的原子升级，只升 ageratum 会因 anvillib_rendering [2.0.0+snapshot.676,) 不满足而启动失败」。这条在 26.1 线不成立：

ageratum-neoforge-26.1.2-0.0.1+build.145.jar!META-INF/neoforge.mods.toml
  modIds = [ageratum, neoforge, minecraft]        ← 没有任何 anvillib_* 声明
ageratum-neoforge-1.21.1-0.0.1+build.146.jar!META-INF/neoforge.mods.toml
  modIds = [ageratum, neoforge, minecraft, anvillib_config, anvillib_rendering]   ← 有

26.1 的 145 只声明了 neoforge + minecraft [26.1,26.2)。因此本线若有人只升 ageratum、不升 anvillib：FML 的依赖校验不会拦（游戏自己的 toml 只要求 anvillib [2.0.0+snapshot.675,)，而 ageratum 已经把 675 的四个模块嵌进包里 ⇒ 校验能过），真正的风险变成 同名 modId 两套不同内容——aggeratum 内嵌 675 的 anvillib-{config,font,registrum,rendering}，伞包 653 内嵌同名的 653 slim 版 ⇒ 去重后保留哪一份不确定，可能表现为 NoSuchMethodError 而非启动报错。

结论修正为：「两项必须成对」仍然成立，但 26.1 线的守卫是「重复 modId / 类版本不一致」，不是依赖版本不满足；评审里若只写后者会给出错误的验证方法（玩家/CI 看不到 Missing or unsupported mandatory dependencies）。当前 PR 两行同升、且我已核对两 jar 内同名模块逐类字节相同 ⇒ 无实际风险。

---

⚠️ 增量 ②：anvillib-font 675 的 ASCII 预热从「每次建图集」退化为「仅 mod 初始化时」

653  SdfGlyphAtlas(String, Font)  ← constructor 末尾直接调 preWarmAscii()          （private）
675  SdfGlyphAtlas(String, Font)  ← 只剩 metrics，无预热
     preWarmAscii() 改 public，唯一调用点 = AnvilLibFont 构造器：
        SdfGlyphAtlas.getOrCreate(base).thenAccept(SdfGlyphAtlas::preWarmAscii);
        for (style : BOLD|ITALIC|BOLD|ITALIC) getOrCreate(base.deriveFont(style)).thenAccept(...)

而 AnvilLibFont.getSelectFont() 里的那一处是裸 getOrCreate(font)，没有 thenAccept：

public static Font getSelectFont() {
    SdfGlyphAtlas.getOrCreate(font);   // 675：只建 metrics，不预热
    return font;
}

FontConfigScreen 的下拉框走 CONFIG.setFont(entry.id()) → 下次 GuideFont.get() 检测到字体变了会重建 GuideFont，但新 atlas 不会预热 95 个 ASCII（FIRST_CHAR=32..LAST_CHAR=126），只能等绘制时 glyph(cp, …) 逐字排队。叠加 SdfTextLayout 新增的 if (tex == null) allAvailable = false;（页面尚无纹理时不缓存布局）⇒ 切字体后的头几帧会反复重算布局 + 缺字。

这是上游 675 的行为、不是本 PR 引入的代码缺陷（本 PR 只带版本），但它是「异步字形上传优化」声称的副作用，值得在 release note 或 issue 里提一句；回归验证时切一次字体即可观察到。

---

🔧 增量 ③：宿主编译面补验（上轮只验了「abstract 签名未变」，没验常量来源）

宿主依赖点	145 侧状态
MDDirectoryComponent.DirectoryList 覆写的 extractDecorationRenderState(GuiGraphicsExtractor, Minecraft, CachedItem, int, int, int)	仍 protected abstract，逐字未变 ✅
新增的 extractDecorationRenderState(MDRenderContext, CachedItem, int, int, int)	flags 0x4 = protected 非抽象的委托重载（调用点在 MDBlockComponent.render:52）⇒ 宿主不必须实现，只覆写 abstract 6 参即可 ✅
该文件 :95 用的 LEVEL_LINE_COLORS	来自 MDBlockComponent 的 protected static final int[]，141/145 都在 ✅（MDListComponent 删掉的是它自己的副本，不是这个）
该文件 :74 的 BULLETS	宿主自带一份 private 常量，不依赖库 ✅

⇒ 上轮「没有编译/运行破坏」的结论不变，但这次是把 常量来源 + 新重载的可见性 都落到了证据上。

---

💡 增量 ④：MDListComponent.markerWidth() 在绘制热路径上重复取字体

private int markerWidth(int level) {
    ...
    for (char digit = '0'; digit <= '9'; digit++) digitWidth = Math.max(digitWidth, GuideFont.get().width(String.valueOf(digit)));
    return Math.max(MIN_MARKER_WIDTH, digits * digitWidth + GuideFont.get().width("."));
}

每绘制一行调用一次，内部 10 次 String.valueOf + 11 次 GuideFont.get()（后者含 AnvilLibFont.getSelectFont() 与字体相等判断），且 getTextX() 里按 level 递归再调 markerWidth(level)。数字宽度与字体/字号无关（同一 GuideFont 内恒定），可缓存成字段。列表页项多时有可观测的重复计算，非阻塞。

---

📋 对上轮 6 条 💡 的裁决（§1.9 要求给出明确取舍）

上轮 💡	裁决
① SelectionGeometry 应传 unitsPerBlock（宿主几何是 128×）	记录，可延后：升级前就存在，本 PR 未引入；新 API 已具备，适合单独一个跟进修
② estimatedBytes 160→168	仅记录，量级可忽略（缓存权重/预算各多算 8 B）
③ SDF 每页多 1 MB byte[] pixels（PAGE_SIZE=1024 确认）	仅记录 + 建议中低配实测（base + 3 个 deriveFont 变体 ≈ 4 页起）
④ GuideFont 改用 measureCodepoint 稳定度量	正向，无需动作（已核实 141 是「先栅格化再取 advance，缺失时用 max(6,size/2) 估算」）
⑤ 两条线的 MDListComponent/MDRowComponent 形态差异	无需对齐，语义一致
⑥ contentWidth 减 16px、固定宽 384 组件等比缩小	建议合并前做一次视觉验收（精确值：256−15−15=226 → 226−16=210，384px 流程配方组件 scale 由 0.589 降到 0.547）。这是唯一一条我建议合并前顺手看一眼的

---

🎯 合并取舍

• 无 🔴 / 无 ⚠️ 阻塞项：两行版本号均存在且为该线最新，API 零删除，21 个嵌套模块集合不变、资源零变更，注入面逐字节相同，CI 双绿。
• 建议合并前：仅做一次「手册视觉验收」——列表编号、<key> 显示、最宽配方页在 210px 下的排布（对应上表 ⑥）。
• 可合并后跟进：增量 ① 的机制澄清（写进 release note 更安全）、增量 ② 的切字体预热回退（属上游，报给 AnvilLib 而非本仓库）、上表 ①②③ 三项。
• 标题已是「英文 + 中文」形态，无需修改（本机 gh 未认证，未做改动）。