Meridian: an automatic work journal that drafts your Jira updates

The problem Meridian targets: work that never reaches the ticket

The README frames the problem as visibility rather than time. Its own question table asks "What did I actually do on this ticket?" and "Why did this take five days when we estimated two?", which is the shape of a developer who did the work but did not narrate it in the tracker. Meridian's answer is to stop relying on memory and instead reconstruct the day from what happened on screen, then turn that reconstruction into text you can paste or post.

The intended user is a developer on a ticket-driven team, working alone at a machine, who already uses Jira or a comparable tracker and an AI provider. The README lists Jira explicitly and the repository topics mention claude, chatgpt, gemini and mcp, so the assumption is that you already have a model endpoint you trust. It is not a team analytics product and it is not a timesheet system; the daily summary is written for the person who did the work.

How the capture, summary and draft pipeline fits together

The architecture is a Rust workspace with a daemon and a Tauri tray. According to the README's build section, `dev-start.sh` opens two terminal windows, the Rust daemon and the Tauri tray, and capture runs in-process inside the tray, so nothing else needs to be installed or registered separately. That is a meaningful design choice: there is no separate screen-recording helper to install, and the tray process is the one holding the capture path.

Data lands in a single encrypted database on the machine, and the README states that analysis runs through whichever AI provider you connect, with only what a summary needs sent to it. Older capture is pruned automatically after 30 days. The output side is the part that distinguishes Meridian from a plain recorder: the README describes an end-of-day summary containing completed tasks and an unexpected fix, a standup already written, and a worklog draft that waits for approval before posting to Jira. The approval gate is stated in the README and shown in the worklog-draft image caption, but the README does not describe what happens when a draft is rejected, edited, or posted to a tracker that is not Jira.

The workspace layout is worth reading before you contribute. `Cargo.toml` keeps a vendored fork of `tauri-plugin-clerk` as a workspace member rather than an exclude, with a comment explaining that excluding it would take it out of `cargo test --workspace`, `clippy --workspace`, `fmt --check`, CI and the pre-push hook. The same file warns that because `.` is a package, a bare `cargo test` skips the rest of the workspace. The release profile block is a deliberate guard: it states that `lto = true` makes the build 1.5 to 2x slower for a roughly 20 to 30 percent smaller binary, and that `codegen-units = 1` measured about 13 percent slower than the default 16 in the linked alacritty benchmark. That is unusually candid build documentation.

Building Meridian from source and running a first day

The README points packaged users at the download button on meridiona.com. For a source checkout, it lists Rust 1.93.1, pinned through `rust-toolchain.toml` so it installs automatically, plus Node 20+ and bun. The sequence below is copied from the README's Build from Source section.

git clone https://github.com/Meridiona/meridian
cd meridian
cp .env.example .env
bash install-dev.sh          # builds all dependencies
bash scripts/setup-hooks.sh  # install git hooks, run this before your first commit
bash dev-start.sh            # starts the daemon and the tray in watch mode

The `.env.example` file documents one variable, `CLERK_PUBLISHABLE_KEY`, and says a blank value means a dev build skips sign-in entirely, so a fresh clone just runs. Packaged builds always require sign-in regardless. If you want to exercise the real sign-in path locally, you set a Clerk dev instance key beginning `pk_test_`. The same file notes that tracker connections are made in the setup wizard and that tuning knobs live in CLAUDE.md, not in the environment file.

After `dev-start.sh`, you should see two windows: the daemon and the tray. Capture begins in the tray process. The README does not give a first-run checklist for verifying that capture is actually recording, so the practical check is whether the tray produces a timeline entry after a few minutes of normal work. The README also says full setup details, including how to reset onboarding and re-download the embedder, are in CONTRIBUTING.md rather than the README itself.

Storage, platform and privacy limits you should weigh first

The hard constraint is disk. The README's system requirements table gives about 20 GB a month, with older capture pruned automatically after 30 days. That is roughly 20 GB of steady-state usage on a laptop, and it is not configurable through anything documented in the README or `.env.example`. If you work on a machine with a small SSD, or you need a retention window longer than 30 days, the README gives you no documented knob.

Platform support is narrower than the build requirements suggest. The system requirements table says macOS Apple Silicon only, with Intel explicitly not supported, or Windows 10/11. The Build from Source section, by contrast, lists macOS Apple Silicon or Intel as build requirements. Those two statements are not reconciled in the README, and the discrepancy is worth resolving before you spend an afternoon on a toolchain that produces a binary the product does not support.

Privacy is the other limit. The README states that activity stays in one encrypted database on the machine, that only what a summary needs is sent to the connected AI provider, and that diagnostics are opt-out and stripped of anything identifying before they leave the device. All of that is a claim about behaviour, not a verifiable property from the README alone. There is a SECURITY.md in the repository, and it is the file to read if the summary payload boundary matters to your employer. The README does not document a rollback path for a draft that has already been posted to Jira, which is the failure mode most likely to annoy a colleague.

How Meridian differs from a time tracker or an MCP memory server

The obvious comparison is a manual time tracker such as Toggl or Clockify. Those ask you to start and stop a timer and assign it to a project; the data is a set of intervals you created. Meridian inverts that. It captures first and asks you to review afterwards, and the artefact it produces is prose (a summary, a standup, a ticket update) rather than a chart of hours. If your organisation bills by the hour, a timer is still the right tool, because Meridian's output is a narrative, not an invoice.

The second comparison is the MCP memory server pattern, which the repository topics reference. Those tools give an agent a store of facts it can query during a session. Meridian is the opposite direction: it observes the human and writes to the tracker. The two are not substitutes, and the README does not describe Meridian as an MCP server itself, only as a tool that connects to AI providers.

The closest thing to a direct alternative is a screen-recording or replay tool used for documentation. Those keep the recording as the deliverable. Meridian treats the recording as raw material and prunes it after 30 days, keeping the summary. That is a deliberate trade: you lose the ability to go back and watch a specific hour after a month, which the README's "three months ago today" question table implies you can still answer, presumably from the stored summary rather than the capture.

Maintenance, release cadence and licence terms

The repository is not archived, and the last push was on 2026-09-05. The recent releases listed are all staging builds of the same version line, v1.91.0-staging.7 through v1.91.0-staging.9, all dated 2026-09-05. That tells you the project is moving, and it also tells you the release notes surface is dominated by prerelease tags rather than stable ones. If you pin to a stable version, the README does not say which tags are considered stable or how long a staging line runs before promotion. `package.json` confirms the release tooling is semantic-release driven and that the app ships as a signed macOS DMG, per `.releaserc.json`.

The upgrade cost is mostly environmental. Rust is pinned in `rust-toolchain.toml`, so a checkout will pull the pinned toolchain automatically. The workspace includes a vendored fork of `tauri-plugin-clerk`, and the `Cargo.toml` comment states plainly that a future upstream re-sync may not be clippy- and fmt-clean, and that finding out at re-sync time is the point. Anyone maintaining a fork of this repository inherits that re-sync work.

Meridian is MIT licensed. That is permissive and permits commercial use and modification, but it is a licence identifier, not legal advice, and it says nothing about the terms of the AI provider you connect or the tracker you post to. Those are separate agreements and the README does not address them.

Editorial conclusion

Adopt Meridian if you work ticket-driven on macOS Apple Silicon or Windows 10/11, your tickets are the thing you keep forgetting to update, and you are comfortable sending summary-level material to an AI provider. Do not adopt it if you need Intel macOS support, if you cannot accept roughly 20 GB of monthly capture storage, or if your employer forbids screen capture on a work machine. Before committing, check SECURITY.md and SETUP.md for the exact capture scope and retention behaviour, and confirm that the tray's approval step is enforced for every tracker you connect.

Frequently asked questions

Official sources

1. License: MIT
2. Meridiona/meridian on GitHub
3. Project website
4. README
5. Releases