fix: ui: theme provider not loading

[npv12]

Important

Fix theme provider loading issue by dynamically importing NextThemesProvider and update backend to handle large transaction data efficiently.

• Frontend:
  • ThemeProvider.tsx: Use dynamic import for NextThemesProvider to prevent SSR, fixing theme loading issue.
  • Update API_BASE_URL in api.ts to use port 8000.
• Backend:
  • statement_controller_test.go: Adjust test to handle 100K transactions.
  • statement_repository.go: Add CreateStatementTxns() for bulk transaction linking.
  • transaction_repository.go: Add CreateTransactions() for bulk transaction creation.
• Mocks:
  • statement_repository.go and transaction_repository.go: Add bulk operations for testing.
• Misc:
  • Remove .cursor/rules and .zed/debug.json files.
  • Add AGENTS.md for project overview and guidelines.

^{This description was created by for aad736a. You can customize this summary. It will automatically update as commits are pushed.}

[ellipsis-dev]

Important

Looks good to me! 👍

Reviewed everything up to aad736a in 1 minute and 50 seconds. Click for details.

• Reviewed 1825 lines of code in 18 files
• Skipped 0 files when reviewing.
• Skipped posting 11 draft comments. View those below.
• Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.

1. frontend/components/providers/ThemeProvider.tsx:1

• Draft comment:
  Good use of dynamic import to defer loading NextThemesProvider with SSR disabled. No major issues.
• Reason this comment was not posted:
  Confidence changes required: 0% <= threshold 1% None

2. frontend/lib/constants/api.ts:1

• Draft comment:
  Default API base URL changed to http://localhost:8000. Ensure the environment variable is set appropriately in production.
• Reason this comment was not posted:
  Confidence changes required: 0% <= threshold 1% None

3. server/internal/api/controller/statement_controller_test.go:45

• Draft comment:
  Test timing modified: reduced iteration count and increased sleep duration. Verify that 8 iterations with 5s sleep reliably cover statement processing time without causing excessive delays.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 1% The comment is asking the PR author to verify the timing changes, which violates the rule against asking for confirmation or verification. It doesn't provide a specific suggestion or point out a clear issue with the code.

4. server/internal/mock/repository/statement_repository.go:64

• Draft comment:
  Mock repository for statements looks straightforward; ensure error messages and locking behavior mimic the production implementation.
• Reason this comment was not posted:
  Confidence changes required: 0% <= threshold 1% None

5. server/internal/mock/repository/transaction_repository.go:90

• Draft comment:
  Duplicate checking logic in CreateTransactions relies on comparing composite fields. Consider potential floating‐point precision issues and ensure consistency with production formatting.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 15% vs. threshold = 50% The comment raises concerns about floating-point precision and consistency with production. However, several issues make this comment questionable: (1) This is a MOCK repository, explicitly for testing, not production code. (2) The comment is speculative ("Consider potential...") rather than pointing to a definite issue. (3) The same duplicate checking logic exists in the existing CreateTransaction method (lines 38-52) which wasn't flagged, suggesting this isn't a new issue introduced by this change. (4) The comment doesn't provide clear, actionable guidance - it just asks to "consider" and "ensure consistency" without specific recommendations. (5) According to the rules, speculative comments like "potential issues" should be removed. The floating-point comparison issue could be legitimate if Amount is a float type, as direct equality comparisons can fail due to precision. However, without seeing the type definition, I can't be certain. Also, the existing code already has this pattern, so if it's an issue, it's not new to this PR. While floating-point precision could theoretically be an issue, this comment is speculative ("Consider potential..."), doesn't provide actionable guidance, and the same pattern exists in unchanged code (CreateTransaction method). The comment also mentions "consistency with production" but this is explicitly a mock repository. Without strong evidence this is a real problem, and given the speculative nature, this comment should be deleted. Delete this comment. It's speculative ("Consider potential..."), doesn't provide clear actionable guidance, and the same comparison logic exists in the unchanged CreateTransaction method. If this were a real issue, it would affect existing code too, not just the new method.

6. server/internal/repository/statement_repository.go:68

• Draft comment:
  Bulk insert in CreateStatementTxns uses dynamic placeholders correctly. Verify that schema and mapping table names come from a trusted source to avoid injection risks.
• Reason this comment was not posted:
  Confidence changes required: 0% <= threshold 1% None

7. server/internal/repository/transaction_repository.go:135

• Draft comment:
  The bulk CreateTransactions implementation is complex but well structured. The use of a mapping key (transactionInsertKey) is clever; however, ensure that formatting (e.g. whitespace and numeric precision) is consistent to avoid mismatches.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 1% The comment is asking the author to ensure consistency in formatting, which is a general request for verification. It doesn't provide a specific suggestion or point out a specific issue in the code. This falls under the rule of not asking the author to ensure behavior is intended or to double-check things.

8. server/internal/service/rule_engine_service.go:38

• Draft comment:
  In ExecuteRules, a new goroutine is spawned with context.Background() instead of propagating the caller’s context. Consider using the provided ctx to allow proper cancellation.
• Reason this comment was not posted:
  Comment was not on a location in the diff, so it can't be submitted as a review comment.

9. server/internal/service/statement_service.go:77

• Draft comment:
  processStatementAsync is launched with context.Background(). It may be better to pass a derived context to allow cancellation propagation.
• Reason this comment was not posted:
  Comment was not on a location in the diff, so it can't be submitted as a review comment.

10. server/internal/service/transaction_service.go:128

• Draft comment:
  UpdateTransaction compares errors via string equality for NoFieldsToUpdate. Consider using errors.Is for robust error comparison.
• Reason this comment was not posted:
  Comment was not on a location in the diff, so it can't be submitted as a review comment.

11. server/internal/service/transaction_service.go:208

• Draft comment:
  Validation methods (validateDateNotInFuture, validateAccountExists, validateCategoryExists) are clear. The use of current day (23:59:59) is acceptable, but ensure this aligns with business requirements.
• Reason this comment was not posted:
  Confidence changes required: 0% <= threshold 1% None

Workflow ID: wflow_IZMkhFZaCLhFp7Rl

^{You can customize by changing your verbosity settings, reacting with 👍 or 👎, replying to comments, or adding code review rules.}