Skip to content

Z3R4H: Windows offline launcher, wrapper scaffold, geo services, UI rebrand & prompt stack#6

Open
RadDad87 wants to merge 1 commit into
mainfrom
codex/propose-plan-for-windows-launcher-implementation-62wupe
Open

Z3R4H: Windows offline launcher, wrapper scaffold, geo services, UI rebrand & prompt stack#6
RadDad87 wants to merge 1 commit into
mainfrom
codex/propose-plan-for-windows-launcher-implementation-62wupe

Conversation

@RadDad87

Copy link
Copy Markdown
Owner

Motivation

  • Provide a Windows-first, fully offline local product path (Z3R4H) that launches Open WebUI against local llama.cpp/Valhalla runtimes and emphasizes offline survival usage.
  • Harden startup on clean Windows machines with a portable BAT launcher and a planned .exe-first wrapper to improve operator UX and failover to the BAT fallback.
  • Add local terrain/routing/geospatial tooling (Valhalla client, DEM sampling, terrain analysis, suitability scoring) and a geo advisor UI to support Navigation & Terrain mode.
  • Introduce Z3R4H branding, mode-driven prompt stack, and deterministic mode→model routing for offline mode-specific behavior.

Description

  • Added documentation and planning artifacts including PROJECT_BRIEF.md, TASKS.md, Z3R4H_CLEAN_ENV_CHECKLIST.md, and Z3R4H_PROGRESS_SUMMARY.md for scope, tasks and RC validation workflows.
  • Implemented a portable Windows launcher launch_z3r4h.bat and runtime config runtime/runtime_config.env plus helper scripts under runtime/ to start bundled or fallback runtimes (start_backend.bat, start_valhalla.bat, build_backend_exe.bat).
  • Added a native C#/.NET wrapper scaffold under 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: added a geo router and services under backend/open_webui/services/geo/ including valhalla_client.py, dem_loader.py, terrain_service.py, suitability_service.py, ai_geo_orchestrator.py, and pydantic schemas.py, plus config.py feature flags and health checks; wired routers/geo.py into main.py at /api/geo.
  • Frontend/UI: rebranded app strings and manifests to Z3R4H in 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).
  • Geo UI: implemented a maps page and components GeoAdvisor.svelte, RouteResultCard.svelte, SiteResultCard.svelte and wiring at src/routes/(app)/maps/+page.svelte plus Svelte store src/lib/stores/geo.ts and client-side integration for /api/geo endpoints.
  • Prompts and modes: added core system prompt and mode-specific prompts under src/lib/prompts/z3r4h/ including core_system.txt, failure_behavior.txt and per-mode prompts for the Z3R4H modes.
  • Tests and contracts: added backend pytest tests backend/open_webui/test/geo/test_geo_endpoints_and_services.py, frontend unit/contract tests src/lib/components/map/__tests__/maps_flow.spec.ts, and wrapper contract tests wrapper/tests/test_wrapper_startup_contract.py to codify expected behaviors and interfaces.

Testing

  • No automated test execution was performed as part of this change; the patch adds automated tests prepared for CI but did not run them here.
  • Added backend tests: backend/open_webui/test/geo/test_geo_endpoints_and_services.py which exercises geo endpoints, DEM fallback behavior, suitability scoring, and intent classification.
  • Added frontend tests: 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.py to assert startup orchestration text/paths for the wrapper scaffold.

Codex Task

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 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':

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge 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'])

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge 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 👍 / 👎.

Comment on lines +34 to +36
if ((int)res.StatusCode >= 200 && (int)res.StatusCode < 500)
{
return (true, $"{label} readiness endpoint reachable: {endpoint}");

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Badge 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 👍 / 👎.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant