# Page Editor SSR Coverage Audit

## Scope
This audit compares section types available in the admin canvas and customer DynamicPage renderer against explicit PHP SSR renderers in `includes/Frontend/PageSSR.php`.

## Coverage Matrix
| Section type | Admin canvas | Customer SPA | PHP SSR | Status |
|---|---:|---:|---:|---|
| `hero` | yes | yes | `render_hero` | covered |
| `content` | yes | yes | `render_content` | covered |
| `image-text` | yes | yes | `render_image_text` | covered |
| `feature-grid` | yes | yes | `render_feature_grid` | covered, now reads `items` with `features` fallback |
| `cta-banner` | yes | yes | `render_cta_banner` | covered |
| `contact-form` | yes | yes | `render_contact_form` | covered for SEO structure only |
| `bento-category-grid` | yes | yes | `render_bento_category_grid` | covered |
| `product-carousel` | yes | yes | `render_product_carousel` | covered for configured/static product data |
| `shoppable-image` | yes | yes | `render_shoppable_image` | covered |
| `marquee-banner` | yes | yes | `render_marquee_banner` | covered |

## Immediate Finding
The SSR path now has explicit renderers for all section types exposed by the editor canvas. The next gap is deeper content parity for sections that rely on runtime API data, especially product carousel data loading.

## Next Implementation Targets
1. Add product data resolution for `product-carousel` when SSR runs without pre-resolved products.
2. Add parity fixtures covering one scalar-heavy section and one repeater-heavy section.
3. Add snapshot tests comparing React content output vs SSR content output.