Update existing lifecycle phases (Platform)

content/docs/for-platform-operators/concepts/lifecycle/_index.md

@@ -17,21 +17,21 @@ An **image build** requires 5 lifecycle phases, as shown below:
 
 > **Note**: when talking about lifecycle phases you'll sometimes see nouns like `analyzer` or `/cnb/lifecycle/analyzer`
 > and you'll sometimes see verbs like `analyze` or `analyze phase`.<br><br>
-> These are all more-or-less interchangeable: the nouns refer to the lifecycle binary and the verbs refer to the work that the lifecycle performs.
+> These are all more-or-less interchangeable: the nouns refer to the `lifecycle` binary and the verbs refer to the work that the `lifecycle` performs.
 
-The lifecycle must be run in a containerized environment (such as a Docker container or CI/CD system).
+The `lifecycle` must be run in a containerized environment (such as a `Docker` container or `CI/CD` system).
 
 The [`analyzer`][analyzer], [`restorer`][restorer], and [`exporter`][exporter] (shown in pink above)
-require access to an image repository - either an **OCI registry** or Docker-compliant **daemon** (such as Docker or Podman)
+require access to an image repository - either an **OCI registry** or Docker-compliant **daemon** (such as `Docker` or `Podman`)
 in order to do their work.
 
-This means that either registry credentials or a Docker socket must be available in the container where the lifecycle phase is running.
+This means that either registry credentials or a `Docker` socket must be available in the container where the lifecycle phase is running.
 For security hardening, these phases run in separate containers to avoid exposing sensitive data to **buildpacks**.
 
 The [`detector`][detector] and [`builder`][builder] (shown in purple above)
 invoke buildpacks to do the work of determining which buildpacks are needed and
 transforming application source code into runnable artifacts (the real work of buildpacks!).
-For security hardening, both the lifecycle and buildpacks run as non-root users when doing this work.
+For security hardening, both the `lifecycle` and buildpacks run as non-root users when doing this work.
 
 When a builder is [trusted][trusted builder], all 5 lifecycle phases can be run in the same container,
 and in this case the [`creator`][creator] binary is used to run all 5 lifecycle phases with a single command invocation.
@@ -54,4 +54,4 @@ These include phases relating to [starting][launcher] or [rebasing][rebaser] the
 [launcher]: /docs/for-platform-operators/concepts/lifecycle/launch
 [rebaser]: /docs/for-platform-operators/concepts/lifecycle/rebase
 [extender]: /docs/for-platform-operators/concepts/lifecycle/extend
-[platform api]: /docs/reference/spec/platform-api
+[platform api]: /docs/reference/spec/platform-api

content/docs/for-platform-operators/concepts/lifecycle/analyze.md

@@ -1,4 +1,3 @@
-
 +++
 title="Analyze"
 aliases=[
@@ -7,11 +6,11 @@ aliases=[
 weight=1
 +++
 
-The `analyzer` restores files that buildpacks may use to optimize the build and export phases.
+The `analyzer` restores files that buildpacks may use to optimize the `build` and `export` phases.
 
 <!--more-->
 
-Prior to `Platform API 0.7`, the `analyzer` was responsible for analyzing the metadata from the cache and the previously built image (if available) to determine what layers can or cannot be reused.
+Prior to `Platform API 0.7`, the `analyzer` was responsible for analyzing the metadata from the cache and the previously built image, if available, to determine what layers can or cannot be reused.
 This information is used during the `export` phase in order to avoid re-uploading unchanged layers.\
 Starting from `Platform API 0.7`, the `analyze` phase runs before the `detect` phase in order to validate registry access for all images that are used during the build as early as possible. In this way it provides faster failures for end users. The other responsibilities of the `analyzer` were moved to the `restorer`.\
 For more information, please see [this migration guide][platform-api-06-07-migration].
@@ -26,4 +25,4 @@ For more information, please see [this migration guide][platform-api-06-07-migra
 | `1-10`, `13-19` | Generic lifecycle errors            |
 | `30-39`         | Analysis-specific lifecycle errors  |
 
-[platform-api-06-07-migration]: https://buildpacks.io/docs/for-platform-operators/how-to/migrate/platform-api-0.6-0.7/
+[platform-api-06-07-migration]: https://buildpacks.io/docs/for-platform-operators/how-to/migrate/deprecated/platform-api-0.6-0.7/

content/docs/for-platform-operators/concepts/lifecycle/build.md

@@ -7,6 +7,8 @@ The `builder` transforms application source code into runnable artifacts that ca
 
 <!--more-->
 
+The `platform` must execute `builder` in the `build` environment.
+
 ### Exit Codes
 
 | Exit Code       | Result                              |
@@ -17,3 +19,7 @@ The `builder` transforms application source code into runnable artifacts that ca
 | `1-10`, `13-19` | Generic lifecycle errors            |
 | `51`            | Buildpack build error               |
 | `50`, `52-59`   | Build-specific lifecycle errors     |
+
+***
+
+For more information about the `builder`, see the [Platform API spec](https://github.com/buildpacks/spec/blob/main/platform.md#builder).

content/docs/for-platform-operators/concepts/lifecycle/create.md

@@ -3,12 +3,16 @@ title="Create"
 weight=6
 +++
 
-The `creator` runs analyze, detect, restore, build, and export in a single command.
+The `creator` runs `analyze`, `detect`, `restore`, `build`, and `export` in a single command.
 
 <!--more-->
 
+The `platform` must execute `creator` in the `build` environment.
+
 ### Exit Codes
 
+The outputs produced by `creator` are identical to those produced by `exporter`, with the following additional expanded set of error codes.
+
 | Exit Code       | Result                                |
 |-----------------|---------------------------------------|
 | `0`             | Success                               |
@@ -20,3 +24,7 @@ The `creator` runs analyze, detect, restore, build, and export in a single comma
 | `40-49`         | Restoration-specific lifecycle errors |
 | `50-59`         | Build-specific lifecycle errors       |
 | `60-69`         | Export-specific lifecycle errors      |
+
+***
+
+For more information about the `creator`, see the [Platform API spec](https://github.com/buildpacks/spec/blob/main/platform.md#creator).

content/docs/for-platform-operators/concepts/lifecycle/detect.md

@@ -1,4 +1,3 @@
-
 +++
 title="Detect"
 aliases=[
@@ -7,7 +6,7 @@ aliases=[
 weight=2
 +++
 
-The `detector` finds an ordered group of buildpacks to use during the build phase.
+The `detector` finds an ordered group of buildpacks to use during the `build` phase.
 
 <!--more-->
 
@@ -17,6 +16,7 @@ The detector is invoked in the build environment without any required arguments
 One of the [input files][inputs] is [`order.toml`][order] and two of its [output files][outputs] are [`group.toml`][group] and [`plan.toml`][plan].
 
 Unless some flags are passed in, the detector will use the following defaults:
+
 * Path resolution for order definition: `/cnb/order.toml`
 * Path to output group definition: `<layers>/group.toml`
 * Path to output resolved build plan: `<layers>/plan.toml`
@@ -31,6 +31,7 @@ If all of the groups fail, the detection process fails.
 
 Each buildpack in each group is marked as either optional or as required.
 In order to pass the detection process, two conditions must be satisfied:
+
 * The detect scripts of all required buildpacks must pass successfully (the exit code is zero).
 * The detector should be able to create a build plan (to be written in the `plan.toml`) with all of the requirements of the group’s buildpacks.
 
@@ -48,6 +49,7 @@ Each buildpack can define two lists with provided and required dependencies (or
 The detector reads the build plans of the buildpacks of the “chosen” group (after filtering out the buildpacks whose detect script failed). It goes over all of the options and tries to create a file with a list of entries, each with provides and requires lists, that fulfills all of the buildpacks requirements. Each of the options is called a trial, and this output file is called `plan.toml`.
 
 The two restrictions for provides and requires are:
+
 * A dependency that is provided by a buildpack, must be required by either the buildpack itself or by a later buildpack in the group.
 * A dependency that is required by a buildpack, must be provided by the buildpack itself or by a previous buildpack in the group.
 
@@ -57,19 +59,19 @@ If at least one of the above failed on a required buildpack, the trial fails and
 
 | Exit Code       | Result|
 |-----------------|-------|
-| `0`             | Success
-| `11`            | Platform API incompatibility error
-| `12`            | Buildpack API incompatibility error
-| `1-10`, `13-19` | Generic lifecycle errors
-| `20`            | All buildpacks groups have failed to detect w/o error
-| `21`            | All buildpack groups have failed to detect and at least one buildpack has errored
-| `22-29`         | Detection-specific lifecycle errors
+| `0`             | Success|
+| `11`            | Platform API incompatibility error|
+| `12`            | Buildpack API incompatibility error|
+| `1-10`, `13-19` | Generic lifecycle errors|
+| `20`            | All buildpacks groups have failed to detect w/o error|
+| `21`            | All buildpack groups have failed to detect and at least one buildpack has errored|
+| `22-29`         | Detection-specific lifecycle errors|
 
-### Some links to important parts of the code:
+### Some links to important parts of the code
 
-The following file is responsible for the detection command: https://github.com/buildpacks/lifecycle/blob/main/cmd/lifecycle/detector.go. 
+The following file is responsible for the detection command: <https://github.com/buildpacks/lifecycle/blob/main/cmd/lifecycle/detector.go>.
 
-The public functions in the above file are being called by the `Run` function in the following file: https://github.com/buildpacks/lifecycle/blob/main/cmd/command.go
+The public functions in the above file are being called by the `Run` function in the following file: <https://github.com/buildpacks/lifecycle/blob/main/cmd/lifecycle/cli/command.go>
 
 The spec of the detector can be found [here][spec].
 

content/docs/for-platform-operators/concepts/lifecycle/export.md

@@ -1,4 +1,3 @@
-
 +++
 title="Export"
 aliases=[

content/docs/for-platform-operators/concepts/lifecycle/extend.md

@@ -3,7 +3,7 @@ title="Extend"
 weight=9
 +++
 
-The `extender` applies Dockerfiles output by image extensions to the build or runtime base image.
+The `extender` applies Dockerfiles output by image extensions to the `build` or `runtime` base image.
 
 <!--more-->
 
@@ -16,3 +16,7 @@ The `extender` applies Dockerfiles output by image extensions to the build or ru
 | `12`            | Buildpack API incompatibility error |
 | `1-10`, `13-19` | Generic lifecycle errors            |
 | `100-109`       | Extension-specific lifecycle errors |
+
+***
+
+For more information about the `extender`, see the [Platform API spec](https://github.com/buildpacks/spec/blob/main/platform.md#extender-optional).

content/docs/for-platform-operators/concepts/lifecycle/launch.md

@@ -9,8 +9,16 @@ The `launcher` is the entrypoint for the final OCI image, responsible for launch
 
 ### Exit Codes
 
+If the `launcher` errors before executing the process, it will have one of the following error codes:
+
 | Exit Code | Result                              |
 |-----------|-------------------------------------|
 | `11`      | Platform API incompatibility error  |
 | `12`      | Buildpack API incompatibility error |
 | `80-89`   | Launch-specific lifecycle errors    |
+
+Otherwise, the exit code shall be the exit code of the launched process.
+
+***
+
+For more information about the `launcher`, see the [Platform API spec](https://github.com/buildpacks/spec/blob/main/platform.md#launcher).

content/docs/for-platform-operators/concepts/lifecycle/rebase.md

@@ -3,7 +3,7 @@ title="Rebase"
 weight=8
 +++
 
-The `rebaser` places application layers atop a new version of the runtime base image.
+The `rebaser` places application layers atop a new version of the `runtime` base image.
 
 <!--more-->
 
@@ -16,3 +16,7 @@ The `rebaser` places application layers atop a new version of the runtime base i
 | `12`            | Buildpack API incompatibility error |
 | `1-10`, `13-19` | Generic lifecycle errors            |
 | `70-79`         | Rebase-specific lifecycle errors    |
+
+***
+
+For more information about the `rebaser`, see the [Platform API spec](https://github.com/buildpacks/spec/blob/main/platform.md#rebaser).

content/docs/for-platform-operators/concepts/lifecycle/restore.md

@@ -16,3 +16,7 @@ The `restorer` copies layers from the cache into the build container.
 | `12`            | Buildpack API incompatibility error   |
 | `1-10`, `13-19` | Generic lifecycle errors              |
 | `40-49`         | Restoration-specific lifecycle errors |
+
+***
+
+For more information about the `restorer`, see the [Platform API spec](https://github.com/buildpacks/spec/blob/main/platform.md#restorer).