--- Context from: C:\Users\janic\.gemini\GEMINI.md ---
## Gemini Added Memories
- The visual look and feel for the game is a stylized, whimsical pirate context with a serious tone underneath.
- The user's questions will primarily focus on the 'www-dev' and 'laravel_datagate' folders. They may also ask about 'docker' sometimes, and very rarely about 'autojobs'.
- autojobs is a legacy project that generates entities for WordPress. The goal is to move to Laravel as the source of truth, and no new features should be added to autojobs if possible.
- The `www-dev` project runs in WSL, and the `laravel_datagate` project runs in a Docker container. I am on a Windows host, so I must execute commands for `laravel_datagate` inside its Docker container and commands for `www-dev` inside WSL.
- The user's development environment consists of `www-dev` running in WSL and `laravel_datagate` running in a Docker container named `laravel`. All commands must be executed in the correct context. The user will use Copilot AI for implementation, so my primary role is to provide detailed implementation plans.
- My primary role is to help the user understand what we're doing and why. I do not write code, but instead provide detailed plans for another AI to implement.
- The WordPress plugin `PeliarvostelutAdminAPI` provides production API endpoints under the `/wp-json/admin/review` namespace. The `POST /wp-json/admin/review/` endpoint, used for creating/updating reviews, returns objects with `id`, `url`, `summary`, and `sentence_highlight`. The `key_sentence` from Laravel is mapped to `sentence_highlight` in the response.
- User has experience in entertainment design, professional CMS development (SharePoint, EPiServer), and personal projects with WordPress and Laravel.
- User's SharePoint experience includes several intranet and some web projects, a 4-month frontend refactoring consultancy, and smaller projects like a weather portal using pure HTML/CSS/JavaScript, Backbone, Mustache, and SASS (pre-framework era).
- User's SharePoint projects involved working very tightly in the client layer, utilizing well-implemented Scrum with nearly daily client presence and 2-week sprints.
- User's entertainment design experience is not professional, but includes design process, art fundamentals, and studies in CGMA.
- User's specific interests include: Environment art, tools programming, shaders, digital painting, and automated visual systems for design.
- User's web design skillsets primarily refer to visual design. They also have another WordPress project: a mid-size, content-heavy game review site with a fully custom template/plugins, gradually moving to a Sage-based theme and blocks. This project includes an n8n-based automation process for generating YouTube shorts from reviews combined with gameplay videos.
- The carousel items on the front page don't work correctly.
- On the game page, the error section feels a bit strange because it doesn't have any text on it, it's just an image, and that image doesn't always contain anything with the product logo.
- The Information box on the game page looks very bad.
- Nobody is using the shorts component.
- The platform scoping in the review page is potentially not very good. Perhaps we should explore through A/B testing whether or not it would be better if it was all in one.
- The front page preview items are sub-optimal and have poor reusability and should be re-thought.
- The Editor's choice component looks and feels bad, and it cannot be scrolled.
- The 'per G' items are too dark and weird. The ingress shouldn't be revealed on hover, as it's making the component feel weird and surprising from a UX standpoint.
- Consider separation of different types of content types such as hardware reviews, articles, news, and regular game reviews on the front page.
- The button that loads new content feels a little bit strange. It shows three items for no good reason, and this doesn't feel like a very progressive UI.
- Check that we are actually lazy loading all of the images that are in our front-page carousel.
- New reviews are not visible in the search component. The search component has been implemented in a way that uses a local index instead of an autocomplete. We should be looking into implementing this feature with a conventional autocomplete that retrieves data from the back end.
- The social media icons should be reconsidered. The Twitter icon is out of date. The Discord icon has z-index issues. We should re-evaluate which ones we should have and where we should place them.
- In the desktop version, the front end page carousel arrow feels very awkward since its position is completely inside the element. The entire shaded area should probably be clickable for UX convenience.
- The news page is in a horrible shape. None of the preview items are functioning, the images are not functioning, it doesn't look good. The cards are very uninviting and unprofessional looking.
- We do not have profile pictures. We should add them to bring a little bit of personality to the reviews and other contexts where they exist.
- We were originally considering implementing the shorts as more visible, higher in the hierarchy, but due to their click rates, perhaps at most we should try them out with A/B testing at some point to redetermine whether or not it's a conceptual issue or a presentation one.
- We should probably begin to replace our components one by one with Block and Gutenberg components in order to comply with modern Wordpress development standards.
- The footer is absolutely hideous. We definitely need to rethink it. It's too dark, it contains very outdated information (almost 9 years old), and it's not related in any way to the current content of the site.
- Categorized Task List:

**Front Page & General UI:**
*   **Carousel:**
    *   Items don't work correctly.
    *   Arrow on desktop feels awkward; the entire shaded area should be clickable.
    *   Verify that all images are lazy-loaded.
*   **Content & Layout:**
    *   Preview items are sub-optimal and have poor reusability.
    *   Editor's choice component looks bad and is not scrollable.
    *   'per G' items are too dark; ingress shouldn't be on hover.
    *   Consider separating content types (hardware, articles, news, reviews).
    *   The "load more" button feels strange.
*   **Footer:**
    *   The footer is hideous, dark, and has outdated information.
*   **Social Media:**
    *   Reconsider social media icons (outdated Twitter, z-index on Discord).

**Specific Pages:**
*   **Game Page:**
    *   The error section feels strange (just an image, no text).
    *   The Information box looks very bad.
*   **News Page:**
    *   The page is in horrible shape; preview items, images, and cards are broken and unprofessional.
*   **Review Page:**
    *   Platform scoping is potentially not very good; consider A/B testing.

**Features & Technical Debt:**
*   **Search:**
    *   New reviews aren't in the search component; it should be a proper autocomplete.
*   **Shorts Component:**
    *   Nobody is using the shorts component; re-evaluate with A/B testing.
*   **User Profiles:**
    *   Add profile pictures for personality.
*   **Modernization:**
    *   Begin replacing components one by one with Gutenberg blocks.
- Tasks are now located in the folder: D:\projects\web\gamereality\bedrock\docs\obsidian\Game Reality Project\Tasks
- The user wants to build a skill-set that over time, allows them to develop technical systems around their design aesthetic, so that they could produce entire games, or a chunk such as the visuals of a game.
- My primary role is to produce tasks and relevant descriptions of our issues and intent in form of documents to sonnet to implement.
- When the user refers to 'movies', they are typically referring to the ffmpeg and moviepy Docker containers. The goal is to manage their features based on which one is more suitable for the task.
- When the user asks me to write an issue, I need to persist it in a way that sonnet can easily access it.
- The issue with frozen segments in split videos has been resolved.
- When investigating issues, document the findings in accessible files (like problem files or GEMINI.md). If an initial hypothesis about the cause or fix is incorrect, update the documentation to reflect the actual code state and the remaining unknowns or alternative investigation paths. This ensures that the investigation process and current understanding are available for future reference and for other LLMs.
- The term 'per g items' should be understood as 'preview items'.
--- End of Context from: C:\Users\janic\.gemini\GEMINI.md ---

## Instructions for Task and Issue Documentation (for Sonnet)

**Purpose:** To ensure clear, consistent, and actionable documentation for all tasks and issues, facilitating efficient implementation and tracking.

**Location:** All task and issue documents should be created as Markdown files within the `D:\projects\web\gamereality\bedrock\docs\obsidian\Game Reality Project\Tasks` directory.

**Format:** Each document must be a Markdown file (`.md`).

**Content Structure:** Each task/issue document should adhere to the following structure:

```markdown
# Task: [Concise Task/Issue Title]

## Problem
[Clearly describe the current problem or bug. What is happening that shouldn't, or what is missing?]

## Goal
[State the desired outcome or objective of this task. What should be achieved once this task is complete?]

## Context
[Provide relevant background information. This might include:
- Where in the codebase the issue/task is located (e.g., specific files, components).
- Current implementation details that are relevant to the change.
- Why this task is important (e.g., user experience impact, technical debt, business value).
- Any specific constraints or considerations (e.g., performance, compatibility).
- Mention relevant tech stack decisions (e.g., "Frontend will use Vanilla JS and Axios, not jQuery").
]

## Proposed Solution for Sonnet
[Outline the high-level steps or approach Sonnet should take to address the task. This should be a guide, not a line-by-line instruction.
- Break down the solution into logical sub-steps (e.g., Backend changes, Frontend changes, Testing).
- Specify which project context applies (e.g., `www-dev` in WSL, `laravel_datagate` in Docker).
- Mention any specific tools or libraries to use or avoid (e.g., "Use Axios for API calls," "Avoid jQuery for new development").
]

## Acceptance Criteria
[Define clear, measurable conditions that must be met for the task to be considered complete and successful.
- What should the user observe?
- What tests should pass?
- What are the performance expectations?
]

## Priority
[Assign a priority level (e.g., High, Medium, Low) and briefly justify it.]
```

**Example:** Refer to `Implement_Backend_Autocomplete_Search.md` for a practical example of this structure.

**Key Principles:**
*   **Clarity:** Ensure all descriptions are unambiguous.
*   **Actionability:** The document should provide enough information for Sonnet to begin implementation.
*   **Consistency:** Adhere to this structure for all new task and issue documents.
*   **Contextual:** Always provide sufficient context for Sonnet to understand the 'why' behind the 'what'.