samiandClaude Sonnet 5
6632b75099
capture.offer applies capture.enabled/excludedHosts/monitoredExtensions/
monitoredMimeTypes/minSizeBytes from settings, then the rules table (new
store::Rules + CORE's vdm::rules::match_rules/glob_match — DAEMON only converts its
own stored proto::Rule JSON into CORE's plain vocabulary, per that header's own
layering note), resolves the category folder (a rule's explicit categoryId/saveDir,
else store::Categories::guess_by_extension — the same extension guess
download.probe's suggestedCategoryId already used, now shared instead of
duplicated), dedupes against active (non-terminal) tasks by exact URL, and on `take`
calls add_one() — the same path download.add itself uses, so a captured download is
a real, admitted, persisted task, not a special case.
The 750ms deadline (CLAUDE.md §4 / AGENT-DAEMON.md build step 6) is checked
cooperatively between every step via a new rpc::CaptureDataSource seam: the real
implementation wraps store::Settings/Categories/Rules/Tasks; a test fake can jump its
own injected clock forward to simulate "the store was slow just now" with zero real
sleep. This catches the realistic failure mode (several slow steps adding up) though
it cannot preempt a single pathologically stuck call mid-flight — a true preemptive
guarantee would need the same async/background-thread treatment as download.probe,
which isn't safe to do against the same sqlite3 connection (opened SQLITE_OPEN_NOMUTEX,
explicitly not for concurrent use) without a second connection; left as a known,
documented limit of this pass rather than adding that plumbing speculatively.
capture.getRules returns the same settings-backed fields capture.offer itself reads,
so the two can never drift. rulesVersion is a placeholder constant (1) — no persisted
revision counter exists yet, and the extension already re-fetches on
event.settings.changed regardless.
New store/rules.{hpp,cpp}: rules table CRUD (list, and an atomic upsert+remove for
rules.upsert later). store::Categories::guess_by_extension replaces a duplicate copy
that used to live in sched/scheduler.cpp. store::Tasks::has_active_duplicate for the
dedupe check.
Verified against real veloxd + tools/testserver: a monitored-type offer answers in
~5ms and actually creates + downloads the task, correctly categorized; an
unmonitored type, an excluded host, a rule-vetoed host, and a second offer for a
still-active URL all answer ignore with the right reason; a bad category save dir
surfaces its real -32011. New capture_offer_test covers all of the above plus the
deadline itself (two cases, one per "slow" checkpoint), asserting real wall-clock
time barely moves even though the fake clock jumped 2 simulated seconds. Full ctest:
54/54 (excluding the pre-existing, unrelated conformance failure noted in the
previous commit).
Co-Authored-By: Claude Sonnet 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01GRDjHGgpYmMoPE2UFbe7pP
Velox Download Manager (VDM)
An IDM-class download manager for Ubuntu 26.04 LTS: multi-segment accelerated HTTP(S) downloading, resume, categories and automatic file distribution, queues and scheduler, speed limiter, a Firefox extension that captures downloads automatically, and clipboard link capture.
Name is a placeholder. Binaries are
veloxd,velox-gui,velox,velox-nmhost. Rename before first release if you want something else — do it in M0, never later.
Status
Phase M0 — scaffolding. No implementation code exists yet. This repository currently contains the architecture, the wire contract, the roadmap, and one brief per build lane so that several agents can work in parallel without colliding.
Start here:
| Document | What it answers |
|---|---|
| docs/01-architecture.md | Process model, why four binaries, framework choices and why |
| docs/02-roadmap.md | Milestones M0–M7, what runs in parallel, exit gates |
| docs/03-gui-spec.md | IDM-parity UI: every window, dialog, column, menu |
| docs/04-engine-design.md | Segmentation, resume, buffers, rate limiting, disk I/O |
| docs/05-extension-spec.md | Firefox capture, transports, pairing, media grabber |
| docs/06-risks-and-spikes.md | Snap Firefox, Wayland clipboard, and the other landmines |
| docs/07-packaging.md | .deb/PPA, Flatpak, AMO signing, install layout |
| contracts/README.md | The interface. Both sides build against this |
| CLAUDE.md | Rules of engagement for agents working in this repo |
Per-lane briefs live in docs/agents/ — one per agent, each with an owned directory list, a definition of done, and the files it must never touch. To dispatch the agents, use docs/agents/PROMPTS.md — six copy-paste prompts plus the worktree commands and the wave order.
Architecture in one picture
┌────────────────────┐ native messaging (stdio JSON) ┌──────────────┐
│ Firefox extension │◄───────────── or ──────────────►│ velox-nmhost │
│ (MV3, TS) │ loopback WS 127.0.0.1 + token └──────┬───────┘
└────────────────────┘ │
│
┌────────────────────┐ ▼
│ velox-gui (Qt 6) │◄──── JSON-RPC 2.0 over Unix socket ──► ┌─────────────┐
└────────────────────┘ $XDG_RUNTIME_DIR/velox/velox.sock │ veloxd │
│ (daemon) │
┌────────────────────┐ │ │
│ velox (CLI) │◄───────────────────────────────────────┤ libveloxcore│
└────────────────────┘ └──────┬──────┘
│
SQLite + sparse files
The daemon owns all state and all sockets. The GUI is a view — closing it does not stop a download. The extension never touches the disk; it hands URL + headers + cookies to the daemon and gets a task id back.
Repository layout
vdm/
├── contracts/ ⭐ Wire contract: JSON Schema, fixtures, codegen. Frozen per version.
├── core/ C++23 libveloxcore — engine. No UI, no RPC, no SQL.
├── daemon/ C++23 veloxd — RPC server, scheduler, queues, SQLite store.
├── gui/ C++23 velox-gui — Qt 6 Widgets, IDM-parity UI.
├── cli/ C++23 velox — scriptable client.
├── nmhost/ C++23 velox-nmhost — Firefox native-messaging bridge (thin pipe).
├── extension/ TS Firefox MV3 WebExtension.
├── tools/
│ ├── mockd/ TS mock daemon — lets GUI + extension work before veloxd exists.
│ ├── testserver/ Deliberately hostile HTTP server (no Range, flaky, redirects, auth).
│ ├── bench/ Throughput and CPU benchmarks.
│ └── fuzz/ libFuzzer targets for parsers.
├── tests/
│ ├── conformance/ Protocol suite. Every lane must pass it. Gate for merging.
│ ├── integration/ veloxd + testserver.
│ └── e2e/ Playwright: real Firefox + real daemon + real file on disk.
├── packaging/ debian/, flatpak/, appimage/, native-host manifests.
└── docs/ Everything above, plus adr/ and agents/.
Toolchain bootstrap
Surveyed on this machine 2026-09-09 — most of it is already installed:
| Present | Version |
|---|---|
| git · cmake · ninja · g++ · gdb | 2.53.0 · 4.2.3 · — · 15.2.0 (C++23 ready) |
| qt6-base-dev · qt6-tools-dev · qt6-tools-dev-tools | ✓ |
| libcurl4-openssl-dev · libsqlite3-dev · nlohmann-json3-dev · libssl-dev | ✓ |
| libavformat-dev · libavcodec-dev · ffmpeg | ✓ |
| clang-format · clang-tidy · python3 · pkg-config | ✓ |
| python3-jsonschema · python3-referencing (conformance static runner) | ✓ |
Only these four are missing:
sudo apt update && sudo apt install -y \
qt6-svg-dev \ # GUI: SVG icon rendering
libsecret-1-dev \ # DAEMON: Secret Service for site logins
nodejs npm \ # EXT + PROTO: extension build, mockd, conformance runner
clang # optional: libFuzzer targets in M7
Node in the 26.04 archive may lag; if the extension toolchain needs 22+, use nvm.
Verify with cmake --preset dev && cmake --build --preset dev once lane CORE lands its
first target. Note CMake 4.2.3 is installed — newer than the 3.28 floor in
CMakeLists.txt, and it hard-errors on cmake_minimum_required below 3.5, so no
dependency may ship a pre-3.5 CMake file.