Verification statuses

There is no per-repo CI and no per-repo credential: not in org-runink/forge, and not in any forged repo. CORE verifies them all centrally and reports the result as GitHub commit statuses. FORGE reads those statuses and never computes its own.

The contexts

Context	Posted on	Meaning
`core/ci`	Every forged repo and FORGE’s own repo, at each open PR head and at the default-branch HEAD	The aggregate result
`core/ci/<lane id>`	Project repos that carry `forge.yaml`	One lane, verified in its folder

States

State	Meaning
`pending`	Queued or running
`success`	The checks passed
`failure`	A check failed. This includes “Nothing to verify yet”
`error`	CORE’s infrastructure could not run the checks: the token, the checkout, a missing toolchain, or a cancel or timeout

target_url is the CORE run, and description is CORE’s reason, at most 140 characters.

Descriptions to expect

These are CORE’s descriptions, taken from core’s forgecheck:

Description	Where
`Nothing to verify yet: no .dsl or .herd file and no Go package in <folder>`	A pipeline lane with no code
`Nothing to verify yet: <folder> does not exist`	A lane whose folder is missing
`Nothing to verify yet: no go.mod or package.json in <folder>`	A web lane with no code
`Nothing to verify yet: no component has code yet`	Aggregate, when every lane is empty
`N/M components failed — <id>: <why>`	Aggregate, when a lane really failed
`P/M components verified[, E with nothing to verify yet]`	Aggregate `success`
`forge.yaml is invalid: <first reason>`	Aggregate `failure`, with no lane statuses

When a lane errors, the aggregate is error. When the manifest has been read, every lane context goes pending. A lane with no recorded result (because it was cancelled or timed out) closes as error.

Why “nothing to verify” is a failure. A skipped job concludes as success, and an empty project would then show green. The studio matches the Nothing to verify yet prefix and draws Nothing built yet, not a broken build.

What CORE runs, by kind

Profile	Checks
`pipeline` lane	TOML-parse every `.dsl` and `.herd`, then `go build`, `go vet` and `go test` when the folder has Go packages of its own or there is a root `go.mod`
`web` lane	`go build`, `go vet` and `go test` when the folder has a `go.mod`; `npm ci && npm run build` (plus lint when declared) when it, or its `web/`, has a `package.json`
`org-runink/forge` itself	`go vet`, `go build` and `go test -race` in `grpc/`, then Flutter `pub get`, `analyze`, `test` and `build web --base-href /forge/ --pwa-strategy=none`

A repo without forge.yaml is verified by its topic: forge-web (or no kind topic) gets the web profile, and forge-pipeline gets the pipeline profile.

How FORGE reads them

Per lane (GetChat and GetProject): core/ci/<lane id> on the default-branch HEAD becomes LaneStatus.verification_*. An imported one-lane app reads the plain core/ci.
Per app (GetApp): the combined status of the default-branch HEAD, context core/ci. See App.state in the API reference.
Per iteration (ListIterations): the core/ci of the newest default-branch commit in the iteration’s time window. It is mapped to run words: pending becomes in_progress; success becomes completed with success; failure or error becomes completed with failure.

A failed status read is reported as unavailable. It is never turned into a guessed state.

Whether CORE posts core/ci on forged repos today is not verified from FORGE. Until it does, every Verification stage reads “No verification yet”.

Sources

grpc/internal/ghforge/coreci.go (CoreCIContext); grpc/internal/ghforge/project.go (LaneContext); grpc/cmd/{forge_server,iterations_server,chat_server}.go; flutter/lib/features/forge/loop_models.dart; core’s CLAUDE.md (“Central verification (core/ci)”) and grpc/cmd/forgecheck/.

gRPC API Environment