Sorry for the delay...
If you've installed mojito globally (probably via npm install --global mojito) the mojito commandline will be installed in your path. If you install mojito locally into your app, the commandline is available at ./node_modules/mojito/bin/mojito. You can see all mojito commands by typing mojito help and get help for each command with mojito help <command>, for example mojito help create. The commandline that takes the client-side part of your app and packages it up as an HTML5 app (for use in phonegap etc) is mojito build html5app.
Mojito itself doesn't know how to determine connectivity speed or device heat, but is structured in a way that there's a natural place to plug that information into your mojito app. Each request in a mojito app runs in a "context" which is an arbitrary key:value dictionary that encapsulates the runtime context for that request. Some example keys are "environment" (which could for example be "development", "production", "staging", etc) or "device" (for example "iphone", "ipad", "android"). Out of the box, mojito will set up a few of these for you, but you are definitely encouraged to define your own based on the different considerations you want your app to be sensitive to.
The Y.mojito.client.pause() is actually a mostly-internal method, and may in fact go away in the future. Just as you suspect, it has nothing to do with DOM but instead has to do with the pausing/resuming different tasks inside of the client-side part of mojito. (It's needed for a few situations, but I'm really hoping we can chop out pause()/resume() when we rewrite the client-side.)
Here are some basics of how Mojito work, which will hopefully make things clearer. A mojito app is organized into "mojits", each of which is responsible for creating a section of the page. As well, each mojit is a unit of MVC: each mojito has a controller, at least one view, and zero-or-more models as needed. When mojito runs a mojit, it really runs ("invokes") a method on the controller (which we call "action"). That method of the controller decides what needs to be done (perhaps calling a model), and then returns data to be rendered using a view. The view used is the same name as the method on the controller by default, but the method can decide to use a different view instead if desired. These mojits can run on the server or client, or in only certain locations if you decide that it's better only to run your mojit on the server for example. As well, each mojit can have a "binder" which is a piece of code associated with each view an only runs on the client. (It's pretty similar to Y.View from YUI.) The binder is what responds to user clicks and other interesting events, can can call back into the mojito if needed. One of the things it can do is invoke an action on the controller, and mojito will take care of running the controller, on the client-side if the controller is allowed to run there, or mojito will RPC back to the server to run the controller there if it's not allowed/available on the client. That's part of what we're trying to accomplish with Mojito: you can write your code to a single API and have it run in either client or server, but can still customize/optimize for each environment when you need to do that. One last point: a mojit can be implemented using the "composite" design pattern, where a mojit is actually implemented as a bunch of child mojits. (In fact, this is how a page is made: it's just a single top-level mojit that has a bunch of child mojits for each section of the page.)
Drew
