chore: Remove .gemini context directory from repository

.gemini/project_context.md

@@ -1,42 +0,0 @@
-## Gemini Added Memories
-- I use CachyOS on my main desktop computer.
-- My laptop runs Arch.
-- My kid has a Windows 10 desktop.
-- I have a homelab setup running Proxmox.
-- I lack proper documentation on my homelab setup.
-- The file docs/network-scan.md is a working document for raw scan data and can be overwritten.
-- The file docs/Network-Clients.md is the final, readable documentation for network clients.
-- All homelab related project documentation is stored in /home/joe/Cloud9/Documents/Obisdian/cloud9/homelab-docs
-- We are documenting the user's homelab. So far, we have:
-- Scanned the network and created a `Network-Clients.md` file.
-- Documented the user's CachyOS desktop in `cachyos-desktop.md`.
-- Documented the Brother printer in `brother-printer.md` and created a maintenance CSV.
-- Documented the Proxmox node in `proxmox-node.md`.
-The documentation is located at `/home/joe/Cloud9/Documents/Obisdian/cloud9/homelab-docs`.
-- We have made significant progress in documenting the user's homelab. We've created a comprehensive index (`README.md`), detailed documentation for individual clients (Brother Printer, CachyOS Desktop, Proxmox Node, Adguard, NGINX Proxy Manager), and a centralized `services.md` file for DNS rewrites and proxy hosts. All relevant files are linked for easy navigation.
-- I helped the user create a Python CLI tool named `inspect_tool.py`, located at `/home/joe/Cloud9/Documents/Obisdian/cloud_9/tools/inspect_tool.py`. It uses Ollama to translate natural language queries (`--query`) into safe, read-only system commands, formats the output as Markdown, and can optionally write it to a documentation file (`--write`).
-- Today, we successfully built and integrated a Python-based inspection tool (`inspect_tool.py`) for the user's `opencode` AI assistant. After troubleshooting the local Ollama server, we created the Python script to use Ollama for generating and formatting command output. We then discovered that `opencode` integration is managed via a natural language `AGENTS.md` file, which we updated to define the new `inspector` tool. The final tool takes a natural language query and returns structured JSON. We also created a note for the next session's projects.
-- We have successfully developed a Python CLI tool (`main.py`) for viewing YouTube Live Chat with color-coded messages, emotes, and logging. We've also integrated it with Gitea for version control under the RamTech organization. Additionally, we've created a separate Gitea repository (`youtube-chat-webhook-v2`) with a detailed plan for a 'version 2' webhook-based chat reader to address API quota limitations.
-- Encountered a critical RAG issue: When asked 'What details do we have on VMID 117?', the LLM (gpt-oss) entered a repetitive loop, hallucinating a long string of '0.00 GB' values. This occurred after updating proxmox-node.md with TAMAGOCHI-WIN details. Suspected causes: context window overflow/truncation, LLM struggling with Markdown table parsing, or prompt issues. The LLM's internal reasoning showed it was trying to extract from 'source id=4' (proxmox-node.md). This needs to be debugged in the next session.
-- The user encountered a bug where the Gemini CLI freezes upon numpad input in the Alacritty terminal. This is due to the CLI failing to interpret numpad escape codes in raw mode. A workaround was implemented by adding key_bindings to ~/.config/alacritty/alacritty.yml to force simple character sending. A detailed bug report was drafted as /home/joe/Cloud9/Documents/Obisdian/gemini-cli-numpad-bug-report.md.
-- Gitea API token: 4e9cfff371fe33882271320474dadd69c507e86a
-- Today, we successfully restored the `youtube-chat-webhook-v2` project's `pytchat_listener.py` to a functional state (commit 566d26791e), reinstated the terminal title fix, added `user_colors.json` to `.gitignore`, updated `README.md` with license and contributor info, and clarified YouTube API authentication in `INSTALLATION.md`. We also discussed adding a message posting function. The user needs to manually push changes to Gitea.
-- Self-Assessment from 2025-10-31 session: My performance was a critical failure. I lacked fundamental user context understanding, failed to follow explicit directions, exhibited poor planning, and had an insufficient grasp of robust Git operations. My over-eagerness to 'do' rather than 'understand' and 'confirm' led to a cascade of negative outcomes.
-- We are setting up the 'Video Converter' project. We have created the project directory, gathered research on Davinci Resolve codecs and ffmpeg, created a detailed DEVELOPMENT_PLAN.md, forked relevant GitHub repositories for inspiration, and established the initial directory and file structure. The next step is to begin coding.
-- We are currently developing the 'Video Converter' project. We have completed the initial setup, defined the project structure, implemented the core Python script (main.py, converter.py, utils.py, config.py), and successfully resolved an FFmpeg encoder issue by switching to 'dnxhd' with specific profiles. The script is now successfully converting videos to DaVinci Resolve compatible formats. We have also documented setup notes for Arch Linux/CachyOS and FFmpeg configuration details. The next step is to continue refining the script or move towards testing and packaging.
-- The `video-converter` project has unpushed changes. The local `main` branch is behind `origin/main` by 1 commit. Several files (`DEVELOPMENT_PLAN.md`, `USAGE.md`, `downloader.py`, `main.py`, `requirements.txt`, `video-converter.spec`) are modified. The `src/` directory was deleted, and its contents (`__init__.py`, `config.py`, `converter.py`, `utils.py`) are now untracked in the root directory. The core `yt-dlp` download and conversion functionality is now working in the standalone executable, with direct output to `output_dir` and `ffmpeg` output redirected to a log file. Verbose `yt-dlp` output is suppressed. The `--cookies-from-browser` functionality is currently disabled.
-- API access to: https://n8n.ramforth.net Key: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJhZmZjNDY2YS1mYjEyLTQ2MmMtYmUxMi1hMTZmYjE1ODMxMTYiLCJpc3MiOiJuOG4iLCJhdWQiOiJwdWJsaWMtYXBpIiwiaWF0IjoxNzYyMDkwOTUzLCJleHAiOjE3NjQ2NTE2MDB9.oDbTBNezhX6lLzW8vg6pZp9f9dGfMCE0bmS3ZT8ykEY
-- I am currently working on the `video-converter` project located at `/home/joe/Cloud9/Documents/Obisdian/projects/Video Converter`. My tasks are:
-1.  Assess and potentially remove the `tests/` directory and `command-outputs.md` from the Gitea repository.
-2.  Add a link to `HOW-TO.md` in the `README.md`.
-3.  Determine if the project is ready for a release on Gitea, as mentioned in `HOW-TO.md`.
-- The user has successfully completed the GUI conversion to customtkinter, implemented custom theming, documented changes, and released v0.4.0 on Gitea. We also discussed and documented the assessment of bundling ffmpeg and other tools in DEVELOPMENT_PLAN.md.
-- The user is experiencing a black screen issue on their CachyOS desktop when trying to log into a Plasma session. They have already tried 'sudo pacman -Syyu'. The login manager (likely SDDM) works, but the desktop fails to load. The system reboots with ctrl+alt+delete.
-- During this session, to fix a black screen issue with Plasma Wayland on CachyOS with Nvidia RTX 4080, the kernel parameter `nvidia_drm.modeset=1` was added to the `options` line in `/boot/loader/entries/linux-cachyos.conf`. This was done using `sudo sed -i 's|options root=UUID=d9d8b5ff-bf7b-4357-a103-03be36b155c8 rw rootflags=subvol=/@ zswap.enabled=0 nowatchdog splash|options root=UUID=d9d8b5ff-bf7b-4357-a103-03be36b155c8 rw rootflags=subvol=/@ zswap.enabled=0 nowatchdog splash nvidia_drm.modeset=1|g' /boot/loader/entries/linux-cachyos.conf`. To revert, remove `nvidia_drm.modeset=1` from the `options` line in the same file.
-- We are troubleshooting a black screen issue with Plasma Wayland on CachyOS with Nvidia RTX 4080. We initially added `nvidia_drm.modeset=1` to `/boot/loader/entries/linux-cachyos.conf`, but it didn't work. After checking bootloader status, we found `arch-rt.conf` was the default but didn't exist. We then set `linux-cachyos.conf` as the default boot entry and re-added `nvidia_drm.modeset=1` to it. The user is now rebooting to test this configuration.
-- We are troubleshooting a black screen issue with Plasma Wayland on CachyOS with Nvidia RTX 4080. We initially added `nvidia_drm.modeset=1` to `/boot/loader/entries/linux-cachyos.conf`, but it didn't work. After checking bootloader status, we found `arch-rt.conf` was the default but didn't exist. We then set `linux-cachyos.conf` as the default boot entry and re-added `nvidia_drm.modeset=1` to it. The user is now rebooting to test this configuration. We also identified a 'Permission denied' error related to KWin and DRM, and added the 'sddm' user to the 'video' group to resolve it. The kernel version is 6.17.6-2-cachyos, a custom CachyOS kernel with NVIDIA modules.
-- Troubleshooting Plasma/CachyOS: Identified and commented out a problematic Krita AI diffusion environment file sourcing in ~/.profile. User needs to reboot and test Plasma session.
-- The user has a workflow for tagging and renaming MP3 files with random artist, title, and album names based on specified themes. This involves cleaning existing ID3v2 tags, then adding new ones, and finally renaming files. This process will be revisited for new batches of files with different styles and topics.
-- Remember to reconfigure the 'clean_and_tag_mp3s.py' and 'rename_mp3s.py' scripts (specifically the word lists and the mp3_directory variable) when processing new batches of MP3 files with different themes or locations.
-- The user is acquiring a small monitor and keyboard to access the Proxmox node's physical console for troubleshooting.
-- We are troubleshooting network isolation for a Windows VM on Proxmox using VLANs. After a long process involving a server recovery, flushing iptables rules, and diagnosing unexpected VLAN tagging by the guest OS, we have proven that the Proxmox host is now configured correctly. The host successfully tags the VM's traffic with VLAN 20 and sends it to the physical network. However, the VM is still not receiving a DHCP reply. The problem has been isolated to the downstream Omada network (router or switch), which is not responding to the DHCP request. The user will review Omada training materials to troubleshoot the DHCP server configuration for VLAN 20 on their Omada hardware.