fix(templates): move the generator dependency ranges with today's dependabot wave

.changeset/cli-app-generator-lucide-range-4968.md

@@ -0,0 +1,27 @@
+---
+'@object-ui/cli': patch
+---
+
+The routed temp app's generated manifest now asks for the same `lucide-react` range this repo installs.
+
+`utils/app-generator.ts` writes the routed variant's `dependencies` with two
+quoted third-party ranges, and `lucide-react` had fossilised a minor behind the
+22 sibling manifests that declare it: the generated manifest said `^1.29.0`
+while the repo had moved to `^1.31.0`. A generated app therefore asked npm for
+an icon library older than the one every `@object-ui/*` package it installs
+alongside was built against.
+
+The drift was not silent — `app-generator.test.ts` derives its expectation from
+the in-repo range precisely so a bump on one side and not the other fails a
+test, and both of its pins were red. What went wrong is that they went red too
+late to stop anything: the dependency PR that moved the repo range merged while
+those shards were still running, so the failure surfaced on `main` and then on
+the merge ref of every unrelated open PR. The range is now caught up; the
+reporting hole and the merge-ordering hole are filed separately (objectui#4968).
+
+The remaining eleven anchored ranges were swept against the same dependabot
+batch and are all in sync, so this is the batch's only consumer-side follow-up.
+Deriving the value from the workspace instead of quoting it was considered and
+rejected: nine of the thirteen anchored ranges quote the repo root manifest,
+which is not published with this CLI, so no single derivation can serve the
+table and a bespoke one for this one name would leave the class untouched.

.changeset/create-plugin-jest-dom-range-4968.md

@@ -0,0 +1,21 @@
+---
+'@object-ui/create-plugin': patch
+---
+
+A scaffolded plugin's generated manifest now asks for the same `@testing-library/jest-dom` range this repo installs.
+
+`src/templates.ts`'s `DEV_DEPENDENCIES` had fossilised one patch behind the repo
+root: the template said `^7.0.0` while the root manifest had moved to `^7.0.1`.
+`templates.test.ts`'s anchor rule caught it and was red on `main`.
+
+Same defect class, same day and same dependabot wave as the `lucide-react` drift
+in `@object-ui/cli`'s app generator, so both templates move together here — which
+is how the previous occurrence of this incident was handled too (objectui#4098 /
+PR objectui#4099 moved these same two templates in one PR). This one came from
+the dev-dependencies group bump rather than the single-package bump, and it was
+found only because the two ratchets live in different packages: the anchor rule
+throws on its first mismatch, so nothing reports the second template until the
+first is green.
+
+The remaining seven anchored ranges in this template were swept against the same
+wave and are all in sync.

packages/cli/src/utils/app-generator.ts

@@ -177,14 +177,31 @@ function buildAppDependencies(): Record<string, string> {
  * with an unsatisfiable import. Declaring it at the producer is the fix — the
  * alias becomes a workspace convenience rather than the only thing holding the
  * import up.
+ *
+ * Both ranges here are QUOTED from this repo, per the objectui#3742 /
+ * objectui#3754 anchoring discipline: `react-router-dom` from the root
+ * manifest, `lucide-react` from the sibling manifests that declare it (the root
+ * does not). `app-generator.test.ts`'s `DEPENDENCY_ANCHORS` names the anchor for
+ * each and fails when a bump on either side leaves this file behind — which is
+ * the whole reason the values are allowed to be literals at all.
+ *
+ * That gate is not decoration; it has fired. objectui#4968: a dependabot bump
+ * moved `lucide-react` across all 22 sibling manifests and this literal stayed
+ * a minor behind, so the pin went red on every open PR's merge ref until the
+ * literal caught up. Deriving the value instead was considered and rejected in
+ * that PR — 9 of the 13 anchored ranges quote the repo ROOT manifest, which is
+ * not published with this CLI, so there is no one derivation the whole table
+ * could share and a bespoke one for this single name would buy nothing. The
+ * durable cure is upstream of this file: the shards carrying the gate have to
+ * finish before a dependency PR can merge.
  */
 function buildRoutedAppDependencies(): Record<string, string> {
   const range = platformPackageRange();
   return {
     react: REACT_RANGE,
     'react-dom': REACT_RANGE,
     'react-router-dom': '^7.18.2',
-    'lucide-react': '^1.29.0',
+    'lucide-react': '^1.31.0',
     ...Object.fromEntries(PLATFORM_RUNTIME_PACKAGES.map((name) => [name, range]))
   };
 }

packages/create-plugin/src/templates.ts

@@ -59,7 +59,7 @@ export const VITEST_SETUP_FILE = 'vitest.setup.ts';
  *
  * | dependency                  | range     | anchor                                     |
  * | --------------------------- | --------- | ------------------------------------------ |
- * | `@testing-library/jest-dom` | `^7.0.0`  | repo root package.json (also apps/console) |
+ * | `@testing-library/jest-dom` | `^7.0.1`  | repo root package.json (also apps/console) |
  * | `@testing-library/react`    | `^16.3.2` | repo root package.json (also apps/console) |
  * | `@vitejs/plugin-react`      | `^6.0.5`  | every `packages/plugin-*` (not in root)    |
  * | `jsdom`                     | `^30.0.1` | repo root package.json                     |
@@ -84,7 +84,7 @@ export const VITEST_SETUP_FILE = 'vitest.setup.ts';
  * monorepo, not a failing install.
  */
 const DEV_DEPENDENCIES: Record<string, string> = {
-  '@testing-library/jest-dom': '^7.0.0',
+  '@testing-library/jest-dom': '^7.0.1',
   '@testing-library/react': '^16.3.2',
   '@vitejs/plugin-react': '^6.0.5',
   jsdom: '^30.0.1',