The T14 rows that need the host to reach the machine under ToyOS are deleted, with the swap chain and the machine's end of the stream: 27 boots to 26

Cargo.toml

@@ -134,10 +134,6 @@ exclude = [
     "tests/toyos-rust-tests/tls-lib",
     "tests/toyos-rust-tests/tls-multi-crate",
     "tests/toyos-rust-tests/tls-multi-crate/dep",
-    # A host judge: a second implementation, whose dependency graph is not the
-    # harness's to resolve (`src/build.rs`, `build_host_judges`). It takes
-    # upstream tokio, where the `[patch]` below names the fork.
-    "tests/ssh-client-host",
 ]
 
 [package]
@@ -154,8 +150,6 @@ default-run = "toyos-build"
 fatfs = "0.3.6"
 fontdue = "0.9"
 gpt = "3.1.0"
-# The unprivileged ICMP datagram socket `icmp::echo` asks a metal boot over,
-# which is the platform call that replaces a `ping` binary.
 libc = "0.2"
 toml = "0.8"
 uuid = { version = "1", features = ["v4"] }
@@ -183,8 +177,7 @@ toyos-osrelease = { path = "toyos-osrelease" }
 # off a stick, so one declaration is what both sides spell it with.
 toyos-quiesce = { path = "toyos-quiesce" }
 # The swap port's name and the one program the image may give it to, so the
-# gate on every manifest and the host that asks for a swap read what the supervisor and
-# sshserver read.
+# gate on every manifest reads what the supervisor reads.
 toyos-swap = { path = "toyos-swap" }
 # The watchdog's parameter name, so the gate over `kernel/src/params.rs` reads
 # the same constant the kernel and the bootloader do.

issues/a-boot-paint-at-subsystems-ready-stalled-4-ms-on-the-t14.md

@@ -8,7 +8,7 @@ opened: 2026-10-04
 
 One T14 boot of `lantalkcase`, at `43cbe73d4` (pull request #710's head, run
 on 2026-10-04), wrote `panel: paints=10 px=8513536 us=25527 max_us=8194`. The
-machine's record for that boot is `boot.lantalkcase.panel_max_us = 3919`
+machine's record for that boot was `boot.lantalkcase.panel_max_us = 3919`
 (`tests/metal/lenovo-20w0003amz.toml`), and the judge's ceiling 7838, so the
 judge exited 1. The same kernel's four other boots of that run read `max_us`
 3921, 3802, 3878 and 3870, and the negative control's four 3837, 3883, 3927
@@ -31,7 +31,9 @@ the claim. What stalled a paint for 4.3 ms is not known — a single boot, with
 no instrument inside the paint.
 
 Owner: the orchestrator, who holds the T14 record. Exit: the stall's cause is
-named from a measurement — the review's alternating `lantalkcase` boots of
-`e81d26db8` and `43cbe73d4`, three each, comparing `max_us` and the gap from
-`subsystems ready` to the next record, is the first — and removed, and three
-`lantalkcase` boots then read `panel_max_us` inside the record's ceiling.
+named from a measurement — the review's alternating boots of `e81d26db8` and
+`43cbe73d4`, three each, comparing `max_us` and the gap from `subsystems
+ready` to the next record, is the first — and removed, and three boots of one
+image then read `panel_max_us` inside the record's ceiling. `lantalkcase` is
+deleted (`issues/the-host-cannot-reach-the-t14-while-it-runs-toyos.md`), so
+the boots are of an image the profile still runs.

issues/a-childs-end-is-an-event-and-a-parent-takes-its-children-down.md

@@ -44,8 +44,9 @@ directory is `issues/every-program-sees-only-the-files-it-was-given.md`'s.
    all it does kept: a `restart` row that ends is started again on the ports
    it kept; a row without one has its acceptors closed, so a client's next
    connect is `Gone`; a swap's expected end leaves them open for the binary
-   after it. `src/metalswap.rs`'s `judge` reads the third, on the T14 through
-   `toyos-metal --swap`; no test reads the first two.
+   after it. No test reads any of the three: `src/metalswap.rs`'s `judge`
+   read the third, on the T14 through `toyos-metal --swap`, and is deleted
+   (`issues/the-host-cannot-reach-the-t14-while-it-runs-toyos.md`).
 2. **An end says how**. An end reads as an exit, a kill or a fault kind
    alike on every architecture, and a bare code reads the last two as failures.
    No end reads as a quit's reason. *Exit*: exited 137, killed, and each fault

issues/a-connect-between-two-accepts-is-reset.md

@@ -28,6 +28,9 @@ the client hides this and does not fix it.
 QEMU and T14 rows both, with `lan_swap_hold`, the T14 row's judge and the
 metal harness's swapping boots, which that row was the one user of, and
 `29733dba3` then deleted the swap file and `--hand-back` only they used.
+`toyos-metal --swap`, the host's stream and its ssh client went after them;
+`issues/the-host-cannot-reach-the-t14-while-it-runs-toyos.md` records the commit
+that restores those.
 
 **Exit**: a listener that queues a connect arriving between two accepts, and
 `lan_swap` restored and green.

issues/a-renamed-services-state-stays-under-its-old-name-unread.md

@@ -18,7 +18,7 @@ five services, and a DATA volume that outlives that change:
   `/state/sshserver`, which a client that pinned the old key refuses;
 - no longer authorizes a key that lived only in `/state/sshd/authorized_keys`:
   `userland/sshserver/src/main.rs`'s `authorized_keys` reads
-  `/state/sshserver/authorized_keys` and `/system/etc/ssh_authorized_keys`, so
+  `/state/sshserver/authorized_keys`, so
   a machine updated over ssh whose owner's key was only there refuses its owner
   afterwards.
 

issues/a-test-asserts-a-daemons-line-off-a-boot-log-that-ends-before-it.md

@@ -27,8 +27,8 @@ test-runner, so a daemon's line can come after the marker. Two tests read one fr
   ```
 
 #639 has each `iommu_virtio_platform` arm wait on the guest for the daemon's lines it reads
-(`d773a4306`). `lan_dhcp_lease` has left the guest suite: its T14 row
-judges the whole readback, which ends at the boot's last word.
+(`d773a4306`). `lan_dhcp_lease` has left the guest suite, and its T14 row is
+deleted (`issues/the-host-cannot-reach-the-t14-while-it-runs-toyos.md`).
 
 Owner: the orchestrator.
 

issues/four-shares-take-a-file-server.md

@@ -47,7 +47,7 @@ detached from a desktop shell and runs in that shell's login session. Its
 one share with each other and with the terminal that started the server: one
 login at its parts has every other's next connection or stream on that server
 refused, and that terminal's. Only where a boot config starts sshserver as a
-service (`tests/lantalkcase`, `tests/metalcase`) does each launch it makes
+service (`tests/metalcase`) does each launch it makes
 open a session of its own.
 
 **Ruled** (owner, 2026-10-07):