模块边界：apps/esp32

图的读法

这张 Package Diagram 以 apps/esp32_lvgl 为中心，展示它作为工程模块边界时观察到的文件规模、符号规模和跨模块依赖。
图中的箭头表示本地仓库证据观察到的跨模块关系，主要用于理解技术依赖方向；它不是业务流程顺序，也不是运行时消息时序。
当前观察到的主要外部依赖包括：firmware、apps/linux_uconsole_gtk。

技术复杂度分析

apps/esp32_lvgl 当前包含 31 个文件和 402 个符号，属于软件结构模型识别出的技术组织边界。
跨模块关系呈现为：被其它模块引用或调用 217 次，主动依赖或调用外部模块 3 次，因此它被其他模块依赖更多。
当前对外依赖未形成明显异常，但仍应结合具体业务入口判断依赖方向是否稳定。

与业务复杂度的关联

apps/esp32_lvgl 不是业务故事本身，而是业务能力落地时可能经过的技术边界。
如果组织/过程模型中某个 Use Case 的证据、入口或下钻图落在 apps/esp32_lvgl，该 Use Case 应当反向链接到这张 Package Diagram，说明业务故事由哪个工程模块承载。
当前关联仍是 CANDIDATE：这里只能根据仓库证据解释技术边界，不能替代组织/过程模型对业务故事、参与者和业务目标的确认。

治理建议

新增功能时，优先确认它属于该模块的稳定职责，而不是因为调用方便而落入该模块。
保持该模块的依赖方向可解释，避免形成隐式公共工具箱。
当业务 Use Case 文档引用该模块时，应在 Use Case 下钻文档中记录具体入口、调用链或配置证据。

UML / 技术图

flowchart LR
  package_node["apps/esp32_lvgl"]
  dependency_1["firmware"]
  package_node --> dependency_1
  dependency_2["apps/linux_uconsole_gtk"]
  package_node --> dependency_2

覆盖范围

模块路径：apps/esp32_lvgl
文件数：31
符号数：402
被其他模块依赖或调用：217
依赖或调用外部模块：3

图内语义元素下钻

apps/esp32_lvgl package
apps/esp32_lvgl 是当前 Package Diagram 的中心工程边界，用来观察它自身规模、依赖方向和可下钻技术复杂度。

技术角色
技术组织边界：它把 apps/esp32_lvgl 下的文件、符号和跨模块关系聚合成一个可讨论的工程单元。

为什么出现
本地仓库证据在 apps/esp32_lvgl 下观察到足够文件、符号或跨模块关系，因此它值得被提升为软件结构模型中的 package 级入口。

关系意义
图中从 apps/esp32_lvgl 指向其它节点的箭头表示当前边界依赖外部 package/module；被其他模块依赖或调用 217 次、依赖或调用外部模块 3 次，用于判断它更像稳定复用边界还是编排/桥接边界。

下钻意图
下钻该节点可以继续查看 apps/esp32_lvgl 内的关键组件、结构协作切片、运行链路、部署节点和复杂度热点，从而理解这个工程边界如何承载功能变化。

业务关联
该节点不是业务故事本身，但组织/过程模型中落到 apps/esp32_lvgl 的 Use Case 可以把这里作为技术承载边界引用。当前关联仍是 CANDIDATE。

变更影响
修改 apps/esp32_lvgl 的公共入口、依赖方向或目录边界，可能影响引用它的组件图、sequence 片段、部署配置和相关业务故事的验证路径。

置信度
high
证据
- package scope: apps/esp32_lvgl
- 模块路径：apps/esp32_lvgl
- 文件数：31
- 符号数：402
- 被其他模块依赖或调用：217
- 依赖或调用外部模块：3
- apps/esp32_lvgl/APP_SHELL_MANIFEST.md
- apps/esp32_lvgl/CMakeLists.txt
风险
- 如果只把该节点当作目录名，会遗漏它作为稳定工程边界的职责判断。
- 如果依赖外部模块的迹象持续增加，可能说明该边界承担过多编排或桥接职责。
问题
- 当前仓库证据尚未把该 package 明确 Trace 到某个 Use Case；因此业务关联保持候选。
firmware package
firmware 是 apps/esp32_lvgl 当前观察到的外部技术边界依赖；它说明当前模块不是孤立实现，而是需要借助另一组工程能力完成职责。

技术角色
跨模块技术依赖边界：当前 package 需要另一个 package/module 提供能力、契约、配置或运行支撑。

为什么出现
本地仓库证据在 apps/esp32_lvgl 与 firmware 之间观察到跨模块事实关系，因此该依赖被放入 Package Diagram，而不是只藏在代码 import/call 里。

关系意义
apps/esp32_lvgl -> firmware 表示本地仓库证据观察到跨模块关系；它解释技术依赖方向，但不直接证明业务流程。

下钻意图
下钻 firmware 可以查看它自己的 Package Diagram，再继续进入其组件、结构、sequence 或热点，判断当前依赖究竟落在入口、运行时、工具注册、模型适配还是基础设施边界。

业务关联
apps/esp32_lvgl 如果承载用户可见能力，那么对 firmware 的依赖可能是该能力的运行机制、扩展点或治理约束。该业务关联需要由组织/过程模型的 Use Case 证据确认。

变更影响
修改 firmware 的公共接口、路径或运行方式，可能让 apps/esp32_lvgl 的调用链、打包入口、agent 工作流或 UI 行为发生连锁变化。

置信度
high
证据
- dependency edge: apps/esp32_lvgl -> firmware
- firmware/c6_companion/CMakeLists.txt
- firmware/c6_companion/components/tm_ble/CMakeLists.txt
- firmware/c6_companion/components/tm_ble/include/tm_ble.h
- firmware/c6_companion/components/tm_ble/tm_ble.c
- firmware/c6_companion/components/tm_diag/CMakeLists.txt
- firmware/c6_companion/components/tm_diag/include/tm_diag.h
- firmware/c6_companion/components/tm_diag/tm_diag.c
风险
- 跨模块依赖只能证明技术关系，不能直接证明业务关系。
- 如果该依赖只是因为实现方便而存在，未来变更可能形成边界漂移或隐式公共工具箱。
问题
- 当前证据尚未证明 apps/esp32_lvgl 依赖 firmware 与某个 Use Case、runtime command 或配置决策直接相关。
- 当前依赖方向按仓库事实记录为候选，尚未发现架构决策文档证明它是稳定边界。
apps/linux_uconsole_gtk package
apps/linux_uconsole_gtk 是 apps/esp32_lvgl 当前观察到的外部技术边界依赖；它说明当前模块不是孤立实现，而是需要借助另一组工程能力完成职责。

技术角色
跨模块技术依赖边界：当前 package 需要另一个 package/module 提供能力、契约、配置或运行支撑。

为什么出现
本地仓库证据在 apps/esp32_lvgl 与 apps/linux_uconsole_gtk 之间观察到跨模块事实关系，因此该依赖被放入 Package Diagram，而不是只藏在代码 import/call 里。

关系意义
apps/esp32_lvgl -> apps/linux_uconsole_gtk 表示本地仓库证据观察到跨模块关系；它解释技术依赖方向，但不直接证明业务流程。

下钻意图
下钻 apps/linux_uconsole_gtk 可以查看它自己的 Package Diagram，再继续进入其组件、结构、sequence 或热点，判断当前依赖究竟落在入口、运行时、工具注册、模型适配还是基础设施边界。

业务关联
apps/esp32_lvgl 如果承载用户可见能力，那么对 apps/linux_uconsole_gtk 的依赖可能是该能力的运行机制、扩展点或治理约束。该业务关联需要由组织/过程模型的 Use Case 证据确认。

变更影响
修改 apps/linux_uconsole_gtk 的公共接口、路径或运行方式，可能让 apps/esp32_lvgl 的调用链、打包入口、agent 工作流或 UI 行为发生连锁变化。

置信度
high
证据
- dependency edge: apps/esp32_lvgl -> apps/linux_uconsole_gtk
- apps/linux_uconsole_gtk/APP_SHELL_MANIFEST.md
- apps/linux_uconsole_gtk/CMakeLists.txt
- apps/linux_uconsole_gtk/packaging/trailmate-uconsole.desktop
- apps/linux_uconsole_gtk/packaging/trailmate-uconsole.png
- apps/linux_uconsole_gtk/README.md
- apps/linux_uconsole_gtk/src/linux_uconsole_gtk_app_shell.cpp
- apps/linux_uconsole_gtk/src/linux_uconsole_gtk_app_shell.h
风险
- 跨模块依赖只能证明技术关系，不能直接证明业务关系。
- 如果该依赖只是因为实现方便而存在，未来变更可能形成边界漂移或隐式公共工具箱。
问题
- 当前证据尚未证明 apps/esp32_lvgl 依赖 apps/linux_uconsole_gtk 与某个 Use Case、runtime command 或配置决策直接相关。
- 当前依赖方向按仓库事实记录为候选，尚未发现架构决策文档证明它是稳定边界。

可下钻 UML

函数节点：main component · contains

打开函数节点：main 是为了确认 apps/esp32_lvgl 内部哪一个具体对象承担入口、编排、适配、契约或共享职责。重点查看代码锚点 apps/esp32_lvgl/tests/esp32_lvgl_sd_coredump_contract_smoke.cpp，以及它的被引用/调用关系和对外依赖/调用关系是否意味着变更会扩散。

function 位于 apps/esp32_lvgl/tests/esp32_lvgl_sd_coredump_contract_smoke.cpp#L33，协调多个外部对象或能力，用于解释技术协作和变更影响面。

函数节点：contains component · contains

打开函数节点：contains 是为了确认 apps/esp32_lvgl 内部哪一个具体对象承担入口、编排、适配、契约或共享职责。重点查看代码锚点 apps/esp32_lvgl/tests/esp32_lvgl_sd_coredump_contract_smoke.cpp，以及它的被引用/调用关系和对外依赖/调用关系是否意味着变更会扩散。

function 位于 apps/esp32_lvgl/tests/esp32_lvgl_sd_coredump_contract_smoke.cpp#L19，被多个对象复用或依赖，用于解释技术协作和变更影响面。

函数节点：companion_enter component · contains

打开函数节点：companion_enter 是为了确认 apps/esp32_lvgl 内部哪一个具体对象承担入口、编排、适配、契约或共享职责。重点查看代码锚点 apps/esp32_lvgl/src/esp32_lvgl_idf_app_registry.cpp，以及它的被引用/调用关系和对外依赖/调用关系是否意味着变更会扩散。

function 位于 apps/esp32_lvgl/src/esp32_lvgl_idf_app_registry.cpp#L72，协调多个外部对象或能力，用于解释技术协作和变更影响面。

动态协作：tick 调用 log_loop_interval sequence · dynamic_flow

打开这条 sequence 是为了把 apps/esp32_lvgl 的静态依赖还原成一段可读协作：tick -> log_loop_interval。重点判断这是 import、调用、引用还是消息方向，以及它是否真的影响运行路径。

apps/esp32_lvgl/src/esp32_lvgl_arduino_loop_runtime.cpp 中的 tick calls apps/esp32_lvgl/src/esp32_lvgl_arduino_loop_runtime.cpp 中的 log_loop_interval。

动态协作：add_status_line 调用 add_label sequence · dynamic_flow

打开这条 sequence 是为了把 apps/esp32_lvgl 的静态依赖还原成一段可读协作：add_status_line -> add_label。重点判断这是 import、调用、引用还是消息方向，以及它是否真的影响运行路径。

apps/esp32_lvgl/src/esp32_lvgl_idf_app_registry.cpp 中的 add_status_line calls apps/esp32_lvgl/src/esp32_lvgl_idf_app_registry.cpp 中的 add_label。

动态协作：add_u32_line 调用 add_label sequence · dynamic_flow

打开这条 sequence 是为了把 apps/esp32_lvgl 的静态依赖还原成一段可读协作：add_u32_line -> add_label。重点判断这是 import、调用、引用还是消息方向，以及它是否真的影响运行路径。

apps/esp32_lvgl/src/esp32_lvgl_idf_app_registry.cpp 中的 add_u32_line calls apps/esp32_lvgl/src/esp32_lvgl_idf_app_registry.cpp 中的 add_label。

动态协作：add_hex_line 调用 add_status_line sequence · dynamic_flow

打开这条 sequence 是为了把 apps/esp32_lvgl 的静态依赖还原成一段可读协作：add_hex_line -> add_status_line。重点判断这是 import、调用、引用还是消息方向，以及它是否真的影响运行路径。

apps/esp32_lvgl/src/esp32_lvgl_idf_app_registry.cpp 中的 add_hex_line calls apps/esp32_lvgl/src/esp32_lvgl_idf_app_registry.cpp 中的 add_status_line。

动态协作：companion_enter 调用 add_label sequence · dynamic_flow

打开这条 sequence 是为了把 apps/esp32_lvgl 的静态依赖还原成一段可读协作：companion_enter -> add_label。重点判断这是 import、调用、引用还是消息方向，以及它是否真的影响运行路径。

apps/esp32_lvgl/src/esp32_lvgl_idf_app_registry.cpp 中的 companion_enter calls apps/esp32_lvgl/src/esp32_lvgl_idf_app_registry.cpp 中的 add_label。

动态协作：companion_enter 调用 add_status_line sequence · dynamic_flow

打开这条 sequence 是为了把 apps/esp32_lvgl 的静态依赖还原成一段可读协作：companion_enter -> add_status_line。重点判断这是 import、调用、引用还是消息方向，以及它是否真的影响运行路径。

apps/esp32_lvgl/src/esp32_lvgl_idf_app_registry.cpp 中的 companion_enter calls apps/esp32_lvgl/src/esp32_lvgl_idf_app_registry.cpp 中的 add_status_line。

证据

apps/esp32_lvgl/APP_SHELL_MANIFEST.md
apps/esp32_lvgl/CMakeLists.txt
apps/esp32_lvgl/library.json
apps/esp32_lvgl/README.md
apps/esp32_lvgl/src/esp32_lvgl_app_shell.cpp
apps/esp32_lvgl/src/esp32_lvgl_app_shell.h
apps/esp32_lvgl/src/esp32_lvgl_arduino_app_registry.cpp
apps/esp32_lvgl/src/esp32_lvgl_arduino_app_runtime_access.cpp

问题

暂无未决问题。