Update to Uniform

{
  "description": "Model and build header navigation in Uniform — authored, reorderable nav items, dropdown flyouts, mega-menu panels with a category rail and promo area, and mobile drawers. Covers modeling the component chain, the slot-data techniques a parent needs to read its own children, variant-driven layout, and the interaction and accessibility layer. Use when adding a navigation bar, header, navbar, mega menu, flyout, or dropdown menu to a Uniform project, restructuring navigation so editors can author and reorder menu items, adding a mobile navigation drawer, or reviewing a navigation implementation for authoring or accessibility problems.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 176
    },
    {
      "relative_path": "references/discovery.md",
      "size_in_bytes": 4373
    },
    {
      "relative_path": "references/interaction-and-a11y.md",
      "size_in_bytes": 6929
    },
    {
      "relative_path": "references/modeling.md",
      "size_in_bytes": 7462
    },
    {
      "relative_path": "references/slot-data-access.md",
      "size_in_bytes": 7805
    }
  ],
  "name": "uniform-navigation",
  "skill_md_contents": "---\nname: uniform-navigation\ndescription: Model and build header navigation in Uniform — authored, reorderable nav items, dropdown flyouts, mega-menu panels with a category rail and promo area, and mobile drawers. Covers modeling the component chain, the slot-data techniques a parent needs to read its own children, variant-driven layout, and the interaction and accessibility layer. Use when adding a navigation bar, header, navbar, mega menu, flyout, or dropdown menu to a Uniform project, restructuring navigation so editors can author and reorder menu items, adding a mobile navigation drawer, or reviewing a navigation implementation for authoring or accessibility problems.\nlicense: MIT\n---\n\n# Uniform navigation and mega menus\n\nNavigation in Uniform is a chain of small components, authored and reordered in the visual\neditor. The hard part is that **a slot hands a parent already-rendered, opaque children** —\nso a menu shell that needs its children's *labels*, to draw a category rail or a mobile\nsection heading, cannot get them by reading the slot. Everything here follows from that.\n\n## Workflow\n\n### 1. Discover before you model\n\nNever assume the project is greenfield, and never assume which component library it uses.\nFind out which of these you are in — the answer changes every later step. See\n[references/discovery.md](references/discovery.md) for the greps.\n\n| What you find | Do |\n|---|---|\n| Navigation components already exist | **Extend them.** Add the panel/category level; keep existing IDs |\n| A header exists but is flat (links only) | Add the flyout + panel levels beneath it |\n| Nothing exists | Model the full chain from scratch |\n\nAlso determine, before writing any parameter: **is the Design Extensions integration\ninstalled?** If it is not, `dex-*` parameter types produce values your code has no resolver\nfor. Use plain `select` / `text` / `asset` / `link` types instead.\n\n### 2. Model the chain, not a component\n\nNavigation is a chain of small components, each slot allowing only the next level. Menu\ndepth is a consequence of **which components a slot allows** — never a depth parameter, and\nnever numbered parameters (`link1`, `link2`).\n\n```text\nheader\n└── (center slot)  → link | flyout\n    └── flyout                            ← trigger + panel shell; variant switches layout\n        ├── (panel slot)  → link | group | category\n        │   └── category                  ← rail label + its own panel\n        │       └── (panel slot) → group | link | image | rich text | layout\n        │           └── group             ← labelled column of links\n        │               └── (links slot) → link\n        └── (aside slot)  → promo content\n```\n\nFull slot policy, naming, and the pattern layer: [references/modeling.md](references/modeling.md).\n\n### 3. Wire the parent → child data path *first*\n\nBefore any layout work, prove the shell can read its children. This is where navigation\nbuilds fail, and the failure is silent. See\n[references/slot-data-access.md](references/slot-data-access.md).\n\nThe shape, framework-neutral:\n\n- The **rail** (labels) comes from raw child component instances, read server-side.\n- The **panel** (content) comes from rendering the slot normally and filtering to the\n  active child by `_id`.\n\nNever rebuild children from raw data — read labels from it, render children through the slot.\n\n### 4. Branch layout on variant, not on a parameter\n\nA dropdown, a full-bleed mega panel, and a master-detail mega panel are the same component\nin different layouts. Use a display **variant** for the layout switch and let the presence\nof categories pick the sub-shape:\n\n| Variant | Categories present | Layout |\n|---|---|---|\n| default | — | absolute panel anchored to the trigger |\n| mega | none | full-bleed panel, edge to edge |\n| mega | one or more | rail + panel, plus optional aside |\n\nFull-bleed panels must be positioned below the header, not below the trigger. Measure the\nheader's bottom edge on resize and scroll rather than hard-coding a height.\n\n### 5. Build the interaction layer\n\nHover intent with asymmetric delays, Escape to close, focus management, and `inert` on\nclosed panels. Do not ship a keyboard-reachable closed menu.\n[references/interaction-and-a11y.md](references/interaction-and-a11y.md).\n\n### 6. Compose into a pattern\n\nAssemble the header once as a **component pattern**, then place it in the page composition's\nheader slot — typically inside a **composition pattern** so every page inherits it. Which\nparameters to lock and which to open is a project decision, not a rule; make the trade\nexplicit rather than defaulting to locking everything.\n\nThat header slot is one you did not create. Confirm it accepts a *pattern*, not just your\nheader component — `patternsInAllowedComponents` reads backwards and blocks patterns when\nset to `true`. See [references/modeling.md](references/modeling.md).\n\n## Framework specifics\n\nThis skill is framework-neutral by design. How a parent reads child data, and whether that\ncode is a server or client component, is your framework SDK's business:\n\n- **Next.js App Router** — [uniform-nextjs-app-router](../uniform-nextjs-app-router/SKILL.md),\n  whose `references/advanced.md` documents the composition cache\n- **Next.js Page Router** — [uniform-nextjs-page-router](../uniform-nextjs-page-router/SKILL.md)\n\nGeneral slot, parameter, naming, and pattern rules live in\n[uniform-experience-modeling](../uniform-experience-modeling/SKILL.md); this skill does not\nrestate them.\n\n## Guardrails\n\n- **Repetition is a slot.** Numbered parameters (`link1`, `linkText2`) cap the count, block\n  reordering, and forfeit personalization and A/B testing on individual menu items. The\n  general rule is in\n  [uniform-experience-modeling](../uniform-experience-modeling/references/slots.md).\n- **Render editable labels with `UniformText`**, not as a raw string, or the editor cannot\n  edit them inline. This bites on a category rail specifically: the label there is read from\n  slot data, and printing that string produces a label nothing can click. Either render the\n  rail label through the slot as well, or state plainly that the rail is edited from the\n  component tree.\n- **A parent must never rebuild its children** from raw slot data. It loses personalization,\n  A/B tests, patterns, and editor affordances. Read metadata from raw data; render children\n  through the slot.\n- **Never enable allow-all on a navigation slot.** A promo/aside slot is the one place a wide\n  allow-list is defensible — still enumerate it rather than toggling allow-all.\n- **Editor placeholder items are real slot items.** Checking `items.length` to decide whether\n  a region has content is always true in the editor. Filter out placeholder entries first.\n- **A curated menu is authored as components; the project map drives *derived* navigation**\n  — breadcrumbs, a sitemap, a section index. Nav items should still link *to* project map\n  nodes. Entries behind a data resource are a valid third option when the menu genuinely\n  mirrors content already modeled that way. All three, and when each is right:\n  [references/modeling.md](references/modeling.md).\n\n## Resources\n\n- [Discovery](references/discovery.md) — find the existing navigation surface, the design\n  system, and the token layer before changing anything\n- [Modeling](references/modeling.md) — the component chain, slot policy, parameters, depth,\n  and the pattern layer\n- [Slot data access](references/slot-data-access.md) — the mechanism: how a shell reads its\n  own children, the four techniques, and the silent failures\n- [Interaction and accessibility](references/interaction-and-a11y.md) — hover intent, focus\n  management, `inert`, the rail's correct ARIA pattern, mobile\n"
}