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.
Back to the reference overview.
Type index
- CheckReportV1 — Machine-readable result of
site-pipeline check. - CheckSummary — Outcome counts and pass/fail decision for one
checkrun. - CliDiagnostic — Structured operator-facing failure without internal exception details.
- CliDiagnosticIssue — One bounded, actionable detail attached to a CLI failure.
- CliFailureReportV1 — Stable JSON envelope emitted when no command report can be produced.
- PipelineDiagnosticEntry — Structured diagnostic emitted during planning, checking, or staging.
- ReducedDiagnosticDetailsSummary — Compact placeholder used when full diagnostic details were too large to keep.
- ResolvedMaterializationEntry — One local checkout or fetched input that the planner expects to exist.
- ResolvedMaterializationReportV1 — Machine-readable planning report for required local inputs.
- StageDataFiles — Stage-relative paths of aggregate metadata files currently present in one stage tree.
- StageManifestV1 — Authoritative entry-point document for a staged output tree.
- StageRoots — Named top-level directories inside a stage tree.
- StageRunReportV1 — Machine-readable result of
buildor one completed watch cycle. - StageRunSummary — Outcome counts and usability flags for one stage-producing run or watch cycle.
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:524288limitBytes: 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. |