fix(install): support current TanStack Start setup and callback registration

[nicknisi]

Problem

A real TanStack Start install generated a valid app, but the CLI reported four false validation errors and then failed callback registration.

Two independent defects:

1. Package rules already declared @tanstack/react-start as an alternate, but the validator ignored alternates. File checks also assumed the older app/ layout, missing valid callback and middleware files under src/.
2. Dashboard callback setup passed the default userland application ID as setRedirectUris.applicationId. That argument resolves an AuthKit IDP application, so the real API returned Application not found.

Fix

• Honor package alternates while preserving dependency-location requirements.
• Recognize conventional TanStack app/routes and src/routes layouts, including nested, flat, index, and route files in TS/TSX/JS/JSX.
• Send the already client-ID-matched environmentId to setRedirectUris. Keep existing URI/default preservation, dry-run validation, concurrent-change checks, readback, and mandatory callback registration.
• Make application-setup mocks reject the wrong application-ID contract instead of allowing this defect to pass tests.

No general route parser, dashboard overwrite policy change, dependency change, or CI change.

Validation

• Reproduced all four validation errors against the reported app before the fix; afterward it validates with zero issues.
• Real API dry-run: userland applicationId failed with Application not found; matched environmentId returned RedirectUrisSet. Diagnostic probes did not write settings.
• Regression tests failed before the fixes and pass afterward.
• bun run test: 3,197 passed across 169 files.
• bun run typecheck, bun run lint, bun run build, and git diff --check passed.
• Independent review found no blockers.
• User reran the rebuilt installer and confirmed it worked. Full browser authentication flows were not independently verified.

[greptile-apps]

Confidence Score: 5/5

[Medium risk] Updates authentication setup validation and API contract.

The PR appears safe to merge; the remaining concern is non-blocking validation performance in large source trees.

Findings

1.  Broad globs cause many reads ▶

Fix with agent prompt

### Issue 1
src/lib/validation/validator.ts:195
When no file contains the expected pattern, this loop reads every matching file. The TanStack source rule matches all TS, TSX, JS, and JSX files under `app` and `src`, so validation of a large app can spend substantial time reading files just to produce a missing-pattern warning. A bounded or more targeted check would avoid that cost while still checking beyond the first match.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

Summary

The PR updates TanStack Start installation validation to recognize current package and route layouts, uses the matched environment ID for callback registration, and adds regression coverage. The follow-up commit makes file-pattern validation inspect all matches rather than only the first.

_{Reviews (2) · Last reviewed commit: "fix(validation): inspect all matching fi..."}

[greptile-apps]

Broad globs cause many reads
When no file contains the expected pattern, this loop reads every matching file. The TanStack source rule matches all TS, TSX, JS, and JSX files under app and src, so validation of a large app can spend substantial time reading files just to produce a missing-pattern warning. A bounded or more targeted check would avoid that cost while still checking beyond the first match.

Prompt To Fix With AI

This is a comment left during a code review.
Path: src/lib/validation/validator.ts
Line: 195

Comment:
**Broad globs cause many reads**
When no file contains the expected pattern, this loop reads every matching file. The TanStack source rule matches all TS, TSX, JS, and JSX files under `app` and `src`, so validation of a large app can spend substantial time reading files just to produce a missing-pattern warning. A bounded or more targeted check would avoid that cost while still checking beyond the first match.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!