test(runtime-host): drive liveness-crossing waits from an injected probe cadence

[UncertaintyDeterminesYou4ndMe]

Part of #2389 (Runtime Host workspace; the Pi TUI workspace landed as #2448, desktop e2e and alignment audit follow separately).

What changed

Two tests held work pending for a fixed 2.1s purely to outlive the client connection's hardcoded DEFAULT_LIVENESS_INTERVAL_MS = 2_000:

• agent-graph-two-client-uds.test.ts — FakeAgentGraphAuthority.stop() slept 2.1s (the fake-shutdown case named in the issue) so the pending agent.graph.stop request would cross a liveness probe cycle.
• host-kernel.test.ts (slow domain work preserves multiplexed requests and retires only explicit deadlines) — the test slept 2.1s while holding an admitted request open before releasing its gate.

Both waits existed to prove the #2392 contract: liveness probes never retire a request that has no explicit deadline. The 2s value is incidental to that contract — what matters is that at least one probe fires while the request is pending.

The probe interval is now injectable: ConnectRuntimeHostInput.livenessIntervalMs (validated by the same requireTimeout as the existing timeout options, default unchanged at 2s), threaded through connectResolvedRuntimeHost into the connection's #scheduleLivenessCheck. Both tests inject a 100ms cadence and derive their waits from it (2 cycles + margin) — the wait is now measured in a unit the test controls instead of guessed against a constant it cannot see.

Retained contracts

• Probe-crossing semantics are exercised identically: with the 100ms cadence, two probes fire while the request is pending, and the request still completes with its real result.
• The probe timeout (DEFAULT_LIVENESS_TIMEOUT_MS), handshake/connect deadlines, and the explicit 50ms read_timeout case in the host-kernel test are untouched.
• The remaining short sleeps in this workspace are all poll intervals inside bounded wait loops (already observable completion) — audited and left as-is.

Production surface

One additive optional field on ConnectRuntimeHostInput; passing nothing preserves today's behavior exactly.

Timing (local, node --test)

Test	Before	After
two UDS Clients query and control one Agent graph…	~2.5s	0.36s
slow domain work preserves multiplexed requests…	~2.6s	0.38s

Full workspace suite after a clean build: 734/734 pass.

[Astro-Han]

Thanks for this. The injected cadence matches the existing connectTimeoutMs/handshakeTimeoutMs pattern, default behavior is unchanged (2s), and both tests are genuinely faster (430/450ms). The assertions still bite: if #2392 regresses, the pending request gets retired and the deepEqual fails.

One gap: the tests can't tell "probes fired and the request survived" from "probes never fired". If a future change stops using livenessIntervalMs in the constructor (types still compile), every assertion passes with zero probes in the window. A probe counter on the server side, asserted before release, would make the premise falsifiable. Cheap to add.

Nit: livenessIntervalMs is validated in the constructor, after connect + handshake, so a bad value surfaces as "handshake_failed" instead of a config error; the other timeouts validate up front. Approving.

[UncertaintyDeterminesYou4ndMe]

Both points addressed in bad4d15:

• Falsifiable premise: ConnectRuntimeHostInput.onLivenessProbe fires after a probe round-trips and validates its Host Epoch. The host-kernel test now releases the admitted request only after two observed probe round-trips (bounded — a cadence that stops taking effect times out loudly instead of vacuously passing), and the Agent-graph fake's stop() awaits that same crossing instead of a derived sleep, so the ordering is causal with no fixed timing left at all.
• Nit: livenessIntervalMs is now validated up front in connectResolvedRuntimeHost alongside connectTimeoutMs/handshakeTimeoutMs, so a bad value surfaces as a config error, not handshake_failed.

Both tests got faster again (~0.29s / ~0.33s); 734/734 after a clean build.

[Astro-Han]

Thanks for the follow-up. Both review points are substantively addressed:

• the tests now wait for observed, epoch-validated probe round-trips instead of assuming the injected cadence fired;
• livenessIntervalMs is validated before transport and handshake work, consistently with the existing timeout options.

The resulting tests are faster and their probe-crossing premise is now falsifiable.

P3 — Test observability is exposed through the public client input.

onLivenessProbe is documented as a test hook but is now part of the exported ConnectRuntimeHostInput. Its callback also runs inside the probe success chain, so an observer exception can fail the connection.

This is non-blocking because existing callers do not pass it and default production behavior is unchanged. Longer term, I would prefer observing probes through a package-internal test seam or Host/transport fixture. If the callback remains a public diagnostics hook, its exceptions should be isolated from connection health.

Small test-scoping suggestion: in the Agent Graph test, pass the probe observer only to the final TUI connection that issues agent.graph.stop. That makes it impossible for an earlier slow query on another connection to satisfy the shared counter.

The requested follow-up is effective, and I found no blocking issue. Approved.

简体中文

感谢继续修改。上一轮的两个问题都已经得到实质解决：

• 测试现在等待实际观察到、并完成 Host Epoch 校验的 probe round-trip，不再假设注入的 cadence 已经触发；
• livenessIntervalMs 现在与现有 timeout 配置一样，在 transport 和 handshake 之前完成校验。

测试变得更快，而且 probe-crossing 前提现在可以被证伪。

P3 — 测试观测能力进入了公开 client input。

onLivenessProbe 的文档明确说明它是 test hook，但它现在属于公开导出的 ConnectRuntimeHostInput。callback 还运行在 probe success chain 内，因此 observer 抛出的异常可能导致连接失败。

这是非阻塞问题，因为现有调用方不会传入它，默认生产行为也没有变化。长期来看，更适合通过 package-internal 测试 seam 或 Host/transport fixture 观察 probe。如果保留为公开 diagnostics hook，则 observer 异常不应影响连接健康。

还有一个小的测试作用域建议：Agent Graph 测试只给最终执行 agent.graph.stop 的 TUI connection 传入 probe observer。这样前面其他 connection 上的慢查询就不可能提前满足共享 counter。

本轮修改有效，没有发现阻塞问题。Approve。

[UncertaintyDeterminesYou4ndMe]

Both follow-ups applied in fc78317:

• Observer isolation: onLivenessProbe exceptions are now swallowed at the call site — a diagnostics hook can no longer fail the connection it is watching — and the input doc states that contract explicitly. On the longer-term point: agreed a package-internal seam would be cleaner; if a second consumer of probe observability ever appears, that's the moment to move it behind a Host/transport fixture rather than the public input.
• Test scoping: the Agent-graph observer is now wired only onto the final TUI connection that issues agent.graph.stop, so no other connection's slow query can satisfy the shared counter.

Suite green after a clean build; typecheck and biome pass.

[UncertaintyDeterminesYou4ndMe]

Part of #2389 (Runtime Host workspace; the Pi TUI workspace landed as #2448, desktop e2e and alignment audit follow separately).

What changed

Two tests held work pending for a fixed 2.1s purely to outlive the client connection's hardcoded DEFAULT_LIVENESS_INTERVAL_MS = 2_000:

• agent-graph-two-client-uds.test.ts — FakeAgentGraphAuthority.stop() slept 2.1s (the fake-shutdown case named in the issue) so the pending agent.graph.stop request would cross a liveness probe cycle.
• host-kernel.test.ts (slow domain work preserves multiplexed requests and retires only explicit deadlines) — the test slept 2.1s while holding an admitted request open before releasing its gate.

Both waits existed to prove the #2392 contract: liveness probes never retire a request that has no explicit deadline. The 2s value is incidental to that contract — what matters is that at least one probe fires while the request is pending.

The probe interval is now injectable: ConnectRuntimeHostInput.livenessIntervalMs (validated by the same requireTimeout as the existing timeout options, default unchanged at 2s), threaded through connectResolvedRuntimeHost into the connection's #scheduleLivenessCheck. Both tests inject a 100ms cadence and derive their waits from it (2 cycles + margin) — the wait is now measured in a unit the test controls instead of guessed against a constant it cannot see.

Retained contracts

• Probe-crossing semantics are exercised identically: with the 100ms cadence, two probes fire while the request is pending, and the request still completes with its real result.
• The probe timeout (DEFAULT_LIVENESS_TIMEOUT_MS), handshake/connect deadlines, and the explicit 50ms read_timeout case in the host-kernel test are untouched.
• The remaining short sleeps in this workspace are all poll intervals inside bounded wait loops (already observable completion) — audited and left as-is.

Production surface

One additive optional field on ConnectRuntimeHostInput; passing nothing preserves today's behavior exactly.

Timing (local, node --test)

Test	Before	After
two UDS Clients query and control one Agent graph…	~2.5s	0.36s
slow domain work preserves multiplexed requests…	~2.6s	0.38s

Full workspace suite after a clean build: 734/734 pass.

[Astro-Han]

Thanks for this. The injected cadence matches the existing connectTimeoutMs/handshakeTimeoutMs pattern, default behavior is unchanged (2s), and both tests are genuinely faster (430/450ms). The assertions still bite: if #2392 regresses, the pending request gets retired and the deepEqual fails.

One gap: the tests can't tell "probes fired and the request survived" from "probes never fired". If a future change stops using livenessIntervalMs in the constructor (types still compile), every assertion passes with zero probes in the window. A probe counter on the server side, asserted before release, would make the premise falsifiable. Cheap to add.

Nit: livenessIntervalMs is validated in the constructor, after connect + handshake, so a bad value surfaces as "handshake_failed" instead of a config error; the other timeouts validate up front. Approving.

[UncertaintyDeterminesYou4ndMe]

Both points addressed in bad4d15:

• Falsifiable premise: ConnectRuntimeHostInput.onLivenessProbe fires after a probe round-trips and validates its Host Epoch. The host-kernel test now releases the admitted request only after two observed probe round-trips (bounded — a cadence that stops taking effect times out loudly instead of vacuously passing), and the Agent-graph fake's stop() awaits that same crossing instead of a derived sleep, so the ordering is causal with no fixed timing left at all.
• Nit: livenessIntervalMs is now validated up front in connectResolvedRuntimeHost alongside connectTimeoutMs/handshakeTimeoutMs, so a bad value surfaces as a config error, not handshake_failed.

Both tests got faster again (~0.29s / ~0.33s); 734/734 after a clean build.

[Astro-Han]

Thanks for the follow-up. Both review points are substantively addressed:

• the tests now wait for observed, epoch-validated probe round-trips instead of assuming the injected cadence fired;
• livenessIntervalMs is validated before transport and handshake work, consistently with the existing timeout options.

The resulting tests are faster and their probe-crossing premise is now falsifiable.

P3 — Test observability is exposed through the public client input.

onLivenessProbe is documented as a test hook but is now part of the exported ConnectRuntimeHostInput. Its callback also runs inside the probe success chain, so an observer exception can fail the connection.

This is non-blocking because existing callers do not pass it and default production behavior is unchanged. Longer term, I would prefer observing probes through a package-internal test seam or Host/transport fixture. If the callback remains a public diagnostics hook, its exceptions should be isolated from connection health.

Small test-scoping suggestion: in the Agent Graph test, pass the probe observer only to the final TUI connection that issues agent.graph.stop. That makes it impossible for an earlier slow query on another connection to satisfy the shared counter.

The requested follow-up is effective, and I found no blocking issue. Approved.

简体中文

感谢继续修改。上一轮的两个问题都已经得到实质解决：

• 测试现在等待实际观察到、并完成 Host Epoch 校验的 probe round-trip，不再假设注入的 cadence 已经触发；
• livenessIntervalMs 现在与现有 timeout 配置一样，在 transport 和 handshake 之前完成校验。

测试变得更快，而且 probe-crossing 前提现在可以被证伪。

P3 — 测试观测能力进入了公开 client input。

onLivenessProbe 的文档明确说明它是 test hook，但它现在属于公开导出的 ConnectRuntimeHostInput。callback 还运行在 probe success chain 内，因此 observer 抛出的异常可能导致连接失败。

这是非阻塞问题，因为现有调用方不会传入它，默认生产行为也没有变化。长期来看，更适合通过 package-internal 测试 seam 或 Host/transport fixture 观察 probe。如果保留为公开 diagnostics hook，则 observer 异常不应影响连接健康。

还有一个小的测试作用域建议：Agent Graph 测试只给最终执行 agent.graph.stop 的 TUI connection 传入 probe observer。这样前面其他 connection 上的慢查询就不可能提前满足共享 counter。

本轮修改有效，没有发现阻塞问题。Approve。

[UncertaintyDeterminesYou4ndMe]

Both follow-ups applied in fc78317:

• Observer isolation: onLivenessProbe exceptions are now swallowed at the call site — a diagnostics hook can no longer fail the connection it is watching — and the input doc states that contract explicitly. On the longer-term point: agreed a package-internal seam would be cleaner; if a second consumer of probe observability ever appears, that's the moment to move it behind a Host/transport fixture rather than the public input.
• Test scoping: the Agent-graph observer is now wired only onto the final TUI connection that issues agent.graph.stop, so no other connection's slow query can satisfy the shared counter.

Suite green after a clean build; typecheck and biome pass.

[UncertaintyDeterminesYou4ndMe]

Part of #2389 (Runtime Host workspace; the Pi TUI workspace landed as #2448, desktop e2e and alignment audit follow separately).

What changed

Two tests held work pending for a fixed 2.1s purely to outlive the client connection's hardcoded DEFAULT_LIVENESS_INTERVAL_MS = 2_000:

• agent-graph-two-client-uds.test.ts — FakeAgentGraphAuthority.stop() slept 2.1s (the fake-shutdown case named in the issue) so the pending agent.graph.stop request would cross a liveness probe cycle.
• host-kernel.test.ts (slow domain work preserves multiplexed requests and retires only explicit deadlines) — the test slept 2.1s while holding an admitted request open before releasing its gate.

Both waits existed to prove the #2392 contract: liveness probes never retire a request that has no explicit deadline. The 2s value is incidental to that contract — what matters is that at least one probe fires while the request is pending.

The probe interval is now injectable: ConnectRuntimeHostInput.livenessIntervalMs (validated by the same requireTimeout as the existing timeout options, default unchanged at 2s), threaded through connectResolvedRuntimeHost into the connection's #scheduleLivenessCheck. Both tests inject a 100ms cadence and derive their waits from it (2 cycles + margin) — the wait is now measured in a unit the test controls instead of guessed against a constant it cannot see.

Retained contracts

• Probe-crossing semantics are exercised identically: with the 100ms cadence, two probes fire while the request is pending, and the request still completes with its real result.
• The probe timeout (DEFAULT_LIVENESS_TIMEOUT_MS), handshake/connect deadlines, and the explicit 50ms read_timeout case in the host-kernel test are untouched.
• The remaining short sleeps in this workspace are all poll intervals inside bounded wait loops (already observable completion) — audited and left as-is.

Production surface

One additive optional field on ConnectRuntimeHostInput; passing nothing preserves today's behavior exactly.

Timing (local, node --test)

Test	Before	After
two UDS Clients query and control one Agent graph…	~2.5s	0.36s
slow domain work preserves multiplexed requests…	~2.6s	0.38s

Full workspace suite after a clean build: 734/734 pass.

[Astro-Han]

Thanks for this. The injected cadence matches the existing connectTimeoutMs/handshakeTimeoutMs pattern, default behavior is unchanged (2s), and both tests are genuinely faster (430/450ms). The assertions still bite: if #2392 regresses, the pending request gets retired and the deepEqual fails.

One gap: the tests can't tell "probes fired and the request survived" from "probes never fired". If a future change stops using livenessIntervalMs in the constructor (types still compile), every assertion passes with zero probes in the window. A probe counter on the server side, asserted before release, would make the premise falsifiable. Cheap to add.

Nit: livenessIntervalMs is validated in the constructor, after connect + handshake, so a bad value surfaces as "handshake_failed" instead of a config error; the other timeouts validate up front. Approving.

[UncertaintyDeterminesYou4ndMe]

Both points addressed in bad4d15:

• Falsifiable premise: ConnectRuntimeHostInput.onLivenessProbe fires after a probe round-trips and validates its Host Epoch. The host-kernel test now releases the admitted request only after two observed probe round-trips (bounded — a cadence that stops taking effect times out loudly instead of vacuously passing), and the Agent-graph fake's stop() awaits that same crossing instead of a derived sleep, so the ordering is causal with no fixed timing left at all.
• Nit: livenessIntervalMs is now validated up front in connectResolvedRuntimeHost alongside connectTimeoutMs/handshakeTimeoutMs, so a bad value surfaces as a config error, not handshake_failed.

Both tests got faster again (~0.29s / ~0.33s); 734/734 after a clean build.

[Astro-Han]

Thanks for the follow-up. Both review points are substantively addressed:

• the tests now wait for observed, epoch-validated probe round-trips instead of assuming the injected cadence fired;
• livenessIntervalMs is validated before transport and handshake work, consistently with the existing timeout options.

The resulting tests are faster and their probe-crossing premise is now falsifiable.

P3 — Test observability is exposed through the public client input.

onLivenessProbe is documented as a test hook but is now part of the exported ConnectRuntimeHostInput. Its callback also runs inside the probe success chain, so an observer exception can fail the connection.

This is non-blocking because existing callers do not pass it and default production behavior is unchanged. Longer term, I would prefer observing probes through a package-internal test seam or Host/transport fixture. If the callback remains a public diagnostics hook, its exceptions should be isolated from connection health.

Small test-scoping suggestion: in the Agent Graph test, pass the probe observer only to the final TUI connection that issues agent.graph.stop. That makes it impossible for an earlier slow query on another connection to satisfy the shared counter.

The requested follow-up is effective, and I found no blocking issue. Approved.

简体中文

感谢继续修改。上一轮的两个问题都已经得到实质解决：

• 测试现在等待实际观察到、并完成 Host Epoch 校验的 probe round-trip，不再假设注入的 cadence 已经触发；
• livenessIntervalMs 现在与现有 timeout 配置一样，在 transport 和 handshake 之前完成校验。

测试变得更快，而且 probe-crossing 前提现在可以被证伪。

P3 — 测试观测能力进入了公开 client input。

onLivenessProbe 的文档明确说明它是 test hook，但它现在属于公开导出的 ConnectRuntimeHostInput。callback 还运行在 probe success chain 内，因此 observer 抛出的异常可能导致连接失败。

这是非阻塞问题，因为现有调用方不会传入它，默认生产行为也没有变化。长期来看，更适合通过 package-internal 测试 seam 或 Host/transport fixture 观察 probe。如果保留为公开 diagnostics hook，则 observer 异常不应影响连接健康。

还有一个小的测试作用域建议：Agent Graph 测试只给最终执行 agent.graph.stop 的 TUI connection 传入 probe observer。这样前面其他 connection 上的慢查询就不可能提前满足共享 counter。

本轮修改有效，没有发现阻塞问题。Approve。

[UncertaintyDeterminesYou4ndMe]

Both follow-ups applied in fc78317:

• Observer isolation: onLivenessProbe exceptions are now swallowed at the call site — a diagnostics hook can no longer fail the connection it is watching — and the input doc states that contract explicitly. On the longer-term point: agreed a package-internal seam would be cleaner; if a second consumer of probe observability ever appears, that's the moment to move it behind a Host/transport fixture rather than the public input.
• Test scoping: the Agent-graph observer is now wired only onto the final TUI connection that issues agent.graph.stop, so no other connection's slow query can satisfy the shared counter.

Suite green after a clean build; typecheck and biome pass.

[UncertaintyDeterminesYou4ndMe]

Part of #2389 (Runtime Host workspace; the Pi TUI workspace landed as #2448, desktop e2e and alignment audit follow separately).

What changed

Two tests held work pending for a fixed 2.1s purely to outlive the client connection's hardcoded DEFAULT_LIVENESS_INTERVAL_MS = 2_000:

• agent-graph-two-client-uds.test.ts — FakeAgentGraphAuthority.stop() slept 2.1s (the fake-shutdown case named in the issue) so the pending agent.graph.stop request would cross a liveness probe cycle.
• host-kernel.test.ts (slow domain work preserves multiplexed requests and retires only explicit deadlines) — the test slept 2.1s while holding an admitted request open before releasing its gate.

Both waits existed to prove the #2392 contract: liveness probes never retire a request that has no explicit deadline. The 2s value is incidental to that contract — what matters is that at least one probe fires while the request is pending.

The probe interval is now injectable: ConnectRuntimeHostInput.livenessIntervalMs (validated by the same requireTimeout as the existing timeout options, default unchanged at 2s), threaded through connectResolvedRuntimeHost into the connection's #scheduleLivenessCheck. Both tests inject a 100ms cadence and derive their waits from it (2 cycles + margin) — the wait is now measured in a unit the test controls instead of guessed against a constant it cannot see.

Retained contracts

• Probe-crossing semantics are exercised identically: with the 100ms cadence, two probes fire while the request is pending, and the request still completes with its real result.
• The probe timeout (DEFAULT_LIVENESS_TIMEOUT_MS), handshake/connect deadlines, and the explicit 50ms read_timeout case in the host-kernel test are untouched.
• The remaining short sleeps in this workspace are all poll intervals inside bounded wait loops (already observable completion) — audited and left as-is.

Production surface

One additive optional field on ConnectRuntimeHostInput; passing nothing preserves today's behavior exactly.

Timing (local, node --test)

Test	Before	After
two UDS Clients query and control one Agent graph…	~2.5s	0.36s
slow domain work preserves multiplexed requests…	~2.6s	0.38s

Full workspace suite after a clean build: 734/734 pass.

[Astro-Han]

Thanks for this. The injected cadence matches the existing connectTimeoutMs/handshakeTimeoutMs pattern, default behavior is unchanged (2s), and both tests are genuinely faster (430/450ms). The assertions still bite: if #2392 regresses, the pending request gets retired and the deepEqual fails.

One gap: the tests can't tell "probes fired and the request survived" from "probes never fired". If a future change stops using livenessIntervalMs in the constructor (types still compile), every assertion passes with zero probes in the window. A probe counter on the server side, asserted before release, would make the premise falsifiable. Cheap to add.

Nit: livenessIntervalMs is validated in the constructor, after connect + handshake, so a bad value surfaces as "handshake_failed" instead of a config error; the other timeouts validate up front. Approving.

[UncertaintyDeterminesYou4ndMe]

Both points addressed in bad4d15:

• Falsifiable premise: ConnectRuntimeHostInput.onLivenessProbe fires after a probe round-trips and validates its Host Epoch. The host-kernel test now releases the admitted request only after two observed probe round-trips (bounded — a cadence that stops taking effect times out loudly instead of vacuously passing), and the Agent-graph fake's stop() awaits that same crossing instead of a derived sleep, so the ordering is causal with no fixed timing left at all.
• Nit: livenessIntervalMs is now validated up front in connectResolvedRuntimeHost alongside connectTimeoutMs/handshakeTimeoutMs, so a bad value surfaces as a config error, not handshake_failed.

Both tests got faster again (~0.29s / ~0.33s); 734/734 after a clean build.

[Astro-Han]

Thanks for the follow-up. Both review points are substantively addressed:

• the tests now wait for observed, epoch-validated probe round-trips instead of assuming the injected cadence fired;
• livenessIntervalMs is validated before transport and handshake work, consistently with the existing timeout options.

The resulting tests are faster and their probe-crossing premise is now falsifiable.

P3 — Test observability is exposed through the public client input.

onLivenessProbe is documented as a test hook but is now part of the exported ConnectRuntimeHostInput. Its callback also runs inside the probe success chain, so an observer exception can fail the connection.

This is non-blocking because existing callers do not pass it and default production behavior is unchanged. Longer term, I would prefer observing probes through a package-internal test seam or Host/transport fixture. If the callback remains a public diagnostics hook, its exceptions should be isolated from connection health.

Small test-scoping suggestion: in the Agent Graph test, pass the probe observer only to the final TUI connection that issues agent.graph.stop. That makes it impossible for an earlier slow query on another connection to satisfy the shared counter.

The requested follow-up is effective, and I found no blocking issue. Approved.

简体中文

感谢继续修改。上一轮的两个问题都已经得到实质解决：

• 测试现在等待实际观察到、并完成 Host Epoch 校验的 probe round-trip，不再假设注入的 cadence 已经触发；
• livenessIntervalMs 现在与现有 timeout 配置一样，在 transport 和 handshake 之前完成校验。

测试变得更快，而且 probe-crossing 前提现在可以被证伪。

P3 — 测试观测能力进入了公开 client input。

onLivenessProbe 的文档明确说明它是 test hook，但它现在属于公开导出的 ConnectRuntimeHostInput。callback 还运行在 probe success chain 内，因此 observer 抛出的异常可能导致连接失败。

这是非阻塞问题，因为现有调用方不会传入它，默认生产行为也没有变化。长期来看，更适合通过 package-internal 测试 seam 或 Host/transport fixture 观察 probe。如果保留为公开 diagnostics hook，则 observer 异常不应影响连接健康。

还有一个小的测试作用域建议：Agent Graph 测试只给最终执行 agent.graph.stop 的 TUI connection 传入 probe observer。这样前面其他 connection 上的慢查询就不可能提前满足共享 counter。

本轮修改有效，没有发现阻塞问题。Approve。

[UncertaintyDeterminesYou4ndMe]

Both follow-ups applied in fc78317:

• Observer isolation: onLivenessProbe exceptions are now swallowed at the call site — a diagnostics hook can no longer fail the connection it is watching — and the input doc states that contract explicitly. On the longer-term point: agreed a package-internal seam would be cleaner; if a second consumer of probe observability ever appears, that's the moment to move it behind a Host/transport fixture rather than the public input.
• Test scoping: the Agent-graph observer is now wired only onto the final TUI connection that issues agent.graph.stop, so no other connection's slow query can satisfy the shared counter.

Suite green after a clean build; typecheck and biome pass.

[UncertaintyDeterminesYou4ndMe]

Part of #2389 (Runtime Host workspace; the Pi TUI workspace landed as #2448, desktop e2e and alignment audit follow separately).

What changed

Two tests held work pending for a fixed 2.1s purely to outlive the client connection's hardcoded DEFAULT_LIVENESS_INTERVAL_MS = 2_000:

• agent-graph-two-client-uds.test.ts — FakeAgentGraphAuthority.stop() slept 2.1s (the fake-shutdown case named in the issue) so the pending agent.graph.stop request would cross a liveness probe cycle.
• host-kernel.test.ts (slow domain work preserves multiplexed requests and retires only explicit deadlines) — the test slept 2.1s while holding an admitted request open before releasing its gate.

Both waits existed to prove the #2392 contract: liveness probes never retire a request that has no explicit deadline. The 2s value is incidental to that contract — what matters is that at least one probe fires while the request is pending.

The probe interval is now injectable: ConnectRuntimeHostInput.livenessIntervalMs (validated by the same requireTimeout as the existing timeout options, default unchanged at 2s), threaded through connectResolvedRuntimeHost into the connection's #scheduleLivenessCheck. Both tests inject a 100ms cadence and derive their waits from it (2 cycles + margin) — the wait is now measured in a unit the test controls instead of guessed against a constant it cannot see.

Retained contracts

• Probe-crossing semantics are exercised identically: with the 100ms cadence, two probes fire while the request is pending, and the request still completes with its real result.
• The probe timeout (DEFAULT_LIVENESS_TIMEOUT_MS), handshake/connect deadlines, and the explicit 50ms read_timeout case in the host-kernel test are untouched.
• The remaining short sleeps in this workspace are all poll intervals inside bounded wait loops (already observable completion) — audited and left as-is.

Production surface

One additive optional field on ConnectRuntimeHostInput; passing nothing preserves today's behavior exactly.

Timing (local, node --test)

Test	Before	After
two UDS Clients query and control one Agent graph…	~2.5s	0.36s
slow domain work preserves multiplexed requests…	~2.6s	0.38s

Full workspace suite after a clean build: 734/734 pass.

[Astro-Han]

Thanks for this. The injected cadence matches the existing connectTimeoutMs/handshakeTimeoutMs pattern, default behavior is unchanged (2s), and both tests are genuinely faster (430/450ms). The assertions still bite: if #2392 regresses, the pending request gets retired and the deepEqual fails.

One gap: the tests can't tell "probes fired and the request survived" from "probes never fired". If a future change stops using livenessIntervalMs in the constructor (types still compile), every assertion passes with zero probes in the window. A probe counter on the server side, asserted before release, would make the premise falsifiable. Cheap to add.

Nit: livenessIntervalMs is validated in the constructor, after connect + handshake, so a bad value surfaces as "handshake_failed" instead of a config error; the other timeouts validate up front. Approving.

[UncertaintyDeterminesYou4ndMe]

Both points addressed in bad4d15:

• Falsifiable premise: ConnectRuntimeHostInput.onLivenessProbe fires after a probe round-trips and validates its Host Epoch. The host-kernel test now releases the admitted request only after two observed probe round-trips (bounded — a cadence that stops taking effect times out loudly instead of vacuously passing), and the Agent-graph fake's stop() awaits that same crossing instead of a derived sleep, so the ordering is causal with no fixed timing left at all.
• Nit: livenessIntervalMs is now validated up front in connectResolvedRuntimeHost alongside connectTimeoutMs/handshakeTimeoutMs, so a bad value surfaces as a config error, not handshake_failed.

Both tests got faster again (~0.29s / ~0.33s); 734/734 after a clean build.

[Astro-Han]

Thanks for the follow-up. Both review points are substantively addressed:

• the tests now wait for observed, epoch-validated probe round-trips instead of assuming the injected cadence fired;
• livenessIntervalMs is validated before transport and handshake work, consistently with the existing timeout options.

The resulting tests are faster and their probe-crossing premise is now falsifiable.

P3 — Test observability is exposed through the public client input.

onLivenessProbe is documented as a test hook but is now part of the exported ConnectRuntimeHostInput. Its callback also runs inside the probe success chain, so an observer exception can fail the connection.

This is non-blocking because existing callers do not pass it and default production behavior is unchanged. Longer term, I would prefer observing probes through a package-internal test seam or Host/transport fixture. If the callback remains a public diagnostics hook, its exceptions should be isolated from connection health.

Small test-scoping suggestion: in the Agent Graph test, pass the probe observer only to the final TUI connection that issues agent.graph.stop. That makes it impossible for an earlier slow query on another connection to satisfy the shared counter.

The requested follow-up is effective, and I found no blocking issue. Approved.

简体中文

感谢继续修改。上一轮的两个问题都已经得到实质解决：

• 测试现在等待实际观察到、并完成 Host Epoch 校验的 probe round-trip，不再假设注入的 cadence 已经触发；
• livenessIntervalMs 现在与现有 timeout 配置一样，在 transport 和 handshake 之前完成校验。

测试变得更快，而且 probe-crossing 前提现在可以被证伪。

P3 — 测试观测能力进入了公开 client input。

onLivenessProbe 的文档明确说明它是 test hook，但它现在属于公开导出的 ConnectRuntimeHostInput。callback 还运行在 probe success chain 内，因此 observer 抛出的异常可能导致连接失败。

这是非阻塞问题，因为现有调用方不会传入它，默认生产行为也没有变化。长期来看，更适合通过 package-internal 测试 seam 或 Host/transport fixture 观察 probe。如果保留为公开 diagnostics hook，则 observer 异常不应影响连接健康。

还有一个小的测试作用域建议：Agent Graph 测试只给最终执行 agent.graph.stop 的 TUI connection 传入 probe observer。这样前面其他 connection 上的慢查询就不可能提前满足共享 counter。

本轮修改有效，没有发现阻塞问题。Approve。

[UncertaintyDeterminesYou4ndMe]

Both follow-ups applied in fc78317:

• Observer isolation: onLivenessProbe exceptions are now swallowed at the call site — a diagnostics hook can no longer fail the connection it is watching — and the input doc states that contract explicitly. On the longer-term point: agreed a package-internal seam would be cleaner; if a second consumer of probe observability ever appears, that's the moment to move it behind a Host/transport fixture rather than the public input.
• Test scoping: the Agent-graph observer is now wired only onto the final TUI connection that issues agent.graph.stop, so no other connection's slow query can satisfy the shared counter.

Suite green after a clean build; typecheck and biome pass.

[UncertaintyDeterminesYou4ndMe]

Part of #2389 (Runtime Host workspace; the Pi TUI workspace landed as #2448, desktop e2e and alignment audit follow separately).

What changed

Two tests held work pending for a fixed 2.1s purely to outlive the client connection's hardcoded DEFAULT_LIVENESS_INTERVAL_MS = 2_000:

• agent-graph-two-client-uds.test.ts — FakeAgentGraphAuthority.stop() slept 2.1s (the fake-shutdown case named in the issue) so the pending agent.graph.stop request would cross a liveness probe cycle.
• host-kernel.test.ts (slow domain work preserves multiplexed requests and retires only explicit deadlines) — the test slept 2.1s while holding an admitted request open before releasing its gate.

Both waits existed to prove the #2392 contract: liveness probes never retire a request that has no explicit deadline. The 2s value is incidental to that contract — what matters is that at least one probe fires while the request is pending.

The probe interval is now injectable: ConnectRuntimeHostInput.livenessIntervalMs (validated by the same requireTimeout as the existing timeout options, default unchanged at 2s), threaded through connectResolvedRuntimeHost into the connection's #scheduleLivenessCheck. Both tests inject a 100ms cadence and derive their waits from it (2 cycles + margin) — the wait is now measured in a unit the test controls instead of guessed against a constant it cannot see.

Retained contracts

• Probe-crossing semantics are exercised identically: with the 100ms cadence, two probes fire while the request is pending, and the request still completes with its real result.
• The probe timeout (DEFAULT_LIVENESS_TIMEOUT_MS), handshake/connect deadlines, and the explicit 50ms read_timeout case in the host-kernel test are untouched.
• The remaining short sleeps in this workspace are all poll intervals inside bounded wait loops (already observable completion) — audited and left as-is.

Production surface

One additive optional field on ConnectRuntimeHostInput; passing nothing preserves today's behavior exactly.

Timing (local, node --test)

Test	Before	After
two UDS Clients query and control one Agent graph…	~2.5s	0.36s
slow domain work preserves multiplexed requests…	~2.6s	0.38s

Full workspace suite after a clean build: 734/734 pass.

[Astro-Han]

Thanks for this. The injected cadence matches the existing connectTimeoutMs/handshakeTimeoutMs pattern, default behavior is unchanged (2s), and both tests are genuinely faster (430/450ms). The assertions still bite: if #2392 regresses, the pending request gets retired and the deepEqual fails.

One gap: the tests can't tell "probes fired and the request survived" from "probes never fired". If a future change stops using livenessIntervalMs in the constructor (types still compile), every assertion passes with zero probes in the window. A probe counter on the server side, asserted before release, would make the premise falsifiable. Cheap to add.

Nit: livenessIntervalMs is validated in the constructor, after connect + handshake, so a bad value surfaces as "handshake_failed" instead of a config error; the other timeouts validate up front. Approving.

[UncertaintyDeterminesYou4ndMe]

Both points addressed in bad4d15:

• Falsifiable premise: ConnectRuntimeHostInput.onLivenessProbe fires after a probe round-trips and validates its Host Epoch. The host-kernel test now releases the admitted request only after two observed probe round-trips (bounded — a cadence that stops taking effect times out loudly instead of vacuously passing), and the Agent-graph fake's stop() awaits that same crossing instead of a derived sleep, so the ordering is causal with no fixed timing left at all.
• Nit: livenessIntervalMs is now validated up front in connectResolvedRuntimeHost alongside connectTimeoutMs/handshakeTimeoutMs, so a bad value surfaces as a config error, not handshake_failed.

Both tests got faster again (~0.29s / ~0.33s); 734/734 after a clean build.

[Astro-Han]

Thanks for the follow-up. Both review points are substantively addressed:

• the tests now wait for observed, epoch-validated probe round-trips instead of assuming the injected cadence fired;
• livenessIntervalMs is validated before transport and handshake work, consistently with the existing timeout options.

The resulting tests are faster and their probe-crossing premise is now falsifiable.

P3 — Test observability is exposed through the public client input.

onLivenessProbe is documented as a test hook but is now part of the exported ConnectRuntimeHostInput. Its callback also runs inside the probe success chain, so an observer exception can fail the connection.

This is non-blocking because existing callers do not pass it and default production behavior is unchanged. Longer term, I would prefer observing probes through a package-internal test seam or Host/transport fixture. If the callback remains a public diagnostics hook, its exceptions should be isolated from connection health.

Small test-scoping suggestion: in the Agent Graph test, pass the probe observer only to the final TUI connection that issues agent.graph.stop. That makes it impossible for an earlier slow query on another connection to satisfy the shared counter.

The requested follow-up is effective, and I found no blocking issue. Approved.

简体中文

感谢继续修改。上一轮的两个问题都已经得到实质解决：

• 测试现在等待实际观察到、并完成 Host Epoch 校验的 probe round-trip，不再假设注入的 cadence 已经触发；
• livenessIntervalMs 现在与现有 timeout 配置一样，在 transport 和 handshake 之前完成校验。

测试变得更快，而且 probe-crossing 前提现在可以被证伪。

P3 — 测试观测能力进入了公开 client input。

onLivenessProbe 的文档明确说明它是 test hook，但它现在属于公开导出的 ConnectRuntimeHostInput。callback 还运行在 probe success chain 内，因此 observer 抛出的异常可能导致连接失败。

这是非阻塞问题，因为现有调用方不会传入它，默认生产行为也没有变化。长期来看，更适合通过 package-internal 测试 seam 或 Host/transport fixture 观察 probe。如果保留为公开 diagnostics hook，则 observer 异常不应影响连接健康。

还有一个小的测试作用域建议：Agent Graph 测试只给最终执行 agent.graph.stop 的 TUI connection 传入 probe observer。这样前面其他 connection 上的慢查询就不可能提前满足共享 counter。

本轮修改有效，没有发现阻塞问题。Approve。

[UncertaintyDeterminesYou4ndMe]

Both follow-ups applied in fc78317:

• Observer isolation: onLivenessProbe exceptions are now swallowed at the call site — a diagnostics hook can no longer fail the connection it is watching — and the input doc states that contract explicitly. On the longer-term point: agreed a package-internal seam would be cleaner; if a second consumer of probe observability ever appears, that's the moment to move it behind a Host/transport fixture rather than the public input.
• Test scoping: the Agent-graph observer is now wired only onto the final TUI connection that issues agent.graph.stop, so no other connection's slow query can satisfy the shared counter.

Suite green after a clean build; typecheck and biome pass.

[UncertaintyDeterminesYou4ndMe]

Part of #2389 (Runtime Host workspace; the Pi TUI workspace landed as #2448, desktop e2e and alignment audit follow separately).

What changed

Two tests held work pending for a fixed 2.1s purely to outlive the client connection's hardcoded DEFAULT_LIVENESS_INTERVAL_MS = 2_000:

• agent-graph-two-client-uds.test.ts — FakeAgentGraphAuthority.stop() slept 2.1s (the fake-shutdown case named in the issue) so the pending agent.graph.stop request would cross a liveness probe cycle.
• host-kernel.test.ts (slow domain work preserves multiplexed requests and retires only explicit deadlines) — the test slept 2.1s while holding an admitted request open before releasing its gate.

Both waits existed to prove the #2392 contract: liveness probes never retire a request that has no explicit deadline. The 2s value is incidental to that contract — what matters is that at least one probe fires while the request is pending.

The probe interval is now injectable: ConnectRuntimeHostInput.livenessIntervalMs (validated by the same requireTimeout as the existing timeout options, default unchanged at 2s), threaded through connectResolvedRuntimeHost into the connection's #scheduleLivenessCheck. Both tests inject a 100ms cadence and derive their waits from it (2 cycles + margin) — the wait is now measured in a unit the test controls instead of guessed against a constant it cannot see.

Retained contracts

• Probe-crossing semantics are exercised identically: with the 100ms cadence, two probes fire while the request is pending, and the request still completes with its real result.
• The probe timeout (DEFAULT_LIVENESS_TIMEOUT_MS), handshake/connect deadlines, and the explicit 50ms read_timeout case in the host-kernel test are untouched.
• The remaining short sleeps in this workspace are all poll intervals inside bounded wait loops (already observable completion) — audited and left as-is.

Production surface

One additive optional field on ConnectRuntimeHostInput; passing nothing preserves today's behavior exactly.

Timing (local, node --test)

Test	Before	After
two UDS Clients query and control one Agent graph…	~2.5s	0.36s
slow domain work preserves multiplexed requests…	~2.6s	0.38s

Full workspace suite after a clean build: 734/734 pass.

[Astro-Han]

Thanks for this. The injected cadence matches the existing connectTimeoutMs/handshakeTimeoutMs pattern, default behavior is unchanged (2s), and both tests are genuinely faster (430/450ms). The assertions still bite: if #2392 regresses, the pending request gets retired and the deepEqual fails.

One gap: the tests can't tell "probes fired and the request survived" from "probes never fired". If a future change stops using livenessIntervalMs in the constructor (types still compile), every assertion passes with zero probes in the window. A probe counter on the server side, asserted before release, would make the premise falsifiable. Cheap to add.

Nit: livenessIntervalMs is validated in the constructor, after connect + handshake, so a bad value surfaces as "handshake_failed" instead of a config error; the other timeouts validate up front. Approving.

[UncertaintyDeterminesYou4ndMe]

Both points addressed in bad4d15:

• Falsifiable premise: ConnectRuntimeHostInput.onLivenessProbe fires after a probe round-trips and validates its Host Epoch. The host-kernel test now releases the admitted request only after two observed probe round-trips (bounded — a cadence that stops taking effect times out loudly instead of vacuously passing), and the Agent-graph fake's stop() awaits that same crossing instead of a derived sleep, so the ordering is causal with no fixed timing left at all.
• Nit: livenessIntervalMs is now validated up front in connectResolvedRuntimeHost alongside connectTimeoutMs/handshakeTimeoutMs, so a bad value surfaces as a config error, not handshake_failed.

Both tests got faster again (~0.29s / ~0.33s); 734/734 after a clean build.

[Astro-Han]

Thanks for the follow-up. Both review points are substantively addressed:

• the tests now wait for observed, epoch-validated probe round-trips instead of assuming the injected cadence fired;
• livenessIntervalMs is validated before transport and handshake work, consistently with the existing timeout options.

The resulting tests are faster and their probe-crossing premise is now falsifiable.

P3 — Test observability is exposed through the public client input.

onLivenessProbe is documented as a test hook but is now part of the exported ConnectRuntimeHostInput. Its callback also runs inside the probe success chain, so an observer exception can fail the connection.

This is non-blocking because existing callers do not pass it and default production behavior is unchanged. Longer term, I would prefer observing probes through a package-internal test seam or Host/transport fixture. If the callback remains a public diagnostics hook, its exceptions should be isolated from connection health.

Small test-scoping suggestion: in the Agent Graph test, pass the probe observer only to the final TUI connection that issues agent.graph.stop. That makes it impossible for an earlier slow query on another connection to satisfy the shared counter.

The requested follow-up is effective, and I found no blocking issue. Approved.

简体中文

感谢继续修改。上一轮的两个问题都已经得到实质解决：

• 测试现在等待实际观察到、并完成 Host Epoch 校验的 probe round-trip，不再假设注入的 cadence 已经触发；
• livenessIntervalMs 现在与现有 timeout 配置一样，在 transport 和 handshake 之前完成校验。

测试变得更快，而且 probe-crossing 前提现在可以被证伪。

P3 — 测试观测能力进入了公开 client input。

onLivenessProbe 的文档明确说明它是 test hook，但它现在属于公开导出的 ConnectRuntimeHostInput。callback 还运行在 probe success chain 内，因此 observer 抛出的异常可能导致连接失败。

这是非阻塞问题，因为现有调用方不会传入它，默认生产行为也没有变化。长期来看，更适合通过 package-internal 测试 seam 或 Host/transport fixture 观察 probe。如果保留为公开 diagnostics hook，则 observer 异常不应影响连接健康。

还有一个小的测试作用域建议：Agent Graph 测试只给最终执行 agent.graph.stop 的 TUI connection 传入 probe observer。这样前面其他 connection 上的慢查询就不可能提前满足共享 counter。

本轮修改有效，没有发现阻塞问题。Approve。

[UncertaintyDeterminesYou4ndMe]

Both follow-ups applied in fc78317:

• Observer isolation: onLivenessProbe exceptions are now swallowed at the call site — a diagnostics hook can no longer fail the connection it is watching — and the input doc states that contract explicitly. On the longer-term point: agreed a package-internal seam would be cleaner; if a second consumer of probe observability ever appears, that's the moment to move it behind a Host/transport fixture rather than the public input.
• Test scoping: the Agent-graph observer is now wired only onto the final TUI connection that issues agent.graph.stop, so no other connection's slow query can satisfy the shared counter.

Suite green after a clean build; typecheck and biome pass.

[UncertaintyDeterminesYou4ndMe]

Part of #2389 (Runtime Host workspace; the Pi TUI workspace landed as #2448, desktop e2e and alignment audit follow separately).

What changed

Two tests held work pending for a fixed 2.1s purely to outlive the client connection's hardcoded DEFAULT_LIVENESS_INTERVAL_MS = 2_000:

• agent-graph-two-client-uds.test.ts — FakeAgentGraphAuthority.stop() slept 2.1s (the fake-shutdown case named in the issue) so the pending agent.graph.stop request would cross a liveness probe cycle.
• host-kernel.test.ts (slow domain work preserves multiplexed requests and retires only explicit deadlines) — the test slept 2.1s while holding an admitted request open before releasing its gate.

Both waits existed to prove the #2392 contract: liveness probes never retire a request that has no explicit deadline. The 2s value is incidental to that contract — what matters is that at least one probe fires while the request is pending.

The probe interval is now injectable: ConnectRuntimeHostInput.livenessIntervalMs (validated by the same requireTimeout as the existing timeout options, default unchanged at 2s), threaded through connectResolvedRuntimeHost into the connection's #scheduleLivenessCheck. Both tests inject a 100ms cadence and derive their waits from it (2 cycles + margin) — the wait is now measured in a unit the test controls instead of guessed against a constant it cannot see.

Retained contracts

• Probe-crossing semantics are exercised identically: with the 100ms cadence, two probes fire while the request is pending, and the request still completes with its real result.
• The probe timeout (DEFAULT_LIVENESS_TIMEOUT_MS), handshake/connect deadlines, and the explicit 50ms read_timeout case in the host-kernel test are untouched.
• The remaining short sleeps in this workspace are all poll intervals inside bounded wait loops (already observable completion) — audited and left as-is.

Production surface

One additive optional field on ConnectRuntimeHostInput; passing nothing preserves today's behavior exactly.

Timing (local, node --test)

Test	Before	After
two UDS Clients query and control one Agent graph…	~2.5s	0.36s
slow domain work preserves multiplexed requests…	~2.6s	0.38s

Full workspace suite after a clean build: 734/734 pass.

[Astro-Han]

Thanks for this. The injected cadence matches the existing connectTimeoutMs/handshakeTimeoutMs pattern, default behavior is unchanged (2s), and both tests are genuinely faster (430/450ms). The assertions still bite: if #2392 regresses, the pending request gets retired and the deepEqual fails.

One gap: the tests can't tell "probes fired and the request survived" from "probes never fired". If a future change stops using livenessIntervalMs in the constructor (types still compile), every assertion passes with zero probes in the window. A probe counter on the server side, asserted before release, would make the premise falsifiable. Cheap to add.

Nit: livenessIntervalMs is validated in the constructor, after connect + handshake, so a bad value surfaces as "handshake_failed" instead of a config error; the other timeouts validate up front. Approving.

[UncertaintyDeterminesYou4ndMe]

Both points addressed in bad4d15:

• Falsifiable premise: ConnectRuntimeHostInput.onLivenessProbe fires after a probe round-trips and validates its Host Epoch. The host-kernel test now releases the admitted request only after two observed probe round-trips (bounded — a cadence that stops taking effect times out loudly instead of vacuously passing), and the Agent-graph fake's stop() awaits that same crossing instead of a derived sleep, so the ordering is causal with no fixed timing left at all.
• Nit: livenessIntervalMs is now validated up front in connectResolvedRuntimeHost alongside connectTimeoutMs/handshakeTimeoutMs, so a bad value surfaces as a config error, not handshake_failed.

Both tests got faster again (~0.29s / ~0.33s); 734/734 after a clean build.

[Astro-Han]

Thanks for the follow-up. Both review points are substantively addressed:

• the tests now wait for observed, epoch-validated probe round-trips instead of assuming the injected cadence fired;
• livenessIntervalMs is validated before transport and handshake work, consistently with the existing timeout options.

The resulting tests are faster and their probe-crossing premise is now falsifiable.

P3 — Test observability is exposed through the public client input.

onLivenessProbe is documented as a test hook but is now part of the exported ConnectRuntimeHostInput. Its callback also runs inside the probe success chain, so an observer exception can fail the connection.

This is non-blocking because existing callers do not pass it and default production behavior is unchanged. Longer term, I would prefer observing probes through a package-internal test seam or Host/transport fixture. If the callback remains a public diagnostics hook, its exceptions should be isolated from connection health.

Small test-scoping suggestion: in the Agent Graph test, pass the probe observer only to the final TUI connection that issues agent.graph.stop. That makes it impossible for an earlier slow query on another connection to satisfy the shared counter.

The requested follow-up is effective, and I found no blocking issue. Approved.

简体中文

感谢继续修改。上一轮的两个问题都已经得到实质解决：

• 测试现在等待实际观察到、并完成 Host Epoch 校验的 probe round-trip，不再假设注入的 cadence 已经触发；
• livenessIntervalMs 现在与现有 timeout 配置一样，在 transport 和 handshake 之前完成校验。

测试变得更快，而且 probe-crossing 前提现在可以被证伪。

P3 — 测试观测能力进入了公开 client input。

onLivenessProbe 的文档明确说明它是 test hook，但它现在属于公开导出的 ConnectRuntimeHostInput。callback 还运行在 probe success chain 内，因此 observer 抛出的异常可能导致连接失败。

这是非阻塞问题，因为现有调用方不会传入它，默认生产行为也没有变化。长期来看，更适合通过 package-internal 测试 seam 或 Host/transport fixture 观察 probe。如果保留为公开 diagnostics hook，则 observer 异常不应影响连接健康。

还有一个小的测试作用域建议：Agent Graph 测试只给最终执行 agent.graph.stop 的 TUI connection 传入 probe observer。这样前面其他 connection 上的慢查询就不可能提前满足共享 counter。

本轮修改有效，没有发现阻塞问题。Approve。

[UncertaintyDeterminesYou4ndMe]

Both follow-ups applied in fc78317:

• Observer isolation: onLivenessProbe exceptions are now swallowed at the call site — a diagnostics hook can no longer fail the connection it is watching — and the input doc states that contract explicitly. On the longer-term point: agreed a package-internal seam would be cleaner; if a second consumer of probe observability ever appears, that's the moment to move it behind a Host/transport fixture rather than the public input.
• Test scoping: the Agent-graph observer is now wired only onto the final TUI connection that issues agent.graph.stop, so no other connection's slow query can satisfy the shared counter.

Suite green after a clean build; typecheck and biome pass.