t27-first migration feasibility map: what src/ can (and cannot) become .t27 specs

[gHashTag]

With the codegen now correct (t27 #1456 optimizer removal + #1457 array/index), I probed what the golden pipeline can actually express, to scope issue #16 (rewrite mesh in .t27) realistically.

t27c codegen CAN express (verified against the fixed t27c)

• Pure free functions on u8..u128, i8..i128.
• Floating point: f32/f64 arithmetic (fn scale(x: f32, k: f32) -> f32 { return (x*k); } -> valid Rust).
• Structs + field access (struct P { x: u32 }, p.x) with auto-derives. Already used (e.g. specs/m3_multihop.t27 PerfCounters).
• Fixed-size arrays [T; N] + usize indexing (post-#1457), control flow (if/while/for), consts, enums.

t27c CANNOT express (hard limits for the datapath)

• impl methods with a self receiver. t27 models behaviour as FREE functions, so a method API like Gf16::add(self, rhs) must become gf16_add(a, b) — an API change that touches callers.
• External crates / FFI. Anything using x25519-dalek, chacha20poly1305, sha2, sockets, TUN, std::net cannot be a spec. This rules out crypto.rs and the transport/IO layers wholesale.
• Network I/O and OS calls (daemon.rs, the Transport impls).

Migration map for src/*.rs

Module	Spec-backable?	Note
wire.rs	YES (done)	already specs/wire.t27
gf16.rs	PARTIAL	float+struct OK, but method API (self.add) -> free fns; refactors callers
routing.rs (ETX)	LIKELY	int/float metric math; check for method/IO use
discovery.rs (Hello framing)	LIKELY	byte framing is pure; MAC/crypto parts are not
crypto.rs	NO	X25519/ChaCha20/SHA via crates
router.rs / daemon.rs / modem.rs	NO wholesale	network I/O + DSP; pure sub-parts (e.g. header encode, ETX update) could be extracted into specs and called from the hand-written shell

Recommendation

The t27-first goal is realistic for the ALGORITHMIC layer (metrics, numeric formats, framing, state machines, the 9 already-wired logic modules) but NOT for the crypto/IO/DSP layer, which stays hand-written Rust and calls into generated logic. Issue #16 should be scoped as SELECTIVE extraction of pure logic into specs, not a wholesale rewrite. Each extraction must keep the 103 tests green.

phi^2 + phi^-2 = 3

[gHashTag]

Empirical probe: extracting the ETX subsystem — DEFINITIVE result

Tried to extract routing.rs's ETX math into a spec end-to-end. Result closes the migration-scope question for the datapath:

Migrates cleanly: pure f32<->f32 arithmetic.
fn etx_formula(df: f32, dr: f32) -> f32 { return 1.0 / (df * dr); } -> valid Rust.

Does NOT migrate (each drops the body or is unexpressible in t27):

• int -> float cast: (got as f32) / (window as f32) emits unimplemented!() — t27c does not lower a u32->f32 cast (the whole function body is dropped). Codegen gap (int->int casts were fixed in #1320; float casts weren't).
• f32::INFINITY — the ETX dead-link sentinel; no t27 representation.
• Method receivers (self.forward.ratio(), Self::DEAD_EPS) — t27 has free functions only.
• Stdlib methods .clamp(0.3, 0.6), .max(1) used by the EWMA new().

The actual ETX subsystem (DeliveryRatio EWMA + LinkStats::etx) is ~90% these Rust-isms; only the bare 1.0/(df*dr) line is a pure free function. Extracting just that one line into a spec+module adds indirection for no real benefit (and doesn't remove the method/INFINITY/cast code around it).

Conclusion (answers issue #16)

Wholesale datapath migration to .t27 is INFEASIBLE with current t27. The pure algorithmic logic that CAN be a spec is already spec-backed (wire.t27 + the 9 wired logic modules). The used datapath (crypto crates, network I/O, EWMA/ETX with casts+INFINITY+methods) stays hand-written Rust and calls into generated logic. Issue #16 should be CLOSED or rescoped to "keep new pure-logic modules spec-first" rather than "rewrite the mesh." The t27-first line of work is complete for what is realistically expressible.

phi^2 + phi^-2 = 3