16 — CMS Content Type (Element Type)

Create the Umbraco Element Type that backs a frontend module.
This is Phase C of the module lifecycle — done AFTER frontend implementation.
Every module (static or interactive) needs an Element Type for CMS integration.

---

Context Loading

Read these files before executing the prompt:

docs/dev-backend-guides/01_UMBRACO_CONTENT_MODELING.md
docs/PRD/06_Content_Modeling_Umbraco.md
docs/PRD/07_Modules_and_Templates.md
docs/dev-frontend-guides/03_MODULE_DEVELOPMENT_LIFECYCLE.md

---

Prompt Template

Read the following context files first:
- docs/dev-backend-guides/01_UMBRACO_CONTENT_MODELING.md
- docs/PRD/06_Content_Modeling_Umbraco.md
- docs/PRD/07_Modules_and_Templates.md
- docs/dev-frontend-guides/03_MODULE_DEVELOPMENT_LIFECYCLE.md

Now define the Umbraco Element Type for the following module:

**Module ID:** M{MODULE_NUMBER}
**Module Name:** {MODULE_NAME}
**Element Type Alias:** {UMBRACO_ALIAS}
**Figma Reference:** {FIGMA_URL}

**Description:**
{BRIEF_DESCRIPTION_OF_MODULE_PURPOSE}

**Content Properties:**
| Property | Alias | Editor | Required | Tab | Varies by Culture |
|----------|-------|--------|----------|-----|-------------------|
| {PROPERTY_NAME} | {camelCaseAlias} | {EDITOR_TYPE} | {yes/no} | {TAB_NAME} | {yes/no} |

Editor types: Textstring, Textarea, Rich Text, Numeric, Toggle, Dropdown,
Media Picker, Content Picker, URL Picker, Tags, Block List, Color Picker.

**Nested Element Types (if any):**
{LIST_ANY_CHILD_ELEMENT_TYPES — e.g., heroSlide inside heroSlider}

**Target Page Types:**
{WHICH_DOCUMENT_TYPES_ALLOW_THIS_BLOCK — e.g., homePage, contentPage}

**Block List Configuration:**
- Label template: {LABEL — e.g., "{{title}}" or "Hero Slider"}
- Inline editing: {yes/no}
- Min items: {NUMBER_OR_NONE}
- Max items: {NUMBER_OR_NONE}

Deliverables:
1. Element Type property schema table (ready for Umbraco backoffice creation)
2. Nested Element Type schemas (if any)
3. Block List configuration per target page type
4. Sample API output (expected JSON from Content Delivery API v2)
5. TypeScript interface matching the API output (for the frontend .types.ts file)

Follow these conventions:
- Aliases are camelCase and immutable once content exists
- Every image uses imageDesktop (Media Picker) + imageMobile (Media Picker)
- Text properties vary by culture (multi-language)
- Numeric, toggle, and config properties are invariant
- Group properties into Tabs: Content, Settings, Images, SEO
- Max 2 levels of Block List nesting (page → module → nested element)

---

Acceptance Criteria

• Element Type alias is camelCase and matches the frontend registry key
• All properties have correct aliases, editors, and required flags
• Properties grouped into Tabs (not just groups)
• Image properties follow imageDesktop + imageMobile pattern
• Text properties are marked as “varies by culture”
• Invariant properties (toggles, numbers) are correctly identified
• Nested Element Types defined (if applicable)
• Block List configuration specified for each target page type
• Sample API output documented (JSON structure)
• TypeScript interface matches API output and aligns with frontend .types.ts
• No property aliases conflict with existing Element Types

---

Common Pitfalls

1. Changing an alias after content exists — Aliases are immutable. Create a new property and migrate.
2. Single image field instead of desktop + mobile — Always imageDesktop + imageMobile.
3. Forgot “varies by culture” — Text properties must vary for PT/EN support.
4. Property alias doesn’t match frontend type — Coordinate with packages/modules/src/m{XX}/types.ts.
5. Block List not configured on page type — Module won’t appear in the editor until added as allowed block.
6. Nested Block Lists too deep — Max 2 levels: page → module → nested element.
7. Missing Tab grouping — Properties should be in Tabs, not loose groups.