[NakataCode]

Summary

The AI assistant treated UI5 Web Components (ui5-* custom elements) like classic sap.m controls: it invented sap.*-style APIs, guessed enum values, and had no event data. Web-component metadata the inspector had already computed was dropped before reaching the assistant's context.

Changes

System prompt

• Teach the assistant web-component vocabulary: tag, attributes, slots, events.
• Clarify that slots are the web-component equivalent of aggregations.
• State explicitly that web components have no data bindings.
• Ground the context rule in both the classic and web-component context sections, so the assistant no longer describes an unlisted property from general knowledge.

Web component context block

• Render a dedicated "Current UI5 Web Component Context" block containing:
  • Tag, Version, ID
  • Properties with manifest-resolved enum values
  • Slots instead of Aggregations
  • No Bindings section
• Forward isWebComponent, tag, and version from the panel into the assistant snapshot.

Events

• Add an Events section to the control context for both web components and classic controls (event names were never sent before).

Version normalization

• Normalize the runtime-reported version to a clean semver before it is used for:

  • the CDN manifest fetch
  • enum lookup
  • the storage key

• Multi-runtime wrapper pages can report a malformed version, e.g.:2.0.0/../../react@18.2.0

  This broke enum resolution and allowed a path-traversal-shaped string to reach a chrome.storage key.

• Normalized at the source (WebComponentsToolsAPI) and defensively at the registry boundary.

Testing

• Added an adversarial test for version normalization proving malformed input never reaches a CDN URL or storage key.

[PetyaMarkovaBogdanova]

Three things worth reviewing further though:

1. version on the displayed context vs. the enum-primed version can diverge.
   _buildWebComponentContextBlock shows control.version (already normalized at source). But webcEnumRegistry.prime() may be called with webcTree.versionInfo.version as a fallback, which goes through the registry normalizer. If the tree's primary version differs from the element's own version, the AI sees one version but enums were resolved against another. Probably harmless in practice, but worth confirming the fallback path uses the same version that's shown.

2. Slots reuse aggregation data shape.
   _renderAggregationsSection(control.aggregations, 'Slots:') assumes webcMain formats slot data in the same shape as aggregations. If slot data arrives with different nesting, the section silently emits nothing. There's no test exercising a real slot payload through the prompt builder with web component data — the PromptBuilder tests likely use hand-crafted fixtures.

3. Single-value enums are silently dropped.
   parseEnumUnion requires count >= 2. A property constrained to exactly one valid value won't be annotated as an enum. This is a deliberate guard against false positives, but it means the AI won't see enum hints for those properties.

[NakataCode]

Point 1 and 2 fixed!
About point 3 -> Agreed this is intentional and I've left it as-is. The guard only filters a single literal unioned with undefined/null; genuine single-value enums are effectively absent from the manifests, and lowering the threshold would also turn the shared dropdown into a one-option