18 lines
2.6 KiB
Markdown
18 lines
2.6 KiB
Markdown
## 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.
|