test(runtime): comms-loss → identical-value recovery contract + silent-resubscribe control (03/S15)

archreview/plans/R3-02-stale-good-family-plan.md

@@ -707,3 +707,27 @@ test could only pass once the production change landed.
   `MeterListener` sees every measurement in the process).
 - The latch counts **RawPaths**, so the raw node and its UNS mirrors report as one ref — the operator is
   told how many tags did not come back, not how many nodes.
+
+### T10 — S15 end-to-end recovery contract + silent-resubscribe control
+
+- RED: `--filter "…DriverHostCommsLossRecoveryTests"` ⇒ **2 failed**, `Timeout 00:00:15 while waiting for
+  a message of type …AttributeValueBatchUpdate` (before `AttributeStatusBatchUpdate` even existed in the
+  first draft, and again while the fake's instance id disagreed — see below).
+- GREEN: 2/2 (33 s wall clock — see the reconnect-interval note). `Runtime.Tests` `~Drivers` filter:
+  333 passed / 3 skipped.
+- **Two harness facts worth keeping** (both cost a red run to find):
+  - `DriverInstanceActor` takes its instance id from **`driver.DriverInstanceId`**, not from the spec the
+    host spawned it with. A fake returning a different id publishes under a key the host's ref map does
+    not contain, and every value is silently dropped as unmapped. The fake now takes the id.
+  - The fake's push-on-subscribe fires on the FIRST subscribe too, so the pre-outage value must come from
+    that push rather than from a separate seeding call — otherwise the probe holds an extra batch.
+- **Deviation:** the plan sketched driving the outage with the #527 watchdog (`commsLossTimeout` 200 ms).
+  The host spawns its children with the **default** `reconnectInterval`/`healthPollInterval` and exposes
+  no seam for either, so the outage is driven by the production `ReconnectDriver` (operator Force
+  Reconnect) command instead — same `Reconnecting` entry, same `ConnectivityChanged(false)`, and it does
+  not touch `HandleRestartDriver` (R3-03's). The watchdog's own trip condition stays covered by
+  `DriverInstanceActorCommsLossWatchdogTests`. The 10 s `DefaultReconnectInterval` is why these two tests
+  take ~15 s each.
+- The identical-value rule is honoured: the driver pushes **5.0 Good** before and after the outage, so the
+  recovery assertion cannot be satisfied by a value change. The control (`InitialPush = null`) asserts
+  `ExpectNoMsg` — no Good ever arrives — and that the audit fires with exactly 1 latched ref.

archreview/plans/R3-02-stale-good-family-plan.md.tasks.json

@@ -71,7 +71,7 @@
     {
       "id": "T10",
       "subject": "S15 end-to-end recovery contract test: real DriverInstanceActor + scripted fake with IDENTICAL-value initial push; silent-resubscribe falsification control",
-      "status": "pending",
+      "status": "done",
       "blockedBy": [
         "T9"
       ]