Pillar — Build & Environment

Prefix: BLD- Catalog: v1.1 deltas (additive to v1.0 Build & Environment). What it measures: whether an agent can reproduce the build and ship a single slice of a product portfolio without a human walking it through secrets, toolchain drift, or a fleet-wide deploy.

v1.0 already covers reproducible builds, pinned runtimes, committed lockfiles, environment templates, hermetic CI, and published images. These v1.1 criteria extend that contract to portfolio subjects: one toolchain matrix, one install path, and deploys that cannot fan out to unrelated applications.

Criteria in this pillar

BLD-100 — Package manager version pinned

Level: 2 · Scope: repository · Check: deterministic
The package manager itself is pinned (packageManager in package.json, Corepack, a committed .npmrc / .yarnrc.yml with an exact version, or the language-equivalent pin) so install on a clean clone cannot silently pick a newer major.
Rationale: a pinned language runtime (BLD-020) still drifts if the installer that resolves the lockfile is free to change. Agents cannot reproduce "works on my machine" failures that come from the package manager.
Evidence expected: pin file or packageManager field present; CI install uses that pin; the constraint is exact or a single minor band.

BLD-110 — Secret-free CI build proof

Level: 3 · Scope: application · Check: deterministic
Compile, typecheck, and unit-test jobs succeed with placeholder or unset secrets. Production secret values are not required to produce a build artifact. Runtime secrets are injected at deploy, not at compile.
Rationale: an agent that cannot prove a slice builds without production credentials is blocked on a human with a vault. Secret-free proof also prevents credentials leaking into build logs and caches.
Evidence expected: CI build job with no secret bindings (or documented placeholders only); a clean clone plus the documented placeholders produces the same artifact; a comment or manifest listing which values are compile-time versus runtime.

BLD-120 — Per-slice deploy isolation

Level: 4 · Scope: portfolio · Check: deterministic
A change under one application deploys only that application. A change to a shared library deploys only the applications that depend on it. Unrelated applications in the same portfolio MUST NOT rebuild or ship as a side effect.
Rationale: portfolio-scale subjects fail closed when every merge fans out to every product. Agents need a machine-readable map from path to deployable so they can ship one slice without taking the rest of the portfolio with them.
Evidence expected: a published affected-slice graph or path filter; deploy logs showing a single-application change shipped only that application; absence of a "deploy all applications" path on library-only diffs except for the documented dependents.

BLD-130 — SBOM emitted on release

Level: 4 · Scope: application · Check: deterministic
Each tagged release produces a Software Bill of Materials in CycloneDX or SPDX for the application artifact and attaches it to the release. The SBOM is generated from the locked dependency graph, not from a hand-maintained list.
Rationale: agents that assemble and operate a product need a machine-readable inventory of what they shipped. Without an SBOM, incident response and licence review become archaeology.
Evidence expected: SBOM artifact on the last release; generator wired into the release job; format is CycloneDX or SPDX.

BLD-140 — Portfolio toolchain matrix published

Level: 3 · Scope: portfolio · Check: deterministic
The portfolio publishes one matrix of supported language runtimes, package managers, and CI images. Every application in the subject is constrained to that matrix; exceptions are enumerated with an owner and a removal date.
Rationale: per-application pins (BLD-020, BLD-100) still leave a portfolio of N toolchains. Agents hopping between applications in the same product cannot keep N runtimes, N installers, and N CI images in their head — and neither can the humans who review them.
Evidence expected: a committed matrix (document or machine-readable file) listing allowed versions; CI fails an application that drifts off the matrix; exception list is empty or time-bounded.

v1.0 Build & Environment — the published BLD-010 through BLD-080 criteria.
v1.1 pillars — draft catalog, including these deltas and the six new pillar stubs.
v1.0 specification — the published standard.

Criteria in this pillar

Level: 2 · Scope: repository · Check: deterministic

The package manager itself is pinned (packageManager in package.json, Corepack, a committed .npmrc / .yarnrc.yml with an exact version, or the language-equivalent pin) so install on a clean clone cannot silently pick a newer major.

Rationale: a pinned language runtime (BLD-020) still drifts if the installer that resolves the lockfile is free to change. Agents cannot reproduce "works on my machine" failures that come from the package manager.

Evidence expected: pin file or packageManager field present; CI install uses that pin; the constraint is exact or a single minor band.

Level: 3 · Scope: application · Check: deterministic

Compile, typecheck, and unit-test jobs succeed with placeholder or unset secrets. Production secret values are not required to produce a build artifact. Runtime secrets are injected at deploy, not at compile.

Rationale: an agent that cannot prove a slice builds without production credentials is blocked on a human with a vault. Secret-free proof also prevents credentials leaking into build logs and caches.

Evidence expected: CI build job with no secret bindings (or documented placeholders only); a clean clone plus the documented placeholders produces the same artifact; a comment or manifest listing which values are compile-time versus runtime.

Level: 4 · Scope: portfolio · Check: deterministic

A change under one application deploys only that application. A change to a shared library deploys only the applications that depend on it. Unrelated applications in the same portfolio MUST NOT rebuild or ship as a side effect.

Rationale: portfolio-scale subjects fail closed when every merge fans out to every product. Agents need a machine-readable map from path to deployable so they can ship one slice without taking the rest of the portfolio with them.

Evidence expected: a published affected-slice graph or path filter; deploy logs showing a single-application change shipped only that application; absence of a "deploy all applications" path on library-only diffs except for the documented dependents.

Level: 4 · Scope: application · Check: deterministic

Each tagged release produces a Software Bill of Materials in CycloneDX or SPDX for the application artifact and attaches it to the release. The SBOM is generated from the locked dependency graph, not from a hand-maintained list.

Rationale: agents that assemble and operate a product need a machine-readable inventory of what they shipped. Without an SBOM, incident response and licence review become archaeology.

Evidence expected: SBOM artifact on the last release; generator wired into the release job; format is CycloneDX or SPDX.

Level: 3 · Scope: portfolio · Check: deterministic

The portfolio publishes one matrix of supported language runtimes, package managers, and CI images. Every application in the subject is constrained to that matrix; exceptions are enumerated with an owner and a removal date.

Rationale: per-application pins (BLD-020, BLD-100) still leave a portfolio of N toolchains. Agents hopping between applications in the same product cannot keep N runtimes, N installers, and N CI images in their head — and neither can the humans who review them.

Evidence expected: a committed matrix (document or machine-readable file) listing allowed versions; CI fails an application that drifts off the matrix; exception list is empty or time-bounded.