diff options
| author | Peter Stone <thepeterstone@gmail.com> | 2026-03-22 23:45:19 +0000 |
|---|---|---|
| committer | Peter Stone <thepeterstone@gmail.com> | 2026-03-22 23:45:19 +0000 |
| commit | 8abc63efdbc0bb96cd6c9aa99d6e9166e0bcabae (patch) | |
| tree | f4d6a082eed9b10bc67436a3ca5188e0182961eb /.gemini/skills/bug-manager/references | |
| parent | 11b905fd437d651b2e39745aa82a5dd36f70331e (diff) | |
chore: unify and centralize agent configuration in .agent/
Diffstat (limited to '.gemini/skills/bug-manager/references')
| -rw-r--r-- | .gemini/skills/bug-manager/references/bug-triage.md | 36 |
1 files changed, 36 insertions, 0 deletions
diff --git a/.gemini/skills/bug-manager/references/bug-triage.md b/.gemini/skills/bug-manager/references/bug-triage.md new file mode 100644 index 0000000..45fe6cf --- /dev/null +++ b/.gemini/skills/bug-manager/references/bug-triage.md @@ -0,0 +1,36 @@ +# Bug Triage & Resolution Guide + +This reference provides a structured approach to managing production bugs using the `doot` project's custom scripts. + +## 1. Listing Bugs +Use `./scripts/bugs` to list all currently open bugs from the production database. +Bugs are stored in the `bugs` table with `id`, `description`, and `created_at`. + +## 2. Investigating Logs +When a bug is reported, always check the production logs first. +Use `./scripts/logs` with various flags: +- `scripts/logs -n 200`: View the last 200 lines. +- `scripts/logs --since "1 hour ago"`: View recent logs. +- `scripts/logs --grep "error"`: Search for specific error patterns. +- `scripts/logs -f`: Follow logs in real-time (useful for reproduction). + +### Common Error Patterns +- **Database Locked:** SQLite `database is locked` errors usually indicate concurrent writes or long-running transactions. +- **Unauthorized:** Check for `401` or `403` status codes in API clients (Todoist, Trello, etc.). +- **Template Errors:** Look for `template: ...: executing ...: nil pointer evaluating ...` which indicates missing data in the renderer. + +## 3. Reproduction +Before applying a fix, attempt to reproduce the bug locally. +1. Use `go test ./...` to ensure the current state is stable. +2. Create a new test case in the relevant `*_test.go` file that specifically triggers the reported bug. +3. Confirm the test fails. + +## 4. Resolution +Once a fix is implemented and verified locally: +1. Deploy the fix using `./scripts/deploy`. +2. Verify the fix in production if possible (e.g., by checking logs). +3. Use `./scripts/resolve-bug <id>` to mark the bug as resolved in the production database. + +## 5. Verification +After resolving, run `./scripts/bugs` again to ensure it no longer appears in the list. +Update `SESSION_STATE.md` to reflect the completed bug fix. |