DEV Community: Warisha Danin Bilal

magpie (Content Desk): How I Built an Offline AI Work Journal to Manage My Side Hustles, Societies, & Applications

Warisha Danin Bilal — Sun, 18 Oct 2026 21:09:22 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle

What I Built

As a student developer balancing coursework, side projects, job applications, and leadership roles in university societies, my biggest bottleneck was chaos. My technical progress lived in scattered git commits, draft ideas were lost in private Gemini/Claude chats, I constantly lost track of job application deadlines, and sitting down to write updates for Substack or LinkedIn felt like starting from a blank void every single time.

I built magpie (cdesk) — an offline, local-first work journal, posting desk, and productivity hub.

Instead of an AI that generates generic marketing fluff, magpie starts with the work you actually did:

Frictionless Capture Inbox: One-command ingestion of daily git commits, raw notes, or exported AI chat histories (Gemini / Claude JSON), tagged by origin and deduplicated.
Source-Linked Work Journal: Daily and weekly summaries where every single line cites the exact capture receipts.
Multi-Channel Workspaces: Tailored drafting for Substack, LinkedIn, and university society channels. Each workspace has its own voice profile (via vector embeddings), platform formatting rules, and banned-phrase filters.
Deterministic Fact-Checking & Receipt Checking: The local model drafts, but pure Python deterministically audits the text. If the model hallucinates numbers, handles, links, or dates not grounded in your source captures, it catches them and retries.
Content Planner & Nudges: Visual calendar views, .ics Google Calendar export, and gentle "you haven't posted in $N$ days" cadence nudges.
Job Tracker & Resume Tailor: A Kanban tracker for internships and jobs, paired with a pipeline that tailors resume bullets and cover letters backed strictly by citations from your real work journal.
Context Pack Generator: Instantly compiles recent journal lines, decisions, and open questions into a single markdown brief to paste into any new AI session.

Who would pay for this? Freelancers, solopreneurs, student builders, and developer advocates managing multiple side projects who want to maintain an active public presence and organized career pipeline without spending hours manually collating notes or paying hefty monthly SaaS subscriptions.

Demo

Here is a full walkthrough of magpie in action — from ingesting git logs and chat exports to generating verified, cited drafts and managing the job application pipeline:

(You can also run the full Streamlit interface locally in one command: streamlit run src/cdesk/app/Home.py or use the CLI via cdesk)

Code

magpie is 100% open-source and local-first:

Warisha-Bilal7 / magpie

How I Built It

magpie was engineered with a strict principle: The model writes; deterministic code verifies, schedules, and counts.

1. Open-Source AI & Local Inference

Local LLMs via Ollama: Runs completely offline with open-weight models (such as qwen2.5:3b, llama3.2, or mistral).
Local Embeddings: Embeddings are generated locally and stored as binary BLOBs directly in SQLite for cosine-similarity voice matching and near-duplicate idea detection.
Offline Template Fallback: Every LLM node has a deterministic Jinja2 template fallback, meaning the entire system remains functional even on a low-spec laptop with Ollama turned off.

2. Stateful Graph Pipelines with LangGraph

magpie splits work into three distinct LangGraph cycles:

Journal Graph: select -> summarize (LLM) -> verify (receipt check) -> store. Unsupported claims are kicked back with exact violation feedback (up to 2 retries) before falling back.
Drafting Graph: gather -> voice matching -> write (LLM) -> fact_check -> rules_check -> save.
Job Tailor Graph: parse_jd (LLM) -> match_evidence -> write_bullets (LLM) -> verify (citations) -> store.

3. Architecture & Stack

Database: SQLite with SQLite FTS5 (full-text search) synchronized via SQLite triggers.
Frontend: Streamlit multi-page app with clean kanban boards, markdown editors, and visual diff badges for rules violations.
CLI: Python Typer + Rich (cdesk capture, cdesk journal, cdesk draft, cdesk tailor, cdesk ics).

Why Does Open Innovation Matter?

Open-source and local-first AI are essential for personal productivity tools:

Absolute Privacy for Sensitive Data: A work journal contains unreleased code commits, internal team notes, personal thoughts, and job hunt statuses. Sending this raw telemetry to proprietary cloud APIs is a non-starter. Open innovation allows everything to run 100% on localhost.
Accessible on Student Hardware: Proprietary frontier models demand ongoing credit card subscriptions and API fees. By leveraging 4-bit quantized open-weight models (1B–7B parameters), Content Desk runs efficiently on an everyday student laptop.
Auditability & Determinism: Open frameworks allow us to insert rigid verifiers between reasoning steps, eliminating hallucinations and ensuring the assistant remains grounded in real facts rather than speculative marketing fluff.

My First User

I built magpie out of personal necessity, and I was my own first user.

Before this, I had three persistent friction points:

Deadlines slipping away: Missing application deadlines and forgetting where I had applied or who I needed to follow up with.
University Society updates: Spending hours every weekend trying to remember what our student team shipped during the week to write announcement posts.
Content creation paralysis: Knowing I needed to share technical learnings on Substack and LinkedIn, but getting stuck on the blank page.

Dogfooding magpie during its development changed my workflow:

Running cdesk capture --git <repo-path> pulls my commits into the journal automatically at the end of the day.
When drafting our society newsletter, the drafting graph produces a structured draft in our tone within seconds, complete with citations to the actual pull requests.
The Kanban job tracker with deadline reminders has kept my application pipeline organized without context switching between three different note-taking apps.

What's Next for Content Desk

This is just the beginning of my side hustle desk. On my roadmap:

👾 Desktop Application & Floating Widget: Packaging Content Desk as a lightweight desktop widget so I can quick-capture thoughts or check due nudges with a global hotkey.
🎨 Vintage Y2K Aesthetic: Giving the UI a cohesive, playful retro Y2K theme with custom CSS styling to make daily planning and writing genuinely fun.
🤖 Grokbot-Style Proactive Assistant: Introducing an interactive, conversational buddy that actively nudges me about stalled job applications, brainstorms angles for society campaigns, and chats through project blockers.
🧪 Further Polish & Edge-Case Debugging: Continuing to refine citation regex heuristics and parser support for more chat export formats.

Prize Categories

Hacktoberfest Open-Source AI Challenge: Week 2 — Side Hustle

A golden hour walk planner that runs on a 1B model.

Warisha Danin Bilal — Sun, 11 Oct 2026 21:50:58 +0000

Open outside

At 17:27 I printed the one-page card and left the door. The sunset was at 18:07. The route sent me past nearby green spaces and the low sun came through the trees right as the card suggested.

Describe the light, the printed card in your hand, and one thing the route got
right or wrong. Example shape: "Sunset was at 18:09. I left the house at
17:14 with one sheet of paper. The card sent me left toward the park instead of
right along the main road, and the low sun came through the trees exactly where
it said it would..."

No architecture in this part. Just the walk.

The problem

Most "where should I walk" tools want you to keep looking at a screen. You open a
map app, drag around, check the sun, pick a loop, and by the time you leave the
light has moved. I wanted the opposite: a few minutes at the keyboard that end in
a single printed page, and then a phone in your pocket.

So the output is a one-page route card (big type, a little map) plus a GPX file
for Organic Maps or OsmAnd. The screen is the shortest part of the experience.

The rule that makes it work: the model never routes

A 1B–3B model cannot plan a loop through a real street network. It will invent a
road, miss a dead end, and hand you a route that crosses a river. So the split is:

The model does language. It reads your request ("45 minutes before dark, trees and quiet") into structured parameters, and it writes the card.
Deterministic code does everything numeric. astral computes sunset and the golden-hour window, osmnx downloads the walk network and green space, networkx builds and scores the loop.

The pipeline is a small LangGraph: intake → sun → weather → map_fetch → route_builder → critic → card_writer → render. The critic can send the route
back for another attempt, loosening the target if it cannot hit the length.

Reading the request with a JSON schema

The intake node asks the local model (Ollama) for structured output, so even a
small model returns valid JSON:

resp = llm.chat_structured(
    model=state["model_name"],
    system="Extract walk parameters. Return JSON only.",
    user=state["user_input"],
    schema=IntakeParams.model_json_schema(),
    temperature=0.0,
    keep_alive="10m",   # stay warm until the card is written
)
intake = IntakeParams.model_validate_json(resp)

If the model is unreachable or returns junk, the node falls back to defaults and
records a warning. The app always produces a card.

Writing the card from facts only

The card_writer prompt is deliberately constrained: the model may only use the
verified facts, and every place name must be wrapped in [[double brackets]] so
it can be checked afterwards.

Use ONLY these facts. Do not invent places, landmarks, or plants.
Wrap every place name in [[double brackets]].
Start: ... | Distance: 3.4 km (~45 min) | Sunset: 2026-10-11 18:08
Golden light comes from the 271° . Weather: 29 C, 20% rain
Green spaces on the route: Allah Rakha Park, Bagh-e-Lyari

Then a check pulls every [[name]] back out and compares it to the OSM list:

unknown = unknown_names(card_text, state["place_names"])
if unknown:
    warnings.append(f"unknown place names: {', '.join(unknown)}")

That check is the difference between "the model wrote a nice card" and "the model
wrote a nice card that sends you to a park that does not exist."

What went wrong

The 1B model invented a place. On one run llama3.2:1b wrote a name that was not in the OSM data. The bracketed-name check caught it and logged a warning instead of shipping it. Not every run — the honest number is in the table below.
OSMnx drops latitude/longitude when it saves a projected graph. The GPX export came out with empty coordinates until the loader inverse-projected the x/y node attributes back to WGS84.
weasyprint would not install on Windows. I print the HTML from Edge headless (or a browser) instead, and treat the PDF as best-effort.

[FIELD TEST — add anything the walk itself exposed: a dead end, a retraced
segment, a muddy path, the light arriving earlier than the card said.]

The model comparison

Same request, same start point, same map — only the model changes. The router has
no LLM, so route quality is identical; the interesting columns are the
hallucination count and the card length.

Model	Pace read	Words	Length error	Peak RAM	Time
`qwen2.5:3b`	normal	36	0.3%	259 MB	106 s
`qwen2.5:1.5b`	brisk	69	4.4%	260 MB	16 s
`llama3.2:1b`	slow	56	9.5%	274 MB	76 s
template (no model)	normal	55	0.3%	273 MB	65 s

All three fit under 0.5 GB of model memory. The 3B read the pace correctly and
produced the shortest, most on-target card; the smaller models misread the pace,
which moves the target length and the length error. Full columns live in
eval/results.csv; the harness is eval/compare.py.

The whole point: the screen should lose.

References

Ollama structured outputs — https://docs.ollama.com/capabilities/structured-outputs
"Ollama Structured Outputs in Practice — Getting Type-Safe JSON from Local LLMs with Pydantic" — https://dev.to/jangwook_kim_e31e7291ad98/ollama-structured-outputs-in-practice-getting-type-safe-json-from-local-llms-with-pydantic-m38
"Your LLM Returns JSON That Isn't JSON: A Robust Structured-Output Pipeline for Local Models" — https://dev.to/syed_anwar/your-llm-returns-json-that-isnt-json