diff options
Diffstat (limited to 'GEMINI.md')
| -rw-r--r-- | GEMINI.md | 17 |
1 files changed, 17 insertions, 0 deletions
diff --git a/GEMINI.md b/GEMINI.md new file mode 100644 index 0000000..3679393 --- /dev/null +++ b/GEMINI.md @@ -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 '[email protected]'. +- My git workflow is: 1. `git status`. 2. `git add <files>`. 3. `GIT_AUTHOR_NAME='Castor Regex' GIT_AUTHOR_EMAIL='[email protected]' 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. |