docs(spec-networking-gaps): networking test plan: gaps G-N1–G-N7 and host→PTask forward defect - #638

_{Comment @coderabbitai help to get the list of available commands.}

sdd-validate — spec boundary findings

Boundary resolved: Spec (docs/specs/08-spec-networking-gaps/08-spec-networking-gaps.md)
Gate set applied: Spec gates (acceptance criteria testable · no implementation leakage · assumptions explicit · proof artifacts present and behavioral)

Gate 1 — Acceptance criteria testable ✅ PASS

All 16 functional requirements across the five units (R1.1–R1.4, R2.1–R2.4, R3.1–R3.3, R4.1–R4.3, R5.1–R5.4) are stated as observable, verifiable conditions: CLI flag acceptance confirmed by RPC output, TCP connection success/rejection, process lifecycle state, and policy round-trip query responses. No vague aspirational criteria found.

Gate 2 — No implementation leakage ⚠️ WARNING (4 findings)

Several functional requirements name specific Rust types, functions, or file paths where a behavioral statement would suffice. These are warnings — the spec can proceed, but the implementation author should read these as "the current baseline" context rather than as locked design decisions.

Finding 2a — R1.2 (docs/specs/08-spec-networking-gaps/08-spec-networking-gaps.md line ~121):

"The silent warn-only best-effort bind of proxy.rs:154–172 shall be replaced"

Prescribes a file name and line range inside a functional requirement. The behavioral statement ("a failed proxy bind is always observable") is present but the file:line citation belongs in a baseline note, not in the "shall" body.

Finding 2b — R3.2 (line ~208):

"The sessions::EgressPolicy struct shall be populated from the request and passed to the existing (or new) apply_egress call site in minimald"

Names a specific Rust struct and a call site where the behavioral statement ("a PTask launched with an egress spec has its egress rules applied") would suffice.

Finding 2c — R4.1 (line ~259):

"shall call wg::start with the loaded MeshConfig and keep the resulting MeshHandle alive"

Names three specific Rust identifiers in a functional requirement. The behavioral intent ("when a mesh config file exists, the daemon enters mesh mode at startup and stays there") is inferable but not the primary framing.

Finding 2d — R5.1 (line ~300):

"shall be refactored from a single vmm_pid: Option<u32> to a map <vm-name> → VmState { lifecycle, vmm_pid, started_at }"

Prescribes a specific Rust data structure shape (field names and types) in a functional requirement. The behavioral statement ("minvmd tracks a named fleet of VMs concurrently") is the operative requirement; the struct layout is implementation.

Note: The "Affected areas" and "Baseline:" sub-notes throughout the spec also reference specific crate paths and type names. These are contextual annotations, not criteria, so they are not findings. Only the cases above appear in "shall" requirement text.

Gate 3 — Assumptions explicit ✅ PASS

All material assumptions are stated:

• Open Questions 1–3 explicitly flag the three unresolved design choices (RST defect root cause, gvproxy injection framing, vsock CID stability) and identify which requirements depend on them.
• The relay-layer egress enforcement boundary (Unit 2 follow-up: R2.2 egress enforcement (relay-layer frame inspection) + R2.4 dynamic port-mapping #553) is declared a Non-Goal and reinforced in R3.1 and R3.2 notes.
• The /dev/kvm hardware gate and MINIMALD_INTEGRATION_MESH env-var gate are explicit in proof artifacts that require them.
• DM5 production certificate management is deferred and documented.

Gate 4 — Proof artifacts present and behavioral ✅ PASS

All five demoable units carry behavioral proof artifacts (1–2 per unit; all within the 1–3 bound). Each would fail against an empty PR, confirming they verify the feature rather than trivially passing.

Observation (not a finding): R4.3 (minimal mesh join sends JoinMeshPeer RPC and persists config) does not have a dedicated proof artifact — the Unit 4 test uses wg::start_with_socket (the existing unit-test socket path) and the CLI proof covers startup enrolment, not the join-then-persist round-trip. Unit 4 has two behavioral proofs so Gate 4 is satisfied, but the implementation author should consider a CLI proof of the form minimal mesh join <addr> && minimal mesh status showing the new peer if the join RPC is non-trivial.

Summary

No Blockers. The spec may proceed to merge and advance to triage. The four Gate 2 warnings are advisory: the implementation leakage does not invalidate the requirements, and a knowledgeable implementer will read the named types as baseline context rather than locked design. The behavioral intent is recoverable in each case.

Generated by sdd-validate · spec boundary · PR #638

Generated by sdd-validate for issue #638 · ◷

Closing for now. We can attempt to run spectacles again once improvements have been made in that framework.