Skip to content

fix(remote-components): resolve the model through an AI capability - #5805

Merged
adrians5j merged 1 commit into
nextfrom
claude/remote-components-capability
Sep 28, 2026
Merged

adrians5j merged 1 commit into
nextfrom
claude/remote-components-capability

Conversation

@adrians5j

@adrians5j adrians5j commented Sep 28, 2026 •

Copy link
Copy Markdown
Member

Problem

Component generation and refinement read their model from settings.providers.presets[0], which is the settings shape #5691 replaced with connections, model roles and capabilities. The as any on the settings object is why the compiler never flagged it.

The feature kept working only for projects configured before #5691, because the legacy providers section still round-trips through storage. A project set up the new way got "No AI provider configured" even with a model configured.

Change

Both use cases now resolve a new wb.generateComponent capability through ResolveAiCapabilityUseCase, the same way the admin assistant and entry generation do. That brings three things:

  • The model comes from the model roles screen, and a project can point component generation at a different model or append instructions, like every other AI feature.
  • The connection and API key arrive resolved, so the use cases no longer decrypt a key themselves.
  • Component generation gets its own row under Settings → AI Power-Ups.

Some choices a reviewer may want to question:

  • One capability for generate and refine. They do the same job against the same output contract that parseGeneratedSource reads. Two settings rows would only let them drift apart.
  • No guidance. Each use case builds its own prompt and passes it to withAdditionalInstructions, the same approach entry generation uses.
  • Default role standard. This matches entry generation, which also takes optional image attachments. Writing working component code is where small models struggle.
  • The resolver is an optional dependency. The ai-powerups extension asks this of outside callers, because nothing in AI Power-Ups is registered when it is off. The use cases return a message saying that instead of failing at DI resolution. A resolver failure is passed through unchanged because it already names the setting to fix.

Testing

  • New packages/remote-components/__tests__/componentCapability.test.ts has six tests. They cover the model and connection coming from the capability, the project's instructions reaching the system prompt, resolver failures passing through, and the path with AI Power-Ups off, for both generate and refine. The fake AI returns a response the parser accepts, so a request assertion can't pass while the use case fails afterwards.
  • The prompt test was checked by reverting to the uncomposed prompt: it failed.
  • Build, lint and adio are clean. 16 tests pass in the package.

Not verified in a browser. Remote components aren't mounted in the monorepo's local webiny.config.tsx: the project never renders <RemoteComponents />, and its remoteComponents: true sits at the top level instead of under aiPowerups, where the schema ignores it. That config is unrelated to this change and I left it alone.

Workspace: wby-next1 · ✨ AI CHAT

🤖 Generated with Claude Code

Summary by CodeRabbit

  • New Features
    • Generate and refine Website Builder components using AI Power-Ups. Component creation and refinement now use the selected AI capability and its configured model and connection, along with applicable capability instructions.
    • If AI Power-Ups are unavailable or the required capability cannot be resolved, component generation and refinement return an error.

Component generation and refinement still read the model from
settings.providers.presets[0], the path #5691 replaced with connections, model
roles and capabilities. The `as any` on the settings kept the compiler from
saying so. It kept working only for projects configured before #5691, because
the legacy providers section still round-trips through storage; a project set
up the new way got "No AI provider configured" with a model configured.

Both use cases now resolve wb.generateComponent through
ResolveAiCapabilityUseCase, the way the admin assistant and entry generation
do. That also puts component generation on the model roles screen, so a
project can choose its model and append instructions like any other AI
feature, and the connection and API key come resolved instead of being
decrypted here.

One capability covers generate and refine. They do the same job against the
same output contract, and two settings rows would only invite them to drift.
It declares no guidance: each use case builds its own prompt and passes it to
withAdditionalInstructions. The default role is standard, matching entry
generation, which also takes optional image attachments.

The resolver is an optional dependency, as the ai-powerups extension asks of
external callers, since nothing in AI Power-Ups is registered when it is off.
The use cases say so instead of failing at DI resolution. A resolver failure is
passed through unchanged because it already names the setting to fix.

Tests cover the model and connection coming from the capability, the project's
instructions reaching the system prompt, resolver failures passing through, and
the AI Power-Ups-absent path, for both use cases. The prompt test was checked
by reverting the composed prompt and watching it fail.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
@github-actions

Copy link
Copy Markdown

🚓 Slop Cop

✅ Nothing worth flagging. The diff looks consistent with the PR's stated intent and the code-style rules.

Focused, coherent PR: switches two use cases from the legacy settings shape to the new AI capability resolver, matching the stated fix; no footprint mismatch, no secrets/debug leftovers, and no style-rule violations found in the added/changed lines.

Automated, non-blocking heads-up from an LLM. It can be wrong — use your judgment. Regenerates on every push.

@coderabbitai

coderabbitai Bot commented Sep 28, 2026 •

Copy link
Copy Markdown

Review in Change Stack →

Navigate logical layers of code changes, visualize relationships, and explore their blast radius.

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info
⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Advanced

Run ID: f8e506ea-02ae-4d4d-9b3f-0048a0b53899

📥 Commits

Reviewing files that changed from the base of the PR and between 697feaa and 8f16939.

📒 Files selected for processing (5)
  • packages/remote-components/__tests__/componentCapability.test.ts
  • packages/remote-components/src/api/Extension.ts
  • packages/remote-components/src/api/capability.ts
  • packages/remote-components/src/api/features/generateComponent/GenerateRemoteComponentUseCase.ts
  • packages/remote-components/src/api/features/refineComponent/RefineRemoteComponentUseCase.ts

Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 6 remain after this review.


📝 Walkthrough

Walkthrough

The extension registers a component-generation AI capability. The generation and refinement use cases resolve that capability for their model and connection, and include capability instructions in their prompts. Tests cover successful resolution and cases where the resolver is unavailable or returns an error.

Changes

Remote component AI

Layer / File(s) Summary
Define and register the component capability
packages/remote-components/src/api/capability.ts, packages/remote-components/src/api/Extension.ts
The package defines the wb.generateComponent capability and registers it with the extension.
Use the capability for generation and refinement
packages/remote-components/src/api/features/generateComponent/GenerateRemoteComponentUseCase.ts, packages/remote-components/src/api/features/refineComponent/RefineRemoteComponentUseCase.ts, packages/remote-components/__tests__/componentCapability.test.ts
Both use cases resolve the capability and use its model, connection, and additional instructions. Tests check successful resolution, resolver errors, and unavailable-resolver cases.

Priority: ⬇️ Low

Estimated code review effort: 3 (Moderate) | ~20 minutes

Change: Bug fix

Sequence Diagram(s)

sequenceDiagram
  participant Remote component use case
  participant ResolveAiCapabilityUseCase
  participant AI
  Remote component use case->>ResolveAiCapabilityUseCase: resolve REMOTE_COMPONENT_CAPABILITY
  ResolveAiCapabilityUseCase-->>Remote component use case: model, connection, and additional instructions
  Remote component use case->>AI: send prompt with resolved model and connection
Loading

Merge Risk: ⚪ Minimal · up to 8f169

Component generation and refinement use the configured capability, with a defined response when AI Power-Ups is disabled. No issue identified here prevents merging after normal checks.

Security Architecture Review

Security architecture risk: 🔵 Low · up to 8f169

The change moves credential selection behind configuration checks rather than adding a caller-selected credential. Component content can now go to a different configured model. Authorization and file ownership could not be fully verified, so the risk is not assessed as minimal.

Retained concerns
No architecture-level concerns identified.

Security review details

Security Blast Radius

  • inferred — Component prompts, source being refined, and successfully resolved reference images can be sent to a project-configured model connection rather than only the first legacy provider. The evidence does not establish an expansion beyond that configured destination.

Trust Boundaries and Controls

  • observed — The generation task is marked private, but its handler forwards supplied file IDs without a visible ownership check. Inspected file-content implementations look up bytes by file ID without an identity argument. These paths predate the changed capability selection; dispatch enforcement and tenant scoping remain unverified.

Hardening Proposals

  • proposed — Verify that private-task dispatch, settings access, and file-content lookup enforce the same project boundary before treating reference-image handling as tenant-isolated. This is a check on an unresolved existing boundary, not an established PR-introduced finding.
🚥 Pre-merge checks | ✅ 5
✅ Passed checks (5 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title clearly describes the main change: remote components now resolve the model through an AI capability.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 5…
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.
✨ Finishing Touches
📝 Generate docstrings
  • Commit to this branch
  • Create a new PR
🧪 Generate unit tests (beta)
  • Commit to this branch
  • Create a new PR

Comment @coderabbitai help to get the list of available commands.

@adrians5j
adrians5j merged commit 04f5b59 into next Sep 28, 2026
19 checks passed
@adrians5j
adrians5j deleted the claude/remote-components-capability branch September 28, 2026 13:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant