detectkit 0.55.2__tar.gz → 0.56.1__tar.gz

{detectkit-0.55.2/detectkit.egg-info → detectkit-0.56.1}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: detectkit
-Version: 0.55.2
+Version: 0.56.1
 Summary: Metric monitoring with automatic anomaly detection
 Author: detectkit team
 License: MIT

{detectkit-0.55.2 → detectkit-0.56.1}/detectkit/__init__.py

@@ -4,7 +4,7 @@ detectk - Anomaly Detection for Time-Series Metrics
 A Python library for data analysts and engineers to monitor metrics with automatic anomaly detection.
 """
 
-__version__ = "0.55.2"
+__version__ = "0.56.1"
 
 from detectkit.core.interval import Interval
 from detectkit.core.models import ColumnDefinition, TableModel

{detectkit-0.55.2 → detectkit-0.56.1}/detectkit/cli/assets/claude/CLAUDE.section.md

@@ -84,7 +84,8 @@ version — **read the relevant one on demand** instead of guessing:
   database key, not the filename. Keep filename and `name` in sync.
 - **Changing a detector parameter changes the detector's identity** and
   recomputes its detections from scratch; the old rows are orphaned. After
-  retuning a live metric, run `dtk clean --select <metric>` to prune them.
+  retuning a live metric, run `dtk clean --select <metric>` to prune them (or,
+  from `dtk ui`, open the metric and click **Clean stale** in its detail view).
 - **`alert_cooldown` defaults to `null`** = a persisting anomaly re-alerts on
   *every* `dtk run`. Always set a cooldown for production metrics.
 - The pipeline is **idempotent**: it resumes from the last saved timestamp.

{detectkit-0.55.2 → detectkit-0.56.1}/detectkit/cli/assets/claude/rules/cli.md

@@ -12,7 +12,7 @@ Run all commands from a project directory (the one containing
 | `dtk run --select <sel>` | Run the load → detect → alert pipeline |
 | `dtk autotune --select <sel>` | Auto-configure a metric's detector (see `autotune.md`) |
 | `dtk tune --select <sel>` | Interactively tune a detector on real data, write it back in place |
-| `dtk ui` | Project-wide live overview + browser pipeline control panel + create/edit/delete metric YAMLs |
+| `dtk ui` | Project-wide live overview + browser pipeline control panel + create/edit/delete metric YAMLs + per-metric Clean stale |
 | `dtk test-alert <metric>` | Send a mock alert to the metric's channels |
 | `dtk unlock --select <sel>` | Clear a stuck pipeline lock |
 | `dtk clean --select <sel>` | Prune internal data that no longer matches the config |
@@ -211,13 +211,21 @@ dtk ui [-s/--select "*"] [--window 24h|7d|30d|90d|all] [--profile NAME] [--no-op
 - `--no-open` — print the URL instead of opening a browser tab.
 
 Clicking a metric's **Open** shows the existing self-contained HTML report
-(the same one `--report` writes) in an overlay. A **pipeline panel** drives
+(the same one `--report` writes) in an overlay, whose header also has a
+**Clean stale** button next to **Tune**: it previews a `dtk clean --select
+<metric>` dry-run (superseded detector generations + row counts, stale
+alert-state ids), and — if anything is stale — an amber confirm strip offers
+**Delete stale data**, which spawns the real `dtk clean --select <metric>
+--execute` as a job (`clean` kind) sharing the run/autotune/unlock gate below;
+on success the report reloads and the overview's stale chip clears. This is
+the drift-mode `dtk clean --select` from inside the UI; `--orphaned-metrics`
+(renamed/deleted metrics) stays CLI-only. A **pipeline panel** drives
 the real CLI as subprocesses — `dtk run` (select/steps/from/to/force/
 full-refresh), `dtk autotune`, `dtk unlock` — streaming their terminal
-output live; **only one of these three runs at a time** (they'd contend for
-the same pipeline lock anyway). **Tune** launches `dtk tune --select
+output live; **only one `run`/`autotune`/`unlock`/`clean` job runs at a
+time** (they'd contend for the same pipeline lock anyway). **Tune** launches `dtk tune --select
 <metric>` for a metric and opens its cockpit in a new tab — unlike
-run/autotune/unlock, **multiple tune jobs run concurrently**, since each is
+run/autotune/unlock/clean, **multiple tune jobs run concurrently**, since each is
 its own isolated, lock-free session. The `dtk ui` server itself takes **no
 pipeline lock** and never mutates anything — every spawned command behaves
 exactly as if typed into a terminal.
@@ -290,7 +298,9 @@ the next normal run recovers on its own.)
 
 Editing metrics over time leaves stale rows in the internal tables. `dtk clean`
 removes that drift. **Both modes dry-run by default** — pass `--execute` to
-actually delete.
+actually delete. Drift mode is also one click away, per metric, from `dtk
+ui`'s detail overlay (**Clean stale**, next to Tune); `--orphaned-metrics`
+stays CLI-only.
 
 - **Drift mode** — `dtk clean --select <sel>`: for each still-existing metric,
   deletes `_dtk_detections` rows for `detector_id`s the config no longer

{detectkit-0.55.2 → detectkit-0.56.1}/detectkit/cli/assets/claude/rules/metrics.md

@@ -149,7 +149,8 @@ columns and bakes the best grouping into the tuned config (see `autotune.md`).
   `detector_id` and recomputes that detector's detections; the old rows are
   orphaned in `_dtk_detections`. **Changing/removing an alerting block** orphans
   its `_dtk_alert_states` row. Prune both with `dtk clean --select <m>`
-  (preview, then `--execute`).
+  (preview, then `--execute`) — or, from `dtk ui`, the metric's detail view's
+  **Clean stale** button.
 - **Renaming/deleting a metric** orphans all its rows under the old name; purge
   with `dtk clean --orphaned-metrics`.
 - Datapoints are keyed only by `(metric, timestamp)` — a parameter edit never

{detectkit-0.55.2 → detectkit-0.56.1}/detectkit/cli/assets/claude/skills/dtk-tune/SKILL.md

@@ -33,8 +33,10 @@ for me, I won't look").
 
 Your job is to **set up the sandbox, open it, and guide the user through it** —
 they drive the chart; you prepare it, explain each control in plain language, and
-handle the follow-up (`dtk run` / `dtk clean`). This skill is the procedure; for
-field detail read the matching file under `.claude/rules/detectkit/` (`cli.md`
+handle the follow-up (`dtk run` / `dtk clean`, or point at `dtk ui`'s per-metric
+**Clean stale** button as the interactive equivalent). This skill is the
+procedure; for field detail read the matching file under
+`.claude/rules/detectkit/` (`cli.md`
 has the full `dtk tune` reference, plus `detectors.md`, `autotune.md`,
 `alerting.md`).
 
@@ -194,6 +196,10 @@ dtk clean --select <name> --execute        # prune the orphaned old detector row
 dtk test-alert <name>                      # if alerting is configured
 ```
 
+(`dtk ui`'s metric detail overlay has the same cleanup as a **Clean stale**
+button, if the user is already there and would rather not switch to a
+terminal.)
+
 ## When to hand off instead
 
 - **Fully automatic, no browser** (CI, "just pick one for me") → the
@@ -211,4 +217,5 @@ dtk test-alert <name>                      # if alerting is configured
 - [ ] You explained the relevant mode(s) — including that **Autotune is built in**
       and runs over the window shown — and which controls stay visible everywhere.
 - [ ] After **Apply**, you ran `dtk run` to recompute and `dtk clean --execute`
-      to prune the orphaned old detector rows (and `dtk test-alert` if alerting).
+      (or `dtk ui`'s **Clean stale** button) to prune the orphaned old detector
+      rows (and `dtk test-alert` if alerting).

{detectkit-0.55.2 → detectkit-0.56.1}/detectkit/cli/commands/clean.py

@@ -264,17 +264,10 @@ def _valid_detector_ids(config: MetricConfig) -> set[str]:
     injection) so the computed ``detector_id`` matches what the pipeline
     writes — anything in the DB not in this set is stale.
     """
-    ids: set[str] = set()
-    for detector_config in config.detectors or []:
-        params = detector_config.get_algorithm_params()
-        seasonality_components = detector_config.get_seasonality_components()
-        if seasonality_components is not None:
-            params["seasonality_components"] = seasonality_components
-        detector = DetectorFactory.create_from_config(
-            {"type": detector_config.type, "params": params}
-        )
-        ids.add(detector.get_detector_id())
-    return ids
+    return {
+        DetectorFactory.detector_id_for_config(detector_config)
+        for detector_config in config.detectors or []
+    }
 
 
 def _valid_alert_config_ids(config: MetricConfig) -> set[str]:

{detectkit-0.55.2 → detectkit-0.56.1}/detectkit/detectors/factory.py

@@ -2,6 +2,8 @@
 Detector factory for creating detector instances from configuration.
 """
 
+from typing import TYPE_CHECKING
+
 from detectkit.detectors.base import BaseDetector
 from detectkit.detectors.statistical.autoreg import AutoregDetector
 from detectkit.detectors.statistical.iqr import IQRDetector
@@ -9,6 +11,9 @@ from detectkit.detectors.statistical.mad import MADDetector
 from detectkit.detectors.statistical.manual_bounds import ManualBoundsDetector
 from detectkit.detectors.statistical.zscore import ZScoreDetector
 
+if TYPE_CHECKING:
+    from detectkit.config.metric_config import DetectorConfig
+
 
 class DetectorFactory:
     """
@@ -119,6 +124,24 @@ class DetectorFactory:
             detectors.append(detector)
         return detectors
 
+    @classmethod
+    def detector_id_for_config(cls, detector_config: "DetectorConfig") -> str:
+        """The ``detector_id`` the detect step would run this configured detector under.
+
+        Mirrors the DETECT step's derivation exactly (``get_algorithm_params``
+        + the same seasonality injection → :meth:`create_from_config` →
+        ``get_detector_id``), so callers that only need the id — the overview's
+        current-config filter, ``dtk clean``'s drift diff, the UI's stale-data
+        preview — all agree with what the pipeline writes. Raises (like
+        :meth:`create`) on a config the factory rejects.
+        """
+        params = detector_config.get_algorithm_params()
+        seasonality_components = detector_config.get_seasonality_components()
+        if seasonality_components is not None:
+            params["seasonality_components"] = seasonality_components
+        detector = cls.create_from_config({"type": detector_config.type, "params": params})
+        return detector.get_detector_id()
+
     @classmethod
     def list_available_types(cls) -> list[str]:
         """