@mmerterden/multi-agent-pipeline 8.6.2 → 10.2.0

package/pipeline/skills/figma-ios/figma-to-component/phases/phase-3d-patterns.md

@@ -1,9 +1,9 @@
-# PHASE 3D — Pattern Detection + Component Architecture + Complexity
+# PHASE 3D  -  Pattern Detection + Component Architecture + Complexity
 
 Analyze design data to detect structural patterns, design the Swift API shape, and evaluate complexity.
-This is the most critical analysis phase — its output defines the API that Phase 4 implements.
+This is the most critical analysis phase  -  its output defines the API that Phase 4 implements.
 
-required — always execute this phase.
+required  -  always execute this phase.
 PARALLEL WITH: Phase 3A, 3B, 3C, 3E, 3F (all read from pass1/ independently)
 
 ---
@@ -100,13 +100,13 @@ Same component with property-based variations.
 | Boolean toggles MULTIPLE elements | Keep `Bool`, keep content properties | `ShowHeader boolean` controls title + subtitle + icon → `showHeader: Bool` |
 | Boolean controls behavior (not visibility) | Keep `Bool` | `IsInteractive boolean` → `isInteractive: Bool` |
 
-**Rationale:** In Figma, a boolean + content slot is two properties because Figma has no optionals. In Swift, `Optional` naturally expresses "present or absent." Keeping a separate `showX: Bool` alongside the content creates redundant state — you can have `showLabel: false` but `text: "Hello"`, which is a contradiction the API shouldn't allow.
+**Rationale:** In Figma, a boolean + content slot is two properties because Figma has no optionals. In Swift, `Optional` naturally expresses "present or absent." Keeping a separate `showX: Bool` alongside the content creates redundant state  -  you can have `showLabel: false` but `text: "Hello"`, which is a contradiction the API shouldn't allow.
 
-**Apply this merge consistently** — if the icon boolean was merged into `Image?`, the label boolean must also be merged into `String?`. Same pattern, same treatment.
+**Apply this merge consistently**  -  if the icon boolean was merged into `Image?`, the label boolean must also be merged into `String?`. Same pattern, same treatment.
 
-**Cross-source merges (Figma boolean + LAYER_TEXT):** After Layer Text Classification (§1.5), re-evaluate the merge rule against the combined property set. A Figma boolean may gate a LAYER_TEXT dynamic property — if the boolean toggles visibility of that single text element, merge the boolean into the LAYER_TEXT property as `String?`. The merge rule applies identically regardless of whether the content property originated from a Figma TEXT override or from layer text classification.
+**Cross-source merges (Figma boolean + LAYER_TEXT):** After Layer Text Classification (section1.5), re-evaluate the merge rule against the combined property set. A Figma boolean may gate a LAYER_TEXT dynamic property  -  if the boolean toggles visibility of that single text element, merge the boolean into the LAYER_TEXT property as `String?`. The merge rule applies identically regardless of whether the content property originated from a Figma TEXT override or from layer text classification.
 
-**Shared-content exception:** When MULTIPLE booleans independently gate sections that share ONE content source, do NOT merge. Each boolean provides independent per-section visibility that a single optional can't express. Example: `/Money&Mil` and `+Money&Mil` both display `milesAmount` — merging would destroy the ability to show one section but not the other. Keep the booleans; the view short-circuits via `if showX, let content = sharedContent { ... }`.
+**Shared-content exception:** When MULTIPLE booleans independently gate sections that share ONE content source, do NOT merge. Each boolean provides independent per-section visibility that a single optional can't express. Example: `/Money&Mil` and `+Money&Mil` both display `milesAmount`  -  merging would destroy the ability to show one section but not the other. Keep the booleans; the view short-circuits via `if showX, let content = sharedContent { ... }`.
 
 ### 1.3 Extract Variant Examples
 
@@ -125,16 +125,16 @@ From metadata_response.xml:
 
 ### 1.5 Layer Text Classification
 
-Figma component properties capture variant axes, boolean toggles, text overrides, and instance swaps — but NOT the actual text content rendered inside layers. That layer text often contains **sample/placeholder data** that must become dynamic API parameters.
+Figma component properties capture variant axes, boolean toggles, text overrides, and instance swaps  -  but NOT the actual text content rendered inside layers. That layer text often contains **sample/placeholder data** that must become dynamic API parameters.
 
 **Procedure:**
 
 1. Extract every visible text value from `design_context_response.json` (from the generated code / layer content)
-2. Filter out texts already captured as Figma TEXT properties in `component_properties.json` — these are already handled
-3. Filter out texts that have a localization key assigned in `pass2/utility_localization.json` (read if available) — these are static labels managed by the localization system
+2. Filter out texts already captured as Figma TEXT properties in `component_properties.json`  -  these are already handled
+3. Filter out texts that have a localization key assigned in `pass2/utility_localization.json` (read if available)  -  these are static labels managed by the localization system
 4. For each remaining text, classify as STATIC or DYNAMIC using contextual reasoning
 
-**Classification — reason about the component's semantic purpose and each text's role:**
+**Classification  -  reason about the component's semantic purpose and each text's role:**
 
 | Question | If YES → |
 |----------|----------|
@@ -144,7 +144,7 @@ Figma component properties capture variant axes, boolean toggles, text overrides
 | Is this a fixed UI label describing what adjacent data represents? | STATIC |
 | Is this a structural/grammatical element (separator, connector, operator like "/" or "+")? | STATIC |
 
-**Key principle:** Reason about what the component IS FOR. A Price component displays prices — price amounts are inherently variable. A "Total Amount" label is inherently fixed — it describes the data, it IS not data. A currency code like "TRY" is variable — the same component shows USD, EUR, GBP in different contexts.
+**Key principle:** Reason about what the component IS FOR. A Price component displays prices  -  price amounts are inherently variable. A "Total Amount" label is inherently fixed  -  it describes the data, it IS not data. A currency code like "TRY" is variable  -  the same component shows USD, EUR, GBP in different contexts.
 
 **Edge cases:**
 - Currency codes/symbols (TRY, USD, €) → DYNAMIC: varies by market/context
@@ -154,8 +154,8 @@ Figma component properties capture variant axes, boolean toggles, text overrides
 - Structural operators that visually separate data ("+", "/", "·") → STATIC
 
 **For each DYNAMIC text, propose:**
-- Swift property name (camelCase, descriptive of the semantic role — e.g., `currencyCode` not `tryText`)
-- Swift type: `String` (formatting is the caller's responsibility — even for numeric data)
+- Swift property name (camelCase, descriptive of the semantic role  -  e.g., `currencyCode` not `tryText`)
+- Swift type: `String` (formatting is the caller's responsibility  -  even for numeric data)
 - Whether required or optional (based on whether the element's parent section is boolean-gated)
 
 **Output:** Include classification in `04_patterns.md` (Layer Text Classification table) and carry DYNAMIC entries into GATE 2 as additional API properties.
@@ -169,11 +169,11 @@ When Layer Text Classification identifies a **currency code + numeric amount** p
 **Detection:** Two adjacent DYNAMIC texts where one is a currency code (3-letter ISO 4217 or known symbol) and the other is a numeric amount. Also triggered when a nested `Price` component instance is detected.
 
 **Rules:**
-- Define a **nested `Price` struct** conforming to `PriceRepresentable` — include ONLY the properties this component needs (amount + currency at minimum)
-- The amount parameter type MUST be `Double`, NOT `String` — formatting is handled by `toConfiguration()` → `CurrencyAmountFormatter` at render time
-- Do NOT flatten price fields into the parent Configuration — keep them grouped in the nested `Price` type
+- Define a **nested `Price` struct** conforming to `PriceRepresentable`  -  include ONLY the properties this component needs (amount + currency at minimum)
+- The amount parameter type MUST be `Double`, NOT `String`  -  formatting is handled by `toConfiguration()` → `CurrencyAmountFormatter` at render time
+- Do NOT flatten price fields into the parent Configuration  -  keep them grouped in the nested `Price` type
 - The view uses `Price(priceModel)` for standalone price display or `CurrencyTextRenderer` for inline attributed text
-- Do NOT hardcode currency placement (left/right) — `CurrencyFormatProvider` determines this from the currency code
+- Do NOT hardcode currency placement (left/right)  -  `CurrencyFormatProvider` determines this from the currency code
 
 **Additional price properties to check for in the design:**
 - Strikethrough/original price → `originalAmount: Double?`
@@ -182,11 +182,11 @@ When Layer Text Classification identifies a **currency code + numeric amount** p
 - Green/red coloring with +/- prefix → `sign: PriceSign?`
 
 **Architecture output:** When a price pattern is detected, the property coverage should list:
-- `price: ComponentName.Price` (PRICE_PATTERN, IMPLEMENT) — nested `PriceRepresentable` conformance
+- `price: ComponentName.Price` (PRICE_PATTERN, IMPLEMENT)  -  nested `PriceRepresentable` conformance
 
 ### 1.5.1b Inline Price in Attributed Text
 
-When a **price pattern** (§1.5.1) appears **inside a text element** alongside static surrounding text (e.g., "TRY 10.000 dan başlayan fiyatlarla"), this is an **inline price attributed text pattern**.
+When a **price pattern** (section1.5.1) appears **inside a text element** alongside static surrounding text (e.g., "TRY 10.000 dan başlayan fiyatlarla"), this is an **inline price attributed text pattern**.
 
 **Detection:** A DYNAMIC price (currency + amount) adjacent to STATIC text within the same visual text block, where the price portion has different typography (bold, larger) than the surrounding text.
 
@@ -212,25 +212,25 @@ When a **price pattern** (§1.5.1) appears **inside a text element** alongside s
   ```
 
 **Architecture output:** When an inline price attributed text pattern is detected, the property coverage should list:
-- `price: ComponentName.Price` (PRICE_PATTERN, IMPLEMENT) — nested `PriceRepresentable` conformance
-- Note in patterns output: "Inline price in attributed text — use `price.attributedString(style:)` with `AttributedString.format()`"
+- `price: ComponentName.Price` (PRICE_PATTERN, IMPLEMENT)  -  nested `PriceRepresentable` conformance
+- Note in patterns output: "Inline price in attributed text  -  use `price.attributedString(style:)` with `AttributedString.format()`"
 
-**This pattern must be explicitly confirmed during analysis.** If a price appears near text, ask: is this a standalone `Price` view + separate `Text`, or a single attributed string combining both? Check the Figma layer structure — if the price and surrounding text are in the same text layer with different font styles, it's inline attributed text.
+**This pattern must be explicitly confirmed during analysis.** If a price appears near text, ask: is this a standalone `Price` view + separate `Text`, or a single attributed string combining both? Check the Figma layer structure  -  if the price and surrounding text are in the same text layer with different font styles, it's inline attributed text.
 
 ### 1.5.1a Attributed Text Pattern (Multi-Font Text)
 
 **Detection during Layer Text Classification:** When examining text elements in `design_context_response.json`, look for text where the generated code has multiple sibling `<span>` tags with different `font-family` or `font-weight` classes. Each distinct style run within a single text element indicates a multi-font attributed text pattern.
 
-**Classify each style run independently** using the same DYNAMIC/STATIC rules from §1.5 — a highlighted portion may be a dynamic prop (varies per instance) OR a static localization key (fixed but styled differently).
+**Classify each style run independently** using the same DYNAMIC/STATIC rules from section1.5  -  a highlighted portion may be a dynamic prop (varies per instance) OR a static localization key (fixed but styled differently).
 
 **Rules:**
 - The surrounding text → localization format key with `%@` placeholders
 - Each differently-styled portion → classify as DYNAMIC (`String` prop) or STATIC (its own localization key)
-- Render using `AttributedString.format()` from `UIExtensions` — template gets base styling, each `%@` argument gets its own styling
+- Render using `AttributedString.format()` from `UIExtensions`  -  template gets base styling, each `%@` argument gets its own styling
 
 ### 1.5.3 Form Pattern Detection
 
-When Sub-Component analysis identifies embedded instances of form-capable design-system components — **Selectbox, Checkbox, CheckboxButton, Radio, RadioButton, TextboxTextarea, DatepickerSchedule** — this is a **form pattern**.
+When Sub-Component analysis identifies embedded instances of form-capable design-system components  -  **Selectbox, Checkbox, CheckboxButton, Radio, RadioButton, TextboxTextarea, DatepickerSchedule**  -  this is a **form pattern**.
 
 **IMPORTANT:** When a form pattern is detected, read the `/figma-form-integration` skill instructions at `.instructions/figma/figma-form-integration/SKILL.md` for the full integration guide.
 
@@ -240,10 +240,10 @@ When Sub-Component analysis identifies embedded instances of form-capable design
 - 2+ → **composite form**: nested `Section: FormSection` class declared in an extension on the component namespace, owned via Configuration.
 
 **Rules:**
-- Every form input MUST be modeled as a `*FormField` subclass — no `Binding<Value>`, no `@State` values, no ad-hoc `isChecked: Bool` / `selectedOption` properties.
-- The caller (scene view-model) constructs fields and rules. The component is headless — it never instantiates fields and never calls `validate()`.
+- Every form input MUST be modeled as a `*FormField` subclass  -  no `Binding<Value>`, no `@State` values, no ad-hoc `isChecked: Bool` / `selectedOption` properties.
+- The caller (scene view-model) constructs fields and rules. The component is headless  -  it never instantiates fields and never calls `validate()`.
 - Static copy (labels, placeholders, helper text, toggle captions) lives in Configuration; fields carry value+state+rules only.
-- Non-form actions (e.g. "Sil", "Edit", "Detaylar") stay as paired closures on the View — they are NOT fields and NOT Configuration values.
+- Non-form actions (e.g. "Sil", "Edit", "Detaylar") stay as paired closures on the View  -  they are NOT fields and NOT Configuration values.
 
 **Figma → FormField mapping:**
 
@@ -278,11 +278,42 @@ Configuration then carries `public let section: ComponentName.Section` plus stat
 
 **Architecture output (atomic, 1 field):** Configuration (or View init) carries the FormField directly, e.g. `public let terms: CheckboxFormField`.
 
+### 1.5.4 Interaction Pattern Detection (navigation / overlays / bottom sheets)
+
+Beyond content patterns, detect **interaction affordances** the component must expose without owning the presentation/routing. Each maps to a cross-cutting integration skill (native-SwiftUI default; a project-supplied system only when `figma-config` declares `ui.<system>`). The rule is the same in all three: the component emits a typed intent (Output closure) or takes a caller-owned binding  -  it never routes, never presents an app-level surface, never owns the sheet.
+
+**Navigation pattern** → read `/figma-navigation` (`.instructions/figma/figma-navigation/SKILL.md`).
+- **Detect:** a tab/section switcher that changes top-level content; a nav bar / header with a **back** or close affordance; a row/card variant implying a **push/detail** (chevron, "Detaylar", disclosure); a link/button whose label implies leaving the screen; a URL landing surface.
+- **Architecture output:** a navigation **Output** (`output: (Output) -> Void` / `onSelect: (ID) -> Void`) OR a caller-owned `selection: Binding<Tab>` OR a plain deep-link entry param. Labels/icons are static (localized) Configuration copy; only the *intent* is a closure. Never a hardcoded `NavigationLink(destination:)`.
+- **Guard:** an in-place segmented filter (no screen change) is a plain `Binding<Enum>`, not navigation.
+
+**Overlay pattern** → read `/figma-overlays` (`.instructions/figma/figma-overlays/SKILL.md`).
+- **Detect:** a toast/snackbar, a spinner/HUD or blocking dim, an alert dialog (1-3 buttons), a data-driven modal card; or a component action needing post-action feedback (saved/deleted/error).
+- **Architecture output:** the component emits an **intent** (`.saved` / `.removeRequested(id)`); the caller (scene/VM) shows the toast/alert/modal. Overlay content is data, never `AnyView`; rich/interactive content is a local `.sheet/.modal { }` at the owning view. Loading is ref-counted with min-show.
+- **Guard:** a static inline banner that is part of the component's own layout is plain content, not an overlay.
+
+**Bottom-sheet pattern** → read `/figma-bottom-sheets` (`.instructions/figma/figma-bottom-sheets/SKILL.md`).
+- **Detect:** the component is (or reveals) a bottom sheet / half-sheet / drawer, a **pinned bottom CTA** bar, a resizable pull-up panel, a **content-sized** sheet, or a **multi-step** in-sheet flow.
+- **Architecture output:** the component is sheet **content**; the caller owns `isPresented`/`item` + detents. A pinned CTA is `.safeAreaInset(edge:.bottom)`, not a presented sheet. If the component *reveals* a child sheet, it emits the trigger intent and the caller presents.
+- **Guard:** an inline expandable/disclosure within the page flow is plain component content.
+
+**Property classification additions:**
+
+| Classification | When | Swift Pattern |
+|---|---|---|
+| Navigation output | push/select/back affordance | `output`/`onSelect` closure on the View |
+| Tab/selection binding | switches top-level content | `selection: Binding<Tab>` |
+| Overlay intent | action needs app-level feedback/confirm | `output`/`onX` closure (caller shows overlay) |
+| Sheet content | component lives inside a sheet | plain component; caller adds `.presentationDetents(...)` |
+| Pinned CTA | sticky bottom action bar | `.safeAreaInset(edge:.bottom)` at the screen |
+
+Record detected interaction patterns in `04b_component_architecture.md` under **Navigation / Overlays / Bottom Sheet** headings (see each skill's "Integration with Phase 3D" for the table shape).
+
 ### 1.5.2 Image Asset Classification
 
 Figma designs contain images that are either **static assets** (bundled in the app) or **dynamic content** (loaded remotely at runtime). Classify each image in the design context.
 
-**Classification — reason about what the image represents:**
+**Classification  -  reason about what the image represents:**
 
 | Signal | Classification |
 |--------|---------------|
@@ -298,7 +329,7 @@ Figma designs contain images that are either **static assets** (bundled in the a
 **For DYNAMIC images:**
 - Swift type: `URL` or `String` (the remote image URL)
 - The view MUST use the remote image component from `CoreUI` (Kingfisher-backed) for async loading, caching, and placeholder handling
-- Do NOT download the Figma placeholder image — it's sample data, not a real asset
+- Do NOT download the Figma placeholder image  -  it's sample data, not a real asset
 - Add a `placeholder` parameter or use a default placeholder view for loading state
 
 **For STATIC images:**
@@ -308,7 +339,7 @@ Figma designs contain images that are either **static assets** (bundled in the a
 - Reference via the generated `Image.` accessor
 
 **Architecture output:** When a dynamic image is detected, the property coverage should list:
-- `{imageName}URL: URL` (LAYER_IMAGE, IMPLEMENT) — or `String` if the URL comes as a string from the API
+- `{imageName}URL: URL` (LAYER_IMAGE, IMPLEMENT)  -  or `String` if the URL comes as a string from the API
 
 ### 1.6 Write `{artifactPath}/pass3/04_patterns.md`
 
@@ -355,9 +386,9 @@ OR: None detected.
 
 | Layer Text | Semantic Role | Classification | Swift Property | Notes |
 |------------|--------------|----------------|----------------|-------|
-| "{text}" | {role} | DYNAMIC / STATIC | `{propName}: String` / — | {rationale} |
+| "{text}" | {role} | DYNAMIC / STATIC | `{propName}: String` /  -  | {rationale} |
 
-OR: All layer text already captured as Figma TEXT properties or localization keys — no additional dynamic parameters.
+OR: All layer text already captured as Figma TEXT properties or localization keys  -  no additional dynamic parameters.
 
 ## Image Asset Classification
 
@@ -374,14 +405,14 @@ OR: No images detected in component.
 
 **This is the core analysis gate.** Using pattern data from GATE 1, determine the complete Swift API shape.
 
-INPUT: GATE 1 output (in memory — just computed)
+INPUT: GATE 1 output (in memory  -  just computed)
 INPUT: `{artifactPath}/pass1/design_context_response.json`
 INPUT: `{artifactPath}/pass1/component_properties.json`
 INPUT: `{artifactPath}/pass3/04c_variant_config_analysis.json` (from Phase 3H)
 
 ### 2.0 Consume Phase 3H Classifications
 
-Read `04c_variant_config_analysis.json`. This contains typed recommendations for every boolean property. **Do NOT re-classify** — use 3H output directly.
+Read `04c_variant_config_analysis.json`. This contains typed recommendations for every boolean property. **Do NOT re-classify**  -  use 3H output directly.
 
 For entries with `"deferredTo": "3D"` (UNCLASSIFIED booleans): analyze using `design_context_response.json` HTML structure to determine if the boolean is a section toggle (controls multiple children → `Bool`), decorative leaf (`Bool`), or behavioral bool (`Bool`).
 
@@ -439,19 +470,19 @@ public let sections: [CardSection]
 
 ### 2.2 Sub-Component Integration
 
-**This section consumes Phase 3H output.** Do NOT re-detect sub-components — 3H has already classified them.
+**This section consumes Phase 3H output.** Do NOT re-detect sub-components  -  3H has already classified them.
 
 Phase 3H provides `dynamicProps` and `staticProps` for each sub-component entry. Only dynamic props are exposed to the caller. Static props are hardcoded internally by the parent View (Phase 4B).
 
 **For each `KNOWN_SUBCOMPONENT` entry:**
 
-Use the `swiftType` from 3H directly — it's already resolved based on dynamic prop count:
+Use the `swiftType` from 3H directly  -  it's already resolved based on dynamic prop count:
 
 | Dynamic Props | Result |
 |---|---|
 | 0 | Boolean presence only |
 | 1 | Unwrapped to prop type (e.g., `String?`) |
-| 2+ | Mini config struct (e.g., `PriceConfiguration?`) — define it in the parent's Configuration |
+| 2+ | Mini config struct (e.g., `PriceConfiguration?`)  -  define it in the parent's Configuration |
 
 ```swift
 // 1 dynamic prop (title only): unwrapped to String?
@@ -463,7 +494,7 @@ public struct PriceConfiguration: Sendable {
     public let currency: String
     public let wholeAmount: String
     public let decimalAmount: String
-    // textStyle is STATIC — not exposed, hardcoded in View body
+    // textStyle is STATIC  -  not exposed, hardcoded in View body
 }
 public let priceConfiguration: PriceConfiguration?  // nil = hidden
 ```
@@ -492,7 +523,7 @@ Same prop filtering as KNOWN_SUBCOMPONENT, plus a paired closure. The data goes
 - Use the `swiftType` from 3H (`Image?` or `Optional3<Image>`)
 - Use the `swiftName` from 3H for naming
 
-**For `UNCLASSIFIED` entries resolved in §2.0:**
+**For `UNCLASSIFIED` entries resolved in section2.0:**
 - Integrate the resolved type (`Bool` for section toggles, etc.)
 
 ### 2.3 Property Classification
@@ -502,18 +533,18 @@ For each property identified in GATE 1, classify into its final Swift form:
 | Classification | When | Swift Pattern |
 |----------------|------|---------------|
 | Required parameter | Always visible, component meaningless without it | `init(title: String)` |
-| Optional parameter | Sometimes hidden/absent | `subtitle: String? = nil` — chain modifier |
-| Merged optional | Boolean toggles ONE content element | `text: String?` — boolean dropped, nil = hidden |
+| Optional parameter | Sometimes hidden/absent | `subtitle: String? = nil`  -  chain modifier |
+| Merged optional | Boolean toggles ONE content element | `text: String?`  -  boolean dropped, nil = hidden |
 | Enum | Variant with named values | `enum State { case active, inactive }` |
 | Bool toggle | Binary behavior OR toggles MULTIPLE elements | `isInteractive: Bool = true` |
 | Array | Repeated homogeneous children | `items: [ItemRow]` |
 | Enum array | Repeated heterogeneous children | `sections: [CardSection]` |
-| Mini config (display) | Boolean-gated sub-component, 2+ dynamic props, no action | `priceConfiguration: PriceConfiguration?` — chain modifier |
+| Mini config (display) | Boolean-gated sub-component, 2+ dynamic props, no action | `priceConfiguration: PriceConfiguration?`  -  chain modifier |
 | Mini config (paired) | Boolean-gated sub-component, 2+ dynamic props + action | Paired modifier: `.actionLink(config) { action }` |
 | Paired single prop | Boolean-gated sub-component, 1 dynamic prop + action | Paired modifier: `.secondaryButton(title) { action }` |
 | Paired closure-only | Boolean-gated sub-component, 0 dynamic props + action | Paired modifier: `.dismissButton { action }` |
 | Closure | Interactive action (always present, not boolean-gated) | `onTap: (() -> Void)?` |
-| Layer text (dynamic) | Sample/placeholder data in Figma layers (from §1.5 classification) | `{propName}: String` |
+| Layer text (dynamic) | Sample/placeholder data in Figma layers (from section1.5 classification) | `{propName}: String` |
 
 ### 2.3.1 Coexistent Property Rule
 
@@ -528,7 +559,7 @@ When two properties are semantically meaningless without each other, they MUST b
 
 **Resolution:** Coexistent pairs are expressed as **paired modifiers** on the View. The data prop goes in Configuration (for nil = hidden), the closure stays as a View dependency. The modifier sets both atomically.
 
-This is NOT limited to sub-components — any two semantically bound props follow this rule.
+This is NOT limited to sub-components  -  any two semantically bound props follow this rule.
 
 ### 2.4 Configuration Hierarchy
 
@@ -660,11 +691,11 @@ OR: No sub-components detected. All properties are flat.
 
 | Property | Classification | Swift Type | Default |
 |----------|---------------|------------|---------|
-| title | Required | `String` | — |
+| title | Required | `String` |  -  |
 | subtitle | Optional | `String?` | `nil` |
-| state | Enum | `State` | — |
+| state | Enum | `State` |  -  |
 | showIcon | Bool toggle | `Bool` | `true` |
-| passengers | Array | `[PassengerRow]` | — |
+| passengers | Array | `[PassengerRow]` |  -  |
 | onTap | Closure | `(() -> Void)?` | `nil` |
 
 ## Enum Definitions
@@ -725,7 +756,7 @@ Alongside the markdown, emit a structured JSON so Phase 3G (Property Coverage) c
       "type": "{VARIANT|BOOLEAN|TEXT|INSTANCE_SWAP|LAYER_TEXT}",
       "status": "{IMPLEMENT|SKIP}",
       "swiftType": "{enum State | String? | Image? | Bool | ...}",
-      "reason": "{only for SKIP — mandatory, e.g. 'Boolean merged into icon: Image? per Boolean Visibility Merge Rule'}"
+      "reason": "{only for SKIP  -  mandatory, e.g. 'Boolean merged into icon: Image? per Boolean Visibility Merge Rule'}"
     }
   ],
   "enums": [
@@ -741,7 +772,7 @@ Alongside the markdown, emit a structured JSON so Phase 3G (Property Coverage) c
 
 **Rules:**
 - Every key from `componentPropertyDefinitions` in `component_properties.json` MUST appear in `properties`
-- DYNAMIC entries from Layer Text Classification (§1.5) MUST also appear in `properties` with `"type": "LAYER_TEXT"` and `"figmaKey": null`
+- DYNAMIC entries from Layer Text Classification (section1.5) MUST also appear in `properties` with `"type": "LAYER_TEXT"` and `"figmaKey": null`
 - IMPLEMENT properties MUST have `swiftType`
 - SKIP properties MUST have `reason`
 - `propertyCount` = count of IMPLEMENT properties (used by GATE 3 complexity check)
@@ -838,14 +869,14 @@ Before marking complete, verify:
 [ ] component_properties.json fully analyzed for variant types
 [ ] All repeating patterns identified and modeled as arrays
 [ ] All variant properties classified (enum, bool, optional, array)
-[ ] Layer text classification performed — all sample/placeholder data identified as DYNAMIC API parameters
-[ ] Image asset classification performed — stock photos as DYNAMIC (remote URL), icons/logos as STATIC (bundled)
-[ ] List inference performed — homogeneous vs heterogeneous determined
-[ ] Sub-component detection performed — configurations created where needed
-[ ] Configuration hierarchy decided — flat vs grouped
+[ ] Layer text classification performed  -  all sample/placeholder data identified as DYNAMIC API parameters
+[ ] Image asset classification performed  -  stock photos as DYNAMIC (remote URL), icons/logos as STATIC (bundled)
+[ ] List inference performed  -  homogeneous vs heterogeneous determined
+[ ] Sub-component detection performed  -  configurations created where needed
+[ ] Configuration hierarchy decided  -  flat vs grouped
 [ ] All enums defined with correct case names
 [ ] Final API design is complete and compilable
-[ ] NO protocols used — all types are concrete structs/enums
+[ ] NO protocols used  -  all types are concrete structs/enums
 [ ] All configurations are Sendable
 [ ] Complexity evaluated using FINAL property count (not raw Figma count)
 [ ] 04_patterns.md written to pass3/

package/pipeline/skills/figma-ios/figma-to-component/phases/phase-3e-assets.md

@@ -1,9 +1,9 @@
-# PHASE 3E — Asset Inventory
+# PHASE 3E  -  Asset Inventory
 
 Inventory downloaded assets, cross-reference with existing token registry.
 Determines which assets are new vs already exist in the project.
 
-CONDITIONAL — skip if no design_context_assets.txt exists or is empty.
+CONDITIONAL  -  skip if no design_context_assets.txt exists or is empty.
 PARALLEL WITH: Phase 3A, 3B, 3C, 3D, 3F (all read from pass1/ independently)
 
 ---
@@ -72,9 +72,9 @@ cd {repos.common.path} && .build/debug/FigmaRegistryUtility ui-token-lookup --na
 
 | Result | Action |
 |--------|--------|
-| Found | Mark status: "Existing" — already in project, no action needed |
-| Not found | Mark status: "New" — needs to be added to asset catalog |
-| Tool error | Mark status: "Unknown" — log warning, continue |
+| Found | Mark status: "Existing"  -  already in project, no action needed |
+| Not found | Mark status: "New"  -  needs to be added to asset catalog |
+| Tool error | Mark status: "Unknown"  -  log warning, continue |
 
 Also check if the asset exists in the UIComponents asset catalog directly:
 

package/pipeline/skills/figma-ios/figma-to-component/phases/phase-3f-utilities.md

@@ -1,10 +1,10 @@
-# PHASE 3F — Utility Integration Summary
+# PHASE 3F  -  Utility Integration Summary
 
 Consolidate Phase 2 utility artifacts and map utilities to design elements.
 Cross-references testing identifiers, localization keys, accessibility keys, and analytics events
 with the actual design elements from Phase 1.
 
-required — always execute this phase.
+required  -  always execute this phase.
 PARALLEL WITH: Phase 3A, 3B, 3C, 3D, 3E (all read from pass1/pass2 independently)
 
 ---
@@ -100,10 +100,10 @@ Source: pass2/utility_identifiers.md, pass2/utility_localization.md, pass2/utili
 
 | Element | Testing ID | Localization Key | Accessibility | Analytics |
 |---------|------------|------------------|---------------|-----------|
-| Title text | `.title` | `ComponentName.Title` | — | — |
+| Title text | `.title` | `ComponentName.Title` |  -  |  -  |
 | Action button | `.actionButton` | `ComponentName.Action` | `.actionButton` | `UIInteractionButtonTapped` |
-| Card container | `.card` | — | — | `UIInteractionCardTapped` |
-| Badge | `.badge` | — | runtime label | — |
+| Card container | `.card` |  -  |  -  | `UIInteractionCardTapped` |
+| Badge | `.badge` |  -  | runtime label |  -  |
 
 ## Testing Identifiers
 
@@ -126,7 +126,7 @@ OR: No localization keys (dynamic text only).
 |-----|---------|-------|
 | ComponentName.ActionButton | VoiceOver label for action | `.accessibilityLabel(...)` |
 
-OR: No dedicated keys — using runtime accessibility patterns.
+OR: No dedicated keys  -  using runtime accessibility patterns.
 
 ## Analytics Events
 

package/pipeline/skills/figma-ios/figma-to-component/phases/phase-3g-property-coverage.md

@@ -1,8 +1,8 @@
-# PHASE 3G — Property Coverage Verification
+# PHASE 3G  -  Property Coverage Verification
 
 Verify that every Figma component property gathered in Phase 1 has been explicitly addressed by Phase 3D's architecture design. Prevents silent property drops.
 
-SEQUENTIAL — runs AFTER all parallel sub-phases (3A-3F) complete.
+SEQUENTIAL  -  runs AFTER all parallel sub-phases (3A-3F) complete.
 DEPENDS ON: Phase 3D output (`pass3/04b_component_architecture.md`)
 
 ---
@@ -41,11 +41,11 @@ USER_ACTION_REQUIRED: Run Phase 3D first.
 Extract the complete list of Figma component properties:
 
 For each property, record:
-- `name` — display name (e.g., "Size", "Loyalty Type", "Icon")
-- `type` — VARIANT, BOOLEAN, TEXT, INSTANCE_SWAP
-- `figmaKey` — exact key from componentPropertyDefinitions (e.g., "Icon#1634:1")
-- `values` — possible values (for VARIANT/BOOLEAN)
-- `default` — default value
+- `name`  -  display name (e.g., "Size", "Loyalty Type", "Icon")
+- `type`  -  VARIANT, BOOLEAN, TEXT, INSTANCE_SWAP
+- `figmaKey`  -  exact key from componentPropertyDefinitions (e.g., "Icon#1634:1")
+- `values`  -  possible values (for VARIANT/BOOLEAN)
+- `default`  -  default value
 
 **CRITICAL: Every property in componentPropertyDefinitions MUST appear in this list. No exceptions.**
 
@@ -84,8 +84,8 @@ For each property, assign exactly one status:
 | `DEFER` | Deferred to future iteration | **Mandatory reason** |
 
 **SKIP reasons (valid examples):**
-- "Fixed to single value per design — not configurable by developers"
-- "Internal Figma layout property — no user-facing impact"
+- "Fixed to single value per design  -  not configurable by developers"
+- "Internal Figma layout property  -  no user-facing impact"
 - "Controlled by parent component via slot composition"
 - "Boolean merged into optional per Boolean Visibility Merge Rule"
 
@@ -118,7 +118,7 @@ Write: {artifactPath}/pass3/00_property_coverage.json
       "figmaKey": "{exact key}",
       "status": "{IMPLEMENT|SKIP|DEFER}",
       "swiftType": "{enum TypeName | Bool | String | Image? | ...}",
-      "reason": "{only for SKIP/DEFER — mandatory}"
+      "reason": "{only for SKIP/DEFER  -  mandatory}"
     }
   ],
   "unmapped": []

package/pipeline/skills/figma-ios/figma-to-component/phases/phase-3h-variant-config.md

@@ -1,9 +1,9 @@
-# PHASE 3H — Variant Property Configuration Analysis
+# PHASE 3H  -  Variant Property Configuration Analysis
 
 Analyze how Figma variant/state properties (booleans, instance swaps) map to Swift configuration types.
 Detects when Figma's boolean-only exposure is insufficient for a sub-component's actual configuration needs.
 
-required — always execute this phase.
+required  -  always execute this phase.
 PARALLEL WITH: Phase 3A, 3B, 3C, 3E, 3F (all read from pass1/ independently)
 MUST COMPLETE BEFORE: Phase 3D (which consumes this output)
 
@@ -41,11 +41,11 @@ Parse `code_connect_map_response.json` and classify every entry:
 |---|---|
 | `label` = our platform (SwiftUI) AND no `componentName` AND `snippet` matches `Image.xxx` | `ICON` |
 | `label` = our platform AND `componentName` present AND `source` URL present | `SUBCOMPONENT` |
-| `label` ≠ our platform (e.g., Compose, React) | `CROSS_PLATFORM` — ignore |
+| `label` ≠ our platform (e.g., Compose, React) | `CROSS_PLATFORM`  -  ignore |
 
 Build a lookup: `{ nodeId → { classification, componentName?, source?, snippet } }`
 
-If code_connect_map is empty or missing → set `codeConnectAvailable = false`. Continue — all booleans will be `UNCLASSIFIED` and 3D handles them.
+If code_connect_map is empty or missing → set `codeConnectAvailable = false`. Continue  -  all booleans will be `UNCLASSIFIED` and 3D handles them.
 
 ---
 
@@ -71,7 +71,7 @@ Look up the instance swap's nodes in the code_connect_map index (GATE 1):
 | Found as `SUBCOMPONENT` (`componentName` + `source`) | `KNOWN_SUBCOMPONENT` | Swift type resolved in GATE 3 |
 | Not found in code_connect_map | `UNMAPPED_SUBCOMPONENT` | → **HALT** |
 
-**Node matching**: The instance swap's `nodeId` from `nestedComponents` is the definition ID. Variant-specific instance IDs appear in code_connect_map. Match by searching for code_connect_map entries whose `data-name` (from surrounding context) corresponds to the instance swap name. If ambiguous, check ALL code_connect_map ICON/SUBCOMPONENT entries — group by snippet pattern and correlate with the instance swap slot.
+**Node matching**: The instance swap's `nodeId` from `nestedComponents` is the definition ID. Variant-specific instance IDs appear in code_connect_map. Match by searching for code_connect_map entries whose `data-name` (from surrounding context) corresponds to the instance swap name. If ambiguous, check ALL code_connect_map ICON/SUBCOMPONENT entries  -  group by snippet pattern and correlate with the instance swap slot.
 
 ### Step 3: Resolve unpaired Boolean
 
@@ -113,7 +113,7 @@ If action pairing detected → reclassify as `PAIRED_ACTION_SUBCOMPONENT`.
 
 This classification tells downstream phases that:
 1. The sub-component needs both data (config props) and a closure (action)
-2. These must be paired at the call site — one without the other is nonsensical
+2. These must be paired at the call site  -  one without the other is nonsensical
 3. A paired modifier pattern is required (not separate config prop + closure)
 
 ---
@@ -145,7 +145,7 @@ Analyze whether the icon has a **computed default** that varies by component sta
 - Icon is generic (e.g., `caretDown`, `chevronRight`) with no variant correlation
 - Icon appears in ALL variants identically with no semantic relationship to variant values
 
-**When uncertain:** Prefer `Optional3<Image>` — it's strictly more expressive than `Image?` and never wrong. The consumer can always use `.default` instead of being forced to know the internal default.
+**When uncertain:** Prefer `Optional3<Image>`  -  it's strictly more expressive than `Image?` and never wrong. The consumer can always use `.default` instead of being forced to know the internal default.
 
 ### KNOWN_SUBCOMPONENT
 
@@ -154,11 +154,11 @@ Analyze whether the icon has a **computed default** that varies by component sta
    ```
    Glob: Sources/UIComponents/**/{ComponentName}Configuration.swift
    ```
-3. **Filter sub-component props — static vs dynamic:**
+3. **Filter sub-component props  -  static vs dynamic:**
 
    Read the sub-component's Configuration (or init for SIMPLE). For each property, determine:
    - **Dynamic**: Content props that the caller controls (title, text, label, description, icon when context-dependent). These carry meaning unique to each usage.
-   - **Static**: Styling/layout props that the parent component dictates (style, size, colorTheme, iconPosition). These are internal design decisions — same for every instance of this sub-component within the parent.
+   - **Static**: Styling/layout props that the parent component dictates (style, size, colorTheme, iconPosition). These are internal design decisions  -  same for every instance of this sub-component within the parent.
 
    **Rule:** If a prop's value is fixed by the parent's design (e.g., secondary button always uses `style: .ghost, size: .default`) → static. If a prop carries caller-specific content → dynamic.
 
@@ -171,7 +171,7 @@ Analyze whether the icon has a **computed default** that varies by component sta
 | 2+ | Mini config struct (e.g., `PriceConfiguration?`) | Multiple dynamic props grouped, nil = hidden |
 | Component doesn't exist | **HALT** | Sub-component must be implemented first |
 
-**Mini config structs** contain ONLY the dynamic props — static props are NOT exposed:
+**Mini config structs** contain ONLY the dynamic props  -  static props are NOT exposed:
 ```swift
 // TurkishButton has 6 props, but in BottomActions context only title is dynamic:
 // → secondaryButtonTitle: String?  (not TurkishButtonConfiguration?)
@@ -181,7 +181,7 @@ Analyze whether the icon has a **computed default** that varies by component sta
 // struct PriceConfiguration { label, currency, wholeAmount, decimalAmount }
 ```
 
-Record the static props and their fixed values in the artifact — Phase 4B needs them to hardcode internally.
+Record the static props and their fixed values in the artifact  -  Phase 4B needs them to hardcode internally.
 
 ### PAIRED_ACTION_SUBCOMPONENT
 
@@ -205,7 +205,7 @@ func dismissButton(action: @escaping () -> Void) -> Self
 
 ### CONTENT_LEAF
 
-Swift type: `String?` — `nil` = hidden. The boolean is dropped (merged into the optional).
+Swift type: `String?`  -  `nil` = hidden. The boolean is dropped (merged into the optional).
 
 ### REPEATING_PATTERN_MEMBER / REPEATING_PATTERN_CONTAINER
 
@@ -255,8 +255,8 @@ Swift type: deferred to Phase 3D. Output `"swiftType": null, "deferredTo": "3D"`
       "swiftType": "Optional3<Image> | String? | PriceConfiguration? | Bool | null",
       "swiftName": "{suggested Swift property name}",
       "dynamicProps": ["{list of dynamic prop names and types, for KNOWN_SUBCOMPONENT / PAIRED_ACTION_SUBCOMPONENT}"],
-      "staticProps": ["{list of static prop names, values, and types — parent hardcodes these}"],
-      "pairedClosure": "(() -> Void)? | null — only for PAIRED_ACTION_SUBCOMPONENT",
+      "staticProps": ["{list of static prop names, values, and types  -  parent hardcodes these}"],
+      "pairedClosure": "(() -> Void)? | null  -  only for PAIRED_ACTION_SUBCOMPONENT",
       "rationale": "{why this classification and type were chosen, including static/dynamic reasoning}",
       "halt": false,
       "deferredTo": null
@@ -294,8 +294,8 @@ This output is consumed by:
 
 | Phase | Artifact Read | Usage |
 |---|---|---|
-| **3D** (GATE 2: Architecture) | `04c_variant_config_analysis.json` | Uses classifications for §2.2 Sub-Component Detection and §2.3 Property Classification. Does NOT re-classify — consumes directly. Resolves UNCLASSIFIED entries using design_context. |
-| **4A** (Configuration) | `04c_variant_config_analysis.json` | Uses `swiftType` for property declarations. Only `dynamicProps` go in config — `staticProps` are omitted. Creates mini config structs for 2+ dynamic props. |
+| **3D** (GATE 2: Architecture) | `04c_variant_config_analysis.json` | Uses classifications for section2.2 Sub-Component Detection and section2.3 Property Classification. Does NOT re-classify  -  consumes directly. Resolves UNCLASSIFIED entries using design_context. |
+| **4A** (Configuration) | `04c_variant_config_analysis.json` | Uses `swiftType` for property declarations. Only `dynamicProps` go in config  -  `staticProps` are omitted. Creates mini config structs for 2+ dynamic props. |
 | **4B** (View) | `04c_variant_config_analysis.json` | For KNOWN_SUBCOMPONENT: instantiates sub-component internally with `staticProps` hardcoded. For PAIRED_ACTION_SUBCOMPONENT: generates paired modifier binding data+closure. For ICON with Optional3: switches on `.default`/`.none`/`.some`. |
 | **6** (Code Connect) | `04c_variant_config_analysis.json` | For KNOWN_SUBCOMPONENT/PAIRED_ACTION_SUBCOMPONENT: `@FigmaBoolean` maps to `nil`/default-config. For ICON with Optional3: `@FigmaBoolean` maps to `.default`/`.none`. No ternary expressions. |