Merge pull request #413 from devigned/fix-image-ex-typo

fix typo to image extension link

CODEOWNERS

@@ -1 +1,6 @@
-* @buildpacks/core-team
+/platform.md @buildpacks/implementation-team-lead @buildpacks/platform-team-lead
+/buildpack.md @buildpacks/bat-team-lead @buildpacks/implementation-team-lead 
+/distribution.md @buildpacks/distribution-team-lead @buildpacks/platform-team-lead
+/extensions/buildpack-registry.md @buildpacks/distribution-team-lead
+/extensions/project-descriptor.md @buildpacks/platform-team-lead
+* @buildpacks/team-leads

OWNERS

@@ -1,4 +0,0 @@
-Stephen Levine, Pivotal <slevine@pivotal.io> (@sclevine)
-Ben Hale, Pivotal <bhale@pivotal.io> (@nebhale)
-Terence Lee, Salesforce <hone02@gmail.com> (@hone)
-Joe Kutner, Salesforce <jkutner@salesforce.com> (@jkutner)

README.md

@@ -50,6 +50,6 @@ When the specification refers to a path in the context of an OCI layer tar (e.g.
 
 These documents currently specify:
 
-- Buildpack API: `0.7`
+- Buildpack API: `0.10`
 - Distribution API: `0.3`
-- Platform API: `0.8`
+- Platform API: `0.14`

buildpack.md

@@ -2,23 +2,14 @@
 
 This document specifies the interface between a lifecycle program and one or more buildpacks.
 
-The lifecycle program uses buildpacks to build software artifacts from source code and pack the result into an OCI image.
-
-This is accomplished in four phases:
-
-1. **Detection,** where an optimal selection of compatible buildpacks is chosen.
-2. **Analysis,** where metadata about OCI layers generated during a previous build are made available to buildpacks.
-3. **Build,** where buildpacks use that metadata to generate only the OCI layers that need to be replaced.
-4. **Export,** where the remote layers are replaced by the generated layers.
-
-The `ENTRYPOINT` of the OCI image contains logic implemented by the lifecycle that executes during the **Launch** phase.
-
 ## Table of Contents
 
 <!-- Using https://github.com/yzhang-gh/vscode-markdown to manage toc -->
 - [Buildpack Interface Specification](#buildpack-interface-specification)
   - [Table of Contents](#table-of-contents)
   - [Buildpack API Version](#buildpack-api-version)
+  - [Terminology](#terminology)
+    - [CNB Terminology](#cnb-terminology)
   - [Buildpack Interface](#buildpack-interface)
     - [Buildpack API Compatibility](#buildpack-api-compatibility)
     - [Key](#key)
@@ -30,7 +21,6 @@ The `ENTRYPOINT` of the OCI image contains logic implemented by the lifecycle th
       - [Build Layers](#build-layers)
       - [Cached Layers](#cached-layers)
       - [Ignored Layers](#ignored-layers)
-  - [App Interface](#app-interface)
   - [Phase #1: Detection](#phase-1-detection)
     - [Purpose](#purpose)
     - [Process](#process)
@@ -38,24 +28,29 @@ The `ENTRYPOINT` of the OCI image contains logic implemented by the lifecycle th
   - [Phase #2: Analysis](#phase-2-analysis)
     - [Purpose](#purpose-1)
     - [Process](#process-1)
-  - [Phase #3: Build](#phase-3-build)
+  - [Phase #3: Generation (image extensions only)](#phase-3-generation-image-extensions-only)
     - [Purpose](#purpose-2)
     - [Process](#process-2)
+  - [Phase #4: Extension (image extensions only)](#phase-4-extension-image-extensions-only)
+    - [Purpose](#purpose-3)
+  - [Phase #5: Build (component buildpacks only)](#phase-5-build-component-buildpacks-only)
+    - [Purpose](#purpose-4)
+    - [Process](#process-3)
       - [Unmet Buildpack Plan Entries](#unmet-buildpack-plan-entries)
-      - [Software Bill of Materials](#software-bill-of-materials)
+      - [Software-Bill-of-Materials](#software-bill-of-materials)
       - [Layers](#layers)
         - [Providing Layers](#providing-layers)
         - [Reusing Layers](#reusing-layers)
         - [Slice Layers](#slice-layers)
-  - [Phase #4: Export](#phase-4-export)
-    - [Purpose](#purpose-3)
-    - [Process](#process-3)
-  - [Launch](#launch)
-    - [Purpose](#purpose-4)
+  - [Phase #6: Export](#phase-6-export)
+    - [Purpose](#purpose-5)
     - [Process](#process-4)
+  - [Launch](#launch)
+    - [Purpose](#purpose-6)
+    - [Process](#process-5)
   - [Environment](#environment)
     - [Provided by the Lifecycle](#provided-by-the-lifecycle)
-      - [Buildpack Specific Variables](#buildpack-specific-variables)
+      - [Targets](#targets)
       - [Layer Paths](#layer-paths)
     - [Provided by the Platform](#provided-by-the-platform)
     - [Provided by the Buildpacks](#provided-by-the-buildpacks)
@@ -76,30 +71,77 @@ The `ENTRYPOINT` of the OCI image contains logic implemented by the lifecycle th
     - [Buildpack Plan (TOML)](#buildpack-plan-toml)
     - [Layer Content Metadata (TOML)](#layer-content-metadata-toml)
     - [buildpack.toml (TOML)](#buildpacktoml-toml)
-      - [Buildpack Implementations](#buildpack-implementations)
-      - [Order Buildpacks](#order-buildpacks)
+      - [Targets](#targets-1)
+      - [Order](#order)
     - [Exec.d Output (TOML)](#execd-output-toml)
   - [Deprecations](#deprecations)
-    - [`0.3`](#03)
-      - [Build Plan (TOML) `requires.version` Key](#build-plan-toml-requiresversion-key)
+    - [buildpack.toml (TOML) `stacks` Array](#buildpacktoml-toml-stacks-array)
+    - [Positional Arguments to `detect` and `build` Executables](#positional-arguments-to-detect-and-build-executables)
+    - [launch.toml (TOML) `bom` Array](#launchtoml-toml-bom-array)
+    - [build.toml (TOML) `bom` Array](#buildtoml-toml-bom-array)
+    - [Build Plan (TOML) `requires.version` Key](#build-plan-toml-requiresversion-key)
 
 ## Buildpack API Version
-This document specifies Buildpack API version `0.7`
+This document specifies Buildpack API version `0.10`
 
 Buildpack API versions:
  - MUST be in form `<major>.<minor>` or `<major>`, where `<major>` is equivalent to `<major>.0`
  - `<major>` and `<minor>` MUST only contain numbers (unsigned 64 bit integer)
  - When `<major>` is greater than `0` increments to `<minor>` SHALL exclusively indicate additive changes
 
+## Terminology
+
+### CNB Terminology
+
+A **buildpack** is a directory containing a `buildpack.toml`. Buildpacks analyze application source code and determine the best way to build it.
+
+A **buildpack group**, or **group**, is a list of one or more buildpacks that are designed to work together - for example, a buildpack that provides `node` and a buildpack that provides `npm`.
+
+An **order** is a list of one or more groups to be tested against application source code, so that the appropriate group for a build can be determined. 
+
+A **component buildpack** is a buildpack containing `/bin/detect` and `/bin/build` executables. Component buildpacks implement the [Buildpack Interface](#buildpack-interface).
+
+A **composite buildpack** is a buildpack containing an order definition in `buildpack.toml`. Composite buildpacks do not contain `/bin/detect` or `/bin/build` executables. They MUST be [resolvable](#order-resolution) into a collection of component buildpacks.
+
+An **image extension** is a directory containing an `extension.toml`. Extensions generate Dockerfiles that can be used to define the runtime base image, prior to buildpack execution. Extensions implement the [Image Extension Interface](image_extension.md). Extensions are always "component": their `extension.toml` cannot contain an order definition.
+
+**Resolving an order** is the process by which an order (which may contain image extensions, component buildpacks, or composite buildpacks) is evaluated together with application source code to produce an optional group of image extensions and a required group of component buildpacks that can be used to build the application. This process is known as **detection**. During detection, the `/bin/detect` executable for each image extension (if present) and the `/bin/detect` executable for each component buildpack is invoked.
+
+An **optional** image extension or buildpack is a group element that, when failing detection, will be excluded from the group without causing the entire group to fail.
+
+A **build plan** is a file used during detection, in which each image extension or component buildpack may express the dependencies that it requires and the dependencies that it provides. A group will only pass detection if a valid build plan can be produced from the dependencies that all elements in the group require and provide. A valid build plan is a plan where all required dependencies are provided in the necessary order, meaning that during the build phase, each component buildpack will have its required dependencies provided by an image extension or component buildpack that runs before it.
+
+A **buildpack plan** is a file unique to each image extension or component buildpack, used during the generation or build phase to communicate the dependencies that it is expected to provide.
+
+A **lifecycle** is software that orchestrates a build. It executes in a series of phases that each have a distinct responsibility.
+
+A **launcher** is an executable that is the `ENTRYPOINT` of the exported OCI image. It is used to start processes at runtime. Having a launcher enables multiple process types to be defined on an image, with process-specific environment variables and other functionality.
+
+**Launch** describes the process of running an application by creating a container from the exported OCI image.
+
+A **platform** is a system or software that orchestrates the lifecycle by invoking each lifecycle phase in order.
+
+A **process definition** is a description, provided by component buildpacks during the build phase, of a process to launch at runtime.
+
+An **application directory** is a directory containing application source code. Component buildpacks may make changes to the application directory during the build phase.
+
+A **layer** is a set of filesystem changes packaged according to the [OCI Image Specification](https://github.com/opencontainers/image-spec/blob/main/layer.md).
+
+A **layer directory** is a directory created by a component buildpack that contains build and/or runtime dependencies, and can be used to configure the build and/or runtime environment. There are three **layer types**:
+  * a **launch layer** is added as a layer in the exported OCI image; it can be re-used on the next build (the lifecycle can avoid re-uploading it) if the component buildpack that created the layer has the same requirements on the next build
+  * a **cache layer** is saved to the cache and its contents may be restored on the next build
+  * a **build layer** contains child directories with paths that are added to the environment (e.g., `PATH`, `LD_LIBRARY_PATH`, etc.) for subsequent buildpacks in the same build
+Any combination of the three layer types are valid for a particular layer directory.
+
 ## Buildpack Interface
 
-The following specifies the interface implemented by executables in each buildpack.
-The lifecycle MUST invoke these executables as described in the Phase sections.
+The following specifies the interface implemented by component buildpacks.
+The lifecycle MUST invoke executables in component buildpacks as described in the Phase sections.
 
 ### Buildpack API Compatibility
 Given a buildpack declaring `<buildpack API Version>` in its [`buildpack.toml`](#buildpacktoml-toml), the lifecycle:
 - MUST either conform to the matching version of this specification when interfacing with the buildpack or
-- return an error to the platform if it does not support `<buildpack API Version>`
+- MUST return an error to the platform if it does not support `<buildpack API Version>`
 
 The lifecycle MAY return an error to the platform if two or more buildpacks within a group declare buildpack API versions that the lifecycle cannot support together within a single build, even if both are supported independently.
 
@@ -117,58 +159,61 @@ The lifecycle MAY return an error to the platform if two or more buildpacks with
 
 ### Detection
 
-Executable: `/bin/detect <platform[AR]> <plan[E]>`, Working Dir: `<app[AR]>`
+Executable: `/bin/detect`, Working Dir: `<app[AR]>`
 
-| Input             | Description
-|-------------------|----------------------------------------------
-| `$0`              | Absolute path of `/bin/detect` executable
-| `<platform>/env/` | User-provided environment variables for build
-| `<platform>/#`    | Platform-specific extensions
-
-| Output             | Description
-|--------------------|----------------------------------------------
-| [exit status]      | Pass (0), fail (100), or error (1-99, 101+)
-| Standard output    | Logs (info)
-| Standard error     | Logs (warnings, errors)
-| `<plan>`           | Contributions to the the Build Plan (TOML)
+| Input                    | Attributes | Description                                       |
+|--------------------------|------------|---------------------------------------------------|
+| `$0`                     |            | Absolute path of `/bin/detect` executable         |
+| `$CNB_BUILD_PLAN_PATH`   | E          | Absolute path of the build plan                   |
+| `$CNB_BUILDPACK_DIR`     | ER         | Absolute path of the buildpack root directory     |
+| `$CNB_PLATFORM_DIR`      | AR         | Absolute path of the platform directory           |
+| `$CNB_PLATFORM_DIR/env/` | AR         | User-provided environment variables for build     |
+| `$CNB_PLATFORM_DIR/#`    | AR         | Platform-specific extensions                      |
 
+| Output                 | Description                                 |
+|------------------------|---------------------------------------------|
+| [exit status]          | Pass (0), fail (100), or error (1-99, 101+) |
+| Standard output        | Logs (info)                                 |
+| Standard error         | Logs (warnings, errors)                     |
+| `$CNB_BUILD_PLAN_PATH` | Contributions to the the Build Plan (TOML)  |
 
 ###  Build
 
-Executable: `/bin/build <layers[EIC]> <platform[AR]> <plan[ER]>`, Working Dir: `<app[AI]>`
+Executable: `/bin/build`, Working Dir: `<app[AI]>`
 
-| Input             | Description
-|-------------------|----------------------------------------------
-| `$0`              | Absolute path of `/bin/build` executable
-| `<plan>`          | Relevant [Buildpack Plan entries](#buildpack-plan-toml) from detection (TOML)
-| `<platform>/env/` | User-provided environment variables for build
-| `<platform>/#`    | Platform-specific extensions
+| Input                    | Attributes | Description                                                                   |
+|--------------------------|------------|-------------------------------------------------------------------------------|
+| `$0`                     |            | Absolute path of `/bin/build` executable                                      |
+| `$CNB_LAYERS_DIR`        | EIC        | Absolute path of the buildpack layers directory                               |
+| `$CNB_BP_PLAN_PATH`      | ER         | Relevant [Buildpack Plan entries](#buildpack-plan-toml) from detection (TOML) |
+| `$CNB_BUILDPACK_DIR`     | ER         | Absolute path of the buildpack root directory                                 |
+| `$CNB_PLATFORM_DIR`      | AR         | Absolute path of the platform directory                                       |
+| `$CNB_PLATFORM_DIR/env/` | AR         | User-provided environment variables for build                                 |
+| `$CNB_PLATFORM_DIR/#`    | AR         | Platform-specific extensions                                                  |
 
-| Output                                   | Description
-|------------------------------------------|--------------------------------------
-| [exit status]                            | Success (0) or failure (1+)
-| Standard output                          | Logs (info)
-| Standard error                           | Logs (warnings, errors)
-| `<layers>/launch.toml`                   | App metadata (see [launch.toml](#launchtoml-toml))
-| `<layers>/launch.sbom.<ext>`             | Launch Software Bill of Materials (see [Software-Bill-of-Materials](#bill-of-materials))
-| `<layers>/build.toml`                    | Build metadata (see [build.toml](#buildtoml-toml))
-| `<layers>/build.sbom.<ext>`              | Build Software Bill of Materials (see [Software-Bill-of-Materials](#bill-of-materials))
-| `<layers>/store.toml`                    | Persistent metadata (see [store.toml](#storetoml-toml))
-| `<layers>/<layer>.toml`                  | Layer metadata (see [Layer Content Metadata](#layer-content-metadata-toml))
-| `<layers>/<layer>.sbom.<ext>`            | Layer Software Bill of Materials (see [Software-Bill-of-Materials](#bill-of-materials))
-| `<layers>/<layer>/bin/`                  | Binaries for launch and/or subsequent buildpacks
-| `<layers>/<layer>/lib/`                  | Shared libraries for launch and/or subsequent buildpacks
-| `<layers>/<layer>/profile.d/`            | Scripts sourced by Bash before launch
-| `<layers>/<layer>/profile.d/<process>/`  | Scripts sourced by Bash before launch for a particular process type
-| `<layers>/<layer>/exec.d/`               | Executables that provide env vars via the [Exec.d Interface](#execd) before launch
-| `<layers>/<layer>/exec.d/<process>/`     | Executables that provide env vars for a particular process type via the [Exec.d Interface](#execd) before launch
-| `<layers>/<layer>/include/`              | C/C++ headers for subsequent buildpacks
-| `<layers>/<layer>/pkgconfig/`            | Search path for pkg-config for subsequent buildpacks
-| `<layers>/<layer>/env/`                  | Env vars for launch and/or subsequent buildpacks
-| `<layers>/<layer>/env.launch/`           | Env vars for launch (after `env`, before `profile.d`)
-| `<layers>/<layer>/env.launch/<process>/` | Env vars for launch (after `env`, before `profile.d`) for the launched process
-| `<layers>/<layer>/env.build/`            | Env vars for subsequent buildpacks (after `env`)
-| `<layers>/<layer>/*`                     | Other content for launch and/or subsequent buildpacks
+| Output                                          | Description                                                                                                      |
+|-------------------------------------------------|------------------------------------------------------------------------------------------------------------------|
+| [exit status]                                   | Success (0) or failure (1+)                                                                                      |
+| Standard output                                 | Logs (info)                                                                                                      |
+| Standard error                                  | Logs (warnings, errors)                                                                                          |
+| `$CNB_LAYERS_DIR/launch.toml`                   | App metadata (see [launch.toml](#launchtoml-toml))                                                               |
+| `$CNB_LAYERS_DIR/launch.sbom.<ext>`             | Launch Software Bill of Materials (see [Software-Bill-of-Materials](#software-bill-of-materials))                |
+| `$CNB_LAYERS_DIR/build.toml`                    | Build metadata (see [build.toml](#buildtoml-toml))                                                               |
+| `$CNB_LAYERS_DIR/build.sbom.<ext>`              | Build Software Bill of Materials (see [Software-Bill-of-Materials](#software-bill-of-materials))                 |
+| `$CNB_LAYERS_DIR/store.toml`                    | Persistent metadata (see [store.toml](#storetoml-toml))                                                          |
+| `$CNB_LAYERS_DIR/<layer>.toml`                  | Layer metadata (see [Layer Content Metadata](#layer-content-metadata-toml))                                      |
+| `$CNB_LAYERS_DIR/<layer>.sbom.<ext>`            | Layer Software Bill of Materials (see [Software-Bill-of-Materials](#software-bill-of-materials))                 |
+| `$CNB_LAYERS_DIR/<layer>/bin/`                  | Binaries for launch and/or subsequent buildpacks                                                                 |
+| `$CNB_LAYERS_DIR/<layer>/lib/`                  | Shared libraries for launch and/or subsequent buildpacks                                                         |
+| `$CNB_LAYERS_DIR/<layer>/exec.d/`               | Executables that provide env vars via the [Exec.d Interface](#execd) before launch                               |
+| `$CNB_LAYERS_DIR/<layer>/exec.d/<process>/`     | Executables that provide env vars for a particular process type via the [Exec.d Interface](#execd) before launch |
+| `$CNB_LAYERS_DIR/<layer>/include/`              | C/C++ headers for subsequent buildpacks                                                                          |
+| `$CNB_LAYERS_DIR/<layer>/pkgconfig/`            | Search path for pkg-config for subsequent buildpacks                                                             |
+| `$CNB_LAYERS_DIR/<layer>/env/`                  | Env vars for launch and/or subsequent buildpacks                                                                 |
+| `$CNB_LAYERS_DIR/<layer>/env.launch/`           | Env vars for launch (after `env`, before `exec.d`)                                                               |
+| `$CNB_LAYERS_DIR/<layer>/env.launch/<process>/` | Env vars for launch (after `env`, before `exec.d`) for the launched process                                      |
+| `$CNB_LAYERS_DIR/<layer>/env.build/`            | Env vars for subsequent buildpacks (after `env`)                                                                 |
+| `$CNB_LAYERS_DIR/<layer>/*`                     | Other content for launch and/or subsequent buildpacks                                                            |
 
 ### Exec.d
 
@@ -288,52 +333,49 @@ At the end of each individual buildpack's build phase:
 - The lifecycle:
   - MUST rename `<layers>/<layer>/` to `<layers>/<layer>.ignore/` for all layers where `launch = false`, `build = false`, and `cache = false`, in order to prevent subsequent buildpacks from accidentally depending on an ignored layer.
 
-## App Interface
-
-| Output                 | Description
-|------------------------|----------------------------------------------
-| `<app>/.profile`       | [†](README.md#linux-only) Bash-formatted script sourced by shell before launch
-| `<app>/.profile.bat`   | [‡](README.md#windows-only) BAT-formatted script sourced by shell before launch
-
 ## Phase #1: Detection
 
 ![Detection](img/detection.svg)
 
 ### Purpose
 
-The purpose of detection is to find an ordered group of buildpacks to use during the build phase.
+The purpose of detection is to find an ordered group of component buildpacks - and, optionally, image extensions - to use during the generation and build phases.
 These buildpacks must be compatible with the app.
 
+For detect requirements that are specific to image extensions, see the [Image Extension Interface](image-extension.md).
+
 ### Process
 
 **GIVEN:**
-- An ordered list of buildpack groups resolved into buildpack implementations as described in [Order Resolution](#order-resolution)
+- An ordered list of resolved groups as described in [Order Resolution](#order-resolution)
 - A directory containing application source code
-- A shell, if needed,
 
-For each buildpack in each group in order, the lifecycle MUST execute `/bin/detect`.
+For each image extension ("extension") or component buildpack ("buildpack") in each group in order, the lifecycle MUST execute `/bin/detect`. Image extensions MUST always be optional during detection.
 
-1. **If** the exit status of `/bin/detect` is non-zero and the buildpack is not marked optional, \
+1. **If** the exit status of a buildpack `/bin/detect` is non-zero and the buildpack is not marked optional, \
    **Then** the lifecycle MUST proceed to the next group or fail detection completely if no more groups are present.
 
-2. **If** the exit status of `/bin/detect` is zero or the buildpack is marked optional,
-   1. **If** the buildpack is not the last buildpack in the group, \
-      **Then** the lifecycle MUST proceed to the next buildpack in the group.
+2. **If** the exit status of `/bin/detect` is zero or the extension or buildpack is marked optional,
+   1. **If** the extension or buildpack is not the last in the group, \
+      **Then** the lifecycle MUST proceed to the next extension or buildpack in the group.
 
-   2. **If** the buildpack is the last buildpack in the group,
-      1. **If** no exit statuses from `/bin/detect` in the group are zero \
+   2. **If** the extension or buildpack is the last in the group,
+      1. **If** no exit statuses from buildpack `/bin/detect` in the group are zero \
          **Then** the lifecycle MUST proceed to the next group or fail detection completely if no more groups are present.
 
-      2. **If** at least one exit status from `/bin/detect` in the group is zero \
-         **Then** the lifecycle MUST select this group and proceed to the analysis phase.
+      2. **If** at least one exit status from a buildpack `/bin/detect` in the group is zero \
+         **Then** the lifecycle MUST select this group and MAY proceed to the generation phase.
 
-The selected group MUST be filtered to only include buildpacks with exit status zero.
-The order of the buildpacks in the group MUST otherwise be preserved.
+The selected group MUST be filtered to only include extensions and buildpacks with exit status zero.
+The order of the extensions and buildpacks in the group MUST otherwise be preserved.
 
-The `/bin/detect` executable in each buildpack, when executed:
+For each `/bin/detect` executable in each extension or buildpack, the lifecycle:
+
+- MUST configure the environment as described in the [Environment](#environment) section.
+
+The `/bin/detect` executable in each extension or buildpack, when executed:
 
 - MAY read the app directory.
-- MAY read the detect environment as described in the [Environment](#environment) section.
 - MAY emit error, warning, or debug messages to `stderr`.
 - MAY augment the Build Plan by writing TOML to `<plan>`.
 - MUST set an exit status code as described in the [Buildpack Interface](#buildpack-interface) section.
@@ -344,64 +386,58 @@ Each `requires` and `provides` section MUST be a list of entries formatted as de
 
 Each pairing of `requires` and `provides` sections (at the top level, or inside of an `or` array) is a potential Build Plan.
 
-For a given buildpack group, a sequence of trials is generated by selecting a single potential Build Plan from each buildpack in a left-to-right, depth-first order.
+For a given group, a sequence of trials is generated by selecting a single potential Build Plan from each extension or buildpack in a left-to-right, depth-first order.
 The group fails to detect if all trials fail to detect.
 
 For each trial,
 - If a required buildpack provides a dependency that is not required by the same buildpack or a subsequent buildpack, the trial MUST fail to detect.
 - If a required buildpack requires a dependency that is not provided by the same buildpack or a previous buildpack, the trial MUST fail to detect.
 - If an optional buildpack provides a dependency that is not required by the same buildpack or a subsequent buildpack, the optional buildpack MUST be excluded from the build phase and its requires and provides MUST be excluded from the Build Plan.
+- If an extension provides a dependency that is not required by a subsequent buildpack, the extension MUST be excluded from the build phase and its provides MUST be excluded from the Build Plan.
 - If an optional buildpack requires a dependency that is not provided by the same buildpack or a previous buildpack, the optional buildpack MUST be excluded from the build phase and its requires and provides MUST be excluded from the Build Plan.
 - Multiple buildpacks MAY require or provide the same dependency.
+- Multiple extensions MAY provide the same dependency.
 
 The lifecycle MAY execute each `/bin/detect` within a group in parallel.
 
-The lifecycle MUST run `/bin/detect` for all buildpacks in a group in a container using common stack with a common set of mixins.
-The lifecycle MUST fail detection if any of those buildpacks does not list that stack in `buildpack.toml`.
-The lifecycle MUST fail detection if any of those buildpacks specifies a mixin associated with that stack in `buildpack.toml` that is not satisfied, see [Mixin Satisfaction](#mixin-satisfaction) below.
-
-#### Mixin Satisfaction
-A buildpack's mixin requirements must be satisfied by the stack in one of the following scenarios.
-
-1) the stack provides the mixin `run:<mixin>` and the buildpack requires `run:<mixin>`
-2) the stack provides the mixin `build:<mixin>` and the buildpack requires `build:<mixin>`
-3) the stack provides the mixin `<mixin>` and the buildpack requires `<mixin>`
-4) the stack provides the mixin `<mixin>` and the buildpack requires `build:<mixin>`
-5) the stack provides the mixin `<mixin>` and the buildpack requires `run:<mixin>`
-6) the stack provides the mixin `<mixin>` and the buildpack requires both `run:<mixin>` and `build:<mixin>`
-7) the stack provides the mixins `build:<mixin>` and `run:<mixin>` the buildpack requires `<mixin>`
+The lifecycle MUST run `/bin/detect` for all extensions and buildpacks in a group in a container using a common build environment.
+If any non-optional buildpack in a group fails to declare a target in `buildpack.toml` matching the build-time and runtime base images, and in the case that no targets are declared and the [inferred target](#targets-1) does not match, the lifecycle MUST fail detection for the group. For matching criteria, see [buildpack.toml](#buildpacktoml-toml).
 
 #### Order Resolution
 
-During detection, an order definition MUST be resolved into individual buildpack implementations.
+During detection, an order definition for image extensions (if present) and an order definition for buildpacks MUST be resolved into a group of image extensions and a group of component buildpacks.
+
+Order definitions for image extensions MUST NOT contain nested orders.
+
+If an order definition for image extensions is present, it MUST be prepended to the order definition for buildpacks before the resolution process occurs.
 
 The resolution process MUST follow this pattern:
 
 Where:
-- O and P are buildpack orders.
-- A through H are buildpack implementations.
+- O and P are orders for image extensions or buildpacks.
+- A through H are image extensions or component buildpacks.
 
 Given:
 
-<img src="http://tex.s2cms.ru/svg/%0AO%20%3D%0A%5Cbegin%7Bbmatrix%7D%0AA%2C%20%26%20B%20%5C%5C%0AC%2C%20%26%20D%0A%5Cend%7Bbmatrix%7D%0A" alt="
-O =
+![
+  O =
 \begin{bmatrix}
 A, &amp; B \\
 C, &amp; D
 \end{bmatrix}
-" />
+](img/matrix1.svg)
 
-<img src="http://tex.s2cms.ru/svg/%0AP%20%3D%0A%5Cbegin%7Bbmatrix%7D%0AE%2C%20%26%20F%20%5C%5C%0AG%2C%20%26%20H%0A%5Cend%7Bbmatrix%7D%0A" alt="
+![
 P =
 \begin{bmatrix}
 E, &amp; F \\
 G, &amp; H
 \end{bmatrix}
-" />
+"](img/matrix2.svg)
 
 It MUST follow that:
 
-<img src="http://tex.s2cms.ru/svg/%0A%5Cbegin%7Bbmatrix%7D%0AE%2C%20%26%20O%2C%20%26%20F%0A%5Cend%7Bbmatrix%7D%20%3D%20%0A%5Cbegin%7Bbmatrix%7D%0AE%2C%20%26%20A%2C%20%26%20B%2C%20%26%20F%20%5C%5C%0AE%2C%20%26%20C%2C%20%26%20D%2C%20%26%20F%20%5C%5C%0A%5Cend%7Bbmatrix%7D%0A" alt="
+![
 \begin{bmatrix}
 E, &amp; O, &amp; F
 \end{bmatrix} =
@@ -409,9 +445,9 @@ E, &amp; O, &amp; F
 E, &amp; A, &amp; B, &amp; F \\
 E, &amp; C, &amp; D, &amp; F \\
 \end{bmatrix}
-" />
+](img/matrix3.svg)
 
-<img src="http://tex.s2cms.ru/svg/%0A%5Cbegin%7Bbmatrix%7D%0AO%2C%20%26%20P%0A%5Cend%7Bbmatrix%7D%20%3D%20%0A%5Cbegin%7Bbmatrix%7D%0AA%2C%20%26%20B%2C%20%26%20E%2C%20%26%20F%20%5C%5C%0AA%2C%20%26%20B%2C%20%26%20G%2C%20%26%20H%20%5C%5C%0AC%2C%20%26%20D%2C%20%26%20E%2C%20%26%20F%20%5C%5C%0AC%2C%20%26%20D%2C%20%26%20G%2C%20%26%20H%20%5C%5C%0A%5Cend%7Bbmatrix%7D%0A" alt="
+![
 \begin{bmatrix}
 O, &amp; P
 \end{bmatrix} =
@@ -421,7 +457,7 @@ A, &amp; B, &amp; G, &amp; H \\
 C, &amp; D, &amp; E, &amp; F \\
 C, &amp; D, &amp; G, &amp; H \\
 \end{bmatrix}
-" />
+](img/matrix4.svg)
 
 Note that buildpack IDs are expanded depth-first in left-to-right order.
 
@@ -433,7 +469,7 @@ If a buildpack order entry within a group has the parameter `optional = true`, t
 
 ### Purpose
 
-The purpose of analysis is to restore `<layers>/<layer>.toml`, `<layers>/<layer>.sbom.<ext>`, and `<layers>/store.toml` files that buildpacks may use to optimize the build and export phases.
+The purpose of analysis is to restore `<layers>/<layer>.toml`, `<layers>/<layer>.sbom.<ext>`, and `<layers>/store.toml` files that component buildpacks may use to optimize the build and export phases.
 
 ### Process
 
@@ -456,15 +492,31 @@ For each buildpack in the group, the lifecycle
 
 After analysis, the lifecycle MUST proceed to the build phase.
 
-## Phase #3: Build
+## Phase #3: Generation (image extensions only)
+
+### Purpose
+
+The purpose of the generation phase is to generate Dockerfiles that can be used to define the build and/or runtime base image. The generation phase MUST NOT be run for Windows builds.
+
+### Process
+
+See the [Image Extension Specification](#image_extension.md).
+
+## Phase #4: Extension (image extensions only)
+
+### Purpose
+
+The purpose of the extension phase is to apply the Dockerfiles generated in the generation phase to the appropriate base image. The extension phase MUST NOT be run for Windows builds.
+
+## Phase #5: Build (component buildpacks only)
 
 ![Build](img/build.svg)
 
 ### Purpose
 
-The purpose of build is to transform application source code into runnable artifacts that can be packaged into a container.
+The purpose of build is to transform application source code into runnable artifacts that can be packaged into a container image.
 
-During the build phase, typical buildpacks might:
+During the build phase, typical component buildpacks might:
 
 1. Read the Buildpack Plan in `<plan>` to determine what dependencies to provide.
 1. Provide the application with dependencies for launch in `<layers>/<layer>`.
@@ -496,9 +548,8 @@ This is achieved by:
 - The final ordered group of buildpacks determined during the detection phase,
 - A directory containing application source code,
 - The Buildpack Plan,
-- Any `<layers>/<layer>.toml` files placed on the filesystem during the analysis phase,
-- Any locally cached `<layers>/<layer>` directories, and
-- A shell, if needed,
+- Any `<layers>/<layer>.toml` files placed on the filesystem during the analysis phase, and
+- Any locally cached `<layers>/<layer>` directories,
 
 For each buildpack in the group in order, the lifecycle MUST execute `/bin/build`.
 
@@ -544,14 +595,16 @@ Correspondingly, each `/bin/build` executable:
 
 #### Unmet Buildpack Plan Entries
 
-A buildpack SHOULD designate a Buildpack Plan entry as unmet if the buildpack did not satisfy the requirement described by the entry.
+A component buildpack SHOULD designate a Buildpack Plan entry as unmet if it did not satisfy the requirement described by the entry.
 The lifecycle SHALL assume that all entries in the Buildpack Plan were satisfied by the buildpack unless the buildpack writes an entry with the given name to the `unmet` section of `build.toml`.
 
+Image extensions MUST satisfy all entries in the Buildpack Plan.
+
 For each entry in `<plan>`:
   - **If** there is an unmet entry in `build.toml` with a matching `name`, the lifecycle
-    - MUST include the entry in the `<plan>` of the next buildpack that provided an entry with that name during the detection phase.
+    - MUST include the entry in the `<plan>` of the next component buildpack that provided an entry with that name during the detection phase.
   - **Else**, the lifecycle
-    - MUST NOT include entries with matching names in the `<plan>` provided to subsequent buildpacks.
+    - MUST NOT include entries with matching names in the `<plan>` provided to subsequent image extensions or component buildpacks.
 
 #### Software-Bill-of-Materials
 
@@ -607,7 +660,7 @@ Additionally, a buildpack MAY specify sub-paths within `<app>` as `slices` in `l
 Separate layers MUST be created during the export phase for each slice with one or more files or directories.
 This minimizes data transfer when the app directory contains a known set of files.
 
-## Phase #4: Export
+## Phase #6: Export
 
 ![Export](img/export.svg)
 
@@ -621,7 +674,7 @@ The purpose of export is to create a new OCI image using a combination of remote
 - The `<layers>` directories provided to each buildpack during the build phase,
 - The `<app>` directory processed by the buildpacks during the build phase,
 - The buildpack IDs associated with the buildpacks used during the build phase, in order of execution,
-- A reference to the most recent version of the run image associated with the stack and mixins,
+- A reference to the most recent version of the run image,
 - A reference to the old OCI image processed during the analysis phase, if available, and
 - A tag for a new OCI image,
 
@@ -679,80 +732,36 @@ The purpose of launch is to modify the running app environment using app-provide
 
 **GIVEN:**
 - An OCI image exported by the lifecycle,
-- A shell, if needed,
-
-First, the lifecycle MUST locate a start command and choose an execution strategy.
-
-To locate a start command, the lifecycle MUST follow the process outlined in the [Platform Interface Specification](platform.md).
-
-To choose an execution strategy,
-
-1. **If** a buildpack-provided process type is chosen as the start command,
-   1. **If** the process type has `direct` set to `false`,
-      1. **If** the process has one or more `args`
-         **Then** the lifecycle MUST invoke a command using the shell, where `command` and each entry in `args` are shell-parsed tokens in the command.
-      2. **If** the process has zero `args`
-         **Then** the lifecycle MUST invoke the value of `command` as a command using the shell.
-
-   2. **If** the process type does have `direct` set to `true`,
-      **Then** the lifecycle MUST invoke the value of `command` using the `execve` syscall with values of `args` provided as arguments.
-
-2. **If** a user-defined process type is chosen as the start command,
-   **Then** the lifecycle MUST select an execution strategy as described in the [Platform Interface Specification](platform.md).
-
-Given the start command and execution strategy,
 
 1. The lifecycle MUST set all buildpack-provided launch environment variables as described in the [Environment](#environment) section.
 
-2. The lifecycle MUST
-   1. [execute](#execd) each file in each `<layers>/<layer>/exec.d` directory in the launch environment and set the [returned variables](#execd-output-toml) in the launch environment before continuing,
-      1. Firstly, in order of `/bin/build` execution used to construct the OCI image.
-      2. Secondly, in alphabetically ascending order by layer directory name.
-      3. Thirdly, in alphabetically ascending order by file name.
-   2. [execute](#execd) each file in each `<layers>/<layer>/exec.d/<process>` directory in the launch environment and set the [returned variables](#execd-output-toml) in the launch environment before continuing,
-      1. Firstly, in order of `/bin/build` execution used to construct the OCI image.
-      2. Secondly, in alphabetically ascending order by layer directory name.
-      3. Thirdly, in alphabetically ascending order by file name.
+1. The lifecycle MUST
+   1. [execute](#execd) each file in each `<layers>/<layer>/exec.d` as described in the [Platform Interface Specification](platform.md).
+   1. [execute](#execd) each file in each `<layers>/<layer>/exec.d/<process>` as described in the [Platform Interface Specification](platform.md).
 
-3. If using an execution strategy involving a shell, the lifecycle MUST use a single shell process to
-   1. source each file in each `<layers>/<layer>/profile.d` directory,
-      1. Firstly, in order of `/bin/build` execution used to construct the OCI image.
-      2. Secondly, in alphabetically ascending order by layer directory name.
-      3. Thirdly, in alphabetically ascending order by file name.
-   2. source each file in each `<layers>/<layer>/profile.d/<process>` directory,
-      1. Firstly, in order of `/bin/build` execution used to construct the OCI image.
-      2. Secondly, in alphabetically ascending order by layer directory name.
-      3. Thirdly, in alphabetically ascending order by file name.
-   3. source [†](README.md#linux-only)`<app>/.profile` or [‡](README.md#windows-only)`<app>/.profile.bat` if it is present.
+1. The lifecycle MUST invoke the command with its arguments, environment, and working directory following the process outlined in the [Platform Interface Specification](platform.md).
 
-
-3. If using an execution strategy involving a shell, the lifecycle MUST source [†](README.md#linux-only)`<app>/.profile` or [‡](README.md#windows-only)`<app>/.profile.bat` if it is present.
-
-4. The lifecycle MUST invoke the start command with the decided execution strategy.
-
-[†](README.md#linux-only)When executing a process using any execution strategy, the lifecycle SHOULD replace the lifecycle process in memory without forking it.
-
-[†](README.md#linux-only)When executing a process with Bash, the lifecycle SHOULD additionally replace the Bash process in memory without forking it.
-
-[‡](README.md#windows-only)When executing a process with Command Prompt, the lifecycle SHOULD start a new process with the same security context, terminal, working directory, STDIN/STDOUT/STDERR handles and environment variables as the Command Prompt process.
+[†](README.md#linux-only)When executing a process, the lifecycle SHOULD replace the lifecycle process in memory without forking it.
 
 ## Environment
 
 ### Provided by the Lifecycle
 
-#### Buildpack Specific Variables
+#### Targets
 
-The following environment variables MUST be set by the lifecycle in each buildpack's execution environment.
+The following environment variables MUST be set by the lifecycle during the `detect` and `build` phases to describe the target runtime image, if inputs are provided.
 
-These variables MAY differ between buildpacks.
-
-| Env Variable        | Description                          | Detect | Build | Launch
-|---------------------|--------------------------------------|--------|-------|--------
-| `CNB_BUILDPACK_DIR` | The root of the buildpack source     | [x]    | [x]   |
+| Env Variable                | Description                                |
+|-----------------------------|--------------------------------------------|
+| `CNB_TARGET_OS`             | Target OS                                  |
+| `CNB_TARGET_ARCH`           | Target architecture                        |
+| `CNB_TARGET_ARCH_VARIANT`   | Target architecture variant (optional)     |
+| `CNB_TARGET_DISTRO_NAME`    | Target OS distribution name (optional)     |
+| `CNB_TARGET_DISTRO_VERSION` | Target OS distribution version (optional)  |
 
 #### Layer Paths
 
-The following layer path environment variables MUST be set by the lifecycle during the build and launch phases in order to make buildpack dependencies accessible.
+The following layer path environment variables MUST be set by the lifecycle during the `build` and `launch` phases in order to make buildpack dependencies accessible.
 
 During the build phase, each variable designated for build MUST contain absolute paths of all previous buildpacks’ `<layers>/<layer>/` directories that are designated for build.
 
@@ -772,19 +781,18 @@ In either case,
 | `CPATH`                                    | `/include`   | header files     | [x]   |        |
 | `PKG_CONFIG_PATH`                          | `/pkgconfig` | pc files         | [x]   |        |
 
-
 ### Provided by the Platform
 
 The following additional environment variables MUST NOT be overridden by the lifecycle.
 
-| Env Variable    | Description                                    | Detect | Build | Launch
-|-----------------|------------------------------------------------|--------|-------|--------
-| `CNB_STACK_ID`  | Chosen stack ID                                | [x]    | [x]   |
-| `BP_*`          | User-provided variable for buildpack           | [x]    | [x]   |
-| `BPL_*`         | User-provided variable for profile.d or exec.d |        |       | [x]
-| `HOME`          | Current user's home directory                  | [x]    | [x]   | [x]
+| Env Variable           | Description                                       | Detect | Build | Launch |
+|------------------------|---------------------------------------------------|--------|-------|--------|
+| `BP_*`                 | User-provided variable for buildpack              | [x]    | [x]   |        |
+| `BPL_*`                | User-provided variable for exec.d                 |        |       | [x]    |
+| `HOME`                 | Current user's home directory                     | [x]    | [x]   | [x]    |
 
-During the detection and build phases, the lifecycle MUST provide any user-provided environment variables as files in `<platform>/env/` with file names and contents matching the environment variable names and contents.
+During the detection and build phases, the lifecycle MUST provide as environment variables any user-provided files in `<platform>/env/` with environment variable names and contents matching the file names and contents.
+During the detection and build phases, the lifecycle MUST provide as environment variables any operator-provided files in `<build-config>/env` with environment variable names and contents matching the file names and contents. This applies for all values of `clear-env` or if `clear-env` is undefined in `buildpack.toml`.
 
 When `clear-env` in `buildpack.toml` is set to `true` for a given buildpack, the lifecycle MUST NOT set user-provided environment variables in the environment of `/bin/detect` or `/bin/build`.
 
@@ -792,8 +800,6 @@ When `clear-env` in `buildpack.toml` is not set to `true` for a given buildpack,
 1. For layer path environment variables, user-provided values are prepended before any existing values and are delimited by the OS path list separator.
 2. For all other environment variables, user-provided values override any existing values.
 
-Buildpacks MAY use the value of `CNB_STACK_ID` to modify their behavior when executed on different stacks.
-
 The environment variable prefix `CNB_` is reserved.
 It MUST NOT be used for environment variables that are not defined in this specification or approved extensions.
 
@@ -883,7 +889,7 @@ Prohibited:
 
 ### Requirements
 
-The lifecycle MUST be implemented so that the detection and build phases do not have access to OCI image store credentials used in the analysis and export phases.
+The lifecycle MUST be implemented so that the detection, generation, extension, and build phases do not have access to OCI image store credentials used in the analysis and export phases.
 The lifecycle SHOULD be implemented so that each phase may run in a different container.
 
 ## Data Format
@@ -897,16 +903,16 @@ value = "<label valu>"
 
 [[processes]]
 type = "<process type>"
-command = "<command>"
+command = ["<command>"]
 args = ["<arguments>"]
-direct = false
 default = false
+working-dir = "<working directory>"
 
 [[slices]]
 paths = ["<app sub-path glob>"]
 ```
 
-The buildpack MAY specify any number of labels, processes, or slices.
+The component buildpack MAY specify any number of labels, processes, or slices.
 
 For each label, the buildpack:
 
@@ -919,15 +925,19 @@ If multiple buildpacks define labels with the same key, the lifecycle MUST use t
 
 For each process, the buildpack:
 
-- MUST specify a `type`, which:
+- MUST specify a `type`, an identifier for the process, which:
   - MUST NOT be identical to other process types provided by the same buildpack.
   - MUST only contain numbers, letters, and the characters ., _, and -.
-- MUST specify a `command` that is either:
-  - A command sequence that is valid when executed using the shell, if `args` is not specified.
-  - A path to an executable or the file name of an executable in `$PATH`, if `args` is a list with zero or more elements.
-- MAY specify an `args` list to be passed directly to the specified executable.
-- MAY specify a `direct` boolean that bypasses the shell.
+- MUST specify a `command` list such that:
+  - The first element of `command` is a path to an executable or the file name of an executable in `$PATH`.
+  - Any remaining elements of `command` are arguments that are always passed directly to the executable [^command-args].
+- MAY specify an `args` list to be passed directly to the specified executable, after arguments specified in `command`.
+  - The `args` list is a default list of arguments that may be overridden by the user [^command-args].
 - MAY specify a `default` boolean that indicates that the process type should be selected as the [buildpack-provided default](https://github.com/buildpacks/spec/blob/main/platform.md#outputs-4) during the export phase.
+- MAY specify a `working-dir` for the process. The `working-dir` defaults to the application directory if not specified.
+
+[^command-args]: For versions of the Platform API that do not support overridable arguments, the arguments in `command` and `args` are always applied together with any user-provided arguments.
+In general, the [Platform Interface Specification](platform.md) is ultimately responsible for launching processes; consult that specification for details.
 
 An individual buildpack may only specify one process type with `default = true`. The lifecycle MUST select, from all buildpack-provided process types, the last process type with `default = true` as the buildpack-provided default. If multiple buildpacks define processes of the same type, the lifecycle MUST use the last process type definition ordered by buildpack execution for the combined process list (a non-default process type definition may override a default process type definition, leaving the app image with no default).
 
@@ -954,7 +964,7 @@ The lifecycle MUST include all unmatched files in the app directory in any numbe
 name = "<dependency name>"
 ```
 
-For each unmet entry in the Buildpack Plan, the buildpack:
+For each unmet entry in the Buildpack Plan, the component buildpack:
 - SHOULD add an entry to `unmet`.
 
 For each entry in `unmet`:
@@ -1019,7 +1029,6 @@ For a given layer, the buildpack MAY specify:
 - Whether the layer is cached, intended for build, and/or intended for launch.
 - Metadata that describes the layer contents.
 
-
 ### buildpack.toml (TOML)
 This section describes the 'Buildpack descriptor'.
 
@@ -1046,9 +1055,13 @@ id = "<buildpack ID>"
 version = "<buildpack version>"
 optional = false
 
-[[stacks]]
-id = "<stack ID>"
-mixins = ["<mixin name>"]
+[[targets]]
+os = "<OS name>"
+arch = "<architecture>"
+variant = "<architecture variant>"
+[[targets.distros]]
+name = "<OS distribution name>"
+version = "<OS distribution version>"
 
 [metadata]
 # buildpack-specific data
@@ -1060,7 +1073,7 @@ Buildpack authors MUST choose a globally unique ID, for example: "io.buildpacks.
 
 *Key: `id = "<buildpack ID>"`*
 - MUST only contain numbers, letters, and the characters `.`, `/`, and `-`.
-- MUST NOT be `config` or `app`.
+- MUST NOT be `app`, `config`, `generated`, or `sbom`.
 - MUST NOT be identical to any other buildpack ID when using a case-insensitive comparison.
 
 **The buildpack version:**
@@ -1068,8 +1081,6 @@ Buildpack authors MUST choose a globally unique ID, for example: "io.buildpacks.
    - Each element MUST increase numerically.
    - Buildpack authors will define what changes will increment `X`, `Y`, and `Z`.
 
-If an `order` is specified, then `stacks` MUST NOT be specified.
-
 **The buildpack API:**
 
 *Key: `api = "<buildpack API version>"`*
@@ -1089,23 +1100,28 @@ The `[[buildpack.licenses]]` table is optional and MAY contain a list of buildpa
 *Key: `sbom-formats = [ "<string>" ]`*
  - MUST be supported SBOM media types as described in [Software-Bill-of-Materials](#software-bill-of-materials).
 
-#### Buildpack Implementations
+#### Targets
 
-A buildpack descriptor that specifies `stacks` MUST describe a buildpack that implements the [Buildpack Interface](#buildpack-interface).
+A buildpack descriptor SHOULD specify `targets`.
 
-Each stack in `stacks` either:
-- MUST identify a compatible stack:
-   - `id` MUST be set to a [valid stack ID](https://github.com/buildpacks/spec/blob/main/platform.md#stack-id).
-   - `mixins` MAY contain one or more mixin names.
-- Or MUST indicate compatibility with any stack:
-   - `id` MUST be set to the special value `"*"`.
-   - `mixins` MUST be empty.
+Each target in `targets`:
+- MUST identify a compatible runtime environment:
+   - `os`, `arch`, and `variant` if provided MUST be valid identifiers as defined in the [OCI Image Specification](https://github.com/opencontainers/image-spec/blob/main/config.md)
+   - `distros` if provided MUST describe the OS distributions supported by the buildpack
+     - For Linux-based images, `distros.name` and `distros.version` SHOULD contain the values specified in `/etc/os-release` (`$ID` and `$VERSION_ID`), as the `os.version` field in an image config may contain combined distribution and version information
+     - For Windows-based images, `distros.name` SHOULD be empty; `distros.version` SHOULD contain the value of `os.version` in the image config (e.g., `10.0.14393.1066`)
+   - Any field not provided will be interpreted as `<matches any>`
 
-#### Order Buildpacks
+If the `targets` list is empty, tools reading `buildpack.toml` will assume:
+  - `os = "linux"` and `arch = <matches any>` if `./bin/build` is present
+  - `os = "windows"` and `arch = <matches any>` if `./bin/build.bat` or `./bin/build.exe` are present
 
-A buildpack descriptor that specifies `order` MUST be [resolvable](#order-resolution) into an ordering of buildpacks that implement the [Buildpack Interface](#buildpack-interface).
+Metadata specified in `[[targets]]` is validated against the runtime and build-time base images.
+* A buildpack target satisfies a base image target when `os`, `arch`, and `variant` match and at least one distribution in `distros` (if provided) matches
+   
+#### Order
 
-A buildpack reference inside of a `group` MUST contain an `id` and `version`.
+A buildpack reference inside of a `group` MUST contain an `id` and `version`. The `order` MUST include only buildpacks and MUST NOT include image extensions.
 
 ### Exec.d Output (TOML)
 ```
@@ -1124,46 +1140,105 @@ Each `key`:
 ## Deprecations
 This section describes all the features that are deprecated.
 
-### `0.3`
+### buildpack.toml (TOML) `stacks` Array
 
-#### Build Plan (TOML) `requires.version` Key
+_Deprecated in Buildpack API 0.10._
 
-The `requires.version` and `or.requires.version` keys are deprecated.
+The `stacks` array is deprecated.
 
 ```toml
-[[requires]]
-name = "<dependency name>"
-version = "<dependency version>"
-
-[[or.requires]]
-name = "<dependency name>"
-version = "dependency version>"
+[[stacks]]
+id = "<stack ID>"
+mixins = ["<mixin name>"]
 ```
 
-To upgrade, buildpack authors SHOULD set `requires.version` as `requires.metadata.version` and `or.requires.version` as `or.requires.metadata.version`.
+Each stack in `stacks` either:
+- MUST identify a compatible stack:
+    - `id` MUST be set to a [valid stack ID](https://github.com/buildpacks/spec/blob/main/platform.md#stack-id).
+    - `mixins` MAY contain one or more mixin names.
+- Or MUST indicate compatibility with any stack:
+    - `id` MUST be set to the special value `"*"`.
+    - `mixins` MUST be empty.
+
+If an `order` is specified, then `stacks` MUST NOT be specified.
+
+Tools reading `buildpack.toml` will translate any section that sets `stacks.id = "io.buildpacks.stacks.bionic"` to:
 
 ```toml
-[[requires]]
-name = "<dependency name>"
-
-[requires.metadata]
-version = "<dependency version>"
-
-[[or.requires]]
-name = "<dependency name>"
-
-[or.requires.metadata]
-version = "<dependency version>"
+[[targets]]
+os = "linux"
+arch = "amd64"
+[[targets.distros]]
+name = "ubuntu"
+version = "18.04"
 ```
 
-If `requires.version` and `requires.metadata.version` or `or.requires.version` and `or.requires.metadata.version` are both defined then lifecycle will fail.
+Furthermore, any buildpack that contains `[[stacks]]` with `id = "*"` will match any target.
 
-For backwards compatibility, the lifecycle will produce a Buildpack Plan (TOML) that puts `version` in `entries.metadata` as long as `version` does not exist in `requires.metadata`.
+### Positional Arguments to `detect` and `build` Executables
+
+_Deprecated in Buildpack API 0.8._
+
+The positional arguments to the `detect` and `build` executables are deprecated.
+The lifecycle provides these values as environment variables.
+
+To upgrade, buildpack authors SHOULD use the following environment variables:
+
+For `detect`:
+
+- `CNB_PLATFORM_DIR` replaces the first positional argument.
+- `CNB_BUILD_PLAN_PATH` replaces the second positional argument.
+
+For `build`:
+
+* `CNB_LAYERS_DIR` replaces the first positional argument.
+* `CNB_PLATFORM_DIR` replaces the second positional argument.
+* `CNB_BP_PLAN_PATH` replaces the third positional argument.
+
+### launch.toml (TOML) `bom` Array
+
+_Deprecated in Buildpack API 0.7._
+
+The `bom` array is deprecated.
 
 ```toml
-[[entries]]
+[[bom]]
 name = "<dependency name>"
 
-[entries.metadata]
-version = "<dependency version>"
+[bom.metadata]
+# arbitrary metadata describing the dependency
 ```
+
+If the `bom` array is used, the buildpack:
+- SHOULD add a bill-of-materials entry to the `bom` array describing each dependency contributed to the app image, where:
+  - `name` is REQUIRED.
+  - `metadata` MAY contain additional data describing the dependency.
+
+The buildpack MAY add `bom` describing the contents of the app dir, even if they were not contributed by the buildpack.
+
+When the build is complete, a legacy Bill of Materials (BOM) describing the app image MAY be generated for auditing purposes.
+
+If generated, this legacy BOM MUST contain all `bom` entries in each `launch.toml` at the end of each `/bin/build` execution, in adherence with the process and data format outlined in the [Platform Interface Specification](platform.md) for legacy BOM formats.
+
+### build.toml (TOML) `bom` Array
+
+_Deprecated in Buildpack API 0.7._
+
+The `bom` array is deprecated.
+
+```toml
+[[bom]]
+name = "<dependency name>"
+
+[bom.metadata]
+# arbitrary metadata describing the dependency
+```
+
+If the `bom` array is used, the buildpack:
+- SHOULD add a bill-of-materials entry to the `bom` array describing each dependency contributed to the build environment, where:
+  - `name` is REQUIRED.
+  - `metadata` MAY contain additional data describing the dependency.
+
+When the build is complete, a legacy build BOM describing the build container MAY be generated for auditing purposes.
+
+If generated, this legacy build BOM MUST contain all `bom` entries in each `build.toml` at the end of each `/bin/build` execution, in adherence with the process and data format outlined in the [Platform Interface Specification](platform.md) for legacy BOM formats.

extensions/bindings.md

@@ -1,109 +1,3 @@
-# Bindings
+# Bindings (DEPRECATED)
 
-Bindings are exposed inside of a container during the detect, build, and launch phases of the lifecycle.  The contents of bindings MUST NOT be part of the image created after the detect and build phases.
-
-## Table of Contents
-
-<!-- Using https://github.com/yzhang-gh/vscode-markdown to manage toc -->
-- [Bindings](#bindings)
-  - [Table of Contents](#table-of-contents)
-  - [Detect and Build Phases](#detect-and-build-phases)
-    - [Metadata](#metadata)
-    - [Secret](#secret)
-    - [Example Directory Structure](#example-directory-structure)
-  - [Launch Phase](#launch-phase)
-    - [Metadata](#metadata-1)
-    - [Secret](#secret-1)
-    - [Example Directory Structure](#example-directory-structure-1)
-
-## Detect and Build Phases
-Before initiating the detect or build phases on the build-image, the platform MUST provide any bindings as files in `<platform>/bindings/<binding-name>` with directory names matching the name of the binding.  Binding names MUST match `[a-z0-9\-\.]{1,253}`.
-
-### Metadata
-Within each binding directory the platform MUST provide a `metadata` directory containing `kind` and `provider` files.  The value of the `kind` file MUST contain an abstract classification of the binding.  The value of the `provider` file MUST identify the provider of this binding.
-
-In addition to the required files, the `metadata` directory MAY contain additional metadata about the binding with file names and contents matching the metadata names and contents.
-
-The collection of files within the directory MAY change between detect and build phase pairs.  The collection of files within the directory MUST NOT change during the detect and build phase pair.
-
-The contents of the files MAY change between detect and build phase pairs.  The contents of the files MUST NOT change during the detect and build phase pair.
-
-### Secret
-Within each binding directory the platform MAY provide a `secret` directory containing the secret associated with the binding with filenames matching the secret key names.
-
-During the detect and build phases, if the `secret` directory exists, the contents of the files MAY be one of the following:
-
-* the values of the secret keys
-* an indirect pointer to another system for value resolution
-
-If the `secret` directory exists, the collection of files within the directory MAY change between detect and build phase pairs.  The collection of files within the directory MUST NOT change during the detect and build phase pair.
-
-If the `secret` directory exists, the contents of the files MAY change between detect and build phase pairs.  The contents of the files MUST NOT change during the detect and build phase pair.
-
-
-### Example Directory Structure
-```plain
-<platform>
-└── bindings
-    ├── primary-db
-    │   └── metadata
-    │       ├── connection-count
-    │       ├── kind
-    │       └── provider
-    └── secondary-db
-        ├── metadata
-        │   ├── connection-count
-        │   ├── kind
-        │   └── provider
-        └── secret
-            ├── endpoint
-            ├── password
-            └── username
-```
-
-## Launch Phase
-During the launch phase, the platform MUST provide any bindings as files in `$CNB_BINDINGS/<binding-name>` with directory names matching the name of the binding.  Binding names MUST match `[a-z0-9\-\.]{1,253}`.  The `CNB_BINDINGS` environment variable MUST be declared and can point to any valid filesystem location.
-
-### Metadata
-Within each binding directory the platform MUST provide a `metadata` directory containing `kind` and `provider` files.  The value of the `kind` file MUST contain an abstract classification of the binding.  The value of the `provider` file MUST identify the provider of this binding.
-
-In addition to the required files, the `metadata` directory MAY contain additional metadata about the binding with file names and contents matching the metadata names and contents.
-
-The collection of files within the directory MAY change between launches.  The collection of files within the directory MUST NOT change during the launch phase.
-
-The contents of the files MAY change between launches.  The contents of the files MAY change during the launch phase.
-
-### Secret
-Within each binding directory the platform MUST provide a `secret` directory containing the secret associated with the binding with filenames matching the secret key names.
-
-During the launch phase, the contents of the files MAY be one of the following:
-
-* the values of the secret keys
-* an indirect pointer to another system for value resolution
-
-The collection of files within the directory MAY change between launches.  The collection of files within the directory MUST NOT change during the launch phase.
-
-The contents of the files MAY change between launches.  The contents of the files MAY change during the launch phase.
-
-### Example Directory Structure
-```plain
-custom-bindings-location
-├── primary-db
-│   ├── metadata
-│   │   ├── connection-count
-│   │   ├── kind
-│   │   └── provider
-│   └── secret
-│       ├── endpoint
-│       ├── password
-│       └── username
-└── secondary-db
-    ├── metadata
-    │   ├── connection-count
-    │   ├── kind
-    │   └── provider
-    └── secret
-        ├── endpoint
-        ├── password
-        └── username
-```
+## NOTE - The CNB Bindings Spec has been deprecated in favor of https://github.com/servicebinding/spec

extensions/project-descriptor.md

@@ -29,8 +29,8 @@ This document specifies Project Descriptor Schema Version `0.2`.
 
 The Schema Version format follows the form of the [Buildpack API Version](https://github.com/buildpacks/spec/blob/main/buildpack.md#buildpack-api-version):
 
-* MUST be in form <major>.<minor> or <major>, where <major> is equivalent to <major>.0
-* When <major> is greater than 0 increments to <minor> SHALL exclusively indicate additive changes
+* MUST be in form `<major>.<minor>` or `<major>`, where `<major>` is equivalent to `<major>.0`
+* When `<major>` is greater than 0, increments to `<minor>` SHALL exclusively indicate additive changes
 
 ## Special Value Types
 

image_extension.md

@@ -0,0 +1,234 @@
+# Image Extension Interface Specification
+
+This document specifies the interface between a lifecycle program and one or more image extensions.
+
+## Table of Contents
+
+<!-- Using https://github.com/yzhang-gh/vscode-markdown to manage toc -->
+- [Image Extension Interface Specification](#image-extension-interface-specification)
+  - [Table of Contents](#table-of-contents)
+  - [Image Extension API Version](#image-extension-api-version)
+  - [Image Extension Interface](#image-extension-interface)
+    - [Detection](#detection)
+    - [Generation](#generation)
+  - [Phase: Generation](#phase-generation)
+    - [Purpose](#purpose)
+    - [Process](#process)
+      - [Dockerfile Requirements](#dockerfile-requirements)
+  - [Data Format](#data-format)
+    - [Files](#files)
+    - [extension.toml (TOML)](#extensiontoml-toml)
+
+## Image Extension API Version
+
+This document accompanies Buildpack API version `0.10`.
+
+## Image Extension Interface
+
+Unless otherwise noted, image extensions are expected to conform to the [Buildpack Interface Specification](buildpack.md).
+
+### Detection
+
+Executable: `/bin/detect`, Working Dir: `<app[AR]>`
+
+Image extensions participate in the buildpack [detection](buildpack.md#detection) process, with the same interface for `/bin/detect`. However:
+- Detection is optional for image extensions, and they are assumed to pass detection when `/bin/detect` is not present.
+- If an image extension is missing `/bin/detect`, the image extension root `/detect` directory MUST be treated as a pre-populated `<output>` directory.
+- Instead of the `CNB_BUILDPACK_DIR` input, image extensions MUST receive a `CNB_EXTENSION_DIR` which MUST be the absolute path of the extension root directory.
+- Image extensions MUST only output `provides` entries to the build plan. They MUST NOT output `requires`.
+
+### Generation
+
+Executable: `/bin/generate`, Working Dir: `<app[AR]>`
+
+Image extensions participate in a generation process that is similar to the buildpack [build](buildpack.md#build) process, with an interface that is similar to `/bin/build`. However:
+- Image extensions' `/bin/generate` MUST NOT write to the app directory.
+- Instead of the `CNB_LAYERS_DIR` input, image extensions MUST receive a `CNB_OUTPUT_DIR` which MUST be the absolute path of an `<output>` directory and MUST NOT be the path of the buildpack layers directory.
+- Instead of the `CNB_BUILDPACK_DIR` input, image extensions MUST receive a `CNB_EXTENSION_DIR` which MUST be the absolute path of the extension root directory.
+- If an image extension is missing `/bin/generate`, the image extension root `/generate` directory MUST be treated as a pre-populated `<output>` directory.
+
+## Phase: Generation
+
+### Purpose
+
+The purpose of the generation phase is to generate Dockerfiles that can be used to define the build and/or runtime base image. The generation phase MUST NOT be run for Windows builds.
+
+### Process
+
+**GIVEN:**
+- The final ordered group of image extensions determined during the detection phase,
+- A directory containing application source code,
+- The Buildpack Plan,
+- An `<output>` directory used to store generated artifacts,
+- A shell, if needed,
+
+For each image extension in the group in order, the lifecycle MUST execute `/bin/generate`.
+
+1. **If** the exit status of `/bin/generate` is non-zero, \
+   **Then** the lifecycle MUST fail the build.
+
+2. **If** the exit status of `/bin/generate` is zero,
+    1. **If** there are additional image extensions in the group, \
+       **Then** the lifecycle MUST proceed to the next image extension's `/bin/generate`.
+
+    2. **If** there are no additional image extensions in the group, \
+       **Then** the lifecycle MUST proceed to the build phase.
+
+For each `/bin/generate` executable in each image extension, the lifecycle:
+
+- MUST provide path arguments to `/bin/generate` as described in the [generation](#generation) section.
+- MUST configure the build environment as described in the [Environment](buildpack.md#environment) section.
+- MUST provide all `<plan>` entries that were required by any buildpack in the group during the detection phase with names matching the names that the image extension provided.
+
+Correspondingly, each `/bin/generate` executable:
+
+- MAY read from the `<app>` directory.
+- MUST NOT write to the `<app>` directory.
+- MAY read the build environment as described in the [Environment](buildpack.md#environment) section.
+- MAY read the Buildpack Plan.
+- MAY log output from the build process to `stdout`.
+- MAY emit error, warning, or debug messages to `stderr`.
+- MAY write either or both of `build.Dockerfile` and `run.Dockerfile` to the `<output>` directory. This file MUST adhere to the requirements listed below.
+- MAY create the following folders in the `<output>` directory with an arbitrary content:
+  
+  either:
+
+  - `context`
+
+  or the image-specific folders:
+
+  - `context.run`
+  - `context.build`
+- MAY write key-value pairs to `<output>/extend-config.toml` that are provided as build args to build.Dockerfile when extending the build image.
+- MUST NOT write SBOM (Software-Bill-of-Materials) files as described in the [Software-Bill-of-Materials](#software-bill-of-materials) section.
+
+#### Context Folders
+
+- The `<output>/context` folder MUST NOT be created together with any combination of the image-specific folders.
+- If the folder `<output>/context` is present it will be set as the build context during the `extend` phase of the build and run images.
+- If the folder `<output>/context.run` is present it will be set as the build context during the `extend` phase of the run image only.
+- If the folder `<output>/context.build` is present it will be set as the build context during the `extend` phase of the build image only.
+- If none of these folders is not present, the build context defaults to the `<app>` folder.
+
+#### Dockerfile Requirements
+
+A `run.Dockerfile`
+
+- MAY contain a single `FROM` instruction
+- MUST NOT contain any other `FROM` instructions
+- MAY contain `ADD`, `ARG`, `COPY`, `ENV`, `LABEL`, `RUN`, `SHELL`, `USER`, and `WORKDIR` instructions
+- SHOULD NOT contain any other instructions
+- SHOULD use the `build_id` build arg to invalidate the cache after a certain layer. When the `$build_id` build arg is referenced in a `RUN` instruction, all subsequent layers will be rebuilt on the next build (as the value will change); the `build_id` build arg SHOULD be defaulted to 0 if used (this ensures portability)
+- SHOULD NOT edit `<app>`, `<layers>`, or `<platform>` directories (see the [Platform Interface Specification](platform.md)) as changes will not be persisted
+- SHOULD use the `user_id` and `group_id` build args to reset the image config's `User` field to its original value if any `USER` instructions are employed
+- SHOULD set the label `io.buildpacks.rebasable` to `true` to indicate that any new run image layers are safe to rebase on top of new runtime base images
+  - For the final image to be rebasable, all applied Dockerfiles must set this label to `true`
+
+A `build.Dockerfile`
+
+- MUST begin with:
+```bash
+ARG base_image
+FROM ${base_image}
+```
+- MUST NOT contain any other `FROM` instructions
+- MAY contain `ADD`, `ARG`, `COPY`, `ENV`, `LABEL`, `RUN`, `SHELL`, `USER`, and `WORKDIR` instructions
+- SHOULD NOT contain any other instructions
+- SHOULD use the `build_id` build arg to invalidate the cache after a certain layer. When the `$build_id` build arg is referenced in a `RUN` instruction, all subsequent layers will be rebuilt on the next build (as the value will change); the `build_id` build arg SHOULD be defaulted to 0 if used (this ensures portability)
+- SHOULD NOT edit `<app>`, `<layers>`, or `<platform>` directories (see the [Platform Interface Specification](platform.md)) as changes will not be persisted
+- SHOULD use the `user_id` and `group_id` build args to reset the image config's `User` field to its original value if any `USER` instructions are employed
+
+## Phase: Extension
+
+### Purpose
+
+The purpose of the extension phase is to apply the Dockerfiles generated in the generation phase to the appropriate base image. The extension phase MUST NOT be run for Windows builds.
+
+### Process
+
+**GIVEN:**
+- The final ordered group of Dockerfiles generated during the generation phase,
+- A list of build args for each Dockerfile specified during the generation phase,
+
+For each Dockerfile in the group in order, the lifecycle MUST apply the Dockerfile to the base image as follows:
+
+- The lifecycle MUST provide each Dockerfile with:
+- A `base_image` build arg
+    - For the first Dockerfile, the value MUST be the original base image.
+    - When there are multiple Dockerfiles, the value MUST be the intermediate image generated from the application of the previous Dockerfile.
+- A `build_id` build arg
+    - The value MUST be a UUID
+- `user_id` and `group_id` build args
+    - For the first Dockerfile, the values MUST be the original `uid` and `gid` from the `User` field of the config for the original base image.
+    - When there are multiple Dockerfiles, the values MUST be the `uid` and `gid` from the `User` field of the config for the intermediate image generated from the application of the previous Dockerfile.
+
+## Data Format
+
+### Files
+
+### extension.toml (TOML)
+
+This section describes the 'Extension descriptor'.
+
+```toml
+api = "<buildpack API version>"
+
+[extension]
+id = "<extension ID>"
+name = "<extension name>"
+version = "<extension version>"
+homepage = "<extension homepage>"
+description = "<extension description>"
+keywords = [ "<string>" ]
+
+[[extension.licenses]]
+type = "<string>"
+uri = "<uri>"
+
+[[targets]]
+os = "<OS name>"
+arch = "<architecture>"
+variant = "<architecture variant>"
+[[targets.distros]]
+name = "<OS distribution name>"
+version = "<OS distribution version>"
+
+[metadata]
+# extension-specific data
+```
+
+Image extension authors MUST choose a globally unique ID, for example: "io.buildpacks.apt".
+
+The image extension `id`, `version`, `api`, and `licenses` entries MUST follow the requirements defined in the [Buildpack Interface Specification](buildpack.md).
+
+An extension descriptor MAY specify `targets` following the requirements defined in the [Buildpack Interface Specification](buildpack.md).
+
+### extend-config.toml (TOML)
+
+```toml
+[[build.args]]
+name = "<build arg name>"
+value = "<build arg value>"
+
+[[run.args]]
+name = "<build arg name>"
+value = "<build arg value>"
+```
+
+The image extension MAY specify any number of args.
+
+For each `[[build.args]]`, the image extension:
+- MUST specify a `name` to be the name of a build argument that will be provided to any output `build.Dockerfile` when extending the build base image.
+- MUST specify a `value` to be the value of the build argument that is provided.
+
+For each `[[run.args]]`, the image extension:
+- MUST specify a `name` to be the name of a build argument that will be provided to any output `run.Dockerfile` when extending the runtime base image.
+- MUST specify a `value` to be the value of the build argument that is provided.
+
+### Build Plan (TOML)
+
+See the [Buildpack Interface Specification](buildpack.md).
+
+### Buildpack Plan (TOML)
+
+See the [Buildpack Interface Specification](buildpack.md). Image extensions MUST satisfy all entries in the Buildpack Plan.

img/genmatrix.sh

@@ -0,0 +1,15 @@
+#!/bin/bash
+
+# A quick script to use tex.s2cms.ru to generate various matrix svgs.
+# (requests were previously inlined directly from buildpack.md, this allows the doc to be read if the remote side is down)
+
+wget -O matrix1.svg http://tex.s2cms.ru/svg/%0AO%20%3D%0A%5Cbegin%7Bbmatrix%7D%0AA%2C%20%26%20B%20%5C%5C%0AC%2C%20%26%20D%0A%5Cend%7Bbmatrix%7D%0A
+wget -O matrix2.svg http://tex.s2cms.ru/svg/%0AP%20%3D%0A%5Cbegin%7Bbmatrix%7D%0AE%2C%20%26%20F%20%5C%5C%0AG%2C%20%26%20H%0A%5Cend%7Bbmatrix%7D%0A
+wget -O matrix3.svg http://tex.s2cms.ru/svg/%0A%5Cbegin%7Bbmatrix%7D%0AE%2C%20%26%20O%2C%20%26%20F%0A%5Cend%7Bbmatrix%7D%20%3D%20%0A%5Cbegin%7Bbmatrix%7D%0AE%2C%20%26%20A%2C%20%26%20B%2C%20%26%20F%20%5C%5C%0AE%2C%20%26%20C%2C%20%26%20D%2C%20%26%20F%20%5C%5C%0A%5Cend%7Bbmatrix%7D%0A
+wget -O matrix4.svg http://tex.s2cms.ru/svg/%0A%5Cbegin%7Bbmatrix%7D%0AO%2C%20%26%20P%0A%5Cend%7Bbmatrix%7D%20%3D%20%0A%5Cbegin%7Bbmatrix%7D%0AA%2C%20%26%20B%2C%20%26%20E%2C%20%26%20F%20%5C%5C%0AA%2C%20%26%20B%2C%20%26%20G%2C%20%26%20H%20%5C%5C%0AC%2C%20%26%20D%2C%20%26%20E%2C%20%26%20F%20%5C%5C%0AC%2C%20%26%20D%2C%20%26%20G%2C%20%26%20H%20%5C%5C%0A%5Cend%7Bbmatrix%7D%0A
+
+# add background color.. (helps with github darkmode)
+sed -i -e's/<svg/<svg style="background-color:white"/' matrix1.svg
+sed -i -e's/<svg/<svg style="background-color:white"/' matrix2.svg
+sed -i -e's/<svg/<svg style="background-color:white"/' matrix3.svg
+sed -i -e's/<svg/<svg style="background-color:white"/' matrix4.svg

img/matrix1.svg

@@ -0,0 +1 @@
+<svg style="background-color:white" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" width="105" height="44" viewBox="1872.02 1483.609 62.765 26.301"><defs><path id="g0-20" d="M2.727 25.735h2.87v-.6h-2.27V.164h2.27v-.6h-2.87v26.17z"/><path id="g0-21" d="M2.422 25.135H.152v.6h2.87V-.436H.152v.6h2.27v24.97z"/><path id="g2-61" d="M7.495-3.567c.163 0 .37 0 .37-.218s-.207-.219-.36-.219H.971c-.153 0-.36 0-.36.219s.207.218.37.218h6.514zm.01 2.116c.153 0 .36 0 .36-.218s-.207-.218-.37-.218H.982c-.164 0-.371 0-.371.218s.207.218.36.218h6.534z"/><path id="g1-59" d="M2.215-.01c0-.72-.273-1.146-.699-1.146a.561.561 0 00-.578.578c0 .294.218.578.578.578.131 0 .273-.044.382-.142.033-.022.044-.033.055-.033s.022.011.022.164c0 .807-.382 1.462-.742 1.822-.12.12-.12.142-.12.174 0 .077.054.12.109.12.12 0 .993-.84.993-2.116z"/><path id="g1-65" d="M1.953-1.255C1.516-.524 1.09-.37.61-.338c-.131.01-.23.01-.23.218 0 .065.055.12.143.12.294 0 .632-.033.938-.033.36 0 .742.033 1.09.033.066 0 .208 0 .208-.207 0-.12-.098-.131-.175-.131-.25-.022-.512-.11-.512-.382 0-.13.065-.25.152-.404l.83-1.396h2.738c.022.23.174 1.713.174 1.822 0 .327-.567.36-.785.36-.153 0-.262 0-.262.218 0 .12.13.12.153.12.447 0 .916-.033 1.363-.033.273 0 .96.033 1.233.033.066 0 .196 0 .196-.218 0-.12-.109-.12-.25-.12-.677 0-.677-.077-.71-.393L6.24-7.549c-.022-.218-.022-.262-.207-.262-.175 0-.218.076-.284.186l-3.796 6.37zm1.309-1.603l2.149-3.6.349 3.6H3.262z"/><path id="g1-66" d="M1.745-.85c-.109.425-.13.512-.992.512-.186 0-.295 0-.295.218 0 .12.098.12.295.12h3.894c1.724 0 3.011-1.287 3.011-2.356 0-.786-.633-1.419-1.69-1.539 1.134-.207 2.28-1.014 2.28-2.05 0-.808-.72-1.506-2.03-1.506H2.553c-.208 0-.317 0-.317.218 0 .12.099.12.306.12.022 0 .229 0 .414.022.197.022.295.033.295.175 0 .043-.011.076-.044.207L1.745-.851zm1.648-3.143l.676-2.705c.098-.382.12-.415.59-.415h1.406c.96 0 1.19.644 1.19 1.124 0 .96-.939 1.996-2.27 1.996H3.393zM2.902-.338c-.153 0-.175 0-.24-.011-.11-.011-.142-.022-.142-.11 0-.032 0-.054.055-.25l.752-3.044H5.39c1.047 0 1.255.808 1.255 1.277 0 1.08-.971 2.138-2.259 2.138H2.902z"/><path id="g1-67" d="M8.29-7.582a.11.11 0 00-.12-.109c-.032 0-.043.011-.163.131l-.763.84c-.099-.153-.6-.97-1.811-.97C3-7.69.545-5.28.545-2.75.545-.95 1.833.24 3.502.24c.949 0 1.778-.436 2.356-.938 1.015-.895 1.2-1.887 1.2-1.92 0-.11-.109-.11-.13-.11-.066 0-.12.023-.143.11-.098.316-.349 1.09-1.101 1.723-.753.611-1.44.797-2.008.797-.981 0-2.138-.567-2.138-2.27 0-.621.23-2.388 1.32-3.665.666-.774 1.691-1.32 2.662-1.32 1.113 0 1.756.84 1.756 2.106 0 .436-.032.447-.032.556s.12.11.163.11c.142 0 .142-.023.197-.219l.687-2.782z"/><path id="g1-68" d="M1.735-.85c-.11.425-.131.512-.993.512-.186 0-.306 0-.306.207C.436 0 .535 0 .742 0h3.61c2.27 0 4.419-2.302 4.419-4.69 0-1.54-.927-2.76-2.564-2.76H2.542c-.207 0-.327 0-.327.206 0 .131.098.131.316.131.142 0 .338.011.469.022.175.022.24.055.24.175 0 .043-.01.076-.044.207L1.735-.851zM4.09-6.699c.098-.382.12-.415.589-.415h1.167c1.07 0 1.975.578 1.975 2.018 0 .535-.218 2.324-1.146 3.524-.316.404-1.178 1.233-2.52 1.233H2.924c-.153 0-.175 0-.24-.011-.11-.011-.142-.022-.142-.11 0-.032 0-.054.054-.25L4.091-6.7z"/><path id="g1-79" d="M8.073-4.756c0-1.757-1.157-2.935-2.782-2.935C2.935-7.69.535-5.215.535-2.673.535-.862 1.756.24 3.327.24c2.313 0 4.746-2.39 4.746-4.996zM3.393-.044c-1.08 0-1.844-.883-1.844-2.323 0-.48.153-2.073.993-3.35.753-1.134 1.822-1.701 2.683-1.701.895 0 1.877.61 1.877 2.236 0 .786-.295 2.487-1.375 3.83C5.204-.688 4.31-.045 3.393-.045z"/></defs><g id="page1"><use x="1872.02" y="1499.492" xlink:href="#g1-79"/><use x="1883.674" y="1499.492" xlink:href="#g2-61"/><use x="1895.189" y="1484.11" xlink:href="#g0-20"/><use x="1900.947" y="1492.7" xlink:href="#g1-65"/><use x="1909.129" y="1492.7" xlink:href="#g1-59"/><use x="1922.378" y="1492.7" xlink:href="#g1-66"/><use x="1901.052" y="1506.249" xlink:href="#g1-67"/><use x="1909.024" y="1506.249" xlink:href="#g1-59"/><use x="1922.122" y="1506.249" xlink:href="#g1-68"/><use x="1931.457" y="1484.11" xlink:href="#g0-21"/></g><script type="text/ecmascript">if(window.parent.postMessage)window.parent.postMessage(&quot;13.07112|78.75|33|&quot;+window.location,&quot;*&quot;);</script></svg>