From the Inside Claude Code - The Claude Code Ecosystem architecture map
The Lowerer is one struct spread over 38 files and 29,700 lines with no unit tests
A single Lowerer type has impl blocks in 38 of the 43 files under src/ir/lowering, about 29,700 lines and roughly 680 functions, sharing 27 fields of mutable state (globals, function metadata, type caches, sema maps). The repo's own cleanup backlog lists it as item 7, and global_init.rs is flagged for 16 levels of nesting. None of these files contains a #[test].
Impact: Any change to lowering can touch shared state used by expression, statement, global-initializer and type code at once, and regressions surface only when a whole C program is compiled.
Recommendation (large effort): Carve the Lowerer into owned sub-components with narrow interfaces (type mapping, global initializers, expression lowering) that take explicit context instead of &mut self, and add focused unit tests for each, beginning with types.rs and global_init*.rs whose inputs are pure data.
The trail
Open on the mapMore from this board
- Optional SessionStore methods raise instead of being absent, so a change in Types reaches 13 modules
- Day 1: start with marketplace.json, the contract everything else serves
- Every SDK module imports its exceptions from one file, _errors.py
- Partner MCP plugins launch unpinned packages on every user's machine
- PR-controlled agent config is restored from the base branch before Claude starts
- Control-protocol failures escape the SDK exception hierarchy
- The triage and dedupe agents are boxed in identity, tools and network
- Label decisions by the triage agent leave no reason a maintainer can see
- Spend and run length are bounded at the transport
- The subprocess transport carries five responsibilities in one file
- Every agent-driven closure has a human override before it happens
- Skip for now: config-only integrations, CI plumbing and single-file plugins
- External-PR workflows never execute contributor code