Combines dioxus's desktop (webview) renderer with the existing `server`
feature so `#[server]` functions execute in-process instead of going over
HTTP — one self-contained native binary with DB, feed polling, LLM calls,
and the scheduler, no separate server to run. main.rs picks the desktop
launcher explicitly since dioxus::launch's automatic platform detection
would otherwise prefer the (also-enabled) server platform over desktop.
Verified: cargo check/clippy pass for the new feature (native crates and
existing server/web features unaffected), and running the built binary
opens a window and completes an in-process server-fn call (DB connects,
migrations run) with no HTTP round trip. CI gets a matching desktop
clippy job with the GTK/WebKit apt packages dioxus-desktop needs to
compile on Linux.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
crates/web/src/components/ was a byte-for-byte copy of the
DioxusLabs/components "preview" registry (a shadcn-style copy-into-
your-project source, not something published as a dependency). Move it
wholesale into a new feedsignal-dioxus-components crate so it reads as
vendored code we depend on rather than application source, and future
app-specific styling should layer on via the class/attributes props
each component already accepts instead of editing the vendored files.
No component logic changed — this is a pure move plus import-path
updates in the four app files that consumed it.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Default view stays the all-feeds joined article list, now with a sidebar
listing every subscribed feed so a reader can pin down to one feed's
articles. Filtering happens server-side (list_ranked_articles now takes
an optional feed_id).
Pulled in the sidebar/badge/scroll_area (plus their sheet/skeleton/
tooltip/separator dependencies) components via `dx components add`
instead of hand-rolling nav/tag/scroll markup, matching this project's
existing pattern of using the Dioxus component library over raw
elements (see button/input).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PqTJmazHBQK878vjQ4JnnF
Adds a URL input + Subscribe button (dx-components Input/Button) to the
UI, wired to a new subscribe_feed server function that upserts the feed
row and does an immediate first fetch so the reader isn't empty until
the next scheduled poll. feedsignal_feeds::fetch_feed now also returns
the feed's title, used to replace the URL placeholder once fetched.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XJJQb2DWZZwQ1yPiaAQQoY
sqlx's query!/query_as! macros only check raw SQL strings against the live
schema; Diesel's table!-derived DSL type-checks query structure itself at
compile time. SQLite has no native async driver, so diesel-async wraps a
blocking SqliteConnection via SyncConnectionWrapper, pooled with bb8.
Migrations move from sqlx's single-file-per-migration format to Diesel's
up.sql/down.sql pairs, run transactionally via diesel_migrations against a
throwaway sync connection at boot (MigrationHarness needs a sync
Connection), giving revertable migrations that sqlx::migrate! doesn't
support.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Rust workspace with core (topic-affinity learning engine + relevance
scoring), db (sqlite/sqlx schema + repo), feeds (RSS/Atom fetch), llm
(rig + local Ollama embeddings/completion), and web (axum + Dioxus
fullstack UI, no separate JS stack). Two-stage relevance filtering
(embedding shortlist -> LLM judgment) and an engagement/surprise-based
topic affinity engine with daily decay. All crates compile and core's
affinity engine has passing unit tests; server and wasm client targets
of feedsignal-web both check clean.
