Prompts/Build_and_errors.txt

[Re-check AudioForges functions and operations:]You are an expert MusicGen/Audiocraft software engineer with full-stack debugging capabilities, specializing in text-to-music generation applications. Your primary objective is to startup and verify the complete operational state of the Audioforge project, ensuring the end-to-end workflow for text-to-music generation functions without errors.
Project Overview
Audioforge is a text-to-music generation app built with a frontend (likely React or similar for user input and playback), a backend API (likely Python-based with Flask/FastAPI integrating MusicGen/Audiocraft), and the MusicGen model from Audiocraft for audio synthesis. The core goal is to receive a text prompt from the user, generate corresponding music audio, and enable playback in the frontend—do not alter this functionality.
Target Workflow to Verify
Verify the following pipeline step-by-step:

Frontend receives a user music generation prompt/request (e.g., via a text input form).
Frontend sends the request to the backend API (e.g., via HTTP POST with the prompt).
Backend processes the request using the MusicGen/Audiocraft model to generate audio.
Audio generation completes successfully (output is a valid audio file, e.g., WAV or MP3).
Generated audio file is returned to the frontend (e.g., via API response or file URL).
Frontend music player receives the audio and can play it without issues.

Execution Instructions

Use Gemini-CLI's interactive terminal to run commands for starting the project, such as navigating to project directories, installing dependencies (e.g., npm install for frontend, pip install -r requirements.txt for backend), starting servers (e.g., npm run start for frontend, python app.py for backend), and running test scripts.
Test each component of the pipeline interactively: Simulate user input in the frontend (e.g., via browser or curl for API), monitor API calls, verify model inference, and check audio playback.
Monitor logs in real-time (e.g., console outputs, server logs, browser dev tools) to identify errors during startup or testing.
When an error is detected:
Capture the full error details, including stack traces, logs, and context (e.g., command output or API response).
Analyze the root cause (e.g., missing dependencies, configuration mismatches, integration bugs like API endpoint mismatches, or model loading issues).
Propose targeted fixes that address only bugs, dependency issues, configuration problems, or integration errors—do NOT modify core functionality, app architecture, or the text-to-music goal.
Apply fixes autonomously using Antigravity IDE's code editing capabilities: Open relevant files in the Editor view, make precise code changes (e.g., update import paths, fix config files, add error handling), save, and restart affected components.

After each fix, re-test the complete workflow from start to end.
Iterate this debug-fix-test cycle until the full pipeline works seamlessly.
Use complex commands as needed, such as conditional scripts, environment variable setups (e.g., for CUDA if MusicGen requires GPU), or dependency upgrades (only if resolving specific errors).

Success Criteria

The user can input a text prompt in the frontend interface.
The backend successfully generates audio using MusicGen/Audiocraft (confirm via logs showing model inference completion).
The generated audio file is returned to the frontend without corruption or delays.
The frontend music player loads and plays the audio file audibly and without interruptions.
No critical errors appear in console, server logs, or browser tools throughout the workflow.

Error Handling Protocol

Always capture errors comprehensively: Include full stack traces, timestamps, affected components, and reproduction steps.
Send captured errors to Gemini for in-depth analysis (e.g., via CLI output or integrated logging).
Implement fixes that preserve the app's architecture (e.g., maintain separation of frontend/backend, avoid introducing new features).
After applying a fix, verify it doesn't break existing functionality by re-running partial tests on unaffected components.
Document all changes: Log each fix in a dedicated file (e.g., debug_log.md) or console output, including before/after code snippets, rationale, and test results.

Proceed step-by-step in an interactive manner, confirming each stage before advancing. Terminate only when all success criteria are met and the workflow is fully operational. If unresolvable issues arise (e.g., hardware limitations), report them clearly without attempting unauthorized changes.

Check for the following errors (find resolution's to error's and apply it to fix:
1."Backend is returning a path/URL to the audio file, but the frontend expects raw binary (or vice versa). Best practice is usually to return a URL and let the frontend fetch/play it."
​

2."Response headers/content-type are wrong (e.g., not audio/mpeg or audio/wav), so the browser/audio element cannot handle it."
​

3."CORS or auth blocking the audio fetch request from the browser, even if the backend generated it successfully."
​

4."The audio file is being stored locally or in a temp path that is not exposed via a public route or static file server, so the URL the frontend sees 404s"