exec straight into help docs server to show output

.milpa/docs/milpa/use-case.md

@@ -80,3 +80,4 @@ Building your own CLI is usually what ends up happening given a team with enough
 
 In my limited experience with engineering teams of less than 300 folks, many of the bootstrapping tasks will involve operations that can easily (and more succintly) be expressed with a shell scripting language. `milpa` could also be a useful intermediate step, that could help teams avoid the dread of jira runbooks until it's a good time to build your own CLI.
 
+Building a CLI is something that happens to me somewhat often, and when golang is a good choice, I get most of `milpa`'s niceties by building my CLI on [chinampa](https://git.rob.mx/nidito/chinampa). `joao`, a configuration manager, is an exmaple of something that started as a [milpa repo](https://github.com/unRob/nidito/tree/0812e0caf6d81dd06b740701c3e95a2aeabd86de/.milpa/commands/nidito/config) that later became [it's own CLI](https://git.rob.mx/nidito/joao); getting it to work with `milpa` first was fundamental in figuring out _what_ it needed to do, and it only took a few hours.

milpa

@@ -18,7 +18,13 @@ fi
 # bash is fine and all, but we need a little helper to run parsing for us
 export MILPA_COMPA="${MILPA_COMPA:-$MILPA_ROOT/compa}"
 # bail early if we're doing magic commands
-if [[ $1 == "__complete"* ]] || [[ "$*" == "itself doctor"* ]] || [[ $1 == "--version" ]] || [[ $1 == "version" ]]; then exec "$MILPA_COMPA" "$@"; fi
+if [[ $1 == "__complete"* ]] ||
+  [[ "$*" == "itself doctor"* ]] ||
+  [[ $1 == "--version" ]] ||
+  [[ $1 == "version" ]] ||
+  [[ "$1 $2 $3" == "help docs --server" ]]; then
+  exec "$MILPA_COMPA" "$@";
+fi
 
 function @milpa.load_util () {
   # shell scripts can call @milpa.load_util to load utils from MILPA_ROOT