feat: Add opt-in AI Chat Assistant dock panel (OpenAI-compatible API)

[Vickyrrrrrr]

What this PR does

Adds an AI Chat Assistant as an optional, dockable panel inside CQ-editor.
Users can describe what they want to model in plain English, receive valid
CadQuery code from any OpenAI-compatible LLM, and insert it directly into
the editor — all without leaving the app.

Motivation

CadQuery is powerful but has a steep learning curve for new users. An
in-editor AI assistant lowers that barrier significantly: instead of
looking up API docs, users can describe intent ("make a box with filleted
edges") and get runnable code instantly. Power users benefit too — they
can ask the AI to iterate on an existing model using the current script
as context.

Changes

cq_editor/widgets/ai_chat.py (new file)

• AIChatWidget — dockable QWidget, integrates like any existing panel
• Chat history with colour-coded roles (You / AI / Error)
• Context injection: current editor script is prepended to every prompt
  so the LLM edits the existing model rather than starting from scratch
• Async LLM calls via QThread — UI never freezes
• Insert & Run button: extracts code from reply, pushes to editor,
  optionally triggers an immediate re-render
• preferences Parameter tree: Enabled, Provider URL, Model, API Key,
  Auto-run — appears under Edit → Preferences → AI Assistant

cq_editor/main_window.py (minimal, additive changes only)

• Register AIChatWidget as a dock panel (right side, default)
• Wire insert_code signal → editor.set_text
• Add AI Assistant toggle under Tools menu

How to use

1. pip install openai
2. Edit → Preferences → AI Assistant → enter API Key + Model
3. Tools → AI Assistant
4. Type a prompt, click Insert & Run

Works with OpenAI, Anthropic (via OpenRouter), local Ollama, or any
OpenAI-compatible endpoint via the Provider URL field.

Compatibility

• openai is optional — guarded by try/except ImportError; CQ-editor
  starts normally without it
• Zero changes to existing behaviour or existing widgets
• All new logic is self-contained in ai_chat.py

Testing

• CQ-editor launches normally with and without openai installed
• Panel docks, undocks, and toggles via View menu
• Preferences save and restore across sessions
• Context injection sends current script to LLM
• Insert & Run loads code into editor and triggers re-render
• Tested with OpenAI (gpt-4o, o3) and OpenRouter

Future work (follow-up PRs)

• Streaming token-by-token response display
• Diff-based code patching instead of full replace
• Auto-fix: feed traceback back to LLM on render error

[jmwright]

Claude Code Review

---

Correctness / Bugs

1. Enabled preference does nothing. preferences has an "Enabled": bool child, but nowhere in the code is it ever read. The panel is unconditionally registered and instantiated regardless of that setting. Either wire it up or
   remove it — right now it's misleading UI.

2. _toggle_ai_panel calls raise_() after hide(). Calling raise_() on a widget that was just hidden makes it visible again. The hide branch should not call raise_().

3. Bare code fallback in _on_response is dangerous. When no fenced code block is found, the entire raw reply is treated as code and loaded into the editor on "Insert & Run". An explanatory error message from the LLM gets inserted
   verbatim into the script.

4. import re inside _extract_code. This import belongs at the top of the module.

5. QAction keyword arguments. The QAction("🤖 AI Assistant", self, triggered=..., toolTip=...) form may not work in all PyQt5 versions. Connect the signal and set the tooltip explicitly after construction.

---

Safety / Privacy

6. API key stored in plaintext preferences. There is no use of keyring or any secure storage. The tooltip reassures users the key is "not sent anywhere else," but it will be written to a plaintext config file on disk. At minimum
   this should be documented prominently; ideally use the system keychain.

7. User code is silently sent to an external API. Every prompt includes the full current script via _inject_context. There is no confirmation dialog, no opt-in warning on first use, and no indication in the UI that code is leaving
   the machine. This is a meaningful privacy/data concern for commercial or proprietary models.

---

Resource / Thread Safety

8. No closeEvent cleanup. If the widget is destroyed while _thread is running (e.g., the user closes CQ-editor mid-request), the thread and worker are not stopped. The worker's signals will fire into a deleted widget. Add a
   closeEvent (or __del__) that calls _thread.quit() / _thread.wait().

9. Context grows unbounded. _history accumulates the full conversation, and _inject_context prepends the entire current script on every user turn. Long sessions with large scripts will send very large payloads and incur
   unnecessary token cost.

---

Architecture

10. from .widgets.ai_chat import AIChatWidget is unconditional. The PR description says the feature is "guarded by try/except ImportError," but the module is always imported by main_window.py. The openai package import is lazy
    (inside _LLMWorker.run), which is correct — but the whole widget class is always loaded. The description is misleading.

11. preferences is a class-level variable. This works fine for a singleton, but it's an unusual pattern that will silently misbehave if two instances are ever created (shared state). The registration pattern used by other widgets
    should be followed.

12. Direct _editor / _debugger attribute assignment post-construction. Passing editor=None, debugger=None then immediately setting them via attribute access in prepare_actions is fragile. Pass them properly through the
    constructor or a dedicated set_dependencies() method.

---

Missing

• No tests of any kind.
• No entry in requirements.txt or setup.cfg for the optional openai dependency (even as an extras group).

[Vickyrrrrrr]

Thanks , agreed on the main points. I’ll fix the enabled toggle, remove the unsafe raw-reply fallback, move the regex import, make QAction creation explicit, and clean up dock visibility handling.
I also agree the privacy story is too weak: I’ll add a clear disclosure that editor code is sent to the configured API, and I’ll switch API key storage to system keyring if possible, or at minimum document the plaintext behavior prominently.
I’ll also add thread cleanup in closeEvent, bound the history/context size, and include tests for the AI widget behavior.

[Vickyrrrrrr]

do give a try sir use good models . just imagine : )

[jmwright]

Is this linter ignore needed?

[Vickyrrrrrr]

Good point, the linter ignore was not needed here. I changed the handler to catch openai.OpenAIError specifically and removed the noqa.

[jmwright]

@Vickyrrrrrr The lint check is failing (tests are still running as I post this). I haven't tried forcing an LLM to be compliant with a specific linter yet, so I am interested how that will work for you.

I created an LLM skill to help overcome common errors LLMs make when trying to write idiomatic CadQuery code. The repo has a Modelfile with a streamlined system prompt that may be useful here.

A higher-level design decision that Claude Code flagged to be aware of:

The auto-fix path sets _auto_insert_flag = True, which means when triggered from the traceback pane, AI-generated code is automatically inserted and run without a confirmation step. That's the intended feature, but it's a prompt-injection surface — if someone could manipulate what goes into the error message or control the API endpoint's responses, they could cause arbitrary code to execute. Not a backdoor, just a design tradeoff you should be aware of.

I will take a closer look at this and try the feature out once CI is passing.

Thanks

[Vickyrrrrrr]

@Vickyrrrrrr The lint check is failing (tests are still running as I post this). I haven't tried forcing an LLM to be compliant with a specific linter yet, so I am interested how that will work for you.

I created an LLM skill to help overcome common errors LLMs make when trying to write idiomatic CadQuery code. The repo has a Modelfile with a streamlined system prompt that may be useful here.

A higher-level design decision that Claude Code flagged to be aware of:

The auto-fix path sets _auto_insert_flag = True, which means when triggered from the traceback pane, AI-generated code is automatically inserted and run without a confirmation step. That's the intended feature, but it's a prompt-injection surface — if someone could manipulate what goes into the error message or control the API endpoint's responses, they could cause arbitrary code to execute. Not a backdoor, just a design tradeoff you should be aware of.

I will take a closer look at this and try the feature out once CI is passing.

Thanks

Damn , this will be very helpfulll . If the current pr merged i will try to implement more features . Me and Codex both won't trouble you much sir . : )