feat: implement AI-powered requirement analysis with hidden internal pricing logic (#76)#83
Merged
Merged
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>
…store index - getPricingConfig: validate all numeric fields, feature prices, and multipliers - validateClassification: reject categories not in allowed pricing set - Trim description server-side before validation - PricingConfig.tsx: remove hardcoded DEFAULT_CONFIG with pricing values; load purely from Firestore with access-denied handling - Add firestore.indexes.json with composite index for estimations query (userId ASC + createdAt DESC) Co-Authored-By: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com>
…nt-side - Remove functions/ directory entirely (Cloud Functions require Blaze plan) - Install @google/generative-ai as frontend dependency - Move AI classification + deterministic cost computation to client-side estimationService with same two-phase architecture: Phase 1: Gemini classifies features (sees category names only, never prices) Phase 2: Client computes costs deterministically from pricing config - Pricing config read from Firestore with hardened validation and defaults - API key provided via VITE_GEMINI_API_KEY environment variable - Remove functions config from firebase.json, revert eslint ignores Co-Authored-By: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com>
…userId check - Make History button visible on mobile (remove hidden sm:flex) - Add empty response guard before JSON.parse of AI output - Validate userId is non-empty before Firestore write 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 to the dashboard. A new ChangesAI Estimation & Pricing Config
Sequence Diagram(s)sequenceDiagram
actor User
participant ProjectEstimation as ProjectEstimation Page
participant estimationService as estimationService.ts
participant Firestore as Firestore
participant GeminiAPI as Google Gemini API
User->>ProjectEstimation: Submit project description
ProjectEstimation->>estimationService: analyzeProject(description, userId)
estimationService->>Firestore: getDoc(pricingConfig/default)
Firestore-->>estimationService: pricing config or fallback to DEFAULT_PRICING
estimationService->>GeminiAPI: generateContent(classificationPrompt, JSON mode)
GeminiAPI-->>estimationService: JSON classification (projectType, complexity, features)
estimationService->>estimationService: validateClassification() → computeEstimate()
estimationService->>Firestore: addDoc(estimations, {userId, description, result, createdAt})
estimationService-->>ProjectEstimation: EstimationResult
ProjectEstimation-->>User: Render complexity badge, feature table, cost range, timeline
User->>ProjectEstimation: Load previous estimates
ProjectEstimation->>estimationService: fetchEstimationHistory(uid)
estimationService->>Firestore: query estimations where userId == uid, orderBy createdAt DESC
Firestore-->>estimationService: EstimationRecord[]
estimationService-->>ProjectEstimation: EstimationRecord[]
ProjectEstimation-->>User: Render expandable history list
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 8b9b6d3): https://servio-0--pr83-devin-1781986005-ai-rcnbq52k.web.app (expires Sat, 27 Jun 2026 20:08:08 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: 7
🧹 Nitpick comments (2)
src/dashboard/pages/ProjectEstimation.tsx (1)
214-217: ⚡ Quick winAccordion toggle is missing explicit expanded-state a11y attributes.
At Line 214, add
aria-expandedandaria-controls, and pair with anidon the expandable panel (Lines 247-255). This keeps the history disclosure state clear for assistive tech.Also applies to: 247-255
🤖 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 214 - 217, The accordion toggle button at line 214 is missing required accessibility attributes for assistive technology. Add the aria-expanded attribute set to the expanded state variable to indicate whether the panel is open or closed, and add an aria-controls attribute with a value that matches a panel id. Then add a corresponding id attribute with the same value to the expandable panel container at lines 247-255 to create the association between the button and the content it controls.src/dashboard/pages/PricingConfig.tsx (1)
31-52: ⚡ Quick winPricing schema/default constants are duplicated across UI and service.
PricingConfigshape/defaults here and insrc/dashboard/services/estimationService.tscan drift. Centralizing shared schema/defaults into one module would prevent subtle config/editor mismatch over time.🤖 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 31 - 52, The PricingConfig interface and EMPTY_CONFIG constant are duplicated across PricingConfig.tsx and estimationService.ts, which can cause them to drift over time. Create a new shared module (such as a constants or config file in the src/dashboard directory) and move the PricingConfig interface definition and EMPTY_CONFIG constant declaration there. Then update the imports in both PricingConfig.tsx and estimationService.ts to reference these definitions from the shared module instead of duplicating them locally.
🤖 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/dashboard/pages/PricingConfig.tsx`:
- Around line 107-124: The handleSave function does not validate the pricing
configuration before saving, allowing invalid states (multipliers or risk
factors of 0, maximumProjectCost less than minimumProjectCost) to be saved but
silently ignored by the estimator service. Add validation logic in the
handleSave function that checks the config object for these invalid conditions
before calling setDoc: verify all multipliers are greater than 0 (referenced in
the code around lines 377-383), verify the risk factor is greater than 0
(referenced around lines 469-479), and verify that maximumProjectCost is greater
than or equal to minimumProjectCost (checked in the range 409-442). If
validation fails, set an appropriate error message and return early without
saving, ensuring admins receive immediate feedback about invalid configurations.
In `@src/dashboard/pages/ProjectEstimation.tsx`:
- Around line 120-123: The motion.tr element's key prop uses only feature.name
which can cause collisions when repeated feature names are returned by the AI,
leading to incorrect React reconciliation. Change the key prop from using just
feature.name to a composite key that combines feature.name with the idx
parameter from the map function (for example, by concatenating them or using
template literals) to ensure each row has a guaranteed unique identifier.
In `@src/dashboard/services/estimationService.ts`:
- Around line 380-385: The createdAt timestamp in the estimation document is
being set using the client-side new Date().toISOString() call, which allows
users to manipulate the timestamp by adjusting their local system clock. Replace
this client-side timestamp generation with Firestore's serverTimestamp()
function in the addDoc call for the estimations collection. This ensures all
timestamps are generated server-side and cannot be tampered with by users,
maintaining proper record ordering and data integrity.
- Around line 334-378: The userId validation check is being performed too late
in the execution flow, after expensive operations like pricing retrieval, Gemini
API calls via model.generateContent(), and estimate computation via
computeEstimate(). Move the userId validation guard to the very beginning of the
function, before calling getPricingConfig() and before initializing the
GoogleGenerativeAI instance, so that the function fails fast if the user is not
authenticated without incurring unnecessary costs from external API calls.
- Around line 39-77: The DEFAULT_PRICING constant in estimationService.ts
exposes sensitive internal pricing rules in the frontend bundle. Move the
DEFAULT_PRICING object and PricingConfig type definition to a backend
service/module instead of keeping it in the frontend code. Create a backend API
endpoint that returns the pricing configuration, then update
estimationService.ts to fetch the pricing data from this endpoint rather than
using the hardcoded constant. This ensures pricing logic remains server-side and
inaccessible to client inspection.
- Around line 327-339: The Gemini API key stored in VITE_GEMINI_API_KEY is
exposed to browser code, creating a security vulnerability where users can
extract and abuse the API quota and billing. Move the GoogleGenerativeAI
initialization and the genAI.getGenerativeModel call to a backend service or
server function that has secure access to the API key. Instead of directly
initializing GoogleGenerativeAI and calling the model in this client-side code,
refactor this to call a backend endpoint that handles the Gemini API requests.
The backend should accept the feature categories and other necessary parameters
from the buildClassificationPrompt call and return the classification results,
while the client-side code should make an HTTP request to this backend endpoint
instead of directly using the API key.
- Around line 169-191: The code casts untrusted JSON data to objects without
first verifying they are actually objects, which can cause unexpected TypeErrors
if data is null, a primitive, or array entries are null. Before casting data to
Record<string, unknown> and accessing its properties, add a check to ensure data
is a non-null object type. Similarly, within the loop iterating over
obj.features, check that each element f is a non-null object before casting it
to Record<string, unknown> and accessing its properties. These type guards
should occur before any property access to ensure validation errors are thrown
as intended.
---
Nitpick comments:
In `@src/dashboard/pages/PricingConfig.tsx`:
- Around line 31-52: The PricingConfig interface and EMPTY_CONFIG constant are
duplicated across PricingConfig.tsx and estimationService.ts, which can cause
them to drift over time. Create a new shared module (such as a constants or
config file in the src/dashboard directory) and move the PricingConfig interface
definition and EMPTY_CONFIG constant declaration there. Then update the imports
in both PricingConfig.tsx and estimationService.ts to reference these
definitions from the shared module instead of duplicating them locally.
In `@src/dashboard/pages/ProjectEstimation.tsx`:
- Around line 214-217: The accordion toggle button at line 214 is missing
required accessibility attributes for assistive technology. Add the
aria-expanded attribute set to the expanded state variable to indicate whether
the panel is open or closed, and add an aria-controls attribute with a value
that matches a panel id. Then add a corresponding id attribute with the same
value to the expandable panel container at lines 247-255 to create the
association between the button and the content it controls.
🪄 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: 3e8cc990-e03b-4fb7-a118-cdec3e102070
⛔ Files ignored due to path filters (1)
package-lock.jsonis excluded by!**/package-lock.json
📒 Files selected for processing (9)
firebase.jsonfirestore.indexes.jsonpackage.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
+107
to
+124
| const handleSave = async () => { | ||
| if (!config) return; | ||
| 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.
The form accepts invalid configs that the estimator later discards silently.
At Lines 377-383 and 469-479, 0 is accepted for multipliers/risk factor; at Lines 409-442, no guard prevents maximumProjectCost < minimumProjectCost. In estimationService.ts, these states trigger fallback to DEFAULT_PRICING, so admins can “save” settings that never take effect.
Also applies to: 377-383, 409-442, 469-479
🤖 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 107 - 124, The handleSave
function does not validate the pricing configuration before saving, allowing
invalid states (multipliers or risk factors of 0, maximumProjectCost less than
minimumProjectCost) to be saved but silently ignored by the estimator service.
Add validation logic in the handleSave function that checks the config object
for these invalid conditions before calling setDoc: verify all multipliers are
greater than 0 (referenced in the code around lines 377-383), verify the risk
factor is greater than 0 (referenced around lines 469-479), and verify that
maximumProjectCost is greater than or equal to minimumProjectCost (checked in
the range 409-442). If validation fails, set an appropriate error message and
return early without saving, ensuring admins receive immediate feedback about
invalid configurations.
Comment on lines
+120
to
+123
| {result.features.map((feature, idx) => ( | ||
| <motion.tr | ||
| key={feature.name} | ||
| initial={{ opacity: 0, x: -10 }} |
There was a problem hiding this comment.
Feature row key is not guaranteed unique.
At Line 122, key={feature.name} can collide when AI returns repeated feature names, causing incorrect row reconciliation/animation behavior. Use a composite key (e.g., name + index/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/dashboard/pages/ProjectEstimation.tsx` around lines 120 - 123, The
motion.tr element's key prop uses only feature.name which can cause collisions
when repeated feature names are returned by the AI, leading to incorrect React
reconciliation. Change the key prop from using just feature.name to a composite
key that combines feature.name with the idx parameter from the map function (for
example, by concatenating them or using template literals) to ensure each row
has a guaranteed unique identifier.
Comment on lines
+39
to
+77
| const DEFAULT_PRICING: 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.
Internal pricing rules are exposed in the shipped client bundle.
At Line 39, DEFAULT_PRICING embeds base prices/multipliers directly in frontend code, so any client can inspect and extract internal pricing logic. This breaks the stated client/admin separation objective.
🤖 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/services/estimationService.ts` around lines 39 - 77, The
DEFAULT_PRICING constant in estimationService.ts exposes sensitive internal
pricing rules in the frontend bundle. Move the DEFAULT_PRICING object and
PricingConfig type definition to a backend service/module instead of keeping it
in the frontend code. Create a backend API endpoint that returns the pricing
configuration, then update estimationService.ts to fetch the pricing data from
this endpoint rather than using the hardcoded constant. This ensures pricing
logic remains server-side and inaccessible to client inspection.
Comment on lines
+169
to
+191
| 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" || | ||
| !allowedCategories.has(feat.category as string) || | ||
| !COMPLEXITIES.has(feat.complexity as string) | ||
| ) { |
There was a problem hiding this comment.
Validation dereferences untrusted JSON before confirming object shape.
At Lines 169-191, data/f are cast and accessed directly. If Gemini returns null, a primitive, or array entries like null, this can throw runtime TypeError before your intended "Invalid ..." errors.
Suggested hardening diff
function validateClassification(
data: unknown,
allowedCategories: Set<string>,
): AIClassification {
- const obj = data as Record<string, unknown>;
+ if (!data || typeof data !== "object" || Array.isArray(data)) {
+ throw new Error("Invalid classification structure");
+ }
+ const obj = data as Record<string, unknown>;
@@
const features: AIFeature[] = [];
for (const f of obj.features) {
+ if (!f || typeof f !== "object" || Array.isArray(f)) {
+ throw new Error("Invalid feature in classification");
+ }
const feat = f as Record<string, unknown>;🤖 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/services/estimationService.ts` around lines 169 - 191, The code
casts untrusted JSON data to objects without first verifying they are actually
objects, which can cause unexpected TypeErrors if data is null, a primitive, or
array entries are null. Before casting data to Record<string, unknown> and
accessing its properties, add a check to ensure data is a non-null object type.
Similarly, within the loop iterating over obj.features, check that each element
f is a non-null object before casting it to Record<string, unknown> and
accessing its properties. These type guards should occur before any property
access to ensure validation errors are thrown as intended.
Comment on lines
+327
to
+339
| const apiKey = import.meta.env.VITE_GEMINI_API_KEY as string | undefined; | ||
| if (!apiKey) { | ||
| throw new Error( | ||
| "AI service is not configured. Set VITE_GEMINI_API_KEY in your environment.", | ||
| ); | ||
| } | ||
|
|
||
| const pricing = await getPricingConfig(); | ||
| const featureCategories = Object.keys(pricing.featurePricing); | ||
| const classificationPrompt = buildClassificationPrompt(featureCategories); | ||
|
|
||
| const genAI = new GoogleGenerativeAI(apiKey); | ||
| const model = genAI.getGenerativeModel({ model: "gemini-1.5-flash" }); |
There was a problem hiding this comment.
Gemini API key is treated as a client secret, but it is public at runtime.
At Line 327, VITE_GEMINI_API_KEY is consumed in browser code; users can extract it and abuse quota/billing. This call path needs a trusted backend boundary (server/function proxy) for key custody.
🤖 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/services/estimationService.ts` around lines 327 - 339, The
Gemini API key stored in VITE_GEMINI_API_KEY is exposed to browser code,
creating a security vulnerability where users can extract and abuse the API
quota and billing. Move the GoogleGenerativeAI initialization and the
genAI.getGenerativeModel call to a backend service or server function that has
secure access to the API key. Instead of directly initializing
GoogleGenerativeAI and calling the model in this client-side code, refactor this
to call a backend endpoint that handles the Gemini API requests. The backend
should accept the feature categories and other necessary parameters from the
buildClassificationPrompt call and return the classification results, while the
client-side code should make an HTTP request to this backend endpoint instead of
directly using the API key.
Comment on lines
+334
to
+378
| const pricing = await getPricingConfig(); | ||
| const featureCategories = Object.keys(pricing.featurePricing); | ||
| const classificationPrompt = buildClassificationPrompt(featureCategories); | ||
|
|
||
| const genAI = new GoogleGenerativeAI(apiKey); | ||
| const model = genAI.getGenerativeModel({ model: "gemini-1.5-flash" }); | ||
|
|
||
| const result = await model.generateContent({ | ||
| contents: [ | ||
| { | ||
| role: "user", | ||
| parts: [ | ||
| { | ||
| text: `${classificationPrompt}\n\nProject description:\n${trimmed}`, | ||
| }, | ||
| ], | ||
| }, | ||
| ], | ||
| generationConfig: { | ||
| temperature: 0.3, | ||
| maxOutputTokens: 2048, | ||
| responseMimeType: "application/json", | ||
| }, | ||
| }); | ||
|
|
||
| const responseText = result.response.text(); | ||
| if (!responseText || responseText.trim().length === 0) { | ||
| throw new Error("AI returned an empty response. Please try again."); | ||
| } | ||
| let parsed: unknown; | ||
| try { | ||
| parsed = JSON.parse(responseText); | ||
| } catch { | ||
| throw new Error("Failed to parse AI response. Please try again."); | ||
| } | ||
|
|
||
| const classification = validateClassification( | ||
| parsed, | ||
| new Set(featureCategories), | ||
| ); | ||
| const estimation = computeEstimate(classification, pricing); | ||
|
|
||
| if (!userId) { | ||
| throw new Error("You must be signed in to save estimation history."); | ||
| } |
There was a problem hiding this comment.
Auth is validated too late, after expensive external work.
At Line 376, userId is checked only after pricing read + Gemini inference + estimate compute. If userId is missing, you still pay the AI call and then fail. Move this guard before Line 334.
🤖 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/services/estimationService.ts` around lines 334 - 378, The
userId validation check is being performed too late in the execution flow, after
expensive operations like pricing retrieval, Gemini API calls via
model.generateContent(), and estimate computation via computeEstimate(). Move
the userId validation guard to the very beginning of the function, before
calling getPricingConfig() and before initializing the GoogleGenerativeAI
instance, so that the function fails fast if the user is not authenticated
without incurring unnecessary costs from external API calls.
Comment on lines
+380
to
+385
| await addDoc(collection(db, "estimations"), { | ||
| userId, | ||
| description: trimmed, | ||
| result: estimation, | ||
| createdAt: new Date().toISOString(), | ||
| }); |
There was a problem hiding this comment.
History timestamp trusts client clock, weakening record integrity.
At Line 384, createdAt uses new Date().toISOString() from the browser. Users can skew local time and manipulate ordering/history consistency. Persist a trusted server-side timestamp and normalize on read.
🤖 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/services/estimationService.ts` around lines 380 - 385, The
createdAt timestamp in the estimation document is being set using the
client-side new Date().toISOString() call, which allows users to manipulate the
timestamp by adjusting their local system clock. Replace this client-side
timestamp generation with Firestore's serverTimestamp() function in the addDoc
call for the estimations collection. This ensures all timestamps are generated
server-side and cannot be tampered with by users, maintaining proper record
ordering and data integrity.
hrx01-dev
approved these changes
Jun 20, 2026
kumudranjan6127-debug
added a commit
to kumudranjan6127-debug/Servio
that referenced
this pull request
Jun 20, 2026
…d @google/generative-ai upstream/main added AI estimation (PR hrx01-dev#83) and admin RBAC (PR hrx01-dev#82) and reverted the broken vite-plugin-ssg prerender step (PR hrx01-dev#87). DashboardLayout conflict resolved: keep our Moon/Sun theme toggle imports alongside upstream's Sparkles/Settings2 for the new nav items. Install @google/generative-ai@^0.24.1 required by the new estimationService. Closes hrx01-dev#71 — theme toggle is already implemented in both the sidebar and mobile header of DashboardLayout; this merge makes it available to all authenticated users on the latest codebase. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
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. No Firebase Cloud Functions required — runs entirely client-side using the Gemini API directly.
Supersedes #77, #79, #80, #81 (closed due to branch protection rules and iterative review feedback).
Architecture (two-phase design, no Cloud Functions)
The AI prompt receives only feature category names for classification — no prices, multipliers, or formulas. All cost/timeline/explanation generation is deterministic code in
computeEstimate(). The Gemini API key is provided viaVITE_GEMINI_API_KEYenv var.What's new
src/dashboard/services/estimationService.ts— Client-side estimation engine:getPricingConfig()reads FirestorepricingConfig/default, merges with defaults, validates all numeric fields (prices >= 0, multipliers > 0, min <= max)buildClassificationPrompt()sends only category names to Gemini (no prices)validateClassification(data, allowedCategories)— strict type/enum/category validation rejects unknown categoriescomputeEstimate()— deterministic cost, timeline, and explanation generationsrc/dashboard/pages/ProjectEstimation.tsx— Client estimation page:src/dashboard/pages/PricingConfig.tsx— Admin pricing config page:firestore.indexes.json— Composite index forestimationsquery (userIdASC +createdAtDESC)Setup
VITE_GEMINI_API_KEY=<your-key>to.envfirebase deploy --only firestore:indexespricingConfigto admin-only accessCloses #76
Link to Devin session: https://app.devin.ai/sessions/c46ef0652e464fe8b81fbb3cc5147eb3
Requested by: @hrx01-dev
Summary by CodeRabbit