Problem
The wordpress_site_plan form contract represents the Busy Bears Wix country selector as an auxiliary button plus a phone control. It retains enough semantics for SSI to set Jetpack showCountrySelector, but does not carry the source selector's visible presentation payload (the generic globe SVG, 24 x 24, before the 16 x 16 chevron).
The Jetpack adapter must not invent that glyph. Its built-in unselected state renders only its chevron, so the rendered selector collapses to 18 x 3.594px instead of the source's 40 x 24px selector. This also shifts the phone input left and prevents visual parity.
Evidence
- Retained source and public
/contact: button[data-hook="country-selector-trigger"] contains a 24 x 24 inline globe SVG and 16 x 16 chevron; source shell is 294 x 42 at 390px.
- Materialized WordPress
/contact and /get-a-quote: SSI emits showCountrySelector: "1"; Jetpack exposes 239 country options per responsive instance, but the unselected trigger contains only its built-in 10 x 6 chevron and measures 18 x 3.594px.
- The source HTML has no selected country/default ISO value to map to Jetpack's flag API.
- SSI's current provider destination map only accepts captured CSS facts. A source SVG/icon payload cannot be represented there without inventing a provider-specific asset.
Requested contract
Extend the generic form presentation/topology contract so an auxiliary country-selector control can carry a safe, provider-neutral visible presentation payload (including its SVG/icon and intrinsic dimensions), associated with the auxiliary control rather than the telephone value input. SSI can then map that payload to a provider-owned prefix destination through its existing adapter boundary.
This should be generic to composite form controls, not Wix- or Busy Bears-specific. It is adjacent to, but not solved by, the closed safe-inline-SVG conversion issue #53: the SVG is preserved in source HTML but is lost when the HTML form is reduced to the wordpress_site_plan form representation.
AI assistance: OpenAI gpt-5.6-terra via OpenCode investigated the source and imported phone controls and drafted this issue under OpenAI gpt-6-astra/OpenCode orchestration. The proposed contract needs implementation and end-to-end validation; no fix is claimed by this issue.
Problem
The
wordpress_site_planform contract represents the Busy Bears Wix country selector as an auxiliary button plus aphonecontrol. It retains enough semantics for SSI to set JetpackshowCountrySelector, but does not carry the source selector's visible presentation payload (the generic globe SVG, 24 x 24, before the 16 x 16 chevron).The Jetpack adapter must not invent that glyph. Its built-in unselected state renders only its chevron, so the rendered selector collapses to 18 x 3.594px instead of the source's 40 x 24px selector. This also shifts the phone input left and prevents visual parity.
Evidence
/contact:button[data-hook="country-selector-trigger"]contains a 24 x 24 inline globe SVG and 16 x 16 chevron; source shell is 294 x 42 at 390px./contactand/get-a-quote: SSI emitsshowCountrySelector: "1"; Jetpack exposes 239 country options per responsive instance, but the unselected trigger contains only its built-in 10 x 6 chevron and measures 18 x 3.594px.Requested contract
Extend the generic form presentation/topology contract so an auxiliary country-selector control can carry a safe, provider-neutral visible presentation payload (including its SVG/icon and intrinsic dimensions), associated with the auxiliary control rather than the telephone value input. SSI can then map that payload to a provider-owned prefix destination through its existing adapter boundary.
This should be generic to composite form controls, not Wix- or Busy Bears-specific. It is adjacent to, but not solved by, the closed safe-inline-SVG conversion issue #53: the SVG is preserved in source HTML but is lost when the HTML form is reduced to the
wordpress_site_planform representation.AI assistance: OpenAI gpt-5.6-terra via OpenCode investigated the source and imported phone controls and drafted this issue under OpenAI gpt-6-astra/OpenCode orchestration. The proposed contract needs implementation and end-to-end validation; no fix is claimed by this issue.