mastermind-runtime-research

Mastermind runtime research

[[mastermind-architecture-review]] reconstructs the runtime path and judges the design. This runs first and does something narrower: find who already depends on what you are about to change, and state where the graph stops being able to tell you. Feed both into the review.

Zero callers is not zero callers

Start here, because every other answer inherits it. The graph is syntactic, so whole classes of real invocation produce no edge at all:

• A queue, topic, or bus. A producer and its consumer are two separate static islands. There is no edge between them and there never will be.
• Framework registration. A route table, a DI container, a decorator-based dispatcher, or a config-declared handler calls code the graph never links.
• Reflection, dynamic dispatch, and interface indirection. The call lands on a name the source never spells.
• Cross-process and cross-language. A worker invoked by a scheduler, or a service reached over HTTP, is outside the index entirely.

So mmcg_callers returning nothing on a handler means no static caller was found, not nothing calls this. Report it that way, and go find the registration, the topic name, or the schedule by reading. A change that looks unreferenced is the single most expensive thing to get wrong here.

Who depends on this today

mmcg_api_surface src/orders/      # symbols under a prefix used from OUTSIDE it
mmcg_callers <symbol>             # static callers, with the caveat above
mmcg_impact <symbol> --depth 3    # transitive blast radius
mmcg_imported_by <symbol>         # importing files, including barrels

mmcg_api_surface is the one most often skipped and the one that matters most: it reports what the rest of the codebase actually reaches into, independent of what is declared public. A module can export twenty symbols and have three real consumers, or export none and still be reached through a re-export. Change the three, not the twenty.