feat: add wac ai context for frontend chat

[centdix]

Summary

Add frontend AI context for Workflow-as-Code script editors so WAC TypeScript and Python editors receive the correct workflow-specific guidance instead of only the generic script prompt.

Changes

• Make the generated getWorkflowAsCodePrompt helper language-aware, selecting the TypeScript or Python WAC SDK context as appropriate.
• Thread a workflowAsCode flag from the script editor through chat, inline chat, and autocomplete prompt construction.
• Detect WAC editor context from WAC templates, auto_kind, and existing WAC code detection while avoiding flow-inline script context leaks.
• Add regression coverage for language-specific WAC prompt selection.

Test plan

• uv run --with pyyaml bash system_prompts/check-freshness.sh
• cd frontend && npm run test:unit -- src/lib/components/copilot/chat/script/wacPrompt.test.ts
• cd frontend && npm run check:fast
• cd frontend && npm run check (passes with existing unrelated warnings)

---

Generated with Claude Code

[cloudflare-workers-and-pages]

Deploying windmill with    Cloudflare Pages

Latest commit:	c38fca8
Status:	✅  Deploy successful!
Preview URL:	https://48b81205.windmill.pages.dev
Branch Preview URL:	https://workflow-code-frontend-conte.windmill.pages.dev

View logs

[claude]

Claude finished @centdix's task in 4m 51s —— View job

---

Review — PR #9021 (WAC AI context for frontend chat)

Read AGENTS.md, the full diff, and traced changeMode/sendRequest call sites that pass lang/isPreprocessor into AIChatManager. Looking only at issues the PR introduces.

Summary

This PR makes the script-editor copilot (chat, inline chat, autocomplete) WAC-aware:

• getWorkflowAsCodePrompt(language?) now selects the TS or Python WAC SDK section, returns '' for unsupported languages, and the helper is regenerated by generate.py with a matching index.d.ts.
• A workflowAsCode flag flows: ScriptEditor.workflowAsCodeAiContext → Editor.workflowAsCode/scriptEditorOptions.workflowAsCode → Autocompletor → autocompleteRequest and prepareScriptSystemMessage/prepareInlineChatSystemPrompt.
• WAC editor context is detected from the template (wac_python/wac_typescript), script.auto_kind === 'wac', or isWorkflowAsCode(code, lang), and scoped with activeModuleTab === null && WAC_CONTEXT_LANGUAGES.includes(lang) so child-module tabs don't pick it up.
• isWorkflowAsCode drops the deno branch, matching the fact that the WAC TS SDK only targets bun (WAC_TS_SDK_LANGUAGES = ['bun']).
• Adds regression tests for both prompt selection and detection.

The plumbing is consistent end-to-end and the gate against flow-inline-script context leakage holds (getScriptOptions in AIChatManager for flow rawscript modules sets options without workflowAsCode, defaulting to false).

Findings

No P0 / P1 issues found.

P2 — WAC prompt drops the per-language context (LANG_BUN / LANG_PYTHON3)

getLangContext previously returned getScriptPrompt(lang), which is SCRIPT_BASE + LANG_<LANG> + SDK_<TS|PY>. With workflowAsCode = true it now returns WORKFLOW_AS_CODE_BASE + WAC_SDK_<TS|PY> only — no LANG_BUN / LANG_PYTHON3, no SCRIPT_BASE, no SDK_TYPESCRIPT/SDK_PYTHON. frontend/src/lib/components/copilot/chat/script/core.ts:117. Worth confirming this is intentional: the WAC base is detailed enough on its own, but the AI loses generic Windmill scripting guidance (resource consumption, regular wmill/windmill-client helpers, run paths, etc.) for the same language.

P2 — changeMode heuristic for inheriting workflowAsCode

const workflowAsCode =
    options?.workflowAsCode ??
    (options?.lang ? false : (this.scriptEditorOptions?.workflowAsCode ?? false))

frontend/src/lib/components/copilot/chat/AIChatManager.svelte.ts:270-272. The "if a caller passes lang, force workflowAsCode = false" rule is what avoids the flow-inline-script leak (generateStep passes lang/isPreprocessor from the flow module). It works for current callers, but the coupling is implicit — any future caller that passes lang for a WAC scenario will silently lose the WAC context. Consider making workflowAsCode an explicit parameter in sendRequest/generateStep/changeMode rather than inferring from "did the caller override lang?". Not blocking.

Nit — WAC_PY_SDK_LANGUAGES = PY_SDK_LANGUAGES

In system_prompts/auto-generated/index.ts:17 (and the generator) the WAC Python languages alias PY_SDK_LANGUAGES. They're equal today but they're conceptually distinct (regular Python SDK vs WAC Python SDK). Easy to inline as ['python3'] to keep the two concepts independent if PY_SDK_LANGUAGES ever grows.

AGENTS.md compliance

No violations spotted — the diff is mostly TS plumbing. No $bindable(default_value) on optional props was added; the new workflowAsCode props default to false/undefined without $bindable misuse.

Test coverage

• Backend: not touched.
• Frontend pure-logic utilities: covered. wacPrompt.test.ts exercises the language-aware prompt selection and the empty-string fallback for non-Bun TS runtimes; wacToFlow.test.ts covers the deno-removal regression. The component-level plumbing (Editor → Autocompletor, ScriptEditor → AIChatManager) is not tested but matches the codebase's "no Svelte component tests" norm.
• CI / docs / config-only: system_prompts/auto-generated/* regeneration and the cli/src/guidance/skills.gen.ts snapshot match the generator output (verified by reading both); the test plan ran system_prompts/check-freshness.sh, which is the right gate.

Manual verification still worth doing before merge: open a WAC TypeScript script in the script editor and confirm the chat system prompt picks up the WAC TS guide (and not the Python one) — easiest way is to open chat from a wac_typescript template script and ask "what should taskFlow look like?". Repeat for a wac_python script. Then open one of the same scripts and switch to a child-module tab; confirm the inline AI chat falls back to the regular script context (no WAC sections), since activeModuleTab !== null should turn workflowAsCodeAiContext off. Finally, in a flow with a rawscript inline step, confirm the chat does not apply WAC context to the step.

[cubic-dev-ai]

No issues found across 18 files

[github-actions]

Codex Review

Found 1 issue:

1. [P2] frontend/src/lib/components/ScriptEditor.svelte:1243
   The new WAC AI context depends on the autoKind prop, but only ScriptBuilder.svelte passes script.auto_kind. flows/content/ScriptEditorDrawer.svelte also loads auto_kind from ScriptService.getScriptByHash() and renders a full ScriptEditor, but does not pass it through. A WAC script opened from a flow’s “edit script” drawer can therefore still get the generic script prompt when frontend code detection misses it, which is exactly the case auto_kind is meant to cover.

Test coverage

Frontend: the PR adds focused unit tests for the prompt helper and WAC detection. I attempted to run them with cd frontend && npm run test:unit -- src/lib/components/copilot/chat/script/wacPrompt.test.ts src/lib/components/graph/wacToFlow.test.ts, but this checkout does not have vitest installed, so I could not verify locally.

Manual verification should cover opening a saved Bun or Python WAC script directly and from a flow script edit drawer, then sending a chat/autocomplete request. The observable result is that both paths include the WAC-specific prompt rather than the generic script prompt.

[github-actions]

Pi Review

I've reviewed this PR (18 files, +202/−41) and found no P0 or P1 issues. The change correctly threads the workflowAsCode flag through the chat, inline chat, and autocomplete prompt construction, with appropriate guards to prevent WAC context from leaking into flow-inline script editors.

---

P2 — Duplicated WAC language list across modules

• frontend/src/lib/components/ScriptEditor.svelte:1240 — WAC_CONTEXT_LANGUAGES = ['python3', 'bun']
• system_prompts/auto-generated/index.ts:14-17 — WAC_TS_SDK_LANGUAGES / WAC_PY_SDK_LANGUAGES

These two locations independently enumerate the supported WAC languages (Bun TypeScript + Python). They serve different purposes (ScriptEditor guards whether to set the workflowAsCode AI-context flag; the prompt module selects which SDK doc to emit), but a future WAC language addition must update both. The fallback in getLangContext() (calls getScriptPrompt when getWorkflowAsCodePrompt returns '') makes this safe in practice, so it's a maintenance synchronisation note rather than a correctness issue.

---

Test coverage

• Frontend pure-logic utilities: covered. New tests in wacPrompt.test.ts validate language-specific prompt selection and the correct boundary between WAC and regular script prompts. wacToFlow.test.ts validates the narrowed isWorkflowAsCode detection (Bun-only, Python). Both are well-structured and target the surface area changed.

• Frontend components: no tests expected per codebase convention (Svelte components are not tested in this repo).

• System prompts / generate.py: the auto-generated output is tested indirectly via the check-freshness.sh script (noted in the PR test plan) and the wacPrompt.test.ts tests that import from $system_prompts.

Manual verification suggested before merge

• Open a WAC Python script editor (template wac_python), open the AI chat panel, and verify the system prompt includes the Python WAC SDK reference but excludes the TypeScript WAC SDK reference.
• Open a WAC Bun TypeScript script editor, repeat, and verify the TypeScript WAC SDK reference is present and the Python one is absent.
• Open a regular (non-WAC) Bun script editor, verify the AI chat does NOT include WAC context ("Windmill Workflow-as-Code Writing Guide").
• Open a flow with an inline Python script, open AI chat from that inline editor, and verify no WAC context leaks in (the system prompt should be the regular script prompt).
• In a WAC Bun editor, trigger autocomplete (code completion) and verify the Mistral context lines do not include WAC-specific guidance (since workflowAsCode defaults to false in Autocompletor when the editor prop hasn't propagated yet — verify the editor-level prop thread through).