Streamlined tutorial and fixed broken links

www/source/docs/create-plans.html.md.erb

@@ -122,19 +122,19 @@ do_download() {
 
 After you have either specified your source in `pkg_source`, or overridden the **do_download()** callback, create a sha256 checksum for your source archive and enter it as the `pkg_shasum` value. The build script will verify this after it has downloaded the archive.
 
-If your package does not download any application or service source files, then you will need to override the **do_download()**, **do_verify()**, and **do_unpack()** callbacks. See [Callbacks](/docs/plan-syntax#callbacks) for more details.
+If your package does not download any application or service source files, then you will need to override the **do_download()**, **do_verify()**, and **do_unpack()** callbacks. See [Callbacks](/docs/reference/plan-syntax#callbacks) for more details.
 
 #### Define your dependencies
 Dependencies are broken up into two main types: build dependencies and run dependencies. Build dependencies are needed while your package builds and run dependencies are those packages needed when your Habitat service is running.
 
 Declare any build dependencies in `pkg_build_deps` and any run dependencies in `pkg_deps`. You can include version and release information when declaring dependencies if your application is bound to that version.
 
-The package `core/glibc` is typically listed as a run dependency and `core/coreutils` as a build dependency; however, you should not take any inference from this. There are no standard dependencies that every package must have. For example, the nodejs-tutorial-app package only includes the `core/node` as a run dependency. You should include dependencies that would natively be part of the build or runtime dependencies your application or service would normally depend on.
+The package `core/glibc` is typically listed as a run dependency and `core/coreutils` as a build dependency; however, you should not take any inference from this. There are no standard dependencies that every package must have. For example, the mytutorialapp package only includes the `core/node` as a run dependency. You should include dependencies that would natively be part of the build or runtime dependencies your application or service would normally depend on.
 
-There is a third type of dependencies, transitive dependencies, that are the run dependencies of either the build or run dependencies listed in your plan. You do not need to explicitly declare transitive dependencies, but they are included in the list of files when your package is built. See [Package contents](/docs/package-contents) for more information.
+There is a third type of dependencies, transitive dependencies, that are the run dependencies of either the build or run dependencies listed in your plan. You do not need to explicitly declare transitive dependencies, but they are included in the list of files when your package is built. See [Package contents](/docs/reference/package-contents) for more information.
 
 #### Override any callbacks
-As shown in an example above, there are occasions when you want to override the default behavior of the hab-plan-build script. The Plan syntax guide lists the default implementations for [callbacks](/docs/plan-syntax#callbacks), but if you need to reference specific packages in the process of building your applications or services, then you need to override the default implementations as in the example below.
+As shown in an example above, there are occasions when you want to override the default behavior of the hab-plan-build script. The Plan syntax guide lists the default implementations for [callbacks](/docs/reference/plan-syntax#callbacks), but if you need to reference specific packages in the process of building your applications or services, then you need to override the default implementations as in the example below.
 
 ~~~ bash
 pkg_name=httpd
@@ -168,14 +168,14 @@ do_build() {
 
 In this example, the `core/httpd` plan references several other core packages through the use of the `pkg_path_for` function before `make` is called. You can use a similar pattern if you need reference a binary or library when building your source files.
 
-When overriding any callbacks, you may use any of the variables, settings, or functions in the [Plan syntax guide](/docs/plan-syntax), except for the runtime configuration settings. Those can only be used in runtime hooks once a Habitat service is running.
+When overriding any callbacks, you may use any of the variables, settings, or functions in the [Plan syntax guide](/docs/reference/plan-syntax), except for the runtime configuration settings. Those can only be used in runtime hooks once a Habitat service is running.
 
 ### Runtime workflow
-Similar to defining the setup and installation experience at buildtime, behavior for your application or service needs to be defined when the supervisor starts it. This is done at runtime through event hooks. Hooks are script files with [shebangs](https://en.wikipedia.org/wiki/Shebang_(Unix)) that you can use to customize this behavior. The following hooks are available: init, run, file-updated, health-check, and reconfigure. See [Hooks](/docs/plan-syntax#hooks) for more information and examples.
+Similar to defining the setup and installation experience at buildtime, behavior for your application or service needs to be defined when the supervisor starts it. This is done at runtime through event hooks. Hooks are script files with [shebangs](https://en.wikipedia.org/wiki/Shebang_(Unix)) that you can use to customize this behavior. The following hooks are available: init, run, file-updated, health-check, and reconfigure. See [Hooks](/docs/reference/plan-syntax#hooks) for more information and examples.
 
 If your service does not require custom behavior during the lifecycle of the running service, then you do not need to create hooks. Also, if you only need to start the application or service when the Habitat service starts, you can instead use the `pkg_svc_run` setting and specify the command as a string. When your package is created, a basic run hook will be created by Habitat.
 
-And, as mentioned above, you can use any of the [runtime configuration settings](/docs/plan-syntax#runtime-configuration-settings), either defined by you in your config file, or defined by Habitat.
+And, as mentioned above, you can use any of the [runtime configuration settings](/docs/reference/plan-syntax#runtime-configuration-settings), either defined by you in your config file, or defined by Habitat.
 
 Once you are done writing your plan, use the studio to [build your package](/docs/create-packages-build).
 

www/source/docs/reference/package-contents.html.md

@@ -39,7 +39,7 @@ Additional switches to be passed to the compiler when this package is used as a
 The fully-qualified identifier for the package. The format is `origin/name/version/release`.
 
 ## INTERPRETERS
-If `pkg_interpreters` is specified in your plan.sh, then this file will be generated and contain a list of absolute paths to any interpreters that a package can provide. Code in a `plan.sh` may use the `fix_interpreter` function to replace hardcoded instances of interpreters, such as `/bin/env`. The location of interpreters in Habitat will be nested under `/hab/pkgs/`. For more information on interpreters, see the fix_interpreter description in [Utility functions](/docs/plan-syntax#utility-functions).
+If `pkg_interpreters` is specified in your plan.sh, then this file will be generated and contain a list of absolute paths to any interpreters that a package can provide. Code in a `plan.sh` may use the `fix_interpreter` function to replace hardcoded instances of interpreters, such as `/bin/env`. The location of interpreters in Habitat will be nested under `/hab/pkgs/`. For more information on interpreters, see the fix_interpreter description in [Utility functions](/docs/reference/plan-syntax#utility-functions).
 
 ## TARGET
 The CPU architecture and platform for the package. The format is `architecture-platform`. For example, x86_64-linux.

www/source/tutorials/getting-started-configure-plan.html.md

@@ -32,7 +32,7 @@ In this tutorial, the archive for our Node.js app already has a configuration fi
 
 5. Save the file.
 
-All user-defined expressions must have the **cfg** prefix. For general service settings, Habitat also defines several system expressions that you may use to configure your service at runtime. See the [Runtime configuration settings](/docs/plan-syntax#runtime-configuration-settings) section of the plan syntax guide for more information.
+All user-defined expressions must have the **cfg** prefix. For general service settings, Habitat also defines several system expressions that you may use to configure your service at runtime. See the [Runtime configuration settings](/docs/reference/plan-syntax#runtime-configuration-settings) section of the plan syntax guide for more information.
 
 As we said, a TOML file is associated with your configuration file and specifies the default values for your service at start up. If you have a templatized configuration file, then you must include a `default.toml` file in your plan folder.
 

www/source/tutorials/getting-started-create-plan.html.md.erb

@@ -51,11 +51,11 @@ We now have a skeleton plan, but we need to modify some of its settings before w
 4. Because this is a tutorial, you don't have to change the `pkg_maintainer` value to your email address; however, when you upload packages for others to consume, you should include your contact information.
 5. Change the `pkg_source` value to point to the archive file that contains the source files described in the previous step. {::comment} Move this into a S3 bucket under the Habitat account before launch {:/comment}
 
-        pkg_source=https://s3-us-west-2.amazonaws.com/nodejs-tutorial-app/nodejs-tutorial-app-0.1.0.tar.gz
+        pkg_source=https://s3-us-west-2.amazonaws.com/${pkg_name}/${pkg_name}-${pkg_version}.tar.gz
 
 6. Change the `pkg_shasum` value to the correct checksum for the tarball.
 
-        pkg_shasum=2ad73b78ef5e88e9e916873c0f762bbdf286e4de93e67cf211f9761a2876c7ef
+        pkg_shasum=b54f8ada292b0249245385996221751f571e170162e0d464a26b958478cc9bfa
 
     > Note: If you modified the source files from the previous step and created your own archive, you will have to compute the sha256 value yourself. If your computed value does not match the value calculated by the `hab-plan-build` script, an error with the expected value will be returned when you execute your plan.
 
@@ -85,13 +85,10 @@ To do both of those actions, we will implement our own **do_build()** and **do_i
 
 ~~~ bash
 do_build() {
-  # The nodejs-tutorial-app source code is unpacked into a directory,
-  # nodejs-tutorial-app-0.1.0, at the root of $HAB_CACHE_SRC_PATH.
-
-  # All of the source files need to be copied over into the $pkg_dirname
-  # directory (mytutorialapp-0.1.0). If you were downloading an archive that
-  # matched your package name and version, you would be able to omit this step.
-  cp -vr ${HAB_CACHE_SRC_PATH}/nodejs-tutorial-app-0.1.0/* .
+  # The mytutorialapp source code is unpacked into a directory,
+  # mytutorialapp-0.1.0, at the root of $HAB_CACHE_SRC_PATH. If you were downloading
+  # an archive that didn't match your package name and version, you would have to
+  # copy the files into $HAB_CACHE_SRC_PATH.
 
   # This installs both npm as well as the nconf module we listed as a
   # dependency in package.json.
@@ -122,20 +119,18 @@ pkg_name=mytutorialapp
 pkg_version=0.1.0
 pkg_maintainer="Your Name <your email address>"
 pkg_license=()
-pkg_source=https://s3-us-west-2.amazonaws.com/nodejs-tutorial-app/nodejs-tutorial-app-0.1.0.tar.gz
-pkg_shasum=2ad73b78ef5e88e9e916873c0f762bbdf286e4de93e67cf211f9761a2876c7ef
-pkg_filename=nodejs-tutorial-app-0.1.0.tar.gz
+pkg_source=https://s3-us-west-2.amazonaws.com/${pkg_name}/${pkg_name}-${pkg_version}.tar.gz
+pkg_shasum=b54f8ada292b0249245385996221751f571e170162e0d464a26b958478cc9bfa
+pkg_filename=${pkg_name}-${pkg_version}.tar.gz
 pkg_deps=(core/node)
 pkg_expose=(8080)
 
 
 do_build() {
-  # The nodejs-tutorial-app source code is unpacked into a folder,
-  # nodejs-tutorial-app-0.1.0, at the root of $HAB_CACHE_SRC_PATH.
-
-  # All of the source files need to be copied over into the $pkg_dirname
-  # directory (mytutorialapp-0.1.0).
-  cp -vr ${HAB_CACHE_SRC_PATH}/nodejs-tutorial-app-0.1.0/* .
+  # The mytutorialapp source code is unpacked into a directory,
+  # mytutorialapp-0.1.0, at the root of $HAB_CACHE_SRC_PATH. If you were downloading
+  # an archive that didn't match your package name and version, you would have to
+  # copy the files into $HAB_CACHE_SRC_PATH.
 
   # This installs both npm as well as the nconf module we listed as a
   # dependency in package.json.
@@ -156,7 +151,7 @@ do_install() {
 }
 ~~~
 
-For a complete listing of all of the plan settings, callbacks, and runtime hooks, see the [Plan syntax guide](/docs/plan-syntax).
+For a complete listing of all of the plan settings, callbacks, and runtime hooks, see the [Plan syntax guide](/docs/reference/plan-syntax).
 
 ## Entering the studio and doing an initial build
 

www/source/tutorials/getting-started-next-steps.html.md

@@ -14,13 +14,12 @@ In this tutorial you learned how to...
 - Add hooks and configuration
 - Build and start your first package
 
-There are many more great features to explore in Habitat! As you venture out, we recommend you keep the following resources at your side. The Docs are always being updated and we've got a great community that is ready and willing to help.
+There are many more great features to explore in Habitat! As you venture out, we recommend you keep the following resources at your side. The docs are always being updated and we've got a great community that is ready and willing to help.
 
 - [Habitat Docs](/docs)
 - [Habitat Open Source Community](/community)
 
-If you've got the time now, then we recommend you crack open the Docs and try your hand at writing a plan
-for one of you own projects. There's no better way to learn than by doing!
+If you've got the time now, then we recommend you crack open the docs and try your hand at writing a plan for one of you own projects. And if you want to extend the tutorial experience, dive into the [Run packages](/docs/run-packages-overview) section of the docs to start playing with the many runtime features of Habitat.
 
 <hr>
 <ul class="main-content--button-nav">

www/source/tutorials/getting-started-process-build.html.md

@@ -9,7 +9,7 @@ A supervisor manages any application or service process within a Habitat service
 
 Services can currently be run in two ways: You can either use the supervisor (`hab-sup`) directly, or you can use export the package and run it in an external runtime format. Using the `hab-sup` directly allows you to rapidly install and test your services before uploading any packages into a depot, but exporting your package into a different runtime format provides flexibility in where your packages run.
 
-For more information on how to natively run Habitat services or how to run services inside an external runtime format, see [Run Services](/docs/run-packages-overview).
+For more information on how to natively run Habitat services or how to run services inside an external runtime format, see [Run packages](/docs/run-packages-overview).
 
 To show the portability of Habitat, you will export and run a Habitat service from within a Docker container through the following steps: