Battry

Battry turns messy daily experiences into structured energy data.

The current loop is simple:

write a log -> parse events -> update battery -> show recent patterns

It's not tryna to be a journal, habit tracker, or therapy tool. Right now it is a small logging and scoring system with a mobile shell around it.

What Works Now

• Submit a text log from the Expo app.
• Parse simple phrases like bad sleep, small talk, doomscroll, quiet time, and music.
• Convert those phrases into structured up / down events.
• Calculate battery_before and battery_after.
• Keep logs in memory when no database is configured.
• Store logs and parsed events in Supabase Postgres when SUPABASE_DATABASE_URL is set.
• Create a private anonymous Supabase Auth session for each device.
• Fetch recent logs for the signed-in user.
• Build a basic weekly report with average/min/max battery, top drainer, top recharger, and a simple risk label.

Current Stack

• Mobile: Expo, React Native, TypeScript
• Backend: Python, FastAPI, Pydantic
• Persistence: in-memory fallback or Supabase Postgres
• Local server: Uvicorn

Code Map

• backend/app/main.py creates the FastAPI app, configures CORS, and mounts routes.
• backend/app/api/ contains HTTP route handlers. These should stay thin.
• backend/app/core/ contains cross-cutting setup like env config and auth.
• backend/app/schemas/ contains Pydantic request/response models.
• backend/app/services/parser_service.py turns log text into labels.
• backend/app/services/battery_service.py turns labels into battery scores.
• backend/app/services/log_repository.py hides the in-memory vs Postgres storage choice.
• backend/app/services/report_service.py calculates weekly report data.
• mobile/App.tsx owns auth state, loaded data, screen switching, and submit/refresh flows.
• mobile/src/api/client.ts is the only mobile file that should call the backend directly.
• mobile/src/auth/supabase.ts creates the Supabase mobile auth client.
• mobile/src/screens/ contains presentational screens that receive data and callbacks.

Backend Setup

Create a virtualenv:

python3 -m venv venv
source venv/bin/activate

Install dependencies:

python3 -m pip install -r requirements.txt

Run the API from the repo root:

python -m uvicorn backend.app.main:app --reload

The backend defaults to:

http://127.0.0.1:8000

Backend Endpoints

Health check:

curl http://127.0.0.1:8000/api/health

Create a log:

curl -X POST http://127.0.0.1:8000/logs \
  -H "Authorization: Bearer $SUPABASE_ACCESS_TOKEN" \
  -H 'Content-Type: application/json' \
  -d '{
    "text": "bad sleep and small talk",
    "logged_at": "2026-04-27T09:00:00Z"
  }'

List logs:

curl -H "Authorization: Bearer $SUPABASE_ACCESS_TOKEN" \
  'http://127.0.0.1:8000/logs'

Get the weekly report:

curl -H "Authorization: Bearer $SUPABASE_ACCESS_TOKEN" \
  'http://127.0.0.1:8000/report/weekly'

Database Mode

The backend has two storage modes:

• No SUPABASE_DATABASE_URL: logs live in memory and reset when the server restarts.
• With SUPABASE_DATABASE_URL: logs and parsed events are written to Supabase Postgres.

Copy the env template when you want persistence:

cp .env.example .env

Then fill in:

SUPABASE_DATABASE_URL=postgresql://...

Run the SQL migration in:

supabase/migrations/202604260001_initial_battry_schema.sql

Auth is wired through Supabase anonymous sign-in. The mobile app creates a private device session without asking for an email or password, signs requests with that bearer token, and the backend derives the randomized Supabase user UUID from the token.

Anonymous sign-in must be enabled in the Supabase Auth settings for the mobile app to create private device identities.

Before enabling it publicly:

• Run supabase/migrations/202605010001_harden_rls_for_anonymous_auth.sql.
• Keep Supabase anonymous sign-in rate limits conservative.
• Keep backend API rate limiting enabled so one anonymous device cannot spam /logs.

Mobile Setup

Install the mobile dependencies:

cd mobile
npm install
cp .env.example .env

Run Expo:

npm run ios

or:

npm start

The mobile app uses:

http://127.0.0.1:8000

by default. Override it with:

EXPO_PUBLIC_API_URL=http://127.0.0.1:8000 npm start

Future Plans

This is still pretty early and plain

What needs to be done:

• backend API rate limiting
• vector parsing
• ML forecasting
• polished charts
• the final Mercury Cell UI

I think making sure the core is tight is the priority then adding the ML features and UX buffs