I feel my reply has become partially obsolete while writing it, but whatever, here it is.
However working on requires an understanding of how to convert ideas/"dreams" from the mind into something the computer can understand.
I partially disagree. You don't actually need to code or know how to code to start writing a design document. Initially you just need to know what the game is about. If you can describe the game from the viewpoint of a player then you should be able to write a decent start to your design. Keep in mind that design documents are not really standardized, their scope varies a fair bit, as does the scope of the projects they describe. Sometimes a design document doesn't contain code, prototypes, or diagrams. Ideally though, it should be complete enough that there is no ambiguity about what features go into the game, and should eventually provide enough detail on how the features work to implement them. Saying there are multiple weapon types and amour systems is a start, but too vague for a final version. Saying what the weapon types are, and the equations for calcuating damage based on weapon and armour is better. It doesn't need to be actual code, but at least a mathematical equation would be a good idea. Describing the high level idea, feel, and flow of a game should come before implementation details. The initial part of writing a design document is then more of a technical writing skill than a coding skill. It's only when you start drilling down to the details of how something is implemented that coding skill becomes important.
Not all dreams are feasible and thus practical prototyping is required to determine what works and what doesn't.
If you keep the design open, it's possible for more experienced programmers to catch ideas that aren't likely to work. Fortunately though, having to solve NP-complete problems and the like in a real-time game isn't an issue that typically comes up. If you can dream up an idea for gameplay, there's a pretty good chance it can be implemented. If it really is a bad idea, that often comes out pretty quick, even before code is written.
Not everything needs to be prototyped first, and certainly not at such an early stage. Prototyping is probably more useful to test a possible implementation of a program feature, rather than as part of a design step that determines what features are present. It would seem very strange if a prototype was driving the design, rather than a design determining which parts to start prototyping. Why build something if it wasn't a needed feature? Why have features that might not be possible to build? That would be more of a research project than game design.
The other half are scattered throughout my iPad and this computer I do word processing on.
All the more reason to start collecting things into one place which can become your authoritative source of information on what the game is and how it will work. You do need to nail things down at some point.
I can certainly put together what I have right now but its nowhere going to be near being complete or fully fleshed out.
It will never be complete if you don't start.
I don't know if you've noticed this, but if you re-read your post, a few parts sound like excuses. I'm not going to debate the validity of them, I'd just like to bring up the mindset of this. It's sometimes a little too easy or convenient (lazy) to find a reason why something can't be done (now), rather than make a decision on the next actionable step. Certainly things won't always go according to plan, but that's not really the point. If you need to wait on something, then make a note to revisit when the time is right, and move on to something else where a decision can be made. Putting things off is easy, making decisions is hard. Decisions are needed for progress.
I am very guilty of putting things off and making excuses myself. I've come to realize that making excuses doesn't help get things done. Coming up with small actionable next steps does help. The most productive people I know always have a small next step to work on. The least productive people I know always have an excuse.
Lately I've often found myself grudgingly try to turn excuses into small actionable next steps. It's hard, I know. I am painfully aware of this.
With that said, I'm glad to see you've made a decision on the format for your design document and actually got started on it. I'm actually impressed. I wasn't expecting 4 pages already. Wait no, 8 pages now? Wow, you're really moving. Good job. I have some reading to catch up on now.
That SMART stuff is exactly what I was trying to get at.
Also, I had similar thoughts about the wormhole idea. I was thinking maybe just leave an air of mystery about it. The crew is woken, the ship has arrived at an unexpected destination. Perhaps they don't know where they are, perhaps they don't even know how long they've been travelling. Maybe there was a computer glitch, maybe there was a wormhole, maybe they've just been travelling for a very very long time, much longer than expected. Give the reader/player something to wonder about. Give them something to discuss. Probably better than giving them something to refute.