MakazhanAlpamys/Soup v0.71.35

v0.71.35 — Compliance pack

on GitHub

Ship a regulated fine-tune with the paperwork it needs — and GGUF export that actually works on Windows.

What's New

soup init --template hipaa|soc2|eu-ai-act|sr-11-7 — four regulation-shaped starting configs (templates 17 → 21). Soup's compliance controls are CLI flags/commands rather than config keys, so each template is a valid training config plus header comments naming that regime's exact commands: PHI scrubbing + air-gap for HIPAA, BOM/attest/sign for SOC 2, Annex XI + energy tracking for the EU AI Act, repro-receipt + diagnose/ship for SR 11-7. License-clean Apache-2.0 base.

soup card <registry-id> -o MODELCARD.md — turn a registry entry into a publishable, provenance-carrying HF model card: base model, training config, eval scorecard, config/data hashes, lineage, and every registered artifact. Adapter-vs-dense is inferred from artifacts, falling back to the training config, so the card sets the right library_name and never misreports the model type.

soup push --card <registry-id> — upload that card as the README, overriding the auto-generated one. A bad ref fails fast, before any network call.

soup ci init — writes .github/workflows/soup-gate.yml: a PR gate chaining soup data validate → soup expect → soup ship --evidence. A regression exits 2 and blocks the merge. Paths are validated to stay under the repo root and shell-quoted; branch and Python version are regex-gated.

Compliance quickstart — docs/compliance.md: template → PII scrub → train with receipt/Annex-XI/energy → registry → BOM + attestation → scan/sign/verify → air-gap → model card → CI gate.

Install / Upgrade

pip install --upgrade soup-cli

Fixed

GGUF export now actually works on Windows — validated end-to-end for the first time (llama.cpp b5270 built CPU-only with VS2022 BuildTools; SmolLM2-135M → q4_0 / q4_k_m / q8_0 / f16 → soup deploy ollama → live inference). Four real bugs, each independently fatal:

• soup export --format gguf cloned llama.cpp into your current directory. SOUP_DIR is the bare name .soup but was used relatively instead of anchored to ~, so the canonical ~/.soup/llama.cpp was never found and a fresh ~200 MB checkout landed wherever you ran from.
• Your first GGUF export downgraded PyTorch and broke CUDA. The auto-clone ran pip install -r <llama.cpp>/requirements.txt into your interpreter, and llama.cpp pins torch~=2.2.1 against the CPU wheel index (observed live: torch 2.5.1+cu → 2.2.2+cpu, transformers 4.57 → 4.46). Soup now installs only the convert script's extra deps, unpinned, and never touches torch.
• A correctly-built llama.cpp wasn't found on Windows. MSVC (like Xcode) is a multi-config generator emitting build/bin/Release/llama-quantize.exe; only the flat layout was searched.
• soup deploy ollama failed on a relative GGUF path ("pull model manifest: file does not exist") — Ollama resolves FROM against the Modelfile's directory, and Soup writes it to a temp dir. The Modelfile now emits an absolute path.

This closes the CPU-validatable half of #70 / #144.

Security

Model-card injection hardening — also fixes the pre-existing soup push auto-card. The ## Training section interpolated base / task / scheduler / recipe unescaped. Since SoupConfig.base and scheduler have no charset validator, a crafted-but-schema-valid config could smuggle raw HTML — or a backtick breaking out of the surrounding code span — into a card published to the public Hub. All values now go through the markdown escaper, which additionally neutralises backticks and strips C0/ESC control bytes.

Also: the generated CI workflow shell-quotes every interpolated path and regex-gates branch/python; the workflow writer reuses the shared containment helper (a hand-rolled S_ISLNK check missed Windows junctions); registry-sourced notes and artifact rows are bounded.

Known Limitations

• The compliance templates are starting points and documentation, not certification. They encode no legal opinion, and a template cannot enforce a control because Soup's compliance controls are CLI flags/commands rather than schema keys.
• soup card reflects only what the registry holds. BOM and attestations are standalone files, not registry artifact kinds, so the card lists registered artifacts (adapter / merged / GGUF / diagnose report / eval results) and the quickstart tells you to emit and attach the rest.
• soup push --card's upload is validated against a mocked Hub API, not a live push. The card render is live-validated; the HTTP upload is not.
• The generated soup-gate.yml is a starting point — it assumes pip install soup-cli and committed data/suite/evidence paths. It's rendered and locally chain-verified (validate=0, expect=0, ship=0/2) but not executed on GitHub CI.
• GGUF was validated CPU-only on Windows with llama.cpp b5270 + MSVC on one tiny model. Ninja/Make, macOS/Xcode, CUDA llama.cpp builds, and larger models are unvalidated (the multi-config fix covers Xcode by construction but is untested there).
• The Ollama round-trip proves the mechanism, not quality — a 135M model trained one step emits gibberish; only the export → deploy → generate path is validated.

Full Changelog: v0.71.34...v0.71.35