From 0af4a5c4fc595af7921330130e6d03dd0c25145b Mon Sep 17 00:00:00 2001
From: sami <sami.alabri@gmail.com>
Date: Fri, 11 Sep 2026 07:55:06 +0400
Subject: [PATCH] gui: verify against the real veloxd; file one daemon gap
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Pointed the existing RPC client at a real veloxd instance (isolated
HOME/XDG_RUNTIME_DIR/XDG_DATA_HOME — never touched the real ~/Downloads),
added a real download.add against tools/testserver, and watched it render
live end to end with no GUI code changes:

  - handshake, subscribe, category.list/queue.list all match what DAEMON
    reported
  - the full event.task.state sequence and batched event.task.progress
    both applied correctly by DownloadTableModel
  - the written file's SHA-256 matches the server's reference

Filed gui/docs/daemon-requests-m1.md: TaskSummary.sizeBytes is never
populated by this daemon build, even in download.get after the task
completes with the exact byte count already on disk. Not a GUI bug —
ProgressDelegate and the model already do the documented right thing
when size is unknown (fall back to plain text, no bar) — but it means
every task renders without a percentage against the real daemon today.
mockd always supplies sizeBytes so this doesn't block current GUI work;
flagging before the M1 GUI<->daemon integration pass.

mockd stays the primary harness for the unhappy paths
(--slow/--flaky/--drop-connection) that a real daemon won't misbehave on
command for.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016Ne28kx4VreeBWZv82Nksd
---
 gui/docs/daemon-requests-m1.md | 39 ++++++++++++++++++++++++++++++++++
 1 file changed, 39 insertions(+)
 create mode 100644 gui/docs/daemon-requests-m1.md

diff --git a/gui/docs/daemon-requests-m1.md b/gui/docs/daemon-requests-m1.md
new file mode 100644
index 0000000..5604d23
--- /dev/null
+++ b/gui/docs/daemon-requests-m1.md
@@ -0,0 +1,39 @@
+# GUI → DAEMON requests (M1)
+
+Filed by lane GUI, from independent verification of `velox-gui` against a real `veloxd`
+(isolated `HOME`/`XDG_RUNTIME_DIR`/`XDG_DATA_HOME`, real `tools/testserver` transfer, GUI's
+existing RPC client and model — no code changed for this check). Handshake, subscribe,
+`category.list`/`queue.list`, the full `event.task.state` sequence, and batched
+`event.task.progress` all match what DAEMON already reported. One gap, below.
+
+## `TaskSummary.sizeBytes` is never populated, even after `complete`
+
+Repro:
+```
+download.add {"url": "http://127.0.0.1:<testserver>/throttled/file/8M", "segments": 4}
+# ... wait for state: complete ...
+download.get {"taskId": "<id>"}
+```
+
+Result's `summary` has no `sizeBytes` key at all (not `null` — absent) even once
+`downloadedBytes` is `8388608` and `state` is `complete`. Same in the `download.list` item
+and in every `event.task.state` / `event.task.progress` frame along the way.
+
+This isn't a probe-order artifact on my end — I called `download.add` directly without a
+prior `download.probe`, but the daemon has the size by the time the transfer finishes (it
+wrote exactly `8388608` bytes) and `download.get` is documented as backing the progress
+dialog with full detail, so the gap persists past the point where the daemon unambiguously
+knows the answer.
+
+**Effect on the GUI:** `TaskSummary.sizeBytes` is what `DownloadTableModel` uses for both
+the Size column and the Status column's percentage — with it absent, Size renders `—` and
+Status falls back to plain text ("Downloading" / "Complete") instead of the progress bar
+with a percentage, for the entire life of every task. This isn't a rendering bug on this
+end: `ProgressDelegate` and the model both do the documented right thing when size is
+unknown (`docs/03-gui-spec.md`'s screenshot shows a bar with a percentage — that needs a
+byte count from somewhere). Screenshots from this run are attached to the session if useful
+as a reference for what "no size" currently looks like end to end.
+
+Not urgent — mockd always supplies `sizeBytes`, so this doesn't block M1 GUI work — but
+worth knowing before the M1 GUI↔real-daemon integration pass, since the percentage bar is
+the headline visual of the main table.