Problem
A sample template can enable an engine that no documented/installable extra provides, and nothing catches it. This is exactly how gmail_web shipped camera_screenshot: enabled: true (fixed in #441) — a Selenium web template requiring a camera source, so optics init --template gmail_web → optics dry_run failed out of the box.
Proposal
Add a drift-guard test that, for every directory under optics_framework/samples/, parses config.yaml and asserts each enabled engine (driver_sources / elements_sources / text_detection / image_detection / llm_models) is covered by an installable extra combination (i.e. maps to a known engine/extra in helper/setup.py, allowing for the always-present core sources).
This keeps the README's "--template scaffolds a working project" promise honest and prevents regressions like the gmail_web one.
Context
Surfaced by a fresh-install audit of the README onboarding commands (see #441, #443).
Problem
A sample template can enable an engine that no documented/installable extra provides, and nothing catches it. This is exactly how
gmail_webshippedcamera_screenshot: enabled: true(fixed in #441) — a Selenium web template requiring a camera source, sooptics init --template gmail_web→optics dry_runfailed out of the box.Proposal
Add a drift-guard test that, for every directory under
optics_framework/samples/, parsesconfig.yamland asserts each enabled engine (driver_sources/elements_sources/text_detection/image_detection/llm_models) is covered by an installable extra combination (i.e. maps to a known engine/extra inhelper/setup.py, allowing for the always-present core sources).This keeps the README's "
--templatescaffolds a working project" promise honest and prevents regressions like the gmail_web one.Context
Surfaced by a fresh-install audit of the README onboarding commands (see #441, #443).