Verification profiles

core-verify.yml chooses one profile per target. It derives the profile from the repository’s own name and topics, never from the dispatch payload:

Profile	Chosen when
`forge`	the repository is `forge` (the FORGE service itself)
`pipeline`	a forged repository with topic `forge-pipeline`
`web`	a forged repository with topic `forge-web`, or with no kind topic at all

When a web or pipeline repository carries forge.yaml at its root, its profile is skipped and each lane is verified by its own kind. See Project manifest. A symlinked forge.yaml counts as present, so forgecheck refuses it as invalid and the profile does not quietly run instead.

Toolchains come from the runner image and are never downloaded per run: Go 1.26 from the baked toolcache (setup-go@v5, cache: false), Flutter at /opt/flutter, and Node 24 bundled with the runner at $HOME/externals/node24/bin. A missing toolchain is an error, never a green build. The job’s timeout is 45 minutes.

forge

For org-runink/forge, with its siblings security and store checked out beside it:

# in grpc/
go vet ./...
go build ./...
go test -race ./...

# in flutter/, with the baked SDK
flutter pub get
flutter analyze --no-fatal-infos
flutter test
flutter build web --release --no-web-resources-cdn --no-tree-shake-icons --base-href /forge/ --pwa-strategy=none

The web build is exactly how FORGE ships behind CORE at /forge/. --pwa-strategy=none means there is no caching service worker.

web

At the repository root, then in web/:

go build ./...
go vet ./...
go test ./...

cd web
npm ci
npm run build
npm run lint     # only when package.json declares a lint script

A forged web app is expected to have its Go backend module at the root (go.mod) and its frontend in web/ (web/package.json). A missing one is a failure.

pipeline

core-verify.yml builds CORE’s own checker from this repository and runs it:

go -C core/grpc build -o "$RUNNER_TEMP/forgecheck" ./cmd/forgecheck
"$RUNNER_TEMP/forgecheck" -root target -github-output "$GITHUB_OUTPUT"
# then, only when forgecheck counted Go packages:
go build ./...
go vet ./...
go test ./...

forgecheck TOML-parses every .dsl/.herd file and counts the Go packages of the root module. Exit code 1 (bad TOML, or nothing to verify) maps to failure. Exit code 2 (it could not run) maps to error.

forgecheck reference

grpc/cmd/forgecheck is CORE-owned. It moved here from FORGE’s pipeline skeleton, so no forged repository carries a copy. It has a default mode and three sub-modes for forge.yaml.

Invocation	Flags	Does	Exit
`forgecheck`	`-root` (default `.`), `-github-output`	TOML-parses every `.dsl`/`.herd` under the root and counts Go packages when the root has `go.mod`. Writes `toml=`, `gopkgs=`, `reason=`	`0` verified · `1` checks failed · `2` could not run
`forgecheck manifest`	`-file` (default `forge.yaml`), `-github-output`	Validates the manifest. Writes `present=`, `valid=`, `reason=`, `lanes=` (JSON), `ids=` (JSON), `has_web=`	`0` absent or valid · `1` invalid · `2` could not read
`forgecheck lanes`	`-root`, `-lanes` (the JSON from `manifest`), `-results` (required)	Verifies each lane in its folder by kind. Rewrites the results file after every lane, so a cut-off run keeps what finished	`0` every lane passed or had nothing to verify · `1` a lane failed or errored · `2` could not run
`forgecheck aggregate`	`-lanes`, `-results`, `-github-output`	Turns the results into `core/ci/<id>` statuses plus the aggregate `core/ci`. Writes `state=`, `description=`, `statuses=`. A missing results file means no lane finished, so every lane is an error	`0`, or `2` for bad arguments

-lanes is re-validated on every use. The lanes are never trusted just because they were valid once, and they are never re-read from a file that a lane’s tests could have rewritten.

To run it locally from a CORE checkout:

cd grpc
go run ./cmd/forgecheck manifest -file /path/to/repo/forge.yaml
go run ./cmd/forgecheck -root /path/to/pipeline-repo

Central verification API Reference