feat: implement AI-powered requirement analysis with hidden internal pricing logic (#76)#79
Closed
devin-ai-integration[bot] wants to merge 2 commits into
Closed
feat: implement AI-powered requirement analysis with hidden internal pricing logic (#76)#79devin-ai-integration[bot] wants to merge 2 commits into
devin-ai-integration[bot] wants to merge 2 commits into
Conversation
…ic (#76) - Add Firebase Cloud Function (analyzeProject) that reads pricing config from Firestore and calls Gemini API server-side, returning only safe client-facing data (features, complexity, cost range, timeline, explanation) - Add ProjectEstimation dashboard page for clients to submit project descriptions and receive instant AI-generated cost estimates - Add PricingConfig admin page to manage feature prices, complexity multipliers, and estimation rules in Firestore - Add estimation history with expandable records - Store all pricing logic, prompts, and formulas exclusively server-side; API responses never leak internal calculation data - Add routes (/dashboard/estimation, /dashboard/pricing-config) and sidebar navigation entries - Update firebase.json with functions configuration Co-Authored-By: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com>
…rministic pricing - AI prompt now only performs feature extraction/classification with category names (no prices, multipliers, or formulas ever sent to AI) - Cost calculation, timeline estimation, and explanation generation all happen deterministically server-side in computeEstimate() - getPricingConfig() now merges Firestore data with defaults and validates numeric bounds to prevent partial/corrupt config - validateClassification() performs thorough type/enum validation of AI output before any downstream processing - No free-form AI text is returned to the client; explanation is built server-side from classification metadata Co-Authored-By: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com>
Contributor
Author
🤖 Devin AI EngineerI'll be helping with this pull request! Here's what you should know: ✅ I will automatically:
Note: I can only respond to comments from users who have write access to this repository. ⚙️ Control Options:
|
📝 WalkthroughWalkthroughAdds an AI-powered project estimation feature end-to-end: a new Firebase callable Cloud Function ( ChangesAI Project Estimation Feature
Sequence Diagram(s)sequenceDiagram
actor User
participant ProjectEstimation as ProjectEstimation Page
participant estimationService as estimationService
participant analyzeProject as analyzeProject (Cloud Function)
participant Gemini as Gemini API
participant Firestore
User->>ProjectEstimation: enters description, clicks Analyze
ProjectEstimation->>estimationService: analyzeProject(description)
estimationService->>analyzeProject: httpsCallable("analyzeProject")
analyzeProject->>Firestore: getDoc("pricingConfig/default")
Firestore-->>analyzeProject: pricing overrides
analyzeProject->>Gemini: generateContent(classification prompt)
Gemini-->>analyzeProject: JSON feature classification
analyzeProject->>analyzeProject: validateClassification() + computeEstimate()
analyzeProject->>Firestore: addDoc("estimations", result)
analyzeProject-->>estimationService: EstimationResult payload
estimationService-->>ProjectEstimation: typed EstimationResult
ProjectEstimation->>User: renders cost range, features, timeline, explanation
Estimated code review effort🎯 4 (Complex) | ⏱️ ~60 minutes Possibly related PRs
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 |
|
Visit the preview URL for this PR (updated for commit 8631d59): https://servio-0--pr79-devin-1781984381-ai-53nc2f8i.web.app (expires Sat, 27 Jun 2026 19:41:09 GMT) 🔥 via Firebase Hosting GitHub Action 🌎 Sign: 15915abb5951eb298a844eda460b24f444d93a69 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 10
🤖 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 `@functions/src/index.ts`:
- Around line 145-167: The validateClassification() function validates that
feat.category is a string, but does not verify that it belongs to an allowed set
of pricing categories. This allows unknown categories to silently use fallback
pricing, which skews estimates. Add a check similar to the existing COMPLEXITIES
validation to ensure feat.category is in an allowed set of pricing categories.
You will need to define or reference a constant containing the valid pricing
category values, then add this to the condition check where feat.category
validation occurs.
- Around line 94-103: The validation check for the merged pricing configuration
only validates minimumProjectCost and maximumProjectCost using Number.isFinite,
but does not validate other numeric fields like bufferPercentage,
riskFactorMultiplier, feature prices, and multipliers which can still result in
NaN or negative values. Enhance the conditional validation statement to also
check that bufferPercentage, riskFactorMultiplier, and any other numeric pricing
fields in the merged object are finite and meet their valid ranges (such as
being non-negative). Apply the same validation enhancement to the second
occurrence mentioned at lines 216-221 to ensure consistent validation across
both locations.
- Around line 284-299: The description validation in the project creation
function does not trim whitespace, which allows whitespace-only strings to pass
the minimum length check. After extracting the description from request.data and
verifying it is a string, call the trim() method on the description variable to
remove leading and trailing whitespace. Then apply the existing length
validation checks (minimum 10 characters and maximum 5000 characters) to the
trimmed value. This ensures that strings containing only whitespace will be
normalized to empty strings and properly fail the minimum length validation.
- Around line 366-371: The estimations collection queries that filter by userId
and order by createdAt require a Firestore composite index that is currently
missing from the repository's configuration. Add the composite index definition
to firestore.indexes.json with collectionGroup set to "estimations" and include
the two required fields: userId in ASCENDING order and createdAt in DESCENDING
order. This will prevent the failed-precondition errors that occur in production
when these queries execute.
In `@src/app/App.tsx`:
- Around line 143-144: The pricing-config Route is currently accessible to any
authenticated user without role verification. Wrap the PricingConfig Route
element with an admin authorization check component (or conditionally render it
based on user admin status) to ensure only users with admin privileges can
access the pricing configuration page. Additionally, ensure the navigation item
that links to pricing-config is also conditionally rendered to only display for
users with admin role, maintaining consistency between available routes and UI
navigation.
In `@src/dashboard/pages/PricingConfig.tsx`:
- Around line 39-77: The DEFAULT_CONFIG object in PricingConfig.tsx contains
sensitive pricing information including featurePricing values,
complexityMultipliers, minimumProjectCost, maximumProjectCost, bufferPercentage,
and riskFactorMultiplier that should not be exposed in the frontend bundle.
Remove the entire DEFAULT_CONFIG constant definition and replace the hardcoded
pricing values with a server API call that fetches this configuration from a
backend endpoint instead, ensuring the pricing logic and values remain
server-only and secure.
- Around line 111-127: The handleSave function saves the config to Firestore
without validating that minimumProjectCost is not greater than
maximumProjectCost, causing invalid configurations to persist. Add validation
logic before the setDoc call that checks if minimumProjectCost exceeds
maximumProjectCost, and if so, set an appropriate error message and return early
to prevent the invalid config from being saved. This ensures that only valid
configurations with proper rule bounds are persisted to the database.
- Around line 98-101: The issue is that snap.data() is being cast directly to
PricingConfig without ensuring all required properties are present, which can
cause crashes when rendering code tries to call Object.entries() on undefined
fields like featurePricing or complexityMultipliers. Instead of directly casting
the data, merge the Firestore document data with safe default values for
PricingConfig before passing it to setConfig. This ensures all required fields
have fallback values if they are missing from the Firestore document.
In `@src/dashboard/pages/ProjectEstimation.tsx`:
- Around line 282-287: The handleSubmit function currently validates a minimum
10-character requirement for the description, but does not enforce the
advertised 5000-character maximum limit. Add an upper-bound validation check in
the handleSubmit function to ensure the trimmed description does not exceed 5000
characters, and set an appropriate error message if this limit is violated.
Additionally, add a maxLength attribute set to 5000 on the description input
field (located around lines 371-382) to provide client-side prevention of
exceeding the limit.
- Around line 339-345: The Button component with the handleLoadHistory onClick
handler that opens the history view is hidden on small mobile viewports due to
the className containing "hidden sm:flex". Remove or modify the "hidden" class
from the className prop so that the button remains visible on mobile screens,
ensuring users on all device sizes can access the estimation history
functionality.
🪄 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 Plus
Run ID: 7373c7c6-7a10-4939-9ba6-2090338769a6
📒 Files selected for processing (12)
eslint.config.jsfirebase.jsonfunctions/.gitignorefunctions/package.jsonfunctions/src/index.tsfunctions/tsconfig.jsonsrc/app/App.tsxsrc/dashboard/components/DashboardLayout.tsxsrc/dashboard/pages/PricingConfig.tsxsrc/dashboard/pages/ProjectEstimation.tsxsrc/dashboard/services/estimationService.tssrc/dashboard/types.ts
Comment on lines
+94
to
+103
| if ( | ||
| !Number.isFinite(merged.minimumProjectCost) || | ||
| !Number.isFinite(merged.maximumProjectCost) || | ||
| merged.minimumProjectCost > merged.maximumProjectCost | ||
| ) { | ||
| return DEFAULT_PRICING; | ||
| } | ||
|
|
||
| return merged; | ||
| } |
There was a problem hiding this comment.
Harden numeric config validation before using merged pricing data.
Current validation only checks minimumProjectCost/maximumProjectCost. Invalid bufferPercentage, riskFactorMultiplier, feature prices, or multipliers can still produce NaN/negative estimates.
Proposed fix
@@
- if (
- !Number.isFinite(merged.minimumProjectCost) ||
- !Number.isFinite(merged.maximumProjectCost) ||
- merged.minimumProjectCost > merged.maximumProjectCost
- ) {
+ const isFiniteNumber = (n: unknown): n is number =>
+ typeof n === "number" && Number.isFinite(n);
+
+ const validFeaturePricing = Object.values(merged.featurePricing).every(
+ (v) => isFiniteNumber(v) && v >= 0,
+ );
+ const validComplexityMultipliers = Object.values(
+ merged.complexityMultipliers,
+ ).every((v) => isFiniteNumber(v) && v > 0);
+
+ if (
+ !isFiniteNumber(merged.minimumProjectCost) ||
+ !isFiniteNumber(merged.maximumProjectCost) ||
+ !isFiniteNumber(merged.bufferPercentage) ||
+ !isFiniteNumber(merged.riskFactorMultiplier) ||
+ merged.minimumProjectCost < 0 ||
+ merged.maximumProjectCost < merged.minimumProjectCost ||
+ merged.bufferPercentage < 0 ||
+ merged.riskFactorMultiplier <= 0 ||
+ !validFeaturePricing ||
+ !validComplexityMultipliers
+ ) {
return DEFAULT_PRICING;
}Also applies to: 216-221
🤖 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 `@functions/src/index.ts` around lines 94 - 103, The validation check for the
merged pricing configuration only validates minimumProjectCost and
maximumProjectCost using Number.isFinite, but does not validate other numeric
fields like bufferPercentage, riskFactorMultiplier, feature prices, and
multipliers which can still result in NaN or negative values. Enhance the
conditional validation statement to also check that bufferPercentage,
riskFactorMultiplier, and any other numeric pricing fields in the merged object
are finite and meet their valid ranges (such as being non-negative). Apply the
same validation enhancement to the second occurrence mentioned at lines 216-221
to ensure consistent validation across both locations.
Comment on lines
+145
to
+167
| function validateClassification(data: unknown): AIClassification { | ||
| const obj = data as Record<string, unknown>; | ||
|
|
||
| if ( | ||
| typeof obj.projectType !== "string" || | ||
| !obj.projectType || | ||
| !COMPLEXITIES.has(obj.overallComplexity as string) || | ||
| !Array.isArray(obj.features) || | ||
| obj.features.length === 0 || | ||
| typeof obj.hasSignificantUnknowns !== "boolean" | ||
| ) { | ||
| throw new Error("Invalid classification structure"); | ||
| } | ||
|
|
||
| const features: AIFeature[] = []; | ||
| for (const f of obj.features) { | ||
| const feat = f as Record<string, unknown>; | ||
| if ( | ||
| typeof feat.name !== "string" || | ||
| !feat.name || | ||
| typeof feat.category !== "string" || | ||
| !COMPLEXITIES.has(feat.complexity as string) | ||
| ) { |
There was a problem hiding this comment.
Reject AI feature categories outside the allowed pricing categories.
validateClassification() accepts any category string. Unknown categories silently hit fallback pricing, which can materially skew estimates.
Proposed fix
@@
-function validateClassification(data: unknown): AIClassification {
+function validateClassification(
+ data: unknown,
+ allowedCategories: Set<string>,
+): AIClassification {
@@
- typeof feat.category !== "string" ||
+ typeof feat.category !== "string" ||
+ !allowedCategories.has(feat.category) ||
!COMPLEXITIES.has(feat.complexity as string)
@@
- classification = validateClassification(parsed);
+ classification = validateClassification(
+ parsed,
+ new Set(featureCategories),
+ );Also applies to: 355-356
🤖 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 `@functions/src/index.ts` around lines 145 - 167, The validateClassification()
function validates that feat.category is a string, but does not verify that it
belongs to an allowed set of pricing categories. This allows unknown categories
to silently use fallback pricing, which skews estimates. Add a check similar to
the existing COMPLEXITIES validation to ensure feat.category is in an allowed
set of pricing categories. You will need to define or reference a constant
containing the valid pricing category values, then add this to the condition
check where feat.category validation occurs.
Comment on lines
+284
to
+299
| const description = request.data?.description; | ||
| if (!description || typeof description !== "string") { | ||
| throw new HttpsError( | ||
| "invalid-argument", | ||
| "A project description is required.", | ||
| ); | ||
| } | ||
|
|
||
| if (description.length < 10) { | ||
| throw new HttpsError( | ||
| "invalid-argument", | ||
| "Please provide a more detailed project description (at least 10 characters).", | ||
| ); | ||
| } | ||
|
|
||
| if (description.length > 5000) { |
There was a problem hiding this comment.
Normalize and trim description on the server before validation.
Whitespace-only input can pass the minimum-length check today. Trim once server-side, then validate/store the normalized value.
Proposed fix
@@
- const description = request.data?.description;
- if (!description || typeof description !== "string") {
+ const rawDescription = request.data?.description;
+ if (typeof rawDescription !== "string") {
throw new HttpsError(
"invalid-argument",
"A project description is required.",
);
}
+ const description = rawDescription.trim();
@@
- if (description.length < 10) {
+ if (description.length < 10) {
throw new HttpsError(
"invalid-argument",
"Please provide a more detailed project description (at least 10 characters).",
);
}🤖 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 `@functions/src/index.ts` around lines 284 - 299, The description validation in
the project creation function does not trim whitespace, which allows
whitespace-only strings to pass the minimum length check. After extracting the
description from request.data and verifying it is a string, call the trim()
method on the description variable to remove leading and trailing whitespace.
Then apply the existing length validation checks (minimum 10 characters and
maximum 5000 characters) to the trimmed value. This ensures that strings
containing only whitespace will be normalized to empty strings and properly fail
the minimum length validation.
Comment on lines
+366
to
+371
| await db.collection("estimations").add({ | ||
| userId: request.auth.uid, | ||
| description, | ||
| result: estimation, | ||
| createdAt: new Date().toISOString(), | ||
| }); |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "Locating Firestore config files..."
fd -i 'firebase.json|firestore.*json'
INDEX_FILE="$(fd -i 'firestore.indexes.json' | head -n1 || true)"
if [[ -z "${INDEX_FILE}" ]]; then
echo "No firestore.indexes.json found."
exit 0
fi
echo "Checking indexes for collectionGroup=estimations..."
jq '.indexes[]
| select(.collectionGroup=="estimations")
| {collectionGroup, queryScope, fields}' "${INDEX_FILE}"
echo "Expected fields for this query pattern:"
echo '- userId (ASCENDING)'
echo '- createdAt (DESCENDING)'Repository: hrx01-dev/Servio
Length of output: 142
🏁 Script executed:
# Search for the query pattern on estimations collection
rg -i 'where.*userid|orderby.*createdat' --type ts --type js -A 3 -B 3
# Also search more broadly for history reads and estimations queries
rg 'estimations' --type ts --type js -A 5 -B 2 | head -100Repository: hrx01-dev/Servio
Length of output: 1596
🏁 Script executed:
# Check firebase.json structure and contents
cat firebase.jsonRepository: hrx01-dev/Servio
Length of output: 1002
🏁 Script executed:
# Look for firestore rules or other configuration files
fd -e rules -e rules.json -e firestore.rulesRepository: hrx01-dev/Servio
Length of output: 42
Add composite index configuration for estimations collection.
The query on estimations with where("userId", "==", uid) + orderBy("createdAt", "desc") (in src/dashboard/services/estimationService.ts) requires a Firestore composite index. This index is missing from the repository's configuration. Without it, production queries will fail with failed-precondition error. Add the index to firestore.indexes.json or Firebase console and commit the configuration:
{
"collectionGroup": "estimations",
"queryScope": "Collection",
"fields": [
{"fieldPath": "userId", "order": "ASCENDING"},
{"fieldPath": "createdAt", "order": "DESCENDING"}
]
}
🤖 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 `@functions/src/index.ts` around lines 366 - 371, The estimations collection
queries that filter by userId and order by createdAt require a Firestore
composite index that is currently missing from the repository's configuration.
Add the composite index definition to firestore.indexes.json with
collectionGroup set to "estimations" and include the two required fields: userId
in ASCENDING order and createdAt in DESCENDING order. This will prevent the
failed-precondition errors that occur in production when these queries execute.
Comment on lines
+143
to
+144
| <Route path="estimation" element={<ProjectEstimation />} /> | ||
| <Route path="pricing-config" element={<PricingConfig />} /> |
There was a problem hiding this comment.
Protect pricing-config with admin authorization, not auth-only routing.
Line 144 currently makes pricing admin controls available to any authenticated user. Add an admin-role gate at route level (and then conditionally expose the nav item) to enforce authorization consistently.
🤖 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/app/App.tsx` around lines 143 - 144, The pricing-config Route is
currently accessible to any authenticated user without role verification. Wrap
the PricingConfig Route element with an admin authorization check component (or
conditionally render it based on user admin status) to ensure only users with
admin privileges can access the pricing configuration page. Additionally, ensure
the navigation item that links to pricing-config is also conditionally rendered
to only display for users with admin role, maintaining consistency between
available routes and UI navigation.
Comment on lines
+39
to
+77
| const DEFAULT_CONFIG: PricingConfig = { | ||
| featurePricing: { | ||
| authentication: 5000, | ||
| dashboard: 15000, | ||
| payment_gateway: 12000, | ||
| real_time_features: 18000, | ||
| database_crud: 8000, | ||
| file_upload: 6000, | ||
| search_functionality: 7000, | ||
| notifications: 5000, | ||
| api_integration: 10000, | ||
| analytics: 8000, | ||
| user_management: 7000, | ||
| responsive_design: 4000, | ||
| seo_optimization: 3000, | ||
| social_login: 4000, | ||
| email_service: 5000, | ||
| chat_messaging: 14000, | ||
| maps_geolocation: 9000, | ||
| media_streaming: 16000, | ||
| cms_content_management: 12000, | ||
| ecommerce_cart: 15000, | ||
| order_management: 12000, | ||
| inventory_management: 10000, | ||
| reporting: 9000, | ||
| multi_language: 6000, | ||
| accessibility: 5000, | ||
| }, | ||
| complexityMultipliers: { | ||
| low: 1.0, | ||
| medium: 1.3, | ||
| high: 1.7, | ||
| enterprise: 2.2, | ||
| }, | ||
| minimumProjectCost: 10000, | ||
| maximumProjectCost: 500000, | ||
| bufferPercentage: 15, | ||
| riskFactorMultiplier: 1.1, | ||
| }; |
There was a problem hiding this comment.
Remove hardcoded pricing constants from the frontend bundle.
Line 39 onward ships internal pricing values (feature prices, multipliers, rules) to every client, which breaks the stated server-only pricing secrecy model.
🤖 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/dashboard/pages/PricingConfig.tsx` around lines 39 - 77, The
DEFAULT_CONFIG object in PricingConfig.tsx contains sensitive pricing
information including featurePricing values, complexityMultipliers,
minimumProjectCost, maximumProjectCost, bufferPercentage, and
riskFactorMultiplier that should not be exposed in the frontend bundle. Remove
the entire DEFAULT_CONFIG constant definition and replace the hardcoded pricing
values with a server API call that fetches this configuration from a backend
endpoint instead, ensuring the pricing logic and values remain server-only and
secure.
Comment on lines
+98
to
+101
| const snap = await getDoc(doc(db, "pricingConfig", "default")); | ||
| if (snap.exists()) { | ||
| setConfig(snap.data() as PricingConfig); | ||
| } |
There was a problem hiding this comment.
Merge Firestore config with safe defaults before setting state.
Line 100 casts raw document data directly to PricingConfig. A partial document can leave featurePricing/complexityMultipliers undefined and crash rendering at Object.entries(...).
Suggested fix
const snap = await getDoc(doc(db, "pricingConfig", "default"));
if (snap.exists()) {
- setConfig(snap.data() as PricingConfig);
+ const raw = snap.data() as Partial<PricingConfig>;
+ setConfig({
+ ...DEFAULT_CONFIG,
+ ...raw,
+ featurePricing: {
+ ...DEFAULT_CONFIG.featurePricing,
+ ...(raw.featurePricing ?? {}),
+ },
+ complexityMultipliers: {
+ ...DEFAULT_CONFIG.complexityMultipliers,
+ ...(raw.complexityMultipliers ?? {}),
+ },
+ });
}🤖 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/dashboard/pages/PricingConfig.tsx` around lines 98 - 101, The issue is
that snap.data() is being cast directly to PricingConfig without ensuring all
required properties are present, which can cause crashes when rendering code
tries to call Object.entries() on undefined fields like featurePricing or
complexityMultipliers. Instead of directly casting the data, merge the Firestore
document data with safe default values for PricingConfig before passing it to
setConfig. This ensures all required fields have fallback values if they are
missing from the Firestore document.
Comment on lines
+111
to
+127
| const handleSave = async () => { | ||
| setSaving(true); | ||
| setError(null); | ||
| setSuccess(false); | ||
|
|
||
| try { | ||
| await setDoc(doc(db, "pricingConfig", "default"), config); | ||
| setSuccess(true); | ||
| setTimeout(() => setSuccess(false), 3000); | ||
| } catch (err) { | ||
| setError( | ||
| err instanceof Error ? err.message : "Failed to save configuration.", | ||
| ); | ||
| } finally { | ||
| setSaving(false); | ||
| } | ||
| }; |
There was a problem hiding this comment.
Validate rule bounds before persisting config.
Line 117 saves even when minimumProjectCost > maximumProjectCost. That creates a persisted config the backend can reject/fallback from, causing admin UI state to diverge from effective estimation behavior.
Suggested fix
const handleSave = async () => {
setSaving(true);
setError(null);
setSuccess(false);
+ if (config.minimumProjectCost > config.maximumProjectCost) {
+ setError("Minimum project cost cannot exceed maximum project cost.");
+ setSaving(false);
+ return;
+ }
+
try {
await setDoc(doc(db, "pricingConfig", "default"), config);🤖 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/dashboard/pages/PricingConfig.tsx` around lines 111 - 127, The handleSave
function saves the config to Firestore without validating that
minimumProjectCost is not greater than maximumProjectCost, causing invalid
configurations to persist. Add validation logic before the setDoc call that
checks if minimumProjectCost exceeds maximumProjectCost, and if so, set an
appropriate error message and return early to prevent the invalid config from
being saved. This ensures that only valid configurations with proper rule bounds
are persisted to the database.
Comment on lines
+282
to
+287
| const handleSubmit = async (e: React.FormEvent) => { | ||
| e.preventDefault(); | ||
| if (!description.trim() || description.trim().length < 10) { | ||
| setError("Please provide a detailed project description (at least 10 characters)."); | ||
| return; | ||
| } |
There was a problem hiding this comment.
Enforce the advertised 5000-character limit.
Line 381 shows a /5000 counter, but there is no client-side cap (maxLength) and no submit-time upper-bound check.
Suggested fix
const handleSubmit = async (e: React.FormEvent) => {
e.preventDefault();
if (!description.trim() || description.trim().length < 10) {
setError("Please provide a detailed project description (at least 10 characters).");
return;
}
+ if (description.trim().length > 5000) {
+ setError("Project description must be 5000 characters or fewer.");
+ return;
+ }
@@
<textarea
id="project-description"
rows={6}
+ maxLength={5000}Also applies to: 371-382
🤖 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/dashboard/pages/ProjectEstimation.tsx` around lines 282 - 287, The
handleSubmit function currently validates a minimum 10-character requirement for
the description, but does not enforce the advertised 5000-character maximum
limit. Add an upper-bound validation check in the handleSubmit function to
ensure the trimmed description does not exceed 5000 characters, and set an
appropriate error message if this limit is violated. Additionally, add a
maxLength attribute set to 5000 on the description input field (located around
lines 371-382) to provide client-side prevention of exceeding the limit.
Comment on lines
+339
to
+345
| {!showHistory && ( | ||
| <Button | ||
| variant="outline" | ||
| size="sm" | ||
| onClick={handleLoadHistory} | ||
| className="hidden sm:flex items-center gap-2" | ||
| > |
There was a problem hiding this comment.
History is unreachable on mobile viewports.
Line 344 hides the only “History” trigger on small screens (hidden sm:flex), so users on mobile cannot open estimation history at all.
Suggested fix
- <Button
+ <Button
variant="outline"
size="sm"
onClick={handleLoadHistory}
- className="hidden sm:flex items-center gap-2"
+ className="flex items-center gap-2"
>📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| {!showHistory && ( | |
| <Button | |
| variant="outline" | |
| size="sm" | |
| onClick={handleLoadHistory} | |
| className="hidden sm:flex items-center gap-2" | |
| > | |
| {!showHistory && ( | |
| <Button | |
| variant="outline" | |
| size="sm" | |
| onClick={handleLoadHistory} | |
| className="flex items-center gap-2" | |
| > |
🤖 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/dashboard/pages/ProjectEstimation.tsx` around lines 339 - 345, The Button
component with the handleLoadHistory onClick handler that opens the history view
is hidden on small mobile viewports due to the className containing "hidden
sm:flex". Remove or modify the "hidden" class from the className prop so that
the button remains visible on mobile screens, ensuring users on all device sizes
can access the estimation history functionality.
Contributor
Author
|
Superseded — reopening with additional review fixes. |
This was referenced Jun 20, 2026
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.
Summary
Adds an AI-powered project estimation system where clients enter a natural-language project description and receive an instant cost/timeline estimate — while all pricing formulas, multipliers, and profit margins remain completely hidden server-side.
Architecture (secure two-phase design)
Key security property: the AI prompt never receives pricing values, multipliers, or formulas — it only gets feature category names for classification. All cost/timeline/explanation generation is deterministic server-side code in
computeEstimate(). This prevents prompt-injection attacks from leaking internal pricing.What's new
functions/src/index.ts— Firebase Cloud Function (analyzeProject):buildClassificationPrompt()sends only feature category names to AI (no prices)validateClassification()performs strict type/enum validation of AI outputcomputeEstimate()deterministically computes costs, timeline, and explanation from classification + pricing configgetPricingConfig()merges Firestore data with defaults, validates numeric boundssrc/dashboard/pages/ProjectEstimation.tsx— Client estimation page:src/dashboard/pages/PricingConfig.tsx— Admin pricing config page:pricingConfig/defaultin FirestoreDeployment prerequisites
firebase functions:secrets:set GEMINI_API_KEYcd functions && npm install && cd .. && firebase deploy --only functionspricingConfigcollection to admin-only access in Firestore security rulesCloses #76
Link to Devin session: https://app.devin.ai/sessions/c46ef0652e464fe8b81fbb3cc5147eb3
Requested by: @hrx01-dev
Summary by CodeRabbit