Updating prod from staging

.ai/skills/CHANGELOG.md

@@ -1,5 +1,37 @@
 # igniteui doc-skill set · changelog
 
+## v4 · 2026-08-31
+
+Teaches the set two xplat contracts it did not know, both of which an author following v3 would get
+wrong. No rule was removed or reworded; two were added and one bullet was scoped. Whole set bumped to
+v4 per the uniform version-line convention.
+
+### Changed
+
+| Change | File(s) |
+|---|---|
+| `apiTerms` added to the normative frontmatter contract: required for xplat, no default, `full` / `passthrough` / `none`, with what each does to a backticked name. A page written to v3's contract has no `apiTerms` and **does not build** — generation throws on a missing or unknown value. `docs/xplat/API-TERMS.md` named as normative. | igniteui-doc-topics/references/house-style.md |
+| `json-snippet` added ahead of the inline-code-snippet bullet: an xplat DV topic states its component once as JSON and generation emits every platform's code from the product's description metadata, so hand written per-platform blocks are the exception now rather than the default. Discouraged rather than banned — a definition cannot carry a data shape, a namespace declaration or a package install, and a block is the right tool there. The existing bullet is scoped to the blocks a topic still authors by hand. `docs/xplat/JSON-SNIPPETS.md` named as normative. | igniteui-doc-topics/references/house-style.md |
+| The populations of the xplat content tree written down, because both rules above are scoped to one of them, and each page now declares which it is in `platformType`. **xplat** owes full API term resolution and a `json-snippet`-first habit; **xplat-unmapped** is the same set where that cannot be applied yet (the Excel library, and the data grid's accessibility topic); **web-only** owes neither and is not to be reworked to match. Identity is not publication: a topic can be xplat and not reach the desktop platforms yet. `platformType` replaces `apiTerms` in the required-fields list, since the mode now follows from the population. | igniteui-doc-topics/references/house-style.md |
+| house-style's version note corrected: it claimed "content unchanged from v2", which v4 makes false. | igniteui-doc-topics/references/house-style.md |
+| Create step 4 now begins with `platformType` for an xplat topic, since it is required, has no default, and decides which standard the rest of the work is held to. | igniteui-doc-topics/references/create-workflow.md |
+| Audit check D0 added (Blocker, xplat): no `platformType`, or one that does not match the topic. Names the two traps — identity is not publication, and a per-platform block or a non-`full` `apiTerms` is a finding on an xplat topic and fine on a web-only one. | igniteui-doc-topics/references/audit-rubric.md |
+| Set-wide version line bumped to `v4 · 2026-08-31`, including the content-unchanged files. | all files |
+
+### Unchanged
+
+Both routers, both skills' `description` fields (so the `.claude/` and `.codex/` adapters still
+byte-match and needed no edit), every audit check and severity, every blueprint and section table,
+and the whole frontmatter skill.
+
+### Where the substance lives
+
+The working guides for these two contracts are repository skills rather than references in this set,
+because they are xplat build machinery rather than house style: `.github/skills/xplat-docs-api-links`
+(modes, `ApiLink` props, `pkg=` disambiguation, the build-time ambiguity trap) and
+`.github/skills/xplat-docs-json-snippets` (fence attributes, channels, the five traps, the checks).
+This set points at them; it does not restate them.
+
 ## v3 · 2026-08-14
 
 Restructures both skills to the routing-hub + references architecture used by the

.ai/skills/README.md

@@ -1,6 +1,6 @@
 # Ignite UI doc-skill set — architecture and maintenance guide
 
-Version: v3 · 2026-08-14 · igniteui doc-skill set. This file is for humans; agents load the
+Version: v4 · 2026-08-31 · igniteui doc-skill set. This file is for humans; agents load the
 SKILL.md files. Change history: `CHANGELOG.md`.
 
 ## What this is
@@ -59,6 +59,14 @@ change over time lives in `references/`. Three reasons:
 └── igniteui-topic-frontmatter/SKILL.md   ← adapter (description byte-matches canonical)
 ```
 
+**Where xplat build machinery lives instead.** Two contracts an xplat author needs are not house
+style but build behaviour, so their working guides are repository skills and this set only points at
+them: `.github/skills/xplat-docs-api-links` (the `apiTerms` modes, `ApiLink` props, `pkg=`
+disambiguation) and `.github/skills/xplat-docs-json-snippets` (fence attributes, channels, the
+checks). house-style names both, and `docs/xplat/API-TERMS.md` and `docs/xplat/JSON-SNIPPETS.md` are
+normative for them. Do not restate their rules here — that is the drift this set was restructured to
+stop.
+
 **Authority chain:** where any two files differ, `house-style.md` wins on content rules (it is the
 single normative field contract and template source); each skill's own references win on its
 operational procedure (severities, report shapes, workflow order). The frontmatter skill reads

.ai/skills/igniteui-doc-topics/SKILL.md

@@ -3,7 +3,7 @@ name: igniteui-doc-topics
 description: >-
   Author or audit Ignite UI documentation topics — component pages, how-to guides, conceptual
   overviews, and category indexes — for both the Angular doc set and the cross-platform (React /
-  Web Components / Blazor) doc set. Applies the Diátaxis framework mapped onto Ignite UI's house
+  Web Components / Blazor / WinUI / Uno) doc set. Applies the Diátaxis framework mapped onto Ignite UI's house
   templates: canonical section order, fixed heading names, frontmatter (including `llms.description`
   and the `relatedComponents` trigger), `.mdx` sample embeds, and per-framework token/PlatformBlock
   mechanics. Use this whenever someone asks to write, draft, create, review, audit, fix, or
@@ -17,7 +17,7 @@ description: >-
 
 # Ignite UI doc topics
 
-Version: v3 · 2026-08-14 · igniteui doc-skill set. All set files carry this version line; before
+Version: v4 · 2026-08-31 · igniteui doc-skill set. All set files carry this version line; before
 editing any file, confirm the lines match across the set. The `.claude` adapter's `description` must
 byte-match this file's `description`. Change log: `.ai/skills/CHANGELOG.md` · human-readable intent:
 `.ai/skills/README.md`.

.ai/skills/igniteui-doc-topics/references/audit-rubric.md

@@ -1,6 +1,6 @@
 # Audit rubric
 
-Version: v3 · 2026-08-14 · igniteui doc-skill set. Before editing, confirm this version line against
+Version: v4 · 2026-08-31 · igniteui doc-skill set. Before editing, confirm this version line against
 `.ai/skills/CHANGELOG.md`.
 
 The audit workflow, the checkable rules for **audit mode**, and the report format to produce. Every
@@ -133,6 +133,13 @@ Run the compass on each section; flag content that has drifted out of the sectio
   Styling instead of Usage.
 
 ### D. Metadata & AI-readiness
+- D0 (Blocker, xplat) No `platformType`, or one that does not match the topic. The field is required
+  and has no default, so a topic without it does not build; and it decides which standard the topic is
+  held to, so the wrong value quietly applies the wrong rules. `xplat` for the DV set,
+  `xplat-unmapped` where its API cannot be resolved, `web-only` for the web platforms and no further.
+  Two traps: identity is not publication, so a topic can be `xplat` and reach no desktop platform; and
+  a per-platform code block or a non-`full` `apiTerms` is a finding on an xplat topic and perfectly
+  fine on a web-only one. `check-doc-scope.mjs` reports both, and house-style carries the contract.
 - D1 (Warning) `relatedComponents` is set but **Usage**'s **Do/Don't** guidance doesn't name the
   specific sibling(s) by name and link them — or vice-versa, it names a sibling that isn't listed in
   `relatedComponents`.

.ai/skills/igniteui-doc-topics/references/create-workflow.md

@@ -1,6 +1,6 @@
 # Create workflow
 
-Version: v3 · 2026-08-14 · igniteui doc-skill set. Content carried from SKILL.md v2 unchanged;
+Version: v4 · 2026-08-31 · igniteui doc-skill set. Content carried from SKILL.md v2 unchanged;
 restructured into this reference so the workflow can evolve without touching the router. Blueprints,
 mechanics, and the frontmatter contract live in `house-style.md`; run the rubric self-check from
 `audit-rubric.md` before delivering.
@@ -9,7 +9,7 @@ mechanics, and the frontmatter contract live in `house-style.md`; run the rubric
 
 1. **Classify** (Step 0 in SKILL.md). Name the topic type.
 2. **Pick the doc set & framework.** Angular set = its own file, plain prose. xplat set = one file
-   for React/WC/Blazor using `{Platform}`/`{ProductName}` tokens and `<PlatformBlock for="…">`. Load
+   for React/WC/Blazor/WinUI/Uno using `{Platform}`/`{ProductName}` tokens and `<PlatformBlock for="…">`. Load
    the relevant details from `house-style.md`.
 3. **Follow the verification workflow** in `house-style.md` before writing technical content.
    Existing snippets and old prose are clues, not authority. For component topics, also inspect the
@@ -28,6 +28,11 @@ mechanics, and the frontmatter contract live in `house-style.md`; run the rubric
 4. **Scaffold frontmatter** — the metadata contract lives in `house-style.md` → "File format &
    frontmatter"; this step orders the work, it does not restate the rules. Apply the contract to
    every topic type, including category/index topics.
+   - **First, for an xplat topic:** `platformType`, which is required and has no default — a topic
+     without it does not build, and it decides the standard the rest of the work is held to. `xplat`
+     for the DV set, `xplat-unmapped` where its API cannot be resolved, `web-only` for a topic that
+     ships for the web platforms and no further. It also settles `apiTerms`, which is then stated only
+     to differ. See house-style → "File format & frontmatter".
    - **Before the body (fixed by convention):** `title` (xplat component topics use the
      `{ComponentTitle}` token; xplat category/index topics use a concise, framework-neutral category
      name without `{Platform}` or `{ProductName}` tokens, for example `title: "Grids and Tables"`;

.ai/skills/igniteui-doc-topics/references/diataxis-cheatsheet.md

@@ -1,6 +1,6 @@
 # Diátaxis cheat-sheet
 
-Version: v3 · 2026-08-14 · igniteui doc-skill set (content unchanged; version line added for the
+Version: v4 · 2026-08-31 · igniteui doc-skill set (content unchanged; version line added for the
 set-wide match check). Before editing, confirm this version line against `.ai/skills/CHANGELOG.md`.
 
 Condensed from https://diataxis.fr (tutorials, how-to, reference, explanation, compass).

.ai/skills/igniteui-doc-topics/references/house-style.md

@@ -1,7 +1,7 @@
 # Ignite UI house style
 
-Version: v3 · 2026-08-14 · igniteui doc-skill set (content unchanged from v2; set-wide version
-bump). Before editing, confirm this version line against `.ai/skills/CHANGELOG.md`. The "File format & frontmatter" section below is the **single normative
+Version: v4 · 2026-08-31 · igniteui doc-skill set (v4 adds the xplat `apiTerms` contract and the
+`json-snippet` rule; content was unchanged from v2 through v3). Before editing, confirm this version line against `.ai/skills/CHANGELOG.md`. The "File format & frontmatter" section below is the **single normative
 field contract** for the doc-skill set; the two SKILL.md files reference it rather than restating it.
 
 The Ignite UI documentation conventions an authored or audited topic must follow. Pair this with
@@ -36,7 +36,7 @@ canonical section table below.
 | Doc set | Frameworks | Path (vnext) | Layout | One topic = |
 |---|---|---|---|---|
 | **Angular** | Angular only | `docs/angular/src/content/en/components/` | flat `*.mdx` | one framework |
-| **xplat** | React · Web Components · Blazor | `docs/xplat/src/content/en/components/<category>/` | categorized `*.mdx` | **one file, all three frameworks** |
+| **xplat** | React · Web Components · Blazor · WinUI · Uno | `docs/xplat/src/content/en/components/<category>/` | categorized `*.mdx` | **one file, all five frameworks** |
 
 The **same section list, order, and names apply to both sets.** Differences are mechanical only (see
 Per-framework mechanics), never the shape of the page. **Dependencies** appears in both sets — it
@@ -63,9 +63,31 @@ llms:
   description: "…"         # AI-facing one-liner; defines the component, not the page — the exact text an assistant quotes
 last_updated: "YYYY-MM-DD" # required for every topic; rendered by the site layout
 relatedComponents: [Toast, Banner]   # TARGET field — drives the Usage Do/Don't trigger (see below)
+platformType: xplat        # xplat: REQUIRED, no default — xplat | xplat-unmapped | web-only
 ---
 ```
 
+- **`platformType` (xplat) is required and has no default.** A missing or unknown value stops the
+  build. It also decides `apiTerms`, which a page then states only to differ: `xplat` implies `full`
+  (names in backticks resolved through the product's description metadata), `xplat-unmapped` implies `passthrough` (resolved
+  by rule, for an API no generator describes), `web-only` implies `none` (left as written, no
+  `ApiLink`). An xplat page may not state `none`; a topic that genuinely cannot resolve its names is
+  `xplat-unmapped`. `docs/xplat/API-TERMS.md` is normative; the `xplat-docs-api-links` skill is the
+  working guide.
+
+- **Three populations share the xplat content tree, held to different standards, and each page says
+  which it is.** The **DV set** — charts, gauges, maps, dashboard tile, data grid, spreadsheet,
+  toolbar, zoom slider — is `platformType: xplat`: canonical names in backticks resolved in full, and
+  a component stated as a `json-snippet` unless a platform-specific snippet is genuinely necessary.
+  `xplat-unmapped` is the same set where that treatment cannot be applied yet — the Excel library,
+  whose API no generator describes, and the data grid's accessibility topic, whose XAML shape is
+  undecided. **Web-only** topics — inputs, layouts, notifications, scheduling, themes, the web grid
+  families, grid lite — carry no such obligation: they may hand write a block per platform and declare
+  any mode, and reworking them to match the DV set is out of scope rather than an improvement.
+  **Identity is not publication:** a topic can be xplat and not reach the desktop platforms yet, so
+  where a page publishes never settles which population it is in. `check-doc-scope.mjs` enforces the
+  declaration and reports the disagreements; the `xplat-docs-json-snippets` skill is the working guide.
+
 - **`llms.description`** already exists in both sets and is high-value — write it as a crisp,
   self-contained answer sentence that **defines the component (or concept), never the page**: subject
   noun names the product and component, no pronouns, no "This topic shows…". It is *not* optional
@@ -113,21 +135,27 @@ import FaqItem from 'igniteui-astro-components/components/mdx/FaqItem.astro';
   - **Web Components** → **`igniteui-webcomponents`**, **`igc-`** tags / **`Igc…Component`** classes.
   - **React** → **`igniteui-react`**, a **wrapper around the `igc`** web components.
   - **Blazor** → **`igniteui-blazor`**, a **wrapper around the `igc`** web components.
-- **Net effect:** the **xplat doc set (React / WC / Blazor) is entirely `igc`-based** — WC is `igc`
-  directly; React and Blazor wrap it. The **Angular doc set is `igx`**.
+  - **WinUI** → **`Infragistics.*`** NuGet packages (e.g. `Infragistics.Core`,
+    `Infragistics.WinUI.Charts`), **XAML elements** / **`Xam…`** classes — native, not `igc`-based.
+  - **Uno Platform** → the same **`Infragistics.*`** NuGet packages and **`Xam…`** XAML classes as WinUI.
+- **Net effect:** the **web xplat platforms (React / WC / Blazor) are entirely `igc`-based** — WC is
+  `igc` directly; React and Blazor wrap it. **WinUI and Uno are native XAML/.NET (`Xam…`), not
+  `igc`-based.** The **Angular doc set is `igx`**.
 - **Exception — WC-first components in the Angular docs.** Some newer components are built as web
   components and surfaced in the Angular docs via the `igc` element rather than a native `igx` one
   (verified: the Angular **Rating** topic installs `igniteui-webcomponents`, registers
   `IgcRatingComponent`, and renders `<igc-rating>`). So **don't assume `igx` for every Angular topic** —
   verify the tag/class per component.
 - **Angular set:** plain prose, no platform tokens. Registers and renders whichever the component is
   (`igx-…` native, or the `igc-…` WC for the exceptions above).
-- **xplat set:** the *same file* serves React / WC / Blazor via:
+- **xplat set:** the *same file* serves React / WC / Blazor / WinUI / Uno via:
   - **Tokens** the build resolves: `{Platform}`, `{ProductName}`, `{PackageWebComponents}`,
     `{PackageReact}`, `{PackageBlazor}`, etc. Use them in title/description/keywords/headings and prose
     — never hard-code "React" where a token belongs.
   - **`<PlatformBlock for="WebComponents">…</PlatformBlock>`** to wrap framework-specific content
-    (install commands, imports, snippets). `for` values: `WebComponents`, `React`, `Blazor`.
+    (install commands, imports, snippets). `for` values: `React`, `WebComponents`, `Blazor`,
+    `WinUI`, `Uno`, plus the group aliases `Web` (the four web platforms) and `NonWeb` / `Xaml`
+    (both = WinUI + Uno). Prefer `for="Web"` for web-only content so it stays correct as platforms grow.
 - **Live samples** embed the same way in both sets:
   `<Sample src="/inputs/rating/basic" height={150} alt="{Platform} Rating Basic Example" />`
 - **API links** use `<ApiLink …>` rather than hand-written URLs so they resolve per framework.
@@ -161,7 +189,7 @@ Use this checklist when creating technical content or auditing an existing topic
 verification gaps; it does not edit the topic. Existing topic prose and snippets are evidence to check,
 not a source of truth.
 
-1. **Identify the target platform.** Angular/native `igx`, Web Components `igc`, React, or Blazor.
+1. **Identify the target platform.** Angular/native `igx`; Web Components `igc`, React, or Blazor (`igc`-based); or WinUI / Uno (native XAML/.NET, `Xam…`).
 2. **Verify public API facts through MCP first.** Use the Ignite UI/API docs MCP source for component
    types, properties, methods, events, and API-link targets.
 3. **If MCP is unavailable, use the official platform API docs.**
@@ -497,6 +525,15 @@ audits the body side.
   document a difference that doesn't exist; replace them with **one two-column table:
   variable · what it changes**. Don't add a defaults column either — defaults vary per theme and
   belong to the generated API reference, and the durable content is the variable's name and effect.
+- **An xplat (DV) topic states its component as a `json-snippet` by default.** Generation emits each
+  platform's own code from the product's description metadata, so the four to six copies cannot drift
+  apart and a property that does not exist cannot be published. A platform-specific snippet is
+  discouraged rather than banned: it stays the right tool where a definition genuinely cannot carry the
+  lesson — a data shape with no component in it, a namespace declaration, a package install, a step
+  only one platform family has — and the reason belongs wherever the change is recorded. **Web-only
+  topics are exempt**; a per-platform block there is not a defect. `docs/xplat/JSON-SNIPPETS.md` is normative and the
+  `xplat-docs-json-snippets` skill is the working guide. The rest of this bullet applies to the blocks
+  a topic still authors by hand — Angular's own topics, and the xplat sections a fence cannot state.
 - **Audit & modernize inline code snippets — not the samples.** Fenced code blocks (` ```… ```
   `) are authored in the topic, so verify and update them: no deprecated APIs or outdated framework
   idioms (drop `standalone: true`; prefer Angular's built-in control flow `@if`/`@for` over

.ai/skills/igniteui-topic-frontmatter/SKILL.md

@@ -13,7 +13,7 @@ description: >-
 
 # Ignite UI topic frontmatter
 
-Version: v3 · 2026-08-14 · igniteui doc-skill set. All set files carry this version line; before
+Version: v4 · 2026-08-31 · igniteui doc-skill set. All set files carry this version line; before
 editing any file, confirm the lines match across the set. The `.claude` adapter's `description` must
 byte-match this file's `description`. Change log: `.ai/skills/CHANGELOG.md` · human-readable intent:
 `.ai/skills/README.md`.