从 openxlings/xim-pkgindex 的能力通道方案里剥出来的一条，与那个方案做不做无关，本身就成立。
现状
xlings 里有 4 处各自 ExecutionContext ctx; 然后逐字段填：
| 位置 |
干什么 |
src/core/xim/installer.cpp:2384 |
安装(config / install 钩子) |
src/core/xim/installer.cpp:3240 |
卸载(uninstall 钩子) |
src/core/cmdprocessor.cpp:275 |
xlings run <script> |
src/cli.cpp:1533 |
同上，另一条入口 |
而 subos_sysrootdir 已经分成了两种填法：前两处走 configure_xpkg_execution_artifact_paths_(installer.cpp:796)，后两处各自内联写一遍。
为什么是问题
这是这个代码库反复被咬的形状：一个事实有多个写入者。今天四处碰巧一致，明天加第五处入口、或者给 ExecutionContext 加一个新字段时，漏掉一处的表现通常是钩子看到一个更保守的上下文，于是多做一点事，不报错，输出一样 —— 又一次"没发生过和成功了长得一样"。
subos_sysrootdir 这一个字段现在就有两种来源，说明这不是假想。
建议
收敛成一个工厂：
mcpplibs::xpkg::ExecutionContext xim::make_execution_context();
四处全部改用它。以后加字段只在工厂里加一次，加第五处入口自动带上。
背景
这条是在 #423 的收尾里发现的：当时在评估要不要给 recipe 一个"客户端能力通道"(让 recipe 能问"这个客户端会不会回收声明式资产")。那个方案已否决(理由见 openxlings/xim-pkgindex 的 .agents/docs/2026-08-27-client-capability-channel-design.md)，但如果哪天真要建，能力必须在所有 ExecutionContext 上都出现，否则某条入口跑的 recipe 会静默走回退分支 —— 到那时这个工厂就是前置条件，而不是可选项。
从 openxlings/xim-pkgindex 的能力通道方案里剥出来的一条，与那个方案做不做无关，本身就成立。
现状
xlings 里有 4 处各自
ExecutionContext ctx;然后逐字段填：src/core/xim/installer.cpp:2384src/core/xim/installer.cpp:3240src/core/cmdprocessor.cpp:275xlings run <script>src/cli.cpp:1533而
subos_sysrootdir已经分成了两种填法：前两处走configure_xpkg_execution_artifact_paths_(installer.cpp:796)，后两处各自内联写一遍。为什么是问题
这是这个代码库反复被咬的形状：一个事实有多个写入者。今天四处碰巧一致，明天加第五处入口、或者给
ExecutionContext加一个新字段时，漏掉一处的表现通常是钩子看到一个更保守的上下文，于是多做一点事，不报错，输出一样 —— 又一次"没发生过和成功了长得一样"。subos_sysrootdir这一个字段现在就有两种来源，说明这不是假想。建议
收敛成一个工厂：
mcpplibs::xpkg::ExecutionContext xim::make_execution_context();四处全部改用它。以后加字段只在工厂里加一次，加第五处入口自动带上。
背景
这条是在 #423 的收尾里发现的：当时在评估要不要给 recipe 一个"客户端能力通道"(让 recipe 能问"这个客户端会不会回收声明式资产")。那个方案已否决(理由见 openxlings/xim-pkgindex 的
.agents/docs/2026-08-27-client-capability-channel-design.md)，但如果哪天真要建，能力必须在所有 ExecutionContext 上都出现，否则某条入口跑的 recipe 会静默走回退分支 —— 到那时这个工厂就是前置条件，而不是可选项。