[finding] main is red on THREE independent counts at once, and two share one mechanism: a dependency bump lands without the in-repo range pin that asserts against it #4980

Filed unassigned by the PM dispatch seat (session session_01Y26DJEHSBhhAQ6wwfsHNza), measured while driving PR #4962 (objectstack#8815, a priority:p0 card) to green. ⛔ Not fixed here — no single lane owns all three, and one of them is a maintainer decision.

⚠️ main is red, so every open PR inherits it

Measured on PR #4962 at 1563d47 (which had just merged current main), run 32012778363. Three of four test shards failed, on three unrelated assertions. There are 8+ open PRs across several seats; none of them can go green.

Each was verified to be pre-existing rather than PR #4962's: shard 3/4 was reproduced on a clean origin/main worktree with none of that PR's changes present (grep -c isFilterValueComplete = 0, --frozen-lockfile), giving the identical failure. Shards 1/4 and 2/4 name files that PR touches not at all.

⭐ Two of the three are the SAME mechanism, which is why this is a class and not a list

Shards 1/4 and 2/4 are one fault: a test asserts that a generated/template manifest carries the same dependency range as the repo root, and a bump changed the root without updating the template. The tests are correct — that is exactly the drift they exist to catch — and they are doing their job. What is missing is that the bump and the pin are not landed together, so the gate fires after the bump is already on main rather than blocking it.

⚠️ Both bumps are automated (dependabot). This will recur on every dependabot batch that touches a range one of these templates mirrors, which means the cost is not "fix these two", it is "fix these two again next week". Two instances live simultaneously today is the measurement that makes it a class.

Known state per instance:

• lucide-react — a fix is already in flight as PR fix(templates): move the generator dependency ranges with today's dependabot wave #4969 (fix(cli): catch the app-generator lucide-react range up to the workspace).
• @testing-library/jest-dom — ⛔ no fix in flight that I can find. This is the one currently unowned.
• $like/$ilike — FilterConditionField cannot author spec 17.0.0 GA's new $like / $ilike — the same shape as the closed $icontains gap (#4023) #4911, open and needs-user-decision. ⛔ Not fixable by any seat: it asks whether the visual builder should offer pattern matching at all, which is an authoring-surface product call. I recorded on that card that its Blocked-by: #4636 precondition has now fired.

Suggested shape (⛔ not decided, and deliberately not attempted here)

For the recurring pair, the durable fix is to stop hand-mirroring: have the template read the root manifest's range at generation time (or generate the template's manifest from the root), so there is one source of the range and no second copy to drift. That converts "a test that catches drift after the fact" into "a structure with no drift to catch" — the same move this org has taken elsewhere (a derived value should be derived, not restated).

⚠️ A narrower option is to teach the dependabot flow to update the mirrored pins in the same PR, but that keeps two copies and relies on the automation knowing every mirror site — a list that is itself unenforced, which is the shape that produced this.

⛔ I did not just bump the two stale ranges to green the queue. It would take minutes, but it is another lane's surface, it leaves the mechanism intact, and it would not actually unblock anything while #4911 is undecided — so it would buy nothing and hide the class.

Re-check commands:

node --version && git log --oneline -6 origin/main
pnpm vitest run packages/create-plugin/src/__tests__/templates.test.ts
pnpm vitest run packages/cli/src/__tests__/app-generator.test.ts
pnpm vitest run packages/fields/src/widgets/__tests__/FilterConditionField.operators.test.ts

Refs: #4911 (the undecided third), PR #4969 (lucide fix in flight), PR #4962 and objectstack#8815 (where all three surfaced together), c1454a2 / 590dd63 (the two bumps).