detectkit 0.54.0__tar.gz → 0.55.0__tar.gz

{detectkit-0.54.0/detectkit.egg-info → detectkit-0.55.0}/PKG-INFO

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

{detectkit-0.54.0 → detectkit-0.55.0}/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.54.0"
+__version__ = "0.55.0"
 
 from detectkit.core.interval import Interval
 from detectkit.core.models import ColumnDefinition, TableModel

{detectkit-0.54.0 → detectkit-0.55.0}/detectkit/cli/assets/claude/rules/cli.md

@@ -224,20 +224,39 @@ exactly as if typed into a terminal.
 
 ### Managing metrics from the UI
 
-The cockpit header has a **New metric** button — an editor overlay seeded
-with a starter YAML template, with an optional subfolder under `metrics/`;
-saving writes `metrics/[<folder>/]<name>.yml`. Every metric row also has an
-**Edit** action that opens its raw YAML in the same editor. **Save** validates
+The cockpit header has a **New metric** button, and every metric row an
+**Edit** action; both open an editor overlay with **two tabs sharing one
+draft**: **Builder** — a structured form over the whole config (basics,
+schedule/loading, seasonality, minimal detector rows with type + 1-2 key
+params — fine-tuning belongs in `dtk tune` —, alerting with a channel
+multi-select seeded from `profiles.yml` channel names, `ai_context`; SQL in
+a syntax-highlighted pane, `query_file` paths read-only; a **From OSI**
+sub-tab compiles a pasted OSI semantic-model metric through the same code
+path as `dtk osi import`) — and **YAML**, the raw text, kept for whole-config
+pastes. The last-edited tab wins, never silently: leaving an edited YAML tab
+validates server-side first and blocks the switch on error; leaving an
+edited Builder re-emits the YAML. A debounced live-validation chip re-checks
+the draft while typing. Keys the form doesn't model (`autotune:`, custom
+templates, unknown detector types/params, a multi-entry alerting list)
+round-trip verbatim, listed under "Preserved fields". Create writes
+`metrics/[<folder>/]<name>.yml`; after a create, a **next-steps strip**
+offers **Load & detect** (`dtk run --steps load,detect` for just that metric
+— no alert step, so an untuned config can't spam a channel) and then **Open
+tune** on the loaded series. **Save** validates
 server-side **before any write**: YAML syntax → full `MetricConfig` → a deep
 detector-params check (each factory-known detector is actually constructed) —
 an invalid config lands in the editor's error pane with nothing written. A
 successful save **archives the previous file verbatim** to
 `metrics/.history/<metric>/` (the same archive `dtk tune`'s Apply writes,
-excluded from metric discovery) and only then overwrites in place, so the
-text typed is what lands on disk, comments intact (normalized only to end
-with a newline). A save is refused when the file changed on disk after the
-editor was opened (a `dtk tune` Apply or another session saved first) —
-reopen the metric rather than overwrite it. Renaming via `name:`
+excluded from metric discovery) and only then overwrites in place. A
+YAML-tab save writes the text typed, comments intact (normalized only to end
+with a newline); a Builder save **re-emits the YAML deterministically,
+dropping hand-written comments** (the archive keeps the previous file; edit
+comment-heavy files from the YAML tab). A save is refused when the file
+changed on disk after the editor was opened (a `dtk tune` Apply or another
+session saved first) — reopen the metric rather than overwrite it. A file
+that doesn't parse opens YAML-only, with the parse error on the disabled
+Builder tab. Renaming via `name:`
 is allowed — uniqueness is enforced project-wide — and rows under the old name
 stay in the `_dtk_*` tables until `dtk clean`. **Delete** lives in the edit
 overlay behind an explicit confirmation step, and the server additionally
@@ -320,6 +339,10 @@ dtk osi import model.osi.yml -m total_sales -i 1h -o metrics/  # scaffold a metr
 dtk osi export -o semantic/detectkit.osi.yml                  # publish back to OSI
 ```
 
+The `dtk ui` metric Builder's **From OSI** sub-tab does the import
+interactively (paste a model, pick a metric/target, Compile) through the
+same code path — see "Managing metrics from the UI" above.
+
 ## Common workflows
 
 ```bash

{detectkit-0.54.0 → detectkit-0.55.0}/detectkit/cli/assets/claude/rules/overview.md

@@ -106,7 +106,9 @@ same reports in a browser overlay plus an overview table (alert frequency,
 freshness — netting out any configured `loading_delay` so a deliberately
 delayed metric doesn't read as stale — quality when incidents are labeled), a
 panel that drives `dtk run` / `dtk autotune` / `dtk unlock`, and an in-browser
-editor to create, edit and delete metric YAML files. See `cli.md`.
+editor to create, edit and delete metric YAML files — a structured **Builder**
+form (with OSI import and a post-create load-then-tune flow) next to a raw
+**YAML** tab. See `cli.md`.
 
 ## Glossary
 

{detectkit-0.54.0 → detectkit-0.55.0}/detectkit/cli/assets/claude/skills/dtk-new-metric/SKILL.md

@@ -16,12 +16,14 @@ need detail on any field, read the matching file under
 `project.md`); this skill is the procedure, those are the reference.
 
 `dtk ui` also has a browser editor for metric YAMLs (a **New metric** button
-and, per row, an **Edit** action), validated the same way before it writes.
-Prefer this skill when scaffolding from scratch — it gathers the query,
-detector and alerting choices and explains each one in context; prefer the UI
-for a quick manual edit while you're already watching the cockpit (nudging a
-threshold, adding a channel) — it's a raw-YAML editor with no procedure behind
-it.
+and, per row, an **Edit** action), validated the same way before it writes:
+a structured **Builder** form (highlighted SQL pane, channel picker, an OSI
+import sub-tab, a post-create load-then-tune strip) next to a raw **YAML**
+tab. Prefer this skill when the user is working with you in the terminal —
+it gathers the query, detector and alerting choices and explains each one in
+context; point them at the UI when they'd rather click through the same flow
+themselves, or for a quick manual edit while already watching the cockpit
+(nudging a threshold, adding a channel).
 
 ## Step 0 — Confirm you're in a detectkit project
 

{detectkit-0.54.0 → detectkit-0.55.0}/detectkit/cli/commands/ui.py

@@ -18,7 +18,7 @@ from detectkit.config.profile import ProfilesConfig
 from detectkit.config.project_config import ProjectConfig
 from detectkit.database.internal_tables import InternalTablesManager
 from detectkit.ui.overview import ALL_WINDOW_PRESETS
-from detectkit.ui.server import serve_ui
+from detectkit.ui.server import build_form_meta, serve_ui
 
 
 def run_ui(
@@ -82,6 +82,8 @@ def run_ui(
     click.echo(click.style(f"detectkit UI: {project_config.name}", fg="cyan", bold=True))
     click.echo(f"  {len(metrics)} metric(s) covered by --select {select} (window: {window})")
 
+    form_meta = build_form_meta(profiles_config)
+
     try:
         serve_ui(
             project_config=project_config,
@@ -92,6 +94,7 @@ def run_ui(
             profile=profile,
             echo=click.echo,
             open_browser=not no_open,
+            form_meta=form_meta,
         )
     except KeyboardInterrupt:
         pass

{detectkit-0.54.0 → detectkit-0.55.0}/detectkit/semantic/__init__.py

@@ -24,6 +24,7 @@ from detectkit.semantic.osi_model import (
     DETECTKIT_VENDOR,
     OsiSemanticModel,
     load_osi_models,
+    parse_osi_models,
 )
 
 __all__ = [
@@ -38,4 +39,5 @@ __all__ = [
     "export_models",
     "import_osi_metric",
     "load_osi_models",
+    "parse_osi_models",
 ]

{detectkit-0.54.0 → detectkit-0.55.0}/detectkit/semantic/osi_model.py

@@ -171,21 +171,25 @@ def normalize_ai_context(raw: Any) -> dict[str, Any] | None:
     return None
 
 
-def load_osi_models(path: Path) -> list[OsiSemanticModel]:
-    """Parse an OSI YAML file into a list of :class:`OsiSemanticModel`.
-
-    Accepts the canonical ``semantic_model:`` root (a list, per the OSI examples)
-    as well as a single mapping or a bare list, for robustness. Raises
-    :class:`OsiParseError` on a missing/empty/malformed file.
+def parse_osi_models(text: str, *, source: str = "<input>") -> list[OsiSemanticModel]:
+    """Parse OSI YAML *text* into a list of :class:`OsiSemanticModel`.
+
+    The text seam behind :func:`load_osi_models`: it takes the raw YAML string
+    directly, so a caller with no file on disk — e.g. the ``dtk ui`` Builder's
+    "From OSI" paste box, which hands the browser's textarea contents straight
+    to the server — can parse a model without writing a temp file first.
+    Accepts the canonical ``semantic_model:`` root (a list, per the OSI
+    examples) as well as a single mapping or a bare list, for robustness.
+    Raises :class:`OsiParseError` on empty/malformed text; *source* names the
+    origin (a file path, or a caller-chosen marker like ``"<pasted OSI
+    model>"``) so error messages stay actionable without a real path.
     """
-    if not path.exists():
-        raise OsiParseError(f"OSI model file not found: {path}")
     try:
-        raw = yaml.safe_load(path.read_text())
+        raw = yaml.safe_load(text)
     except yaml.YAMLError as exc:
-        raise OsiParseError(f"invalid YAML in {path}: {exc}") from exc
+        raise OsiParseError(f"invalid YAML in {source}: {exc}") from exc
     if not raw:
-        raise OsiParseError(f"empty OSI model file: {path}")
+        raise OsiParseError(f"empty OSI model file: {source}")
 
     node: Any = raw.get("semantic_model", raw) if isinstance(raw, dict) else raw
     items = node if isinstance(node, list) else [node]
@@ -196,12 +200,24 @@ def load_osi_models(path: Path) -> list[OsiSemanticModel]:
         try:
             models.append(OsiSemanticModel.model_validate(item))
         except Exception as exc:  # pydantic ValidationError, etc.
-            raise OsiParseError(f"could not parse a semantic_model in {path}: {exc}") from exc
+            raise OsiParseError(f"could not parse a semantic_model in {source}: {exc}") from exc
     if not models:
-        raise OsiParseError(f"no semantic_model found in {path}")
+        raise OsiParseError(f"no semantic_model found in {source}")
     return models
 
 
+def load_osi_models(path: Path) -> list[OsiSemanticModel]:
+    """Parse an OSI YAML file into a list of :class:`OsiSemanticModel`.
+
+    Existence-checks *path*, reads it, then delegates to :func:`parse_osi_models`
+    with ``source=str(path)`` — the same parsing/error-message behavior as
+    before the text/path split, just re-homed onto the text seam.
+    """
+    if not path.exists():
+        raise OsiParseError(f"OSI model file not found: {path}")
+    return parse_osi_models(path.read_text(), source=str(path))
+
+
 def find_metric(
     models: list[OsiSemanticModel], metric_name: str
 ) -> tuple[OsiSemanticModel, OsiMetric]: