nx_myotable.nx

nx_myotable.nx -- ★THE MUSCLE SET AS ONE TABLE, fail-closed, so the count can actually grow. ★THE DEFECT. nx_myoset describes each muscle across FOUR PARALLEL IF-CHAINS -- ms_origin, ms_insert, ms_peak, ms_name -- so adding one muscle means editing four functions and keeping them aligned by hand. nx_skelgen documented this exact shape for its joints: "the same 13 joints are described across sg_jparent, sg_jdx, sg_jdy, sg_jdz and the constraint pair, so adding a joint means editing six places." It is the third instance in this codebase and the cure has not changed: ONE TABLE. ★★AND A REAL FAIL-OPEN BUG, not just an ergonomic one: every chain ENDS IN AN UNGUARDED DEFAULT (`return 250`, `return "gastrocnemius"`). So ms_origin(999) answers 250 and ms_name(999) answers "gastrocnemius" -- ★A PHANTOM MUSCLE THAT LOOKS COMPLETELY REAL. Nothing anywhere says how many muscles exist, so no caller can even know it asked out of range. This table REFUSES instead. ⚠★★WHAT THIS DELIBERATELY DOES **NOT** DO: pad the count. The measured gap is ~18 modelled against ~700 named skeletal muscles, and it would be easy to type another twenty rows of plausible-looking attachment stations right here. This session convicted exactly that habit -- the shoulder width was half its true value because someone typed a number that looked reasonable -- so the mechanism ships with the EXISTING eight re-derived byte-exactly, and every future row must arrive SOURCED. ★The right source is already in hand: attachments should be DERIVED FROM BONE LANDMARKS that nx_skelgen emits, not typed -- the "attach relative to the parent" law this lane learned on the brow. nx_myotable selftest license_tier: ORIGINAL expect_exit: 0 No hw writes (Rule 26).