This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass.
Outside Window is a privacy-first personal agent that helps someone take one realistic outdoor break today.
Most wellness apps turn going outside into another dashboard to manage. Outside Window takes the opposite approach: the screen should be the shortest part of the experience.
The app gives the user:
A recommended time window for today.
A short ten-minute outdoor micro-quest.
A one-tap “I went outside” or “Not today” check-in.
A local outing log that can be exported as CSV.
A learning loop that can eventually improve its recommendation from the user’s real outcomes.
The first recommendation is intentionally transparent rather than pretending to be a highly accurate model before enough personal data exists. The current demo uses a clear heuristic and records the outcome needed to train a personal model later.
The project is for people who work, study, or spend too much time online and want a gentle nudge rather than another productivity system.
Synthetic seed rows are clearly labelled and are not presented as real user behaviour or model evidence.
Repository: github.com/BOTPranav-01/outside-window
Run the local demo:
PowerShell
git clone https://github.com/BOTPranav-01/outside-window.git
cd outside-window
npm install
Copy-Item .env.example .env
npm run seed
npm run dev
Open:
Plain text
http://localhost:8787/
The demo flow is:
Load today’s recommendation.
Read the generated ten-minute quest.
Tap I went outside or Not today.
Inspect the saved event at /api/outings.
Export the user-owned log from /api/export.
The Gemma path can be enabled locally with Ollama:
ollama pull gemma3:4b
npm run dev
Without Ollama, the app uses a safe deterministic fallback quest so the core demo remains functional offline.
A deployed URL and short screen recording should be added here before publishing. Do not submit a fake URL:
Live demo: TODO — add after Render deployment
Video demo: TODO — add a 60–90 second recording
The complete open-source code is available here:
View the Outside Window repository on GitHub
The repository includes:
TypeScript Hono API
Node SQLite persistence
CSV import/export
Zod validation for model-generated quests
Open-Meteo client with coarse coordinate rounding and caching
Feature builder for time, weather, and outcome data
Python prediction sidecar
Leave-one-out evaluation against a fixed 6 PM baseline
Docker Compose configuration
Render service and worker configuration
Tests for the contracts, database, weather features, and workflow recovery
MIT license
The outing history is stored in SQLite on the machine running the app. The user can export it to CSV or import it again. There is no hosted user database in the default setup.
This makes the privacy boundary understandable:
Outing history stays local.
Synthetic seed data is explicitly labelled.
Open-Meteo receives only coarse-rounded coordinates when weather is enabled.
Gemma can run locally through Ollama.
Optional external providers are isolated behind configuration.
No raw voice recordings are stored by the application.
The micro-quest generator uses a provider adapter pointed at Ollama:
OLLAMA_BASE_URL=http://localhost:11434
OLLAMA_MODEL=gemma3:4b
The prompt asks Gemma to return only a strict JSON object containing:
quest title
one to three steps
exactly ten minutes
a safety note
The response is parsed and validated with Zod. Invalid or unavailable model output cannot silently become a success-shaped response; the application falls back to a safe deterministic quest.
This is where open innovation matters technically. The model provider can run on the user’s machine, can be swapped through environment variables, and does not require sending a personal outing history to a closed AI API.
The prediction sidecar defines the intended features:
hour
weekday
temperature
apparent temperature
precipitation probability
rain
humidity
wind
eventual outing outcome
The evaluation script compares a fixed 6 PM baseline with a leave-one-out classifier and prints a Markdown table.
The included demo dataset is synthetic and labelled as synthetic. It is only a repeatable smoke test for the evaluation pipeline. It is not evidence that the model predicts real people accurately. Real accuracy requires real user-owned observations collected over time.
The user-day workflow stores its state locally and has a recovery test that simulates a worker restart without duplicating the user-day state.
The next production integration is Temporal: the same state machine will compute a window, sleep durably, send a nudge, wait up to 45 minutes for a check-in, record the outcome, and trigger a refit.
I kept that distinction explicit rather than claiming a local state test is already Temporal Cloud.
A closed wellness assistant could produce a polished recommendation, but the user would have little ability to inspect or own the system making decisions about their daily behaviour.
Open innovation makes several things possible here:
Local inference: Gemma can run offline through Ollama.
Model choice: the provider can be swapped without rewriting the application.
Inspectable features: the recommendation inputs are visible rather than hidden.
User-owned history: SQLite and CSV make the outing log portable.
Honest evaluation: the fixed 6 PM baseline is included instead of reporting only a model score.
Community improvement: the feature builder, validator, and workflow state are open to review and extension.
The project is intentionally modest about what it knows. It does not claim that a model can solve motivation. It creates a small feedback loop that respects the user and improves only when the user supplies real outcomes.
This section is optional. Add the public DevRelay session link after saving and making the session public.
TODO — add public DevRelay agent session link
I used AI assistance during implementation and will disclose that accurately in the DEV article settings.
I am entering the Gemma category only when the submitted demo runs Gemma locally through Ollama. Gemma generates the structured ten-minute quest, and the application validates the output before showing it to the user.
I am not claiming categories for integrations that are only configuration placeholders.
This is a new project built during the Week 1 challenge window.
Current limitations:
The recommendation is still a transparent demo heuristic.
The included evaluation rows are synthetic and cannot demonstrate real-world accuracy.
The real TabPFN integration is not yet claimed.
Temporal Cloud orchestration is not yet claimed.
ElevenLabs audio is not yet claimed.
Sentry tracing is not yet claimed.
A public Render deployment still needs to be added before submission.
Voice check-in is planned but not part of the current validated demo.
These limitations are deliberate. The goal is to show what works, identify what remains, and avoid presenting scaffolding as a finished integration.
Built with TypeScript, Hono, Node SQLite, Zod, Vitest, Python, FastAPI, Open-Meteo, Ollama/Gemma, Docker, and Render configuration.
The project is MIT licensed. No non-trivial borrowed code is included without attribution.
AI tools assisted with implementation. The repository, application structure, tests, documentation, and integration decisions were created for this challenge project.