Severity: P1
Command: winml build
Category: Validate Inputs Up-Front — when two inputs are independently supplied (config file and -m/--model), their compatibility must be checked at command entry.
Status: Behavior derived from static code path inspection (commands/build.py, loader/config.py). build does not expose --task on the CLI (uv run winml build --help | Select-String task returns nothing — verified), so the only way to set the task is via loader.task in the config JSON.
Repro:
# config.json contains {"loader": {"task": "text-generation"}, ...}
uv run winml build -c config.json -m microsoft/resnet-50 -o temp\bld\
Actual (from code-path analysis and parallel to another audit finding):
resolve_loader_config() accepts task="text-generation" from the config without checking it against microsoft/resnet-50's architecture.TasksManager.get_model_class_for_task("text-generation") resolves to AutoModelForCausalLM.AutoModelForCausalLM.from_pretrained("microsoft/resnet-50") then raises the same ValueError: Unrecognized configuration class ResNetConfig … AutoModelForCausalLM + 100-line config-class dump observed in another audit finding, except now from inside the build pipeline (not export), after the Setup banner and Stages header have already printed (compounds another audit finding).- No traceback de-duplication: the user sees the same wall of text emitted by
transformers plus the build pipeline's own error wrapping.
Expected: At command entry, after loading both --model and the config, validate that loader.task is a supported task for the model architecture (using the same TasksManager map). On mismatch, exit 2 before the Setup banner prints, with one line:
Error: config.loader.task='text-generation' is not supported for --model microsoft/resnet-50 (architecture: resnet).
Supported tasks: image-classification, image-feature-extraction.
Do not download the model, do not print the Setup banner, do not let the upstream ValueError reach the user.
Why it matters: The combination is silent at the seam between config and CLI. A user who reuses a config from a text model with a vision model (or vice versa) sees a cryptic upstream error from transformers rather than a one-line message about their config field. Same root cause as another audit finding but on a different command surface; should be fixed by a single shared validator. Violates R4.1 (validate inputs at entry), R4.2 (reject unsupported combinations), R3.1 (actionable errors).
Severity: P1
Command:
winml buildCategory: Validate Inputs Up-Front — when two inputs are independently supplied (config file and
-m/--model), their compatibility must be checked at command entry.Status: Behavior derived from static code path inspection (
commands/build.py,loader/config.py).builddoes not expose--taskon the CLI (uv run winml build --help | Select-String taskreturns nothing — verified), so the only way to set the task is vialoader.taskin the config JSON.Repro:
Actual (from code-path analysis and parallel to another audit finding):
resolve_loader_config()acceptstask="text-generation"from the config without checking it againstmicrosoft/resnet-50's architecture.TasksManager.get_model_class_for_task("text-generation")resolves toAutoModelForCausalLM.AutoModelForCausalLM.from_pretrained("microsoft/resnet-50")then raises the sameValueError: Unrecognized configuration class ResNetConfig … AutoModelForCausalLM+ 100-line config-class dump observed in another audit finding, except now from inside thebuildpipeline (notexport), after the Setup banner and Stages header have already printed (compounds another audit finding).transformersplus the build pipeline's own error wrapping.Expected: At command entry, after loading both
--modeland the config, validate thatloader.taskis a supported task for the model architecture (using the sameTasksManagermap). On mismatch, exit 2 before the Setup banner prints, with one line:Do not download the model, do not print the Setup banner, do not let the upstream
ValueErrorreach the user.Why it matters: The combination is silent at the seam between config and CLI. A user who reuses a config from a text model with a vision model (or vice versa) sees a cryptic upstream error from
transformersrather than a one-line message about their config field. Same root cause as another audit finding but on a different command surface; should be fixed by a single shared validator. Violates R4.1 (validate inputs at entry), R4.2 (reject unsupported combinations), R3.1 (actionable errors).