DEVELOPER.md

@@ -376,8 +376,8 @@ survive stop/start; guest RAM does not.
 Start on a healthy running VM validates its retained network, synchronizes
 policy, then restores shared bridge/NAT/forwarding rules without spawning another
 VMM. A shared-network setup failure retains the running VM for retry. An ambiguous
-process or interrupted live boot/stop is not adopted as a
-successful start. Failed resume retains the private disk for retry. Restart
+process or interrupted live boot/stop is not adopted as a successful start.
+Failed resume retains the private disk for retry. Restart
 performs stop and start under one operation lock, not two independent public
 calls with a race between them.
 
@@ -705,16 +705,18 @@ including on conntrack-tools 1.4.8, where `--list` is not a supported option.
 ### Coexistence and Recovery
 
 Shared `iptables` egress MASQUERADE/forwarding is separate from private bridge
-policy. The policy adds no DNAT, public listener, or host-port mapping and does not replace
-the host firewall manager. Public inbound connectivity, DNS publication, guest reverse proxies/TLS,
-and integration with UFW/firewalld/Docker/libvirt remain out of scope. An
+policy. The policy adds no DNAT, public listener, or host-port mapping and does
+not replace the host firewall manager. Public inbound connectivity, DNS
+publication, guest reverse proxies/TLS, and integration with
+UFW/firewalld/Docker/libvirt remain out of scope. An
 administrator's external routing/NAT can still affect reachability; do not
 infer source-CIDR restrictions or complete public-exposure protection from the
 use of private addresses. Operators must choose a non-conflicting topology.
 
 If an external actor loses or changes private policy, recovery is explicit
-`ports sync`; `start` also restores shared networking for a running VM. An `enforced` snapshot cannot
-prevent later root-level changes or prove that other rules allow traffic.
+`ports sync`; `start` also restores shared networking for a running VM. An
+`enforced` snapshot cannot prevent later root-level changes or prove that other
+rules allow traffic.
 [FIREWALL.md](FIREWALL.md) retains the original proposal/backend evaluation;
 do not import its unimplemented topology checks into current documentation.
 
@@ -1055,8 +1057,9 @@ The code is intentionally honest about current limits:
 - Guest health is inferred from VMM process state, not application readiness.
 - No quotas, DHCP, host-port mapping, UDP/IPv6 services, or network tenancy.
 - No guest snapshots, extra disks, production image builder, or SSH-key injection.
-- Per-VM private TCP ingress policy exists, but public inbound connectivity, DNS publication,
-  guest reverse proxy/TLS, and external firewall integration remain out of scope.
+- Per-VM private TCP ingress policy exists, but public inbound connectivity,
+  DNS publication, guest reverse proxy/TLS, and external firewall integration
+  remain out of scope.
 - Shared egress `iptables` rules are incremental and idempotent; only the
   private bridge policy is atomically rendered per VM.
 - No autostart, background reconciliation, or guest-coordinated shutdown.

README.md

@@ -255,8 +255,8 @@ well as new connections. This is packet dropping, not a guaranteed TCP RST or
 immediate application disconnect.
 
 These rules govern access to the **guest private IP**. They do not start a
-guest service or provide public inbound connectivity, host-port mappings, DNS publication,
-reverse proxies, or guest-service TLS. UDP and IPv6 service policies are not
+guest service or provide public inbound connectivity, host-port mappings,
+DNS publication, reverse proxies, or guest-service TLS. UDP and IPv6 service policies are not
 yet supported. Guest-initiated IPv4 TCP/UDP egress, its replies, and required
 ARP/ICMP traffic remain allowed; managed TAPs block IPv6.
 

USAGE.md

@@ -1259,8 +1259,7 @@ so the packet test skipped. That is a permission limitation, not real-packet
 or real-host validation. The harness uses veths as TAP stand-ins and simulated
 upstreams to check NAT, offline startup, reconnects and uplink changes. It does
 not boot Firecracker or validate the host's real TAP setup. Run actual
-VM/SSH/egress checks on an isolated Linux host before
-relying on the deployment.
+VM/SSH/egress checks on an isolated Linux host before relying on the deployment.
 
 ## 19. Get Help
 

tests/integration/test_private_ports.py

@@ -2,8 +2,8 @@
 
 Run: UVM_FIREWALL_INTEGRATION=1 python3 -B -m unittest discover -s tests/integration -v
 
-Needs Linux, nft, iptables, ip, bridge, conntrack, sysctl and permission to create network
-namespaces (root, or unprivileged user namespaces). No sudo, installation,
+Needs Linux, nft, iptables, ip, bridge, conntrack, sysctl and permission to create
+network namespaces (root, or unprivileged user namespaces). No sudo, installation,
 /run/netns mounts, host firewall changes or br_netfilter sysctls are used.
 Bridge-connected veths stand in for guest TAPs. A third namespace with two
 uplinks tests NAT, offline startup, reconnects and host route changes without
@@ -380,7 +380,7 @@ def _sandbox(parent_fd):
             guest.request("udp_bind", name=label, ip=vm.guest_ip, port=0)
             guest.request("udp_send", name=label, ip=internet_ip, port=53, data=label)
             query = outside.request("udp_recv", name="internet-dns")
-            assert query == [label, [source, query[1][1]]], query
+            assert query[0] == label and query[1][0] == source, query
             outside.request("udp_send", name="internet-dns", ip=source, port=query[1][1], data="dns-reply")
             assert guest.request("udp_recv", name=label)[0] == "dns-reply"