From 7b1093cad786f4a80c6625b122ee7beb0ca226a7 Mon Sep 17 00:00:00 2001 From: Howard Enos Date: Sun, 19 Jul 2026 09:13:14 -0700 Subject: [PATCH] bug-tracker: integrate into session workflows Wire the bug-tracker skill into the harness operating rules so bugs discovered during sessions get tracked through to resolution: - CLAUDE.md: add bug-tracker to skill-first routing list, add errorlog-to-tracker bridge rule, add filing confirmation gate to Definition of Done - SKILL_ROUTING.md: add bug-tracker to doing-skills table, add "Bug tracking (auto-file on discovery)" subsection with filing criteria and fix-update-close workflow - CLAUDE_EXTENDED.md: add bug-tracker to commands table Validated end-to-end: create/show/comment/label/priority/assign/ close/reopen/re-close all passed (test issue claudetools #87). Co-Authored-By: Claude Opus 4.6 (1M context) --- .claude/CLAUDE.md | 12 ++++++++++-- .claude/CLAUDE_EXTENDED.md | 1 + .claude/SKILL_ROUTING.md | 15 +++++++++++++++ 3 files changed, 26 insertions(+), 2 deletions(-) diff --git a/.claude/CLAUDE.md b/.claude/CLAUDE.md index 91ea0908..a8360509 100644 --- a/.claude/CLAUDE.md +++ b/.claude/CLAUDE.md @@ -46,7 +46,7 @@ production, data-loss. Detail: EXTENDED + `.claude/OLLAMA.md`. other covered domains: credentials → `vault`, RMM actions → `/rmm` (+ `rmm-search` to find a host), M365 → `remediation-tool`, asking a human a question/decision in Discord (get their reply back in-session) → `ask-forum` (never hand-roll the Discord API — that footgun cost us - a broken background wait), etc. Knowing the API is NOT a reason to bypass the skill — + a broken background wait), bugs/features/projects → `bug-tracker`, etc. Knowing the API is NOT a reason to bypass the skill — the memory rules (e.g. [[feedback_syncro_billing]]) describe what the SKILL does, not a license to free-hand it. Reach for raw API ONLY when no skill fits or the skill genuinely cannot do it — and say so explicitly when you do. Mistakes here go to `errorlog.md` (`--correction`). @@ -56,7 +56,8 @@ production, data-loss. Detail: EXTENDED + `.claude/OLLAMA.md`. have to name skill A/B/C. Standing gates (run the check-skill BEFORE declaring done): code edits → `/code-review` + `/simplify` (+ `/security-review` if it touches auth/creds/security); anything outbound/client-facing → `impeccable` / `stop-slop`; Syncro/vendor work → its skill's own - preview+verify gate; wiki/memory writes → their lint (`wiki-lint`/`memory-dream`). **Calibrate to + preview+verify gate; bug reports → confirm title/priority with user before filing via `bug-tracker`; + wiki/memory writes → their lint (`wiki-lint`/`memory-dream`). **Calibrate to stakes** (a typo fix doesn't need a full review) and **use Ollama Tier-0** for the cheap classify/prose passes so this stays low-token. The full request→doing-skill→check-skill map is `.claude/SKILL_ROUTING.md` — read it on demand when a request maps to a skill or work nears done. @@ -74,6 +75,13 @@ production, data-loss. Detail: EXTENDED + `.claude/OLLAMA.md`. - **Hard-to-reverse or outward-facing actions:** confirm first (per-action, per-session). - **Error logging (mandatory, all skills):** when a task or skill hits a GENUINE functional error during execution (failed command, API/auth failure, unexpected API response, tool call), record it to `errorlog.md` (repo root) via the canonical helper — never hand-format: `bash .claude/scripts/log-skill-error.sh "" "" [--context "k=v ..."]`. It stamps UTC date + machine (from `identity.json`) and inserts in the standard `YYYY-MM-DD | MACHINE | skill | error` format (newest on top) for later skill **linting**, and soft-fails so it never breaks the caller. **Every skill MUST call it at its failure branches**; you (main loop) call it after any skill/command genuinely fails. Do NOT log expected/handled conditions (no search matches, no unread messages, a user declining a prompt) — only real failures worth spotting a pattern. Python skills shell out to the same helper. - **Log user corrections too (`--correction`):** when the user CORRECTS an improper assumption or wrong approach you took (e.g. "don't use INKY unless onboarded", "EXO already has Mail.Send", "I don't need an exact match"), log it: `bash .claude/scripts/log-skill-error.sh "" "assumed X; correct is Y" --correction`. These are the highest-value entries — they surface recurring bad assumptions so we can train them out of the system. If the correction is a durable preference, ALSO save it as a `feedback` memory (the two are complementary: memory fixes future behavior, errorlog tracks the pattern for linting). +- **Bug tracker (errorlog → tracker bridge):** when logging a GENUINE functional bug to + errorlog.md (not `--correction`/`--friction`), also evaluate whether it needs follow-up + tracking. If the bug is reproducible, affects a skill/tool/harness component, and won't be + fixed in this session → file it as a Gitea issue via the `bug-tracker` skill (confirm + title/priority with the user). The errorlog captures patterns for linting; the tracker + tracks resolution. When fixing a tracked bug, update/close the issue with a commit ref + comment — never close silently. See `SKILL_ROUTING.md` "Bug tracking" block. - **Log preventable friction too (`--friction`):** any time you waste tokens on a preventable, repeatable self-inflicted error — harness/env/tool misuse (Git-Bash `/tmp` path mismatch, shell env not persisting between Bash calls, passing huge args on the command line, PowerShell var case-collisions, etc.) — log it: `bash .claude/scripts/log-skill-error.sh "" "what wasted tokens + the fix" --friction [--context "ref="]`. **If it repeats something already in memory or CLAUDE.md, that's the highest-value entry** — it means a rule/memory isn't working; cite the ref. This log is the corpus we lint to build better CLAUDE.md rules and to clean stale/misleading memory. Goal: stop paying twice for the same mistake. - **Windows:** ensure `bash` resolves to Git-for-Windows MSYS bash, not the WSL stub; write `.claude/current-mode` with a relative/forward-slash path only (never a backslash Windows diff --git a/.claude/CLAUDE_EXTENDED.md b/.claude/CLAUDE_EXTENDED.md index cff8def5..238a7d05 100644 --- a/.claude/CLAUDE_EXTENDED.md +++ b/.claude/CLAUDE_EXTENDED.md @@ -295,6 +295,7 @@ Vault structure: `infrastructure/`, `clients/`, `services/`, `projects/`, `msp-t | `/remediation-tool` | M365 breach checks, tenant sweeps, gated remediation | | `/feature-request` | Howard submits a GuruRMM feature request — Claude classifies it and messages Mike | | `/shape-spec` | Pre-implementation spec for a GuruRMM feature — produces plan.md, shape.md, references.md, standards.md | +| `bug-tracker` | File, list, update, close bugs/features/projects in Gitea issue tracker. Auto-file when bugs surface during sessions | | `/rmm-audit` | Full end-to-end audit of GuruRMM: API coverage, UI gaps, Rust/TS quality, security, data integrity. Produces timestamped report + updates UI_GAPS.md | | `/forum-post` | Post a technical article to community.azcomputerguru.com — drafts from context, shows preview, inserts via paramiko SSH to Flarum DB | | `/recover` | Reconstruct a session log from a Claude Code transcript after a crash/close-before-save. `/recover `, `/recover latest`, or `/recover --list`. See `.claude/RECOVERY.md` | diff --git a/.claude/SKILL_ROUTING.md b/.claude/SKILL_ROUTING.md index 6a46be6f..8969175f 100644 --- a/.claude/SKILL_ROUTING.md +++ b/.claude/SKILL_ROUTING.md @@ -41,12 +41,27 @@ | Capture an RMM feature idea | `/feature-request`; GuruConnect feature → `gc-feature-request` | | Compile session logs/Syncro into wiki | `/wiki-compile` | | Create a new skill or slash command | `skill-creator` | +| File/list/update/close a bug, feature, or project issue | `bug-tracker` | | Independent 2nd opinion / adversarial verify | `grok` (xAI) or `agy` (Gemini) | | Image/video gen, live web/X search past cutoff | `grok` | | Deep multi-source researched report | `deep-research` | > Not listed? If no skill fits, do it directly — and say so. New recurring need → `skill-creator`. +### Bug tracking (auto-file on discovery) + +When a **genuine functional bug** surfaces during a session — a skill fails unexpectedly, +a command hits a reproducible error that needs follow-up, or the user reports something +broken — **file it as a Gitea issue** via `bug-tracker` (with user confirmation for +title/priority). This is in addition to `log-skill-error.sh` (the errorlog captures +patterns; the tracker tracks resolution). Do NOT file: client machine problems, vendor +API limitations, one-off env/friction issues already resolved, or transient errors. + +When **fixing** a tracked bug during a session, update the issue: +1. Add a progress comment if doing partial work +2. On fix: `py tracker.py close --comment "Fixed in . "` +3. Never close silently — the comment IS the documentation + ### Backups (wiki-first routing) A customer can back up through **any** of several backends, so a backup request is a