anchor.diff:  }
   ....
   
  -The `status` field records the state of the state machine (below) the
  -slot is in.
  +The `status` field records the state the slot is in.
   
   The `externalID` field contains the Oozie ID of the corresponding
   Oozie workflow execution if the slot is running, successful, or failed
  
positive.code: 
  We're proud that in the years of use, not a single bug in Celos has
  caused any downtime, which is attributable to the small codebase
  (about 2000 lines of non-blank, non-commented code for core Celos, as
  measured by cloc) and the rigorous test suite (hundreds of unit tests
  and an extensive integration test).
  
  == Building & Running Celos
  
  
negative.code: 
  == Introduction
  
  Celos is a tool for running periodical workflows that process data in
  Hadoop.
  
  * Written in Java and scripted using JavaScript (which, depending on
    your tastes, may be good or bad).
  
  * Using a general-purpose scripting language for defining workflows
    saves you from configuration hell.
  
  * Simple and robust architecture, that keeps running even when Hadoop
    is down, and picks up where it left off when it's back up.
  
  * Support for continuous delivery of workflows.
  
  * Parsimonious user interface that nevertheless gives a good overview
    over hundreds of workflows.
  
  * Battle-tested for years at
    link:http://www.collective.com[Collective, Inc] and found virtually
    bug-free.
  
  image::etc/images/celos-ui.png[Celos UI]
  
  The Celos UI.
  
  === Oozie
  
  Celos works as a frontend to the
  link:https://oozie.apache.org/[_Apache Oozie_] execution engine.
  Oozie provides services such as distribution of jobs across the
  cluster, log aggregation, and command-line and Web UI tools for
  inspecting running jobs.
  
  To run a job in Oozie it is packaged into a directory and put into
  HDFS, as the following diagram shows:
  
  image::etc/images/oozie.png[Oozie workflow directory]
  
  Oozie requires a small `workflow.xml` file that describes what the job
  should do (in this case call a Java main with some arguments), and
  then runs it on a processing node in the cluster.  Artefacts in the
  `lib` directory are automatically placed on the classpath.  Arguments
  (such as `inputPath` and `outputPath` in the above example) can be
  passed to the job.
  
  Oozie XML files support
  link:https://oozie.apache.org/docs/4.2.0/WorkflowFunctionalSpec.html[many
  different kinds of actions] besides calling Java, such as manipulating
  HDFS, loading data into databases, or sending emails.  This is mostly
  out of scope for this document, but in general, Celos workflows can
  use all features of Oozie.
  
  You can view all currently running jobs in the Oozie Web UI, _Hue_:
  
  image::etc/images/hue-index.png[Hue index]
  
  You can also view details of a particular job in Hue:
  
  image::etc/images/hue-details.png[Hue details]
  
  === Celos Concepts
  
  ==== Workflows
  
  If we have the Oozie job directory to run in HDFS at `/wordcount`,
  hourly input data in `/input/YYYY-MM-DD/HH00`, and want to write
  output data to `/output/YYYY-MM-DD/HH00`, we can set up a simple Celos
  workflow with the ID `wordcount` like this:
  
  [source,javascript]
  ....
  