fix(ga-pin): quick-reference 两行跟到 GA;$like/$ilike 按「未裁」引用式豁免(#4977)

.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.

.changeset/ga-pin-residue-quickref-and-like-exemption-4977.md

@@ -0,0 +1,21 @@
+---
+---
+
+Clears the two GA-pin residues that were red on `main` itself, so every open PR stopped
+inheriting a red `Test (shard 3/4)` (objectui#4977). No published behaviour changes: the
+only files touched are a root doc and a test file.
+
+`QUICK_REFERENCE.md`'s "Current Release" block still quoted `@objectstack/spec` and
+`@objectstack/client` as `^17.0.0-rc.6` after the manifests moved to the `^17.0.0` GA
+range. Both rows now state the range their named anchor declares — the doc followed the
+manifest, the pin that derives the expectation was not loosened.
+
+The `@objectstack/spec` GA `FieldOperatorsSchema` added `$like` and `$ilike`, which no
+builder operator authors, so the #2942 reachability sweep in
+`packages/fields/src/widgets/__tests__/FilterConditionField.operators.test.ts` reported
+them by design. They are excluded through that gate's own citation mechanism as
+**undecided — see objectui#4911** (the open decision box on whether the visual filter
+builder should offer raw pattern matching), with the harvest condition written on the
+entry: a ruling on #4911 must either delete the members and add the operators, or restate
+the paragraph as a decision carrying its reopen condition. No operator was implemented and
+no other gate logic moved — the product ruling stays with the maintainer.

QUICK_REFERENCE.md

@@ -113,9 +113,9 @@ that test tells you to edit this block. The one exception is called out on its r
 
 - **Version:** 17.5.0 (the version every `@object-ui/*` manifest carries — they are one
   `fixed` group in `.changeset/config.json`, so a release moves all of them together)
-- **Spec:** `@objectstack/spec` ^17.0.0-rc.6 (declared by the root `package.json` and by
+- **Spec:** `@objectstack/spec` ^17.0.0 (declared by the root `package.json` and by
   `apps/console/package.json`)
-- **Client:** `@objectstack/client` ^17.0.0-rc.6 (declared by `apps/console/package.json`
+- **Client:** `@objectstack/client` ^17.0.0 (declared by `apps/console/package.json`
   and `packages/data-objectstack/package.json`)
 - **Node.js:** ≥ 22 (see root `engines.node`)
 - **pnpm:** ≥ 9 (the workspace pins `pnpm@10.31.0` via `packageManager`)

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',

packages/fields/src/widgets/__tests__/FilterConditionField.operators.test.ts

@@ -58,8 +58,33 @@ const noTypes = () => undefined;
  * it between @objectstack/spec 17.0.0-rc.2 and rc.5, and no builder operator
  * could author it. `containsCaseInsensitive` now does, so the entry is gone and
  * the parity assertion below is what holds that honest.
+ *
+ * `$like` and `$ilike` arrived with the `@objectstack/spec` 17.0.0 GA pin
+ * (objectui#4636). Their entry here is **undecided — see #4911**, and it claims
+ * nothing else: whether this builder should offer raw pattern matching at all is
+ * an authoring-surface question that has NOT been ruled on, so this is a CITED
+ * OPEN QUESTION, not a finding that the tokens should stay unauthorable. It was
+ * taken because the sweep below is red on `main` itself under the GA pin, which
+ * every open PR inherits (objectui#4977); the question keeps waiting on the
+ * maintainer either way.
+ *
+ * Harvest condition — a ruling on #4911 must change these two members or this
+ * paragraph. Neither survives the ruling untouched:
+ *
+ *   - ruled A (build the operators): delete both members and add the builder
+ *     operators that author them; the parity assertion below then holds that
+ *     honest, exactly as it did when objectui#4023 retired `$icontains`.
+ *   - ruled B (the builder will not offer raw pattern matching): rewrite this
+ *     paragraph as the refusal the ruling makes it — stated as a decision, with
+ *     the ruling's own reopen condition on the entry — and reopen #4911 if that
+ *     condition is ever met.
+ *
+ * Leaving it reading "undecided" after a ruling lands is the stale-exclusion rot
+ * this comment block already warns about, one level up: the ratchet below can
+ * only check that a member is still a spec operator, never that its reason is
+ * still the true one.
  */
-const KNOWN_UNREACHABLE = new Set(['$eq', '$between']);
+const KNOWN_UNREACHABLE = new Set(['$eq', '$between', '$like', '$ilike']);
 
 /** Pull the operator keys out of a `{ field: { $op: v } }` fragment. */
 function operatorsOf(frag: Record<string, any> | null): string[] {