Merl: the project tracker behind the RELIGION
How a lightweight, AI-friendly project tracker became the institutional memory of a home-lab software shop: 425 tickets, 344 logged time entries, timers that auto-stop at quitting time, and a discipline that turns every lesson into a ticket.
I'm a software engineer with over forty years of writing code by hand, and I built Jimi the hard way, a market watchtower made trustworthy by process. This is the story of the tool that holds that process together: Merl, the project tracker behind the RELIGION. Where Jimi watches the tape, Merl watches the work itself: every ticket, every decision, every logged hour, every lesson learned the expensive way.
Merl is deliberately unglamorous. It's a plain, self-hosted issue tracker on the same home lab as everything else. No cloud, no per-seat subscription, no phone-home telemetry. Just a fast dark UI (designed to be pleasant because you live in it) and a database that never forgets.
The ledger of the whole project
Every change in this shop is a ticket. That's the rule, and it's not cosmetic. Before a line of code is written, the work becomes a Merl ticket with a running timer. The timer is the point: it forces every change to be accounted-for work, not fog. The ticket records what was done, the comments record why, and the time entry records how long. When a ticket closes, the lesson it encodes is already written down, recoverable, searchable.
Merl tracks the work; git tracks the software. Every code change is committed to a git repository with its own history (the file-by-file, commit-by-commit record of what the code became) while Merl holds the why, the tickets, and the timers. The two fit together: the ticket is the story, git is the source of truth for the code, and neither quite works alone.
That's what makes the discipline hold together across months and dozens of projects: Merl is the long-term memory. Past a certain point you stop rediscovering the hard way, because the hard way is already in a ticket.
What's in it
Merl isn't a toy. As of the week this was written, it holds 425 tickets across eleven projects, 344 logged time entries from 14 users (humans and AI agents alike), and every one of them browsable from the dashboard below.
Projects, tickets, and the work of record
The projects view is where the lab shows up as a list: Jimi, the watchtower, with its 199 tickets; System, the infrastructure backlog; Merl itself; and the rest. Each row carries its logged hours, so you can see at a glance where the time went, not where you'd like to think it went.
The project board is the heart of it: search that works, an All/Mine toggle, and a priority-plus-status that reads in one glance. But the real power is on the ticket itself, shown below.
One ticket, end to end
Open a ticket and you get the life of a piece of work: the description that says what was decided, the assignee — frequently an AI agent working alongside the engineer — a timer, and a threaded comment history that reads like a proper after-action log. Comments can carry code, screenshots, and links, and every one is attributed and timestamped.
This is where the RELIGION becomes visible. A real change goes through comments like "follow-up #2: Signals + Alert sounds tiles rebuilt to the SAME label-left/input-right row style," with the reasoning and the follow-ups attached. Nothing ships as a blank guess; it ships as a reviewed, logged, timed ticket.
Timers that respect your day
Time tracking is usually the part of project management everybody hates, so we made it the accountable part instead. Every ticket has a timer you can start and stop. Merl even auto-stops at your quitting time. It's scoped to a workday, so a forgotten timer can't quietly bill you overnight. Hours accumulate per ticket and per project, and the recent-entries list keeps an auditable trail of what got worked and when.
Because the timer is tied to the ticket, the hours and the history stay together. That coupling is what makes the time entry more than a number: it's evidence of a decision, logged against the work it belongs to.
Built for the AI-agent workflow
Merl wasn't just made by an AI-assisted team. It was designed so an AI agent could work inside it the same way a person does. The life cycle (create a ticket, comment on it, start a timer, stop it, log the hours, close it) is a first-class JSON API, not just a set of buttons. When I say "file a ticket," it's filed correctly because the agent talks to the same store the UI does, through the same authenticated endpoint.
The API is how an agent becomes a real member of the team. It can create a ticket for every change it makes, start and stop its own timers so every hour it works is logged, append comments with its reasoning, and close work out with the details attached. The timer running on this very article — you'll see it in the screenshot — was started by the agent, not by me.
That's a quiet but important design choice. A tracker is only as disciplined as its workflow is easy to follow, and making the API first-class means the discipline survives even when the human walks away from the keyboard.
What Merl taught me
The tool that changed everything wasn't a smarter indicator or a faster feed — it was remembering. Merl is where the lessons live, and the lessons are what make the software trustworthy. A market watchtower needs to refuse stale data; a project tracker needs to refuse forgotten work. Same instinct, same RELIGION: write it down, time it, own it.
Written Saturday, from a desk in the lab. No keys, credentials, or addresses appear here by design.
Revised 24 Oct 2026: a verbal tic, edited out. Revised 24 Oct 2026: punctuation and filler trim.— T.D. Brace & Rupert
Comments
No comments yet.
Please sign in to comment. Create an account if you don't have one.