feat: regenerate Angular base project and update dependencies

.agents/README.md

@@ -24,7 +24,7 @@ Each procedure is written once, as a skill in `.agents/skills/` ([Agent Skills](
 | [`igniteui-cli-ai-config-skills-refresh`](./skills/igniteui-cli-ai-config-skills-refresh/SKILL.md) | Workflow | Bundled `ai-config` skills | Mirror the framework repositories' `skills/` into the `ai-config` templates. In `dry-run` mode: what changed upstream and content issues |
 | [`igniteui-cli-mcp-tool`](./skills/igniteui-cli-mcp-tool/SKILL.md) | Workflow | MCP server `src/`, tests, tool docs | Add an MCP server tool or change an existing one. Its `scripts/call-tool.mjs` calls a tool on the built server over stdio |
 | [`igniteui-cli-smoke-test`](./skills/igniteui-cli-smoke-test/SKILL.md) | Reference | — | Build, running one spec file, specs that guard templates, running the smoke test, checking kept projects, triaging failures ("Triaging a Run"), editing the script |
-| [`igniteui-cli-template-anatomy`](./skills/igniteui-cli-template-anatomy/SKILL.md) | Reference | — | Template layout per framework, model templates, every place versions are pinned, parity auditing ("Auditing Parity Across Frameworks") |
+| [`igniteui-cli-template-anatomy`](./skills/igniteui-cli-template-anatomy/SKILL.md) | Reference | — | Template layout per framework, model templates, how Angular projects are created from `ng new`, every place versions are pinned, parity auditing ("Auditing Parity Across Frameworks") |
 
 The workflows triage their own smoke runs; use the smoke-test skill directly for a run you started by hand.
 

.agents/skills/igniteui-cli-smoke-test/SKILL.md

@@ -6,7 +6,7 @@ license: MIT
 
 # Ignite UI CLI: Build, Template Specs, Smoke Test
 
-`scripts/smoke-test.sh` is the **only** check that a generated project actually installs and builds. Jasmine stubs `PackageManager.installPackages`, so a green Jasmine run says nothing about real npm resolution or TypeScript compilation of generated code. Run the build and the template specs first: they are fast and catch id and pin mistakes before a slow smoke run.
+`scripts/smoke-test.sh` is the **only** check that a generated project actually installs and builds. Jasmine stubs `PackageManager.installPackages` and the Angular CLI (`ng new` / `ng add`, which create every Angular project), so a green Jasmine run says nothing about real npm resolution, what the current Angular CLI generates, or TypeScript compilation of generated code. Run the build and the template specs first: they are fast and catch id and pin mistakes before a slow smoke run.
 
 ## Build and Template Specs
 
@@ -20,7 +20,8 @@ license: MIT
 
 | Spec | Guards |
 |---|---|
-| `spec/templates/angular-spec.ts` | Template ids exist; no file collisions between templates; every `igniteui-angular` pin in templates and project `package.json` equals `IGNITEUI_ANGULAR_PACKAGE` |
+| `spec/templates/angular-spec.ts` | Template ids exist; no file collisions between templates; every `igniteui-angular` pin in templates equals `IGNITEUI_ANGULAR_PACKAGE`; project templates carry none of the files the Angular CLI generates and the scaffold patches (`angular.json`, `package.json`, tsconfigs, `src/main.ts`) |
+| `spec/templates/angular-scaffold-spec.ts` | The Angular project scaffold, against the stubbed Angular CLI: command sequence, every patch to the generated `angular.json`, `package.json` and tsconfigs, the projects' `extras`, cleanup on failure |
 | `spec/templates/react-spec.ts` | Same, for all four `IGNITEUI_REACT_*` constants |
 | `spec/templates/webcomponents-spec.ts` | Ids and collisions only. It does **not** check version pins against the constants |
 | `spec/templates/template-contracts-spec.ts` | Every jQuery, React, Web Components and Blazor project and component template: matches its framework and project type, its template paths exist, it generates a config |
@@ -30,7 +31,7 @@ license: MIT
 The template specs for a framework run in about 15 seconds, after `npm run build`:
 
 ```bash
-npx jasmine spec/templates/angular-spec.js
+npx jasmine spec/templates/angular-spec.js spec/templates/angular-scaffold-spec.js
 npx jasmine spec/templates/react-spec.js spec/templates/template-contracts-spec.js
 npx jasmine spec/templates/webcomponents-spec.js spec/templates/template-contracts-spec.js
 ```
@@ -51,7 +52,7 @@ Preconditions: `npm run build` has run (the script refuses otherwise); `node` an
 
 Defaults: angular, react, webcomponents; default project template; all component templates. jQuery and Blazor are opt-in (`-f jquery`, `-f blazor`): jQuery needs ProGet credentials for 13 templates and has no build; Blazor needs the .NET SDK and has no component templates.
 
-`--all-projects` takes its list from `ig list`, so **hidden project templates** (`isHidden = true` in the project's `index.ts`, e.g. `base`, `side-nav-auth`, `ai-config`) are not scaffolded. Most reuse the `_base` / `_base_with_home` files; a hidden project with its own `files/package.json` (e.g. Angular `side-nav-auth`) is covered only by `scripts/smoke-test.sh -f <fw> -p <project-id>`. Hidden projects can also reuse another project's `files/` through `templatePaths` (Angular `side-nav-mini-auth` includes `side-nav-auth/files`, manifest included), so a change there needs a `-p` run for each project that pulls it in.
+`--all-projects` takes its list from `ig list`, so **hidden project templates** (`isHidden = true` in the project's `index.ts`, e.g. `base`, `side-nav-auth`, `ai-config`) are not scaffolded. Most reuse the `_base` / `_base_with_home` files; a hidden project with its own packages (a `files/package.json`, or Angular `extras` as in `side-nav-auth`) is covered only by `scripts/smoke-test.sh -f <fw> -p <project-id>`. Hidden projects can also reuse another project's `files/` through `templatePaths` (Angular `side-nav-mini-auth` includes `side-nav-auth/files` and its packages), so a change there needs a `-p` run for each project that pulls it in.
 
 Runs longer than a few minutes: use a long command timeout, or run it in the background with output redirected to a file and wait for the process to exit. The `Results:` line is not the end: when nothing failed and `--keep` is not set, the script deletes the generated projects after printing it. The script **wipes its `--out` directory at start**, so give each run its own directory (e.g. `--out output/smoke-react`, `--out output/smoke-react-projects`) when you need more than one run's results, and never run two at once into the same directory.
 
@@ -115,7 +116,7 @@ The test runners use browser mode with Playwright Chromium. If one fails because
 
 ## Mapping an Install Error Back to Source
 
-A pin in an install error comes from one of: the template's variant `index.ts` (`this.packages`), the framework's `constants.ts`, or a project template's `files/package.json`. See the template-anatomy skill.
+A pin in an install error comes from one of: the template's variant `index.ts` (`this.packages`), the framework's `constants.ts`, or a project template's `files/package.json`. An Angular project's own packages follow `IGNITEUI_ANGULAR_PACKAGE`: `igniteui-angular` at that range, the rest at whatever `ng add` and the project's `extras` resolve, so an install error there is an upstream peer conflict (template-anatomy skill, "Angular Projects").
 
 ## Mapping a Build Error Back to Template Source
 
@@ -150,7 +151,7 @@ End with the PASS/FAIL/SKIP totals, whether the run as a whole is trustworthy (n
 
 ## Constraints When Editing the Script
 
-- Every `ig` call must happen **before** `npm install` in a generated project. After install, `bin/execute.js` delegates to the project-local *published* CLI, so later calls would test the published CLI, not your local build.
+- Call the CLI through `cli` (which loads `packages/cli/lib/cli.js`), never `bin/execute.js`. The wrapper hands off to a project-local `igniteui-cli` whenever one is installed, and Angular projects install one during `ig new`, so calls through it would test the published CLI, not this checkout.
 - Keep the three-way step judgement (exit code, log scan, artifact) intact.
 
 ## Related Skills

.agents/skills/igniteui-cli-template-anatomy/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: igniteui-cli-template-anatomy
-description: "Template anatomy for Angular (igx-ts), React (igr-ts) and Web Components (igc-ts): folder layout, index.ts fields, placeholders, test files, groups, and every place an Ignite UI version is pinned. WHEN TO USE: adding or changing a component template, locating version pins, auditing template parity across frameworks. WHEN NOT TO USE: running builds, template specs or the smoke test (igniteui-cli-smoke-test)."
+description: "Template anatomy for Angular (igx-ts), React (igr-ts) and Web Components (igc-ts): folder layout, index.ts fields, placeholders, test files, groups, how Angular projects are created from `ng new`, and every place an Ignite UI version is pinned. WHEN TO USE: adding or changing a component template, changing what new Angular projects contain, locating version pins, auditing template parity across frameworks. WHEN NOT TO USE: running builds, template specs or the smoke test (igniteui-cli-smoke-test)."
 license: MIT
 ---
 
@@ -83,12 +83,30 @@ Angular has two styles. Pick the one the component library dictates:
 
 React imports components from `igniteui-react` (or `-grids`, `-charts`, `-gauges`) as `Igr*`. Web Components imports `Igc*Component` and calls `defineComponents(...)`.
 
+## Angular Projects
+
+`ig new` and the `ng-new` schematic create an Angular project with the Angular CLI, through `scaffold()` on `BaseIgxProject` (`packages/igx-templates/igx-ts/projects/_base/index.ts`; the steps live in `_base/scaffold.ts`):
+
+1. `ng new` (scss, routing, no SSR, zone.js), `ng add angular-eslint@<Angular major>`, `ng add igniteui-angular@<IGNITEUI_ANGULAR_PACKAGE range>`. `ng add` installs packages, so `--skip-install` only prints a warning. For the same reason the `ng-new` schematic rejects `--dry-run` (`isDryRun` in `packages/ng-schematics/src/ng-new/index.ts`, which reads the workflow's private `_dryRun`; re-check it after an Angular major). The AI config `ng add` writes is deleted; `ig new` and the schematic run their own. When a step fails, the project folder is removed.
+2. The project's `templatePaths` (`_base`, `_base_with_home`, the project's own `files/`) are laid over the generated project, placeholders substituted.
+3. `angular.json` and `package.json` get our deviations as patches (`patchAngularJson`, `patchPackageJson`, which also writes the `IGNITEUI_ANGULAR_PACKAGE` range over the `^<version>` that `ng add` saves); the tsconfigs get the types in the project's `extras`.
+4. `npm install` adds `playwright` and the packages in the project's `extras`: at their latest versions, or at the version an entry names.
+
+Project `files/` are an **overlay**: they hold only files we add or replace wholesale (app code, `README.md`, `ignite-ui-cli.json`, CI workflows, eslint config, `vitest-base.config.ts`, environments, `src/index.html`, `src/styles.scss`). The rest follows from that:
+
+- A change to a file `ng new` generates (`angular.json`, `package.json`, tsconfigs, `src/main.ts`) is a patch in `_base/scaffold.ts`, so the generated file keeps up with Angular. `spec/templates/angular-spec.ts` fails when a project's `files/` carries one of them.
+- A package or global type a project's code needs goes in its `extras` (`side-nav-auth` declares `authExtras`; `side-nav-mini-auth` reuses it). `extras` receives the project's Angular major: a package whose majors follow Angular's (`@angular/*`, `angular-auth-oidc-client`) is pinned to it, since its latest version would outrun the project's Angular once a new major ships.
+- Packages the overlay files use without an `extras` entry (`minireset.css`, `@igniteui/material-icons-extended`) come from `ng add igniteui-angular`; the smoke build fails if it stops adding them.
+- `IGNITEUI_ANGULAR_PACKAGE` in `constants.ts` sets the versions: `igniteui-angular` at that range, Angular at the newest major that range's `peerDependencies` allow (resolved with `npm view` when the project is created). Minors and patches arrive on their own; moving to a new major is a change to that one constant, after which the smoke test below must pass.
+
+Jasmine never runs the real CLI: `spec/helpers/angular-cli-stub.ts` stands in for `ng` and `npm` and writes the project a real `ng new` + `ng add` produce, and `spec/templates/angular-scaffold-spec.ts` checks the command sequence and every patch. When the real output changes shape (a patch fails in a smoke run), update the stub with it. Only the smoke test runs the real CLI, with network access; a change here needs a run over every Angular project template, the hidden `base`, `side-nav-auth` and `side-nav-mini-auth` included (smoke-test skill).
+
 ## Where Ignite UI Versions Are Pinned
 
 Pins live in three kinds of places. **Always regenerate the list with a search; never trust a remembered list.**
 
 1. `constants.ts` per framework (exported `name@range` strings).
-2. Project-template manifests: `<root>/projects/*/files/package.json`. Several projects carry their own copy (e.g. Angular `_base` and `side-nav-auth`; Web Components `_base` and `_base_with_home`).
+2. Project-template manifests: `<root>/projects/*/files/package.json`, e.g. Web Components `_base` and `_base_with_home`. Angular projects have none: their versions follow `IGNITEUI_ANGULAR_PACKAGE` ("Angular Projects").
 3. Hard-coded `this.packages = ["name@range", ...]` in variant `index.ts` files, used where no constant exists (Angular charts/gauges/maps family, `igniteui-grid-lite`, wrapped `igniteui-webcomponents`; Web Components `igniteui-dockmanager`). Some build the name at runtime, e.g. Angular dock-manager: `` `${resolvePackage(NPM_DOCK_MANAGER)}@~2.1.1` ``.
 
 Run **both** search patterns (ripgrep) over `packages/cli/templates` and `packages/igx-templates`, `*.ts` and `*.json`: