The "magic" is that the Runner.CallMethod doesn't actually call the specific code methods for executing tests but simply calls an "Execute" method that is named as <AUTName>TestStep.Execute. That method contains a case statement that parses keywords for the execution. There is no "code" referenced in the CSV files, simply a set of keywords that feed into the loop for creating the array. Code routine calls are constructed on the fly.
If, in the CSV file for the list of tests the first character is a "semi colon", it skips that entire test.
So, where in your framework you have (at least as I under stand it) your CSV file containing specific code routines, I have two CSV files. The first is a list of test cases with simply the test case ID and a descriptor. The second is a list of steps organized by test case ID containing a step counter, the AUT name against which the step will be executed, a keyword designator for the step, and a delimited string for any specific detail data needed during executing that step.
As for large logs, the framework is designed that you can drop in different pairings of the two CSV files for different sets of tests. Rather than having to execute ALL your tests in one project run, you simply designate the project to run with one set of CSV's, copy in another set, run that, and repeat. You'll get a lot of smaller, more easily handled logs that are specific for certain desired testing outcomes.
(shrug) YMMV but I find this an efficient way of constructing tests where, if I need to add a new test case, at minimum I simply need to add more records to the CSV. If the new test case involves new features of the AUT, then I need to add a bit more code but, again, modularized based upon AUT and controlled by the case statements.