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) <noreply@anthropic.com>

.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 "<skill/command>" "<brief error>" [--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 "<skill/context>" "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 "<context e.g. bash/env>" "what wasted tokens + the fix" --friction [--context "ref=<memory-or-rule>"]`. **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

.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 <uuid>`, `/recover latest`, or `/recover --list`. See `.claude/RECOVERY.md` |

.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 <repo> <num> --comment "Fixed in <sha>. <what changed>"`
+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