Claude/security fix 01 lq tyq gytw buo wpr5n e4wo w

[gadgetboy27]

Security developments

Summary by CodeRabbit

• New Features

  • AI-powered financial insights, spending analysis, and smart recommendations
  • Advanced budgeting system with savings goals and threshold alerts
  • Business banking capabilities including invoicing, VAT management, and client tracking
  • Enhanced transaction intelligence with automatic categorization and recurring pattern detection
  • Financial forecasting and comprehensive reporting tools
  • Multi-tier subscription system (Personal Free/Pro, Business Starter/Pro/Enterprise)
  • Receipt OCR processing for expense tracking

• Documentation

  • Added implementation guide, database schema documentation, and pricing strategy
  • Updated README with product overview and feature descriptions
  • Added security incident response documentation

• Chores

  • Improved environment configuration and credential management
  • Added UI component dependencies

[vercel]

@claude is attempting to deploy a commit to the JS Mastery Pro Team on Vercel.

A member of the Team first needs to authorize it.

[coderabbitai]

Walkthrough

Implements a comprehensive AI-powered smart wallet banking system with subscription tiers, multi-collection database schema, environment-driven configuration, business features (VAT, invoicing, receipts), budgeting, AI insights, financial reporting, and extensive documentation covering implementation, database design, and pricing strategy.

Changes

Cohort / File(s)	Summary
Environment & Configuration .env, .env.example, .gitignore	.env cleared of all credentials for security. .env.example expanded with test tokens, Plaid/Dwolla/Anthropic/Sentry configs, and sandbox defaults. .gitignore updated to ignore .env, .env.local, and variant environment files.
Documentation & Schema DATABASE_SCHEMA.md, IMPLEMENTATION_GUIDE.md, PRICING_STRATEGY.md, SECURITY.md, README.md, README_SMART_WALLET.md	Six new comprehensive documentation files: database schema covering 19 collections with relationships; implementation guide detailing four phased features; pricing strategy with Personal/Business tiers and revenue projections; security incident report with remediation; completely rewritten README with marketing-oriented content and quick-start; feature-focused Smart Wallet README with architecture and examples.
Type Definitions types/extended.d.ts	Extensive TypeScript declarations for subscription models, enhanced transactions, budgets, savings goals, business entities, VAT configurations, invoicing, receipts, AI insights, forecasting, alerts, user preferences, and UI component props.
Subscription & Constants constants/subscription.ts, constants/subscription-revised.ts, constants/index.ts	subscription.ts introduces four-tier subscription system with feature gates, usage limits, pricing, trials, and paywall messaging. subscription-revised.ts provides enhanced two-product (Personal/Business) tier structure with utility helpers and conversion strategies. index.ts migrates hardcoded test credentials to environment variables.
Server Actions: AI & Insights lib/actions/ai.actions.ts	New module: AI query handling with Anthropic Claude integration, financial insights generation, tax insights, cashflow forecasting, anomaly detection, spending pattern analysis, and smart recommendations. All features gated by subscription tier and usage limits.
Server Actions: Budgets & Goals lib/actions/budget.actions.ts	Complete CRUD for budgets (with per-tier creation limits), savings goals, and integrated alert system. Tracks spending updates, generates threshold/overage alerts, computes budget summaries, and respects subscription constraints.
Server Actions: Business & Invoicing lib/actions/business.actions.ts	Full domain operations for business entities, VAT configurations, clients, projects, invoices, and receipts. Includes VAT calculation (inclusive/exclusive modes), invoice numbering, OCR receipt processing, and client total updates on payment. Feature-gated creation and access controls.
Server Actions: Transactions & Categorization lib/actions/categorization.actions.ts	Transaction categorization with auto-categorization (rule-based, AI-gated), recurring pattern detection, spending aggregation by category/merchant, and category insights. Bulk operations and filters for comprehensive transaction enrichment.
Server Actions: Reporting lib/actions/reports.actions.ts	Financial report generation: Profit & Loss, Balance Sheet, Cash Flow, VAT Return, Expense, Income, and Tax Summary. Each report validates feature access, aggregates categorized transactions, and persists to database.
Server Actions: Subscriptions lib/actions/subscription.actions.ts	Subscription lifecycle management: fetch/create/update user subscriptions, feature access checks with upgrade hints, usage limit enforcement, trial initiation/termination, cancellation, and feature access summary generation.
Dependencies package.json	Added Radix UI components (buttons, dialogs, dropdowns, forms, etc.), charting libraries, date utilities, and auxiliary packages for enhanced UI and functionality. No removals; only additions.

Sequence Diagram(s)

sequenceDiagram
    actor User
    participant App as App
    participant Sub as Subscription<br/>Service
    participant Feature as Feature<br/>Gate
    participant Action as Action<br/>(AI/Budget/etc)
    participant DB as Database

    User->>App: Request feature (e.g., AI Insight)
    App->>Sub: getUserSubscription(userId)
    Sub->>DB: Fetch subscription tier
    DB-->>Sub: Return tier + features
    Sub-->>App: Subscription data
    
    App->>Feature: checkFeatureAccess(userId, "aiInsights")
    Feature->>Sub: Get subscription details
    Sub-->>Feature: Tier + features
    Feature-->>App: { allowed: boolean, tier, upgrade? }
    
    alt Access Granted
        App->>Action: Execute action (e.g., generateFinancialInsights)
        Action->>Feature: Verify usage limit
        Feature->>DB: Check usage metrics
        DB-->>Feature: Current usage
        Feature-->>Action: { allowed: boolean, remaining: number }
        
        alt Within Limit
            Action->>DB: Fetch user financial data
            DB-->>Action: Transactions, budgets, etc.
            Action->>Action: Process (AI call, aggregation, etc.)
            Action->>DB: Store result
            DB-->>Action: Confirm
            Action-->>App: Result
            App-->>User: Display insight/report
        else Limit Exceeded
            Action-->>App: Usage limit error
            App-->>User: Show upgrade prompt
        end
    else Access Denied
        Feature-->>App: { allowed: false, upgrade: "pro" }
        App-->>User: Display paywall with upgrade hint
    end

Loading

Estimated code review effort

🎯 5 (Critical) | ⏱️ ~120 minutes

Areas requiring particular attention:

• lib/actions/business.actions.ts: Complex VAT calculation logic (inclusive vs. exclusive modes), invoice numbering, cascading client total updates, and OCR receipt processing—requires careful verification of financial accuracy and state consistency.
• lib/actions/subscription.actions.ts and constants/subscription-revised.ts: Dual subscription tier systems (basic and revised) with overlapping feature definitions—clarify intended structure and ensure no conflicts in feature gating across codebase.
• lib/actions/ai.actions.ts: Anthropic Claude integration, feature gating, and usage limit enforcement—verify API call safety, rate limiting, and context assembly for financial queries.
• constants/index.ts: Migration from hardcoded test credentials to environment variables—confirm all fallback values are safe and that sensitive data is not leaked in defaults.
• SECURITY.md: Incident documentation explicitly mentions exposed production credentials (Appwrite, Plaid, Dwolla, hardcoded tokens)—verify all credentials have been rotated and secrets are properly managed.
• Type definitions in types/extended.d.ts: Massive new type surface (19+ interfaces)—validate consistency, naming conventions, and relationships between subscription, transaction, business, and AI types.
• Database schema documentation (DATABASE_SCHEMA.md): Verify 19 collections align with action implementations and test data setup.

Poem

🐰 With whiskers twitching, tails held high,
We've built a wallet to the sky—
From budgets, goals, and AI's gleam,
To invoices and forecasts supreme.
Subscription tiers now set the stage,
A fintech adventure, page by page! 🚀

Pre-merge checks and finishing touches

❌ Failed checks (1 warning, 1 inconclusive)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 60.87% which is insufficient. The required threshold is 80.00%.	You can run @coderabbitai generate docstrings to improve docstring coverage.
Title check	❓ Inconclusive	The pull request title 'Claude/security fix 01 lq tyq gytw buo wpr5n e4wo w' is vague and contains noise (random alphanumeric characters), making it unclear what specific security issue was addressed despite the PR making substantial changes including environment variable handling, subscription systems, AI features, and business logic.	Replace with a clear, descriptive title summarizing the main security fix or primary change, e.g., 'Security: Remove hardcoded credentials from .env and implement environment-based configuration' or 'Add AI-powered banking features with subscription tiers and security hardening'.

✅ Passed checks (1 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 47

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

package.json (1)

12-59: Upgrade jspdf to version 3.0.2 or higher to resolve HIGH severity vulnerabilities.

GitHub security advisories reveal jspdf version 2.5.1 is vulnerable to recent HIGH severity exploits:

• Denial of Service (DoS) vulnerability (2025-08-26, patched in 3.0.2)
• Regular Expression Denial of Service (ReDoS) (2025-03-18, patched in 3.0.1)

Update package.json: "jspdf": "^3.0.2" instead of ^2.5.1.

Other checked dependencies (jspdf-autotable, tesseract.js, @anthropic-ai/sdk, zustand, recharts, sonner) are free from known vulnerabilities matching the pinned versions.

♻️ Duplicate comments (3)

types/extended.d.ts (1)

350-367: RecurringTransaction.detectedTransactionIds vs stored detectedTransactionIdsJSON

The interface models an array:

detectedTransactionIds: string[];

while createRecurringPattern persists detectedTransactionIdsJSON: JSON.stringify([]) and detectRecurringTransactions returns documents without decoding.

Aligning these (either by changing the stored field name/type or by mapping on read) will make RecurringTransaction objects more predictable and type-safe.

lib/actions/ai.actions.ts (1)

384-413: analyzeSpendingPatterns depends on getSpendingByCategory’s incomplete implementation

analyzeSpendingPatterns computes:

avgMonthly: (cat.amount / period) * 30,

but getSpendingByCategory currently never populates amount (it stays at 0) and ignores the date range. As a result, all avgMonthly values will be 0 and trend/percentageChange are hard-coded.

Once getSpendingByCategory is fixed to aggregate real amounts and respect dates, this function will become meaningful. Until then, consider:

• Marking this as experimental and avoiding use in user-facing analytics, or
• Returning only categories and counts, with a more conservative name/typing.

lib/actions/budget.actions.ts (1)

8-13: Same access-control concern as other admin-based actions

Like the categorization and AI modules, all budget/goal/alert functions use an Appwrite admin client and trust the userId argument for scoping. Ensure userId always comes from authenticated server-side context and isn’t client-controlled; otherwise, a caller could operate on another user’s data.

Longer term, you might want a thin wrapper that derives userId internally from the session and removes it from public function parameters to make this invariant harder to break.

Also applies to: 21-25

🧹 Nitpick comments (18)

.gitignore (1)

29-34: Redundant gitignore entries.

Lines 31-34 are redundant since the pattern .env*.local on line 30 already matches these files. Only line 29 (.env) is strictly necessary as a new addition. However, this is a minor maintainability issue and doesn't impact functionality.

Apply this diff to remove redundant entries:

 .env
 .env*.local
-.env.local
-.env.development.local
-.env.test.local
-.env.production.local

.env.example (1)

62-62: Add ending blank line.

Add a blank line at the end of the file to comply with POSIX standards and avoid issues with certain text processing tools.

Based on static analysis hints.

Apply this diff:

 # SENTRY (Optional - for error tracking)
 SENTRY_DSN=
+

DATABASE_SCHEMA.md (1)

111-122: Consider structured data instead of JSON strings.

Lines 117 (vatRatesJSON) and similar JSON string fields throughout the schema (e.g., lines 158, 179, 182, 226, 238, 260, 274, 284-286, 296) store structured data as strings. This approach:

• Prevents querying nested fields
• Loses type safety
• Makes validation difficult
• Complicates indexing

Consider using Appwrite's support for nested documents or creating separate collections for complex relationships.

constants/index.ts (1)

26-44: Add runtime validation for required environment variables.

Empty string fallbacks (|| "") could cause silent failures at runtime if environment variables are not set. Consider adding validation to fail fast during initialization.

Add validation at the end of the file:

// Validate required test environment variables
if (process.env.NODE_ENV === 'development') {
  const requiredTestVars = [
    'NEXT_PUBLIC_TEST_USER_ID',
    'PLAID_TEST_ACCESS_TOKEN',
    'NEXT_PUBLIC_TEST_ITEM_1_ID',
    'NEXT_PUBLIC_TEST_ITEM_1_PLAID_ID',
    'NEXT_PUBLIC_TEST_ACCOUNT_1_ID',
  ];
  
  const missing = requiredTestVars.filter(varName => !process.env[varName]);
  
  if (missing.length > 0) {
    console.warn(
      `⚠️  Missing test environment variables: ${missing.join(', ')}\n` +
      `Set these in your .env file for full test functionality.`
    );
  }
}

README_SMART_WALLET.md (2)

67-137: Add explicit languages to checklist code fences (markdownlint MD040).

All the checklist-style blocks (e.g., under “Smart Categorization”, “Budget Tracking”, “Savings Goals”, “Business Mode”, “VAT/Tax Management”, “Invoicing System”, “Client & Project Tracking”, “Receipt Management”, etc.) use bare triple backticks without a language, which triggers MD040.

Recommend marking them as plain text:

-#### Smart Categorization
-```
+#### Smart Categorization
+```text
 ✅ 40+ categories (income, expenses, business)
 ...
-```
+```

-#### Budget Tracking
-```
+#### Budget Tracking
+```text
 ✅ Weekly/Monthly/Quarterly/Yearly budgets
 ...
-```
+```

Apply the same text language to the other checklist fences flagged by markdownlint (lines 67, 76, 85, 97, 105, 114, 123, 131, 143, 155, 165, 175, 187, 206, 214, 232).

Also applies to: 187-236

---

510-510: Replace bold line with a proper heading (markdownlint MD036).

The line:

**Built with ❤️ for the future of personal & business finance**

is flagged as “emphasis used instead of a heading”. Consider:

-**Built with ❤️ for the future of personal & business finance**
+### Built with ❤️ for the future of personal & business finance

This keeps the intent while satisfying the linter.

IMPLEMENTATION_GUIDE.md (2)

131-151: Qualify strong compliance claims (UK/EU banking, HMRC MTD, GDPR).

The guide states that VAT/tax flows are “Compliant with current UK/EU banking practices”, “HMRC MTD compliant”, and “GDPR compliant data handling”. Given the underlying code (e.g., simplified VAT/tax calculations and generic data-protection notes), these claims are easy to over-interpret as legal/regulatory guarantees.

I recommend either:

• Rephrasing to “designed to support” or “aims to be compatible with” PSD2/MTD/GDPR, or
• Adding an explicit disclaimer that legal compliance depends on deployment configuration, contracts, and external integrations, not just this code.

Also applies to: 261-266, 434-442

---

399-402: Clarify or implement the Appwrite “create collections” script stub.

The “Run this script to create all collections” block is currently just comments:

// Create all 19 collections in Appwrite
// See DATABASE_SCHEMA.md for attributes

Either:

• Replace it with a minimal real script that calls Appwrite to create the collections, or
• Mark it clearly as pseudocode/example to avoid suggesting it’s executable as-is.

lib/actions/reports.actions.ts (1)

138-210: Balance sheet and cashflow statements are mostly stubbed; consider surfacing this to callers.

• generateBalanceSheet returns all-zero assets, liabilities, and equity with a comment noting it’s “simplified”.
• generateCashflowStatement hard-codes beginningCash: 0 and endingCash: netCashChange, ignoring actual balances.

Given these are exposed as “advanced reports” and protected by feature gating, it may surprise users to see empty/incorrect figures.

Two suggestions:

• Either wire these to real data (e.g., bank balances, invoice AR/AP, loans) before exposing in UI, or
• Add a flag or metadata in reportData (e.g., isStub: true) so the frontend can label them as beta/coming-soon instead of authoritative.

Also applies to: 273-297

constants/subscription.ts (1)

270-283: Keep trial configuration DRY with TRIAL_CONFIG.

You already define TRIAL_CONFIG with per-tier durations and features, but startTrial in lib/actions/subscription.actions.ts re-implements trial lengths with hard-coded 14/30 days.

Consider refactoring startTrial to use TRIAL_CONFIG[tier].duration and/or TRIAL_CONFIG[tier].features so that trial behaviour remains consistent if you tweak the config here.

Also applies to: 184-204

lib/actions/subscription.actions.ts (1)

184-241: Use central trial configuration instead of hard-coded durations.

startTrial currently hard-codes:

const trialDays = tier === "enterprise" ? 30 : 14;

Given you already have TRIAL_CONFIG in constants/subscription.ts, it would be more maintainable to read the duration (and even feature set) from there so you have a single source of truth for trial behaviour.

Example:

-import { SUBSCRIPTION_TIERS, canAccessFeature, checkLimit } from "@/constants/subscription";
+import { SUBSCRIPTION_TIERS, TRIAL_CONFIG, checkLimit } from "@/constants/subscription";
...
-    const trialDays = tier === "enterprise" ? 30 : 14;
+    const trialDays = TRIAL_CONFIG[tier].duration;

This keeps product/pricing changes localized to the constants module.

constants/subscription-revised.ts (2)

329-334: getFeatureLimit key space is anchored to personal limits only

limit keys are derived from personal_free.limits, so business-only limits such as teamMembers or apiCallsPerMonth on business tiers are not addressable through this helper.

If you intend to expose those limits as well, consider:

• Defining a shared Limits type and deriving keys from a combined shape, or
• Adding a dedicated helper for business-only limits.

---

265-271: Two parallel tier concepts (SubscriptionTierType vs SubscriptionTier) may diverge

This file introduces SubscriptionTierType = keyof typeof ALL_TIERS (personal_free, business_starter, etc.), while types/extended.d.ts and subscription.actions.ts use SubscriptionTier = "free" | "pro" | "business" | "enterprise" and SUBSCRIPTION_TIERS.

Maintaining both schemas risks drift between:

• Pricing/paywall UI (driven by these richer tiers), and
• Enforcement logic (driven by the older SubscriptionTier).

Consider introducing a single canonical tier model (or an explicit mapping layer) and consolidating uses over time to avoid inconsistent access checks or upgrade prompts.

lib/actions/categorization.actions.ts (1)

101-123: Bulk categorization is fully sequential and may become slow at scale

bulkCategorizeTransactions awaits each categorizeTransaction call in a for...of loop, so N transactions incur N round-trips in series.

If you expect larger batches, consider running them with limited concurrency, e.g.:

await Promise.all(
  categorizations.map(cat =>
    categorizeTransaction(userId, cat.transactionId, {
      transactionId: cat.transactionId,
      category: cat.category,
      transactionType: cat.transactionType,
    })
  )
);

or a small concurrency pool to avoid hammering Appwrite.

lib/actions/ai.actions.ts (2)

89-197: AI insights generation looks consistent; only minor suggestions

generateFinancialInsights uses checkFeatureAccess("aiInsights"), derives insights from getBudgetSummary, and persists them with actionJSON and other metadata. The shapes for type, priority, and action.type match the AIInsight declaration.

Minor optional tweaks you might consider later:

• Batch the createDocument calls with limited concurrency if you add more insight types.
• Store a small deduplication key (e.g., by type + period) if you want to avoid repeatedly inserting equivalent insights.

---

474-541: Anomaly and recommendation generators are stubs but gated by AI access

detectAnomalies and generateSmartRecommendations correctly check aiInsights access, but currently:

• detectAnomalies always returns an empty array.
• generateSmartRecommendations only returns a single “Start Budget Tracking” insight when totalBudgeted === 0, and does not persist insights.

That’s acceptable as a starting point; just ensure any UI built on these APIs can handle empty arrays and doesn’t mislead users into expecting comprehensive anomaly detection or optimization.

lib/actions/budget.actions.ts (1)

293-325: Goal creation reuses budget features; consider dedicated feature flag

createGoal uses:

const subscription = await checkFeatureAccess(data.userId, "budgetTracking");
if (subscription.tier === "free" && userGoals.length >= 2) { ... }

Reusing budgetTracking to gate goal counts works, but if you ever introduce separate subscription flags for goals vs budgets, this coupling may become confusing.

Not urgent, but you might later want a dedicated goalTracking/maxGoals concept to mirror how budgets are handled.

lib/actions/business.actions.ts (1)

693-693: Hardcoded OCR confidence threshold.

The confidence threshold of 0.8 is hardcoded. Consider making this configurable or documenting why this specific value was chosen.

Make the threshold configurable:

+const OCR_CONFIDENCE_THRESHOLD = 0.8; // Minimum confidence for auto-verification
+
 export async function processReceiptOCR(
   receiptId: string,
   ocrData: Receipt["ocrData"]
 ): Promise<Receipt | null> {
   try {
     const { database } = await createAdminClient();

     const updated = await database.updateDocument(
       DATABASE_ID!,
       RECEIPTS_COLLECTION_ID!,
       receiptId,
       {
         ocrDataJSON: JSON.stringify(ocrData),
-        verified: ocrData.confidence > 0.8,
+        verified: ocrData.confidence > OCR_CONFIDENCE_THRESHOLD,
       }
     );

     return parseStringify(updated);
   } catch (error) {
     console.error("Error processing receipt OCR:", error);
     return null;
   }
 }

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between b8d5a8e and 208e3f5.

📒 Files selected for processing (20)

• .env (0 hunks)
• .env.example (2 hunks)
• .gitignore (1 hunks)
• DATABASE_SCHEMA.md (1 hunks)
• IMPLEMENTATION_GUIDE.md (1 hunks)
• PRICING_STRATEGY.md (1 hunks)
• README.md (1 hunks)
• README_SMART_WALLET.md (1 hunks)
• SECURITY.md (1 hunks)
• constants/index.ts (1 hunks)
• constants/subscription-revised.ts (1 hunks)
• constants/subscription.ts (1 hunks)
• lib/actions/ai.actions.ts (1 hunks)
• lib/actions/budget.actions.ts (1 hunks)
• lib/actions/business.actions.ts (1 hunks)
• lib/actions/categorization.actions.ts (1 hunks)
• lib/actions/reports.actions.ts (1 hunks)
• lib/actions/subscription.actions.ts (1 hunks)
• package.json (2 hunks)
• types/extended.d.ts (1 hunks)

💤 Files with no reviewable changes (1)

• .env

🧰 Additional context used

🧬 Code graph analysis (6)

lib/actions/reports.actions.ts (5)

lib/actions/subscription.actions.ts (1)

• checkFeatureAccess (118-150)

lib/appwrite.ts (2)

• createAdminClient (26-43)
• database (36-38)

lib/actions/categorization.actions.ts (1)

• getUserCategorizedTransactions (129-162)

lib/utils.ts (1)

• parseStringify (79-79)

lib/actions/business.actions.ts (1)

• calculateVATReturn (245-302)

lib/actions/subscription.actions.ts (3)

lib/appwrite.ts (2)

• createAdminClient (26-43)
• database (36-38)

lib/utils.ts (1)

• parseStringify (79-79)

constants/subscription.ts (2)

• SUBSCRIPTION_TIERS (5-166)
• checkLimit (188-204)

lib/actions/budget.actions.ts (3)

lib/appwrite.ts (2)

• createAdminClient (26-43)
• database (36-38)

lib/actions/subscription.actions.ts (2)

• checkUsageLimit (156-178)
• checkFeatureAccess (118-150)

lib/utils.ts (1)

• parseStringify (79-79)

lib/actions/ai.actions.ts (5)

lib/actions/subscription.actions.ts (2)

• checkFeatureAccess (118-150)
• checkUsageLimit (156-178)

lib/actions/budget.actions.ts (2)

• getUserBudgets (64-100)
• getBudgetSummary (239-287)

lib/appwrite.ts (2)

• createAdminClient (26-43)
• database (36-38)

lib/utils.ts (1)

• parseStringify (79-79)

lib/actions/categorization.actions.ts (1)

• getSpendingByCategory (348-393)

lib/actions/business.actions.ts (3)

lib/actions/subscription.actions.ts (1)

• checkFeatureAccess (118-150)

lib/appwrite.ts (2)

• createAdminClient (26-43)
• database (36-38)

lib/utils.ts (1)

• parseStringify (79-79)

lib/actions/categorization.actions.ts (3)

lib/appwrite.ts (2)

• createAdminClient (26-43)
• database (36-38)

lib/utils.ts (1)

• parseStringify (79-79)

lib/actions/subscription.actions.ts (1)

• checkFeatureAccess (118-150)

🪛 dotenv-linter (4.0.0)

.env.example

[warning] 16-16: [UnorderedKey] The APPWRITE_BUDGETS_COLLECTION_ID key should go before the APPWRITE_SUBSCRIPTION_COLLECTION_ID key

(UnorderedKey)

---

[warning] 17-17: [UnorderedKey] The APPWRITE_SAVINGS_GOALS_COLLECTION_ID key should go before the APPWRITE_SUBSCRIPTION_COLLECTION_ID key

(UnorderedKey)

---

[warning] 18-18: [UnorderedKey] The APPWRITE_BUSINESS_ENTITIES_COLLECTION_ID key should go before the APPWRITE_SAVINGS_GOALS_COLLECTION_ID key

(UnorderedKey)

---

[warning] 20-20: [UnorderedKey] The APPWRITE_CLIENTS_COLLECTION_ID key should go before the APPWRITE_SAVINGS_GOALS_COLLECTION_ID key

(UnorderedKey)

---

[warning] 21-21: [UnorderedKey] The APPWRITE_PROJECTS_COLLECTION_ID key should go before the APPWRITE_SAVINGS_GOALS_COLLECTION_ID key

(UnorderedKey)

---

[warning] 22-22: [UnorderedKey] The APPWRITE_INVOICES_COLLECTION_ID key should go before the APPWRITE_PROJECTS_COLLECTION_ID key

(UnorderedKey)

---

[warning] 23-23: [UnorderedKey] The APPWRITE_RECEIPTS_COLLECTION_ID key should go before the APPWRITE_SAVINGS_GOALS_COLLECTION_ID key

(UnorderedKey)

---

[warning] 24-24: [UnorderedKey] The APPWRITE_ENHANCED_TRANSACTIONS_COLLECTION_ID key should go before the APPWRITE_INVOICES_COLLECTION_ID key

(UnorderedKey)

---

[warning] 25-25: [UnorderedKey] The APPWRITE_RECURRING_TRANSACTIONS_COLLECTION_ID key should go before the APPWRITE_SAVINGS_GOALS_COLLECTION_ID key

(UnorderedKey)

---

[warning] 26-26: [UnorderedKey] The APPWRITE_AI_INSIGHTS_COLLECTION_ID key should go before the APPWRITE_BUDGETS_COLLECTION_ID key

(UnorderedKey)

---

[warning] 27-27: [UnorderedKey] The APPWRITE_CASHFLOW_FORECASTS_COLLECTION_ID key should go before the APPWRITE_CLIENTS_COLLECTION_ID key

(UnorderedKey)

---

[warning] 28-28: [UnorderedKey] The APPWRITE_ALERTS_COLLECTION_ID key should go before the APPWRITE_BUDGETS_COLLECTION_ID key

(UnorderedKey)

---

[warning] 29-29: [UnorderedKey] The APPWRITE_USER_PREFERENCES_COLLECTION_ID key should go before the APPWRITE_VAT_CONFIGURATIONS_COLLECTION_ID key

(UnorderedKey)

---

[warning] 30-30: [UnorderedKey] The APPWRITE_FINANCIAL_REPORTS_COLLECTION_ID key should go before the APPWRITE_INVOICES_COLLECTION_ID key

(UnorderedKey)

---

[warning] 35-35: [UnorderedKey] The PLAID_ENV key should go before the PLAID_SECRET key

(UnorderedKey)

---

[warning] 36-36: [UnorderedKey] The PLAID_PRODUCTS key should go before the PLAID_SECRET key

(UnorderedKey)

---

[warning] 37-37: [UnorderedKey] The PLAID_COUNTRY_CODES key should go before the PLAID_ENV key

(UnorderedKey)

---

[warning] 44-44: [UnorderedKey] The NEXT_PUBLIC_TEST_USER_ID key should go before the PLAID_TEST_ACCESS_TOKEN key

(UnorderedKey)

---

[warning] 45-45: [UnorderedKey] The NEXT_PUBLIC_TEST_ITEM_1_ID key should go before the NEXT_PUBLIC_TEST_USER_ID key

(UnorderedKey)

---

[warning] 46-46: [UnorderedKey] The NEXT_PUBLIC_TEST_ITEM_1_PLAID_ID key should go before the NEXT_PUBLIC_TEST_USER_ID key

(UnorderedKey)

---

[warning] 47-47: [UnorderedKey] The NEXT_PUBLIC_TEST_ACCOUNT_1_ID key should go before the NEXT_PUBLIC_TEST_ITEM_1_ID key

(UnorderedKey)

---

[warning] 48-48: [UnorderedKey] The NEXT_PUBLIC_TEST_ITEM_2_ID key should go before the NEXT_PUBLIC_TEST_USER_ID key

(UnorderedKey)

---

[warning] 49-49: [UnorderedKey] The NEXT_PUBLIC_TEST_ITEM_2_PLAID_ID key should go before the NEXT_PUBLIC_TEST_USER_ID key

(UnorderedKey)

---

[warning] 50-50: [UnorderedKey] The NEXT_PUBLIC_TEST_ACCOUNT_2_ID key should go before the NEXT_PUBLIC_TEST_ITEM_1_ID key

(UnorderedKey)

---

[warning] 55-55: [UnorderedKey] The DWOLLA_BASE_URL key should go before the DWOLLA_KEY key

(UnorderedKey)

---

[warning] 56-56: [UnorderedKey] The DWOLLA_ENV key should go before the DWOLLA_KEY key

(UnorderedKey)

---

[warning] 62-62: [EndingBlankLine] No blank line at the end of the file

(EndingBlankLine)

🪛 LanguageTool

PRICING_STRATEGY.md

[uncategorized] ~155-~155: If this is a compound adjective that modifies the following noun, use a hyphen.
Context: ... request → "Enterprise includes API" 4. High volume usage → "Contact sales" **Target Conve...

(EN_COMPOUND_ADJECTIVE_INTERNAL)

DATABASE_SCHEMA.md

[grammar] ~338-~338: Use a hyphen to join words.
Context: ...ation ### Initial Setup: 1. Create free tier subscription for all existing users...

(QB_NEW_EN_HYPHEN)

README.md

[style] ~54-~54: This phrase is redundant. Consider writing “Connect”.
Context: ... Banking #### Free Tier ($0/month) - ✅ Connect up to 2 bank accounts - ✅ Create 5 budgets...

(CONNECT_TOGETHER)

---

[grammar] ~204-~204: Use a hyphen to join words.
Context: ... #### Cashflow Forecasting - 30/60/90 day projections - 6-month & 1-year...

(QB_NEW_EN_HYPHEN)

---

[style] ~486-~486: Consider using a less common alternative to make your writing sound more unique and professional.
Context: ...ontributing Contributions are welcome! Please feel free to submit a Pull Request. 1. Fork the rep...

(FEEL_FREE_TO_STYLE_ME)

🪛 markdownlint-cli2 (0.18.1)

SECURITY.md

55-55: Unordered list indentation
Expected: 0; Actual: 3

(MD007, ul-indent)

---

56-56: Unordered list indentation
Expected: 0; Actual: 3

(MD007, ul-indent)

---

56-56: Bare URL used

(MD034, no-bare-urls)

---

57-57: Unordered list indentation
Expected: 0; Actual: 3

(MD007, ul-indent)

---

58-58: Unordered list indentation
Expected: 0; Actual: 3

(MD007, ul-indent)

---

59-59: Unordered list indentation
Expected: 0; Actual: 3

(MD007, ul-indent)

---

60-60: Unordered list indentation
Expected: 0; Actual: 3

(MD007, ul-indent)

---

61-61: Unordered list indentation
Expected: 0; Actual: 3

(MD007, ul-indent)

---

64-64: Unordered list indentation
Expected: 0; Actual: 3

(MD007, ul-indent)

---

64-64: Bare URL used

(MD034, no-bare-urls)

---

65-65: Unordered list indentation
Expected: 0; Actual: 3

(MD007, ul-indent)

---

66-66: Unordered list indentation
Expected: 0; Actual: 3

(MD007, ul-indent)

---

67-67: Unordered list indentation
Expected: 0; Actual: 3

(MD007, ul-indent)

---

68-68: Unordered list indentation
Expected: 0; Actual: 3

(MD007, ul-indent)

---

71-71: Unordered list indentation
Expected: 0; Actual: 3

(MD007, ul-indent)

---

71-71: Bare URL used

(MD034, no-bare-urls)

---

72-72: Unordered list indentation
Expected: 0; Actual: 3

(MD007, ul-indent)

---

73-73: Unordered list indentation
Expected: 0; Actual: 3

(MD007, ul-indent)

---

76-76: Unordered list indentation
Expected: 0; Actual: 3

(MD007, ul-indent)

---

77-77: Unordered list indentation
Expected: 0; Actual: 3

(MD007, ul-indent)

---

78-78: Unordered list indentation
Expected: 0; Actual: 3

(MD007, ul-indent)

---

79-79: Unordered list indentation
Expected: 0; Actual: 3

(MD007, ul-indent)

---

82-82: Unordered list indentation
Expected: 0; Actual: 3

(MD007, ul-indent)

---

83-83: Unordered list indentation
Expected: 0; Actual: 3

(MD007, ul-indent)

---

84-84: Unordered list indentation
Expected: 0; Actual: 3

(MD007, ul-indent)

---

117-117: Unordered list indentation
Expected: 0; Actual: 3

(MD007, ul-indent)

---

118-118: Unordered list indentation
Expected: 0; Actual: 3

(MD007, ul-indent)

---

119-119: Unordered list indentation
Expected: 0; Actual: 3

(MD007, ul-indent)

---

120-120: Unordered list indentation
Expected: 0; Actual: 3

(MD007, ul-indent)

---

121-121: Unordered list indentation
Expected: 0; Actual: 3

(MD007, ul-indent)

---

124-124: Unordered list indentation
Expected: 0; Actual: 3

(MD007, ul-indent)

---

125-125: Unordered list indentation
Expected: 0; Actual: 3

(MD007, ul-indent)

---

126-126: Unordered list indentation
Expected: 0; Actual: 3

(MD007, ul-indent)

---

223-223: Bare URL used

(MD034, no-bare-urls)

---

224-224: Bare URL used

(MD034, no-bare-urls)

---

225-225: Bare URL used

(MD034, no-bare-urls)

---

228-228: Bare URL used

(MD034, no-bare-urls)

---

229-229: Bare URL used

(MD034, no-bare-urls)

---

232-232: Bare URL used

(MD034, no-bare-urls)

---

233-233: Bare URL used

(MD034, no-bare-urls)

---

236-236: Bare URL used

(MD034, no-bare-urls)

---

237-237: Bare URL used

(MD034, no-bare-urls)

README_SMART_WALLET.md

67-67: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

---

76-76: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

---

85-85: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

---

97-97: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

---

105-105: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

---

114-114: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

---

123-123: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

---

131-131: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

---

143-143: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

---

155-155: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

---

165-165: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

---

175-175: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

---

187-187: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

---

206-206: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

---

214-214: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

---

232-232: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

---

510-510: Emphasis used instead of a heading

(MD036, no-emphasis-as-heading)

PRICING_STRATEGY.md

265-265: Tables should be surrounded by blank lines

(MD058, blanks-around-tables)

---

275-275: Tables should be surrounded by blank lines

(MD058, blanks-around-tables)

---

338-338: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

---

354-354: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

---

415-415: Emphasis used instead of a heading

(MD036, no-emphasis-as-heading)

---

420-420: Emphasis used instead of a heading

(MD036, no-emphasis-as-heading)

---

425-425: Emphasis used instead of a heading

(MD036, no-emphasis-as-heading)

---

430-430: Emphasis used instead of a heading

(MD036, no-emphasis-as-heading)

🔇 Additional comments (8)

SECURITY.md (2)

1-48: Excellent incident documentation and remediation.

The security incident report clearly describes the exposure, severity, and immediate actions taken. This transparency is commendable and helps prevent future incidents.

---

37-37: Consider notifying the upstream repository.

Line 37 indicates credentials "originated from the upstream repository (adrianhajdin/banking)". If production credentials are still exposed in the upstream repository, consider notifying the maintainer privately to help them secure their repository as well.

PRICING_STRATEGY.md (1)

1-510: Product documentation in security PR.

This comprehensive pricing strategy document is well-structured but seems out of scope for a PR titled "Security developments". Consider splitting business/product documentation into a separate PR focused on feature planning.

That said, the document itself is thorough and provides clear value propositions, conversion funnels, and competitive analysis.

constants/index.ts (1)

24-27: Security improvement: Hardcoded tokens removed.

Excellent work moving hardcoded tokens to environment variables. This addresses the critical security incident documented in SECURITY.md.

README.md (1)

1-545: Comprehensive documentation overhaul.

The README has been transformed from a tutorial-style guide to professional product documentation with clear feature descriptions, pricing tiers, setup instructions, and competitive positioning. The documentation is well-structured and comprehensive.

However, this extensive rewrite seems out of scope for a PR titled "Security developments". Consider separating product/feature documentation updates into a dedicated PR to keep security fixes focused and reviewable.

lib/actions/reports.actions.ts (1)

512-585: Fix getQuarterlyBreakdown to filter transactions by year.

The year parameter is received but never used. Transactions from different years are bucketed into the same quarters (e.g., Q1 2023 and Q1 2024 both appear as "Q1"), causing incorrect tax summaries.

Add year filtering to lines 670-674 in lib/actions/reports.actions.ts:

 const quarterTransactions = transactions.filter(t => {
   const date = new Date(t.date || t.$createdAt);
+  if (Number.isNaN(date.getTime()) || date.getFullYear() !== year) return false;
   const month = date.getMonth();
   return month >= startMonth && month < endMonth;
 });

Likely an incorrect or invalid review comment.

lib/actions/budget.actions.ts (1)

239-286: Budget summary aggregation looks correct and is used consistently

getBudgetSummary aggregates totals and utilization across active budgets and exposes exactly the metrics AI and insight modules need (totalBudgeted, totalSpent, avgUtilization, etc.). Logic is straightforward and handles the no-budget case safely.

types/extended.d.ts (1)

296-316: AI-related types line up well with AI action implementations

AIInsight and CashflowForecast definitions closely match how AI insights and forecasts are produced and consumed in ai.actions.ts (including action.type unions and forecast dataPoints). Where you already parse actionJSON/dataPointsJSON, the runtime objects adhere to these interfaces, which is good.

[coderabbitai]

🛠️ Refactor suggestion | 🟠 Major

Clarify the "DO NOT COMMIT" warning.

The comment on line 39 states "DO NOT COMMIT!" but this is the .env.example file, which is intended to be committed. The warning should clarify that values should not be committed, only the template keys.

Apply this diff to clarify the comment:

-# PLAID TEST TOKENS (For development/testing only - DO NOT COMMIT!)
-# Generate these from Plaid Dashboard > Sandbox > Generate Token
+# PLAID TEST TOKENS (For development/testing only)
+# Generate these from Plaid Dashboard > Sandbox > Generate Token
+# IMPORTANT: Never commit actual token values to .env - keep them in your local .env file only!
 PLAID_TEST_ACCESS_TOKEN=
 PLAID_TEST_ACCESS_TOKEN_1=
 PLAID_TEST_ACCESS_TOKEN_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

	# PLAID TEST TOKENS (For development/testing only - DO NOT COMMIT!)
	# Generate these from Plaid Dashboard > Sandbox > Generate Token
	PLAID_TEST_ACCESS_TOKEN=
	PLAID_TEST_ACCESS_TOKEN_1=
	PLAID_TEST_ACCESS_TOKEN_2=
	NEXT_PUBLIC_TEST_USER_ID=
	NEXT_PUBLIC_TEST_ITEM_1_ID=
	NEXT_PUBLIC_TEST_ITEM_1_PLAID_ID=
	NEXT_PUBLIC_TEST_ACCOUNT_1_ID=
	NEXT_PUBLIC_TEST_ITEM_2_ID=
	NEXT_PUBLIC_TEST_ITEM_2_PLAID_ID=
	NEXT_PUBLIC_TEST_ACCOUNT_2_ID=
	# PLAID TEST TOKENS (For development/testing only)
	# Generate these from Plaid Dashboard > Sandbox > Generate Token
	# IMPORTANT: Never commit actual token values to .env - keep them in your local .env file only!
	PLAID_TEST_ACCESS_TOKEN=
	PLAID_TEST_ACCESS_TOKEN_1=
	PLAID_TEST_ACCESS_TOKEN_2=
	NEXT_PUBLIC_TEST_USER_ID=
	NEXT_PUBLIC_TEST_ITEM_1_ID=
	NEXT_PUBLIC_TEST_ITEM_1_PLAID_ID=
	NEXT_PUBLIC_TEST_ACCOUNT_1_ID=
	NEXT_PUBLIC_TEST_ITEM_2_ID=
	NEXT_PUBLIC_TEST_ITEM_2_PLAID_ID=
	NEXT_PUBLIC_TEST_ACCOUNT_2_ID=

🧰 Tools

🪛 dotenv-linter (4.0.0)

[warning] 44-44: [UnorderedKey] The NEXT_PUBLIC_TEST_USER_ID key should go before the PLAID_TEST_ACCESS_TOKEN key

(UnorderedKey)

---

[warning] 45-45: [UnorderedKey] The NEXT_PUBLIC_TEST_ITEM_1_ID key should go before the NEXT_PUBLIC_TEST_USER_ID key

(UnorderedKey)

---

[warning] 46-46: [UnorderedKey] The NEXT_PUBLIC_TEST_ITEM_1_PLAID_ID key should go before the NEXT_PUBLIC_TEST_USER_ID key

(UnorderedKey)

---

[warning] 47-47: [UnorderedKey] The NEXT_PUBLIC_TEST_ACCOUNT_1_ID key should go before the NEXT_PUBLIC_TEST_ITEM_1_ID key

(UnorderedKey)

---

[warning] 48-48: [UnorderedKey] The NEXT_PUBLIC_TEST_ITEM_2_ID key should go before the NEXT_PUBLIC_TEST_USER_ID key

(UnorderedKey)

---

[warning] 49-49: [UnorderedKey] The NEXT_PUBLIC_TEST_ITEM_2_PLAID_ID key should go before the NEXT_PUBLIC_TEST_USER_ID key

(UnorderedKey)

---

[warning] 50-50: [UnorderedKey] The NEXT_PUBLIC_TEST_ACCOUNT_2_ID key should go before the NEXT_PUBLIC_TEST_ITEM_1_ID key

(UnorderedKey)

🤖 Prompt for AI Agents

In .env.example around lines 39 to 50 the header says "DO NOT COMMIT!" which is
misleading because this example file should be committed; change the comment to
clarify that only the template keys should be committed and that actual secret
values (access tokens) must never be committed — e.g., replace the warning with
a concise note: this file is a committed template for developers, but do NOT
commit real secrets or token values (fill them locally or via CI secrets); keep
the existing instruction about generating Plaid sandbox tokens from the Plaid
Dashboard.

[coderabbitai]

⚠️ Potential issue | 🔴 Critical

Critical: Access tokens exposed to client-side code.

Variables with NEXT_PUBLIC_ prefix are bundled into the client-side JavaScript code and should only be used for non-sensitive data. Sensitive information should never be stored in environment variables that begin with NEXT_PUBLIC_.

Lines 26, 32, 35, 39, 40, 42 use NEXT_PUBLIC_ prefix for test user IDs, item IDs, and account IDs. While these may be test values, Plaid access tokens (lines 27, 33, 40) should NEVER use the NEXT_PUBLIC_ prefix as this exposes them to the browser.

Additionally:

• Line 27 uses PLAID_TEST_ACCESS_TOKEN (no number suffix)
• Lines 33 and 40 use PLAID_TEST_ACCESS_TOKEN_1 and _2 (with suffixes)
• This naming inconsistency could cause confusion

Apply this diff to fix the security issue:

-// SECURITY NOTE: Never hardcode tokens! These are now loaded from environment variables.
-// For testing purposes only - set these in your .env file
-export const TEST_USER_ID = process.env.NEXT_PUBLIC_TEST_USER_ID || "";
-export const TEST_ACCESS_TOKEN = process.env.PLAID_TEST_ACCESS_TOKEN || "";
+// SECURITY NOTE: Never hardcode tokens! These are now loaded from environment variables.
+// For testing purposes only - set these in your .env file
+// WARNING: These constants expose data to client-side. Only use for non-sensitive test identifiers.
+export const TEST_USER_ID = process.env.NEXT_PUBLIC_TEST_USER_ID || "";
+// Server-side only - never expose access tokens to client
+export const TEST_ACCESS_TOKEN = process.env.PLAID_TEST_ACCESS_TOKEN || "";

 // Test items - configure these in your .env file
 export const ITEMS = [
   {
     id: process.env.NEXT_PUBLIC_TEST_ITEM_1_ID || "",
-    accessToken: process.env.PLAID_TEST_ACCESS_TOKEN_1 || "",
+    accessToken: process.env.PLAID_TEST_ACCESS_TOKEN || "",
     itemId: process.env.NEXT_PUBLIC_TEST_ITEM_1_PLAID_ID || "",
     userId: process.env.NEXT_PUBLIC_TEST_USER_ID || "",
     accountId: process.env.NEXT_PUBLIC_TEST_ACCOUNT_1_ID || "",
   },
   {
     id: process.env.NEXT_PUBLIC_TEST_ITEM_2_ID || "",
-    accessToken: process.env.PLAID_TEST_ACCESS_TOKEN_2 || "",
+    accessToken: process.env.PLAID_TEST_ACCESS_TOKEN_1 || "",
     itemId: process.env.NEXT_PUBLIC_TEST_ITEM_2_PLAID_ID || "",
     userId: process.env.NEXT_PUBLIC_TEST_USER_ID || "",
     accountId: process.env.NEXT_PUBLIC_TEST_ACCOUNT_2_ID || "",
   },
 ];

Important: If ITEMS is used in client-side code, you'll need to refactor to fetch access tokens server-side via API routes instead of including them in this client-accessible constant.

Also applies to: 32-44

🤖 Prompt for AI Agents

In constants/index.ts around lines 26-27 and also affecting lines 32-44, the
review flags that Plaid access tokens and other sensitive values are exposed to
client-side bundles via NEXT_PUBLIC_* vars and inconsistent naming
(PLAID_TEST_ACCESS_TOKEN vs PLAID_TEST_ACCESS_TOKEN_1/_2); remove any
NEXT_PUBLIC_* usage for secrets, rename environment keys to non-public names
(e.g. PLAID_TEST_ACCESS_TOKEN[_1|_2]) and load them only on the server (node
runtime or API routes), move access-token-dependent logic out of client-side
code so ITEMS or access tokens are fetched via secure server-side endpoints, and
ensure any client-side constants only contain non-sensitive IDs (or are fetched
from server endpoints) with consistent env var naming.

[coderabbitai]

⚠️ Potential issue | 🟠 Major

canAccessFeature return type is too narrow for mixed numeric/boolean feature fields

features includes numeric limits (e.g., maxBankAccounts) and booleans, but canAccessFeature:

export function canAccessFeature(
  tier: SubscriptionTierType,
  feature: keyof typeof PERSONAL_TIERS.personal_free.features
): boolean {
  return ALL_TIERS[tier].features[feature];
}

returns the raw value, which is number | boolean at runtime while the signature promises boolean. This will either fail type-checking or silently allow numeric values to be treated as truthy.

Consider either:

• Restricting feature to a union of boolean feature keys, or
• Returning boolean | number and normalizing to a boolean where needed.

🤖 Prompt for AI Agents

In constants/subscription-revised.ts around lines 322 to 327, canAccessFeature
currently types its return as boolean but reads values that may be number |
boolean; change the function to either (A) accept only boolean feature keys by
tightening the feature param to the union of keys whose values are boolean
(derive a type like BooleanFeatureKeys = { [K in keyof typeof
PERSONAL_TIERS.personal_free.features]: typeof
PERSONAL_TIERS.personal_free.features[K] extends boolean ? K : never }[keyof
...]) and keep boolean return, or (B) change the return type to boolean | number
and return the raw value, or (preferred) (C) keep the boolean signature but
coerce the stored value to boolean (e.g., return
!!ALL_TIERS[tier].features[feature]); update callers accordingly if they need
numeric limits instead of a boolean.

[coderabbitai]

⚠️ Potential issue | 🔴 Critical

🧩 Analysis chain

Fix feature/usage helpers: type mismatch in canAccessFeature and potential NaN in getUsagePercentage.

Two issues here:

1. canAccessFeature:

export function canAccessFeature(
  tier: SubscriptionTierType,
  feature: keyof typeof SUBSCRIPTION_TIERS.free.features
): boolean {
  return SUBSCRIPTION_TIERS[tier].features[feature];
}

features[feature] can be a number (maxBankAccounts, etc.) or boolean, but the function claims to return boolean, which will fail strict type-checking and is ambiguous at runtime.

If the intent is “truthy means available”, cast explicitly:

 export function canAccessFeature(
   tier: SubscriptionTierType,
   feature: keyof typeof SUBSCRIPTION_TIERS.free.features
 ): boolean {
-  return SUBSCRIPTION_TIERS[tier].features[feature];
+  return Boolean(SUBSCRIPTION_TIERS[tier].features[feature]);
 }

2. getUsagePercentage:

export interface UsageMetrics {
  aiQueriesUsed: number;
  ocrScansUsed: number;
  invoicesCreated: number;
  reportsGenerated: number;
  periodStart: string;
  periodEnd: string;
}

export function getUsagePercentage(
  tier: SubscriptionTierType,
  metric: keyof UsageMetrics,
  used: number
): number {
  const limits = SUBSCRIPTION_TIERS[tier].limits;
  const limitKey = `${metric}PerMonth` as keyof typeof limits;
  const maxLimit = limits[limitKey];
  ...
}

Because metric can be periodStart/periodEnd, you end up looking for periodStartPerMonth in limits, which is undefined ⇒ used / undefined ⇒ NaN.

A minimal fix is to narrow the accepted metric keys and map them explicitly to the limits:

-export function getUsagePercentage(
-  tier: SubscriptionTierType,
-  metric: keyof UsageMetrics,
-  used: number
-): number {
-  const limits = SUBSCRIPTION_TIERS[tier].limits;
-  const limitKey = `${metric}PerMonth` as keyof typeof limits;
+type UsageCountMetric = "aiQueriesUsed" | "ocrScansUsed" | "invoicesCreated" | "reportsGenerated";
+
+export function getUsagePercentage(
+  tier: SubscriptionTierType,
+  metric: UsageCountMetric,
+  used: number
+): number {
+  const limits = SUBSCRIPTION_TIERS[tier].limits;
+  const metricToLimit: Record<UsageCountMetric, keyof typeof SUBSCRIPTION_TIERS.free.limits> = {
+    aiQueriesUsed: "aiQueriesPerMonth",
+    ocrScansUsed: "ocrScansPerMonth",
+    invoicesCreated: "invoicesPerMonth",
+    reportsGenerated: "reportsPerMonth",
+  };
+  const limitKey = metricToLimit[metric];
   const maxLimit = limits[limitKey];

This keeps the API safe and makes the metric/limit mapping explicit.

Also applies to: 356-378

---

🏁 Script executed:

#!/bin/bash
# Locate constants/subscription.ts and examine the SUBSCRIPTION_TIERS structure and functions
find . -name "subscription.ts" -type f | head -20

Length of output: 27

---

🏁 Script executed:

#!/bin/bash
# Once file is located, examine the full structure
cat constants/subscription.ts

Length of output: 10764

---

🏁 Script executed:

#!/bin/bash
# Alternative: search for the file if it's not at the exact path
find . -name "*.ts" -o -name "*.tsx" | xargs grep -l "canAccessFeature" | head -5

Length of output: 101

---

Fix type mismatch in canAccessFeature and NaN bug in getUsagePercentage.

Two critical issues confirmed:

1. canAccessFeature (lines 174–179): The features object mixes numbers (maxBankAccounts: 1, maxBudgets: 3, etc.) and booleans (budgetTracking: true, aiInsights: false, etc.), but the function declares a boolean return type and returns the value directly. This violates strict type-checking and is ambiguous at runtime.

   Fix: Cast to boolean explicitly:

   return Boolean(SUBSCRIPTION_TIERS[tier].features[feature]);

2. getUsagePercentage (lines 356–378): The metric parameter accepts any key from UsageMetrics, including periodStart and periodEnd. The code builds ${metric}PerMonth keys (e.g., periodStartPerMonth), which don't exist in the limits object. This causes limits[limitKey] to be undefined, leading to used / undefined → NaN.

   Fix: Narrow the metric type to exclude time fields:

   type UsageCountMetric = "aiQueriesUsed" | "ocrScansUsed" | "invoicesCreated" | "reportsGenerated";
   
   export function getUsagePercentage(
     tier: SubscriptionTierType,
     metric: UsageCountMetric,
     used: number
   ): number {
     const limits = SUBSCRIPTION_TIERS[tier].limits;
     const metricToLimit: Record<UsageCountMetric, keyof typeof SUBSCRIPTION_TIERS.free.limits> = {
       aiQueriesUsed: "aiQueriesPerMonth",
       ocrScansUsed: "ocrScansPerMonth",
       invoicesCreated: "invoicesPerMonth",
       reportsGenerated: "reportsPerMonth",
     };
     const limitKey = metricToLimit[metric];
     const maxLimit = limits[limitKey];
     // ... rest of function

🤖 Prompt for AI Agents

constants/subscription.ts around lines 174–179 and 356–378: canAccessFeature
currently returns mixed-type values from the features map which contains numbers
and booleans; change the function to coerce the returned value to a boolean
(e.g., use Boolean(...) around the feature lookup) so the signature boolean
return type is satisfied. For getUsagePercentage, narrow the metric parameter to
only the actual usage-count keys (exclude periodStart/periodEnd) or map incoming
metric keys to their corresponding per-month limit keys; then look up that
mapped limit key on limits, guard against undefined (treat as 0 or return 0%),
and compute used/limit safely to avoid NaN.

[coderabbitai]

⚠️ Potential issue | 🟠 Major

Document encryption for sensitive personal data.

The users collection contains highly sensitive fields (SSN on line 20, dateOfBirth on line 19) that should be encrypted at rest. Document the encryption strategy for PII fields to ensure GDPR/CCPA compliance.

Add a security section to the documentation:

## Security Considerations

### Encryption at Rest
- **SSN** - Encrypted using Appwrite's encryption
- **dateOfBirth** - Encrypted
- **dwollaCustomerId** - Encrypted
- All PII encrypted before storage

### Field-Level Permissions
- SSN: Admin only
- Financial data: User + Admin
- Public profile: All authenticated users

🤖 Prompt for AI Agents

In DATABASE_SCHEMA.md around lines 8 to 22, the users collection documents
sensitive PII fields (ssn and dateOfBirth) but lack any documented encryption
and access-control guidance; add a "Security Considerations" section that
prescribes encryption-at-rest for SSN, dateOfBirth, and dwollaCustomerId (and
note encryption occurs before storage), and specify field-level permissions
(e.g., SSN: admin-only, financial data: user+admin, public profile:
authenticated users), include brief notes on encryption mechanism (Appwrite or
KMS) and mention audit/logging and key management responsibilities.

[coderabbitai]

⚠️ Potential issue | 🟠 Major

🧩 Analysis chain

Guard against IDOR-style misuse: don’t trust caller-provided userId for subscription mutations.

All exported functions (getUserSubscription, createSubscription, updateSubscriptionTier, checkFeatureAccess, checkUsageLimit, startTrial, cancelSubscription, getFeatureAccessSummary) take a raw userId string and then operate via the Appwrite admin client.

If any server action or API route forwards a client-supplied userId into these functions without verifying ownership, it becomes trivial for a malicious user to:

• Read another user’s subscription,
• Upgrade/downgrade tiers,
• Start or cancel trials/subscriptions on someone else’s account.

To harden this:

• Derive userId from the authenticated session/token on the server (e.g., NextAuth/Appwrite JWT) instead of taking it as a free-form parameter, or
• Add a thin wrapper that resolves userId from auth and keep these lower-level helpers private to the server layer that already has a trusted identity.

At minimum, review all call sites and ensure userId is never coming from untrusted client input.

Also applies to: 247-272, 278-326

---

I'll verify the security concern by inspecting the full file and examining call sites.

---

🏁 Script executed:

```shell
#!/bin/bash
# View the complete subscription.actions.ts file to see all functions
fd -e "subscription.actions.ts" -x cat {}

Length of output: 0

---

🏁 Script executed:

#!/bin/bash
# Search for imports and calls to subscription functions across the codebase
rg -n --type=ts --type=tsx "from.*subscription.actions|import.*subscription" -A 2 -B 2

Length of output: 27

---

🏁 Script executed:

#!/bin/bash
# Search for call sites of the main subscription functions
rg -n --type=ts --type=tsx -P "(getUserSubscription|createSubscription|updateSubscriptionTier|checkFeatureAccess|checkUsageLimit|startTrial|cancelSubscription|getFeatureAccessSummary)\(" -B 3 -A 1 | head -100

Length of output: 27

---

🏁 Script executed:

#!/bin/bash
# Check for auth context extraction patterns (NextAuth, session, JWT) in action files
rg -n --type=ts --type=tsx "getSession|auth\(\)|useAuth|session\?" -B 2 -A 2 | head -60

Length of output: 27

---

Let me adjust the scripts to work with available tools:

---

🏁 Script executed:

```shell
#!/bin/bash
# Find subscription.actions.ts file
fd "subscription.actions" 

Length of output: 35

---

🏁 Script executed:

#!/bin/bash
# Search for subscription imports using simpler pattern
rg "subscription.actions" -n -B 1 -A 1

Length of output: 1765

---

🏁 Script executed:

#!/bin/bash
# Search for function calls without type filtering
rg "getUserSubscription|createSubscription|updateSubscriptionTier" -n -B 2 -A 1 | head -80

Length of output: 3514

---

🏁 Script executed:

#!/bin/bash
# Look for server action/API route files that might use auth
fd -e ".ts" -e ".js" | grep -E "(action|api|route)" | head -20

Length of output: 349

---

🏁 Script executed:

#!/bin/bash
# Search for auth session extraction patterns
rg "getSession|session\.|auth\(" -n -B 1 -A 1 | head -60

Length of output: 728

---

---

🏁 Script executed:

```shell
#!/bin/bash
# View the complete subscription.actions.ts file
cat lib/actions/subscription.actions.ts

Length of output: 9426

---

🏁 Script executed:

#!/bin/bash
# Check how budget.actions calls subscription functions
rg -n "checkFeatureAccess|checkUsageLimit" lib/actions/budget.actions.ts -B 3 -A 2 | head -50

Length of output: 996

---

🏁 Script executed:

#!/bin/bash
# Check how ai.actions calls subscription functions
rg -n "checkFeatureAccess|checkUsageLimit" lib/actions/ai.actions.ts -B 3 -A 2 | head -50

Length of output: 1945

---

🏁 Script executed:

#!/bin/bash
# Search for where createSubscription or updateSubscriptionTier are called (not just defined)
rg "createSubscription|updateSubscriptionTier" -n | grep -v "export async function"

Length of output: 274

---

🏁 Script executed:

#!/bin/bash
# Check for any API routes that might receive userId from query/body
fd -path "*/app/*" -name "*route*" -o -path "*/pages/api/*" -name "*.ts" | head -10

Length of output: 168

---

---

🏁 Script executed:

```shell
#!/bin/bash
# Find the function definitions that call checkFeatureAccess/checkUsageLimit in budget.actions
rg -n "export async function|function" lib/actions/budget.actions.ts | head -20

Length of output: 953

---

🏁 Script executed:

#!/bin/bash
# Get the full function signature for createBudget in budget.actions
rg -A 8 "export async function createBudget" lib/actions/budget.actions.ts

Length of output: 378

---

🏁 Script executed:

#!/bin/bash
# Get the full function signature for queryAIAssistant in ai.actions
rg -A 10 "export async function queryAIAssistant" lib/actions/ai.actions.ts

Length of output: 476

---

🏁 Script executed:

#!/bin/bash
# Check the type definition for AIQueryRequest
rg -n "interface AIQueryRequest|type AIQueryRequest" 

Length of output: 58

---

🏁 Script executed:

#!/bin/bash
# Search for where these server actions are called from (client components, forms, etc)
rg -n "queryAIAssistant|createBudget" --type=ts --type=jsx -B 2 -A 1 | grep -E "(action|import|await)" | head -40

Length of output: 27

---

---

🏁 Script executed:

```shell
#!/bin/bash
# View AIQueryRequest type definition
rg -A 10 "declare interface AIQueryRequest" types/extended.d.ts

Length of output: 305

---

🏁 Script executed:

#!/bin/bash
# Search for CreateBudgetProps type definition
rg -n "interface CreateBudgetProps|type CreateBudgetProps"

Length of output: 61

---

🏁 Script executed:

#!/bin/bash
# Find where createBudget is imported and called
rg "from.*budget.actions|import.*createBudget" -n

Length of output: 96

---

🏁 Script executed:

#!/bin/bash
# Find where queryAIAssistant is imported and called
rg "from.*ai.actions|import.*queryAIAssistant" -n

Length of output: 0

---

🏁 Script executed:

#!/bin/bash
# Search for form submissions or client-side calls to these actions
rg "createBudget\(|queryAIAssistant\(" -n -B 3 -A 1 | head -60

Length of output: 1129

---

---

🏁 Script executed:

```shell
#!/bin/bash
# View CreateBudgetProps type definition
rg -A 10 "declare interface CreateBudgetProps" types/extended.d.ts

Length of output: 280

---

🏁 Script executed:

#!/bin/bash
# Search in components folder for where these actions are called
fd -type f \( -name "*.ts" -o -name "*.tsx" \) -path "*/components/*" | head -20

Length of output: 170

---

🏁 Script executed:

#!/bin/bash
# Look for form components or pages that might call createBudget or queryAIAssistant
rg "createBudget|queryAIAssistant|AIQueryRequest|CreateBudgetProps" -n -B 2 -A 2 --glob="*/components/**" --glob="*/app/**" | head -80

Length of output: 148

---

🏁 Script executed:

#!/bin/bash
# Check if there's auth middleware or session extraction in app or middleware files
fd -type f -name "middleware.*"

Length of output: 170

---

🏁 Script executed:

#!/bin/bash
# Look for any wrapper functions that might extract userId from session before calling subscription functions
rg "userId.*session|session.*userId|getSession" lib/actions/ -n -B 2 -A 2 | head -60

Length of output: 261

---

---

🏁 Script executed:

```shell
#!/bin/bash
# Simple search: find all files that reference createBudget (outside of definitions)
rg "createBudget" -l | grep -v node_modules

Length of output: 53

---

🏁 Script executed:

#!/bin/bash
# Find all .tsx and .ts files in app or components directories
find . -type d -name "app" -o -type d -name "components" | head -5

Length of output: 18

---

🏁 Script executed:

#!/bin/bash
# List app directory structure
ls -la app/ 2>/dev/null || echo "No app directory"

Length of output: 463

---

🏁 Script executed:

#!/bin/bash
# Search more broadly for where userId might come from in request/form context
rg "data\.userId|request\.userId|userId.*=" -n | grep -v "subscription.actions\|budget.actions\|ai.actions" | head -40

Length of output: 474

---

🏁 Script executed:

#!/bin/bash
# Check if there's any auth extraction happening before these action calls
rg "getUserInfo|getUser|session\.|auth\(" lib/actions/*.ts -n | grep -v "console\|error" | head -30

Length of output: 2934

---

Harden IDOR risk: userId parameter design needs ownership verification at the architecture level.

The review comment correctly identifies an architectural vulnerability: all subscription functions (getUserSubscription, createSubscription, updateSubscriptionTier, checkFeatureAccess, checkUsageLimit, startTrial, cancelSubscription, getFeatureAccessSummary) accept userId: string directly without internal ownership verification and operate with full admin privileges via createAdminClient().

Confirmed: This design pattern is risky. Call chain analysis shows budget.actions.createBudget(data) and ai.actions.queryAIAssistant(request) both extract data.userId and request.userId and pass them directly to subscription functions, which then query/modify database records based on that userId. If either of these receives userId from untrusted client input without prior verification, it enables IDOR.

However: No call sites in UI components were found in the codebase—functions are currently only defined and referenced in documentation. This suggests either the component implementations are not yet included in this PR or are elsewhere.

Recommendation: The architectural concern is valid and should be addressed regardless. Either:

• Extract userId from authenticated session/JWT within subscription.actions.ts itself, or
• Establish a clear contract that all callers must verify ownership before invoking these functions, and add JSDoc warnings to all exported functions.

Review all integration points when component code is added to ensure userId originates from verified authentication context.

[coderabbitai]

⚠️ Potential issue | 🟡 Minor

Replace placeholder support email.

Line 517 contains a placeholder email "[email protected] (placeholder)". Either replace with a real contact email or remove this section before merging.

Apply this diff:

-Need help? Have questions?
-
-- 📧 **Email:** [email protected] (placeholder)
-- 💬 **Issues:** [GitHub Issues](https://github.com/gadgetboy27/banking_app_plaid/issues)
+Need help? Have questions?
+
 - 📖 **Documentation:** See docs folder
 - 🐛 **Bug Reports:** Use GitHub Issues with `bug` label
+- 💬 **Questions:** [GitHub Discussions](https://github.com/gadgetboy27/banking_app_plaid/discussions)

Committable suggestion skipped: line range outside the PR's diff.

🤖 Prompt for AI Agents

In README.md around line 517 the contact email is a placeholder
("[email protected] (placeholder)"); replace it with the correct
support/contact email for the project or remove the entire email line if no
public contact should be published, and ensure any change matches the
repository's contributing or contact policy and formatting used in surrounding
lines.

[coderabbitai]

⚠️ Potential issue | 🟡 Minor

Replace placeholder contact email.

The placeholder "[Your contact email]" should be replaced with an actual security contact email before merging, or this section should be removed if a contact method isn't available yet.

Apply this diff:

-If you discover a security vulnerability, please email:
-- **Email:** [Your contact email]
-- **Response Time:** Within 24 hours
-
-Please do NOT open public GitHub issues for security vulnerabilities.
+If you discover a security vulnerability:
+- **DO NOT** open public GitHub issues for security vulnerabilities
+- Create a private security advisory via GitHub's Security tab
+- Or contact the repository maintainer directly

Committable suggestion skipped: line range outside the PR's diff.

🤖 Prompt for AI Agents

In SECURITY.md around line 152, the contact email field still contains the
placeholder "[Your contact email]"; replace that placeholder with the project's
actual security contact email (e.g., [email protected]) or, if no contact
exists yet, remove the entire "Email" line to avoid publishing a placeholder;
ensure the chosen value is a monitored address and update any related docs or
configuration that reference the security contact.

[coderabbitai]

⚠️ Potential issue | 🟠 Major

EnhancedTransaction interface doesn’t match how enhanced transactions are stored

EnhancedTransaction extends Transaction and includes tags?: string[], merchantName, etc. In categorization.actions.ts, enhanced records are stored in a separate collection with:

• Only a subset of these fields (no base Transaction data).
• tagsJSON (string) rather than tags: string[].

Given action functions like categorizeTransaction and getEnhancedTransaction currently return documents from that collection directly, the runtime shape does not match EnhancedTransaction.

To avoid subtle bugs:

• Introduce a storage-level type (e.g., EnhancedTransactionDocument) that reflects the Appwrite schema (tagsJSON, no base Transaction fields).
• Map that to a true EnhancedTransaction (join + JSON parse) at the boundary where you need the richer type.

[coderabbitai]

⚠️ Potential issue | 🟡 Minor

Alert.metadata vs metadataJSON in storage

Alert declares metadata?: any, but createAlert writes metadataJSON and getUserAlerts returns documents without decoding or renaming them.

To keep the types honest and reduce UI coupling to storage details, consider:

• Changing the interface to include metadataJSON if you want to expose the raw string, or
• Decoding metadataJSON into metadata in getUserAlerts and keeping metadataJSON internal.

This comment applies similarly to other ...JSON fields (e.g., actionJSON on AIInsight) — where you already decode, the types and implementation are nicely aligned.

🤖 Prompt for AI Agents

In types/extended.d.ts around lines 373–387, Alert currently declares metadata?:
any while storage uses metadataJSON; align the type with implementation by
either (A) replacing or adding metadataJSON?: string to the Alert interface so
it reflects the raw stored field, or (B) keep metadata?: any and update
getUserAlerts to decode metadataJSON into metadata (remove metadataJSON from the
returned object) so runtime objects match the type; apply the same pattern to
other *JSON fields (e.g., AIInsight.actionJSON) so types and storage/decoding
are consistent.

[coderabbitai]

Review continued from previous batch...

[coderabbitai]

⚠️ Potential issue | 🔴 Critical

Critical: Missing authorization check in getBusinessEntity.

This function retrieves a business entity by ID without verifying that the entity belongs to the requesting user. Any user can access any business entity if they know the ID.

Add ownership verification:

 export async function getBusinessEntity(entityId: string): Promise<BusinessEntity | null> {
   try {
     const { database } = await createAdminClient();

     const entity = await database.getDocument(
       DATABASE_ID!,
       BUSINESS_ENTITIES_COLLECTION_ID!,
       entityId
     );

     return parseStringify(entity);
   } catch (error) {
     console.error("Error fetching business entity:", error);
     return null;
   }
 }

Should be:

-export async function getBusinessEntity(entityId: string): Promise<BusinessEntity | null> {
+export async function getBusinessEntity(entityId: string, userId: string): Promise<BusinessEntity | null> {
   try {
     const { database } = await createAdminClient();

     const entity = await database.getDocument(
       DATABASE_ID!,
       BUSINESS_ENTITIES_COLLECTION_ID!,
       entityId
     );
+
+    // Verify ownership
+    if (entity.userId !== userId) {
+      throw new Error("Unauthorized access to business entity");
+    }

     return parseStringify(entity);
   } catch (error) {
     console.error("Error fetching business entity:", error);
     return null;
   }
 }

📝 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

	export async function getBusinessEntity(entityId: string): Promise<BusinessEntity | null> {
	try {
	const { database } = await createAdminClient();
	const entity = await database.getDocument(
	DATABASE_ID!,
	BUSINESS_ENTITIES_COLLECTION_ID!,
	entityId
	);
	return parseStringify(entity);
	} catch (error) {
	console.error("Error fetching business entity:", error);
	return null;
	}
	}
	export async function getBusinessEntity(entityId: string, userId: string): Promise<BusinessEntity | null> {
	try {
	const { database } = await createAdminClient();
	const entity = await database.getDocument(
	DATABASE_ID!,
	BUSINESS_ENTITIES_COLLECTION_ID!,
	entityId
	);
	// Verify ownership
	if (entity.userId !== userId) {
	throw new Error("Unauthorized access to business entity");
	}
	return parseStringify(entity);
	} catch (error) {
	console.error("Error fetching business entity:", error);
	return null;
	}
	}

🤖 Prompt for AI Agents

In lib/actions/business.actions.ts around lines 83 to 98, getBusinessEntity
currently returns any entity by ID without verifying ownership; change the
function to accept the requesting user's ID (e.g., add a parameter like
requestingUserId: string), fetch the entity as now, then verify the entity's
ownership field (e.g., entity.ownerId or owner_user_id) matches requestingUserId
and return null (or throw an authorization error) if it does not; update all
callers to pass the requester user ID and ensure the ownership field name
matches the DB schema and is validated before returning the entity.

[coderabbitai]

⚠️ Potential issue | 🔴 Critical

Critical: Missing authorization check in getBusinessProjects.

This function retrieves projects by businessEntityId without verifying the requesting user owns that business entity.

Add ownership verification:

 export async function getBusinessProjects(
   businessEntityId: string,
+  userId: string,
   filters?: { status?: Project["status"]; clientId?: string }
 ): Promise<Project[]> {
   try {
     const { database } = await createAdminClient();
+
+    // Verify user owns the business entity
+    const entity = await database.getDocument(
+      DATABASE_ID!,
+      BUSINESS_ENTITIES_COLLECTION_ID!,
+      businessEntityId
+    );
+
+    if (entity.userId !== userId) {
+      throw new Error("Unauthorized access to business entity");
+    }

     const queries = [Query.equal("businessEntityId", [businessEntityId])];

🤖 Prompt for AI Agents

In lib/actions/business.actions.ts around lines 420 to 448, getBusinessProjects
currently returns projects for any businessEntityId without verifying the
caller; add an ownership/authorization check before listing projects: accept (or
obtain from auth context) the requesting user's id, fetch the business entity by
businessEntityId, verify the requesting user is the owner or a permitted member
(or has appropriate role), and if not authorized throw an AuthorizationError or
return an empty array; only call database.listDocuments when authorization
succeeds and keep existing error handling/logging.

[coderabbitai]

⚠️ Potential issue | 🔴 Critical

Critical: Missing authorization check in updateProject.

This function updates a project without verifying the requesting user owns the associated business entity.

Add ownership verification:

 export async function updateProject(
   projectId: string,
+  userId: string,
   data: Partial<Project>
 ): Promise<Project | null> {
   try {
     const { database } = await createAdminClient();
+
+    // Verify ownership before update
+    const project = await database.getDocument(
+      DATABASE_ID!,
+      PROJECTS_COLLECTION_ID!,
+      projectId
+    );
+
+    const entity = await database.getDocument(
+      DATABASE_ID!,
+      BUSINESS_ENTITIES_COLLECTION_ID!,
+      project.businessEntityId
+    );
+
+    if (entity.userId !== userId) {
+      throw new Error("Unauthorized access to project");
+    }

     const updated = await database.updateDocument(
       DATABASE_ID!,
       PROJECTS_COLLECTION_ID!,
       projectId,
       data
     );

     return parseStringify(updated);
   } catch (error) {
     console.error("Error updating project:", error);
     return null;
   }
 }

📝 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

	export async function updateProject(
	projectId: string,
	data: Partial<Project>
	): Promise<Project | null> {
	try {
	const { database } = await createAdminClient();
	const updated = await database.updateDocument(
	DATABASE_ID!,
	PROJECTS_COLLECTION_ID!,
	projectId,
	data
	);
	return parseStringify(updated);
	} catch (error) {
	console.error("Error updating project:", error);
	return null;
	}
	}
	export async function updateProject(
	projectId: string,
	userId: string,
	data: Partial<Project>
	): Promise<Project | null> {
	try {
	const { database } = await createAdminClient();
	// Verify ownership before update
	const project = await database.getDocument(
	DATABASE_ID!,
	PROJECTS_COLLECTION_ID!,
	projectId
	);
	const entity = await database.getDocument(
	DATABASE_ID!,
	BUSINESS_ENTITIES_COLLECTION_ID!,
	project.businessEntityId
	);
	if (entity.userId !== userId) {
	throw new Error("Unauthorized access to project");
	}
	const updated = await database.updateDocument(
	DATABASE_ID!,
	PROJECTS_COLLECTION_ID!,
	projectId,
	data
	);
	return parseStringify(updated);
	} catch (error) {
	console.error("Error updating project:", error);
	return null;
	}
	}

🤖 Prompt for AI Agents

In lib/actions/business.actions.ts around lines 450 to 469, the updateProject
function currently performs an update without verifying that the caller owns the
related business; add an ownership check before calling database.updateDocument:
fetch the existing project by projectId, read its businessId, load the business
record and compare its ownerId (or equivalent owner field) to the requesting
user's id (so updateProject must accept a callerUserId parameter or derive it
from request context), and if they don't match return null or throw an
authorization error; only proceed to database.updateDocument when the caller is
authorized, and log/return a clear unauthorized response.

[coderabbitai]

⚠️ Potential issue | 🟠 Major

🧩 Analysis chain

Missing ownership verification for client access.

The function retrieves a client document without verifying the requesting user has access to it, potentially exposing other users' client data.

Verify that the client belongs to the business entity:

     const { database } = await createAdminClient();

     // Get client details
     const client = await database.getDocument(
       DATABASE_ID!,
       CLIENTS_COLLECTION_ID!,
       data.clientId
     );
+
+    // Verify client belongs to the business entity
+    if (client.businessEntityId !== data.businessEntityId) {
+      throw new Error("Client does not belong to this business entity");
+    }

---

I need to verify the security concern by examining the codebase. Let me investigate the function context and authorization patterns.

---

🏁 Script executed:

```shell
#!/bin/bash
# Get the full createInvoice function to understand context
sed -n '475,553p' lib/actions/business.actions.ts

Length of output: 2219

---

🏁 Script executed:

#!/bin/bash
# Search for how other functions handle client/ownership verification
rg -n "businessEntityId" lib/actions/business.actions.ts -A2 -B2

Length of output: 3262

---

🏁 Script executed:

#!/bin/bash
# Look for type definitions or interfaces for data parameter
ast-grep --pattern 'function createInvoice($_) { $$$ }'

Length of output: 0

---

🏁 Script executed:

#!/bin/bash
# Check if there are any schema or type files
fd -e ts -e tsx -path "*/types/*" -o -path "*/schemas/*" | head -20

Length of output: 168

---

Add ownership verification when retrieving client document.

The function retrieves a client without verifying it belongs to the requesting user's business entity, creating an authorization bypass vulnerability. An attacker could create invoices for clients they don't own.

Apply the suggested fix at lines 486-490:

    const client = await database.getDocument(
      DATABASE_ID!,
      CLIENTS_COLLECTION_ID!,
      data.clientId
    );

+    // Verify client belongs to the business entity
+    if (client.businessEntityId !== data.businessEntityId) {
+      throw new Error("Client does not belong to this business entity");
+    }

📝 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

	const client = await database.getDocument(
	DATABASE_ID!,
	CLIENTS_COLLECTION_ID!,
	data.clientId
	);
	const client = await database.getDocument(
	DATABASE_ID!,
	CLIENTS_COLLECTION_ID!,
	data.clientId
	);
	// Verify client belongs to the business entity
	if (client.businessEntityId !== data.businessEntityId) {
	throw new Error("Client does not belong to this business entity");
	}

🤖 Prompt for AI Agents

In lib/actions/business.actions.ts around lines 486 to 490, the code fetches a
client document but does not verify the client belongs to the requesting
business; after retrieving the client with database.getDocument(...,
data.clientId) add a check comparing the fetched client's business id (e.g.
client.businessId or client.business?.id) to the caller's business id available
in the request data/context (e.g. data.businessId or data.business.id) and if
they don't match throw an authorization error (or return/abort) so callers
cannot operate on clients owned by other businesses.

[coderabbitai]

⚠️ Potential issue | 🟡 Minor

Currency is hardcoded instead of retrieved from business entity.

The comment indicates currency should come from the business entity, but it's hardcoded to "USD".

Retrieve currency from business entity:

+    // Get business entity for currency
+    const businessEntity = await database.getDocument(
+      DATABASE_ID!,
+      BUSINESS_ENTITIES_COLLECTION_ID!,
+      data.businessEntityId
+    );
+
     const invoice = await database.createDocument(
       DATABASE_ID!,
       INVOICES_COLLECTION_ID!,
       ID.unique(),
       {
         userId: data.userId,
         businessEntityId: data.businessEntityId,
         invoiceNumber,
         status: "draft",
         clientId: data.clientId,
         clientName: client.name,
         clientEmail: client.email,
         clientAddress: client.address || null,
         itemsJSON: JSON.stringify(processedItems),
         subtotal,
         vatAmount,
         totalAmount,
-        currency: "USD", // From business entity
+        currency: businessEntity.currency,
         issueDate: new Date().toISOString(),
         dueDate: data.dueDate,
         notes: data.notes || null,
         terms: null,
       }
     );

📝 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

	currency: "USD", // From business entity
	// Get business entity for currency
	const businessEntity = await database.getDocument(
	DATABASE_ID!,
	BUSINESS_ENTITIES_COLLECTION_ID!,
	data.businessEntityId
	);
	const invoice = await database.createDocument(
	DATABASE_ID!,
	INVOICES_COLLECTION_ID!,
	ID.unique(),
	{
	userId: data.userId,
	businessEntityId: data.businessEntityId,
	invoiceNumber,
	status: "draft",
	clientId: data.clientId,
	clientName: client.name,
	clientEmail: client.email,
	clientAddress: client.address || null,
	itemsJSON: JSON.stringify(processedItems),
	subtotal,
	vatAmount,
	totalAmount,
	currency: businessEntity.currency,
	issueDate: new Date().toISOString(),
	dueDate: data.dueDate,
	notes: data.notes || null,
	terms: null,
	}
	);

🤖 Prompt for AI Agents

In lib/actions/business.actions.ts around line 540, the currency is hardcoded to
"USD" but should be taken from the business entity; replace the literal with the
business entity's currency property (e.g., business.currency or
businessEntity.currency) and ensure the variable is in scope, adding a safe
fallback like 'USD' only if the entity value is absent or falsy, and include a
null/undefined check before use.

[coderabbitai]

⚠️ Potential issue | 🔴 Critical

Critical: Missing authorization check in getBusinessInvoices.

This function retrieves invoices by businessEntityId without verifying the requesting user owns that business entity.

Add ownership verification:

 export async function getBusinessInvoices(
   businessEntityId: string,
+  userId: string,
   filters?: { status?: Invoice["status"]; clientId?: string }
 ): Promise<Invoice[]> {
   try {
     const { database } = await createAdminClient();
+
+    // Verify user owns the business entity
+    const entity = await database.getDocument(
+      DATABASE_ID!,
+      BUSINESS_ENTITIES_COLLECTION_ID!,
+      businessEntityId
+    );
+
+    if (entity.userId !== userId) {
+      throw new Error("Unauthorized access to business entity");
+    }

     const queries = [Query.equal("businessEntityId", [businessEntityId])];

[coderabbitai]

⚠️ Potential issue | 🔴 Critical

Critical: Missing authorization check in updateInvoiceStatus.

This function updates invoice status and client totals without verifying the requesting user owns the invoice or associated entities.

Add ownership verification:

 export async function updateInvoiceStatus(
   invoiceId: string,
+  userId: string,
   status: Invoice["status"],
   paidDate?: string
 ): Promise<Invoice | null> {
   try {
     const { database } = await createAdminClient();
+
+    // Verify ownership before update
+    const invoice = await database.getDocument(
+      DATABASE_ID!,
+      INVOICES_COLLECTION_ID!,
+      invoiceId
+    );
+
+    const entity = await database.getDocument(
+      DATABASE_ID!,
+      BUSINESS_ENTITIES_COLLECTION_ID!,
+      invoice.businessEntityId
+    );
+
+    if (entity.userId !== userId) {
+      throw new Error("Unauthorized access to invoice");
+    }

     const updateData: any = { status };
     if (status === "paid" && paidDate) {
       updateData.paidDate = paidDate;
     }

     const updated = await database.updateDocument(
       DATABASE_ID!,
       INVOICES_COLLECTION_ID!,
       invoiceId,
       updateData
     );

Committable suggestion skipped: line range outside the PR's diff.

🤖 Prompt for AI Agents

In lib/actions/business.actions.ts around lines 591 to 634, updateInvoiceStatus
performs invoice and client updates without verifying the requester owns the
invoice; add an authorization check by accepting a requestingUserId (or
equivalent) parameter, fetch the invoice first, fetch the related client if
needed, verify that the invoice (or client) ownerId matches requestingUserId,
and if it does not return null or throw an unauthorized error before performing
any update; only after that ownership check proceed to update the invoice and,
if status is "paid", update the client's totalPaid; propagate clear unauthorized
errors and keep existing error handling for other failures.