Refine builder partner prompt flow#998
Open
tannerlinsley wants to merge 1 commit into
Open
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: ⛔ Files ignored due to path filters (2)
📒 Files selected for processing (17)
✅ Files skipped from review due to trivial changes (4)
🚧 Files skipped from review as they are similar to previous changes (13)
📝 WalkthroughWalkthroughThe PR refactors the Application Starter from an AI-driven analyze/generate flow to a single deterministic resolver, adds Lovable as a new hosting deploy partner, and introduces a unique-constraint system ( ChangesApplication Starter: Deterministic Resolver, Partner Constraints, and UI Refactor
Sequence Diagram(s)sequenceDiagram
participant User
rect rgba(99, 102, 241, 0.5)
Note over User,ApplicationStarter: Options reveal phase
User->>ApplicationStarter: Type input, click "Next"
ApplicationStarter->>useApplicationBuilder: submitCurrentInput()
useApplicationBuilder->>useApplicationBuilder: hasRevealedOptions = true
end
rect rgba(16, 185, 129, 0.5)
Note over ApplicationStarter,resolveApplicationStarterDeterministically: Resolution phase
useApplicationBuilder->>resolveApplicationStarterDeterministically: resolveSubmittedInput(submittedInput)
resolveApplicationStarterDeterministically-->>useApplicationBuilder: ApplicationStarterResult
useApplicationBuilder->>BuilderIntegration: applyResult(result, {silent?})
useApplicationBuilder-->>ApplicationStarter: result, showActionSection=true
end
rect rgba(245, 158, 11, 0.5)
Note over ApplicationStarter,HostingPartner: Deploy/copy phase
ApplicationStarter->>ApplicationStarter: renderSelectedHostingDeployButton()
User->>ApplicationStarter: Click "Deploy to Lovable/Netlify/..."
ApplicationStarter->>useApplicationBuilder: openLovableStart() / openNetlifyStart()
useApplicationBuilder->>HostingPartner: open URL with resolved prompt
end
Estimated code review effort🎯 4 (Complex) | ⏱️ ~90 minutes Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
src/utils/partners.tsx (1)
1557-1622:⚠️ Potential issue | 🟠 Major | ⚡ Quick winLet tier resolution see all inferred constraint matches.
Lines 1582-1583 make the first inferred partner for a unique constraint win before
getApplicationStarterCompatiblePartnerIdsruns on Line 1622. If input matches multiple hosting/auth partners, rule order can suppress a higher-tier partner, bypassing the intended tier-based compatibility resolution.Proposed fix
const blockedUniqueConstraints = new Set( selectedSourcePartners.flatMap(getPartnerUniqueConstraints), ) const inferredCategories = new Set<PartnerCategory>() - const inferredUniqueConstraints = new Set<PartnerUniqueConstraint>() const inferredPartnerIds = Array<string>() @@ const isBlockedByUniqueConstraint = partnerUniqueConstraints.some( - (uniqueConstraint) => - blockedUniqueConstraints.has(uniqueConstraint) || - inferredUniqueConstraints.has(uniqueConstraint), + (uniqueConstraint) => blockedUniqueConstraints.has(uniqueConstraint), ) @@ - if (hasUniqueConstraint) { - for (const uniqueConstraint of partnerUniqueConstraints) { - inferredUniqueConstraints.add(uniqueConstraint) - } - } else { + if (!hasUniqueConstraint) { inferredCategories.add(partner.category) }🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/utils/partners.tsx` around lines 1557 - 1622, The current code adds inferred partners to the inferredPartnerIds array during loop iteration, allowing rule order to suppress higher-tier partners before tier-based resolution can occur. Instead of immediately pushing partners to inferredPartnerIds when a rule matches, pass both the inferredPartnerIds array and the accumulated inferred constraints (inferredUniqueConstraints and inferredCategories sets) to the getApplicationStarterCompatiblePartnerIds function so it can perform proper tier-based compatibility resolution with complete visibility of all matching partners and their constraints, rather than having the loop iteration order pre-filter the candidates.src/components/ApplicationStarter.tsx (1)
359-535:⚠️ Potential issue | 🟠 MajorCompact mode doesn't expose final actions (copy/deploy)—
submitButtonis never passed by any compact mode callers.All three instances using
mode="compact"(CategoryArticle.tsx, StartLanding.tsx, RouterLanding.tsx) omit thesubmitButtonprop. Since line 921 renders{compact ? submitButton : null}, compact pages will render no action buttons. TheprimaryActionLabelandsecondaryActionLabelpassed to these components are only used in full mode. Either compact callers should passsubmitButtonwith the expected actions, or ApplicationStarter should auto-generate one from the label props when in compact mode.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/components/ApplicationStarter.tsx` around lines 359 - 535, The ApplicationStarter component in compact mode does not expose final action buttons because the submitButton prop is never passed by the three compact mode callers (CategoryArticle.tsx, StartLanding.tsx, and RouterLanding.tsx). Fix this by either modifying each of these three caller components to pass a submitButton prop containing copy and deploy actions when instantiating ApplicationStarter in compact mode, or alternatively modify the ApplicationStarter component to auto-generate the submitButton from the primaryActionLabel and secondaryActionLabel props when in compact mode and submitButton is not provided. Choose the approach that best fits the application architecture.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@src/components/ApplicationStarter.tsx`:
- Around line 311-316: The onSubmit handler in the ApplicationStarter component
calls generatePrompt() and submitCurrentInput() without checking
action-availability conditions that the buttons enforce, allowing keyboard
submissions to bypass validation. Add the same guard conditions used by the
buttons (checking hasMigrationRepositoryUrlError, empty input, and generating
state) to the onSubmit handler before executing either action to ensure keyboard
submits respect the same gating as button clicks.
In `@src/utils/application-starter.server.ts`:
- Around line 52-54: The issue is that
getInferredApplicationStarterPartnerIdsFromUserInput is being called with an
empty array for selected partners, which can result in inferred partner IDs that
conflict with partners already selected in request.input, diverging from how
buildRecipe handles partner filtering. To fix this, extract the compatible
selected partner IDs from request.input by calling
getApplicationStarterCompatiblePartnerIds on the selected partners in
request.input, store the result in a local variable before the return statement
to avoid recomputation, and then pass that local variable instead of the empty
array to getInferredApplicationStarterPartnerIdsFromUserInput so that inferred
partners are properly filtered against the selected partner constraints.
In `@src/utils/partners.tsx`:
- Around line 629-633: The applicationStarterPromptInstructions array at line
632 excludes Cloudflare, Netlify, and Railway from being added when Lovable is
selected, but Vercel should also be included in this exclusion list since it is
marked as a hosting-constrained partner in this file. Update the instruction
string that currently mentions "Cloudflare, Netlify, or Railway" to also include
"Vercel" in the list of hosting targets to avoid adding when Lovable is
selected.
---
Outside diff comments:
In `@src/components/ApplicationStarter.tsx`:
- Around line 359-535: The ApplicationStarter component in compact mode does not
expose final action buttons because the submitButton prop is never passed by the
three compact mode callers (CategoryArticle.tsx, StartLanding.tsx, and
RouterLanding.tsx). Fix this by either modifying each of these three caller
components to pass a submitButton prop containing copy and deploy actions when
instantiating ApplicationStarter in compact mode, or alternatively modify the
ApplicationStarter component to auto-generate the submitButton from the
primaryActionLabel and secondaryActionLabel props when in compact mode and
submitButton is not provided. Choose the approach that best fits the application
architecture.
In `@src/utils/partners.tsx`:
- Around line 1557-1622: The current code adds inferred partners to the
inferredPartnerIds array during loop iteration, allowing rule order to suppress
higher-tier partners before tier-based resolution can occur. Instead of
immediately pushing partners to inferredPartnerIds when a rule matches, pass
both the inferredPartnerIds array and the accumulated inferred constraints
(inferredUniqueConstraints and inferredCategories sets) to the
getApplicationStarterCompatiblePartnerIds function so it can perform proper
tier-based compatibility resolution with complete visibility of all matching
partners and their constraints, rather than having the loop iteration order
pre-filter the candidates.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: bfddbf6e-6091-4e33-9cff-2f74b177eb8c
⛔ Files ignored due to path filters (2)
src/images/lovable-black.svgis excluded by!**/*.svgsrc/images/lovable-white.svgis excluded by!**/*.svg
📒 Files selected for processing (15)
src/components/ApplicationStarter.tsxsrc/components/ApplicationStarterHotkeys.client.tsxsrc/components/application-builder/parts.tsxsrc/components/application-builder/shared.tssrc/components/application-builder/useApplicationBuilder.tsxsrc/components/builder/BuilderWorkspace.tsxsrc/components/builder/useBuilderUrl.tssrc/components/home/HomeApplicationStarter.tsxsrc/components/landing/RouterLanding.tsxsrc/components/landing/StartLanding.tsxsrc/components/stack/CategoryArticle.tsxsrc/utils/application-starter.server.tssrc/utils/application-starter.tssrc/utils/partner-pages.tssrc/utils/partners.tsx
Comment on lines
+52
to
54
| inferredPartnerIds: getApplicationStarterCompatiblePartnerIds( | ||
| getInferredApplicationStarterPartnerIdsFromUserInput(request.input, []), | ||
| recipe, | ||
| ), |
There was a problem hiding this comment.
Keep analysis partner inference aligned with selected-partner constraints.
Line 53 passes [] for selected partners, so inferredPartnerIds can still include a hosting/auth partner that conflicts with a partner already selected in request.input. That makes the analysis payload diverge from buildRecipe, which filters inferred partners against compatible selected partners before applying overrides.
Suggested fix
- inferredPartnerIds: getApplicationStarterCompatiblePartnerIds(
- getInferredApplicationStarterPartnerIdsFromUserInput(request.input, []),
- ),
+ inferredPartnerIds: getApplicationStarterCompatiblePartnerIds(
+ getInferredApplicationStarterPartnerIdsFromUserInput(
+ request.input,
+ getApplicationStarterCompatiblePartnerIds(
+ getApplicationStarterSelectedPartnerIds(request.input),
+ ),
+ ).filter(
+ (partnerId) =>
+ !hasApplicationStarterPartnerConflictWithAny(
+ partnerId,
+ getApplicationStarterCompatiblePartnerIds(
+ getApplicationStarterSelectedPartnerIds(request.input),
+ ),
+ ),
+ ),
+ ),Consider storing the compatible selected IDs in a local before the return to avoid recomputing them.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@src/utils/application-starter.server.ts` around lines 52 - 54, The issue is
that getInferredApplicationStarterPartnerIdsFromUserInput is being called with
an empty array for selected partners, which can result in inferred partner IDs
that conflict with partners already selected in request.input, diverging from
how buildRecipe handles partner filtering. To fix this, extract the compatible
selected partner IDs from request.input by calling
getApplicationStarterCompatiblePartnerIds on the selected partners in
request.input, store the result in a local variable before the return statement
to avoid recomputation, and then pass that local variable instead of the empty
array to getInferredApplicationStarterPartnerIdsFromUserInput so that inferred
partners are properly filtered against the selected partner constraints.
tannerlinsley
force-pushed
the
taren/builder-lovable-partner-flow
branch
7 times, most recently
from
e11804c to
e62ca0d
Compare
tannerlinsley
force-pushed
the
taren/builder-lovable-partner-flow
branch
from
e62ca0d to
ece0a3a
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What changed
/builderso integrations are visible immediately, prompt/CLI output refreshes as the starter input and options change, and selected hosting partners expose the relevant Deploy action./builderSummary prompt preview aligned with the exact prompt that Copy Prompt will copy.Why
Lovable needs to participate in gold partner rotation and in the builder prompt/deploy flow without adding latency or conflicting partner choices. The builder can now resolve the final prompt locally from the selected options instead of waiting on AI generation.
Validation
pnpm exec tsc --pretty falsepnpm run lint(passes with existing warnings)git diff --checkpnpm run format && pnpm run testsuccessfully; lint still reports the existing 10 warnings in unrelated files.Summary by CodeRabbit
Release Notes
New Features
Improvements