ci: pin GoReleaser to the triggering tag, fix tag-collision regression

When v0.3.1 was tagged on the same commit as v0.3.1-rc2, the release
workflow built and tried to publish rc2 artifacts instead of v0.3.1,
failing with 'already_exists' on every asset upload.

Root cause: goreleaser-action@v6 + 'version: latest' (locked to v2.x)
falls back to 'git describe --tags' for the current tag, which picked
v0.3.1-rc2 over v0.3.1 when both refs pointed at HEAD. Explicitly
setting GORELEASER_CURRENT_TAG = github.ref_name forces the workflow
to use the tag that triggered it, regardless of other refs at the same
commit.

.github/workflows/release.yml

@@ -61,3 +61,8 @@ jobs:
           args: release --clean
         env:
           GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+          # Force GoReleaser to use the triggering tag rather than fall
+          # back to `git describe` — which can resolve to an older tag
+          # (e.g., a vX.Y.Z-rc tag) when multiple tags point at the same
+          # commit. Surfaced as the v0.3.1 release failure on 2026-05-24.
+          GORELEASER_CURRENT_TAG: ${{ github.ref_name }}

.goreleaser.yml

@@ -37,9 +37,12 @@ changelog:
   sort: asc
   filters:
     exclude:
-      - "^docs:"
-      - "^test:"
-      - "^chore:"
+      # Match both bare and scoped conventional commits, e.g. both
+      # "docs:" and "docs(readme):" should be excluded.
+      - "^docs[:(]"
+      - "^test[:(]"
+      - "^chore[:(]"
+      - "^style[:(]"
 
 # Multi-arch Docker images published to GitHub Container Registry.
 # Build host needs Docker buildx and a `docker login ghcr.io` for the
@@ -98,3 +101,6 @@ release:
   github:
     owner: VikingOwl91
     name: gnoma
+  # Auto-detect prereleases from semver: tags with -rc, -beta, -alpha,
+  # -pre, etc. suffix get marked as prerelease on GitHub.
+  prerelease: auto

TODO.md

@@ -4,6 +4,37 @@ Active work, newest first.
 
 ## In flight
 
+- **Bandit selector — design decisions deferred.** The current
+  selector (`internal/router/selector.go:scoreArm`) is greedy
+  quality-weighted: per-(arm × task-type) EMA scores blended 70/30
+  with heuristic defaults, divided by CostWeight-adjusted cost. It
+  is **not** a true multi-armed bandit — no UCB-style exploration
+  bonus, no Thompson sampling. Tracked as a design question rather
+  than a must-implement item because of two open dependencies:
+
+  1. **Whether to keep numeric EMA at all.** The 2026-05-07 roadmap
+     (Phase 4) puts re-evaluating bandit learning on hold until the
+     SLM-driven dispatcher is in production. Three options on the
+     table: keep bandit as feedback for the SLM, retire EMA in
+     favour of qualitative outcome summaries fed to the SLM, or
+     split responsibilities (SLM = intent routing, bandit =
+     cost/quality within a tier). See
+     [`docs/superpowers/plans/2026-05-07-gnoma-roadmap.md`](docs/superpowers/plans/2026-05-07-gnoma-roadmap.md)
+     §Phase 4.
+
+  2. **User-tunable selector knobs.** Several constants are
+     hardcoded today: `qualityAlpha` (EMA smoothing, ~3-sample
+     memory), the 70/30 observed/heuristic blend,
+     `strengthScoreBonus` for tagged task types, and the
+     `DefaultThresholds.Minimum` quality floor. Surfacing these as
+     `[router.bandit]` config keys would let users tune for their
+     workloads (faster alpha for shifting model performance, longer
+     memory for stable fleets) without waiting for the strategic
+     decision in #1.
+
+  Surfaced from the r/coolgithubprojects v0.3.1 launch thread
+  (2026-05-24, `u/Ha_Deal_5079`).
+
 - **Security boundary — egress controls + session audit log.** The
   current `Firewall` is a content boundary only (scans messages and
   tool results for secrets via regex + Shannon entropy, redacts or