That Bro Who Ate With You Every Day Back in High School

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

The seat that went missing

Everyone goes through it, and nobody talks about it — because it feels too normal to mention.

You graduate high school. Your class scatters to universities in different cities, different countries. The group chat goes quiet, not from a fight, just from life. And one day you realize the friendship didn't end. It just stopped having a place to happen.

For me, that place was a lunch table.

Every noon in high school, Harold — my roommate, my friend — and I sat down together and ate. School was chaos: grades, gossip, teachers, pressure, the whole social weather system of being seventeen. But noon was the safe spot. Trays down, and for forty minutes we could talk about everything that wasn't school. Nothing important was ever decided there, which is exactly why it mattered.

Now Harold is at Rutgers in the US, and I'm at UofT in Toronto. We're not even that far apart on a map — and yet the number of meals we've shared since graduation is basically zero. The friendship is fine. The table is gone.

Here's the part that worried me. Harold is a huge foodie, but he's also aggressively frugal. Left to himself at college, he eats at whatever cheap hole-in-the-wall is closest, quality be damned — and his stomach pays for it regularly. The only times he eats well are the times he's eating with people. Put him in a group and he'll follow everyone to the good place, no questions asked.

So I kept thinking: what if, when Harold is standing in front of some menu alone on a Tuesday, something small reminded him of our lunch table — and helped him choose a little more rationally, a little more healthily? Not a lecture. Not a diet app. Just a saved seat.

That's what I built.

What I Built

That Bro Who Ate With You Every Day Back in High School is a guided terminal app — bilingual, English and Simplified Chinese — that helps Harold decide what to eat, remember what matters about food, and keep a small companionship loop alive across the distance.

The core is one small question: does the preference I remember actually apply to this meal?

I can remember something correctly and still use it at the wrong time. A weekday habit may not apply on Saturday. An old note may need another conversation. A keyword match alone cannot settle either question. So the app works in two stages:

1. A local open-weight model (Gemma 3 4B, via Ollama) reads a pasted menu and extracts grounded food phrases — only phrases actually present in the text, returned as a small JSON array.
2. A food adapter maps those phrases to remembered concepts, and a deterministic, domain-neutral Python guard decides the memory action: USE, IGNORE, or ASK — each with a verdict and a reason.

The guard keeps an explicit precedence: revoked permission comes first; high-risk records (like allergies) always need human review; unresolved external facts need verification; out-of-scope or superseded records are ignored; supported current records can be used; uncertainty asks. It never certifies a dish as safe. A synthetic allergy record in the tests escalates even when the model finds no matching ingredient — because not finding a match is not proof the allergen is absent.

Around that core, the app is a small daily companion: two routes when you're hungry (too tired → takeout, up for a walk → cafeteria), a searchable 3,535-record offline food reference catalog, your own saved dishes and places, an optional after-meal journal, a "lunchbox" for exchanging notes with a friend as local files, and postcards you can export for the next meal together. Recorded prices keep their dates; today's availability is honestly marked unknown. Choosing an idea never records it as eaten.

Demo

Here's the full loop, captured from the app. The terminal shots run in demo mode with clearly labeled synthetic records; the postcard at the end is the real one I made for Harold after his trial.

The home table: "a seat saved for you." Two routes — too tired → takeout, up for a walk → the cafeteria.

Type "something warm" and it surfaces nearby food ideas — explicitly labeled as ideas, not listings. Ingredients, availability, and price stay unknown unless you supply them.

Pick one: "Ramen bowl with beef." Choosing an idea never records it as ordered or eaten — it just holds the idea for today.

And here's the guard doing its real job: paste an actual menu, and it checks remembered notes against it. The synthetic peanut-allergy record escalates for human review even with no matching ingredient detected — missing a match is not proof of absence. The weekday-vegetarian note is ignored because this meal date falls outside its scope.

The same idea in miniature — the same chicken dish, the same weekday-vegetarian memory, two different meal dates:

Meal date	Memory action	Why
Friday, October 2	USE	The preference applies on weekdays
Saturday, October 3	IGNORE	The meal falls outside the preference's declared scope

The model extracts the chicken phrase; the adapter creates the candidate. The same extraction feeds both cases — the difference in the decision comes from the guard's context (the meal date), not from asking the model to change its mind. Remembering correctly is not the same as applying correctly.

Try the synthetic walkthrough — no model download needed; it uses clearly labeled canned extractions:

git clone https://github.com/Jesse-Zeng423/that-bro-who-ate-with-you-everyday-back-in-highschool.git
cd that-bro-who-ate-with-you-everyday-back-in-highschool
python3 plate-memory.py --demo

For the real local-AI path (Ollama + Gemma 3 4B, everything on your machine):

OLLAMA_NO_CLOUD=1 ollama serve
# in another terminal:
ollama pull gemma3:4b
python3 -m src.cli --menu examples/weekend.txt --date 2026-10-03

The live local-Gemma evidence — Gemma 3 4B running on an 8 GB Apple Silicon Mac across four synthetic menus, all four producing the expected guard actions — is in the local-smoke-v11.json trace. That is an integration check, not an accuracy benchmark — I'm not claiming more than it is.

And the loop closes with the postcard:

A small note for your friend. Write it here, then send the file yourself — nothing is ever sent automatically.

"Same table, soon." Exported locally as HTML — no servers, no analytics, nothing leaves the machine unless you send it.

Code

Jesse-Zeng423 / that-bro-who-ate-with-you-everyday-back-in-highschool

Local Gemma menu extraction with a domain-neutral deterministic memory applicability guard. Built for a friend.

Plate Memory

v1.0.0 · usable local release — Download · Start here

That bro who ate with you every day back in high school.

Remember the preference. Check whether it applies today.

A guided local terminal app built for Harold, Jesse's friend and roommate from high school and a big foodie. Before planning a meal, it checks remembered preferences against the meal's actual context. Harold's specific preferences and trial feedback are still to be supplied; every profile and menu committed here is explicitly synthetic.

An open-weight model extracts food phrases from a pasted menu. A food adapter maps these grounded phrases to remembered concepts. A domain-neutral deterministic Python guard then decides which memories can be used, ignored, or need confirmation. A relevant memory can be stale or out of scope.

For example, a synthetic weekday-only vegetarian preference applies on Friday but does not apply on Saturday. A 2023 note about…

View on GitHub

I started this project during the challenge window.

How I Built It

The first version asked the small model to do too much — match multiple remembered concepts at once. It produced wrong matches and piles of uncertain candidates. I kept those traces (they're in the repo's diagnostics) and narrowed the model's job instead of hiding the failure: the model only copies food phrases from the menu text. A limited, explicit vocabulary table maps phrases to concepts — chicken can be a candidate for a poultry rule, coriander leaves for a cilantro rule, custom terms match literally. The CLI rejects anything not present in the source: no invented phrases, no duplicates, no extra fields, no duplicate JSON keys — and it attaches the original line as evidence.

Crucially, the model never sees the friend's profile. It gets menu text only — no names, no remembered text, no dates, no policy metadata. The adapter derives those from the local profile and the meal date, then calls the generic engine, which understands memory items, task context, and risk, with no food concepts hard-coded. Permission is checked locally before any remembered record can influence a recommendation.

The terminal interface is deliberate: everything stays in one place, bilingual from the first screen, with draft-preserving navigation (/back edits the previous answer, /home keeps a session draft, /cancel asks before discarding). Browsing needs no profile at all — and the app refuses to let "no profile" become an implicit claim of dietary suitability. Saved places keep prices with their observation dates; availability stays unknown unless the user supplies it. Postcards export as local HTML/PNG with no external fonts, scripts, or analytics; only previewed fields are shared; nothing is ever sent automatically.

Tests cover the boundaries I cared about: invalid metadata, a simulated model response attempting to inject a guard verdict, canned examples running from an unrelated working directory. 69 unittest tests and 43 pytest subtests on the core CLI, CI green, and the expanded terminal checks recorded in the repo's validation record. These establish rule behavior — not real-world extraction accuracy.

Handing it to Harold

Harold tried it — and the trial landed exactly where I'd hoped.

He said it's fun. And he told me that the next time he's stuck in front of a menu, unable to decide, he'll open this little program the way he'd text me: like a good friend who's always there to help him make the better food call.

That's the whole thesis of this project, confirmed by its one and only target user. Not a diet app, not a lecture — a saved seat. The lunch table, ported to a terminal, running on his own machine, waiting for the next time he's hungry and alone and about to pick the cheapest thing on the street.

Why Does Open Innovation Matter?

Because this is a tool about a friend's private life — and the architecture is the ethics.

The profile never leaves his computer. The model receives only menu text. The rules run locally and can be read by anyone: Harold can open the guard code and see exactly why a memory was used or ignored, which is more than any cloud recommendation service will ever show him. Once the weights are downloaded, there is no API key, no per-call bill, no account. The code is MIT; Gemma's weights are open under Google's Gemma Terms (I'm not claiming the weights carry the code's license); Ollama is MIT.

Openness is also what keeps the failure boundary visible instead of hidden: the model can misread a menu; the guard can't verify that manually entered metadata is true; ingredients and cross-contact need confirmation with the preparer. This is decision support, not medical or food-safety advice — and because it's open, that boundary is inspectable rather than a slogan.

Most importantly: anyone can fork this for their own version of Harold. The friendship that scattered after graduation is a universal story. The guard is domain-neutral by design — food is just this weekend's adapter. Your "bro from high school" might need something completely different remembered, and applied at the right time. Take the engine, write your own adapter, save your own seat.

Prize Categories

Best Use of Gemma: local Gemma 3 4B performs the grounded phrase extraction that feeds the food adapter — real inference, on-device, documented in the local smoke-test traces.