v0.9.1

Added

• Prometheus connector: optional prometheus.org_id sends the
  X-Scope-OrgID tenant header on every query, enabling multi-tenant
  Grafana Mimir and Cortex endpoints (parity with the Loki connector's
  org_id). Omitted = behavior unchanged for vanilla Prometheus. (#42)

---

Full Changelog: v0.9.0...v0.9.1

v0.9.0

Added

• OpenAI-compatible LLM provider: point triage at a self-hosted endpoint
  (SGLang, vLLM, Ollama, LM Studio) with llm.provider: openai-compatible
  and llm.base_url — no proxy required, and alert data never leaves your
  network. Includes enforced-JSON output by default (llm.response_format),
  defensive handling for hybrid-reasoning models (reasoning_content
  ignored, leading <think> blocks stripped, thinking disabled per request
  unless llm.thinking: true), Bearer auth only when a key is configured,
  and retries on transient local-runtime errors. The memory classifier
  follows the same endpoint using llm.model. New for both providers:
  llm.timeout_seconds (default 120 — the previous fixed value). See the
  "OpenAI-compatible endpoint" integration guide.

---

Full Changelog: v0.8.3...v0.9.0

v0.8.3

Added

• Triage prompt caching: when verification is enabled, the draft call marks
  the shared prefix (system prompt + evidence pack) as an Anthropic
  prompt-cache breakpoint and the re-judge call reads it seconds later at
  ~0.10× input price — roughly a 40% input-cost cut on a typical verified
  incident with the default model. llm.response audit rows now carry
  cache_creation_input_tokens / cache_read_input_tokens, and a warning is
  logged when the re-judge call read no cached prefix (model floor not met, or
  prefix drift). With verification disabled, requests are byte-identical to
  before and nothing is cached.

Fixed

• Triage verification no longer lowers a finding's confidence over empty
  contrast-query results unless the query reused metric names and label keys
  confirmed present in the evidence; the verification-plan prompt now steers
  the model toward single-metric queries and away from cross-metric label
  joins that return empty regardless of ground truth.
• Evidence-pack metric snapshots: comparator series (those sharing only the
  incident's node/instance) are now ranked largest-value-first within each
  metric family and capped at 3 per family, so the LLM sees a true top-N of
  neighboring producers instead of an alphabetical slice; the incident's own
  member series are never capped.

---

Full Changelog: v0.8.2...v0.8.3

v0.8.2

Fixed

• Storm-sized incidents no longer fail triage with llm: response truncated at max_tokens:
  prompts now itemize at most the 20 most significant alerts (omitted members are recorded
  with the correlated role deterministically) and cap finding prose, so the response's
  output-token size stays flat at any incident size. llm.max_tokens is unchanged.

---

Full Changelog: v0.8.1...v0.8.2

v0.8.1

Fixed

• Model-proposed verification queries were silently dropped when the model
  emitted the verification key as a bare query list instead of the
  {"queries": [...]} envelope — the plan parser rejected the whole block and
  every such round fell back to floor-only checks (observed on
  claude-haiku-4-5 immediately after 0.8.0 went live). The prompt now spells
  out the exact envelope shape and the parser accepts both shapes, so targeted
  disprove-queries — including the mandatory ones behind the scope-inflation
  guard — actually run.

---

Full Changelog: v0.8.0...v0.8.1

v0.8.0

Added

• Verification round: triage now falsifies its own draft verdict before persisting —
  a deterministic floor (peer-scope up ratio + cross-incident scan) plus up to 4
  model-chosen read-only checks run on every judged incident, and a second LLM pass
  revises the verdict against the results. Degraded rounds mark the finding
  "unverified" and can never raise confidence. Config: triage.verification
  (default on; enabled: false restores single-call triage).

---

Full Changelog: v0.7.5...v0.8.0

v0.7.5

Changed

• Slack recurrence updates no longer post to the channel. The recurrence
  resurfacing messages introduced in 0.7.4 (real-world-change "why" and
  milestone nudges) used Slack's "also send to channel" on their thread
  replies, so every resurface also landed as a new channel message — too
  noisy in practice. These messages now post as plain thread replies only;
  the in-place card count edit is unchanged. notify.slack.recurrence_mode
  keeps its meaning (change-gated gates the thread replies, off silences
  them).

---

Full Changelog: v0.7.4...v0.7.5

v0.7.4

Added

• Change-gated recurrence visibility in Slack: a recurring incident resurfaces in
  the channel only when a re-fire is a real-world change (severity rise, a new
  symptom, or accelerating cadence) or crosses a milestone (×5/×10/×25/×50/×100,
  then every ×100), each stating why it resurfaced. Plain re-fires stay silent —
  the card's occurrence count edits in place. An escalation now edits the
  incident's existing card instead of posting a new one, so the whole recurrence
  reads as one thread. New notify.slack.recurrence_mode: change-gated | off.

---

Full Changelog: v0.7.3...v0.7.4

v0.7.3

Fixed

• Metric enrichment no longer self-inflicts "Prometheus unreachable" during
  alert storms. A broad {instance="…"} selector pulled every series for a
  node, and all of an incident's scopes shared one query deadline, so under storm
  load the later queries timed out — falsely reporting a healthy backend as
  unreachable and capping the finding's confidence. Each enrichment query is now
  bounded server-side (prometheus.max_series, default 1000), the per-instance
  queries are capped, and the fetch deadline is split per query so one slow query
  can no longer starve the rest. A backend that is merely slow is reported as
  degraded (metrics slow) rather than unreachable, and no longer lowers the
  finding's confidence.

---

Full Changelog: v0.7.2...v0.7.3

v0.7.2

Fixed

• Large incidents no longer fail triage with a truncated reply. The triage
  output ceiling was hardwired to 1024 tokens; a large correlated incident (whose
  finding JSON carries one entry per member alert) could exhaust it mid-reply,
  failing the whole analysis with a misleading not valid JSON error and leaving
  the prior finding standing on every re-judgment. The ceiling is now a
  configurable llm.max_tokens (default 4096), and a reply cut off at the ceiling
  is reported as an actionable response truncated at max_tokens=…; raise llm.max_tokens instead of a JSON parse error.

---

Full Changelog: v0.7.1...v0.7.2