In June 2026 the CPython Steering Council paused new work on the experimental copy-and-patch JIT and requested a Standards-Track PEP, explicitly inviting alternative proposalsand suggesting the design describe “a JIT infrastructure that can support multiple implemen-tation strategies” rather than a single one. We accept that invitation. Our position is that thedecisive lever for high-performance dynamic-language execution is not any single tier or trickbut co-design across every layer of the stack at once—from the source dialect, through a whole-program-optimizing source-to-C transpiler, down to bare-metal thread context switching and aC language extended with call-graph contracts. Building on the minipy/ShivyCX pipeline, inwhich the entire runtime is written in one restricted-Python dialect and compiled as a singlewhole program, we report three results that together move the system decisively toward full self-containment. First, the runtime’s front end —a fully dynamic PEG parser—compiles straight tonative code through the same pipeline that compiles the interpreter, verified byte-identical toCPython across a four-way differential test. Second, the transpiler itself (py2c, ∼14,000 lines)now compiles and runs on the interpreter it produces: minipy compiles all 648 of its functions,the module fully initializes, and it begins transpiling small programs—closing a meta-circularloop between the compiler and its runtime. Third, we replace the external assembler: rasm,an x86-64 assembler written in the same dialect, encodes ShivyCX’s output byte-identicallyto GNU as (100/100 instruction forms) and emits ELF objects that link and run correctlyend-to-end across a program battery (9/9). With a native front end, a self-hosting transpiler,and an in-dialect assembler, the only external tool left in the self-hosted path is the systemlinker—narrowing the distance to a fully self-hosted, dependency-free JIT to a single, namedcomponent, and directly answering the two concerns raised against the current CPython JIT:its build-time LLVM dependency and its uncertain long-term maintainability.