There is a point to be made about the size of your workbook, and how you'd be better off separating out: (1) the program your working on; and (2) the tools you're using, not least because with 149 modules, and who knows how many procedures, I'm surprised you're not bumping into conflict errors more often.
There is also a point to resolved about you not being able to find "Sub three" when you search for it, because that's not really 'a thing'. Do you have any of the find dialog settings left on maybe? One very quick and easy way of finding the procedure is to mimic what Application.Run does by literally doing that manually in the Immediate Window, and executing it. So:
And see what happens. Alternatively, you could execute Application.Goto "three", which will take you straight to the procedeure (assuming there is only one named that in your workbook, and you don't have any modules called 'three'... which, as I type this now, is starting to feel like its becoming the frontrunner of possible culprits. But the absolutely surefire way of finding the procedure is to preface it with the name of the module! So:
VBA Code:
Application.Run "Module148.three"
At this juncture, I would suggest giving your modules and subs more meaningful names. It makes sense to use simple words for the speech recognition commands, but the actual names of subroutines don't have to be same as the command.