Add Go as a full pipeline port

[aslakhellesoy]

Adds Go as a complete Varar port, structured exactly like the other ports and proven against the shared conformance corpus (no fresh tests). Module github.com/varar-dev/varar-go rooted at go/, with core · varar (facade) · config · runner · gotest packages.

Conformance (byte-for-byte)

• All four artifacts × 15 bundles — var-doc (parse), registry, plan, trace (execute), incl. the emoji/combining-mark offset bundles via a UTF-16 conversion layer.
• Config — 8/8 conformance/config/cases.
• Extraction — the tree-sitter Go dialect extracts identically to TypeScript across all 15 bundles.
• Drift — hash/drift unit vectors (unit-gated, no golden by design).

Key decisions (ADR 0010 / 0011)

• Injected Steps builder, full-replacement Value state, runtime.Caller source capture, single variadic handler shape — the static-language pattern (Rust/C#).
• Depends on the official cucumber-expressions-go library (stale at v6.2.0, but its {int}/{word}/{string} regexps are byte-identical to the reference) with Varar's own value transforms — documented as an exception since there is no 20.0.0-line Go release yet.
• go test integration = one t.Run subtest per Markdown example (no compile-time codegen needed, unlike Rust's libtest-mimic).

Integration

• make go (threaded into check), coverage → lcov (80.4%), .github/workflows/go.yml, README/coverage.json row.
• examples/go-gotest standalone consumer project — 6 specs, 30 examples all pass, with custom parameter types, header-bound rows, and a committed drift baseline.
• Tree-sitter dialect + both grammar loaders + VS Code bundler + knip; CodeMirror go highlighter; SiteLang; front-page Editor tabs; a Go <TabItem> in every docs lang-tab group; languages.json.
• Parked release wiring (GO_MODULES_ENABLED gate, 69-go-modules.sh, varar-examples pin, cliff/lint-commits scope) mirroring the Rust/C# pattern.

Verification

make go ✓ · pnpm check (biome/typecheck/knip/tests/jscpd) ✓ · pnpm --filter @varar/website... build ✓ · commit-lint ✓

🤖 Generated with Claude Code

[aslakhellesoy]

Code review

Found 1 issue:

1. The package doc comment and README describe step files as steps_*.go, but every file in the project is *.steps.go and varar.config.json declares "steps": ["*.steps.go"] (CLAUDE.md says "Step definition files: *.steps.ts", i.e. *.steps.<lang>). Since this example is what authors copy from, the reversed pattern is worth a one-line fix in both places.

varar/examples/go-gotest/steps.go

Lines 3 to 5 in 96f29c8

	// (yahtzee.go, roman.go, library_domain.go) are the code under test; the
	// steps_*.go files hold the step definitions, one per spec.
	package example

varar/examples/go-gotest/README.md

Lines 26 to 28 in 96f29c8

	its step files in, so there is nothing to glob at runtime.)
	- **`steps_*.go`** define the steps. Go has no import-for-side-effect, so — like
	the Rust/Java/Kotlin/C# ports and unlike TypeScript/Python — each file exposes a

---

API simplification (requested: godog comparison)

Separately, on the ask to look for a simpler, more idiomatic API against godog. Four observations, roughly in order of value-for-effort:

1. HandlerReturn should probably be (*Value, error). The three-state struct encodes two independent Go idioms at once — "value or no value" and "error or no error". Notably Fails is exported but used zero times in examples/go-gotest; every failure path there uses panic(...), which execute.go already recovers into the same channel. func(state Value, args []Value) (*Value, error) represents the same tri-state losslessly (nil, nil / &v, nil / nil, err) and drops an exported type plus three constructors. Mechanical to do now, breaking once the module is tagged.

varar/go/core/handler.go

Lines 26 to 42 in 96f29c8

	type HandlerReturn struct {
	Value Value
	Present bool
	Err *HandlerError
	}
	// Returns builds a "value present" return.
	func Returns(v Value) HandlerReturn { return HandlerReturn{Value: v, Present: true} }
	// NoReturn is the "no assertion / no change" return.
	func NoReturn() HandlerReturn { return HandlerReturn{} }
	// Fails builds a failing return.
	func Fails(message string) HandlerReturn { return HandlerReturn{Err: NewHandlerError(message)} }
	// HandlerFunc is the closure a Handler wraps.
	type HandlerFunc func(state Value, args []Value) HandlerReturn

2. Package clauses don't match their directories. go/core is package varcore, go/config is varconfig, go/runner is varrunner, go/gotest is vargotest — only go/varar matches. This forces an alias at every import site, including the one package consumers import directly (vargotest "github.com/varar-dev/varar-go/gotest" in every specs_test.go, instead of a bare gotest.Run(...)). Renaming the clauses only — no directory or import-path changes — is cheap now and breaking after the first tag.

varar/go/gotest/gotest.go

Lines 13 to 15 in 96f29c8

	// }
	package vargotest

3. Missing panicking Value accessors. AsInt/AsString/AsMap are all (T, bool), so the example re-implements asInt/asStr/smap wrappers by hand. MustInt()/MustString()/MustMap() on Value would remove that boilerplate from every consumer. Purely additive.

4. godog-style typed handlers — worth a follow-up, not this PR. ADR 0010 justifies the fixed func(state Value, args []Value) shape by saying "Go cannot infer closure arity the way Rust's IntoHandler trait does." That's true of Rust's compile-time trait dispatch, but it isn't godog's mechanism — godog uses runtime reflection over ctx.Step(expr, handler), which is how it accepts func(name string, age int) error. So the ADR rules out a different approach than the one on the table; worth re-litigating explicitly. The cost is real though (a reflect-based Value coercion layer plus the table/doc-string trailing-arg case), and it's a second parallel way to write a handler — better as an additive prototype once there's a second Go example project to validate against.

The NewSteps() + Registry() handoff, by contrast, looks justified rather than excess ceremony — the runner consumes the plain core Registry, mirroring Rust's into_registry() and C#'s ToRegistry().

Note on what didn't make the cut: several candidate bugs were investigated and dropped as pre-existing rather than Go-specific — the unterminated-fence Span/BodySpan inconsistency and the paramSpans misalignment on non-participating capture groups both reproduce TypeScript and Rust behavior exactly, and drift.go's sort.Strings vs compareUTF16 gap mirrors the same gap in rust/core/src/drift.rs. They may still be worth a shared-corpus test, but they aren't regressions in this PR.

🤖 Generated with Claude Code

_{- If this code review was useful, please react with 👍. Otherwise, react with 👎.}