Record JSON log ingestion design decision, file follow-up tickets (ticket 003)

Decision covers detection, invalid-JSON handling, and a prioritized feature
roadmap (repowise decision fdb47034ad954e3ea0b898fdc2750c32). Files three
follow-up implementation tickets (014-016) and removes the investigation
ticket now that the decision is recorded.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XFUNZwCvz3kcod3352ZR2o

tickets/003-json-log-ingestion-support.md

@@ -1,13 +0,0 @@
-# Investigate and design JSON log input handling
-
-Figure out what should and can happen if the logs are JSON input. What happens if the JSON is invalid during ingestion. What useful functionality can we have.
-
-## Notes
-This is an investigation/design ticket before implementation. Needs a decision on:
-- How JSON-formatted log lines are detected and parsed.
-- What happens on invalid/malformed JSON during ingestion (drop, store raw, flag, error metric, etc).
-- What functionality JSON structure could unlock (field extraction, filtering/querying by field, structured display in the log viewer, etc).
-
-## Acceptance criteria
-- A short design decision is written (e.g. via `repowise decision add`) covering: detection, invalid-JSON handling, and prioritized feature ideas.
-- Follow-up implementation ticket(s) filed based on the decision.

tickets/014-json-log-structured-display.md

@@ -0,0 +1,10 @@
+# Render JSON log lines as structured key/value trees
+
+Follow-up to the JSON log ingestion design decision (repowise decision fdb47034ad954e3ea0b898fdc2750c32).
+
+When an ingested log line's raw text parses as a JSON object, display it in the log viewer as a collapsible key/value tree instead of a raw string. Lines that aren't valid JSON objects keep rendering as plain text, unchanged.
+
+## Acceptance criteria
+- LogPreview.tsx detects a JSON-object log line (starts with `{` and parses) and renders it as a collapsible key/value tree.
+- Non-JSON (or invalid-JSON) lines are unaffected — same raw-text rendering as today.
+- Detection/parsing happens client-side against the existing raw `text` field; no backend API change required for this ticket.

tickets/015-json-field-param-metric-declaration.md

@@ -0,0 +1,10 @@
+# Allow params/metrics to be declared from a JSON field path
+
+Follow-up to the JSON log ingestion design decision (repowise decision fdb47034ad954e3ea0b898fdc2750c32).
+
+Extend param/metric declaration so a param can be extracted from a JSON field path (e.g. `foo.bar`) on lines that parse as JSON objects, as an alternative to the existing regex-capture-group extraction.
+
+## Acceptance criteria
+- `RegexToMetricPrimitiveMatcher` (src/data_value.rs) or a sibling type supports a JSON-field-path extraction source alongside the existing regex-capture-group source, reusing `ParamRole`/`MetricPrimitiveKind`.
+- The params declaration UI (Params.tsx) lets a user choose "JSON field" as an alternative to "regex capture group" when declaring a param, for lines detected as JSON.
+- Existing regex-based params/metrics are unaffected.

tickets/016-filter-by-json-field.md

@@ -0,0 +1,11 @@
+# Support filtering/querying by JSON field in the filter bar
+
+Follow-up to the JSON log ingestion design decision (repowise decision fdb47034ad954e3ea0b898fdc2750c32).
+
+Extend the filter query language with a JSON field accessor (e.g. `json[field] <op> value`), comparable to the existing `metric[param] <op> value` comparison, so JSON fields can be filtered without first declaring a metric/param for them.
+
+## Acceptance criteria
+- `filter_parser.pest` gains a `json[field]` (or similar) accessor usable anywhere `metric[param]` is today, for comparisons.
+- The engine evaluates `json[field]` against a line's parsed JSON (when it parses as an object), consistent with how declared params/metrics are evaluated today.
+- Lines that aren't valid JSON simply don't match any `json[field]` comparison (no error).
+- Existing filter syntax (metric/param comparisons, regex(), sequence, timestamp, and/or) is unaffected.