fix(presets): guard non-list/non-mapping provides.templates in PresetManifest

[jawwad-ali]

Problem

PresetManifest._validate iterates provides["templates"] with no shape guards, unlike the direct sibling ExtensionManifest._validate (which guards both the container and each entry). A malformed third-party preset.yml therefore crashes with a raw TypeError rather than a clean validation error:

templates: 5        →  TypeError: 'int' object is not iterable
templates: [null]   →  TypeError: argument of type 'NoneType' is not iterable
templates: [5]      →  TypeError: argument of type 'int' is not iterable

The install handler (presets/_commands.py) only catches PresetCompatibilityError / PresetValidationError / PresetError, so the TypeError escapes all three and dumps an unhandled Python traceback to the user on specify preset install. (A string/list entry is arguably worse — it slips past into the misleading "Template missing 'type', 'name', or 'file'".)

Reproduced on main (4d3a428): the same three malformed shapes fed to the sibling ExtensionManifest return clean ValidationErrors — confirming the parity gap.

Fix

Add the two guards ExtensionManifest already has, raising PresetValidationError:

templates = provides["templates"]
if not isinstance(templates, list):
    raise PresetValidationError("Invalid provides.templates: expected a list")
for tmpl in templates:
    if not isinstance(tmpl, dict):
        raise PresetValidationError("Each template entry in 'provides.templates' must be a mapping")
    ...

Valid manifests (a list of mappings) pass both guards unchanged — no behaviour change for correct input.

Verification

• New test_non_list_templates_raises_validation_error + parametrized test_non_mapping_template_entry_raises_validation_error (None/5/"oops"/["nested"]): fail before (raw TypeError or the misleading "Template missing…" message), pass after (clean PresetValidationError). Mirrors the existing test_non_mapping_yaml_raises_validation_error precedent.
• Full TestPresetManifest: 24 passed. ruff clean.

---

AI-assisted: authored with Claude Code. I reproduced the raw TypeErrors on main and confirmed the sibling ExtensionManifest already returns clean errors for the identical shapes.

[Copilot]

Pull request overview

Improves preset manifest validation so malformed template declarations raise controlled errors.

Changes:

• Validates provides.templates container and entry shapes.
• Adds regression tests for malformed values.

Show a summary per file

File	Description
src/specify_cli/presets/__init__.py	Adds template shape guards.
tests/test_presets.py	Tests invalid containers and entries.

Review details

Tip

Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

• Files reviewed: 2/2 changed files
• Comments generated: 1
• Review effort level: Medium

[jawwad-ali]

Correct, and a good catch — fixed in 7612936. My original test used templates: 5 (truthy), which is exactly why it passed while every falsy non-list still hit the misleading message.

Reordered to presence → container type → emptiness:

if "templates" not in provides: raise ...("must provide at least one template")
templates = provides["templates"]
if not isinstance(templates, list): raise ...("Invalid provides.templates: expected a list")
if not templates: raise ...("must provide at least one template")

An empty list deliberately keeps the "at least one template" message — it genuinely is a well-typed container with no templates — so the pre-existing test_no_templates_provided is unaffected. I added a regression guard for that, and parametrized the non-list test over truthy (5, "oops", {"a": 1}) and falsy (0, False, None, "", {}) values — the 5 falsy cases fail before this commit.