|
3 | 3 | This document provides guidelines for AI agents working on the GenMedia Creative Studio codebase. |
4 | 4 |
|
5 | 5 | ## Styling |
| 6 | + |
6 | 7 | - Prefer using shared styles from `components/styles.py` for common UI elements and layout structures. |
7 | 8 | - Page-specific or component-specific styles that are not reusable can be defined locally within those files. |
8 | 9 |
|
9 | 10 | ## Google Cloud Storage (GCS) |
| 11 | + |
10 | 12 | - All interactions with GCS for storing media or other assets should use the `store_to_gcs` utility function located in `common/storage.py`. |
11 | 13 | - This function is configurable via `config/default.py` for bucket names. |
12 | 14 |
|
13 | 15 | ## Configuration |
| 16 | + |
14 | 17 | - Application-level configuration values, such as model IDs, API keys (though avoid hardcoding keys directly), GCS bucket names, and feature flags, should be defined in `config/default.py`. |
15 | 18 | - Access these configurations by importing `cfg = Default()` from `config.default`. |
16 | 19 |
|
17 | 20 | ## State Management |
| 21 | + |
18 | 22 | - Global application state (e.g., theme, user information) is managed in `state/state.py`. |
19 | 23 | - Page-specific UI state should be defined in corresponding files within the `state/` directory (e.g., `state/imagen_state.py`, `state/veo_state.py`). |
20 | 24 |
|
21 | 25 | ## Error Handling |
| 26 | + |
22 | 27 | - For errors that occur during media generation processes and need to be communicated to the user, use the `GenerationError` custom exception defined in `common/error_handling.py`. |
23 | 28 | - Display these errors to the user via dialogs or appropriate UI elements. |
24 | 29 | - Log detailed errors to the console/server logs for debugging. |
25 | 30 |
|
26 | 31 | ## Adding New Generative Models |
| 32 | + |
27 | 33 | - When adding a new generative model capability (e.g., a new type of image model, a different video model): |
28 | | - - Add model interaction logic (API calls, request/response handling) to a new file in the `models/` directory (e.g., `models/new_model_name.py`). |
29 | | - - Create UI components for controlling the new model in a subdirectory under `components/` (e.g., `components/new_model_name/generation_controls.py`). |
30 | | - - Create a new page for the model in `pages/` (e.g., `pages/new_model_name.py`), utilizing the page scaffold and new components. |
31 | | - - Define any page-specific state in `state/new_model_name_state.py`. |
32 | | - - Add relevant configurations to `config/default.py`. |
33 | | - - Update navigation in `config/navigation.json`. |
| 34 | + - Add model interaction logic (API calls, request/response handling) to a new file in the `models/` directory (e.g., `models/new_model_name.py`). |
| 35 | + - Create UI components for controlling the new model in a subdirectory under `components/` (e.g., `components/new_model_name/generation_controls.py`). |
| 36 | + - Create a new page for the model in `pages/` (e.g., `pages/new_model_name.py`), utilizing the page scaffold and new components. |
| 37 | + - Define any page-specific state in `state/new_model_name_state.py`. |
| 38 | + - Add relevant configurations to `config/default.py`. |
| 39 | + - Update navigation in `config/navigation.json`. |
34 | 40 |
|
35 | 41 | ## Metadata |
| 42 | + |
36 | 43 | - When storing metadata for generated media, use the `MediaItem` dataclass from `common/metadata.py` and the `add_media_item_to_firestore` function. |
37 | 44 | - Ensure all relevant fields in `MediaItem` are populated. |
38 | 45 |
|
39 | 46 | ## Testing |
| 47 | + |
40 | 48 | - Write unit tests for utility functions and model interaction logic. |
41 | 49 | - Aim to mock external API calls during unit testing. |
42 | 50 | - Use `pytest` as the testing framework. |
43 | 51 |
|
44 | 52 | ## Code Quality |
| 53 | + |
45 | 54 | - Use `ruff` for code formatting and linting. Ensure code is formatted (`ruff format .`) and linted (`ruff check --fix .`) before submitting changes. |
| 55 | + |
| 56 | + |
| 57 | +## 🤖 GitHub Automation Agents |
| 58 | + |
| 59 | +This repository uses **Google's Gemini CLI** to automate software engineering tasks. Our AI agents assist with code reviews, issue triage, and general maintenance to keep the project moving efficiently. |
| 60 | + |
| 61 | +## Automatic Behaviors |
| 62 | + |
| 63 | +These agents run automatically based on events in the repository. |
| 64 | + |
| 65 | +### 🔎 Code Reviewer |
| 66 | + |
| 67 | +- **Trigger:** When a **Pull Request** is opened. |
| 68 | + |
| 69 | +- **Action:** The agent reviews the code changes (diff), looking for bugs, security issues, and style improvements. |
| 70 | +- **Output:** It posts review comments directly on the PR. |
| 71 | +- **Note:** The agent focuses on the *diff* only and provides constructive feedback. It does not replace human review. |
| 72 | + |
| 73 | +### 📋 Issue Triage |
| 74 | + |
| 75 | +- **Trigger:** When a new **Issue** is opened. |
| 76 | + |
| 77 | +- **Action:** The agent analyzes the title and body of the issue. |
| 78 | +- **Output:** It automatically applies relevant **Labels** (e.g., `bug`, `enhancement`, `question`) to help organize the backlog. |
| 79 | + |
| 80 | +--- |
| 81 | + |
| 82 | +## Maintainer Commands |
| 83 | + |
| 84 | +Project maintainers (Owners, Members, Collaborators) can manually invoke the agents using comment commands. |
| 85 | + |
| 86 | +| Command | Description | |
| 87 | +| :--- | :--- | |
| 88 | +| `@gemini-cli /review` | Manually triggers a full code review on the current Pull Request. | |
| 89 | +| `@gemini-cli /triage` | Manually triggers label analysis on the current Issue or PR. | |
| 90 | +| `@gemini-cli [question]` | Ask the agent a question about the codebase or request a specific task. |
| 91 | + |
| 92 | +*Example:* `@gemini-cli Explain how the authentication flow works.` | |
| 93 | + |
| 94 | +> **Note:** These commands are restricted to project maintainers to prevent abuse and manage costs. |
| 95 | +
|
| 96 | +--- |
| 97 | + |
| 98 | +## Workflow Architecture |
| 99 | + |
| 100 | +The automation is built on GitHub Actions using a "Router-Worker" pattern: |
| 101 | + |
| 102 | +1. **Dispatch Router (`gemini-dispatch.yml`):** The entry point. It listens for events, validates permissions, and routes the request to the correct worker. |
| 103 | +2. **Worker Workflows:** |
| 104 | + - `gemini-review.yml`: Handles code analysis. |
| 105 | + - `gemini-triage.yml`: Handles labeling. |
| 106 | + - `gemini-invoke.yml`: Handles general Q&A. |
| 107 | + |
| 108 | +This system is powered by the [Gemini CLI](https://github.com/google-github-actions/run-gemini-cli) action. |
0 commit comments