[Peefy]

Fixes #207

Summary

go/lib/<platform>/ and wasm/kcl.wasm are ~370MB of compiled artifacts
and ~89% of the tracked tree, and every one of them is reproducible from
the kcl-lang/kcl release of the same
version. They are now tracked on release/* branches and release tags
only; development branches drop them and fetch them on demand.

A fresh clone goes from 394MB to 21MB.

Same shape as wasmtime-go,
which keeps its build/ directory empty on main and fills it in from CI,
with the artifacts committed onto the release. The mechanism is not new
here either — swift-release.yaml already git add -fs the universal
libkcl_lib_c.a onto its tag.

What changes for consumers

	before	after
release tag	vendored	vendored (unchanged)
development branch	vendored	hack/download-libs.sh
type-check / vet, no binaries	n/a	go build -tags no_libembed ./...

Only the development-branch row is a behaviour change.

How it works

• hack/download-libs.sh pulls one platform's runtime from the matching
  kcl-lang/kcl release. The two iOS static archives are cross-compiled from
  this repo's c/ crate instead, because they are kcl-lib-c and have no
  published asset. Nine CI jobs call it.
• vendor-libs.yaml runs on a push to release/v* and commits every
  artifact onto that branch.
• //go:embed is a compile-time dependency, so the six kcl_lib_*.go
  files (Go's implicit _GOOS_GOARCH filename constraint picks one) take a
  !no_libembed opt-out, and kcl_lib_noembed.go covers -tags no_libembed.
  install now rejects an empty CliLib with an actionable error rather than
  writing a zero-byte library that fails later at dlopen.

Why a branch, not a force-moved tag

swift-release.yaml force-updates its tag after the fact. That does not work
here: wasm-test.yaml publishes @kcl-lib/wasm to npm on a tag push, and
kcl.wasm is in that package's files array. A workflow that rewrites the
tag afterwards races the publish, and the failure is silent — npm publishes
successfully with no runtime inside it. On a release branch the binaries are
committed before the tag exists, so there is no ordering to get wrong.

Consequence: release tags must be cut from release/*, not from main.
The procedure is in docs/lib-vendoring.md.

windows/arm64 is not vendored yet

vendor-libs.yaml derives the version from the branch name and downloads
kcl-lib-<tag>-windows-arm64.zip, which no kcl release has shipped.
kcl-lang/kcl#2219 adds that target
to the release matrix, but only the first kcl tag cut after it lands carries the
asset — so vendoring that one platform fails until then.

That also broke dart-test.yaml's windows-11-arm leg, which used to pass
only because go/lib/windows-arm64/kcl.dll was committed here. The leg is now
commented out with a pointer back to kcl#2219; re-enable it once a release
carrying the asset is out and KCL_VERSION points at it. No other workflow
builds for windows/arm64, so this is the only coverage affected.

The existing v0.12.x tags still carry their binaries and are untouched. History
is deliberately not rewritten — git filter-repo would strip them from those
tags and break anyone pinning one.

Test plan

• fresh clone of the resulting tree is 21MB, down from 394MB
• go build ./... on darwin/arm64 without the binary fails with the
  expected //go:embed message (unchanged, and self-explanatory)
• go build -tags no_libembed ./... and go vet pass on all six
  GOOS/GOARCH pairs
• -tags no_libembed + InstallKcl returns the actionable error and
  writes no library file
• full go test ./... passes with the binaries present
• hack/download-libs.sh exercised end to end against stubbed archives:
  download, unpack, stage, unknown platform, missing asset, --wasm,
  bash 3.2 empty-array path, and the Windows zip fallback
• every one of the nine call sites resolves against its job's
  working-directory
• shellcheck -S style clean; parses under the bash 3.2 that ships with
  macOS
• CI green on the real download paths across all 7 go-test legs, 7 dart
  legs, the 4 AST-diff bindings and the wasm/npm job — the local sandbox
  could not reach release-assets.githubusercontent.com, so these runs are
  what actually exercise the download

Follow-ups this does not do

wasm/kcl.wasm is now a network fetch on every wasm CI run, and the wasm
tests carry hardcoded expectations about what that specific build can and
cannot do (wasm/tests/consistency.test.ts, generate_api.test.ts). They
pass today because the version is pinned by KCL_VERSION; if that pin is
ever loosened to "latest", those skip lists will start failing. Worth a
follow-up issue.

🤖 Generated with Claude Code