qapu-cli 0.7.2__tar.gz → 0.7.3__tar.gz

{qapu_cli-0.7.2/qapu_cli.egg-info → qapu_cli-0.7.3}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: qapu-cli
-Version: 0.7.2
+Version: 0.7.3
 Summary: CLI client for the Qapu API - built for the Hermes agent, but usable by anyone talking to api.ovoo.com.tr from outside the Swarm.
 Author: OVOO Technology
 Classifier: Programming Language :: Python :: 3
@@ -59,7 +59,7 @@ Either way installs a `qapu` command (see `pyproject.toml`'s `[project.scripts]`
 | `qapu data` | Readings per variable for a device - latest value, last N buffered readings (--last), daily min/avg/max (--days), or an explicit --start/--end range (GET /hermes/data/{device_id}). |
 | `qapu energy` | One day's active/reactive energy breakdown per phase (GET /hermes/energy/{device_id}). |
 | `qapu health` | Check CLI/server version, connectivity, and server status (GET /health, no auth required). |
-| `qapu pipeline` | Fleet-wide pipeline throughput for a time window - ingest/data/rule/blockchain packet+event counts (GET /hermes/pipeline/stats). |
+| `qapu pipeline` | Fleet-wide pipeline throughput for a time window - ingest/data/rule/blockchain packet+event counts (GET /hermes/pipeline/stats). `--watch` live-refreshes in place. |
 | `qapu power` | Power synthesis parameters, grouped (active/reactive/apparent, imbalance, power factor) (GET /hermes/data/{device_id}). |
 | `qapu timeline` | Get one device's timeline events (GET /hermes/timeline/{device_id}). |
 | `qapu trend` | Trend for one variable on one device: recent readings, daily min/avg/max, or an explicit --start/--end range (GET /hermes/trend/{device_id}/{variable_id}). |
@@ -368,6 +368,8 @@ qapu pipeline --json
 ```
 Not device-scoped - a fleet-wide summary across every service in the `ingest -> stream -> calibration -> raw-writer -> synthesis -> ... -> rule` pipeline. Deliberately reads from the real tables each stage actually writes to (`raw_data.stream_time`/`valid_pack` for `hardware`'s ingest, `streams.stream_time` for `data`'s calibration+synthesis completion, `device_timeline.create_time` for `rule`'s observable output, `blockchain.create_time` for mined blocks) rather than any service's own `/health` endpoint - those are point-in-time snapshots (uptime, CPU, last-message-age), not a windowed throughput count. New `common/qapu_common/domain/pipeline.py` (`Pipeline_Stats.get_stats(minutes)`, four plain `SELECT count(*) ... WHERE <time column> >= now() - interval` queries, no caching - these are meant to be live) + `GET /hermes/pipeline/stats` (`services/api/src/routers/hermes.py`, `minutes` query param, 1 to 10080/7 days). **`Rule_Events` deliberately does NOT count rule evaluations** - `rule` evaluates every single stream message 1:1, the same count `Data_Processed` already reports, so repeating it would be redundant; it counts `device_timeline` rows instead, rule's actual observable output (a trigger/reset transition), not every evaluation pass. The CLI prints a bordered summary table plus a soft backlog hint (yellow note, not an error) if `Data_Processed` looks meaningfully behind `Ingest_Valid` (`<80%`) - a sign of consumer lag worth checking, not itself proof of one. Live-tested against real prod DB: `--minutes 60` correctly returned all zeros (no test traffic in the preceding hour at that point in the session), `--minutes 1440` correctly returned real 24h counts, and a fresh real packet sent immediately before a `--minutes 5` check showed up as exactly `+1` across Ingest/Data_Processed/Blockchain_Mined (Rule_Events stayed `0`, correctly - that packet's only variable, `PCB_T`, didn't cross any rule threshold).
 
+**`--watch`/`-w` added the same day**, per direct follow-up request ("pipe line canlı takip edilebilecek bir tool yapabilirmiyiz") - polls the same endpoint every `--interval` seconds (default `5.0`) and redraws the summary in place via Rich's `Live`, instead of printing once and exiting; `Ctrl+C` stops cleanly. Each poll after the first also shows a `DEĞİŞİM` column - green `+N` if a stage's count grew since the last poll, red `-N` if it somehow shrank (shouldn't happen for these monotonic counters within a fixed window, but rendered anyway rather than assumed impossible), `·` if unchanged - a bare redrawn count doesn't read as "live" the way a visible delta does. Refactored the table-building logic into a shared `_build_pipeline_group()` (title + table + optional backlog note, returned as one `rich.console.Group`) used by both the one-shot path and the `--watch` loop, so they can't drift apart. Not combinable with `--json` (a live-refreshed raw-JSON dump isn't a coherent thing to build - errors clearly if both are passed). The delta/redraw logic itself was verified directly (calling `_build_pipeline_group()` with two synthetic consecutive polls and confirming the `+4`/`+2`/`·` rendering, plus the empty-result error path) rather than through a full `--watch` session end to end - `rich.Live`'s screen-redraw behavior depends on `console.is_terminal`, which this environment's piped/non-TTY test harness can't exercise the same way a real interactive terminal does; confirm the actual live redraw looks right in a real terminal session if this is touched again.
+
 `qapu trend` shows a per-variable history plus a simple linear-regression trend line (slope + direction). Three modes, picked by which options you pass:
 - **Raw readings** (`--last N`, default `N=20`): the measurement cache's rolling buffer - bounded to its own depth (~50 most recent packets), *not* a time window. Good for "what's it doing right now."
 - **Daily aggregates** (`--days N`): one row per calendar day (min/avg/max/count), from the same cache the `/measurement/{device_id}/history` endpoint reads - this is what actually covers multi-day/month windows, since the raw buffer doesn't go back that far. `--days` wins over `--last` if both are given (and `--start`/`--end` isn't).

qapu_cli-0.7.2/PKG-INFO → qapu_cli-0.7.3/README.md

@@ -1,15 +1,3 @@
-Metadata-Version: 2.4
-Name: qapu-cli
-Version: 0.7.2
-Summary: CLI client for the Qapu API - built for the Hermes agent, but usable by anyone talking to api.ovoo.com.tr from outside the Swarm.
-Author: OVOO Technology
-Classifier: Programming Language :: Python :: 3
-Requires-Python: >=3.10
-Description-Content-Type: text/markdown
-Requires-Dist: typer<1.0,>=0.12
-Requires-Dist: httpx<1.0,>=0.27
-Requires-Dist: rich<16.0,>=13.0
-
 # Qapu CLI
 
 A thin command-line client for the Qapu API (`api.ovoo.com.tr`), built for the Hermes agent (runs outside this Swarm, in a separate datacenter, and only ever talks to Qapu through this public API) - but usable by anything else that needs to script against Qapu from outside the private network.
@@ -59,7 +47,7 @@ Either way installs a `qapu` command (see `pyproject.toml`'s `[project.scripts]`
 | `qapu data` | Readings per variable for a device - latest value, last N buffered readings (--last), daily min/avg/max (--days), or an explicit --start/--end range (GET /hermes/data/{device_id}). |
 | `qapu energy` | One day's active/reactive energy breakdown per phase (GET /hermes/energy/{device_id}). |
 | `qapu health` | Check CLI/server version, connectivity, and server status (GET /health, no auth required). |
-| `qapu pipeline` | Fleet-wide pipeline throughput for a time window - ingest/data/rule/blockchain packet+event counts (GET /hermes/pipeline/stats). |
+| `qapu pipeline` | Fleet-wide pipeline throughput for a time window - ingest/data/rule/blockchain packet+event counts (GET /hermes/pipeline/stats). `--watch` live-refreshes in place. |
 | `qapu power` | Power synthesis parameters, grouped (active/reactive/apparent, imbalance, power factor) (GET /hermes/data/{device_id}). |
 | `qapu timeline` | Get one device's timeline events (GET /hermes/timeline/{device_id}). |
 | `qapu trend` | Trend for one variable on one device: recent readings, daily min/avg/max, or an explicit --start/--end range (GET /hermes/trend/{device_id}/{variable_id}). |
@@ -368,6 +356,8 @@ qapu pipeline --json
 ```
 Not device-scoped - a fleet-wide summary across every service in the `ingest -> stream -> calibration -> raw-writer -> synthesis -> ... -> rule` pipeline. Deliberately reads from the real tables each stage actually writes to (`raw_data.stream_time`/`valid_pack` for `hardware`'s ingest, `streams.stream_time` for `data`'s calibration+synthesis completion, `device_timeline.create_time` for `rule`'s observable output, `blockchain.create_time` for mined blocks) rather than any service's own `/health` endpoint - those are point-in-time snapshots (uptime, CPU, last-message-age), not a windowed throughput count. New `common/qapu_common/domain/pipeline.py` (`Pipeline_Stats.get_stats(minutes)`, four plain `SELECT count(*) ... WHERE <time column> >= now() - interval` queries, no caching - these are meant to be live) + `GET /hermes/pipeline/stats` (`services/api/src/routers/hermes.py`, `minutes` query param, 1 to 10080/7 days). **`Rule_Events` deliberately does NOT count rule evaluations** - `rule` evaluates every single stream message 1:1, the same count `Data_Processed` already reports, so repeating it would be redundant; it counts `device_timeline` rows instead, rule's actual observable output (a trigger/reset transition), not every evaluation pass. The CLI prints a bordered summary table plus a soft backlog hint (yellow note, not an error) if `Data_Processed` looks meaningfully behind `Ingest_Valid` (`<80%`) - a sign of consumer lag worth checking, not itself proof of one. Live-tested against real prod DB: `--minutes 60` correctly returned all zeros (no test traffic in the preceding hour at that point in the session), `--minutes 1440` correctly returned real 24h counts, and a fresh real packet sent immediately before a `--minutes 5` check showed up as exactly `+1` across Ingest/Data_Processed/Blockchain_Mined (Rule_Events stayed `0`, correctly - that packet's only variable, `PCB_T`, didn't cross any rule threshold).
 
+**`--watch`/`-w` added the same day**, per direct follow-up request ("pipe line canlı takip edilebilecek bir tool yapabilirmiyiz") - polls the same endpoint every `--interval` seconds (default `5.0`) and redraws the summary in place via Rich's `Live`, instead of printing once and exiting; `Ctrl+C` stops cleanly. Each poll after the first also shows a `DEĞİŞİM` column - green `+N` if a stage's count grew since the last poll, red `-N` if it somehow shrank (shouldn't happen for these monotonic counters within a fixed window, but rendered anyway rather than assumed impossible), `·` if unchanged - a bare redrawn count doesn't read as "live" the way a visible delta does. Refactored the table-building logic into a shared `_build_pipeline_group()` (title + table + optional backlog note, returned as one `rich.console.Group`) used by both the one-shot path and the `--watch` loop, so they can't drift apart. Not combinable with `--json` (a live-refreshed raw-JSON dump isn't a coherent thing to build - errors clearly if both are passed). The delta/redraw logic itself was verified directly (calling `_build_pipeline_group()` with two synthetic consecutive polls and confirming the `+4`/`+2`/`·` rendering, plus the empty-result error path) rather than through a full `--watch` session end to end - `rich.Live`'s screen-redraw behavior depends on `console.is_terminal`, which this environment's piped/non-TTY test harness can't exercise the same way a real interactive terminal does; confirm the actual live redraw looks right in a real terminal session if this is touched again.
+
 `qapu trend` shows a per-variable history plus a simple linear-regression trend line (slope + direction). Three modes, picked by which options you pass:
 - **Raw readings** (`--last N`, default `N=20`): the measurement cache's rolling buffer - bounded to its own depth (~50 most recent packets), *not* a time window. Good for "what's it doing right now."
 - **Daily aggregates** (`--days N`): one row per calendar day (min/avg/max/count), from the same cache the `/measurement/{device_id}/history` endpoint reads - this is what actually covers multi-day/month windows, since the raw buffer doesn't go back that far. `--days` wins over `--last` if both are given (and `--start`/`--end` isn't).

{qapu_cli-0.7.2 → qapu_cli-0.7.3}/pyproject.toml

@@ -1,6 +1,6 @@
 [project]
 name = "qapu-cli"
-version = "0.7.2"
+version = "0.7.3"
 description = "CLI client for the Qapu API - built for the Hermes agent, but usable by anyone talking to api.ovoo.com.tr from outside the Swarm."
 readme = "README.md"
 requires-python = ">=3.10"

{qapu_cli-0.7.2 → qapu_cli-0.7.3}/qapu_cli/main.py

@@ -15,7 +15,8 @@ from typing import Any, Optional
 import httpx
 import typer
 from rich.columns import Columns
-from rich.console import Console
+from rich.console import Console, Group
+from rich.live import Live
 from rich.panel import Panel
 from rich.table import Table
 from rich.tree import Tree
@@ -1256,32 +1257,49 @@ def device_energy(
 # Get One Variable's Trend on One Device - Either the Last N Raw Buffered
 # Readings, or Daily Min/Avg/Max Over the Last N Days (Mutually Exclusive -
 # --days Wins if Both are Given)
-@app.command("pipeline")
-def pipeline_stats(
-	minutes: int = typer.Option(60, "--minutes", help="Window size in minutes (default 60, max 10080/7 days)."),
-	as_json: bool = typer.Option(False, "--json", help="Print raw JSON instead of the summary table."),
-):
-	"""Fleet-wide pipeline throughput for a time window - ingest/data/rule/blockchain packet+event counts (GET /hermes/pipeline/stats)."""
-	result: dict[str, Any] = client.get("/hermes/pipeline/stats", params={"minutes": minutes})
+def _window_label(minutes: int) -> str:
 
-	if as_json:
-		typer.echo(json.dumps(result, indent=2))
-		return
+	# Format a Window Size as "N dk" or "N sa" (Whole Hours Only)
+	if minutes < 60 or minutes % 60 != 0:
+		return f"{minutes} dk"
+	return f"{minutes // 60} sa"
 
-	if not result:
-		typer.echo("İstatistikler alınamadı.")
-		return
 
-	window = result.get("Window_Minutes", minutes)
-	window_label = f"{window} dk" if window < 60 else (f"{window // 60} sa" if window % 60 == 0 else f"{window} dk")
+# Build the Pipeline Summary as a Single Renderable (Title + Table +
+# Optional Backlog Note) - Shared by the One-Shot Print and the --watch
+# Live Loop Below, so Both Stay in Sync as the Table's Shape Evolves.
+# `previous` (the Last Poll's raw stats dict, or None) Lets --watch Show a
+# "+N since last check" Delta per Stage, Which is What Actually Makes a
+# Polling Loop Feel "Live" Rather than Just a Table that Happens to
+# Redraw - a Bare Count with No Motion Indicator Doesn't Read as
+# Streaming.
+def _build_pipeline_group(result: dict[str, Any], minutes: int, previous: Optional[dict[str, Any]] = None, as_of: Optional[str] = None) -> Group:
+
+	title = f"[bold]Pipeline Özeti[/bold] - son {_window_label(minutes)}"
+	if as_of:
+		title += f"  [dim](güncellendi: {as_of})[/dim]"
 
-	console.print(f"[bold]Pipeline Özeti[/bold] - son {window_label}\n")
+	if not result:
+		return Group(title, "\n[red]İstatistikler alınamadı.[/red]")
 
 	table = Table(show_header=True, header_style="bold")
 	table.add_column("AŞAMA")
 	table.add_column("SAYI", justify="right")
+	if previous is not None:
+		table.add_column("DEĞİŞİM", justify="right")
 	table.add_column("DETAY")
 
+	def delta_str(key: str, current: int) -> str:
+		if previous is None:
+			return ""
+		prev_value = previous.get(key, 0) or 0
+		diff = current - prev_value
+		if diff > 0:
+			return f"[green]+{diff}[/green]"
+		if diff < 0:
+			return f"[red]{diff}[/red]"
+		return "·"
+
 	ingest_total = result.get("Ingest_Total", 0)
 	ingest_valid = result.get("Ingest_Valid", 0)
 	ingest_invalid = result.get("Ingest_Invalid", 0)
@@ -1289,18 +1307,65 @@ def pipeline_stats(
 	rule_events = result.get("Rule_Events", 0)
 	blocks_mined = result.get("Blockchain_Mined", 0)
 
-	table.add_row("Ingest (hardware)", str(ingest_total), f"{ingest_valid} geçerli, {ingest_invalid} geçersiz")
-	table.add_row("Data İşlendi (data)", str(data_processed), "kalibrasyon + sentez tamamlanan paket")
-	table.add_row("Kural Olayları (rule)", str(rule_events), "tetiklenen/sıfırlanan olay (device_timeline)")
-	table.add_row("Blockchain Kazıldı", str(blocks_mined), "yeni blok")
+	rows = [
+		("Ingest (hardware)", ingest_total, "Ingest_Total", f"{ingest_valid} geçerli, {ingest_invalid} geçersiz"),
+		("Data İşlendi (data)", data_processed, "Data_Processed", "kalibrasyon + sentez tamamlanan paket"),
+		("Kural Olayları (rule)", rule_events, "Rule_Events", "tetiklenen/sıfırlanan olay (device_timeline)"),
+		("Blockchain Kazıldı", blocks_mined, "Blockchain_Mined", "yeni blok"),
+	]
+	for label, value, key, detail in rows:
+		row = [label, str(value)]
+		if previous is not None:
+			row.append(delta_str(key, value))
+		row.append(detail)
+		table.add_row(*row)
 
-	console.print(table)
+	parts: list[Any] = [title, table]
 
 	# Simple Backlog Hint - not an Alert, Just a Note if the Numbers Look
 	# Off (data_processed Should Track ingest_valid Closely Since data
 	# Consumes qapu.raw 1:1)
 	if ingest_valid > 0 and data_processed < ingest_valid * 0.8:
-		console.print(f"\n[yellow]Not: Data işlenen paket sayısı ({data_processed}), geçerli ingest sayısından ({ingest_valid}) belirgin şekilde düşük - olası birikme/gecikme, kontrol edilebilir.[/yellow]")
+		parts.append(f"[yellow]Not: Data işlenen paket sayısı ({data_processed}), geçerli ingest sayısından ({ingest_valid}) belirgin şekilde düşük - olası birikme/gecikme, kontrol edilebilir.[/yellow]")
+
+	return Group(*parts)
+
+
+@app.command("pipeline")
+def pipeline_stats(
+	minutes: int = typer.Option(60, "--minutes", help="Window size in minutes (default 60, max 10080/7 days)."),
+	watch: bool = typer.Option(False, "--watch", "-w", help="Live-refresh the summary in place every --interval seconds (Ctrl+C to stop), instead of printing once."),
+	interval: float = typer.Option(5.0, "--interval", help="Seconds between refreshes in --watch mode."),
+	as_json: bool = typer.Option(False, "--json", help="Print raw JSON instead of the summary table. Not combinable with --watch."),
+):
+	"""Fleet-wide pipeline throughput for a time window - ingest/data/rule/blockchain packet+event counts (GET /hermes/pipeline/stats)."""
+
+	if as_json and watch:
+		typer.echo("Error: --json ve --watch birlikte kullanılamaz.", err=True)
+		raise typer.Exit(code=1)
+
+	# --watch: Poll on a Live-Refreshed Loop Until Ctrl+C
+	if watch:
+		previous: Optional[dict[str, Any]] = None
+		try:
+			with Live(console=console, refresh_per_second=4) as live:
+				while True:
+					result: dict[str, Any] = client.get("/hermes/pipeline/stats", params={"minutes": minutes})
+					as_of = datetime.now().strftime("%H:%M:%S")
+					live.update(_build_pipeline_group(result, minutes, previous=previous, as_of=as_of))
+					previous = result or previous
+					time.sleep(interval)
+		except KeyboardInterrupt:
+			return
+
+	# One-Shot Fetch
+	result: dict[str, Any] = client.get("/hermes/pipeline/stats", params={"minutes": minutes})
+
+	if as_json:
+		typer.echo(json.dumps(result, indent=2))
+		return
+
+	console.print(_build_pipeline_group(result, minutes))
 
 
 @app.command("trend")

qapu_cli-0.7.2/README.md → qapu_cli-0.7.3/qapu_cli.egg-info/PKG-INFO

@@ -1,3 +1,15 @@
+Metadata-Version: 2.4
+Name: qapu-cli
+Version: 0.7.3
+Summary: CLI client for the Qapu API - built for the Hermes agent, but usable by anyone talking to api.ovoo.com.tr from outside the Swarm.
+Author: OVOO Technology
+Classifier: Programming Language :: Python :: 3
+Requires-Python: >=3.10
+Description-Content-Type: text/markdown
+Requires-Dist: typer<1.0,>=0.12
+Requires-Dist: httpx<1.0,>=0.27
+Requires-Dist: rich<16.0,>=13.0
+
 # Qapu CLI
 
 A thin command-line client for the Qapu API (`api.ovoo.com.tr`), built for the Hermes agent (runs outside this Swarm, in a separate datacenter, and only ever talks to Qapu through this public API) - but usable by anything else that needs to script against Qapu from outside the private network.
@@ -47,7 +59,7 @@ Either way installs a `qapu` command (see `pyproject.toml`'s `[project.scripts]`
 | `qapu data` | Readings per variable for a device - latest value, last N buffered readings (--last), daily min/avg/max (--days), or an explicit --start/--end range (GET /hermes/data/{device_id}). |
 | `qapu energy` | One day's active/reactive energy breakdown per phase (GET /hermes/energy/{device_id}). |
 | `qapu health` | Check CLI/server version, connectivity, and server status (GET /health, no auth required). |
-| `qapu pipeline` | Fleet-wide pipeline throughput for a time window - ingest/data/rule/blockchain packet+event counts (GET /hermes/pipeline/stats). |
+| `qapu pipeline` | Fleet-wide pipeline throughput for a time window - ingest/data/rule/blockchain packet+event counts (GET /hermes/pipeline/stats). `--watch` live-refreshes in place. |
 | `qapu power` | Power synthesis parameters, grouped (active/reactive/apparent, imbalance, power factor) (GET /hermes/data/{device_id}). |
 | `qapu timeline` | Get one device's timeline events (GET /hermes/timeline/{device_id}). |
 | `qapu trend` | Trend for one variable on one device: recent readings, daily min/avg/max, or an explicit --start/--end range (GET /hermes/trend/{device_id}/{variable_id}). |
@@ -356,6 +368,8 @@ qapu pipeline --json
 ```
 Not device-scoped - a fleet-wide summary across every service in the `ingest -> stream -> calibration -> raw-writer -> synthesis -> ... -> rule` pipeline. Deliberately reads from the real tables each stage actually writes to (`raw_data.stream_time`/`valid_pack` for `hardware`'s ingest, `streams.stream_time` for `data`'s calibration+synthesis completion, `device_timeline.create_time` for `rule`'s observable output, `blockchain.create_time` for mined blocks) rather than any service's own `/health` endpoint - those are point-in-time snapshots (uptime, CPU, last-message-age), not a windowed throughput count. New `common/qapu_common/domain/pipeline.py` (`Pipeline_Stats.get_stats(minutes)`, four plain `SELECT count(*) ... WHERE <time column> >= now() - interval` queries, no caching - these are meant to be live) + `GET /hermes/pipeline/stats` (`services/api/src/routers/hermes.py`, `minutes` query param, 1 to 10080/7 days). **`Rule_Events` deliberately does NOT count rule evaluations** - `rule` evaluates every single stream message 1:1, the same count `Data_Processed` already reports, so repeating it would be redundant; it counts `device_timeline` rows instead, rule's actual observable output (a trigger/reset transition), not every evaluation pass. The CLI prints a bordered summary table plus a soft backlog hint (yellow note, not an error) if `Data_Processed` looks meaningfully behind `Ingest_Valid` (`<80%`) - a sign of consumer lag worth checking, not itself proof of one. Live-tested against real prod DB: `--minutes 60` correctly returned all zeros (no test traffic in the preceding hour at that point in the session), `--minutes 1440` correctly returned real 24h counts, and a fresh real packet sent immediately before a `--minutes 5` check showed up as exactly `+1` across Ingest/Data_Processed/Blockchain_Mined (Rule_Events stayed `0`, correctly - that packet's only variable, `PCB_T`, didn't cross any rule threshold).
 
+**`--watch`/`-w` added the same day**, per direct follow-up request ("pipe line canlı takip edilebilecek bir tool yapabilirmiyiz") - polls the same endpoint every `--interval` seconds (default `5.0`) and redraws the summary in place via Rich's `Live`, instead of printing once and exiting; `Ctrl+C` stops cleanly. Each poll after the first also shows a `DEĞİŞİM` column - green `+N` if a stage's count grew since the last poll, red `-N` if it somehow shrank (shouldn't happen for these monotonic counters within a fixed window, but rendered anyway rather than assumed impossible), `·` if unchanged - a bare redrawn count doesn't read as "live" the way a visible delta does. Refactored the table-building logic into a shared `_build_pipeline_group()` (title + table + optional backlog note, returned as one `rich.console.Group`) used by both the one-shot path and the `--watch` loop, so they can't drift apart. Not combinable with `--json` (a live-refreshed raw-JSON dump isn't a coherent thing to build - errors clearly if both are passed). The delta/redraw logic itself was verified directly (calling `_build_pipeline_group()` with two synthetic consecutive polls and confirming the `+4`/`+2`/`·` rendering, plus the empty-result error path) rather than through a full `--watch` session end to end - `rich.Live`'s screen-redraw behavior depends on `console.is_terminal`, which this environment's piped/non-TTY test harness can't exercise the same way a real interactive terminal does; confirm the actual live redraw looks right in a real terminal session if this is touched again.
+
 `qapu trend` shows a per-variable history plus a simple linear-regression trend line (slope + direction). Three modes, picked by which options you pass:
 - **Raw readings** (`--last N`, default `N=20`): the measurement cache's rolling buffer - bounded to its own depth (~50 most recent packets), *not* a time window. Good for "what's it doing right now."
 - **Daily aggregates** (`--days N`): one row per calendar day (min/avg/max/count), from the same cache the `/measurement/{device_id}/history` endpoint reads - this is what actually covers multi-day/month windows, since the raw buffer doesn't go back that far. `--days` wins over `--last` if both are given (and `--start`/`--end` isn't).