anchor.diff:  
   [**Executor on GitHub**](https://github.com/cloudfoundry-incubator/executor)
   
  -### <a id=''></a> Garden
  +### <a id='garden'></a> Garden
   
   - provides a platform-independent server/client to manage garden containers
   
  
positive.code: - annotate containers with arbitrary metadata
  - snapshot containers for down-timeless redeploys
  
  Current implementations:
  
  - [**Garden-Linux**](https://github.com/cloudfoundry-incubator/garden-linux) provides a linux-specific implementation of a Garden interface.
  
  ### <a id='app-lifecycles'></a>App Lifecycles
  
  Each App Lifecycle provides a set of binaries that manage a *Cloud Foundry*-specific application lifecycle.  There are three binaries:
  
  - The **Builder** *stages* a CF application.  The CC-Bridge runs the Builder as a Task on every staging request.  The Builder perfoms static analysis on the application code and does any necessary pre-processing before the application is first run.
  - The **Launcher** *runs* a CF application.  The CC-Bridge sets the Launcher as the Action on the CF application's DesiredLRP.  The Launcher executes the user's start command with the correct system context (working directory, environment variables, etc).  
  
negative.code: 
  [**Rep on GitHub**](https://github.com/cloudfoundry-incubator/rep)
  
  ### <a id='executor'></a> Executor
  
  - the Executor doesn't know about the Task vs LRP distinction.  It is primarily responsible for implementing the generic executor actions detailed in the [API documentation](https://github.com/cloudfoundry-incubator/receptor/blob/master/doc/actions.md)
  
  