Navigation

Three navigation surfaces feed off one tree. This page says which page ids are menu anchors, which navigation tags Swift templates resolve by name, and the two ways a navigation change fails to appear.

What the baseline guarantees

Layer: surface-swift 1.5.1.
Menu anchors under area 3:
  Navigation/Secondary Navigation/  Express Buy (feature-reordering), Find dealers,
                                    Quick Order (feature-reordering),
                                    Subscribe (feature-subscription-orders),
                                    Kit Configurator + Kit Configurator Detail
                                    (feature-bom-configurator)
  Navigation/Footer Navigation/     About the shop, Help and info, Languages
Header/footer pages are page ids 156 (Desktop Footer), 157 (Desktop Header),
158 (Mobile Footer), 159 (Mobile Header), wired on the area's Swift-v2_Master item fields
(area.yml itemFields HeaderDesktop/HeaderMobile/FooterDesktop/FooterMobile).
Navigation tags the Swift templates resolve by name: `Shop` is set on the Shop page
(replace/_content/Swift 2/Shop/page.yml `navigationTag: "Shop"`). Templates call
GetPageIdByNavigationTag("<tag>"); an unresolved tag falls back to 0 and renders href="#".
navDepth obligation (surface.contract-notes.json `navDepth`): the header nav needs at least
one menu-visible child relation or the theme's dropdown affordance has nothing to open.
Not present by design: no mega-menu content beyond what the Shop group tree produces. This
composition has only the five PACK-* groups the feature layers ship, so the shop mega-menu is
near-empty until you author a group tree.

Which skill covers it

dw-swift-building (dynamo: true) — SKILL.md:75-86 names the eight tags Swift expects:
homepage, shop, cart, checkout, orderconfirmation, myaccount, login, register.
dw-content-modelling (dynamo: true) — references/page-paragraph-writes.md:191-224 owns both
navigation failure modes.
dw-demo-swift (dynamo: false) — references/header-menu.md (332 lines): why the nav is flat,
nav visibility is not access control, and the four interaction probes.

Which MCP tools brand it

get_navigation_structure -> get_pages_by_parent_id -> set_page_item_fields -> save_pages
-> set_page_menu -> reorder_pages -> fetch_frontend_page_html
To give the header nav its dropdown depth, dw-demo-swift/references/header-menu.md:41-55
prescribes, in this order:
  save_groups              (author child ecom groups under the top groups, parentGroupId)
  assign_products_to_group (populate each child so the landing is not empty)

Verify

MCP, two-part, because a re-parent is cached:
1. get_navigation_structure lists the page at its new parent.
2. fetch_frontend_page_html on <site-root>/home contains the link text.
If 1 passes and 2 fails it is the page-tree cache, not permissions — restart the host
(dw-content-modelling/references/page-paragraph-writes.md:204-224).
Second assert: get_page_by_id on the Shop page returns navigationTag "Shop" (non-empty).
`save_pages` has no navigationTag member and drops the key silently
(page-paragraph-writes.md:191-202). Assert the value, never the call status; a template link
rendering as `#` is the same finding seen from the frontend.
Third assert, the one a markup check cannot make (dw-demo-swift/references/header-menu.md:
317-332): the caret's DOM border-right is non-zero, `elementFromPoint` mid-gap resolves inside
the panel, the open-state caret is static, and `menu.right >= link.right`. A synthetic click
masks the vertical-reach bug.