DEV Community: Arnulfo

Modo Tortuga: a local Gemma that turns a 30-item to-do list into three tiny first steps

Arnulfo — Mon, 26 Oct 2026 03:35:40 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge: Week 3.

What I Built

Modo Tortuga ("Turtle Mode") is for the days when the list is so long that the laziest option is to not start at all.

You give it a plain text file with up to 30 to-dos, one per line, written however you like. A Gemma model running on your laptop picks at most three and gives you a first step for each: something you can do in 15 minutes or less that leaves a small, visible result. Then it stops. It doesn't reschedule anything, send anything, or touch your calendar. It just points.

The effort it saves is the decision itself: reading the whole list, weighing dates against each other, and figuring out what "start" even means for a vague item like "prepare a presentation". Sloths don't plan the whole tree. They reach for the next branch.

I wrote it in Spanish because that's how I write my lists (I'm in Panama), so the output below is in Spanish with a translation.

Demo

A fictional list (no personal data), with optional [YYYY-MM-DD] deadlines:

[2026-10-24] Revisar lista de materiales para el taller del sábado
[2026-10-25] Preparar una presentación breve para el club de lectura
Ordenar fotos duplicadas de un viaje ficticio
Comparar tres recetas para una cena sencilla
[2026-10-23] Confirmar el horario del salón comunitario
Clasificar notas sueltas de un proyecto de jardinería
Escribir una lista de preguntas para la próxima reunión
Comprar cartulina para una actividad escolar ficticia

Real output from gemma4:e2b on an Apple M3 laptop with 8 GB of RAM, in 32 seconds, offline:

Modo Tortuga · empieza por esto (propuesta; tú decides):
1. Confirmar el horario del salón comunitario · vence 2026-10-23
   Primer paso: Buscar el horario del salón comunitario en línea
   Motivo: Confirma la disponibilidad del espacio.
2. Revisar lista de materiales para el taller del sábado · vence 2026-10-24
   Primer paso: Abrir la lista de materiales para el taller del sábado
   Motivo: Desbloquea la revisión de la lista.
3. Preparar una presentación breve para el club de lectura · vence 2026-10-25
   Primer paso: Abrir un documento y redactar el título de la presentación
   Motivo: Inicia la preparación de la presentación.

In English: "Turtle Mode · start with this (a suggestion; you decide): 1. Confirm the community hall schedule, due Oct 23. First step: look up the hall's hours online. 2. Review the materials list for Saturday's workshop, due Oct 24. First step: open the materials list. 3. Prepare a short talk for the book club, due Oct 25. First step: open a document and write the talk's title."

It picked the three dated items, in deadline order, and left the five undated ones for another day. That's the right call for this list. The first steps vary in quality, though. "Write the title" is a real, tiny start. "Open the materials list" is a step, but barely more than the task.

Code

yosef7 / modo-tortuga

Local first-step planner: Gemma in Ollama turns a long to-do list into three tiny first steps (Hacktoberfest 2026 DEV Challenge, Week 3)

Modo Tortuga

English: a local first-step planner. Give it up to 30 to-dos and a Gemma model running in Ollama on your laptop picks at most three, each with a first step of 15 minutes or less. Nothing leaves 127.0.0.1. Built for the Hacktoberfest Open-Source AI Challenge: Week 3.

Un prototipo local para esos días en que una lista de pendientes es demasiado larga para empezar. Lee hasta 30 líneas de texto y le pide a un modelo abierto que elija hasta tres primeros pasos. Muestra una propuesta; no cambia tareas, archivos ni calendarios.

Creado durante la ventana del Hacktoberfest Open-Source AI Challenge: Week 3, cuyo tema es Slow and Steady.

Código publicado bajo licencia MIT (ver LICENSE).

Probar

Requiere Python 3.10+, Ollama y un modelo compatible. No tiene dependencias Python de terceros.

ollama serve                         # en otra terminal, si no está activo
ollama

…

View on GitHub

One Python file of 138 lines, three unit tests, MIT license, and nothing to install from PyPI. It only uses the standard library.

ollama pull gemma4:e2b

python3 tortuga.py ejemplo.txt

python3 -m unittest -v test_tortuga.py

How I Built It

The pipeline is short on purpose:

Parse. Each line becomes {"id": "T3", "due": "2026-10-23", "text": "..."}. Dates only count if they're written explicitly. Comments (#) are skipped, lines are capped at 300 characters, and lists at 30 items.
Ask Gemma. The list goes to Ollama's /api/chat at 127.0.0.1:11434 with temperature: 0, think: false, and a JSON Schema in the format field. Ollama constrains decoding to that schema, so the model can only answer with 1 to 3 objects of id, first_step, why_now. The prompt asks for steps under 15 minutes that produce something checkable, and gives one example, because without it the small model tended to just repeat the task title.
Don't trust it. A schema can force the shape but not the content. So validate() rejects any id that isn't in the input, any duplicate, and empty or overlong text. The model never gets to invent a task, and the task text and date shown to you come from your file, not from the model.
Show, don't act. The result is printed and that's it. The prompt also tells the model not to suggest sending, paying, deleting or publishing anything on its own.

Here's the rule I ended up with: the model interprets the messy free-form list, and plain code checks every claim it makes about that list.

I chose gemma4:e2b because it runs on a base 8 GB laptop alongside everything else I have open. A bigger model would probably write sharper first steps, but then it wouldn't run on the machine I actually use.

Why Does Open Innovation Matter?

A to-do list is one of the most personal files you have. Mine has health appointments, money, and names of people I owe a reply. I'm not going to paste that into a cloud chat every morning. That's why this works better open than closed:

It stays on my machine. The code refuses any host other than 127.0.0.1:11434. The only internet use is the one-time model download.
It works offline, which means it works on a bus or with bad Wi-Fi.
It costs nothing per run. No API key, no quota. A tool you're supposed to use when you're tired can't have a "your credits ran out" moment.
It can be checked. Open weights and an open runtime let me pin the model and set temperature 0. With the same list, I get the same answer, which is what I want from something that tells me what to do.

Gemma's open weights and Ollama's open-source runtime are what make this a 138-line script instead of a service with an account, a privacy policy, and a bill.

The Lazy Payoff

Honest version: I haven't timed it against picking tasks by hand, so I won't claim a number of minutes saved. What I can measure is that it takes 32 seconds on my laptop and turns an 8-item list into 3 actions, and the first of those can be done in under 15 minutes. The real payoff is psychological: the time it saves is the time I'd spend staring at the list not starting.

The next step, which I didn't get to this week, is to log for a few days how long it takes me to start with and without it.

Prize Categories

Best Use of Gemma. The whole project is gemma4:e2b running locally through Ollama, with schema-constrained JSON output and validation on top.

Cuadre: turning Panama's paper receipts into a tax-ready spreadsheet, with Gemma on my laptop

Arnulfo — Mon, 19 Oct 2026 16:01:37 +0000

I started Cuadre for the Hacktoberfest Open-Source AI Challenge (Week 2: Side Hustle), but I didn't publish it before the deadline. It isn't a challenge entry. I'm sharing it anyway because what I learned building it is worth writing down.

What I Built

In Panama, almost every purchase a freelancer or a small business makes comes with a paper receipt. It has the shop's tax ID (the RUC) and a line for ITBMS, our sales tax: 7% on most things, 10% on hotels, 15% on tobacco. The ITBMS you pay on work purchases can often be credited against the ITBMS you owe each month (your accountant decides which purchases qualify). To get it, someone has to sit down at the end of the month and type every receipt into a spreadsheet. A shoebox of thermal paper becomes rows of merchant, RUC, date, subtotal, tax and total.

That someone is usually the freelancer at 11 p.m., or their accountant, who gets the receipts as blurry WhatsApp photos from 30 different clients.

Cuadre (from cuadrar, "to make the books balance") does the typing. You put the receipt photos in a folder and run one command. You get:

recibos.csv, one row per receipt, which opens cleanly in Excel;
resumen.md, with totals by month and category and the ITBMS paid;
a short list of the receipts a human should double-check, each with the reason.

The photos are read by Gemma, an open-weight model, running on my own laptop. They never leave the machine.

Who it's for:

Accountants with small-business clients. This is the strongest case: they transcribe receipts by hand every month, and they can't send their clients' data to a cloud service they don't control.
Freelancers who file ITBMS every month and want back the tax they paid on their own purchases.
Small shops, like a fonda (a small home-style restaurant), a hardware store or a repair shop, that keep receipts in a box until the accountant asks for them.

Demo

Six made-up Panamanian receipts, each one with a trap: a supermarket ticket with tax-exempt groceries, a fonda lunch where the tax rounds, a stationery store, a hotel taxed at 10%, the same stationery receipt photographed twice, and a handwritten kiosk receipt with no RUC and no tax line. Every merchant, RUC and amount below is fictional.

This is the actual output from Gemma on my laptop:

┌────────────────────────────────────────────────────────────────────────┐
│ Cuadre · 6 recibos                                                     │
│ Compras: B/. 146.43 · ITBMS pagado: B/. 10.98                          │
│ Listos: 2 · Para revisar: 4                                            │
│   ! 01-super.jpg: El ITBMS es 3,5 % del subtotal (lo normal: 7 %);     │
│     puede haber productos exentos                                      │
│   ! 04-hotel.jpg: El RUC «155612233-2» no tiene forma de RUC panameño  │
│   ! 05-papeleria-otra-foto.jpg: Posible duplicado de 03-papeleria.jpg: │
│     no se suma                                                         │
│   ! 06-kiosko.jpg: Sin ITBMS desglosado                                │
│ Leyó: gemma4:e2b, en este equipo                                       │
└────────────────────────────────────────────────────────────────────────┘

The interface is in Spanish because the people it's for speak Spanish. In short:

ITBMS paid: B/. 10.98, exactly right (0.83 + 0.60 + 1.05 + 8.50). The balboa (B/.) is pegged one-to-one to the US dollar.
Supermarket: the tax is only 3.5% of the subtotal. That's not an error, because some groceries are exempt, but it's worth a look.
Hotel: Gemma cut off the end of the RUC. The code noticed that the result doesn't look like a Panamanian RUC and flagged it. I left this one in on purpose: it shows the checks doing their job.
Duplicate photo: detected and not counted twice.
Kiosk: no tax line and no RUC, as expected for a handwritten receipt.

And this is the CSV an accountant would receive (first rows):

archivo,fecha,comercio,ruc,dv,factura,categoria,subtotal,itbms,total,estado,avisos
02-fonda.jpg,2026-10-05,FONDA DONA MERY,8-745-1290,12,000231,alimentación,8.50,0.60,9.10,ok,
03-papeleria.jpg,2026-10-07,PAPELERIA CALIDONIA,2556-112-251344,08,0012877,oficina,15.00,1.05,16.05,ok,
04-hotel.jpg,2026-10-09,HOTEL BRISAS DE BOQUETE,155612233-2,57,H-00981,hospedaje,85.00,8.50,93.50,revisar,El RUC «155612233-2» no tiene forma de RUC panameño

How I Built It

Python standard library only at runtime, 42 tests, and a cache keyed by the photo's hash, so when you add next week's receipts and run it again, only the new photos are read.

The rule: the model transcribes, the code calculates. A small vision model reads printed text well, but it's not reliable at arithmetic, and a tax report can't contain invented numbers. So Gemma has exactly one job, which is to copy what is printed. Everything else is plain code:

Step	Who does it	Why
Read the photo	Gemma 4 E2B, locally through Ollama	The only step that needs a vision model
Shape of the answer	A JSON Schema in Ollama's `format`	Gemma can't return extra fields or invent a category
Amounts	`monto_de_linea()`	Gemma copies the whole line; the code separates the rate (7%) from the amount (0.83)
Dates	`fecha()`	Day first, the way Panama writes them
Sum, rate, RUC, date, duplicates	`validar.py`	Fixed rules. A doubtful receipt goes to "review" instead of being added silently
Totals	`informe.py`	`Decimal` math, so no rounding drift; duplicates are excluded

Gemma runs with temperature: 0 and thinking turned off: transcription doesn't need reasoning, and the same photo always gets the same reading. On a laptop with 16 GB of RAM and no GPU, a receipt takes between 6 and 27 seconds.

What testing taught me. The first version looked fine on paper. Then I ran it on real images, and Gemma taught me three things:

What I saw	What I changed
In the `itbms` field, Gemma copied the label `"ITBMS 7%"` instead of the amount, on all six receipts. The code doesn't make up numbers, so all six came out "doesn't balance"	Ask Gemma for the complete printed line (`ITBMS 7% 0.83`) and let the code pull out the last amount, ignoring percentages
On the hotel receipt, Gemma dropped the last part of the RUC	Nothing to fix in the model: the RUC shape check caught it. That's the point of having checks
On the handwritten kiosk receipt, it put the date `10/10/26` in the subtotal field, and the code read it as B/. 26.00	A line shaped like a date is never an amount. If the date is missing and turns up in another field, the code recovers it from there

After those changes, the run is stable: the exact ITBMS total, the duplicate excluded, the exempt items detected, and every doubtful receipt marked for review.

One limit I kept on purpose: Cuadre checks the shape of a RUC, not its check digit, because I haven't verified the tax authority's algorithm. It says so instead of pretending.

Why Open Models Matter Here

A receipt is personal data. It tells you where someone shopped, what they bought, when and how much. A freelancer's receipts also reveal who they work for. For an accountant, uploading those photos to a cloud API means handing their clients' data to a third party. With Gemma running in Ollama, the only connection Cuadre makes is to localhost:11434. The code doesn't accept any other address. Nothing leaves the office.

The business only works if a receipt costs close to nothing. An accountant with 30 clients and about 100 receipts per client reads around 3,000 receipts a month. With a local model, that costs the laptop's electricity. There's no per-image fee that grows with every new client and no quota that runs out at the end of the month, which is exactly when everyone files.

I can't be locked out. If a provider raises prices or retires a model, Cuadre keeps working: the model is on the disk, and swapping it is one flag (--modelo gemma4:e4b on a machine with more memory).

I could shape the model around the job. Because the runtime is open, I could constrain the output with a schema, turn off thinking, fix the temperature, and see exactly how Gemma failed. Then I could build a check around each failure. With open weights, the next step is possible too: fine-tuning Gemma on anonymized Panamanian receipts so it cuts fewer RUCs.

To be honest about the trade-off: a large hosted model would probably make fewer reading mistakes. But for this job, privacy and a near-zero cost per receipt matter more, and the small model's mistakes are the kind the code can catch.

What's Next

So far I've only tested Cuadre on the six fictional receipts above. The next steps are running it on real receipts (without publishing them), putting it in front of an accountant to see whether they'd actually pay for it, and opening the repository.

AI assistance disclosure: I built Cuadre with Claude Code (Claude Opus 5.5) as my coding agent. It implemented the code, tests and documentation, generated the demo receipts, and drafted this post from the recorded test runs. I chose the idea and the Panamanian tax rules to check, and reviewed the results.

Ventana seca: finding the dry hour to get outside in Panama's rainy season, with Gemma on my laptop

Arnulfo — Wed, 07 Oct 2026 02:08:46 +0000

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

What I Built

October is the heart of the rainy season in Panama City. Most afternoons, the sky opens up somewhere between 1 and 5 p.m. A weather app gives me a percentage for every hour and leaves the decision to me, so I end up checking the screen over and over, or I just stay inside.

Ventana seca ("dry window") answers one question: when today can I be outside without getting soaked or cooked?

I don't have a free weekday morning for a trail. My chance to be outside is my daily route: on foot near Plaza 5 de Mayo at 7:30 a.m., arriving in Costa del Este at 8:00, lunch at noon, heading out at 4:00. So the main mode takes that route, checks the forecast for each stop, and tells me which stop is worth spending time outdoors, plus what to carry for the whole day. On weekends, a second mode looks for the best window at a park like the Parque Natural Metropolitano or the Cinta Costera.

You run one command in the morning, read one card, and optionally save a calendar event that alerts you 30 minutes before. Then the phone goes back in your pocket. The screen should be the shortest part of the experience.

Demo

This is my real route for Tuesday, October 6, with the real forecast and Gemma choosing on my laptop:

The 7:30 and 8:00 stops look dry (20% and 18%). Noon brings a 66% chance of rain with a 39 °C heat index, and 4:00 p.m. is at 88%. Gemma picks 8:00 a.m. in Costa del Este, and the raincoat goes on the list from the morning because of the afternoon.

Here is the same route when I write, in my own words, that I want to walk during lunch:

Gemma respects the time I asked for and warns me about the rain and heat. The red Ojo ("heads up") line is not written by the model. The code adds it whenever the chosen window scores poorly. I'll explain why below.

Watch the 31-second demo video. It has no narration and shows the command and the resulting card for three scenes. The interface is in Spanish, because the people I built it for speak Spanish.

Code

yosef7 / ventana-seca

Find the rain-free window to go outside in Panama City, chosen by Gemma running locally. DEV Hacktoberfest 2026 · Week 1: Touch Grass

Ventana seca

En octubre llueve en Ciudad de Panamá casi todas las tardes. Ventana seca mira el pronóstico por hora de los próximos días, calcula los tramos de luz con menos lluvia, calor y sol fuerte para salir a caminar o correr, y deja que Gemma, un modelo de pesos abiertos que corre en tu propio equipo con Ollama, escoja uno según lo que tú le pidas. El resultado es una tarjeta de un vistazo y un recordatorio en el calendario que avisa media hora antes, para que guardes el teléfono y salgas.

In English. Ventana seca ("dry window") finds the best rain-free window to go outside in Panama City during the rainy season. It scores hourly forecasts from Open-Meteo, lets Google's open-weight Gemma model, running locally through Ollama, pick one of those windows based on what you ask for in plain words, and writes a one-glance card plus…

View on GitHub

MIT license, Python standard library only (plus pytest for the 25 tests). Setup:

git clone https://github.com/yosef7/ventana-seca.git
cd ventana-seca
uv sync
ollama pull gemma4:e2b
uv run python -m ventana_seca --ruta "7:30 5 de mayo, 8:00 costa del este, 12 pm costa del este, 4 pm costa del este"

The route is saved, so the next mornings it's just uv run python -m ventana_seca --mi-ruta.

How I Built It

The split: code calculates, the model interprets. Numbers are where a small model is most likely to slip, so the code handles all of them:

Forecast. Ventana seca asks Open-Meteo for hourly rain probability, millimeters, heat index, UV and daylight. It asks for the coordinates of the place (a park, a plaza), never mine, and keeps a local copy so it still works without signal.
Scoring, no AI. Each window starts at 100 points and loses points for rain probability, expected millimeters, heat index above 32 °C and UV above 7. The code keeps up to five daylight windows, at most two per day and at least three hours apart, so there are real alternatives (morning vs. late afternoon). In route mode, each stop of my day is a candidate.
Choice, with Gemma. Gemma 4 E2B runs locally through Ollama (the 4.6 GB Q4_K_M build, on a MacBook with 8 GB of RAM). It receives the candidates with their forecast and whatever I wrote: "quiero caminar en la hora del almuerzo", "voy con mi hija de 6 años, que no aguanta el calor". Its reply is constrained with Ollama's structured output: a JSON Schema whose ventana field only accepts the labels of the computed windows, and whose llevar (things to carry) field only accepts items from a closed list.
Validation and fallback. If Ollama isn't running, or the answer is invalid, a fixed rule picks the highest score. The tool always answers.
Non-negotiables in code. Water always; raincoat at 30% rain or more; cap and sunscreen at UV 6+; repellent on forest trails; a flashlight if the window touches darkness. In route mode they're computed for the whole day.

What testing with the real forecast taught me. The first version worked, and then the real runs showed me five problems. Each one changed the design:

What I saw	What I changed
With Gemma 4's thinking mode on, a choice took 38 to 114 seconds	Picking among five options doesn't need long reasoning: `think: false` brought it down to 7–9 seconds
Gemma called a 53% chance of rain "poca probabilidad" (low probability)	The code now adds the Ojo line for any window scoring under 60, whatever the model says
Gemma wrote "la opción B" in its explanation, a letter the card never shows	Gemma now chooses among readable labels like "mar 6 oct, 12:00 p. m. en Costa del Este", so there's no internal code to leak
Asked for lunch, it picked 8:00 a.m. without saying why it rejected noon	New instruction: if the requested time exists, honor it and warn clearly
It offered 7:00–8:00 and 8:00–9:00 as different options	Windows on the same day must be three hours apart

The pattern I ended up with: the model is good at understanding what I want, and the code is in charge of the facts and the safety warnings. Every number on the card comes from the forecast, never from the model.

The full list of decisions is in docs/arquitectura.md, and every test run is in docs/validacion.md.

Taking It Outside

On Tuesday, October 6, I followed my usual route with the card from the demo above. Here is the forecast next to what actually happened:

Stop	Forecast	What happened
7:30 a.m. · Plaza 5 de Mayo	20% · 31 °C · dry	Dry
8:00 a.m. · Costa del Este	18% · 31 °C · dry	Dry under a gray sky
12:00 p.m. · Costa del Este	66% · 39 °C · rain and heat	It rained
4:00 p.m. · Costa del Este	88% · 31 °C · rain	It rained

The day went the way the card said it would. The stop Gemma picked, 8:00 a.m. in Costa del Este, was dry. I took this photo at 8:15:

Then noon arrived as forecast. At 12:43 p.m., through a window in Costa del Este, the rain was streaking the glass and the hills in the distance had disappeared:

The raincoat, which the card put on the list in the morning because of the afternoon, was needed twice. At 5:52 p.m. the pavement was still wet:

One honest detail: when I checked Open-Meteo's hourly record for the same coordinates that night, it showed the storm between 11 a.m. and 1 p.m. (8.3 mm at noon) and 0 mm at 4 p.m., even though I saw rain in the afternoon. The record is a model estimate for a grid cell several kilometers wide, and a local afternoon shower can fall outside it. The full comparison is in docs/validacion.md.

Why Does Open Innovation Matter?

What I write about my day stays on my laptop. The preference text can be personal: when you leave work, who you're going out with. The saved route is literally my daily location pattern. With Gemma running locally, none of that goes to a server. The only request that leaves the computer is the forecast, and it carries the coordinates of a public place, not my GPS, with no account and no API key.

It costs nothing to run every morning. No per-request fee, no quota, no subscription. That matters for a tool you're supposed to use daily.

I could see and change how the model behaves. Because the model and the runtime are open, I measured the thinking mode, turned it off, and constrained the output with a schema. When the model softened a 53% rain chance, I could build a guardrail around its exact behavior instead of hoping a hosted API wouldn't change under me. The model is also swappable with --modelo, for example gemma4:e4b on a machine with more memory.

It works where the signal doesn't. Gemma doesn't need the internet, and the forecast is cached. On a trail with no coverage, the card still comes from the last forecast and says when it was saved.

To be honest about the trade-off: a large hosted model would probably write nicer explanations. But this job needed control and privacy more than eloquence, and the small model's mistakes are exactly the kind the code can catch.

Prize Categories

Best Use of Gemma. Gemma 4 E2B, running locally with Ollama, is the decision-maker at the core of Ventana seca. It interprets a free-text preference, chooses among computed windows through a constrained JSON Schema, and writes the explanation on the card. Its behavior shaped the design: thinking mode off for speed, readable labels instead of letters, and a code-side warning when it understates risk.

AI assistance disclosure: I built Ventana seca with Claude Code (Claude Opus 5.5) as my coding agent: it implemented the code, tests and documentation, generated the demo, and drafted this post from my route and the recorded test results. I picked the idea, supplied my real route, reviewed the results and tested it on my own commute.

Sendero: a local catechesis record with open AI for a chapel community in San Miguelito, Panama

Arnulfo — Sun, 04 Oct 2026 14:51:26 +0000

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

What I Built

Sendero is a catechesis record built for the community of the Capilla Nuestra Señora de Lourdes in Valle de Urraca, San Miguelito, Panama. The chapel's catechists accompany children through several stages of formation, and they need one reliable place to record each child's journey: enrollment, attendance, the formation received, the requirements met, and each change of stage.

Sendero turns that record into preparation for the next meeting. Its Spanish interface brings together periods, groups, participant profiles, multiple responsible adults, attendance, observations, stage requirements and a chronological history.

The open AI feature is at the start of each child's page: Preparar acompañamiento. An open-weight model selects and prioritizes two or three reviewed preparation actions and a question for the child's responsible adult, using the current requirement states and attendance counts. The proposal is saved with its model and evidence snapshot. If the record changes, Sendero marks it outdated.

The catechesis team can create a dated period and its groups, enroll a participant with multiple responsible adults, record attendance and class topics under that enrollment, and consult the complete history. Existing profiles survive the schema upgrade; new enrollments do not duplicate the participant. A catechist can mark a current AI proposal as reviewed, which records the review without changing requirements or stages.

The goal is deliberately modest: help the team arrive at the next meeting knowing what to review, while every decision about a child's progress remains with the catechists.

Sendero is intended to be handed over to the chapel community. So far I have tested the working prototype with fictional records only. Reviewing the actual stage names and requirements with the catechesis team is the next acceptance step; I do not yet have their feedback to report.

Demo

Watch the 49-second demonstration.

The recording shows the complete workflow: login with a fictional demo code, period and group creation, a participant with two responsible adults, attendance and a class topic, an observation, a real local model proposal, human review, and persistence after reload. All displayed records are fictional. The application is in Spanish; the video has no narration, and the wait while the local model generates its proposal is shown in real time.

Code

Source code, setup instructions and MIT license.

The model has its own license: the Qwen2.5-Coder-3B-Instruct model card identifies it as qwen-research. The application's MIT license does not change those model terms.

How I Built It

The application uses Python, Flask, SQLite, plain JavaScript and Ollama. I chose the available local qwen2.5-coder:3b model for the prototype and kept the adapter configurable through OLLAMA_MODEL.

The modules separate the interface, HTTP API, formation rules, persistence and local inference. SQLite foreign keys and transactions keep the records consistent; stage advancement also checks the expected current stage to reject a repeated transition. Versioned migrations add saved AI proposals, periods, groups, enrollments, responsible adults and human review without replacing existing child records. An invalid initial enrollment rolls back the entire new profile. Attendance must belong to the participant and fall within the enrollment period.

The model receives a small context: numbered requirements and their completion states, recorded-class and attendance counts, the current stage identifier and whether another stage exists. Names, contacts, class topics and free-text observations stay out of the model request.

My first free-text generation was structurally valid but suggested details not supported by the record. I changed the design: the JSON Schema supplies an allowed catalog of actions and questions, and the server validates membership and rejects duplicate actions before saving. The model can choose and prioritize within that catalog; it cannot introduce a new requirement through its response.

That is a deliberate limit on generative freedom. Sendero never treats AI output as proof that a requirement is complete, and the model has no tools to write to the formation record.

The expanded workflow passes 26 automated tests. The final Chromium run completed login, period and group creation, enrollment with two responsible adults, attendance and topic entry, local inference, review, reload and a mobile contact edit with zero JavaScript errors. Four views at both 390 and 320 pixels had no horizontal overflow. Those are emulated mobile checks, not a test on a physical phone.

In the recorded run, the real Ollama request returned a valid proposal in 17.79 seconds, with the model not yet loaded in memory; an earlier run with the model already loaded took 3.34 seconds. These observations describe this machine and those requests, not a performance guarantee. The browser validation records the final checks. The previous three-case evaluation remains available as evidence from the earlier prototype.

The implementation follows Ollama’s structured-output contract. The earlier structural-validation approach was informed by DevShakib's article on structured output and Mukunda Katta's explanation of rule-based output validation. A valid response is still a proposal for the catechists to review, not a guarantee that its priorities are useful.

Why Does Open Innovation Matter?

This project concerns children, so local operation is a practical design choice. Once the dependencies and model are downloaded, recording and inference can run without an external inference service, a subscription or a paid API key. A parish community can keep its own records on its own computer, and the AI request carries only numerical progress information that never leaves that machine.

Open local inference also let me inspect the request, change the response contract after an unsatisfactory result, and repeat the experiment. The community can try a different local model through the same adapter, respecting its license, without rewriting the registration and formation modules. I have not fine-tuned the model or claimed that this is impossible with every closed API.

The current version runs on one trusted computer with a single shared access code. It includes local access protection, a downloadable SQLite backup and printable records. Individual accounts for each catechist, retention and consent procedures, testing on a physical phone and acceptance testing with the catechesis team remain future work. The demonstration uses fictional data throughout.

AI assistance disclosure: I used Codex to help implement, test and document Sendero, and to draft this article from the stated need and recorded validation results. I used Claude Code to revise the article and documentation for the community-focused version and to re-record the demonstration.