Summary

• Arrays nested inside a block (e.g. a faqs array field inside a faqSection block) were reconstructed as plain objects with numeric keys ({"0": {...}}) instead of proper arrays on import
• richText fields inside those nested arrays were left as raw JSON strings instead of being parsed back to objects

Root causes

Bug 1 — wrong container type for array fields inside blocks

unflattenObject has a special-case branch for blocks fields. When the path continued past the block field name (e.g. faqContent_0_faqSection_faqs_0_question), it always created blockObject[fieldName] = {}, never []. Two fixes applied:

• Detect whether the segment immediately after the field name is a numeric index and create [] accordingly
• Add an else if branch in the general traversal to handle the case where currentObject is already an array and the current segment is a numeric index (which happens after the block-field jump)

Bug 2 — import hook not firing for richText inside nested arrays

toLogicalKey strips array index segments from flat keys to resolve import hook registrations (e.g. faqContent_0_faqSection_faqs_0_answer → faqContent_faqSection_faqs_answer). It only strips a numeric segment when the previous segment is in arrayLikeNames. collectArrayLikeNames recurses via field.flattenedFields but not via field.blocks[i].flattenedFields, so array field names declared inside block definitions (like faqs) were never added to the set. The hook lookup therefore failed and the JSON string was left unparsed.

Defence-in-depth — normalizeRichText key-name heuristic replaced

The post-processing fallback in normalizeRichText previously matched block properties by checking whether the runtime key name contained "richText". This never reached fields nested inside arrays inside blocks. Replaced with a schema-driven recursive walker (normalizeRichTextInFields) that handles richText, blocks, array, group, and tab fields at any depth.