Reviewing the executive summary for Galaxy's workflow state validation work (for GCC2026 talk prep). The original summary made strong claims about competing projects that needed fact-checking.

"New Chat" button in ChatHistoryPanel sidebar is a no-op when user is already on /chatgxy (no exchange ID in URL).

ChatHistoryPanel.vue:67-75 does router.push("/chatgxy") to start a new chat. Vue Router ignores navigation to the current route, so nothing happens when already at /chatgxy.

Both test files are solid. All 8 mutation experiments were caught (8/8), confirming these tests actually verify real behavior rather than being auto-generated fluff.

Tests to consider eliminating:

Currently BatchDataInstance (line 534) and BatchDataInstanceInternal (line 883) are simple {src, id} models. Add map_over_type: Optional[str] = None to both. Use Optional[str] — consistent with how collection_type is modeled elsewhere.

This is the core request-layer gap — map_over_type is how clients express subcollection mapping intent in batch values, but the schema doesn't model it.

We implemented a SidebarList extraction in 79678d08d5. Can we evaluate the refactoring plan (CONVERGE_CHAT_HISTORY_PLAN.md) versus just parameterizing ChatHistoryPanel and using it in both places? Is that viable? What are the blockers? What results in better structure?

Approach A — Synthetic Tool Steps: During CWL import, inject Galaxy's bundled pick_value expression tool as a synthetic workflow step for each workflow output that uses pickValue. The tool already handles first_non_null (via first_or_error) and the_only_non_null (via only). Parser-only change — no model migrations, no runtime changes. Does NOT cover all_non_null (tool can't return arrays/collections). Estimated 1-2 files touched in parser.py.

Approach B — Native Framework Support: Add a pick_value column to the WorkflowOutput model, create duplicate-label WorkflowOutput objects across source steps, then post-process pickValue semantics in run.py after all steps complete. Covers all three modes including all_non_null. Requires DB migration, model changes, parser changes, import changes, runtime changes, and export changes. Estimated 5-7 files touched.

Two conformance tests require Docker container execution:

1. test_conformance_v1_0_dockeroutputdir — Tool docker-output-dir.cwl uses dockerOutputDirectory: /other, runs touch /other/thing. Without Docker, /other doesn't exist.
2. test_conformance_v1_0_docker_entrypoint — Tool docker-run-cmd.cwl with bash:4.4.12 image. Command is -c 'echo moo' > cow relying on Docker ENTRYPOINT (bash). Without Docker, -c is "command not found".

The notebook chat panel hardcodes agent_type = "notebook_assistant". The notebook assistant is good at document editing but knows nothing about Galaxy's visualization plugin system, Vega-Lite spec generation, or chart type recommendations. Users doing data exploration want AI help picking and configuring visualizations — a different skill set from "rewrite my Methods section."

The architecture already supports multi-agent at every layer except one frontend constant:

CWL conformance test test_conformance_v1_2_timelimit_basic is a false green - it passes because a broad exception handler (lib/galaxy_test/base/populators.py:3191-3194) catches an unrelated failure, not because Galaxy actually enforces the ToolTimeLimit requirement. Galaxy declares ToolTimeLimit in SUPPORTED_TOOL_REQUIREMENTS but never extracts, propagates, or enforces the timelimit value.

1. Add timelimit as a first-class resource requirement in Galaxy XML/YAML tools (non-CWL)
2. Wire it through the existing resource requirements infrastructure (which implicitly reaches TPV)