Some errors occurred when validating the changesets config:
The package or glob expression "giselles-ai" is specified in the `ignore` option but it is not found in the project. You may have misspelled the package name or provided an invalid glob expression. Note that glob expressions must be defined according to https://www.npmjs.com/package/micromatch.

# **Prompt for AI Code Assistant: Generate E2E Tests for Nodemailer Dependency Bump**

Hello! I need you to act as an expert QA engineer and generate E2E tests using Playwright.

This PR involves a major version bump of `nodemailer`, a critical dependency for sending emails in our `studio.giselles.ai` application. We need to ensure that no regressions have been introduced and that all email-related functionalities are working as expected. Pay close attention to potential breaking changes noted in the release logs.

### 1. Context Summary

*   **PR Description:** The PR updates `nodemailer` from `v7.0.11` to `v8.0.5`. This is a major version bump that includes security patches, bug fixes, and a significant breaking change.
*   **Key Change Impact:** This change exclusively affects the backend logic for sending emails. All user flows that trigger an email are at risk of regression.
*   **Breaking Change:** The `nodemailer` v8.0.0 release notes mention a breaking change: `Error code 'NoAuth' renamed to 'ENOAUTH'`. Our backend error handling might be affected. While we can't test the backend code directly with Playwright, we must verify that the UI handles any potential email-sending failures gracefully.
*   **Critical Paths for Testing:**
    1.  **User Registration:** The flow where a new user signs up and should receive a welcome or verification email.
    2.  **Password Reset:** The "Forgot Password" flow where a user requests a password reset link via email.
    3.  **Contact/Feedback Forms:** Any forms that send an email notification to administrators or a confirmation to the user upon submission.

### 2. Test Scenarios

Please generate tests covering the following scenarios. Assume the application has standard "Sign Up," "Login," and "Forgot Password" pages.

*   **Test File:** Create a new test file named `e2e/email-flows.spec.ts`.

#### Scenario 1: Successful User Registration (Happy Path)
*   **Goal:** Verify that a user can complete the sign-up form and the UI confirms that a verification email has been sent.
*   **Steps:**
    1.  Navigate to the `/signup` page.
    2.  Fill in the registration form (e.g., name, email, password). Use a unique, dynamically generated email address to ensure test isolation (e.g., `test-user-${Date.now()}@example.com`).
    3.  Click the "Sign Up" or "Register" button.
    4.  **Assert:** The user is redirected to a confirmation page OR a success toast/message appears on the current page. The message should be similar to "Registration successful! Please check your email to verify your account."

#### Scenario 2: Successful Password Reset Request (Happy Path)
*   **Goal:** Verify that a user can request a password reset and the UI confirms that instructions have been sent.
*   **Setup:** This test requires a pre-existing user. Use a seeded test user account (e.g., `test-user@example.com`) or create one in a `test.beforeEach` block.
*   **Steps:**
    1.  Navigate to the `/forgot-password` page.
    2.  Enter the email address of the existing test user.
    3.  Click the "Send Reset Link" button.
    4.  **Assert:** A success message is displayed on the page, like "If an account with that email exists, a password reset link has been sent."

#### Scenario 3: Graceful Failure on Email Service Error (Sad Path)
*   **Goal:** Simulate a backend failure during an email-sending process and verify the UI displays a user-friendly error message. This directly tests the application's resilience to backend issues, including the `ENOAUTH` breaking change.
*   **Strategy:** Use Playwright's network mocking (`page.route()`) to intercept the API call that triggers the email (e.g., `POST /api/auth/signup`) and force a 500 Internal Server Error response.
*   **Steps:**
    1.  Define a route handler before the action: `await page.route('**/api/auth/signup', route => route.abort('failed'));` or `route => route.fulfill({ status: 500, json: { message: 'Email service unavailable' } })`.
    2.  Navigate to the `/signup` page.
    3.  Fill in the registration form with valid data.
    4.  Click the "Sign Up" button.
    5.  **Assert:** An error message or toast is displayed to the user, such as "An error occurred. Please try again later." The user should **not** be redirected to a success page.

### 3. Playwright Implementation Instructions

*   **Selectors:** Use `data-testid` attributes for robust selectors where possible. If not available, use `page.getByRole`, `page.getByLabel`, or `page.getByPlaceholderText`.
    *   Sign-up Email: `page.getByLabel('Email')` or `page.getByTestId('signup-email-input')`
    *   Sign-up Button: `page.getByRole('button', { name: /Sign Up|Register/i })`
    *   Success Message: `page.getByText(/check your email/i)`
    *   Error Message: `page.getByText(/An error occurred|Something went wrong/i)`

*   **Assertions:** Use `expect` from `@playwright/test`.
    *   `await expect(page.getByText('...')).toBeVisible();`
    *   `await expect(page).toHaveURL(/.*\/confirmation/);`

*   **Email Verification (Advanced):**
    *   For a complete test, we would ideally check if the email was actually sent and received. Add comments in the code suggesting how to integrate with an email testing service like [MailHog](https://github.com/mailhog/MailHog) or [Ethereal](https://ethereal.email/).
    *   **Example comment to add:**
        ```typescript
        // ADVANCED: To verify email receipt, an email testing service like MailHog should be used.
        // After this step, an API call would be made to the MailHog API to fetch the latest email
        // for 'test-user@example.com' and assert its contents.
        // const mailhogResponse = await request.get('http://localhost:8025/api/v2/messages');
        // const emails = await mailhogResponse.json();
        // expect(emails.items[0].Content.Headers.To[0]).toContain('test-user@example.com');
        ```

### 4. MCP Integration Guidelines

*   **Execution Command:** The generated tests can be run via Playwright MCP with the following command structure. Please add this as a comment at the top of the test file.
    ```bash
    # To run these tests via Playwright MCP:
    # mcp playwright test e2e/email-flows.spec.ts --project=chromium
    ```
*   **Environment Configuration:** These tests will require environment variables for the application to connect to the database and SMTP server. Ensure the test environment (`.env.test` or CI variables) is configured with placeholder/test credentials for the email service.

### 5. CI-Ready Code Requirements

*   **Structure:**
    *   Use `describe` blocks to group related tests: `describe('Email Sending Functionality', () => { ... });`
    *   Use `test.beforeEach` for setup logic (like navigation or user creation) to keep tests DRY.
*   **Naming Conventions:**
    *   Test file: `email-flows.spec.ts`
    *   Test descriptions: Use clear, descriptive titles like `test('should show success message after user registration', async ({ page }) => { ... });`
*   **Isolation and Parallelization:**
    *   Ensure all tests are atomic and independent.
    *   The use of dynamic data (e.g., unique emails) is critical for running tests in parallel without collisions. Avoid any shared state between test files.
*   **Code Quality:** Generate clean, readable TypeScript code with appropriate `async/await` and type annotations.