fix(canvas+templates): fetch runtime dropdown from /templates registry

[HongmingWang-Rabbit]

Summary

• `GET /templates` now returns the `runtime` field from each template's `config.yaml` (was being parsed then dropped)
• `ConfigTab` fetches `/templates` and builds the runtime dropdown dynamically. Adding a template to `manifest.json` now propagates automatically — no canvas PR required
• Static fallback list preserved for offline/older-backend scenarios

The bug

A Hermes workspace had `runtime=hermes` in the DB row (top badge rendered "hermes") but the Config dropdown showed "LangGraph (default)" because "hermes" wasn't among the hardcoded options. HTML `` silently fell back to the first option, and saving would have clobbered the runtime back to empty. Test plan [ ] Rebuild workspace-server image, hit `GET /templates` → response includes `runtime` field per entry [ ] Load canvas ConfigTab on a Hermes workspace → dropdown shows "Hermes Agent" as selected [ ] Load canvas offline (e.g. tenant unreachable) → dropdown falls back to the static 8-option list [ ] Add a new template to manifest.json, redeploy → appears in dropdown without code change Fixes the user-visible issue in `hongmingwang.moleculesai.app` where the Hermes workspace's Config tab showed the wrong runtime.

[HongmingWang-Rabbit]

Expanded scope (commit 82d7bf0)

Extended this PR beyond runtime dropdown to cover Model + Required Env too — per user ask "the model should fetch dynamically what this runtime supports" + "the Required Env Vars should be dynamic as well, based on selected model".

Schema now surfaced through `/templates`

```yaml
runtime_config:
model:
models:
- id:
name:
required_env: [<API keys / secrets for this model>]
```

Canvas ConfigTab

• Runtime select → from `/templates` (mount-time fetch)
• Model input → `` combobox seeded by selected runtime's `models[]`, still free-form
• Required Env Vars → defaults to selected model's `required_env`, labelled "(suggested)"; user edits override

Paired

• feat(config): add models[] registry with per-model required_env Molecule-AI/molecule-ai-workspace-template-hermes#4 — Hermes template declares models[] (proof)
• Add models[] registry to remaining 7 workspace templates #1527 — follow-up tracking the other 7 template repos

[HongmingWang-Rabbit]

Self-review (five-axis)

Re-read the diff cold. Findings below. TL;DR: one Important UX bug in how the "(suggested)" Required Env Vars propagate on save, plus missing tests. No Critical issues.

Important: suggested required_env is cosmetic-only

The "Required Env Vars (suggested)" display is derived but never committed to state, which means saving doesn't write the suggested values to config.yaml. Trace:

```tsx
values={
config.runtime_config?.required_env?.length
? config.runtime_config.required_env
: (currentModelSpec?.required_env ?? [])
}
```

• On mount: `config.runtime_config.required_env` = whatever was in yaml (often empty for new workspaces, or the old model's list)
• User picks a different model → `currentModelSpec` changes → TagList re-renders showing new suggestion
• User doesn't interact with the TagList (thinking "it's already right") → state's `required_env` is unchanged
• User hits Save → `toYaml(config)` serializes the OLD (possibly empty) `required_env` → workspace runs with the wrong env check

Concrete scenario: User selects "MiniMax M2.7 (via OpenRouter)", UI shows `OPENROUTER_API_KEY` as suggested, saves, workspace fails because config still has `HERMES_API_KEY` as the required env.

Fix: when the model input's value becomes an exact match for a known modelSpec id, commit that model's required_env to state — IF the current required_env is empty OR matches the previously-selected modelSpec's required_env (i.e. was itself template-driven, not user-edited). Rough shape:

```tsx
onChange={(e) => {
const v = e.target.value;
const nextSpec = availableModels.find((m) => m.id === v);
setConfig((prev) => {
const prevRequired = prev.runtime_config?.required_env ?? [];
const prevSpec = availableModels.find((m) => m.id === (prev.runtime_config?.model || prev.model));
const wasTemplateDriven =
prevRequired.length === 0 ||
JSON.stringify(prevRequired) === JSON.stringify(prevSpec?.required_env ?? []);
const nextRequired = wasTemplateDriven && nextSpec?.required_env
? nextSpec.required_env
: prevRequired;
return {
...prev,
runtime_config: { ...prev.runtime_config, model: v, required_env: nextRequired },
};
});
}}
```

Important: no tests

• Backend: `templates_test.go` has no assertion that the /templates response now carries `runtime` or `models[]`. A test fixturing a config.yaml with `runtime_config.models` and asserting shape would catch a future regression where someone drops the new fields from the raw struct.
• Canvas: no test for ConfigTab's runtime-dropdown-populated-from-fetch or model-datalist behaviour.

Per the user's own rule "E2E tests must verify data flow", the minimal adequate coverage here is a backend unit test on List(). Canvas test is nice-to-have.

Optional: duplicate-id defence

`` in the datalist — if a template author accidentally ships two model entries with the same id, React emits a dup-key warning and `availableModels.find((m) => m.id === currentModelId)` silently returns only the first, hiding the second entry's env. Use `key={`${m.id}-${i}`}` and consider a dev-time warning if backend returns duplicate ids per template.

Optional: extract RuntimeAndModelSection

ConfigTab is ~370 lines and growing. The new runtime/model/env block is ~60 self-contained lines — reasonable extraction when someone next touches this file.

Nit: string-match special case

`if (!v || v === "langgraph") continue;` — skip logic keyed on a literal. A const `const DEFAULT_RUNTIME = "langgraph"` would make it more grep-friendly. Not blocking.

FYI: not browser-verified

Canvas is deployed from Vercel, so this branch can't be exercised in browser until merge + Vercel redeploy. Went as far as typecheck + Go build + cold diff re-read. Acknowledged risk: visual/rendering regressions in the datalist combobox that only show up in Safari/Firefox.

---

Verdict

Request changes — primarily to fix the required_env propagation bug. Everything else is optional/nit.

[HongmingWang-Rabbit]

Review fixes applied (commit 6f06ebf)

Important #1: required_env propagation

• Model `onChange` now commits matched spec's `required_env` to state — but only when prior value was empty or matched the previous spec's list (user edits always win)
• Dropped the display-only fallback in the TagList; shows only what's in state, so Save serializes honestly
• Added "Template suggests X — Apply" affordance for the edge case where state diverges from the template (e.g. pre-existing workspace where required_env lags the template's current recommendation)
• Small `arraysEqual` helper to compare env lists

Important #2: backend tests

• `TestTemplatesList_RuntimeAndModelsRegistry` — asserts response carries `runtime` + `models[]` with per-model `required_env`
• `TestTemplatesList_LegacyTopLevelModel` — asserts older templates with top-level `model:` still round-trip correctly, Models[] empty
• Both pass locally

Optional: duplicate-id defence

• `` — template authors shipping two models with the same id no longer silently collide

Deferred (optional, not blocking)

• Extract RuntimeAndModelSection component — file's growing but still navigable
• Const for "langgraph" default runtime string — nit

Verification

• `go test ./internal/handlers -run TestTemplatesList_Runtime` — PASS
• `go test ./internal/handlers -run TestTemplatesList_Legacy` — PASS
• `npx tsc --noEmit` — clean wrt ConfigTab (pre-existing unrelated test-file errors remain)
• Browser verification still pending (Vercel redeploys on merge)

Re-review: verdict flipped from Request changes → ready for merge modulo normal CI.

[molecule-ai]

LGTM. Canary staging workflow is well-designed with alerting auto-close on recovery.

[molecule-ai]

PR #1526 — fix(canvas+templates): fetch runtime dropdown from /templates registry

Approve. Solid multi-part fix. A few observations to document for future work:

Main fix (runtime field surfacing): Correct. templateSummary now includes runtime, and canvas/ConfigTab dynamically builds the dropdown from GET /templates. The silent fallback to first-option (the original bug) is fully resolved.

SSRF hardening (ssrf.go): Good defence-in-depth. Blocking RFC-1918 + metadata + link-local at the URL-resolution layer protects the A2A proxy path. The net.LookupHost approach correctly handles DNS rebinding over time. Test coverage is comprehensive.

E2E pipeline additions (canary, full SaaS, canvas Playwright): Worth calling out: the 30-min canary catches regressions between nightly runs, the canvas Playwright suite exercises the actual runtime dropdown in-browser, and the e2e-canvas teardown safety-net is a good pattern. These complement the existing API-level tests.

Org import (org_import.go): The workspace tree creation logic is clean. Env var expansion in workspace_dir (the ${WORKSPACE_DIR} fix) is handled correctly before validation. Plugin pre-install, channel adapters, and schedule cron expressions all have appropriate error handling with graceful skips.

One minor note for follow-up: ConfigTab.tsx adds ~150 lines with a new data-fetching pattern (/templates → build dropdown). If the /templates endpoint ever returns a template with a runtime value not in the static fallback list, the dropdown will still render the full runtime value from the registry. That's the right behavior, just worth verifying once against a Hermes-registered template on staging.

Clean fix, approved.