Internals

Stage: List

The imeight program list in its text format is entered to the Program Listing tab.

Step: Parsing

Programmer presses the > RUNNER button, or hits F9, on the Program Listing tab. The list will be parsed.
This is the analogy of tokenization and relink in the C64. You can think of it as a partial compilation if you like.
Parse errors may happen in this step. Otherwise the Runner Screen registers, PROGRAM UPDATED.

Stage: Runner

When parse is successful then the tokenized and relinked (partly compiled) code is stored in the program array in the JavaScript emulator. The program array, together with labels, dataLookup, elseBranches structures for efficient running and memory for the emulated memory's content are the representation of the runnable program "in the runner."
In the program array, contrary to C64, not only the keywords are replaced by byte tokens but it also is transformed into a postfix Polish notation.
The labels structure is an optimized analogy of the linked list of lines in C64. GOTO (GOSUB, etc.) will not have to do a linear search for the line number like C64 used to implement it. Instead, the label is looked up in labels, which is a map (dictionary.) This structure is also created in the parse step, together with program array.
More structures prepared by the parser help the runner similarly: dataLookup - program array index of each DATA instruction's parameter list start, elseBranches - THEN clause pointers mapped to their line end pointers to tell where to jump in case a condition is not met.

Directly add instructions to the runner?

The Runner Screen accepts instructions, too. They will get parsed line by line, and added to the end of the program in the runner.
The Program Listing tab tries its best to keep track of such changes, normally the line gets added to the end of the list. But only normally!

Meantime between List stage and Parsing step

Programmer may anytime modify the list in Program Listing tab. The program in the runner does not follow such changes live, only gets updated when > RUNNER button (or F9) is next pushed.
If a direct instruction addition happens on Runners Screen in the meantime, then the instruction is added to the in-runner version, while Program Listing tab has a newer version, not necessarily resembling the source code of the program in the runner. It would be incorrect to simply add the line to the list. Instead, a message PROGRAM FORKED appears on the Program Listing tab, which means, lines entered in the runner may get lost by pushing the > RUNNER (F9) in this status.

Running

The RUN command is nothing but resetting instruction pointer to the START, then a CLR instruction, followed by CONT command.
START is the label pointing to index 0 in the program array, that is where your program starts.
CLR erases all variable values, user functions and arrays, restores initial values of built-in variables.
CONT iterates over the program array. It may find:

• instruction (byte token or string representation of it): pulls arguments from argument stack, runs instruction;
• function call (by name): pulls argument list from argument stack, applies function, pushes result to argument stack;
• operator (string representation): pulls operands from argument stack, applies operation, pushes result to argument stack;
• literal or name (string representation): pushes it on the argument stack.

When one element of the program array could formally be two or more on this list, the topmost one is considered.

And that's it?

Yes, runner is simple because parser does a big part of the job. Thanks to the postfix Polish order, the arguments are ready and evaluated on the argument stack when the instruction is reached, or the operation/function on them is.
Another consequence though of the postfix Polish notation is that the logical AND/OR operators can't be short-circuited.