DEV Community: Jesus Chetia

StorySteps: an offline atlas for the stories attached to places

Jesus Chetia — Sat, 10 Oct 2026 17:46:09 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass

Here is the scene this is built for.

You are standing at a set of worn stone steps behind the old post office. Someone who grew up here tells you her grandmother cut through them on the way to the market, and that the treads are smooth on one side only. Two years from now that detail exists in your phone and nowhere else, and in four years it may exist nowhere at all.

StorySteps is a PWA for collecting exactly that, and then getting out of the way. Open the app, press record (after asking the person in front of you, which the app reminds you about), speak for a minute, stop. Transcribe it, fix the two words the model got wrong, save. The memory now has a place, a date you recorded it, a date it reportedly happened, a transcript, and the original audio. Then you put the phone back in your pocket and keep walking.

No account. No server. No sync. The models run on the device.

What I Built

A field session is a walk. You name it, and every memory recorded during it belongs to that walk, so the archive reads as a sequence of outings rather than a pile of loose notes.

Each memory carries more than a note. It has a category (oral history, natural feature, local tradition, environmental change, observation, built heritage), a source (firsthand, recollection, observation, supplied reference) and a verification status that is yours to set, never the model's.

The two dates are deliberately separate, and this is the part I care about most:

recorded: when you captured it. Always known.
event date: when it supposedly happened. Often vague, so it accepts 1998, 1998-04 or 1998-04-12 and stores the precision alongside it, so a year never silently pretends to be a day.

If the speaker said "sometime in the seventies", the event date is 1970s-ish vague and stays vague. The app will not sharpen it for you.

The map shows every placed memory with a marker coloured by category, a legend, filters, and a results list that stays in sync with it. Location is only requested when you press the button, and anything you type or pick by hand is stored as an estimate, labelled as an estimate, never as a device reading.

The timeline is per place. It puts recorded dates next to remembered event dates so the gap between when you heard it and when it happened is visible instead of hidden.

Export and import exist because the archive should be yours. Export writes a versioned JSON file, with audio as an explicit opt-in because base64 makes it enormous. Import validates every field and the schema version before a single row is written, shows you how many records are new and how many already exist, and applies the whole thing in one transaction, so a malformed file leaves your archive exactly as it was.

Screenshots:

What it refuses to do

It never invents a transcript. Short or silent recordings are rejected with a reason instead.
It never marks model output as verified history. Extraction produces suggestions you must accept.
It never sends a transcript, a recording or a coordinate anywhere.
It never claims a model is ready when it is not.

Demo

Live demo: https://storysteps.onrender.com

Code

greenbugx / StorySteps

Every place has a story. Go outside and find it.

StorySteps

Every place has a story. Go outside and find it.

StorySteps turns walks, conversations and observations into an atlas of local memories: oral histories, disappearing landmarks, local traditions and environmental change. You record a note or a conversation, and it becomes an archive record attached to a place and a date.

Everything stays on your device. There is no account, no server, no analytics and no remote AI. The models that transcribe and structure your notes run in your own browser.

The problem

Local knowledge is fragile. A village elder describes where the old crossing used to be, a mason explains which stones were reused from the railway station, someone notices the last banyan at a crossing is gone. Most of it is written down in a notebook, or not at all, and within a few years the details are gone with the people who held them.

StorySteps is…

View on GitHub

React 19, Vite, TypeScript, Tailwind v4, Dexie over IndexedDB, Leaflet, LiteRT-LM, Transformers.js, Zod, vite-plugin-pwa, and 29 tests. pnpm install && pnpm run dev and it runs, with no API key and no environment file.

How I Built It

Two open models, both inside the browser:

Model	Size	How it runs	Fetched when
Whisper base, quantised ONNX	about 76 MB, plus about 26 MB for the ONNX runtime	Transformers.js in a Web Worker, WebGPU when a real adapter answers, WASM otherwise	first time you press Transcribe
Gemma 4 E2B, web build	about 1.9 GB	LiteRT-LM on the main thread	when you press Download model in Settings

flowchart TD
    A[Walk and conversation] --> B{Input}
    B -->|Typed note| C[Original text]
    B -->|Audio| D[Whisper in a worker]
    D --> E[Transcript, audio kept]
    C --> F[Gemma extracts fields]
    E --> F
    F --> G[Zod validation]
    G --> H{A human accepts it?}
    H -->|Yes| I[Dexie and IndexedDB]
    I --> J[Archive, timeline, map marker]

Whisper runs in a worker, and the audio never enters React state

MediaRecorder writes chunks straight into IndexedDB as blobs. The blob is decoded and resampled to 16 kHz mono, checked for length and for actual silence, and only then handed to the worker. Silence and near-silence are rejected before the model is invoked, because there is no point spending 76 MB and 13 seconds to learn that nothing was said. My own fake-microphone test recording tripped that guard, which is the nicest possible confirmation that it works.

The worker reports download progress, so the first run tells you it is fetching about 76 MB rather than appearing to hang.

Gemma streams, because 1.9 GB will not fit twice

The obvious way to use Gemma is to hand LiteRT-LM a URL, but that means a 1.9 GB download every session and no offline use. Instead the download is streamed through a TransformStream into the Cache API, with progress and a cancel, and the engine is handed cache.match(...) as a stream. The browser never holds two copies in memory, a reload costs nothing, and the app has no way to reach for the network on a later run.

The runtimes are served from this origin, not a CDN

LiteRT-LM and onnxruntime-web both default to fetching their WASM from jsDelivr. That would quietly break local AI the moment the signal drops, which is the one thing this app cannot afford. A small Vite plugin copies both runtimes out of node_modules at build time and serves them from /runtime/litert and /runtime/ort, where the service worker caches them on first use.

The schema refuses sloppy data

Partial dates are validated as real dates, 1998-13 is rejected, coordinates must appear as a pair or not at all, and an event date's declared precision has to match its own length. That last one sounds fussy until you remember that a year and a day look identical in a string, and a database full of fake precision is worse than one full of honest gaps.

Bugs I hit along the way

Whisper died on WebGPU with webgpuInit is not a function. I had pointed onnxruntime at the ort-wasm-simd-threaded.jsep factory. In the version installed here, WebGPU has moved out of jsep, so the runtime asked the module for an entry point it does not define, then reported that no backend was available:

asyncify.mjs -> 1   (webgpuInit)
jspi.mjs     -> 1
jsep.mjs     -> 0   <-- what I was loading
plain .mjs   -> 0

Repointing at asyncify fixed it, and WebGPU transcription now runs with a real adapter. There is now a test that fails if that factory ever stops exporting webgpuInit, because I verified it catches the original bug by reintroducing it.

Offline, the app quietly lost its typography. The service worker precached js, css, html and svg but not woff2, so with no connection the headings fell back to system serif. Nothing errored, it just looked wrong. Fonts are precached now, 18 entries and 1.74 MB, and I check it by reading the computed font family on an offline reload.

The map rendered inside a fraction of its own box. leaflet.css was never imported, so panes and tiles had no size rules and the map drew into about a quarter of its container with the rest blank. It looked like a tile outage, which is exactly what it was not.

The onboarding gate fought the router. A flag read on first render redirected to the welcome page after you had already left it, because the state was initialised as "not done" instead of "not known yet". Small bug, immediate bounce.

Selects displayed raw values like observation instead of Observation, because the component needs its item labels declared. Every control now has an accessible name, which I checked by walking all five routes and asserting no button, link or input is nameless.

Why Does Open Innovation Matter?

Because of what the data is.

An oral history with coordinates attached is not something you want sitting on a server you do not control, especially when the people in it never agreed to that. With a closed API, every transcript, every recording and every location would leave the device, there would be a per-token bill attached to a hobby that happens on a walk, and the entire thing would die the moment the signal does.

Open weights meant the models are a detail rather than a dependency. I could build the part that actually matters, the quiet collecting and the honest archive, and let the AI sit behind a toggle that is off by default.

It also meant I could go and read what onnxruntime actually ships. The bug above was not a support ticket or a vague "model sometimes does not work", it was a grep away, and the fix was mine to make. Being able to read the runtime is half the value of it being open.

Both models ran on my machine with a real WebGPU adapter, and Whisper also on the WASM fallback, producing the same transcript either way. It also transcribed with every non-localhost request blocked, which is the proof that it needs no network.

My Agent Session

StorySteps: Building a Local-First Memory Atlas in the Browser

You

Build StorySteps, a privacy-first offline-first PWA that turns walks, conversations and observations into an atlas of local memories. (Full 500 line specification abridged here.) Hard rules: no backend, no account, no API key, no analytics, no em dashes in any file, do not scaffold a new project or replace the package manager, do not commit or stage anything, and never fake a capability. Model inference and transcription must run locally; map tiles may need the network. Ship a README with honest claims about what was actually tested.

Agent

Repository audit first, before any edits. Node 26.7.0, pnpm 11.3.0, Vite 8, React 19, Tailwind v4, shadcn/ui on Base UI. The template shipped Dexie, Leaflet, LiteRT-LM and Transformers.js but no tests, no router and a bare counter page.

▸ bash pnpm run build && pnpm run lint

Input

$ pnpm run build && pnpm run lint

Output

build clean; lint failed with 3 pre-existing react-refresh errors in ui/badge.tsx, ui/button.tsx and ui/tabs.tsx. Recorded as baseline so they are not misattributed later.

Agent

Data model first, since everything else depends on it. Partial event dates need explicit precision, otherwise a year and a day look identical to the schema. Coordinates are nullable but must appear as a pair.

▸ write src/lib/validation/schemas.ts

Input

src/lib/validation/schemas.ts

Output

memoryRecordSchema with partialDateSchema (YYYY, YYYY-MM, YYYY-MM-DD), latitude and longitude range checks, a refinement that rejects a half-filled coordinate pair, and a refinement tying eventDatePrecision to the actual date length.

Agent

Dexie with two versions: v1 plus a v2 upgrade that backfills the fields added during the build, so an early archive survives. Audio is a separate table so metadata queries never drag blobs through.

▸ write src/lib/db/database.ts

Input

src/lib/db/database.ts

Output

Database class extends Dexie; version(2).upgrade() backfills eventDatePrecision, eventDateUncertain, locationPrecision, needsCorroboration and fieldSessionId on existing rows.

Agent

Local AI is the part most likely to quietly lie, so it got the most scrutiny. Gemma 4 E2B is 1.9 GB, which is far too big to hold twice in memory, so the model streams into the Cache API and is handed to LiteRT-LM as a stream.

▸ bash curl -sIL on the gemma-4-E2B-it-web.litertlm resolve URL

Input

$ curl -sIL on the gemma-4-E2B-it-web.litertlm resolve URL

Output

content-length: 2008432640 (1.87 GiB), ungated, public.

Agent

The LiteRT-LM and ONNX runtimes load their WASM from a CDN by default, which would break local AI offline and send a request to a third party. A small Vite plugin copies both runtimes out of node_modules and serves them from this origin under /runtime/litert and /runtime/ort.

Agent

Verification was browser-driven wherever possible, because the acceptance criteria are behavioural. Typed memories, search, editing, deletion, export and import were exercised through the real UI.

▸ browser fill Title and Original note, press Save memory

Input

fill Title and Original note, press Save memory

Output

redirected to the new memory route with the record rendered; persisted across reload; empty title and an impossible date (1998-13) both blocked save with a specific message.

You

no available backend found. ERR: [webgpu] TypeError: j(...).webgpuInit is not a function when I press Transcribe on the Device

Agent

That is a real bug and it is mine. The WebGPU path pointed at the ort-wasm-simd-threaded.jsep factory. In the onnxruntime-web version installed here, WebGPU has moved out of jsep, so the runtime called a function the factory never defines, then reported no backend at all.

▸ bash grep -c webgpuInit onnxruntime-web/dist/ort-wasm-simd-threaded.*.mjs

Input

$ grep -c webgpuInit onnxruntime-web/dist/ort-wasm-simd-threaded.*.mjs

Output

asyncify.mjs -> 1, jspi.mjs -> 1, jsep.mjs -> 0, plain .mjs -> 0. The asyncify factory carries webgpuInit and is also what Transformers.js defaults to.

Agent

Fixed the paths, dropped the unusable 28 MB jsep pair from the build, and added a one-shot fallback so a WebGPU failure lands on WASM with an honest message instead of a dead end. Added a regression test that asserts the configured factory really exports webgpuInit.

▸ vitest revert the fix, run src/lib/ai/ortAssets.test.ts

Input

revert the fix, run src/lib/ai/ortAssets.test.ts

Output

x points at a factory that exposes the webgpu entry point -- expected 'async function ortWasmThreaded' to contain 'webgpuInit'. The test reproduces the original bug.

Agent

Whisper was proven on the real model rather than mocked: an 11 second speech sample transcribed correctly in about 13 seconds including the first download, and about 3 seconds once cached. Re-running with every non-localhost request blocked produced the same transcript, which is the evidence that it works offline.

▸ browser transcribe a fetched speech sample through the transcriber module

Input

transcribe a fetched speech sample through the transcriber module

Output

{ status: 'transcribed', device: 'wasm', text: 'And so my fellow Americans ask not what your country can do for you, ask what you can do for your country.' } A synthetic silent WAV returned { status: 'rejected', reason: 'That recording is silent.' } rather than a fabricated transcript.

You

change the project name to StorySteps please

Agent

Renamed the product name everywhere, and the identifiers too, not just the strings: the IndexedDB name, the Dexie class, the archive format id and export filename, both Cache API names, the manifest name and the icon files. Flagged the two real consequences: an archive exported under the old format string no longer imports, and a browser profile with old data starts empty.

You

please add MIT license to the project please

Agent

Adding MIT surfaced a problem worth deciding out loud: react-leaflet 5.0.0 is not MIT, it is Hippocratic License 2.1, which adds a termination clause, arbitration and an indemnity and binds users to human rights compliance. Leaflet itself is BSD-2-Clause. Asked whether to keep it and document the exception, or drop it for a hand written Leaflet wrapper. The author chose to keep it, so the README states the exception plainly and names the single file that would have to change for a purely MIT dependency set.

Agent

Final pass found a real offline defect: the service worker precached js, css, html and svg but not woff2, so offline the display face silently fell back to system serif. Fonts are precached now (18 entries, 1.74 MB), verified by resolving getComputedStyle on an offline reload.

Agent

What I would tell someone considering this build: everything except Gemma inference is verified in a real browser, the map tile layer genuinely needs the internet, and browser storage is neither encrypted nor durable. Gemma is implemented and its runtime loads, but the test browser returns a null WebGPU adapter, so the 1.9 GB download, generation and the extraction review screen are unproven on real hardware and the README says so.

Prize Categories

Best Use of Gemma
Best Use of Render

What if your journal could understand you? So I built DayBook

Jesus Chetia — Sun, 04 Oct 2026 21:33:51 +0000

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend

This is a team submission
Teammate - @piyushnextgen

What We Built

Daybook began with a simple problem: a friend of ours who was already journaling, but most of the time, the entries just stayed there.

He could write about a stressful day, a productive week, a bad habit, or something that kept coming up, but noticing those patterns across dozens of entries was almost impossible manually.

So we built Daybook for him.

Daybook is a private AI journal that reads your entries locally and helps surface patterns in your habits, mood, routines, and thoughts over time. Instead of just storing what you write, it helps you understand what keeps showing up.

The important part is where this happens.

Your journal never needs to leave your device. Daybook uses a local LLM, so the AI can work with your personal entries without sending them to a cloud AI service.

We wanted to build something that was genuinely useful to one person, while also answering a question we kept coming back to:

Can AI be helpful with something as personal as journaling without requiring you to give away your data?

Daybook is our attempt at an answer.

Demo

DayBook UI Demo

Note: Local AI features are not available in the deployed demo because DayBook runs AI locally using Ollama. The backend requires a running Ollama instance on port 11434.

Video Demo

Code

greenbugx / Daybook

A private AI journal that learns your habits, finds patterns, and helps you improve, powered by a local LLM with your data staying on-device.

A local-first AI journal that learns your habits, finds recurring patterns, and helps you reflect on what you could improve

Everything happens on your own machine. Your writing never leaves your computer, and the AI that reads it runs locally through Ollama, so there is no account to create, no key to paste, and no company holding a copy of your thoughts.

Screenshots

Home	Journal Spread

Analytics	Goals

Calendar	Library

What DayBook Does

DayBook is built around a few simple habits that turn into something useful over time.

Write a page a day. Each date has one journal entry with a topic…

View on GitHub

How We Built It

We wanted Daybook to be useful with genuinely personal data, which made the usual "send it to an AI API" approach feel wrong for this project.

So we built it local-first from the beginning.

At the core is Gemma 3 4B, an open-weight model running locally through Ollama. There is no OpenAI API, Gemini API, or hosted AI service sitting between the journal and the model.

The whole stack lives on the user's machine:

flowchart LR
    U["You, in a browser"] -->|"localhost:5173"| V["Vite dev server"]
    V -->|"React app"| U
    V -->|"proxies /api to 3001"| B["Fastify backend"]
    B -->|"SQL, WAL mode"| D[("SQLite<br/>data/daybook.db")]
    B -->|"local HTTP"| O["Ollama"]
    O --> G["Gemma 3 4B"]

The frontend is built with React 19 and TypeScript, while the local backend handles application logic and communication with Ollama. Journal data and personal memories are stored locally using SQLite.

That separation was intentional. The application can use an LLM for things like identifying recurring habits, finding patterns across entries, and pointing out areas for reflection, while the actual data stays on the same machine.

When a user asks Daybook to analyze their journal, the request stays within that local stack:

Journal → Backend → Ollama → Gemma → Analysis → Daybook

That's what allows Daybook to look for recurring habits, patterns, wins, struggles, and areas for improvement without requiring a cloud AI API.

To run Daybook, we only need three local processes:

React + TypeScript for the interface
Local backend for application logic
Ollama + Gemma 3 4B for AI analysis

No API key required

What Daybook Can Actually Do

Daily entries with topic, mood, weather, location, and a rich text editor
Goals tied to a date, so you can see what you meant to do next to what you wrote about
A reflection chat where you ask in plain language and get an answer grounded in your actual entries
Per entry observations the AI generates after you save
Memory suggestions you approve or dismiss, so nothing is remembered without your say so
A streak that counts unbroken days honestly
One image per entry, stored as a real file on your disk
Saved quotes collected in a Library
A profile built through onboarding that shapes how reflections are written

The AI is grounded, not creative

This was the part we spent the most time on. A journal AI that invents things is worse than useless, because you cannot trust what it tells you about your own life.

The system prompt carries 18 explicit rules. The model is told that its only source of truth is the context handed to it, that it must never invent entries, dates, goals, or statistics, that it must separate a one time observation from a recurring pattern, and that it must say plainly when there is not enough evidence. It is also told to avoid diagnosing anything about mental or physical health, and to respect a thingsToAvoidAssuming list the user fills in during onboarding.

Eight reflection intents decide how the model reads the context:

Intent	Looks for
`RECURRING_PATTERNS`	The same thing showing up again
`MOOD_EMOTIONAL`	Mood and emotional tone
`STRUGGLES`	What keeps getting in the way
`WINS_PROGRESS`	Wins, progress, momentum
`GOALS`	Goal follow through
`HABITS_ROUTINES`	Routines and timing
`CHANGE_OVER_TIME`	How things shifted over time
`SELF_UNDERSTANDING`	What Daybook knows about you

Questions that never reach the model

We route every question before it costs anything.

If a question can be answered from the database, Daybook answers it with SQL and skips the model entirely. Ask how many entries you have written, or what your goals are, and you get an exact answer instantly. Only questions that genuinely need interpretation go to Gemma.

flowchart TD
    Q["Your question"] --> ROUTE["classifyAiIntent"]
    ROUTE -->|"quote"| DQ["Return today's quote"]
    ROUTE -->|"streak"| DS["Return the streak"]
    ROUTE -->|"goals"| DG["Read goals from SQL"]
    ROUTE -->|"journal"| DJ["Read entries from SQL"]
    ROUTE -->|"reflection, or anything else"| LLM["Ask Gemma"]
    LLM --> INTENT["classifyReflectionIntent"]
    INTENT --> CTX["buildAiContext<br/>entries, goals, profile,<br/>stats, memories, observations"]
    CTX --> PROMPT["buildAiSystemPrompt<br/>18 grounding rules plus context"]
    PROMPT --> RUN["Ollama generates the answer"]
    RUN --> OUT["Answer with its intent label"]

This keeps answers exact where exactness matters, and spends model time only where interpretation is actually needed.

The streak is not AI

The streak is plain arithmetic over your entry dates. It converts dates to day numbers, ignores the future, returns zero unless you wrote today, then counts backwards while days are unbroken. If you skip a day, it ends there. No model, no guessing, no being generous with dates.

High-Level System Architecture

flowchart TB
subgraph USER["User Machine - 100% Local"]
  BROWSER["Browser<br/>localhost:5173"]
  subgraph FRONTEND["Frontend - React 19 + TS + Vite + Tailwind 4"]
    APP["App.tsx<br/>Routing and shared state"]
    VIEWS["Views<br/>InteractiveBook / JournalBook<br/>Calendar / Goals / Library<br/>AnalyticsAI / Settings / Onboarding"]
    APICLIENT["lib/api.ts<br/>Typed fetch wrapper for /api/*"]
  end
  subgraph BACKEND["Backend - Fastify :3001"]
    ROUTES["REST API<br/>users / journals / goals<br/>quotes / memories / ai/*"]
    ZOD["Zod Validation"]
    CONTEXT["buildAiContext()<br/>entries + goals + memories + profile"]
    AILOGIC["Intent routing and<br/>grounded prompt building"]
  end
  subgraph DATA["Data Layer"]
    DRIZZLE["Drizzle ORM"]
    SQLITE["SQLite<br/>better-sqlite3<br/>data/daybook.db<br/>WAL + foreign keys ON"]
    FILES["data/media/<userId>/<date>/<id>.png"]
  end
  subgraph AI["AI Layer - Ollama :11434"]
    OLLAMA_SDK["ollama npm SDK<br/>format json, temp 0.4"]
    GEMMA["Gemma 3:4b"]
  end
end
BROWSER --> APP --> VIEWS --> APICLIENT
APICLIENT -- "/api/* via Vite proxy" --> ROUTES
ROUTES --> ZOD --> DRIZZLE --> SQLITE
ROUTES --> CONTEXT --> AILOGIC --> OLLAMA_SDK --> GEMMA
ROUTES --> FILES

Using an open-weight model also meant we weren't locked into one AI provider. The model can be changed, experimented with, or eventually customized without redesigning the entire product around a proprietary API.

For a journal, where the data can be deeply personal, local inference isn't just a technical choice. It is part of the product itself.

Data model

Twelve tables, with foreign keys turned on so deleting an entry cleans up its goals, media rows, and observations in one step.

erDiagram
    users ||--o| user_profiles : has
    users ||--o{ local_sessions : opens
    users ||--o{ journal_entries : writes
    journal_entries ||--o{ journal_goals : contains
    journal_entries ||--o| journal_media : illustrated_by
    journal_entries ||--o{ journal_observations : analysed_by
    journal_entries ||--o{ memories : may_seed
    quotes ||--o{ saved_quotes : saved_as

Details we are proud of

Ownership is decided on the server, every time. No endpoint accepts a user id, an entry id, or a file path from the client. Each request resolves the active local session, finds that user's entry for the requested date, then works only with the media and goals hanging off it.

Images are safe by construction. Files are named with a server generated UUID, so your original filename never reaches the filesystem. Every path is built from your user id and the date you asked for, and any path resolving outside the media folder is refused. We tested a ../../../../etc/passwd payload and it landed on a UUID filename inside the media root like any other upload.

A photo failure never costs you your writing. The journal text is saved first. If the image fails afterwards, your text stays saved, your preview stays visible, and you get a clear error instead of a false success.

Date changes cannot leak content. Opening a date fires four requests in parallel, each carrying an AbortController. Switch to October 5 while October 4 is still loading and the stale reply is discarded, so October 4 can never appear on October 5.

Tech Stack

Layer	Technology	Port / Location
Frontend	React 19, TypeScript, Vite 8, Tailwind CSS 4, shadcn/ui, Lucide	`:5173` · `src/`
Backend	Fastify 5, Zod 4, Drizzle ORM, tsx	`:3001` · `server/src/index.ts`
Database	better-sqlite3, Drizzle Kit	`data/daybook.db`
AI	Ollama, Gemma 3 4B, Ollama npm package	`:11434`
Development	pnpm, Ollama	Local

Running Daybook

Ollama → Backend (:3001) → Frontend (:5173)
  ↓
Gemma 3 4B

ollama serve
ollama pull gemma3:4b

cd server
pnpm dev

# In another terminal
pnpm dev

Requires Node.js 26 or newer, pnpm, and Ollama.

Why Does Open Innovation Matter?

For Daybook, open innovation wasn't just about using a different AI model. It changed what we were comfortable building in the first place.

A journal is full of things you probably wouldn't want sitting on someone else's servers. Thoughts, bad days, habits, goals, personal memories. We wanted Daybook to actually analyze that information without making the user choose between useful AI and privacy.

Using an open-weight model like Gemma 3 4B made that possible.

Using Gemma 3 4B through Ollama gave us a way to do that. The model runs locally, so in our setup, the journal and its AI analysis can stay on the user's machine without requiring a third-party AI API or API key.

And that's where open models became more interesting to us than just being a cheaper alternative.

We can run the model locally through Ollama, keep the journal and its analysis on the user's machine, and build around the model without depending on a third-party AI API or API key.

It also gives us something a closed API doesn't: control.

We have control over what runs, where it runs, and how we build around it. We can experiment with different models, swap them out, run the system offline, and eventually customize the model for the kind of reflection Daybook needs.

For us, that control matters because of the kind of data we're working with.

It's that we could build an AI product around data we don't want to send anywhere in the first place.

For us, that's the real promise of open innovation: it lets developers decide where AI runs, what it sees, and how the system is built around it.

That's what it meant for Daybook.

My Agent Session

DayBook: Making the Beautiful UI for people's journal

You

Implement the FIRST-TIME PERSONAL ONBOARDING UI for DayBook. The goal is to create a beautiful, calm, journal-like onboarding experience when an existing local user has onboardingCompleted === false. The onboarding should collect personal information DayBook will later use to personalize journal analysis and AI responses. Follow the existing DayBook theme (calm, personal, warm, minimal, editorial, journal-inspired).

Agent

Created OnboardingView.tsx with a 7-step calm, editorial questionnaire reflecting DayBook's visual identity:
- Steps for current focus, personal bio, habits/motivators, known struggles, ideal day, reflection style (Gentle, Balanced, Direct), and things to avoid assuming.
- Integrated seamlessly with FirstRunRegistration and InteractiveBook flow so first-time users see it prior to opening the journal spread.
- Data structured for profile update with zero local storage hacks or database schema alterations.

▸ write_to_file DayBook/src/components/OnboardingView.tsx

Input

DayBook/src/components/OnboardingView.tsx

Output

File created with editorial onboarding component and responsive steps.

You

Some fix in Journal: the Bold, Italic, and Underline tool is not working properly. Check it out and fix it.

Agent

Investigated the contenteditable formatting mechanism in OpenJournalSpread.tsx:
- Added proper selection restoration and inline style dispatching (journal-style-sync).
- Ensured bold, italic, and underline commands toggle reliably across selected ranges and update toolbar highlight states.

▸ replace_file_content DayBook/src/components/OpenJournalSpread.tsx

Input

DayBook/src/components/OpenJournalSpread.tsx

Output

Updated selection formatting listeners and toolbar synchronization.

You

The GOALS and Observations 'Daybook noticed' overlaps when Daybook noticed has many things to show. Can you fix that, make both of them cleanly scrollable and not overlapping each other?

Agent

Updated the left page layout in OpenJournalSpread.tsx:
- Configured Today's Goals and DayBook Noticed containers with flex-1 min-h-0 overflow-hidden and inner overflow-y-auto scrollbar-none.
- Added subtle section dividing borders and bounded max heights so neither section pushes or overlaps the other.

▸ replace_file_content DayBook/src/components/OpenJournalSpread.tsx

Input

DayBook/src/components/OpenJournalSpread.tsx

Output

Layout converted to independent scrollable containers.

You

Collapse this mood selections to a drop down selection, so goals and Daybook Noticed gets good space.

Agent

Collapsed the 14-button mood selection grid into an inline dropdown menu in OpenJournalSpread.tsx:
- Added dropdown trigger displaying the active mood emoji, title, and chevron.
- Implemented floating popover menu with 2-column layout and click-outside dismissal.
- Freed up vertical space, providing ample room for Goals and DayBook Noticed.

▸ replace_file_content DayBook/src/components/OpenJournalSpread.tsx

Input

DayBook/src/components/OpenJournalSpread.tsx

Output

Mood selector transformed to compact dropdown picker.

DayBook: Core Backend Architecture, Local AI Reflections, and Persistence

You

Review the DayBook codebase and implement the next persistence phase: Journal Goals. The goals need a dedicated SQLite table with foreign keys to journal entries, REST endpoints for CRUD operations, and full UI integration.

Agent

Implemented Journal Goals persistence end-to-end:
- Created journal_goals schema in Drizzle ORM with foreign key cascades to journal_entries.
- Added REST API routes for listing, creating, toggling completion, and deleting goals.
- Integrated goals state and optimistic UI updates into the journal view.

▸ edit_file server/src/db/schema.ts

Input

server/src/db/schema.ts

Output

Added journal_goals table with foreign key relationship.

You

Implement real journal streak calculation in DayBook. Streaks should be computed from actual journal entry dates in SQLite without relying on client-side mocks.

Agent

Implemented SQLite-backed consecutive streak counting:
- Added date normalization and consecutive day algorithm spanning back from today or yesterday.
- Created GET /api/journal/streak endpoint returning current and longest streak.
- Updated UI header badge to display live database streak count.

▸ edit_file server/src/index.ts

Input

server/src/index.ts

Output

Added streak computation logic and API route.

You

Implement DayBook core local AI reflection system. It must run locally using Ollama, ground reflections in SQLite journal context, and provide thoughtful journal insights without leaking user data.

Agent

Integrated local AI reflection engine:
- Connected to Ollama local instance running Gemma.
- Implemented deterministic retrieval of recent entries, mood trends, and active goals to construct the reflection prompt context.
- Added streaming reflection generation with fallback handling.

▸ edit_file server/src/ai/engine.ts

Input

server/src/ai/engine.ts

Output

Created local LLM reflection pipeline.

You

Implement smart AI queries and deterministic data retrieval. Factual queries (like goal counts, mood history, dates) should be answered directly from SQLite, while reflective prompts use the local LLM.

Agent

Built hybrid query router:
- Intent classification routes factual questions directly to SQL aggregations.
- Reflective and emotional questions are enriched with retrieved SQLite context and passed to the local LLM.
- Drastically reduced LLM latency and eliminated hallucinations for historical journal facts.

▸ edit_file server/src/ai/router.ts

Input

server/src/ai/router.ts

Output

Implemented intent routing between SQL queries and LLM generation.

You

Implement DayBook Quote System and Persistent Library: daily quotes, quote catalog, and SQLite-backed saving/unsaving of favorite quotes.

Agent

Created persistent Quote & Library system:
- Added quotes and saved_quotes tables in SQLite.
- Built deterministic daily quote selection based on date hashing.
- Added endpoints for favoriting quotes and browsing saved quotes in the Library view.

▸ edit_file server/src/db/schema.ts

Input

server/src/db/schema.ts

Output

Added quotes and saved_quotes tables with migration.

You

Implement per-entry AI observations (DayBook Noticed). When an entry is written, the system should generate concise categorized observations (patterns, achievements, emotions).

Agent

Implemented Per-Entry AI Observations (DayBook Noticed):
- Added journal_observations schema with observation types (habit, emotion, milestone).
- Extracted structured observations upon saving journal entries.
- Rendered categorized observation tags in the left page margin of the journal spread.

▸ edit_file server/src/index.ts

Input

server/src/index.ts

Output

Added observation generation and schema linkage.

You

Implement AI Memory Suggestion with explicit user confirmation. DayBook should detect long-term facts or habits from reflections, propose them to the user, and only persist them to user memory upon approval.

Agent

Implemented AI Memory Suggestions with human-in-the-loop confirmation:
- Added suggested_memories table with status tracking (pending, confirmed, dismissed).
- Built memory suggestion extraction prompted from recent journal reflections.
- Provided confirmation controls in the UI so users retain complete authority over stored memories.

▸ edit_file server/src/db/schema.ts

Input

server/src/db/schema.ts

Output

Added suggested_memories and confirmed_memories tables.

You

Implement deep personalization, context-aware AI reflections, and the knowledge endpoint showing what DayBook knows about the user.

Agent

Implemented Deep Personalization & Knowledge Surface:
- Added GET /api/ai/knowledge endpoint aggregating profile facts, confirmed memories, recurring themes, and reflection preferences.
- Dynamically tuned AI reflection tone according to user style (Gentle, Balanced, Direct).
- Ensured all personalization remains strictly local on device.

▸ edit_file server/src/ai/knowledge.ts

Input

server/src/ai/knowledge.ts

Output

Aggregated user knowledge model for personalized prompting.

Prize Categories

Gemma - Daybook uses Gemma 3 4B as its core AI model, running locally through Ollama to analyze journal entries while keeping personal data on-device.

Render - Used to deploy the parts of Daybook that need to be accessible beyond the local development environment.

GitHub - Used for open-source development, CI/CD, collaboration, version control, and sharing Daybook's code with the community.

DEV Community: Jesus Chetia

StorySteps: an offline atlas for the stories attached to places

What I Built

What it refuses to do

Demo

Code

greenbugx / StorySteps

Every place has a story. Go outside and find it.

StorySteps

The problem

How I Built It

Whisper runs in a worker, and the audio never enters React state

Gemma streams, because 1.9 GB will not fit twice

The runtimes are served from this origin, not a CDN

The schema refuses sloppy data

Bugs I hit along the way

Why Does Open Innovation Matter?

My Agent Session

Prize Categories

What if your journal could understand you? So I built DayBook

What We Built

Demo

Code

greenbugx / Daybook

A private AI journal that learns your habits, finds patterns, and helps you improve, powered by a local LLM with your data staying on-device.

Table of Contents

Screenshots

What DayBook Does

How We Built It

What Daybook Can Actually Do

The AI is grounded, not creative

Questions that never reach the model

The streak is not AI

High-Level System Architecture

Data model

Details we are proud of

Tech Stack

Running Daybook

Why Does Open Innovation Matter?

My Agent Session

Prize Categories