03 包装/类可见性：研究卡与拟执行实验（2026-10-04）

问题：WAR 自带 JAR、服务器 API、EAR 共享库分别给谁看？缺库与冲突库怎样判别？
官方依据：Jakarta EE Platform 11.0 https://jakarta.ee/specifications/platform/11/jakarta-platform-spec-11.0 ，§8.1.1（独立模块、EAR）、§8.2.1（EAR library-directory 默认 lib；仅直属 .jar、WAR WEB-INF/lib）、§8.2.2（库冲突时平台版可能优先）、§8.3（未规定类加载器拓扑）、§8.3.1/§8.3.2（必有/可有/禁止依赖的可见性）、§8.4.1（每个应用只用同名类的一个版本、application.xml 可选）。Jakarta Servlet 6.1 https://jakarta.ee/specifications/servlet/6.1/jakarta-servlet-spec-6.1 ，§8.2、§10，部署描述符与 Web 包结构。
源码入口：examples/javaee-enterprise/pom.xml；webapp/pom.xml；webapp/src/main/java/blog/javaee/web/{RestApplication,HealthResource}.java；webapp/src/main/webapp/WEB-INF/beans.xml；deploy/server.xml。主工程只有 WAR，不包含 EAR 或 EJB 模块；server.xml 文本不能证明已成功部署。

已观察基础证据：writing-plans/javaee-enterprise/verification/20261004T061900Z-pg16-foundation/build-3.stdout.txt 为 Maven clean verify BUILD SUCCESS（五模块），server-final.stdout.txt 为 Open Liberty 26.0.0.5 应用启动及实际安装特性，health.headers.txt/datasource.headers.txt 为两个 HTTP 200，body 文件分别为 ready/connected，退出码文件均为 0。db-version.txt 的库名为 javaee_lab。此组日志不是 jar tf 包检查的原始输出，也不是本章模拟 EAR、删库或 API 冲突的部署结果。

正常路径：JDK 21，进入 examples/javaee-enterprise；运行 ../hibernate-lab/mvnw -B -ntp -f "$PWD/pom.xml" clean package；用 jar tf webapp/target/procurement-webapp-1.0-SNAPSHOT.war 检查三份 procurement-*.jar 位于 WEB-INF/lib、HealthResource 位于 WEB-INF/classes、beans.xml 位于 WEB-INF，且没有 WEB-INF/lib/jakarta.jakartaee-api-*.jar。采集 Maven 输出、退出码、war sha256sum 和 jar tf 原文。不能用已存在的 target/ 副本充当干净构建。
失败路径 A：复制正常 WAR 到 mktemp -d 的 missing-domain.war；zip -d "$scratch/missing-domain.war" 'WEB-INF/lib/procurement-domain-*.jar'；用 jar tf 检查被删条目不存在；保留原包哈希和坏包哈希。对坏包的实际部署/请求只在隔离服务器执行，保存应用启动日志/异常链及确切的请求路径；类缺失可能在部署期也可能在首次加载业务类时暴露，HTTP /health 成功不能当业务成功。
失败路径 B（可选，仅静态注入，不放到生产包）：先验证本地 Maven 仓库存在 ~/.m2/repository/jakarta/platform/jakarta.jakartaee-api/11.0.0/jakarta.jakartaee-api-11.0.0.jar；复制 WAR 为 "$scratch/api-conflict.war"；mkdir -p "$scratch/injected/WEB-INF/lib"；cp 上述 API JAR 到 injected/WEB-INF/lib/；(cd "$scratch/injected" && jar uf "$scratch/api-conflict.war" WEB-INF/lib/jakarta.jakartaee-api-11.0.0.jar)；jar tf 断言 API JAR 进入包。静态检查可以确定冲突来源，不预言类加载顺序或必然报错；若不部署则运行时行为依然 NOT_RUN。
实际证据：正常构建=NOT_RUN；故障静态检查=NOT_RUN；容器部署和业务请求=NOT_RUN；API 冲突运行效果=NOT_RUN。需单独记录环境、应用服务器实际版本/功能、部署包 SHA-256、完整命令、退出码、日志中首个缺失类/冲突类、请求码、业务结果与回滚；不得用阅读规范代替运行证据。