fix broken links

docs/010-overview.md

@@ -8,13 +8,13 @@ tags: [diego-release, bbs]
 
 Diego is Cloud Foundry's next generation container runtime, and the BBS server is its central orchestrator.
 
-The BBS accepts client requests from both inside and outside a Diego cluster, dispatching work to the [auctioneer](http://github.com/cloudfoundry/auctioneer) so it can balance work among the [cells](cells.md). In Diego, there are two distinct types of work:
+The BBS accepts client requests from both inside and outside a Diego cluster, dispatching work to the [auctioneer](http://github.com/cloudfoundry/auctioneer) so it can balance work among the [cells](011-cells.md). In Diego, there are two distinct types of work:
 
-- [**Tasks**](tasks.md) are one-off processes that Diego guarantees will run at most once.
-- [**Long-Running Processes**](lrps.md) (LRPs) are processes that Diego monitors for health continually.  Diego can distribute, run, and monitor several identical instances of a given LRP. When an LRP instance crashes, Diego restarts it automatically.
+- [**Tasks**](020-tasks.md) are one-off processes that Diego guarantees will run at most once.
+- [**Long-Running Processes**](030-lrps.md) (LRPs) are processes that Diego monitors for health continually.  Diego can distribute, run, and monitor several identical instances of a given LRP. When an LRP instance crashes, Diego restarts it automatically.
 
-Tasks and LRP instances run in [Garden](http://github.com/cloudfoundry-incubator/garden) containers on Diego Cells.  The filesystem mounted into these containers can be either a 'preloaded' rootfs colocated with the Diego cell or an arbitrary Docker image. Diego also provides some additional [environment variables](environment.md) to processes running in its containers.
+Tasks and LRP instances run in [Garden](http://github.com/cloudfoundry-incubator/garden) containers on Diego Cells.  The filesystem mounted into these containers can be either a 'preloaded' rootfs colocated with the Diego cell or an arbitrary Docker image. Diego also provides some additional [environment variables](051-environment.md) to processes running in its containers.
 
 In addition to launching and monitoring Tasks and LRPs, Diego streams logs from containers and cells to end users via the [Loggregator system](http://github.com/cloudfoundry/loggregator). Diego also allows clients to store routing data on LRPs. In Cloud Foundry, routing tiers such as the [HTTP Gorouter](http://github.com/cloudfoundry/gorouter) and the [TCP router](https://github.com/cloudfoundry-incubator/cf-tcp-router) use this data to route external traffic to container processes.
 
-Diego provides only a basic notion of client multitenancy via the concept of a [domain](domains.md). Enforcement of richer multitenancy, such as quotas for organizations or visibility restrictions for different users, falls on the [Cloud Controller](http://github.com/cloudfoundry/cloud_controller_ng) in the case of Cloud Foundry.
+Diego provides only a basic notion of client multitenancy via the concept of a [domain](050-domains.md). Enforcement of richer multitenancy, such as quotas for organizations or visibility restrictions for different users, falls on the [Cloud Controller](http://github.com/cloudfoundry/cloud_controller_ng) in the case of Cloud Foundry.

docs/011-cells.md

@@ -33,5 +33,3 @@ manages containers, and reports app status and other data to the BBS and Loggreg
 ## Metron Agent
 
 * Forwards application logs, errors, and application and Diego metrics to the Loggregator Doppler component
-
-[back](README.md)

docs/012-api-cells.md

@@ -50,4 +50,3 @@ None.
 client := bbs.NewClient(url)
 cells, err := client.Cells(logger)
 ```
-[back](README.md)

docs/020-tasks.md

@@ -101,6 +101,3 @@ If `ResultFile` was specified and the Task has completed succesfully, `Result` w
 #### `Annotation`
 
 This is the arbitrary string that was specified in the TaskDefinition.
-
-
-[back](README.md)

docs/021-defining-tasks.md

@@ -6,7 +6,7 @@ tags: [diego-release, bbs]
 
 ## Defining Tasks
 
-This document explains the fields available when defining a new Task. For a higher-level overview of the Diego Task API, see the [Tasks Overview](tasks.md).
+This document explains the fields available when defining a new Task. For a higher-level overview of the Diego Task API, see the [Tasks Overview](020-tasks.md).
 
 ```go
 client := bbs.NewClient(url)
@@ -155,23 +155,23 @@ Setting `ImagePassword` requires the `ImageUsername` to also be set.
 
 ##### `EnvironmentVariables` [optional]
 
-See description of [Environment Variables](common-models.md#environmentvariables-optional)
+See description of [Environment Variables](054-common-models.md#environmentvariables-optional)
 
 ##### `CachedDependencies` [optional]
 
-See description of [Cached Dependencies](common-models.md#cacheddependencies-optional)
+See description of [Cached Dependencies](054-common-models.md#cacheddependencies-optional)
 
 ##### `ImageLayers` [optional]
 
-See description of [Image Layers](common-models.md#imagelayers-optional)
+See description of [Image Layers](054-common-models.md#imagelayers-optional)
 
 ##### `TrustedSystemCertificatesPath` [optional]
 
 An absolute path inside the container's filesystem where trusted system certificates will be provided if an operator has specified them.
 
 ##### `VolumeMounts` [optional]
 
-See description of [Volume Mounts](common-models.md#volumemounts-optional)
+See description of [Volume Mounts](054-common-models.md#volumemounts-optional)
 
 ##### `PlacementTags` [optional]
 
@@ -225,7 +225,7 @@ A memory limit in mebibytes applied to the container.  If the total memory consu
 
 ##### `Action` [required]
 
-Encodes the action to execute when running the Task.  For more details, see the section on [Actions](actions.md).
+Encodes the action to execute when running the Task.  For more details, see the section on [Actions](053-actions.md).
 
 
 #### Task Completion and Output
@@ -258,7 +258,7 @@ By default network access for any container is limited but some tasks may need s
 
 ##### `EgressRules` [optional]
 
-See description of [EgressRules](common-models.md#egressrules-optional)
+See description of [EgressRules](054-common-models.md#egressrules-optional)
 
 ---
 
@@ -286,7 +286,3 @@ The `MetricsGuid` field sets the `ApplicationId` on container metris coming from
 ##### `Annotation` [optional]
 
 Diego allows arbitrary annotations to be attached to a Task.  The annotation may not exceed 10 kilobytes in size.
-
-
-
-[back](README.md)

docs/022-task-examples.md

@@ -83,5 +83,3 @@ if err != nil {
   log.Printf("failed to cancel task: " + err.Error())
 }
 ```
-
-[back](README.md)

docs/023-api-tasks.md

@@ -279,4 +279,3 @@ if err != nil {
     log.Printf("failed to delete task: " + err.Error())
 }
 ```
-[back](README.md)

docs/024-api-tasks-internal.md

@@ -55,7 +55,7 @@ if shouldStart {
 
 ## FailTask
 
-**Deprecated** in favor of [CompleteTask](api-tasks-internal.md#completetask) and [CancelTask](api-tasks.md#canceltask).
+**Deprecated** in favor of [CompleteTask](024-api-tasks-internal.md#completetask) and [CancelTask](023-api-tasks.md#canceltask).
 
 ### BBS API Endpoint
 
@@ -155,5 +155,3 @@ if err != nil {
     log.Printf("could not complete task: " + err.Error())
 }
 ```
-
-[back](README.md)

docs/030-lrps.md

@@ -114,7 +114,7 @@ The fact that a DesiredLRP is present in Diego does not mean that the correspond
 
 ## Fetching ActualLRPs
 
-As outlined above, DesiredLRPs represent the consumer's intent for Diego to run instances.  To fetch instances, consumers must [fetch ActualLRPs](api-lrps.md#actuallrp-apis).
+As outlined above, DesiredLRPs represent the consumer's intent for Diego to run instances.  To fetch instances, consumers must [fetch ActualLRPs](033-api-lrps.md#actuallrp-apis).
 
 When fetching ActualLRPs, one can fetch *all* ActualLRPs in Diego, all ActualLRPs of a given `domain`, all ActualLRPs for a given DesiredLRP by `process_guid`, and all ActualLRPs at a given *index* for a given `process_guid`.
 
@@ -216,7 +216,7 @@ Indicates if the ActualLRP can respond to traffic succesfully or not.
 
 When an ActualLRP is first created, `routable` is set by default to `False`.
 
-Once the ActualLRP is assigned to a cell, the container performs start up and parallel healthchecking processes, including optional [readiness checks as defined in the DesiredLRP](./defining-lrps.md).
+Once the ActualLRP is assigned to a cell, the container performs start up and parallel healthchecking processes, including optional [readiness checks as defined in the DesiredLRP](./031-defining-lrps.md).
 
 After the readiness checks pass, or if there are no readiness checks defined at all, the ActualLRP `routable` field is tranistioned from `False` to `True`.
 
@@ -240,7 +240,7 @@ The availability zone of the Diego cell where ActualLRP is running.
 
 ## Killing ActualLRPs
 
-Diego supports killing the `ActualLRP`s for a given `process_guid` at a given `index`.  This is documented [here](api-lrps.md#retireactuallrp).  Note that this does not change the *desired* state -- Diego will simply shut down the `ActualLRP` at the given `index` and will eventually converge on desired state by restarting the (now-missing) instance.  To permanently scale down a DesiredLRP you must update the `instances` field on the DesiredLRP.
+Diego supports killing the `ActualLRP`s for a given `process_guid` at a given `index`.  This is documented [here](033-api-lrps.md#retireactuallrp).  Note that this does not change the *desired* state -- Diego will simply shut down the `ActualLRP` at the given `index` and will eventually converge on desired state by restarting the (now-missing) instance.  To permanently scale down a DesiredLRP you must update the `instances` field on the DesiredLRP.
 
 
 ## Domain Freshness
@@ -251,10 +251,8 @@ In order to perform this responsibility safely, however, Diego must have some wa
 
 To circumvent this, it is up to the consumer of Diego to inform Diego that its knowledge of the desired state is up-to-date.  We refer to this as the "freshness" of the desired state.  Consumers explicitly mark desired state as *fresh* on a domain-by-domain basis.  Failing to do so will prevent Diego from taking actions to ensure eventual consistency (in particular, Diego will refuse to stop extra instances with no corresponding desired state).
 
-To maintain freshness you perform a simple [POST](domains.md#upserting-a-domain).  The consumer typically supplies a TTL and attempts to bump the freshness of the domain before the TTL expires (verifying along the way, of course, that the contents of Diego's DesiredLRP are up-to-date).
+To maintain freshness you perform a simple [POST](050-domains.md#upserting-a-domain).  The consumer typically supplies a TTL and attempts to bump the freshness of the domain before the TTL expires (verifying along the way, of course, that the contents of Diego's DesiredLRP are up-to-date).
 
 It is possible to opt out of this by updating the freshness with *no* TTL.  In this case the freshness will never expire and Diego will always perform all its eventual consistency operations.
 
 > Note: only destructive operations performed during an eventual consistency convergence cycle are gated on freshness.  Diego will continue to start/stop instances when explicitly instructed to.
-
-[back](README.md)

docs/031-defining-lrps.md

@@ -6,7 +6,7 @@ tags: [diego-release, bbs]
 
 ### Defining LRPs
 
-This document explains the fields available when defining a new LRP. For a higher-level overview of the Diego LRP API, see the [LRPs Overview](lrps.md).
+This document explains the fields available when defining a new LRP. For a higher-level overview of the Diego LRP API, see the [LRPs Overview](030-lrps.md).
 
 ```go
 client := bbs.NewClient(url)
@@ -141,7 +141,7 @@ refer to it by its `ProcessGuid`.
 - If you attempt to create a DesiredLRP with a `ProcessGuid` that matches that
   of an existing DesiredLRP, Diego will attempt to update the existing
   DesiredLRP.  This is subject to the rules described in [updating
-  DesiredLRPs](lrps.md#updating-desiredlrps) below.
+  DesiredLRPs](030-lrps.md#updating-desiredlrps) below.
 
 
 ##### `Domain` [required]
@@ -211,23 +211,23 @@ Setting `ImagePassword` requires the `ImageUsername` to also be set.
 
 ##### `EnvironmentVariables` [optional]
 
-See description of [Environment Variables](common-models.md#environmentvariables-optional)
+See description of [Environment Variables](054-common-models.md#environmentvariables-optional)
 
 ##### `CachedDependencies` [optional]
 
-See description of [Cached Dependencies](common-models.md#cacheddependencies-optional)
+See description of [Cached Dependencies](054-common-models.md#cacheddependencies-optional)
 
 ##### `ImageLayers` [optional]
 
-See description of [Image Layers](common-models.md#imagelayers-optional)
+See description of [Image Layers](054-common-models.md#imagelayers-optional)
 
 ##### `TrustedSystemCertificatesPath` [optional]
 
 An absolute path inside the container's filesystem where trusted system certificates will be provided if an operator has specified them.
 
 ##### `VolumeMounts` [optional]
 
-See description of [Volume Mounts](common-models.md#volumemounts-optional)
+See description of [Volume Mounts](054-common-models.md#volumemounts-optional)
 
 ##### `PlacementTags` [optional]
 
@@ -295,15 +295,15 @@ Diego is responsible for performing any container setup necessary to successfull
 
 After creating a container, Diego will first run the action specified in the `Setup` field.
 This field is optional and is typically used to download files and run (short-lived) processes that configure the container.
-For more details on the available actions see [actions](actions.md).
+For more details on the available actions see [actions](053-actions.md).
 
 - If the `Setup` action fails the `ActualLRP` is considered to have crashed and will be restarted
 
 ##### `Action` [required]
 
 After completing any `Setup` action, Diego will launch the `Action` action.
 This `Action` is intended to launch any long-running processes.
-For more details on the available actions see [actions](actions.md).
+For more details on the available actions see [actions](053-actions.md).
 
 ##### `CheckDefinition` [optional]
 
@@ -360,7 +360,7 @@ A TCP health check.
 
 If provided, Diego will monitor the long running processes encoded in `Action` by periodically invoking the `Monitor` action.
 If the `Monitor` action returns succesfully (exit status code 0), the container is deemed "healthy", otherwise the container is deemed "unhealthy".
-Monitoring is quite flexible in Diego and is outlined in more detail [here](lrps.md#monitoring-health).
+Monitoring is quite flexible in Diego and is outlined in more detail [here](030-lrps.md#monitoring-health).
 
 ##### `StartTimeoutMs` [required]
 
@@ -399,7 +399,7 @@ The total length of the routing information must not exceed 131072 bytes (128kb)
 
 ##### `EgressRules` [optional]
 
-See description of [EgressRules](common-models.md#egressrules-optional)
+See description of [EgressRules](054-common-models.md#egressrules-optional)
 
 #### Logging
 
@@ -438,5 +438,3 @@ clients.
 
 Diego allows arbitrary annotations to be attached to a DesiredLRP.
 The annotation must not exceed 10 kilobytes in size.
-
-[back](README.md)

docs/032-lrp-examples.md

@@ -159,5 +159,3 @@ if err != nil {
     log.Printf("failed to remove desired lrp: " + err.Error())
 }
 ```
-
-[back](README.md)

docs/033-api-lrps.md

@@ -543,4 +543,3 @@ if err != nil {
     log.Printf("failed to remove desired lrp: " + err.Error())
 }
 ```
-[back](README.md)

docs/034-api-lrps-internal.md

@@ -489,4 +489,3 @@ if err != nil {
     log.Printf("failed to remove evacuating actual lrp: " + err.Error())
 }
 ```
-[back](README.md)

docs/041-revisioning-bbs-api-endpoints.md

@@ -53,5 +53,4 @@ based on when each was introduced:
 |                                  | `/v1/desired_lrps/list.r3` (new) |                            |                            |
 
 # See Also
-- To find more documentation about specific endpoints, look in the [table of contents](README.md) for links to API references.
-- To find information about endpoints that are deprecated (that is, still supported but planned to be removed in the next major release), look at [this document in diego-release](https://github.com/cloudfoundry/diego-release/blob/develop/docs/deprecations.md#bbs-1).
+- To find information about endpoints that are deprecated (that is, still supported but planned to be removed in the next major release), look at [this document in diego-release](https://github.com/cloudfoundry/diego-release/blob/develop/docs/081-deprecations.md#bbs-1).

docs/042-bbs-migration.md

@@ -34,4 +34,3 @@ This will create test and implementation files for your migration in
 `db/migrations`. Look for `TODO` comments in the test file to get started.
 
 Note that the test file includes a test for migration idempotency.
-

docs/050-domains.md

@@ -116,4 +116,3 @@ None.
 client := bbs.NewClient(url)
 domains, err := client.Domains(logger)
 ```
-[back](README.md)

docs/051-environment.md

@@ -8,9 +8,9 @@ tags: [diego-release, bbs]
 Diego provides several collections of environment variables to processes running in containers.  These include the following layers, in order:
 
 - Environment variables baked into the Docker image (for Docker-image-based containers only)
-- Container-level environment variables (defined on the [`Task`](tasks.md) and [`DesiredLRP`](lrps.md) objects)
+- Container-level environment variables (defined on the [`Task`](020-tasks.md) and [`DesiredLRP`](030-lrps.md) objects)
 - Configuration environment variables (LRPs only, described below)
-- Process-level environment variables (defined on the [`RunAction`](actions.md#runaction) object)
+- Process-level environment variables (defined on the [`RunAction`](053-actions.md#runaction) object)
 
 ## Configuration-level Environment Variables
 
@@ -27,8 +27,6 @@ LRPs have additional runtime properties that are exposed to processes in the con
 These environment variables are provided *only* if the operator deploying Diego has enabled `-exportNetworkEnvVars` on the Cell rep.
 
 - `CF_INSTANCE_IP` provides the IP of the host running the container.  This is the IP used to address the container from the outside.
-- `CF_INSTANCE_PORT` contains the host-side port corresponding to the *first* port in the `DesiredLRP` [`ports`](lrps.md#ports) array.
+- `CF_INSTANCE_PORT` contains the host-side port corresponding to the *first* port in the `DesiredLRP` [`ports`](030-lrps.md#ports) array.
 - `CF_INSTANCE_ADDR` is identical to `$CF_INSTANCE_IP:$CF_INSTANCE_PORT`.
-- `CF_INSTANCE_PORTS` contains a list of JSON objects of the form `[{"external":60413,"internal":8080},{"external":60414,"internal":2222}]`. The internal ports are the container-side ports specified in the `DesiredLRP` [`ports`](lrps.md#ports) array, and the external ports are the corresponding host-side ports.
-
-[back](README.md)
+- `CF_INSTANCE_PORTS` contains a list of JSON objects of the form `[{"external":60413,"internal":8080},{"external":60414,"internal":2222}]`. The internal ports are the container-side ports specified in the `DesiredLRP` [`ports`](030-lrps.md#ports) array, and the external ports are the corresponding host-side ports.

docs/052-events.md

@@ -250,5 +250,3 @@ When a Task is deleted, a
 [TaskRemovedEvent](https://godoc.org/code.cloudfoundry.org/bbs/models#TaskRemovedEvent)
 is emitted. The field value of `Task` will have information about the
 Task that was just removed.
-
-[back](README.md)

docs/053-actions.md

@@ -6,7 +6,7 @@ tags: [diego-release, bbs]
 
 # Available Actions
 
-[Tasks](tasks.md) and [LRPs](lrps.md) express their work in terms of composable Actions. The following types of Action are available:
+[Tasks](020-tasks.md) and [LRPs](030-lrps.md) express their work in terms of composable Actions. The following types of Action are available:
 
 - Basic Actions:
     - [`RunAction`](#runaction): Runs a process in the container.
@@ -356,6 +356,3 @@ The action to run.
 
 If provided, logs emitted by this action and its subaction will be tagged with
 the provided `LogSource`.  Otherwise the container-level `LogSource` is used.
-
-
-[back](README.md)