Imported pages nest 9-13 levels deep, and the collapsible share of that is ~1 level

Start by reading the hasIndependentWrapperOwnership rule and the two assertions described in the issue, then inspect the parse_blocks measurements and the editor store's List View representation. The next step requires an owner to choose between changing the tree presentation and moving the folding boundary. Done means the selected direction is agreed and its existing contracts remain covered by the suite.

What this is

Not a bug report. A measurement, and a question for the owners of the wrapper-folding rule, because the obvious fix contradicts two contracts that look deliberate.

Measurement

A small four-page Weebly source, imported and inspected in the editor. Group-like blocks against total blocks, and the depth of the deepest path:

The deepest path on the blog page, with what each level carries:

0  group   .wrapper                                    page wrapper
1  layout-shell [1]                                    already folded
2  columns .wsite-not-footer                           layout table
3  column
4  group   .blog-body            + geometry carrier
5  group   .blocks-engine-editor-anchor-wsite-content  anchor target
6  group   .blog-post + editor-anchor-blog-post-...    anchor target
7  group   .blog-content                               projected CSS hook
8  group   .wsite-multicol                             no style, one child
9  group   .wsite-multicol-table-wrap + carrier, margin 0
10 columns .wsite-multicol-table
11 column  padding 15px
12 group   .paragraph                                  projected CSS hook
13 paragraph

Every wrapper carries a blocks-engine-source-div-* projection class, so the author stylesheet is addressed against these exact divs. Unwrapping them is not available.

Counting what could fold under a rule of "a wrapper whose declared presentation resolves to nothing visible is not independently owned": 1-3 chains per page, worth about one level of depth each.

Why I did not ship it

Relaxing hasIndependentWrapperOwnership that way fails two assertions that read as intentional:

• a media-only container retains intrinsic height when its visual layer is out of flow - a generated geometry carrier has to stay a block.
• 6: styled wrappers remain owned native boundaries with their direct child topology - a wrapper declaring margin-top:0 stays an owned boundary, which is exactly the "neutral spacing" case.

So the current line is drawn on purpose: a wrapper keeps its own block so its presentation stays editable, and folding is reserved for wrappers that own nothing. By that line these pages are already close to optimal, and the depth is the source's own DOM depth rather than slop the importer added.

The question

The cost lands on a reader rather than on rendering. In List View a 13-level chain of Group entries is mostly static source scaffolding that reads exactly like content the user is meant to edit. Two directions, both needing an owner's call:

1. Leave the tree alone and let the editor tell the difference - present a folded or already-owned scaffolding wrapper differently from an editable Group, so depth stops costing attention.
2. Move the line - let a wrapper whose presentation resolves to nothing visible fold, and accept that its zero-valued declaration stops being editable through the block. That is the change the two assertions above currently forbid.

Happy to implement either. I did not want to flip a tested decision unilaterally for one level of depth.

AI assistance disclosure

Measured and written with AI assistance - grok-4.6 via OpenCode - from a live import: block trees read through the editor store, wrapper counts and deepest paths computed with parse_blocks, and the folding rule exercised against the suite to find which contracts it breaks. A human retains review and merge authority.