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 Agent: Generate Playwright E2E Tests**

**Act as an expert QA engineer specializing in automated E2E testing with Playwright.**

Your task is to generate a comprehensive E2E test suite for the `AppEntryInputDialog` component based on the provided context. The component has been refactored to simplify its props and data fetching logic.

### 1. Context Summary

The pull request refactors the `AppEntryInputDialog` component. Previously, it could accept either an `app` object directly or a `node` object, from which it would then fetch the app details.

The change removes the ability to pass the `app` prop directly. The component now **only accepts a `node: AppEntryNode` prop** and **always uses the `useSWR` hook to fetch the app configuration** from the `getApp` endpoint whenever the node's status is `"configured"`.

*   **Key Functionality Change:** The data flow is now unified. The component is entirely dependent on a remote data fetch (`useSWR`) to render its main content when the associated node is configured.
*   **Affected User Flow:** The primary user flow is a user triggering the opening of this dialog, which should then display a form based on the configuration of an "App".
*   **Critical Paths to Test:**
    1.  The loading state while the app configuration is being fetched.
    2.  The successful rendering of the form after the data fetch completes.
    3.  The behavior when the component is rendered for a node that is *not* configured (i.e., no data fetch should occur).
    4.  The handling of data fetch errors.
    5.  Regression testing of the form's submission functionality.

### 2. Test Scenarios

Generate tests covering the following scenarios. Each test should be atomic and self-contained.

*   **Happy Path Scenarios:**
    1.  **Test 1: Displays Loading State and Renders Form on Success:**
        *   **Given:** The `AppEntryInputDialog` is opened with a `node` prop where `node.content.status` is `"configured"`.
        *   **When:** The `getApp` API call is in flight.
        *   **Then:** A loading indicator (`LoaderIcon`) should be visible within the dialog.
        *   **When:** The `getApp` API call resolves successfully with a valid app configuration.
        *   **Then:** The loading indicator should disappear.
        *   **And:** The form, including input fields defined in the mock API response, should be rendered and visible.

    2.  **Test 2: Form Submission (Regression Test):**
        *   **Given:** The dialog has successfully loaded and rendered the form (as in Test 1).
        *   **When:** The user fills in the form fields with valid data and clicks the "Run" button (the one with `PlayIcon`).
        *   **Then:** The `onSubmit` callback should be triggered with the correct input data structure. (You can test this by asserting a side effect, like a console log or a mocked function call).

*   **Edge Case & Sad Path Scenarios:**
    3.  **Test 3: Handles API Fetch Error:**
        *   **Given:** The `AppEntryInputDialog` is opened with a `configured` node.
        *   **When:** The `getApp` API call is mocked to return a 500 server error.
        *   **Then:** The dialog should display a user-friendly error state (e.g., an error message, a disabled submit button). It should not be stuck in a loading state.

    4.  **Test 4: Non-Configured Node:**
        *   **Given:** The `AppEntryInputDialog` is opened with a `node` prop where `node.content.status` is **not** `"configured"`.
        *   **When:** The component renders.
        *   **Then:** No network request to the `getApp` endpoint should be made.
        *   **And:** The dialog should render in a non-interactive or empty state, as there is no app schema to display. Assert that the main form content area is empty or shows a placeholder.

### 3. Playwright Implementation Instructions

Use the following guidelines to write the tests in TypeScript.

*   **Mocking API Requests:** Use `page.route()` to intercept and mock the `getApp` API call. This is **critical** for testing all scenarios without a real backend. The `useSWR` hook in the component will use the mocked responses.

    ```typescript
    // Example of mocking a successful response
    await page.route('**/api/v1/apps/*', async (route, request) => {
        // Assuming the endpoint is something like /api/v1/apps/{appId}
        if (request.url().includes('getApp')) { // Make this more specific if possible
            const mockAppResponse = {
                app: {
                    id: 'app-123',
                    name: 'My Test App',
                    config: {
                        inputs: [
                            { type: 'text', name: 'prompt', label: 'User Prompt' },
                            { type: 'file', name: 'context_file', label: 'Context File' }
                        ]
                    }
                }
            };
            await route.fulfill({
                status: 200,
                contentType: 'application/json',
                body: JSON.stringify(mockAppResponse),
            });
        }
    });

    // Example of mocking an error response
    await page.route('**/api/v1/apps/*', async (route) => {
        await route.fulfill({
            status: 500,
            contentType: 'application/json',
            body: JSON.stringify({ message: 'Internal Server Error' }),
        });
    });
    ```

*   **Selectors:** Target elements robustly. The diff indicates usage of Radix UI and Lucide icons.
    *   **Dialog:** `page.getByRole('dialog')`
    *   **Loading Icon:** The `LoaderIcon` likely renders as an SVG. A `data-testid` is best. If not present, use a selector like `getByRole('dialog').locator('svg.lucide-loader-icon')`. For the purpose of this task, let's assume a `data-testid="loading-spinner"` is added.
    *   **Form Inputs:** `page.getByLabel('User Prompt')`
    *   **Submit Button:** `page.getByRole('button', { name: 'Run' })` (Assuming the button with `PlayIcon` has accessible text "Run").
    *   **Close Button:** `page.getByRole('button', { name: 'Close' })`

*   **User Interactions:**
    *   Use `await page.click(...)` to open the dialog (this part will be outside the component's test, simulating how a user opens it).
    *   Use `await locator.fill(...)` to enter text into inputs.
    *   Use `await locator.click()` to submit the form.

*   **Assertions:**
    *   `await expect(page.getByTestId('loading-spinner')).toBeVisible();`
    *   `await expect(page.getByTestId('loading-spinner')).toBeHidden();`
    *   `await expect(page.getByRole('dialog')).toBeVisible();`
    *   `await expect(page.getByLabel('User Prompt')).toBeVisible();`
    *   To verify a network call was NOT made, you can use a flag inside `page.route` and assert its state after the interaction.

    ```typescript
    let getAppCalled = false;
    await page.route('**/api/v1/apps/*', () => { getAppCalled = true; /* ... */ });
    // ... perform action ...
    expect(getAppCalled).toBe(false);
    ```

### 4. MCP Integration Guidelines

*   **Command Structure:** The tests should be executable via a standard Playwright MCP command.
    ```bash
    # Example command to run a specific test file
    mcp playwright test -- src/app/app-entry-input-dialog/dialog.spec.ts
    ```
*   **Environment:** The tests should not depend on any specific `.env` variables other than a potential `BASE_URL` which Playwright can be configured to use. Since we are mocking all API calls, no backend-specific variables are needed.

### 5. CI-Ready Code Requirements

*   **Test Organization:**
    *   Create a new test file named `dialog.spec.ts` inside the `src/app/app-entry-input-dialog/` directory.
    *   Use a top-level `describe('AppEntryInputDialog', () => { ... });` block to group all tests for this component.
*   **Naming Conventions:**
    *   Test names should clearly describe the behavior being tested, e.g., `test('should display a loading state while fetching the app configuration')`.
*   **Code Structure:**
    *   Write clean, readable, and well-commented code.
    *   Each `test` block should be independent. Use `test.beforeEach` to perform common setup for a group of tests, such as mocking the route or navigating to a page, but ensure mocks are specific to the test case if they differ.
*   **Parallelization:** Ensure tests are atomic and do not share state. Mocking API responses within each test using `page.route` naturally supports this, allowing tests to run in parallel without interference.