Open question: what to do with the VS Code extension branch (feat/vscode-extension) #37

Status

feat/vscode-extension turns csauto into a VS Code extension: a sidebar with one section per campaign, the dashboard embedded in a webview and themed natively, a managed Python runtime, and marketplace packaging.

The branch has had no activity since 2026-07-17 and has no PR. Measured against main (6a74ffd):

• 44 commits ahead, 40 behind. It misses everything since July: the code_aster adapter, solver capabilities (feat: derive dashboard panels and actions from solver capabilities #22), the GUI mount fix (fix: mount shared dir symlinks when opening the solver GUI #23), the RUNNING and FAILED status fixes (fix: stop reporting crashed cases as RUNNING forever #24, fix: keep the FAILED status of a launch that never started #25).
• 115 files changed, +4648 / −2149.
• A trial merge into main conflicts textually on only five files (CHANGELOG.md, README.md, ROADMAP.md, VERSION, frontend/package.json) plus the built bundles. The structural changes below are the real cost, not the conflicts.

Nobody has decided what should happen to it. This issue records that the question is open and what it covers, so that it does not stay implicit.

What the branch contains

The extension itself

• package.json, src/*.ts, esbuild.js, tsconfig.json, .vscodeignore at the repository root: the root becomes a Node project as well as a Python one.
• Ten commands: open dashboard, start, stop and restart the server, logs, install the CLI, doctor, reload, prepare, stop all servers.
• scripts/bundle-wheel.sh: the .vsix embeds a csauto wheel and installs it into a venv the extension manages.
• .github/workflows/extension.yml, scoped to the feature branch, and changes to release.yml.

Structural changes to csauto

• The frontend build moves from frontend/dist/ to csauto/_frontend/, inside the Python package, and serve_commands.py serves it from there.
• Version jumps to 1.0.0, where main is at 0.5.0.
• The README is rewritten extension-first, and the branding becomes solver-neutral, with a Simvia mark and a solver-aware favicon.

Changes useful without the extension

• New CLI commands kill, note and convergence, which the extension calls but which stand on their own.
• CSAUTO_API_TOKEN as an environment fallback for the API token.
• The solver GUI scaled to the client display through build_gui_command(..., gui_env=), plus Open GUI working on WSL. This needs re-checking against the GUI mount fix of fix: mount shared dir symlinks when opening the solver GUI #23.
• A frontend embed mode (frontend/src/lib/vscode-embed.ts, theme bridge) that is harmless outside VS Code.

Open questions

1. Do we want a VS Code extension for csauto at all? Simvia already ships VS Code Aster. Is csauto a CLI with a web dashboard that an extension wraps, or an extension first, as the branch's README says?
2. Where does it live? In this repository, with a root that is both a Python and a Node project, or in its own repository consuming csauto as a published wheel, like VS Code Aster?
3. How is the frontend shipped? The move to csauto/_frontend/ conflicts with how main and [qarnot-1] Run a campaign on the Qarnot cloud #34 commit frontend/dist/ today. Whichever lands second must redo its build into the other location, or the server serves a stale UI.
4. One version or two? The branch bumps csauto to 1.0.0 for the extension's sake. The CLI and the extension may want independent versions.
5. Who carries it? It needs an owner for the rebase, and then for marketplace releases.

Options

• A. Revive in this repository. Rebase on main, settle questions 3 and 4, open a PR. The cost is concentrated in the frontend relocation and in re-testing the GUI changes against fix: mount shared dir symlinks when opening the solver GUI #23.
• B. Move to its own repository. Keep only the generic changes here (embed mode, CSAUTO_API_TOKEN, the CLI commands) and have the extension depend on a published csauto. This keeps this repository Python-only, at the price of release coordination between two repositories.
• C. Salvage and park. Extract the changes useful without the extension into small PRs on main, then archive the branch until a decision on question 1.
• D. Drop it. Delete the branch and close this issue.

Options B and C start with the same extraction, so it can begin before question 1 is answered.

Interaction with current work

• [qarnot-1] Run a campaign on the Qarnot cloud #34 and [qarnot-2] Qarnot for every solver: a Run option each adapter opts into (code_saturne, code_aster, openTELEMAC) #36 change the Run dialog and rebuild frontend/dist/. Merging this branch after them means its frontend relocation must absorb their bundles.
• The dashboard embedded by the extension would inherit the Qarnot option from [qarnot-2] Qarnot for every solver: a Run option each adapter opts into (code_saturne, code_aster, openTELEMAC) #36 with no extension-side work, since the webview renders the same frontend.

Definition of done

• A decision on questions 1 and 2 is recorded in this issue.
• Then one of: the branch is merged through a PR (A), moved to its own repository (B), salvaged into main and archived (C), or deleted (D).