feat(python-notebook-migration, frontend): add an AI generate workflow entry point on the dashboard

[zyratlo]

What changes were proposed in this PR?

Adds an "AI generate workflow" entry point on the workflow dashboard for the Python notebook to Texera workflow migration tool. A user can upload a Jupyter notebook (.ipynb) and get a generated Texera workflow without opening a workflow first.

Dashboard button (user-workflow.component.{ts,html})

• A new robot icon button in the workflows toolbar, styled like the existing "Upload ZIP/JSON" button and gated on pythonNotebookMigrationEnabled with a non read-only access level.
• openAiGenerateModal() opens the same NotebookImportModalComponent used elsewhere, with no footer and centered.
• generateWorkflowFromNotebook(file, model) runs the pipeline in stages, each with its own error toast: validate the .ipynb extension, parseAndTagNotebook(file) to read and uuid-tag the cells, sendToAIGenerateWorkflow(notebook, model) to call the LLM, then createWorkflow(...) to persist the result. After the workflow exists, it best-effort adds it to the current project, stores the notebook and cell mapping, and navigates to the new workflow with ?autolayout=1. Once the workflow is created the flow never re-runs generation and never orphans the workflow.

Import modal (notebook-import-modal.component.{ts,html,scss})

• The modal keeps the diagram at the top and holds the form plus a solid absolute loading overlay, so it does not resize or re-center when it swaps to the loading view.
• The loading view shows a spinner, a "Generating your workflow" message, and an elapsed-time stopwatch computed from a wall-clock start time so a backgrounded tab cannot undercount.
• While generation runs the modal is locked: it is not closable, mask-closable, or keyboard-dismissable, so a user cannot interrupt an in-flight generation.

Workspace auto-layout (workspace.component.ts)

• On load the workspace reads ?autolayout=1, renders the workflow synchronously so the operators exist, runs auto-layout once, and then strips the query param. The Jupyter notebook panel opens on its own through the wid-driven JupyterPanelService. No generation code lives in the workspace.

Shared mapping key (notebook-migration.service.ts, jupyter-panel.service.ts)

• notebookMappingKey(wid) is now the single source of truth for the cache key shared by the dashboard store step and the Jupyter panel lookup.

Behavior note

• A wid is required to open the workspace, so the workflow is created before navigation. If navigation is later blocked, the workflow is still saved and reachable from the dashboard. This is intentional so a completed generation is never lost.

Demo

pr11demo.mov

Note: a mock LLM API was used in this demo so that we don't need to wait for real-time generation. This does not affect any functionality for this PR.

Any related issues, documentation, discussions?

Closes #7360
Parent issue #4301

How was this PR tested?

Added and updated unit specs, with full line and branch coverage on the changed code:

• user-workflow.component.spec.ts
• notebook-import-modal.component.spec.ts
• workspace.component.spec.ts
• notebook-migration.service.spec.ts

Was this PR authored or co-authored using generative AI tooling?

Generated-by: Claude Code (Claude Opus 4.8)

[github-actions]

Automated Reviewer Suggestions

Based on the git blame history of the changed files, we recommend the following reviewers:

• Contributors with relevant context: @Neilk1021, @Ma77Ball, @kunwp1
  You can notify them by mentioning @Neilk1021, @Ma77Ball, @kunwp1 in a comment.

[zyratlo]

/request-review @mengw15

[Copilot]

Pull request overview

Adds dashboard-based AI notebook-to-workflow generation, persistence, notebook mapping, and one-time workspace layout.

Changes:

• Adds the dashboard entry point and generation pipeline.
• Adds a locked modal with loading status and elapsed time.
• Shares mapping keys and auto-layouts generated workflows.

Reviewed changes

Copilot reviewed 12 out of 12 changed files in this pull request and generated 4 comments.

Show a summary per file

File	Description
notebook-migration.service.ts	Adds notebook parsing, typing, and mapping-key helper.
notebook-migration.service.spec.ts	Tests parsing and storage behavior.
jupyter-panel.service.ts	Uses the shared mapping key.
workspace.component.ts	Auto-layouts generated workflows.
workspace.component.spec.ts	Tests auto-layout behavior.
notebook-import-modal.component.ts	Adds locked loading state and timer.
notebook-import-modal.component.spec.ts	Tests submission locking and timing.
notebook-import-modal.component.scss	Styles the loading overlay.
notebook-import-modal.component.html	Adds the loading UI.
user-workflow.component.ts	Implements dashboard generation and persistence.
user-workflow.component.spec.ts	Tests generation success and failures.
user-workflow.component.html	Adds the AI-generation toolbar button.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 89.69%. Comparing base (4afe8d4) to head (2981604).

Additional details and impacted files

@@             Coverage Diff              @@
##               main    #7601      +/-   ##
============================================
+ Coverage     89.67%   89.69%   +0.01%     
+ Complexity     4399     4395       -4     
============================================
  Files          1177     1177              
  Lines         46976    47090     +114     
  Branches       5260     5271      +11     
============================================
+ Hits          42127    42238     +111     
  Misses         3092     3092              
- Partials       1757     1760       +3     

Flag	Coverage Δ		*Carryforward flag
access-control-service	70.00% <ø> (ø)		Carriedforward from 3698d6f
agent-service	98.62% <ø> (ø)		Carriedforward from 3698d6f
amber	86.37% <ø> (-0.03%)	⬇️	Carriedforward from 3698d6f
computing-unit-managing-service	72.46% <ø> (ø)		Carriedforward from 3698d6f
config-service	77.31% <ø> (ø)		Carriedforward from 3698d6f
file-service	68.90% <ø> (ø)		Carriedforward from 3698d6f
frontend	90.73% <100.00%> (+0.06%)	⬆️
notebook-migration-service	78.89% <ø> (ø)		Carriedforward from 3698d6f
pyamber	97.57% <ø> (ø)		Carriedforward from 3698d6f
workflow-compiling-service	57.89% <ø> (ø)		Carriedforward from 3698d6f

*This pull request uses carry forward flags. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[mengw15]

Left two comments. I also checked Copilot's four independently — all four hold up and the fixes look right, including the vid pushback, since the fetch side hardcodes the same value.

[mengw15]

Both of my comments are fixed. Two follow-ups on the timeout itself.

[mengw15]

A fixed bound can't tell "stalled" from "slow": a conversion that would have finished at 11 minutes now fails, and retrying hits the same wall, so the tool is permanently unusable for that notebook rather than just slow. The cost is lopsided — too generous only means waiting longer on a real stall, too tight discards work that would have succeeded.

Worth making this configurable rather than compiled in, so a deployment can match it to its own models and notebook sizes.

[mengw15]

A timeout lands here too, and "Error while communicating with the LLM" points at the network when the request was fine and just slow — the real reason only reaches the console, so the user spends the full limit waiting and then goes off debugging connectivity.

This is the half of my earlier comment that's still open: the hang is bounded now, but the user still can't tell what happened. A distinct message on the timeout rejection would close it.