.agents/brain.md

@@ -23,9 +23,15 @@ This document summarizes the architectural knowledge, conventions, and learnings
   ```
 - **Custom Skills:** Can be defined as JSON files in `.agents/skills/`. We successfully created `close_feature.json` to automate the Git workflow of checking out `main`, merging a feature branch, verifying functionality, and deleting the branch.
 
-## 4. Completed Milestones
+## 4. GitHub Actions & CI/CD
+- **Gemini Code Review Automation:** We integrated `petarzarkov/gemini-code-review-action` to automatically review PRs.
+  - **Secrets:** Must be passed using `env:` instead of `with:` (e.g., `GEMINI_API_KEY`, `GITHUB_TOKEN`), otherwise the action fails with unexpected input errors. NEVER hardcode API keys in workflow files.
+  - **Model Naming:** Google's `v1beta` API is very strict. `gemini-1.5-flash` often fails. You must use the fully-qualified name like `gemini-1.5-flash-latest` or `gemini-2.0-flash-lite`.
+  - **Pinning Versions:** Always pin GitHub Actions to a specific version tag (e.g., `@v1.0.4`) rather than `@latest` to prevent unexpected breaking changes.
+
+## 5. Completed Milestones
 - **Phase 3 (Nutrition):** Implemented. Recipes now store `calories`, `protein`, `carbs`, and `fat`. Admin panel handles inputs, and the UI displays them beautifully.
 - **Phase 4 (Interactive Cooking Mode):** Implemented. Recipes now support step-by-step looping background videos and interactive timers (`step_videos`, `step_timers`). The UI utilizes a fullscreen overlay slider with Vanilla JS logic.
 
-## 5. Next Steps
+## 6. Next Steps
 According to `TODO.md`, the next major feature block is **Phase 5 (PWA & Offline Support)**, which involves service workers, manifest files, and enabling the app to be installable on mobile devices.

.agents/rules/AGENT.md

@@ -15,6 +15,7 @@ The core idea is that all feature development should take place in a dedicated b
    `git checkout main && git pull origin main && git checkout -b feature/your-feature-name`
 3. **Atomic Commits:** Make small, logical, and self-contained commits to your feature branch.
 4. **Push & Pull Request:** Push the feature branch to the remote repository and open a Pull Request (PR) against `main`. PRs act as a forum for discussing the feature and performing code reviews before it is merged.
+   - **GitHub Actions Rule:** When setting up automated workflows (like Gemini AI PR review), **always pin actions to a specific version tag** (e.g., `@v1.0.4`) instead of `@latest` to prevent breaking changes. Ensure secrets are passed safely via repository secrets (`env:`), never hardcoded.
 5. **Merge & Close:** Once approved, the feature branch is merged into `main` and then deleted. (You can use the `close_feature` skill for this).
 
 ### 2. Merge Conflict Policy
@@ -23,14 +24,30 @@ When multiple features are developed simultaneously, `main` might advance before
 #### Resolution Procedure:
 Never force-push blindly or overwrite other developers' work without understanding it. Follow these exact steps to resolve a conflict:
 
-1. **Fetch Latest Main:** Update your local repository's main branch:
+1. **Update Local Main:** Fetch the latest changes from the remote `main` branch.
    ```bash
    git checkout main
    git pull origin main
+   ```
+2. **Merge Main into Feature Branch:** Switch back to your feature branch and merge `main` into it.
+   ```bash
+   git checkout feature/your-feature-name
+   git merge main
+   ```
+3. **Resolve Conflicts:** Git will pause the merge and mark the conflicted files. Open these files in your editor, look for the conflict markers (`<<<<<<<`, `=======`, `>>>>>>>`), and manually choose the correct code. Remove the markers once done.
+4. **Stage and Commit:** After resolving all conflicts, stage the files and finish the merge commit.
+   ```bash
+   git add .
+   git commit -m "Merge main into feature and resolve conflicts"
+   ```
+5. **Push Updates:** Push the resolved feature branch back to the remote repository to update the Pull Request.
+   ```bash
+   git push origin feature/your-feature-name
+   ```
 
 ### 3. Documentation Update
 
-.md Files die nichts an der Integrität oder Impact der Codebase beiwirken sollen als einfacher Commit in Main behandelt werden.
+Markdown files that do not affect the integrity or behavior of the codebase must be committed directly to the `main` branch.
 
 ## Project Management