fix(quick-router): "will it rain tomorrow" asks for current weather, not the forecast

[kai392]

Fixes #912.

Root cause

weather_request has two branches and they disagreed about the forecast flag.

The general weather/forecast branch derives it from the utterance:

let forecast = text.contains("forecast")
    || text.contains("tomorrow")
    || text.contains("week")
    || text.contains("7 day")
    || text.contains("seven day");

The "is it rain…" / "will it rain…" branch above it never computes anything —
all four of its return paths hardcode false.

forecast is what selects the 7-day forecast over a right-now reading (per the
tool schema: "true for 7-day forecast, false for current weather"), so a
question about a future day was answered with the current sky. Which answer you
got depended only on which verb you used:

"What's the weather in Denver tomorrow?" -> forecast: true
"Will it rain in Denver tomorrow?"       -> forecast: false

Fix

Lift the existing predicate into asks_for_forecast and call it from both
branches.

No new semantics — the rule is exactly the one the general branch already
applied, now shared instead of duplicated-then-forgotten. That also means the
two branches cannot drift apart again.

Impact

Future-day rain questions ask Home Assistant for the forecast instead of current
conditions. Present-tense questions are unchanged. The two phrasings of the same
question now resolve identically — the new test asserts that directly by routing
both and comparing.

Risk / tradeoffs

Low. The only behavior change is forecast: false -> true on rain utterances
containing forecast/tomorrow/week/7 day/seven day; everything else
keeps its current value, and neither branch's location handling is touched.

Worth naming: the shared rule is still a keyword list, so "will it rain in a month" stays forecast: false — a real gap, but a pre-existing one that the
general branch has too, and widening the keyword set is a separate change from
making the two branches agree. The existing
rain_query_time_expression_is_not_a_location test pins that utterance's
location, and this PR leaves its forecast value as it was.

Real Behavior Proof

• I have built and run the affected code locally (or noted why I could not).
• I have NOT verified on Jetson hardware, and I explain the equivalent verification path or validation gap below.

Tested profile / hardware:

• laptop (Windows host — see the gap note below)
• CI-only / docs-only

What I ran

I do not have a Jetson, and genie-core does not build on my Windows host
(libc::gmtime_r, tokio::signal::unix and friends are Unix-only), so the
routing change was exercised two ways.

1. Direct route() calls. I compiled the four quick-router source files
unmodified — crates/genie-core/src/tools/{quick,home_action,calc_input,number_words}.rs,
included by #[path], with only ToolCall and HomeActionKind stubbed — into a
throwaway binary and called tools::quick::route() directly. No logic was
copied or reimplemented.

2. cargo test -p genie-core on Linux via GitHub Actions, plus the rest of
the matrix (cargo fmt, cargo clippy -D warnings, --no-default-features,
and the aarch64-unknown-linux-gnu release build), run on this exact commit
before opening this PR: kai392#5 — all green.

test tools::quick::tests::rain_query_asks_for_the_forecast_when_the_question_is_about_a_future_day ... ok
test result: ok. 902 passed; 0 failed; 6 ignored; 0 measured; 0 filtered out

The pre-existing rain_query_keeps_named_city and
rain_query_time_expression_is_not_a_location tests still pass; both assert
location only, so the forecast flag was previously unpinned in either branch.

What I observed

Before, on main @ 02a577d:

"Will it rain tomorrow?"                -> get_weather {"location":"home","forecast":false}
"Will it rain next week?"               -> get_weather {"location":"home","forecast":false}
"Will it rain in Seattle tomorrow?"     -> get_weather {"location":"seattle","forecast":false}
"Will it rain in New York this weekend" -> get_weather {"location":"new york","forecast":false}
"Is it raining tomorrow"                -> get_weather {"location":"home","forecast":false}

After, same harness, same build:

"Will it rain tomorrow?"                -> get_weather {"location":"home","forecast":true}
"Will it rain next week?"               -> get_weather {"location":"home","forecast":true}
"Will it rain in Seattle tomorrow?"     -> get_weather {"location":"seattle","forecast":true}
"Will it rain in New York this weekend" -> get_weather {"location":"new york","forecast":true}
"Is it raining tomorrow"                -> get_weather {"location":"home","forecast":true}

"Is it raining?"                        -> get_weather {"location":"home","forecast":false}
"Is it raining in Denver"               -> get_weather {"location":"denver","forecast":false}
"Will it rain this afternoon?"          -> get_weather {"location":"home","forecast":false}
"Will it rain in the morning"           -> get_weather {"location":"home","forecast":false}
"Jared: Is it raining for school pickup?" -> get_weather {"location":"home","forecast":false}

"Will it rain in Denver tomorrow"       -> get_weather {"location":"denver","forecast":true}
"What's the weather in Denver tomorrow" -> get_weather {"location":"denver","forecast":true}

Validation gap

The routing half is fully covered above. What I could not verify is that the
downstream get_weather execution actually returns tomorrow's forecast for
forecast: true against a live provider — that needs network and the configured
weather backend on device. crates/genie-core/src/tools/weather.rs is the path a
maintainer would exercise to confirm it end to end.

Summary by CodeRabbit

• Bug Fixes
  • Improved weather and rain-query handling for future conditions, including forecasts for tomorrow, the week ahead, and seven-day periods.
  • Weather requests now more consistently distinguish current conditions from forecast requests.
  • Fixed school-pickup rain queries so they preserve the correct forecast context.
  • Improved consistency between rain and general weather requests when identifying forecast periods and locations.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: e10daed1-6e3d-46a0-8d14-13cc0bcefad4

📥 Commits

Reviewing files that changed from the base of the PR and between 02a577d and e7997f1.

📒 Files selected for processing (1)

• crates/genie-core/src/tools/quick.rs

---

📝 Walkthrough

Walkthrough

The quick weather router now shares forecast detection between rain and general weather queries. Future-day rain requests set forecast: true, current-condition requests remain false, and tests verify consistent forecast and location values across both routing paths.

Changes

Weather forecast routing

Layer / File(s)	Summary
Shared forecast detection and routing crates/genie-core/src/tools/quick.rs	Adds asks_for_forecast and applies its result to rain and general weather routing, including the school-pickup special case.
Forecast routing tests crates/genie-core/src/tools/quick.rs	Tests future-day and current rain queries and verifies agreement between rain and general weather routes.

Estimated code review effort: 2 (Simple) | ~10 minutes

Possibly related PRs

• GeniePod/genie-claw#809: Updates the same weather router’s interpretation of forecast and location fields.
• GeniePod/genie-claw#860: Modifies related weather-routing heuristics in quick.rs.
• GeniePod/genie-claw#868: Adjusts related weather time-expression routing logic.

Suggested reviewers: matedev01, jeffrey701, yurii214

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title matches the bug being fixed and clearly points to the quick-router weather/forecast mismatch.
Linked Issues check	✅ Passed	The changes implement #912 by sharing the forecast predicate, fixing future rain queries, and preserving current-weather and location behavior.
Out of Scope Changes check	✅ Passed	The diff appears limited to the routing fix and related tests, with no unrelated behavior or public API changes.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

_{Comment @coderabbitai help to get the list of available commands.}