Z3R4H: Windows offline launcher, wrapper scaffold, geo services, UI rebrand & prompt stack#6
Conversation
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: a279355dfc
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| route_area = form_data.route_area.model_dump() if form_data.route_area else None | ||
| constraints = form_data.constraints.model_dump(exclude_none=True) if form_data.constraints else None | ||
|
|
||
| if query_type == 'camp': |
There was a problem hiding this comment.
Validate site-search location inputs before scoring
The /api/geo/site-search handler forwards requests to find_* scoring without checking that either coordinates or route_area is present, but _resolve_center raises ValueError when both are missing. Because this endpoint does not catch that exception, a malformed request gets a 500 instead of a client error, which makes the API contract brittle for callers and UI retries.
Useful? React with 👍 / 👎.
| data = await client.route(form_data.model_dump(exclude_none=True)) | ||
| if include_terrain and ENABLE_TERRAIN_ANALYSIS: | ||
| metrics = extract_route_metrics(data) | ||
| slope_profile = compute_slope_profile(metrics['elevations_m']) |
There was a problem hiding this comment.
Use computed sample distance in terrain slope analysis
Route terrain analysis computes slopes with the default 30m spacing even though extract_route_metrics already derives sample_distance_m from the decoded route geometry. On routes with sparse geometry points, this inflates slope percentages and can misclassify difficulty/risk in /api/geo/route?include_terrain=true responses.
Useful? React with 👍 / 👎.
| if ((int)res.StatusCode >= 200 && (int)res.StatusCode < 500) | ||
| { | ||
| return (true, $"{label} readiness endpoint reachable: {endpoint}"); |
There was a problem hiding this comment.
Restrict readiness success to healthy HTTP status codes
The readiness probe currently treats any response below 500 as "ready," so 4xx responses (for example, wrong health path returning 404) are accepted as successful startup checks. That can let orchestration proceed and launch the browser even when backend/AI/routing health endpoints are misconfigured or unavailable from a client perspective.
Useful? React with 👍 / 👎.
Motivation
.exe-first wrapper to improve operator UX and failover to the BAT fallback.Description
PROJECT_BRIEF.md,TASKS.md,Z3R4H_CLEAN_ENV_CHECKLIST.md, andZ3R4H_PROGRESS_SUMMARY.mdfor scope, tasks and RC validation workflows.launch_z3r4h.batand runtime configruntime/runtime_config.envplus helper scripts underruntime/to start bundled or fallback runtimes (start_backend.bat,start_valhalla.bat,build_backend_exe.bat).wrapper/(Program.cs,ConfigResolver,RuntimeOrchestrator,ReadinessProbe,BatFallback,StartupScreen, logging and config types) implementing package-root resolution, dual-service orchestration, readiness probing, structured exit codes and BAT fallback hooks (Task 19–25 milestones).backend/open_webui/services/geo/includingvalhalla_client.py,dem_loader.py,terrain_service.py,suitability_service.py,ai_geo_orchestrator.py, and pydanticschemas.py, plusconfig.pyfeature flags and health checks; wiredrouters/geo.pyintomain.pyat/api/geo.src/lib/constants.ts,app.html, site manifests and search descriptors; added mode selector UI (Z3R4HModeSelector.svelte), mode-aware prompt stack and model routing utilities (z3r4hPromptStack.ts,z3r4hModeRouting.ts), and integrated mode storage and prompt composition into chat flows (Chat.svelte,Navbar.svelte,Channel.svelte).GeoAdvisor.svelte,RouteResultCard.svelte,SiteResultCard.svelteand wiring atsrc/routes/(app)/maps/+page.svelteplus Svelte storesrc/lib/stores/geo.tsand client-side integration for/api/geoendpoints.src/lib/prompts/z3r4h/includingcore_system.txt,failure_behavior.txtand per-mode prompts for the Z3R4H modes.backend/open_webui/test/geo/test_geo_endpoints_and_services.py, frontend unit/contract testssrc/lib/components/map/__tests__/maps_flow.spec.ts, and wrapper contract testswrapper/tests/test_wrapper_startup_contract.pyto codify expected behaviors and interfaces.Testing
backend/open_webui/test/geo/test_geo_endpoints_and_services.pywhich exercises geo endpoints, DEM fallback behavior, suitability scoring, and intent classification.src/lib/components/map/__tests__/maps_flow.spec.ts(Vitest) to assert UI contract hooks for the geo components, and wrapper tests:wrapper/tests/test_wrapper_startup_contract.pyto assert startup orchestration text/paths for the wrapper scaffold.Codex Task