[jonasjabari]

Ticket

https://community.openproject.org/wp/AI-100

What is this?

A demo-only prototype of the AI description assistant (AI-100, AI-126), running on the real LLM connection from the AI-3 stack. Never to be merged: the branch is the open part of the AI-3 stack (PR 7 #24885 up to PR 12 #25349; PRs 1 to 6 are on dev since 2026-09-30) plus dev plus the demo commits, so the diff shows both. AI-133 to AI-136 are on dev. Rebuilt on 2026-10-02 after the AI-3 migrations were renumbered on dev; a demo-only migration drops the LLM tables of the earlier stack once, so LLM settings entered before have to be entered again. Last synced with dev on 2026-10-23.

What it demonstrates:

• The merged AI-133 and AI-135 code (runs with an append-only event log, availability rules, streaming job with cancel and time budget) and the AI-136 run endpoints (POST /api/v3/ai_text_transform_runs, GET …/:uuid?after=<seq>, POST …/:uuid/cancel).
• AI::TextTransforms::LlmGateway, the AI-137 shape: Llm::Runtime.for(:description_assistant) with streaming, zero retries and error translation.
• An admin sandbox below every text transform action form (Administration → AI → Text transform actions → edit) that posts text, polls the run and shows the streamed result, the stored system prompt and the polled events.

Editor demo (AI-126)

Open a work package and click into the description. The "Assistant" split button at the right end of the toolbar is the real CKEditor plugin from AI-101 (opf/commonmark-ckeditor-build#131, bundle built from build-repo master plus that PR). It lists the actions the API offers for the work package (AI-134); the main part runs the last used action, the arrow opens the list.

Only the button is taken from AI-101 (#25770). The result pane is the real implementation: AI-172 from dev plus the open PR branches of AI-173 (#26091, floating behaviour) and AI-175 (#26138, endpoints), merged into this branch; the parts no ticket delivers yet (footer forms, polling, the applied wait) are demo glue until AI-175/AI-176 land. What happens after the click:

• The core AiActionsService.run(action, editor, resource) reads the selection from the editor model and posts to AI::TextTransformPanesController through turboRequests, like the wiki page link macro requests its dialog. The controller starts the run and appends the result pane (Primer::Beta::BorderBox) to the body.
• The pane polls the controller. Each answer brings the text so far, already formatted with format_text, or 204 when nothing changed. No separate markdown endpoint; the API v3 run endpoints are not used by the pane.
• Replace, close and Try again are Turbo forms. The finished text returns to the service through the dispatchEvent stream action, tied to the request by a requestId, and is applied with model.insertContent.

With text selected, only the selection is sent and replaced; otherwise the whole description. Replace keeps the editor's undo history. The pane can be dragged and resized from four handles. Append ?ai_demo_fault=blocked or ?ai_demo_fault=failed to the page URL to see the "stopped" and "failed" states.

Try it in the PullPreview

1. Administration → AI → LLM connection: base URL including the version segment (e.g. https://…/v1), API key, save, sync models, enable. If the gateway's models are missing from the list, add them by hand.
2. AI models: bind a chat model to "Description assistant" or set a default chat model.
3. Text transform actions: switch the assistant on, activate an action, open it and use the sandbox at the bottom. "Save and stay" keeps the sandbox state while editing the prompt.

Findings for AI-3 while building this (found on the stack version of 2026-09-09, not re-checked against the rewrite)

• Llm::Session sends instructions with the developer role; OpenAI-compatible gateways drop it silently, so the whole system prompt is lost. Patched here with openai_use_system_role = true.
• For api_format: openrouter the model list is registry-backed, not fetched from the server; a bound model may not exist on the gateway.
• The base URL must contain the version segment; without it completions hit /chat/completions and 404.
• The gateway's GET /v1/models returns a bare JSON array, not the OpenAI { "data": [...] } envelope, which blocked saving the connection. Fixed upstream in [AI-3] Discover the embedding models OpenRouter serves separately #25349; the demo-only patch is gone.

The real implementation lands as AI-133 to AI-137.

🤖 Generated with Claude Code

[github-actions]

Deploying openproject with ⚡ PullPreview

Field	Value
Latest commit	e289c77
Job	deploy
Status	✅ Deploy successful
Preview URL	https://pr-25245-ai-100-prototype-pu-ip-78-47-93-79.my.opf.run:443

View logs

[jonasjabari]

Bildschirmaufnahme.2026-09-10.um.17.47.03.mov

[github-actions]

Warning

Flaky specs

• rspec ./spec/features/notifications/navigation_spec.rb[1:1:1]

🤖 Ask Copilot to investigate

Copy the prompt below into a new comment on this PR to delegate the investigation to GitHub Copilot. It will look into the flakiness and open a separate pull request with you as reviewer.

@copilot The following spec(s) are flaky in CI (first seen on PR #25245, linked for reference only):

- `rspec ./spec/features/notifications/navigation_spec.rb[1:1:1]`

Treat this as a standalone task, unrelated to PR #25245. Create a new branch from origin/dev and open a new pull request targeting dev — do not stack it on PR #25245 or reuse that branch.

Follow the playbook in docs/development/testing/handling-flaky-tests/README.md to find the root cause and fix the underlying race — do not skip, delete, or weaken the spec to make it pass; disabling is a last resort per the playbook, and only with a bug ticket. Verify the fix by running the spec(s) repeatedly (e.g. `script/bulk_run_rspec --run-count 10`).

If you cannot reproduce the flake or are not confident in a fix after reasonable investigation, do not fabricate a change or skip the spec to force CI green. Instead, leave the pull request in draft and document what you tried, the suspected cause, and any leads in its description, then assign @jonasjabari to take over.

Once the fix is verified, title the PR after the spec(s) it fixes, and use the PR description to explain the root cause, how the change resolves it, and the before/after results. Label the PR `flaky-spec`, assign @jonasjabari, and request a review from @jonasjabari.
On every commit, set @jonasjabari as the sole co-author with a `Co-authored-by:` trailer (use their GitHub no-reply email so it links to their account), so it is traceable who dispatched the fix.

[github-actions]

Warning

Flaky specs

• rspec ./modules/reporting/spec/features/work_package_costlog_spec.rb[1:1:1]

🤖 Ask Copilot to investigate

Copy the prompt below into a new comment on this PR to delegate the investigation to GitHub Copilot. It will look into the flakiness and open a separate pull request with you as reviewer.

@copilot The following spec(s) are flaky in CI (first seen on PR #25245, linked for reference only):

- `rspec ./modules/reporting/spec/features/work_package_costlog_spec.rb[1:1:1]`

Treat this as a standalone task, unrelated to PR #25245. Create a new branch from origin/dev and open a new pull request targeting dev — do not stack it on PR #25245 or reuse that branch.

Follow the playbook in docs/development/testing/handling-flaky-tests/README.md to find the root cause and fix the underlying race — do not skip, delete, or weaken the spec to make it pass; disabling is a last resort per the playbook, and only with a bug ticket. Verify the fix by running the spec(s) repeatedly (e.g. `script/bulk_run_rspec --run-count 10`).

If you cannot reproduce the flake or are not confident in a fix after reasonable investigation, do not fabricate a change or skip the spec to force CI green. Instead, leave the pull request in draft and document what you tried, the suspected cause, and any leads in its description, then assign @jonasjabari to take over.

Once the fix is verified, title the PR after the spec(s) it fixes, and use the PR description to explain the root cause, how the change resolves it, and the before/after results. Label the PR `flaky-spec`, assign @jonasjabari, and request a review from @jonasjabari.
On every commit, set @jonasjabari as the sole co-author with a `Co-authored-by:` trailer (use their GitHub no-reply email so it links to their account), so it is traceable who dispatched the fix.

[github-actions]

Warning

Flaky specs

• rspec ./modules/gantt/spec/features/timeline/timeline_dates_spec.rb[1:2:1]

🤖 Ask Copilot to investigate

Copy the prompt below into a new comment on this PR to delegate the investigation to GitHub Copilot. It will look into the flakiness and open a separate pull request with you as reviewer.

@copilot The following spec(s) are flaky in CI (first seen on PR #25245, linked for reference only):

- `rspec ./modules/gantt/spec/features/timeline/timeline_dates_spec.rb[1:2:1]`

Treat this as a standalone task, unrelated to PR #25245. Create a new branch from origin/dev and open a new pull request targeting dev — do not stack it on PR #25245 or reuse that branch.

Follow the playbook in docs/development/testing/handling-flaky-tests/README.md to find the root cause and fix the underlying race — do not skip, delete, or weaken the spec to make it pass; disabling is a last resort per the playbook, and only with a bug ticket. Verify the fix by running the spec(s) repeatedly (e.g. `script/bulk_run_rspec --run-count 10`).

If you cannot reproduce the flake or are not confident in a fix after reasonable investigation, do not fabricate a change or skip the spec to force CI green. Instead, leave the pull request in draft and document what you tried, the suspected cause, and any leads in its description, then assign @jonasjabari to take over.

Once the fix is verified, title the PR after the spec(s) it fixes, and use the PR description to explain the root cause, how the change resolves it, and the before/after results. Label the PR `flaky-spec`, assign @jonasjabari, and request a review from @jonasjabari.
On every commit, set @jonasjabari as the sole co-author with a `Co-authored-by:` trailer (use their GitHub no-reply email so it links to their account), so it is traceable who dispatched the fix.