首次定向测试 `./examples/kotlin-language/gradlew -p examples/kotlin-language --no-daemon --console=plain test --tests example.tasks.TaskHttpRoutesTest` 返回 1；原始终端诊断摘录：

e: file:///home/admin/workspace/my-blogs/examples/kotlin-language/src/main/kotlin/example/tasks/TaskHttpRoutes.kt:104:5 Unresolved reference 'install'.
e: file:///home/admin/workspace/my-blogs/examples/kotlin-language/src/main/kotlin/example/tasks/TaskHttpRoutes.kt:104:35 Unresolved reference. None of the following candidates is applicable because of a receiver type mismatch:
fun Configuration.json(json: Json = ..., contentType: ContentType = ...): Unit
> Task :compileKotlin FAILED
BUILD FAILED in 1m 3s

缺 `io.ktor.server.application.install` 扩展导入；补上后定向复跑。这里是未重定向命令的实际编译诊断摘录，不宣称保留了第一次完整 stdout。

第二次错误在离线编译测试：主项目 `:compileKotlin` 成功，但 `:compileTestKotlin` 前解析 `io.ktor:ktor-server-test-host-jvm:3.3.1` 时报告 `No cached version ... available for offline mode.`，返回码 1。第一次在线命令尚未走到测试依赖解析；需先在线拉取测试制品，再单独核对离线运行。

第三次在线解析测试依赖后在 `TaskHttpRoutesTest.kt:77:13` 报 `Return type mismatch: expected 'String', actual 'Any'`，返回码 1；测试 lambda 的取消分支从 `await(): Unit` 与另一分支 `String` 混合推导。改为永不正常返回的 `awaitCancellation(): Nothing`，符合故障注入目标。

第四次离线 `:compileTestKotlin` 成功，`:test` 前解析 `testRuntimeClasspath` 失败：Ktor 的传递依赖要求未缓存的 `junit-platform-launcher:1.13.4`、`jansi:2.4.2`、`kotlinx-coroutines-slf4j:1.10.2` 等，退出 1；须在线解析完整运行依赖，不能将“源码编译成功”说成完整离线测试通过。

后续定向测试在固定端口的旧路径曾 PASS；改为客户端关闭早于任务完成后，在 `HttpClient.send()` 长时间等待，线程栈停在 `TaskHttpRoutesTest.kt:131`。该次 clean test 手工终止，不能计为通过。旧代码先用 `ServerSocket(0)` 取得端口、关闭 socket 再让 Netty 启动，存在重新绑定窗口；新实现直接在 Netty 配置端口 0，等 `resolvedConnectors()` 获取实际绑定端口，并给真实 HTTP 请求设置 10 秒超时；后续复跑才能判断该故障是否真正解除。

改由 Netty 直接绑定 0 后仍在第一次 POST 超时 10 秒，JUnit XML 有 `HttpTimeoutException`，应用停止时 Netty 记录被关闭 event executor 的后续异常（均保留于本文件和终端）。按单变量排除，先将 202 回包从动态 `registry.status()` 还原为提交时 `Queued` 快照，独立核对是否为状态查询引入的耦合；不把这次超时写成通过。

还原提交时 `Queued` 快照后，三条定向测试通过（BUILD SUCCESSFUL in 50s）。202 回包因此是“提交时初始状态”，**不是**任务在 HTTP 响应送达时的实时状态；GET `/tasks/{id}` 才返回查询时状态。两次真实端口超时的完整因果尚未完成源码归因，不能宣称动态状态查询本身是 Ktor 的稳定语义或唯一根因。

随后完整离线 clean test（85 用例）再次在真实端口带未放闸后台任务的第一次 POST 超时 10 秒，`TaskHttpRoutesTest` 3 用例中 1 FAIL；`verification/34/build.txt` 保留退出码 1，真实 HTTP 中途断线场景不得写成 PASS。将“已完成 202 响应后关闭订阅客户端，后台仍在运行”的闸门证据限制在 `testApplication` 内存客户端；真实端口回到实际可验证的默认任务 POST/GET。后续真实端口并发等待/断线实验仍待排查。

即便后台任务改为默认即时完成，JDK `HttpClient.send` 仍多次在实际 Netty 回环端口的首个 POST 上触发 10 秒 `HttpTimeoutException`；绑定端口由 `resolvedConnectors()` 返回正数（一次为 39037），排除“端口仍为 0”。改用 JDK 的 `HttpURLConnection` 与明确的 HTTP/1.1 连接和超时再次复验；是否为 JDK 客户端/环境交互问题尚不能下结论。

`HttpURLConnection` 在 `port=0/resolvedConnectors()` 方案下同样于首个 POST 抛 `SocketTimeoutException`，实际 API 端口有值但未得到应答；客户端类型不是单一故障解释。最后单独还原初次曾通过的 `ServerSocket(0)` 探测固定端口、关闭探测 socket 再启动 Netty，作为一次对照。若该路径无法稳定复跑，真实 HTTP 必须保持 NOT_RUN，不把测试应用替代它。

恢复固定端口后，与另外两个 `testApplication` 用例同跑仍超时；只筛真实端口一个方法独立跑却 BUILD SUCCESSFUL in 34s。将两个测试应用中新增的独立 `createClient` + `.close()` 从响应闸门用例撤除，回到共享测试客户端记录“已响应/后台尚未完成”；客户端关闭时机不再宣称已测试。这个改动需再跑所有用例才能判断测试间干扰是否解决。

移除额外测试客户端后，前一轮 `clean test` 曾全通过，但增加执行次数断言后再次在真实端口 POST 超时；该问题不应靠多次重试碰巧成功。将带 `@Tag("loopback")` 的真实回环测试交给单独的 `loopbackTest` Gradle `Test` 任务，与普通 `testApplication` 用例使用不同测试 JVM；`clean test loopbackTest` 同时执行两层测试，明确记录各自失败和退出码，不能把单独跑过理解为在同一进程混跑正常。混跑的具体资源干扰根因仍未证明。
