zeekayandHanzo Dev ca9c49f7a7 schema: regenerate, instead of hand-editing what a generator owns ...

insights/schema_enums.py said HOG = "script" while schema.json had said
'script' for some time — the file was simply stale, and it carries a DO NOT EDIT
header naming `insightscli build:schema` as the way to move it.

Regenerated with datamodel-code-generator 0.36.0, the version pyproject pins.
Sixteen member names were stale, not one:

    HOG                             -> SCRIPT          (ScriptLanguage, EvaluationRuntime)
    CREATE_FN_TRANSFORMATION_FUNCTION -> CREATE_SCRIPT_TRANSFORMATION_FUNCTION
    CREATE_FN_FUNCTION_{FILTERS,INPUTS} -> CREATE_INSIGHTS_FUNCTION_{FILTERS,INPUTS}
    RUN_FN_EVAL_TEST                -> RUN_SCRIPT_EVAL_TEST
    CLICK_HOUSE                     -> DATASTORE

and 8 files referenced the old names, so those move with them. The values never
changed — only the member names, which is the whole point of a generated enum:
the name comes from the value and the value is the contract.

Worth recording why this was not done by hand. The stale file rendered
`scriptJson` as INSIGHTS_JSON; the generator renders it SCRIPT_JSON. Predicting
the output from the stale file would have produced a wrong name that looked
plausible and survived until the next regeneration. Getting the pinned tool was
cheaper than guessing: `uv run --with 'datamodel-code-generator~=0.36.0'`.

The only hog left in the generated schema is WHO_GHO = "WhoGho", an integration
vendor.

Co-authored-by: Hanzo Dev <[email protected]>

2026-08-09 21:52:10 -07:00

..

__init__.py

…

run_script_eval.py

schema: regenerate, instead of hand-editing what a generator owns

2026-08-09 21:52:10 -07:00

test_run_script_eval.py

no hogs: products and insights

2026-08-09 09:16:43 -07:00