kcl-generate: emit Go validation for check/rule blocks — drop the startup KCL runtime dependency #23

New issue

Open

opened 2026-08-07 02:20:51 +00:00 by ginjiruu · 0 comments

ginjiruu commented

2026-08-07 02:20:51 +00:00

Owner

Background

Graduated from wayfinding ticket #9 (toolbelt/cmd design grilling, Q2b).

The toolbelt's config story is KCL-as-spec: schema.k is the single source of truth, kcl-generate emits the field registry + bootstrap (var App = config.New(...)). Field-level validation is already generated Go (Field.ValidValues, ValidateTag, #@kcl:validate hooks) and runs without the KCL runtime.

What is NOT codegen'd is schema-level validation: check/rule blocks. Those are enforced at startup by the KCL runtime (cfg.Validate() → kcl.ValidateConfig against the schema path).

Consequence

Every binary links the KCL runtime (kcl-lang.io/kcl-go + the 206 MB kcl-lang.io/lib) even though its field-level validation is already generated.
The .k schema file must be shipped next to the binary at runtime (SchemaPath), and path deps resolved — a deployment smell.
Runtime validation is accepted for the #9 landing, but the runtime dependency and shipping-the-schema are real costs.

Question

Can kcl-generate emit Go validation for the KCL check/rule blocks that are expressible (types, literal unions, ranges, cross-field constraints), and keep the runtime only as a fallback for inexpressible blocks? KCL is a full language, so full translation is a compiler project — the ticket should scope what fraction of real-world schemas are expressible.

Not

Not part of issue #9 (toolbelt/cmd). Candidate for a future triage decision; labeled needs-triage. Per the map's deliverable shape, resolving this ticket writes a plan to docs/plans/ only — no code lands until the post-map clean rewrite.

## Background Graduated from wayfinding ticket [#9](https://git.animeteamspeak.moe/ginjiruu/toolbelt/issues/9) (toolbelt/cmd design grilling, Q2b). The toolbelt's config story is KCL-as-spec: `schema.k` is the single source of truth, `kcl-generate` emits the field registry + bootstrap (`var App = config.New(...)`). Field-level validation is already generated Go (`Field.ValidValues`, `ValidateTag`, `#@kcl:validate` hooks) and runs without the KCL runtime. What is NOT codegen'd is **schema-level validation**: `check`/`rule` blocks. Those are enforced at startup by the KCL runtime (`cfg.Validate()` → `kcl.ValidateConfig` against the schema path). ## Consequence - Every binary links the KCL runtime (`kcl-lang.io/kcl-go` + the 206 MB `kcl-lang.io/lib`) even though its field-level validation is already generated. - The `.k` schema file must be shipped next to the binary at runtime (`SchemaPath`), and path deps resolved — a deployment smell. - Runtime validation is accepted for the #9 landing, but the runtime dependency and shipping-the-schema are real costs. ## Question Can `kcl-generate` emit Go validation for the KCL `check`/`rule` blocks that are expressible (types, literal unions, ranges, cross-field constraints), and keep the runtime only as a fallback for inexpressible blocks? KCL is a full language, so full translation is a compiler project — the ticket should scope what fraction of real-world schemas are expressible. ## Not Not part of issue #9 (toolbelt/cmd). Candidate for a future triage decision; labeled `needs-triage`. Per the map's deliverable shape, resolving this ticket writes a plan to `docs/plans/` only — no code lands until the post-map clean rewrite.

ginjiruu added the

needs-triage

label

2026-08-07 02:20:55 +00:00

ginjiruu referenced this issue

2026-08-07 02:21:03 +00:00

Design toolbelt/cmd — the shared cobra bootstrap surface #9

ginjiruu referenced this issue

2026-08-07 02:21:19 +00:00

Toolbelt glue absorption — map: what the toolbelt absorbs from duplicated consumer glue #1

ginjiruu added this to the Toolbelt glue absorption milestone

2026-08-07 02:22:46 +00:00