anchor.diff:  For this reason, uploading a blob and then removing it is considered poor practice.
   
   When creating dev releases, you should run `bosh add blob` to inform
  -BOSH of local paths to blobs, but refrain from running `bosh upload blob`.
  -That command is discussed in connection with dev releases.
  +BOSH of local paths to blobs, but refrain from running `bosh upload blobs`.
  +That command is discussed in connection with final releases.
   
   ## <a id="..."></a> Update Specs to Complete Jobs ##
   
   _what have we not done yet?_
   
  -## <a id="..."></a> Create Release Properties  ##
  +## <a id="..."></a> Create Job Properties  ##
   
   * Properties are inputs ...
   * Coordinating with the `properties` block in the manifest...
  
positive.code: At compile time, BOSH translates `BOSH_INSTALL_TARGET` to the actual location on deployed VMs
  where binaries need to be.
  If the instructions you provide in the packaging scripts fail to deliver compiled code to
  `BOSH_INSTALL_TARGET`, then as far as your release is concerned, that code does not exist.
  This failure scenario can happen if, for example, you use a `make` command that by default
  delivers compiled code to some standard location.
  That is why you need some equivalent of the `configure` command in the example packaging
  
negative.code: 
  ### <a id="control"></a> Create control scripts for the jobs  ###
  
  Every deployed job needs a way to start and stop.
  You provide that in a BOSH release by writing a control script for each job.
  
  The control script:
  