DEV Community: Vinks Goyal

Gnosk — Know what your code knows

Vinks Goyal — Mon, 19 Oct 2026 05:24:11 +0000

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

What I Built

Gnosk is an offline PII scanner for freelance developers. You point it at a folder. It scans every file in milliseconds and reports where personal data lives — Aadhaar numbers, PAN cards, Indian phone numbers, emails, twelve provider API-key shapes — with the exact file path, line number, and a confidence score. Then it writes a redacted markdown inventory you can hand to a client without a second thought.

The problem it solves is legal, not technical. Freelancers in India are increasingly being asked by clients to sign data-protection clauses under the DPDP Act. Most of them have no idea what personal data their project actually touches. Enterprise DLP tools cost more than a freelancer's monthly income. Cloud-based scanners want you to upload the exact data you're trying to protect. Both of those answers are non-starters.

Gnosk is the third option. Deterministic validators run first — regex, Verhoeff checksums, provider-format patterns — and a local Gemma 2B model runs only on the findings the rules can't decide. Nothing leaves the machine. You can unplug the network cable and the scan still works.

Repo: https://github.com/vinksgoyal/gnosk
Tests: 215 passing, ruff clean
License: MIT
Platform: Linux and macOS. Windows requires WSL — documented, not polished.

Demo

Four things to watch for in the demo:

Triage before the model. A scan produces five findings. Four are resolved by rules in ten milliseconds. One goes to the model. The AI sees one item, not five.
Real-world scan. The same tool against my Downloads folder: 127 files, 6 findings, 0.13 seconds. Two of the findings were my own email in my own resume — sitting in a folder I'd forgotten about.
Redaction. The report shows 23********24, not 234567890124. Two characters at each end, asterisks in the middle. The report cannot become the leak it's warning you about.
Offline. Airplane mode on. Scan still runs.

Code

Repo: https://github.com/vinksgoyal/gnosk

git clone https://github.com/vinksgoyal/gnosk
cd gnosk
./install.sh

Then:

gnosk scan ./my-project             # quick scan
gnosk scan ./my-project --classify  # add local model verdicts
gnosk report ./my-project           # write a client-ready inventory

Stack: Python 3.11+, typer for the CLI, rich for terminal output, questionary for the REPL, ollama-python for the local model, gemma2:2b via Ollama.

The install script is ~190 lines of bash: version-checks Python, creates a virtualenv, installs the package, symlinks gnosk into ~/.local/bin. Idempotent, colored output, specific error messages — if Python 3.11 is missing, it tells you the exact apt install line instead of "command not found."

How I Built It

I'm on a 2-core Intel laptop with 7.7 GB RAM and no GPU. Every architectural decision in this project comes from that constraint.

Day 1 — the deterministic layer. Five validators (Aadhaar, PAN, email, Indian phone, API keys) plus tests. My hand-computed Verhoeff check digit was wrong on the first try — the validator caught it. That was the first evidence that deterministic-first would pay off: the failing test wasn't the code, it was my arithmetic.

Day 2 — the wall. I benchmarked the model: a 2 KB prompt takes 38 seconds to process on this hardware. My initial classifier prompt was 1,500 characters and timed out at 180 seconds. The first three attempts at building the classifier failed because I assumed the bottleneck was prompt size. It wasn't. Output tokens were. Capping num_predict at 180 and dropping the reason field from the model's response cut wall time from over 180 seconds to under 60.

Day 3 — the false-positive hunt. This is the part I'm most proud of.

Act 1. I scanned a Hacktoberfest project I had on disk — a bird-detection app called birdbuddy. It reported 14 phone numbers. Every one was a fragment of the same SHA256 hash: ...987d8227518893. The substring 8227518893 is 10 digits starting with 8, which matches my Indian-phone regex exactly. A 64-character hex string contains about 55 overlapping 10-digit windows; several will match a phone pattern by pure chance.

Act 2. I added a hex-run filter — if a finding's span sits inside a 32+ character hex run, drop it. My test suite caught the fix eating GitHub PATs. A 40-character ghp_AAAA... token looked like a hex run because 36 of its 40 characters are hex. Added a condition: the matched span itself must consist entirely of hex characters. ghp_ contains g, h, p, _ — not hex. Filter fixed.

Act 3. Re-ran birdbuddy. Still 8 phone numbers. These were decimal fragments of per-token LLM prices from a .backboard/sessions/*.jsonl gateway log. 0.000000234375 produces 234375000000 if you squint at the digits. Added an entropy filter — real Indian phone numbers don't have five or more zeros — and a skip-list entry for tool-generated directories.

After all three fixes, birdbuddy returns zero findings. Real bug, three iterations, real numbers. None of this came from test fixtures. All of it came from running the tool on data that wasn't designed to make the tests pass.

Day 4 — triage. The --classify flag was initially sending every finding to the model, which took 120 seconds per file on this hardware. That made the AI look like a bolt-on. Triage rules now resolve the easy cases first:

Known fixture values (alice@example.com, AKIAIOSFODNN7EXAMPLE) → fixture
Files in tests/, fixtures/, examples/ → fixture, except API keys and checksum-valid Aadhaar, which always defer to the model
Checksum-valid Aadhaar outside a test path → likely_real (format validity only, not personhood)
Everything else → model

On the demo folder, that's four triaged plus one modeled. On a real client project, it means the model is called once or twice per scan, not once per finding.

Day 5 — the rename. I renamed the project from VaultScan to Gnosk. This broke the venv, because Python venvs embed absolute paths at creation time. rm -rf .venv && ./install.sh fixed it in thirty seconds. Renaming a project directory is never just mv.

The result is 215 tests, zero failures, an install script verified from a fresh shell, and a terminal UI that respects NO_COLOR and refuses to emit ANSI codes when piped to a file — because a security tool that dumps escape sequences into a log file isn't a tool you'd trust.

Why Does Open Innovation Matter?

A cloud-based scanner cannot solve this problem at any price.

The DPDP Act asks freelancers to take responsibility for personal data. The only way to know what personal data a project touches is to scan it. The only safe way to scan client data is not to send it to someone else's server. OpenAI, Anthropic, Google — they all require uploading data to their API. That's a non-starter for the exact use case Gnosk exists for.

What open-weight models unlock here isn't a cheaper API call. It's a category of tool that couldn't exist otherwise: an AI that runs on the same laptop as the data, with no network path out.

The specific pieces that make Gnosk work:

Gemma 2B via Ollama. Runs on a 2-core CPU with no GPU. About 60 seconds for a bounded classification task. Slow, but usable, and free forever.
Localhost inference. The only network call is localhost:11434. Turn off Wi-Fi and everything still works.
Open weights mean I can tune the prompt against my own hardware. With a closed API, every prompt iteration costs tokens. On my machine, it costs three minutes and no money — and I iterated dozens of times.

If Gemma weren't open-weight, the honest alternative for Gnosk would be no AI at all. The deterministic scanner works fine. It just can't tell a real client email from a test fixture. That judgment call is exactly what the model handles, and it's the difference between a tool that produces 14 false positives on a real project and one that produces zero.

The "open" in open-source AI isn't a licensing footnote here. It's the entire reason the project is possible.

My Agent Session

I built Gnosk mostly in conversation with an AI coding assistant. The real number: roughly 15 hours across 5 days and about 200 messages. Every commit in the repo is a real step in that process.

What worked:

Tight feedback loops. "Run the tests, paste the output" beat "explain how this should work." Most bugs got fixed in a single turn because the loop closed fast.
The agent pushed back on my bad ideas. When I tried to build a full-screen textual TUI, it said "3–6 hours on 2-core hardware, DEV post unstarted — this is the wrong call." It was right. We shipped a REPL instead, in an hour.
The agent was honest about trade-offs. When I asked for a continuously animating signature, it suggested a static gradient first and explained why a looping color cycle was a worse product. That small moment shaped three later decisions.

What didn't work:

Long conversations degrade. Around message 100, the agent started forgetting context from earlier in the session. I had to re-explain the Finding dataclass twice. A CLAUDE.md file at the repo root would have prevented this — that lesson is now in the repo as ARCHITECTURE.md.
Suggested nano edits were unreliable. Twice, an edit corrupted the file (merged lines, deleted a function body). The fix was full-file overwrites via cat > file <<'EOF'. Slower to read, but it never corrupts.
The agent can't verify its own suggestions on my hardware. "This should run in ~30 seconds" was sometimes 90. The only fix was to run it and paste the real numbers back.

The tool worked. The prompt did not do the work — the iteration did. My best commits came from the agent being wrong and me running the code to find out why.

Prize Categories

Gemma — Best Use of Gemma

Gnosk uses gemma2:2b via Ollama for ambiguous-finding classification. Measured on 2-core CPU, no GPU: about 60 seconds per file with five findings. Full prompt strategy and benchmark numbers are in ARCHITECTURE.md section 8 of the repo.

The model is not decoration. It's the difference between a scan that produces 14 false positives on a real project and one that produces zero. Removing it would turn Gnosk from a tool a freelancer could actually hand to a client into a noisy regex scanner they'd uninstall after one run.

BirdBuddy: an offline bird call identifier that runs entirely on your device

Vinks Goyal — Wed, 07 Oct 2026 18:38:20 +0000

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

What I Built

BirdBuddy is an offline bird call identifier. You're on a trail with no signal, you hear a bird, you record three seconds, and BirdBuddy tells you what it is — with everything running locally on the device in your pocket.

The screen is the shortest part of the experience. Open the app, tap once, put the phone away. The identification finishes in about two seconds. No cloud round-trip, no account, no upload. Just you, the bird, and a 52 MB model that never leaves your machine.

Who it's for: hikers, birders, and anyone who's ever heard something beautiful in the woods and had no idea what it was.

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

Note: hosted on Render's free tier (512 MB RAM). The first request after idle may take 30–60 seconds to wake up. See the video below for the real, snappy experience.

Demo

https://www.youtube.com/watch?v=7b3iXirhnTQ

What you're seeing:

The light, offline-first UI
Upload or record a 3-second bird call
Top-3 matches ranked by confidence
The top match spoken aloud by an on-device TTS voice
A Settings tab to tune Top-K, confidence threshold, and voice speed

Code

GitHub: https://github.com/vinksgoyal/birdbuddy

Repo layout:

src/inference.py — BirdNET ONNX inference (audio → species)
src/voice.py — Piper TTS (text → speech, offline)
app.py — Gradio UI
scripts/tinker_finetune.py — Tinker fine-tune of Qwen3.5-4B for bird expertise
Dockerfile + render.yaml — one-click deployment
docs/ — Copilot usage screenshots

How I Built It

BirdBuddy is built entirely on open-source AI. Three open pieces make it work.

1. BirdNET v2.4 — open-weight acoustic classifier

BirdNET is a bioacoustics model released by the Cornell Lab of Ornithology and Chemnitz University. I used the FP32 truncated-DFT ONNX variant (~52 MB) running through ONNX Runtime on CPU. It classifies 3-second, 48 kHz audio into 6,522 species.

The model runs on a laptop, a phone, or a Raspberry Pi — no GPU required. Inference latency is under two seconds on a modern laptop CPU.

2. Piper — open-weight text-to-speech

Piper is an MIT-licensed neural TTS that runs on CPU. I used the en_US-lessac-medium voice (~63 MB). When BirdNET returns its top match, Piper speaks it out loud: "I heard a Northern Cardinal."

No ElevenLabs, no Google Cloud TTS — the voice is a local ONNX model, just like the classifier.

3. Qwen3.5-4B fine-tuned with Tinker

The audio model gives us a species ID. To make BirdBuddy useful and not just a label, I fine-tuned a small LLM to act as a bird expert — field notes, habitat, how to identify by sound.

I built a 165-example chat dataset covering 60 common North American species, then fine-tuned Qwen3.5-4B with a LoRA adapter (r=16) using Thinking Machines' Tinker.

Training loss over 3 epochs:

Epoch	Avg loss
1	202.64
2	95.09
3	68.43

Baseline output on a held-out prompt (before fine-tune):

"I don't know how to use the API. ... Give me a field note for American Kestrel..."

Fine-tuned output (after training):

"American Kestrel (Falco sparverius) is a small falcon with brown upperparts and blue wings. Its shape, plumage, and behavior are useful clues when recording a field observation..."

That's the improvement the Tinker category asks for: a specific task, a clear baseline, a measurable gain.

4. Built with GitHub Copilot

Copilot was the workbench for the entire project:

Copilot Chat in VS Code scaffolded src/inference.py, src/voice.py, and the Gradio UI
Copilot coding agent took Issue #2 and opened a PR that adds the GitHub Actions CI workflow
GitHub Actions now runs tests on every push

5. Backboard R-CLI for dataset work

I used Backboard's R-CLI as a coding agent inside the repo for dataset curation and pipeline review — it summarized the inference pipeline, flagged missing error handling, and produced scripts/agent_review.md.

Deployment

Docker + Render. The Dockerfile downloads both models (BirdNET and Piper) at build time so the container is fully self-contained. No API keys, no external services at runtime.

Why Does Open Innovation Matter?

This project only exists because of open-source AI. Every design decision traces back to it.

The model is open-weight. BirdNET was released specifically for bioacoustics research. A closed API would have cost per call, required internet, and — critically — wouldn't have let me swap models. During development I tried three different classifiers. With a closed API, I'd be stuck with whatever the vendor offered.

The training data is open. The species library is a community-curated dataset of bird recordings. Thousands of birders contributed. A closed model trained on proprietary data would be a black box. I can inspect exactly what my model learned.

The runtime is open. ONNX Runtime means BirdBuddy runs on Android, iOS, Linux, macOS — even a Raspberry Pi. A closed inference service would lock me into one platform and one pricing tier.

The voice is open. Piper is MIT-licensed. Its voice models are open-weight. The TTS runs on the same laptop as the classifier.

The cost is zero. No API keys. No usage limits. No "your free tier has expired." A kid in a rural area with a hand-me-down phone can use this. A researcher in a country with unreliable internet can use this.

The agent harness is open. Backboard's R-CLI let me automate the boring parts — dataset cleaning, pipeline review — without locking my workflow into a proprietary IDE. I could inspect every step the agent took.

The fine-tune is open. Tinker let me fine-tune Qwen3.5-4B to a specific task and prove, with numbers, that the fine-tune beat the baseline. A closed model endpoint would not have given me the loss curve, the LoRA weights, or the freedom to swap base models.

The closed alternative would be: a subscription app that uploads your audio to a server, identifies birds you could have identified yourself, and charges $9.99/month. That's not innovation — that's rent-seeking.

This is innovation: a 52 MB classifier, a 63 MB voice model, a fine-tuned LoRA — all running on your device, in the middle of nowhere, for free, forever.

My Agent Session

Backboard R-CLI session: sess_3f07cb2e — model openai/gpt-5.5, profile coding

The session covered:

Reading src/inference.py, app.py, and requirements.txt
Summarizing the pipeline
Flagging missing error handling on the audio loader
Producing scripts/agent_review.md

Prize Categories

Entering:

Best Use of GitHub Copilot — Chat, coding agent PR, and Actions CI
Best Use of Tinker — fine-tuned Qwen3.5-4B with a measurable loss improvement (202.64 → 68.43)
Best Use of Backboard — R-CLI agent session saved and embedded
Best Use of Render — deployed and live at birdbuddy.onrender.com

What's Next

Package BirdBuddy as a real mobile app (React Native + ONNX Runtime Mobile)
Expand the Tinker fine-tune dataset to all 6,522 BirdNET species
Add a "trail log" that stores sightings locally and syncs later — never during the walk
Bring back a real hardware button on a Bluetooth clicker so you can record without touching the phone

Built with open-source AI, for the birds, and for everyone who'd rather be outside.

Unstick: One Tiny Action Instead of a Plan

Vinks Goyal — Sun, 04 Oct 2026 06:11:52 +0000

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

What I Built

Unstick gives you one tiny action instead of a plan.

Every productivity tool, every AI chatbot, every roadmap does the same thing: it shows you the whole mountain. Ask ChatGPT how to start a creative portfolio and it gives you five sections, twenty sub-bullets, and an implied skill tree you didn't ask to see. That's technically helpful and completely useless if you're already overwhelmed.

I built Unstick because I've been that person. I've started my portfolio fourteen times and never finished. Not because I'm lazy — because every time I opened a tool, it showed me how much I didn't know yet, and I closed the tab.

Unstick does the opposite. You give it a goal. It gives you exactly three cards:

Start here — one physical action you can do in five minutes
If you have 15 minutes — a slightly bigger one
Not today — a greyed-out card that says: "The rest of the plan exists. You don't need to see it."

That third card is the whole product. The absence of a plan is the feature. No progress bars. No "step 3 of 47." No skill tree.

Who it's for: me. I'm the friend I built this for. I don't have someone else to hand it to this weekend, and I'm not going to invent one. I've started my portfolio fourteen times. This is the tool that would have made me finish.

Demo

Live app: https://unstick-api-c7va.onrender.com

Type a goal. Click the button. Three cards.

API endpoint (for the terminal-inclined):

bash

curl -X POST https://unstick-api-c7va.onrender.com/api/unstick \
  -H "Content-Type: application/json" \
  -d '{"goal":"start a creative portfolio","minutes":15,"energy":2,"location":"home","time":"21:30"}'

Video: https://www.youtube.com/video/JtzAP9eyUZc

Note on the demo: the fine-tuned classifier is trained specifically for creative portfolio goals. For other goals it still returns scope-safe actions, but the domain fit is weak — a "finish my thesis" prompt will give you portfolio-shaped actions. That's a real limitation, not a hidden one. A next step would be broadening the training set.

Code

GitHub: github.com/vinksgoyal/unstick

Structure:

app/ — FastAPI backend + Tinker + Backboard clients
frontend/ — the three-card UI
training/ — dataset, label helper, Tinker fine-tune script
eval/ — base vs fine-tuned evaluation harness
unstick-evidence/ — every screenshot, log, and number cited in this post

How I Built It

The prompt says to use open-source AI at the core. Here's what that actually means in this project.

The engine: local open-weight models

The candidate generator runs Gemma 2B locally through Ollama. When you type a goal, the app asks Gemma to decompose it into candidate actions. That call happens on your machine. No cloud API sees the raw brain-dump.

Gemma is not good at this task out of the box. Here's what it produced when I asked it to generate actions for "Start a creative portfolio":

text

"Stand up and stretch for 30 seconds."
"Go to the kitchen and pour a glass of water."
"Pick up a pen and paper and start doodling for 5 minutes."
"Shuffle a deck of cards."
"Take a five-minute walk in your neighborhood."

None of those have anything to do with starting a portfolio. The base model drifts into generic wellness advice because it can't hold the goal in mind. That's the "before" state.

The classifier: Tinker fine-tune

The scope-safety classifier is the actual product. Its job is to look at a (goal, action) pair and decide: is this action safe to show an overwhelmed person?

I defined six ways an action can fail:

Failure	Example
`reveals_scope`	"Sketch your homepage layout"
`needs_new_skill`	"Learn Figma"
`needs_decision`	"Pick your best five pieces"
`not_physical`	"Think about your design style"
`needs_other_person`	"Ask a friend for feedback"
`off_topic`	"Pour a glass of water" (for a portfolio goal)

I hand-labeled 128 (goal, state, action) triples across those six categories, plus safe examples. 100 went to training, 44 to a held-out set.

Then I fine-tuned Qwen3-8B with LoRA on Tinker, using the SDK directly with masked cross-entropy loss on the answer tokens only.

Results

Model	Accuracy	Safe-F1	Fail-F1	Latency	Rows
Base Qwen3-8B	0.2727	0.4000	0.3721	96s	44
Fine-tuned (Tinker LoRA)	0.7045	0.7778	0.9429	118s	44

Base model: 27% accuracy. Fine-tune: 70%. The fail-class F1 — how well the model catches bad actions — went from 0.37 to 0.94. That's the difference between a demo and something you'd actually use.

The memory layer: Backboard

Unstick remembers how you act, never what you said.

After you complete an action, the app stores an abstract signal in Backboard:

json

{
  "goal_id": "abc123",
  "energy": 2,
  "minutes": 15,
  "time_bucket": "evening",
  "action_type": "file_rename",
  "completed": true
}

No content. No goal text. No draft titles. Just six fields about what kind of moment this was.

On the next request, Backboard's semantic search returns the signals that match the current state: "This user completes file-rename actions at 9pm with energy 2 about 80% of the time." That context shapes which candidate the model ranks highest.

The record() method enforces the boundary at the code level — any field outside the allowed set raises ValueError. There is no path by which your draft titles or half-formed thoughts reach Backboard.

Deployment: Render

The whole thing runs on Render — FastAPI backend, static frontend, one service. The deployed version uses Tinker for both candidate generation and classification (Ollama doesn't run on Render's free tier).

Live URL: unstick-api-c7va.onrender.com

Cold start is 60–90 seconds on the free tier. Subsequent requests are fast.

Why Does Open Innovation Matter?

Three specific reasons, not abstract philosophy.

1. The content never leaves your machine.

The raw material for a portfolio is unfinished work. Half-drawn things. Abandoned drafts. Songs you're embarrassed by. That's the most personal stuff a person owns, and it's exactly the stuff that has to go into the tool for it to be useful.

If this ran on a closed API, every abandoned draft and every "I don't know what I'm doing" brain-dump would sit on someone else's server. With Gemma running locally through Ollama, it doesn't. That's not a talking point — it's the reason the tool can be honest with you.

2. The classifier is trained on one person's patterns.

I fine-tuned the model on 100 examples I labeled by hand. Not 100,000 scraped examples. Not a commercial dataset. Mine. The fail taxonomy — reveals_scope, needs_new_skill, needs_decision — those categories exist because I noticed those were the exact things that make me freeze.

You cannot fine-tune a closed API on one person's patterns. The model belongs to a vendor, and you get the vendor's judgment about what "good" means. With Tinker and an open-weight base model, the model belongs to me.

3. It costs nothing to run.

Gemma 2B runs on a laptop with no GPU. Ollama serves it with one command. The local version of Unstick costs $0 per message. I can use it 30 times a night without thinking about the bill. For a tool designed to be used 30 times a night, that matters.

4. The model is swappable.

I ran Gemma, then Llama, then Qwen on the same prompt during development. I swapped the classifier architecture between fine-tuning runs. With a closed API, you get one model and one behavior, forever. With open weights, the whole design space stays available.

That's what open innovation made possible here: a tool that was honest because it was private, and personal because it could be trained on one person.

My Agent Session

The whole project was built with GitHub Copilot's coding agent. You can see it in the git history — Copilot commits its own session state:

text

261a8ba Wire Backboard behavioural memory (signals only, never content)
0d7f165 Agent host session 177818fb-a6ca-41c7-be2d-f5476e619709 - turn 1
db22d40 Drop separate static service; FastAPI serves the frontend
242fbbb Serve frontend from FastAPI at root; use relative API base
33be99c Agent host session d5a1d459-9a19-48f0-93b5-d32eae080cc7 - turn 7
5aafbfb Wire Tinker fine-tuned classifier into the app
26d73d6 Fine-tuned Qwen3-8B via Tinker: 27% -> 70% accuracy on held-out set
03d3beb Agent host session 4de8b0e3-5d57-4107-917a-5535793c011b - turn 3
7cb3fd0 Build Unstick scaffold

Three Copilot agent sessions are visible in the log:

4de8b0e3-5d57-4107-917a-5535793c011b — initial FastAPI + frontend scaffold
d5a1d459-9a19-48f0-93b5-d32eae080cc7 — Tinker integration
177818fb-a6ca-41c7-be2d-f5476e619709 — Backboard wire-up

What Copilot did well:

Scaffolded the entire repo from a single mega-prompt
Wrote the FastAPI backend, frontend, and test suite
Created the GitHub Actions workflow and initial render.yaml
Correctly refused to invent Tinker API endpoints (left TODO: verify docs comments)
Debugged the Datum length mismatch after I described the exact error

Two bugs Copilot missed that I fixed by hand:

Constraint checker was treating the user's available minutes as the action's duration, so every action failed the "5 minutes" rule. Fixed by removing the state read and only checking the action text.
Tinker Datum construction used only the prompt as model_input while target_tokens used the full sequence, causing a 3-token mismatch. Fixed by using full_ids[:-1] as input and full_ids[1:] as targets, then adding an assertion to catch future mismatches.

Prize Categories

Tinker (Thinking Machines) — Fine-tuned Qwen3-8B with LoRA on 100 hand-labeled examples. Base model: 27% accuracy. Fine-tune: 70%. Fail-F1: 0.37 → 0.94. Full recipe in training/tinker_finetune.py, evaluation in eval/run_eval.py.

Render — Live app at unstick-api-c7va.onrender.com. FastAPI backend + static frontend, one service. Deploy config in render.yaml.

Backboard — Behavioural memory layer storing only abstract signals (never content). Verified end-to-end: stored a signal, searched for it, got it back with a 0.61 relevance score.

GitHub Copilot — Whole project scaffolded in agent mode. Three session IDs visible in the git log. Two Copilot bugs caught and fixed by hand.

Ollama + Gemma 2B — Local open-weight model for candidate generation. Runs offline, costs $0 per message, keeps the raw brain-dump on the user's machine.

FastAPI + Pydantic — Backend. Tests pass, CI green.

What I Learned

The hard part wasn't the fine-tune. It was deciding what "bad" means.

Defining the six failure categories was the real product work. Once I could name why an action was bad — reveals scope, needs a decision, requires a new skill — the classifier became tractable. Without those labels, the fine-tune was just vibes.

Open-source AI is a specific advantage, not a slogan.

For this project, "open" meant four concrete things: the drafts stay on my laptop, the model is trainable on my patterns, running it costs nothing, and I can swap the base model when I want. All four of those are real features, not philosophy.

The base model is 27% wrong in ways that look helpful.

The most important finding: the base model didn't produce garbage. It produced generic wellness advice that looked reasonable. "Stand up and stretch." "Take a walk." Those are fine sentences. They're just not portfolio actions. A closed API would have shipped that behavior forever because it looks fine in a demo. The fine-tune is what catches it.

Built for the Hacktoberfest Weekend Challenge: Build for a Friend.