regex/GEMINI.md

Gemini Added Memories

• The user and I were analyzing a RISC-V Go panic. The user provided a panic log showing a 'SIGQUIT: quit' signal. I concluded that the panic was not a bug, but rather the result of a test timeout in 'tsan_test.go', which was running a long, resource-intensive build of the standard library with the thread sanitizer enabled. The test harness sent SIGQUIT to terminate the build process and get a stack dump.
• Assume my base directory is /home/jcarr/go/src
• The gemini-cli application is located in github.com/google-gemini/gemini-cli and is a Node.js project.
• To test the build of gemini-cli, always run exactly: cd github.com/google-gemini/gemini-cli && make build
• The "regex" application is located in go.wit.com/apps/regex and is written in Go
• To build the 'regex' application, I must first change into the go.wit.com/apps/regex directory and then run the make regex command.
• The "Google Gemini AI GO API" is located in google.golang.org/genai.
• I must not search for anything. Instead, I must stop and ask the user for the location of files or information.
• When committing to git, I will use the author name 'Castor Regex' and the email 'regex@wit.com'.
• My git workflow is: 1. git status. 2. git add <files>. 3. GIT_AUTHOR_NAME='Castor Regex' GIT_AUTHOR_EMAIL='regex@wit.com' git commit -m '...'. I will not run git push.
• When asked to commit code with git, I should follow the git workflow
• My standard workflow: Upon completing a task and verifying the solution, I will automatically commit the changes. Then follow my git workflow
• My standard git workflow: Upon completing a task and verifying the solution, I will automatically commit the changes following the standard workflow.
• New operational rule: If a fix or modification I make results in an error, I will NOT revert the changes with git checkout. I will leave the modified files in their current state for the user to inspect and debug.
• CRITICAL WORKFLOW RULE: After making any code changes and before committing, I MUST always attempt to build the project (e.g., run 'make' or the appropriate build command). I am only allowed to commit changes that compile successfully. If a build fails, I must fix the compilation error before proceeding with the commit. I will not commit broken code.
• WORKFLOW UPDATE: If a build fails and the user subsequently tells me to commit, I will assume the user has fixed the compilation errors. My next step is to re-run the build command to verify. If this verification build succeeds, I will then proceed with committing my original changes. If it still fails, I will report the new error.