IMPORTANT: Developer documentation for the current development branch. This content is unreleased, may change without notice, and must not be treated as Buildish release documentation.

Planning and stage-contract types

Pipeline-emitted planning, diagnostics, and stage-manifest contracts.

Pipeline-emitted planning, diagnostics, and stage-manifest contracts.

Back to the reference overview.

Type index

CheckReportV1

Machine-readable result of site-pipeline check.

  • category: emitted
  • ownership: pipeline-derived
  • file contract: (inner type)
Field Type Required Description
schemaVersion Literal[1] yes Schema version for the check report.
generatedAt TimestampString yes Timestamp when the check report was generated.
command Literal[‘check’] yes Command name that produced this report; always check for this contract.
summary CheckSummary yes Outcome summary with pass/fail state and diagnostic counts for the run.
diagnostics list[PipelineDiagnosticEntry] yes Structured diagnostics emitted during the check run.

Example: Validation report with one warning that does not fail the run.

 1{
 2  "schemaVersion": 1,
 3  "generatedAt": "2026-04-06T08:35:00Z",
 4  "command": "check",
 5  "summary": {
 6    "status": "warnings",
 7    "passed": true,
 8    "failOnSeverity": "error",
 9    "errorCount": 0,
10    "warningCount": 1,
11    "infoCount": 0
12  },
13  "diagnostics": [
14    {
15      "severity": "warning",
16      "code": "catalog.redirectReasonMissing",
17      "message": "Redirect /spark/docs/current/ has no reader-facing reason.",
18      "componentSlug": "spark",
19      "targetId": "/spark/docs/current/"
20    }
21  ]
22}

CheckSummary

Outcome counts and pass/fail decision for one check run.

  • category: emitted
  • ownership: pipeline-derived
  • file contract: (inner type)
Field Type Required Description
status RunStatus yes Overall diagnostic status for the run after counts were evaluated.
passed bool yes Whether the check run satisfied the configured failure threshold and should be treated as passing.
failOnSeverity CheckFailureThreshold yes Configured severity threshold that decides whether warnings already fail the run or only errors do.
errorCount NonNegativeInteger yes Number of error diagnostics emitted during the run.
warningCount NonNegativeInteger yes Number of warning diagnostics emitted during the run.
infoCount NonNegativeInteger yes Number of informational diagnostics emitted during the run.

CliDiagnostic

Structured operator-facing failure without internal exception details.

  • category: emitted
  • ownership: pipeline-derived
  • file contract: (inner type)
Field Type Required Description
category CliErrorCategory yes High-level failure category suitable for automation branching.
code NonEmptyString yes Stable machine-readable CLI failure code.
message NonEmptyString yes Concise human-readable summary of the failure.
source NonEmptyString no Sanitized input name associated with the failure, when available.
issues tuple[CliDiagnosticIssue, …] no Bounded actionable issue details retained for this failure.
omittedIssueCount NonNegativeInteger no Number of additional issues omitted to keep the failure bounded.

Selected field examples

  • code: Example: "input-validation-failed"
  • source: Example: "site/catalog.yaml"

CliDiagnosticIssue

One bounded, actionable detail attached to a CLI failure.

  • category: emitted
  • ownership: pipeline-derived
  • file contract: (inner type)
Field Type Required Description
location NonEmptyString yes Bounded source or field location for the issue.
code NonEmptyString yes Stable machine-readable issue code.
message NonEmptyString yes Concise human-readable explanation of the issue.
actualBytes NonNegativeInteger no Observed input size when the issue reports a size limit.
limitBytes NonNegativeInteger no Configured maximum input size when the issue reports a size limit.

Selected field examples

  • location: Example: "components[0].slug"
  • code: Example: "required"
  • message: Example: "Field required"

CliFailureReportV1

Stable JSON envelope emitted when no command report can be produced.

  • category: emitted
  • ownership: pipeline-derived
  • file contract: (inner type)
Field Type Required Description
schemaVersion Literal[1] yes Schema version for the CLI failure report.
kind Literal[‘cliFailure’] yes Discriminator separating failures from command-specific reports.
command Literal[‘plan’, ‘check’, ‘build’, ‘watch’] yes Command whose normal JSON report could not be produced.
exitCode Literal[1, 2, 3] yes CLI process exit code associated with this failure.
error CliDiagnostic yes Structured error category, code, message, and bounded issue details.

Example: Authored input validation failure with one actionable issue.

 1{
 2  "schemaVersion": 1,
 3  "kind": "cliFailure",
 4  "command": "check",
 5  "exitCode": 1,
 6  "error": {
 7    "category": "input",
 8    "code": "input-validation-failed",
 9    "message": "Document does not satisfy its schema",
10    "source": "site/catalog.yaml",
11    "issues": [
12      {
13        "location": "components[0].slug",
14        "code": "required",
15        "message": "Field required"
16      }
17    ],
18    "omittedIssueCount": 0
19  }
20}

PipelineDiagnosticEntry

Structured diagnostic emitted during planning, checking, or staging.

  • category: emitted
  • ownership: pipeline-derived
  • file contract: (inner type)
Field Type Required Description
severity DiagnosticSeverity yes Diagnostic severity level that callers can use for gating and presentation.
code NonEmptyString yes Stable machine-readable diagnostic code.
message NonEmptyString yes Primary human-readable diagnostic message.
componentSlug NonEmptyString no Component slug associated with the diagnostic when a specific component is directly affected.
artifactKey NonEmptyString no Artifact key associated with the diagnostic when a specific artifact is directly affected.
targetId NonEmptyString no Additional target identifier, such as a path, ref, or release key, that helps callers locate the problem precisely.
details ReducedDiagnosticDetailsSummary | ExtensionsObject no Structured detail payload for the diagnostic, or a bounded summary when the original detail payload was too large.

Selected field examples

  • code: Example: "catalog.invalidRedirectTarget"
  • message: Example: "Redirect target route:/spark/missing/ could not be resolved."
  • componentSlug: Example: "spark"
  • artifactKey: Example: "runtime"
  • targetId: Example: "/spark/docs/current/"

ReducedDiagnosticDetailsSummary

Compact placeholder used when full diagnostic details were too large to keep.

  • category: emitted
  • ownership: pipeline-derived
  • file contract: (inner type)
Field Type Required Description
omitted Literal[True] yes Always true, signalling that the original diagnostic details were intentionally omitted.
reason Literal[‘sizeLimitExceeded’] yes Reason why the original diagnostic details were replaced by this bounded summary.
actualBytes PositiveInteger yes Actual serialized size of the original diagnostic details payload in bytes.
limitBytes PositiveInteger yes Configured byte limit that the original diagnostic details exceeded.
summary NonEmptyString no Short human-readable summary of the omitted details payload.
fingerprint NonEmptyString no Stable fingerprint that lets tooling correlate repeated oversized payloads without storing the full payload.

Selected field examples

  • actualBytes: Example: 524288
  • limitBytes: Example: 65536

ResolvedMaterializationEntry

One local checkout or fetched input that the planner expects to exist.

  • category: emitted
  • ownership: pipeline-derived
  • file contract: (inner type)
Field Type Required Description
sourceKey NonEmptyString no Named source binding that produced this materialization requirement.
inputKind MaterializationInputKind yes Kind of materialized input, such as a component checkout, artifact checkout, or provider-derived fetch target.
componentSlug NonEmptyString no Component slug for the materialized input when the requirement is tied to a specific component.
artifactKey NonEmptyString no Artifact key for the materialized input when the requirement is tied to one independently versioned artifact.
releaseLine NonEmptyString no Release-line key when the required local input is scoped to one maintenance line.
version NonEmptyString no Exact version when the required local input is scoped to one released version.
ref NonEmptyString no Exact source-control ref when the planner resolved this input from a branch or named ref.
tag NonEmptyString no Exact tag name when the planner resolved this input from a tagged release.
commitSha NonEmptyString no Resolved commit SHA for the required input when one was discovered.
expectedLocalPath LocalPathString yes Local filesystem path where the planner expects this input to be present or materialized.
status MaterializationStatus yes Current materialization status, such as already present, missing, or needing refresh.
provenance NonEmptyString no Short explanation of how the planner derived this materialization requirement.
watchEligible bool no Whether watch mode can safely monitor this input for incremental restaging.
reason NonEmptyString no Human-readable explanation of why this input is required or why its current status matters.

Selected field examples

  • sourceKey: Example: "apache-spark"
  • componentSlug: Example: "spark"
  • artifactKey: Example: "runtime"
  • releaseLine: Example: "4.0"
  • version: Example: "4.0.0"
  • ref: Example: "refs/heads/main"
  • tag: Example: "v4.0.0"
  • commitSha: Example: "6f0fd1f7b2c4a6d8e9f00123456789abcdef0123"
  • expectedLocalPath: Example: ".buildish/materialized/apache-spark/main"

ResolvedMaterializationReportV1

Machine-readable planning report for required local inputs.

  • category: emitted
  • ownership: pipeline-derived
  • file contract: (inner type)
Field Type Required Description
schemaVersion Literal[1] yes Schema version for the materialization planning report.
generatedAt TimestampString yes Timestamp when this planning report was generated.
target PlanningTarget yes Planning target that this report was generated for, such as build or watch preparation.
entries list[ResolvedMaterializationEntry] yes Required local inputs together with their expected locations and current materialization status.
diagnostics list[PipelineDiagnosticEntry] no Structured diagnostics emitted while resolving required local inputs for this planning target.

Example: Planning report with one required release checkout.

 1{
 2  "schemaVersion": 1,
 3  "generatedAt": "2026-04-06T08:30:00Z",
 4  "target": "build",
 5  "entries": [
 6    {
 7      "sourceKey": "apache-spark",
 8      "inputKind": "released",
 9      "componentSlug": "spark",
10      "artifactKey": "runtime",
11      "version": "4.0.0",
12      "tag": "v4.0.0",
13      "expectedLocalPath": ".buildish/materialized/apache-spark/v4.0.0",
14      "status": "present",
15      "watchEligible": false,
16      "reason": "Release docs are staged from the release tag checkout."
17    }
18  ],
19  "diagnostics": []
20}

StageDataFiles

Stage-relative paths of aggregate metadata files currently present in one stage tree.

  • category: emitted
  • ownership: pipeline-derived
  • file contract: (inner type)
Field Type Required Description
components StageRelativePath yes Stage-relative path of the published component aggregate file.
artifacts StageRelativePath yes Stage-relative path of the published artifact aggregate file.
routes StageRelativePath yes Stage-relative path of the published route aggregate file.
redirects StageRelativePath yes Stage-relative path of the published redirect aggregate file.
releases StageRelativePath no Stage-relative path of the published release aggregate file when release metadata is present.
candidates StageRelativePath no Stage-relative path of the published candidate aggregate file when release-candidate metadata is present.
refs StageRelativePath no Stage-relative path of the published ref aggregate file when development, line-head, or named-ref metadata is present.
translations StageRelativePath no Stage-relative path of the published translation aggregate file when localized page groups are present.
compatibility StageRelativePath no Stage-relative path of the published compatibility aggregate file when compatibility assertions are present.
mounts StageRelativePath no Stage-relative path of the published mount aggregate file when mounted subtrees are present.
providers StageRelativePath no Stage-relative path of the provider aggregate file when provider metadata is present in the stage.
contentIndex StageRelativePath no Stage-relative path of the content-index aggregate file when the stage includes a generated page index.
diagnostics StageRelativePath no Stage-relative path of the diagnostics aggregate file when diagnostics were published into the stage.
unitContributions StageRelativePath no Stage-relative path of the persisted unit-contribution manifest file when it is present.
outputOwnership StageRelativePath no Stage-relative path of the output-ownership map when incremental rebuild metadata is present.
aggregateDependencies StageRelativePath no Stage-relative path of the aggregate-dependency map when incremental rebuild metadata is present.

Selected field examples

  • components: Example: "data/components.json"
  • artifacts: Example: "data/artifacts.json"
  • routes: Example: "data/routes.json"
  • redirects: Example: "data/redirects.json"
  • releases: Example: "data/releases.json"
  • candidates: Example: "data/candidates.json"
  • refs: Example: "data/refs.json"
  • translations: Example: "data/translations.json"
  • compatibility: Example: "data/compatibility.json"
  • mounts: Example: "data/mounts.json"
  • providers: Example: "data/providers.json"
  • contentIndex: Example: "data/content-index.json"
  • diagnostics: Example: "data/diagnostics.json"
  • unitContributions: Example: "data/unit-contributions.json"
  • outputOwnership: Example: "data/output-ownership.json"
  • aggregateDependencies: Example: "data/aggregate-dependencies.json"

StageManifestV1

Authoritative entry-point document for a staged output tree.

  • category: emitted
  • ownership: pipeline-derived
  • file contract: manifest.json
Field Type Required Description
schemaVersion Literal[1] yes Schema version for the stage manifest.
stageLayoutVersion SchemaVersion yes Version of the stage directory layout contract that this manifest follows.
generatedAt TimestampString yes Timestamp when the manifest was generated.
command StageCommand yes Stage-producing command that created the stage tree represented by this manifest.
frontMatterFormat Literal[‘yaml’] yes Front matter serialization format used for staged content files.
aggregateFormat Literal[‘json’] yes Serialization format used for aggregate metadata files in the stage data directory.
roots StageRoots yes Top-level stage directories used for content, static assets, and aggregate data.
dataFiles StageDataFiles yes Stage-relative paths of aggregate metadata files currently present in the stage.

Example: Stage manifest that points at content, static, and aggregate roots.

 1{
 2  "schemaVersion": 1,
 3  "stageLayoutVersion": 1,
 4  "generatedAt": "2026-04-06T08:40:00Z",
 5  "command": "build",
 6  "frontMatterFormat": "yaml",
 7  "aggregateFormat": "json",
 8  "roots": {
 9    "content": "content",
10    "static": "static",
11    "data": "data"
12  },
13  "dataFiles": {
14    "components": "data/components.json",
15    "artifacts": "data/artifacts.json",
16    "routes": "data/routes.json",
17    "redirects": "data/redirects.json",
18    "releases": "data/releases.json",
19    "refs": "data/refs.json",
20    "contentIndex": "data/content-index.json"
21  }
22}

StageRoots

Named top-level directories inside a stage tree.

  • category: emitted
  • ownership: pipeline-derived
  • file contract: (inner type)
Field Type Required Description
content StageRelativePath yes Stage-relative directory that contains rendered pages and content files.
static StageRelativePath yes Stage-relative directory that contains copied static assets.
data StageRelativePath yes Stage-relative directory that contains aggregate metadata files.

Selected field examples

  • content: Example: "content"
  • static: Example: "static"
  • data: Example: "data"

StageRunReportV1

Machine-readable result of build or one completed watch cycle.

  • category: emitted
  • ownership: pipeline-derived
  • file contract: (inner type)
Field Type Required Description
schemaVersion Literal[1] yes Schema version for the stage run report.
generatedAt TimestampString yes Timestamp when the stage run report was generated.
command StageCommand yes Stage-producing command that produced this report, such as build or watch.
summary StageRunSummary yes Outcome summary with success state, stage usability, and diagnostic counts for the run.
stageRootPath LocalPathString no Local path to the root of the stage tree, if the run produced one.
manifestPath LocalPathString no Local path to the generated stage manifest when the stage is usable.
cycle NonNegativeInteger no Completed watch-cycle number for watch reports; omitted for one-shot build reports.
diagnostics list[PipelineDiagnosticEntry] yes Structured diagnostics emitted during the stage-producing run.

Selected field examples

  • cycle: Example: 3

Example: Successful build report with a usable stage manifest.

 1{
 2  "schemaVersion": 1,
 3  "generatedAt": "2026-04-06T08:40:00Z",
 4  "command": "build",
 5  "summary": {
 6    "status": "clean",
 7    "succeeded": true,
 8    "wroteStage": true,
 9    "stageUsable": true,
10    "errorCount": 0,
11    "warningCount": 0,
12    "infoCount": 2
13  },
14  "stageRootPath": ".buildish/stage/current",
15  "manifestPath": ".buildish/stage/current/manifest.json",
16  "diagnostics": []
17}

StageRunSummary

Outcome counts and usability flags for one stage-producing run or watch cycle.

  • category: emitted
  • ownership: pipeline-derived
  • file contract: (inner type)
Field Type Required Description
status RunStatus yes Overall diagnostic status for the run after counts were evaluated.
succeeded bool yes Whether the run finished with a usable stage and should be treated as successful.
wroteStage bool yes Whether the run actually wrote or refreshed stage output on disk.
stageUsable bool yes Whether downstream tooling may safely use the stage after this run finished.
errorCount NonNegativeInteger yes Number of error diagnostics emitted during the run.
warningCount NonNegativeInteger yes Number of warning diagnostics emitted during the run.
infoCount NonNegativeInteger yes Number of informational diagnostics emitted during the run.