Fix Admin Settings 500: Jinja set scope does not cross an include

[Paul Lizer (paullizer)]

Fixes the 500 on Admin Settings, plus a silent variant of the same bug found while investigating.

Base: feature/admin-settings-ia.

The failure

File "templates/admin/_panes/actions.html", line 17, in top-level template code
<input ... {% if analyze_capability.enabled %}checked{% endif %}>
jinja2.exceptions.UndefinedError: 'analyze_capability' is undefined

Root cause

Jinja {% set %} scope does not cross an {% include %} boundary.

While Admin Settings was one 14,000-line template this never mattered — a variable derived near the top was visible everywhere below it. Splitting it into 44 per-tab partials made it matter: a variable derived in one partial is simply not visible in another.

Three variables were left behind when their consuming card moved to a different tab:

Variable	Declared in	Used in	Failure
analyze_capability	agents	actions	500
comparison_capability	agents	actions	500
enable_dai_debug	redis-caching	cosmos	silent

Each is a pure derivation from settings, which the route supplies to every template, so moving the declaration into the consuming pane is safe and self-contained.

The one you didn't see

The two failure modes are very different, and the quiet one is worse:

• Attribute access on a missing name raises and takes the page down. Loud, found immediately.
• A boolean test on a missing name is silently false, because Jinja's default Undefined is falsy.

enable_dai_debug is used as {% if enable_dai_debug %} in six places on the Cosmos tab. Those debug controls and shadow-validation diagnostics would never have rendered, whatever the setting was, and nothing would have reported a problem. It was found only by auditing for the pattern that caused the crash — not by the error.

Why every existing test passed

All the Admin Settings tests inspect the template as text: field names, card ids, tag balance, navigation parity, modal placement. Every one was green.

None of them execute the template. A template can satisfy every static check and still raise the moment Flask renders it. That is the real gap this PR closes.

test_admin_settings_renders.py

Renders the whole page through Jinja using the same undefined handling Flask uses, so an UndefinedError surfaces in the suite instead of in a browser. This is the test that would have caught the bug immediately.

It also asserts every navigation tab renders a pane, and that exactly one pane is active and it is the landing tab.

The render context is derived from the route's own render_template call and the app context processors, so it cannot drift as those change.

test_admin_settings_pane_variable_scope.py

Static scope analysis via jinja2.meta.find_undeclared_variables, which catches the silent variant a render cannot. It names the offender precisely:

'analyze_capability' is used in 'actions' but only declared in ['agents']

Variables declared inside a {% for %} loop are correctly treated as local.

Both tests are verified against a planted copy of the real bug, so they are known to fail when they should.

Verification

Check	Result
Page renders	1,383,741 chars, no error
Navigation tabs rendering a pane	44 / 44
Active panes	exactly 1, and it is the landing tab
Cross-pane variable leaks	none
Field names vs Development	452 → 452, zero lost, zero added
Regression set (75 files)	32 pre-existing failures, unchanged
Jinja compile	46/46 admin templates
XSS sinks	pass

No setting changed and nothing needs re-entering.

Version 0.260.019. Full write-up in ADMIN_SETTINGS_PANE_VARIABLE_SCOPE_FIX.md.

The rule worth keeping: a template is not verified until it has been rendered.