Verify each finding against the current code and only fix it if needed.

Inline comments:
In @.specify/NOSTR_EXCHANGE_RATES.md:
- Around line 259-269: Update the spec to use a consistent event update
frequency across the document: pick either a specific interval (e.g., "every 5
minutes") or explicitly state the allowed range (e.g., "every 5–10 minutes
depending on market volatility"), and apply that choice to all mentions
including the "v1 (HTTP)"/ "v2 (Nostr)" bandwidth comparison block, the "5-10
minute TTL" reference, and the PR objectives section so "1 event pushed to all
subscribed clients every 5-10 minutes" and the stated PR objective ("updates
every 5 minutes") are aligned.
- Around line 166-170: The spec adds a persistent SQLite cache for
"exchange_rates" but omits the schema, invalidation policy, and how to map
persisted data into AsyncValue states; add a concrete table definition (columns:
id, currency_code, btc_rate, fetched_at, source, mostro_pubkey) and indexes for
currency_code and fetched_at, implement startup purge of rows older than 24
hours, treat entries older than 15 minutes as "stale" when used as a fallback,
and document that when loading fallback data you should return
AsyncValue.data(rates, staleness: duration) (not AsyncValue.error) while surface
an explicit staleness warning; reference the persistent cache handling around
the "exchange_rates" cache key and the AsyncValue state mapping logic so
reviewers can locate where to persist/read and apply the purge/staleness checks.
- Around line 160-164: The event handling flow that parses event.content needs
explicit error handling: when verifying pubkey (event.pubkey) and signature
(event.verify()) succeeds but JSON.parse(event.content) throws, catch the parse
error, log it with context (including event id/pubkey), do not update the
in-memory/persistent cache or notify Riverpod UI state, and instead trigger the
HTTP API fallback path to fetch/update rates; ensure the parse-failure branch is
clearly documented in the update flow and returns/flags the event as handled to
avoid crashes or duplicate processing.
- Around line 237-238: The UI currently logs an error message ("Could not fetch
exchange rates. Using cached data.") while the fallback path
self.load_from_cache() returns Ok(rates), causing a mismatch between
persistent-cache semantics and AsyncValue mapping; decide which behavior you
want and implement it consistently: either (Option A) treat cached fallback as a
successful AsyncValue.data(rates) plus a staleness flag (add a staleness
boolean/metadata on the rates and render a warning in ErrorView or replace
ErrorView with a StaleDataView), or (Option B) surface the network failure as
AsyncValue.error(err, cachedData) so the error handler (the error: (err, stack)
=> ErrorView(...) branch) can render both the error and the attached cached
rates; update the code paths around self.load_from_cache(), the AsyncValue
construction (AsyncValue.data vs AsyncValue.error), and the ErrorView usage to
reflect the chosen option so the UI message matches the actual returned
AsyncValue.
- Around line 353-374: The migration text is ambiguous about backwards
compatibility—explicitly state that the abstract ExchangeService interface
(methods getExchangeRate() and getCurrencyCodes()) must remain unchanged, add a
new NostrExchangeRateService implementation that internally attempts Nostr first
then falls back to YadioExchangeRateService and persistent cache, and confirm
Riverpod provider names/signatures (e.g. ExchangeRateNotifier,
StateNotifierProvider.family exchangeRateProvider and a
Provider<ExchangeService> exchangeServiceProvider) remain the same so the new
service is a drop‑in replacement for existing UI code.
- Line 122: The fenced code block for the architecture diagram is missing a
language identifier; update the opening fence to include one (e.g., change the
opening "```" to "```text") so the diagram lines like "ExchangeRateService (Rust
core)" and "NostrExchangeRateProvider (primary)" are rendered and recognized
correctly by tooling.

In @.specify/README.md:
- Around line 92-108: The fenced code block in .specify/README.md is missing a
language identifier which can break syntax highlighting; update the opening
fence for the directory-structure block to include a language (for example
"text") so the block becomes ```text and leave the rest unchanged — locate the
directory tree block in README.md (the triple-backtick section showing
".specify/ ├── README.md ...") and add the language identifier to the opening
fence.

---

Nitpick comments:
In @.specify/README.md:
- Around line 13-15: Add a short clarifying note in .specify/README.md near the
list that ARCHITECTURE.md, DESIGN_SYSTEM.md, and PROTOCOL.md are
planned/specs-to-be-added rather than included in this PR; update the list area
to append or precede a single-line remark like "These specification documents
are planned for future implementation and are not included in this PR" so
readers understand the referenced files are pending.
- Around line 43-49: The README currently refers to "SpecKit — the automated app
generation tool" as if it exists; update the wording to clarify SpecKit is
planned or future tooling (e.g., change "These specs are written to be consumed
by SpecKit — the automated app generation tool" to "These specs are intended for
a planned tool ('SpecKit') — an automated app generator to be added in future"),
and add a short note under the bulleted steps that SpecKit is not yet available
in this repository (and that developers should tag specs with status: ready and
run speckit generate once the tool is published).