nx_write.nx

nx_write.nx -- W-BB-1: THE WRITE LANE'S BACKBONE. The organ that actually WRITES. u2605u2605u2605u2605u2605u2605THE GAP THIS CLOSES, AND IT IS EMBARRASSING IN THE RIGHT WAY. The write lane had a ruler (nx_writebench, 625 permil), a panel-reliability bound, a real-person gate, a greeting-structure grader, a campaign continuity checker and a per-turn dialogue meter -- and NO GENERATOR. `nx_writer_run` is 9 functions that emit scaffolding and contain no inference call whatsoever: no engine, no model, no HTTP. Meanwhile the local engine answers /v1/chat/completions in ~1.4s and has all along; the gen lane has been using it for images and chat for weeks. u21d2 WE HAD BUILT GRADERS FOR A THING THAT COULD NOT PRODUCE. u2605u2605u2605u2605u2605u2605A LANE WITH RULERS AND NO PRODUCER MEASURES NOTHING -- COVERAGE ON AN EMPTY LANE IS A NUMBER ABOUT THE RULER, NOT ABOUT A CAPABILITY. WHAT THIS IS: prompt -> real prose, on the local engine, for every mode in the registry -- the writing equivalent of what nx_gen is for images. u2605THE SEAM IS ENFORCED BY CONSTRUCTION, NOT BY POLICY TEXT. write_modes.tsv declares per mode a REGISTER (sfw|mixed|explicit) and a LANE (tutor|local). An `explicit` mode may only run on the `local` lane -- it never leaves this machine. That is a routing fact checked here before a single byte is sent, so it cannot be forgotten by a caller or argued away by a prompt. u2605ENDPOINT FROM THE SWARM SSOT, never a literal: se_addr("gpu-image") -- the same single source the gen daemon resolves per request, so a DHCP move heals both lanes at once (the 6-hardcoded-sites outage is not repeated here). nx_write <mode> <prompt...> -- generate; prose to stdout nx_write modes -- list the registry license_tier: ORIGINAL expect_exit: 0 module: nishi-core.write.backbone