Debug and improve your app

Fix only the code involved in this error. Trace the error message to its source, make a targeted change, and leave unrelated working code untouched. Before you report the fix as done, confirm it resolves the original problem without introducing new ones.

Change only what this task requires. Keep the existing variable names, patterns, and architecture, and check dependencies before editing so nothing else breaks. Show the change as a minimal diff rather than a rewrite. If you notice improvements outside the task, list them separately instead of implementing them.

Before you propose a new table or column, review the existing schema and reuse tables and fields that already serve the purpose. Keep any schema change compatible with current queries, plan a migration that preserves existing data, and check foreign keys and constraints before you change anything.

Treat this as a diagnosis, not a quick patch. Gather the error messages, logs, and observed behavior first. Form several hypotheses about the cause, test them one at a time, and document what you ruled out. Propose a fix only once you have identified the root cause, and note any edge cases it affects.

Before you call a fix complete, test it against the original issue, check related functionality for side effects, and make sure performance has not regressed. Walk through the edge cases. Only report the fix as confirmed after these checks pass.

Match the style, naming conventions, and architectural patterns already in this codebase. Use the same error handling, logging, and testing approaches the project uses rather than introducing new ones.

Build new features on the existing architecture instead of introducing a new pattern. Use the extension points the current design already provides, keep existing features working, and explain how the addition fits into the current structure.

For every change, explain what you changed, why it was needed, and how it works. State any assumptions or dependencies. Add a code comment only where the logic is not obvious from the code itself.

Tell me when a fix adds technical debt. Distinguish a quick fix from a proper solution, recommend which one fits this situation, and note what should be refactored later if we take the shortcut.

Apply the patterns and preferences this project has already established, and take my feedback on earlier changes into account. Keep track of past issues and their fixes so we do not repeat them, and ask about the business requirement behind a request when it affects the technical approach.

Before you create a new page, component, or flow, search the codebase for similar functionality. Reuse or extend what exists, and when two features are close, parameterize one component instead of duplicating it.

When you replace functionality, remove the old implementation instead of commenting it out. Before deleting code, check for imports and references to confirm nothing still uses it. Remove unused imports, orphaned components, and unreachable branches you encounter, and explain why each is safe to delete.

Treat working features as locked. Do not remove or substantially change a functioning component unless I ask for it. When fixing an error in one area, do not make "just in case" changes elsewhere. If a change touches a shared component, confirm every feature that depends on it still works.

This error has resisted standard fixes, so step back before trying again. Question the current assumption about the cause, consider fundamentally different approaches rather than variations of the same one, and outline at least three options with their trade-offs before recommending one. Check less obvious sources such as environment configuration, external dependencies, and race conditions. Break the problem into parts that can be verified independently, and add logging or state tracing where the cause is still unclear.

Before you write a query or change the schema, inspect the current tables, fields, and relationships. Reuse existing queries where one already does the job. If you propose a new table or field, confirm nothing equivalent exists under another name and explain why modifying an existing one is not enough. Note any performance implications of the query.

Follow the existing design system and color palette. Before you create a new UI component, study the existing ones and reuse their spacing, typography, interaction patterns, and theming. Take design tokens from the codebase rather than introducing new values, handle hover, active, disabled, and error states consistently, respect the existing responsive behavior, and keep accessibility standards such as color contrast and keyboard navigation.

Debug this methodically rather than by trial and error. Reproduce the exact issue first, then gather console logs, network requests, component state, and error messages. Form hypotheses, test each one, and narrow down the affected components and trigger conditions. Document what you found, and confirm the final fix resolves the issue without regressions elsewhere.

Check the type definitions in both the database schema and the TypeScript interfaces before implementing anything, and keep strict type checking without falling back to the any type. Watch for common mismatches: numbers arriving as strings, date parsing, and nullable fields. Keep naming consistent between database columns and interfaces, and test with realistic data, including null and undefined cases.

Treat data as one pipeline from the database through the API and application state to the UI, and track how it changes at each stage. Invalidate queries so the UI stays in sync with the database, watch for stale cache data, timing issues, and race conditions, and confirm the final data structure matches what each component expects. Add loading states and error boundaries so the UI stays stable when data is missing.

Review this project for performance problems before they become severe: unnecessary database calls, components that re-render too often, N+1 queries and request waterfalls, long lists without virtualization or pagination, and large bundles or unoptimized images. Prioritize fixes by their effect on load time and responsiveness, and avoid optimizations that do not address a measured bottleneck.

Handle errors so the app stays usable: wrap risky operations in try/catch, use error boundaries so one failing component does not crash the whole page, and let components degrade gracefully with partial data. Show users clear, non-technical error messages, add retries and fallbacks where they help, and log enough context to debug without exposing private data. Fix the root cause rather than suppressing the symptom.

Keep a clear component hierarchy with single-responsibility components and well-defined props. Avoid prop drilling by using context or state management where appropriate, and separate data-handling components from presentational ones. When debugging a component, review the whole tree: prop flow, where state lives, and how event handlers connect. Balance reuse against over-abstraction.

For every API call, verify the authentication headers, parameters, and body format, and handle each type of network error explicitly. Keep request payloads, response types, and application state consistently typed. Check CORS configuration in every environment, add retries with exponential backoff for transient failures, respect rate limits, and cache requests where it reduces load. Test both the success path and the failure cases, and document each endpoint's purpose, parameters, and response format.