jcarr
/
regex
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

GEMINI workflow rules

This commit is contained in:
Jeff Carr 2025-08-30 15:48:22 -05:00
parent bbb12d79e2
commit b750fb9252
1 changed files with 17 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

17
GEMINI.md Normal file
View File

@ -0,0 +1,17 @@
## 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.