IUR hydration: expand_list_repeat doesn't expand repeat-marked children for :artifact_row or custom:* widget types

[ty13r]

Context

Discovered during Wave AshUI-3.9 Item 2 dispatch (2026-05-17/18). After applying the validator allow-list extension in PR #113 (which unblocks compile-time), the same 5 DSL Screen LiveViews in ariston-ui still have 14 of 38 tests failing with content-rendering errors (e.g., "expected 3 block sections, found 0").

Current behavior

AshUI.LiveView.IURHydration.expand_list_repeat/1 (at packages/live_ui/lib/ash_ui/live_view/iur_hydration.ex:142 in the vendored package) only expands repeat-marked children when the destination Element's widget type is "list_repeat":

def expand_list_repeat(%{"type" => "list_repeat", ...} = node, ...) do
  # ... clones template per row ...
end

For Elements with type :artifact_row or type "custom:*", the repeat-marked metadata is present on the node (via metadata.composition.repeat) but the IURHydration pipeline never clones the template node per row → the destination renders as a single template instance with no fan-out.

Desired behavior

Extend hydration (either by widening expand_list_repeat/1's match arm or by adding a new helper expand_template_repeat/1) to handle repeat expansion for :artifact_row and "custom:*" widget types, driven by the same metadata.composition.repeat field that compile_node helpers in the LiveViews already populate correctly.

Affected tests

In ariston-ui:

• test/ariston_ui_web/live/manuscript_live_test.exs — 3 tests (DocBlockTemplate)
• test/ariston_ui_web/live/swimlane_screen_live_test.exs — 4 tests (4 lane card templates)
• test/ariston_ui_web/live/research_page_screen_live_test.exs — 3 tests (ResearchDocRow)
• test/ariston_ui_web/live/conversation_screen_live_test.exs — 2 tests (ConversationMessageRow + ConversationProposalRow)
• test/ariston_ui_web/live/document_chat_workspace_screen_live_test.exs — 2 tests (DocBlock + ChatMessageRow + ProposalRow)

Total: 14 tests blocked on this gap.

Why this is a design call (not a mechanical fix)

Extending hydration shape touches the IUR composition model:

• Pascal-architect decision on whether to extend expand_list_repeat, add a new helper, or refactor the dispatch model entirely
• Implications for how metadata.composition.repeat is interpreted across widget families
• Whether the compile_node LiveView injection pattern (which bypasses BindingEvaluator for the repeat case) stays as-is or gets folded into the new hydration path

Cross-references

• ariston-ui docs/iur-missing-list-binding-sizing.md (merged via PR #385) — sizing investigation
• ash_ui PR fix(ash_ui validations): trust custom:* opaque widget types in :list binding allow-list #113 — validator allow-list extension (this issue's first-half companion)
• Wave AshUI-3.9 Item 2 dispatch report — substrate-gap discovery + escalation
• Related Issue: The-Metagraph/metagraph-connectors#42 (subfamily threading consumer-side gap) — shape similarity (provider wired, consumer not yet)

Labels: design-required, pascal-coordination, wave-ashui-3.9-spillover

[ty13r]

Scope correction post-PR #113 r2 (2026-05-18)

The original framing above ("extend expand_list_repeat to handle :artifact_row + custom:* widget types") was based on the same architectural premise mismatch that PR #113 r1 hit. Codex P2 #2 review on PR #113 surfaced that the canonical destination widget for list-bound children is :list_repeat (wrapping a row template via ui_relationships), NOT :artifact_row or other row-template kinds.

Implication for this issue:

The 14 failing ariston-ui tests (originally attributed to this hydration gap) may be substantially resolved by the ariston-side restructure that wraps :artifact_row / "custom:*" row templates in :list_repeat parent Elements that own the :list binding. expand_list_repeat already handles :list_repeat correctly — the question reduces to whether the row template inside (the :artifact_row or "custom:*" child) gets cloned correctly when it's a CHILD of :list_repeat (vs being the direct destination).

Verification path:

1. Wait for ariston-ui to restructure the 5 affected Screens (queue v3 Item 2 v2, pending Matt's pair-eyes per the queue pivot)
2. Re-run the 14 originally-failing tests against the restructured Screens
3. If most/all pass: this issue can be closed (resolved by the architectural pivot)
4. If "custom:*" row templates inside :list_repeat still don't hydrate correctly: narrow the issue to that specific case (which is still a Pascal-design call but bounded)

Status: keep open with wave-ashui-3.9-spillover label; revisit after the ariston-side restructure verification.

Cross-references:

• ash_ui PR fix(ash_ui validations): trust custom:* opaque widget types in :list binding allow-list #113 (validator narrowed to custom:* bypass only) — first-half companion
• ariston-ui docs/iur-missing-list-binding-sizing.md — sizing doc updated via ariston-ui PR #387 to reflect this pivot
• Phase31RepeatListElement at ash_ui/test/support/resource_authority_modules.ex:185–219 — the canonical :list_repeat destination pattern

[ty13r]

Verification result (2026-05-18, post-pivot) — Pascal-design call now LIVE

Wave AshUI-3.9 Queue v3 Item 2 Step 4 PR A (ariston-ui PR #388) landed the architectural pivot: ProcessManuscriptScreen + ResearchPageScreen now use the canonical :list_repeat wrapper Element pattern from Phase31RepeatListElement. Two new wrapper Elements (ProcessManuscriptBlockList, ResearchPageDocList) introduced; Screens point has_many at the wrappers; wrappers own the :list binding + has_many to the row template (DocBlockTemplate, ResearchDocRow) via ui_relationships kind: :child.

Validator gap closed. All 12 :missing_list_binding failures cleared. 8 of 13 tests pass.

Hydration gap NOT closed. 5 of 13 tests still fail with rendering-content errors. Sonnet sub-agent report:

The ash-list-repeat wrapper renders in HTML (<div class="ash-list-repeat" data-repeat-binding="rows">) confirming the validator is satisfied and the two-level structure is wired correctly, but expand_list_repeat renders only the static template placeholder instead of real runtime rows. The LiveView injects runtime values via build_runtime_bindings, but the pipeline does not traverse the two-level Element relationship to pass those values down to the row template.

So the scope is now precise: expand_list_repeat doesn't traverse the wrapper Element's has_many → row template relationship to populate per-row instances. Not :artifact_row / custom:* specific — applies to ANY two-level Element relationship inside a :list_repeat wrapper.

Scope refinement

The original framing in this issue's body ("extend expand_list_repeat to handle :artifact_row + custom:* widget types") is superseded. The refined scope:

• The wrapper Element is already correctly recognized as :list_repeat
• expand_list_repeat needs to follow the wrapper's ui_relationships (specifically the kind: :child relationship to the row-template Element) and clone the row template per row in the runtime list bound to the :list binding
• Runtime values from build_runtime_bindings need to flow through that traversal so each cloned row instance carries its own row data

This is a Pascal-design call on the IUR composition model — specifically how expand_list_repeat should treat the wrapper-Element's child-relationship as the row-template source.

Affected ariston-ui tests

5 tests across:

• test/ariston_ui_web/live/manuscript_live_test.exs (some pass, some fan-out-dependent fail)
• test/ariston_ui_web/live/research_page_screen_live_test.exs (same shape)

PRs B (SwimlaneScreen) + C (ConversationScreen + DocumentChatWorkspaceScreen) are on HOLD pending this design call — they'd hit the same hydration gap. Dispatching them would just replicate the same test failure pattern.

Cross-references

• ariston-ui PR #388 — the pivot implementation; :list_repeat wrappers + Screen restructure
• ariston-ui PR #387 — sizing doc update documenting the architectural-premise correction
• ash_ui PR fix(ash_ui validations): trust custom:* opaque widget types in :list binding allow-list #113 — validator narrowing (custom:* bypass); merged
• ariston-ui Wave 3.9 Item 2 dispatch (Queue v3) — full pivot context

Status

Pascal-design call. ariston-ui PR #388 is functional pivot evidence — leaving it open for Pascal pair-eyes before merging. PRs B + C deferred until this gap resolves.

Labels: design-required, pascal-coordination, wave-ashui-3.9-spillover