meridiana's Cargo.toml documents the three build settings people reach for and refuse

The release profile is a guard, and the comment explains why

The manifest contains the best-documented build configuration in any repository I have read, because the comment block is a record of decisions already made and rejected.

The values are all the compiler defaults, stated explicitly so the reasoning survives. And the block is labelled a guard rather than a tuning panel.

Three settings are called out as the ones people reach for when they want a more optimised release build, and all three are left off.

Link time optimisation is described as one and a half to two times slower to build for a binary twenty to thirty percent smaller, with a note that a roughly 768 crate dependency closure makes it the single most expensive thing you could add.

Single codegen unit is described as measured slower than the default, citing a benchmark that compared six values and found single unit about thirteen percent behind, and the verdict is that it is not a free win but a regression.

Aborting on panic is rejected on different grounds: it would save five to ten percent of codegen but breaks catch-unwind and changes crash behaviour, and the line about shipping a data daemon is doing the real arguing there.

What remains is a comment explaining why the optimisation level stays where it is, because the session distiller's embedder does real matrix work and lowering it would be an unmeasured runtime regression, with a note to revisit only with a benchmark in hand. And a note that symbol stripping stays off because the symbol table is what makes a shipped user's exported diagnostics backtrace readable, at no build cost.

Intel is unsupported in the release build but builds from source

There is a small asymmetry between the requirements table and the source build section, and it is the kind of thing worth catching before you file a bug.

The system requirements table lists macOS with Apple silicon only, and says explicitly that Intel is not supported.

The build from source requirements list macOS, and there both Apple silicon and Intel are named.

So the shipped binary is Apple silicon only while the source compiles on Intel. That is a normal division for a project whose release pipeline builds signed installers on one architecture, and it is not a contradiction.

The same table gives the resource envelope, which is unusually concrete. CPU at five to ten percent average, running quietly in the background. Memory between half a gigabyte and three. Storage about twenty gigabytes a month, with older capture pruned automatically after thirty days.

Windows 10 and 11 are supported alongside macOS. And the database is stated as encrypted at rest, which is the single most important line in that table for a tool that records everything you do.

The value is reconstruction from screen activity, not a journal you keep

Every feature in this project follows from one decision: the record is built from what happened on screen rather than from anything you type.

The day is rebuilt from actual screen activity so you can scrub back through it like a recording instead of trying to remember. The day summary tells you what you got done and what pulled you off plan. The worklog update is drafted and left ready to post, so you review and send rather than write.

The questions table is the clearest statement of the value, because each row is a question you would otherwise answer badly. What did I actually do on this ticket gets an update drafted from what you did. What was I working on three months ago today works because every day is saved as it happens. What did I get done yesterday is answered from an overnight standup draft. Why did this take five days when we estimated two is answerable because what happened is logged, so you can see where the estimate went. And where does my time actually go is answered with tracked hours rather than a guess.

That last row is the one that changes behaviour. A tool that tells you your time is not where you thought it is worth having even if you never use the ticket drafting.

Pruning after thirty days is a policy, not a setting

The storage line deserves to be read on its own.

About twenty gigabytes a month, with older capture pruned automatically after thirty days.

Thirty days of history, and then it is gone. That is the retention window, and the word automatically is doing the work: there is no setting that extends it.

For the question the project advertises most loudly, asking what you were working on three months ago today, thirty days does not cover it. The day reconstruction and the ticket drafting work inside the window. Anything older requires a tracker to have kept the record, not this tool.

That is a defensible default rather than a flaw. A tool that watches a screen indefinitely accumulates enough to be a liability, and a hard automatic window is a stronger privacy guarantee than a configurable one that defaults high. But it does mean the retention policy is part of the product rather than a detail, and anyone whose real question is about last quarter will be disappointed.

The volume also deserves a moment. Twenty gigabytes a month is not nothing on a laptop, and it is a consequence of storing screen activity rather than text summaries.

Only what a summary needs is sent to the provider

The privacy section is short and the sentence carrying the most weight is the second one.

Activity stays in one encrypted database on your machine. Analysis runs through whichever provider you connect, and only what a summary needs is sent to it. Diagnostics are opt-out and stripped of anything identifying before they leave the device.

Three claims, and the middle one is doing the design work. The tool is not purely local, because summarisation is a model call and the model runs somewhere you did not choose. What it claims is a minimisation boundary: the raw screen activity record never leaves, only what the summary needs.

That is the right shape for this class of tool. The alternative, sending the day's activity wholesale and summarising remotely, would give the provider a complete record of your working day for the privilege of a paragraph. Sending the minimum makes the remote component a function of the output rather than of the input.

Diagnostics being opt-out rather than opt-in is the weaker of the two claims, and being stripped before they leave is the part that matters. Opt-out means the default is on, so the stripping is what protects you, not the consent.

The dev script opens two windows and capture lives inside the tray

The source build is five commands and the explanation afterwards is what makes it usable:

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

That last script opens two terminal windows: the Rust daemon and the Tauri tray. Both rebuild automatically when you save a file.

Then the sentence that answers the question every multi process project invites, which is what has to be registered or installed separately. The answer is nothing, because capture runs in process inside the tray.

That is a meaningful architectural choice. The obvious arrangement is a separate capture service, which then needs installing, starting, keeping alive and restarting. Folding it into the tray means one fewer process to supervise, and it means capture dies when you quit the tray, which is arguably the behaviour you want from a screen watcher.

The toolchain is pinned rather than floating. The Rust version is exact and pinned in a toolchain file that installs it automatically, Node is 20 or newer, and a specific runtime is required. Exact pinning of the compiler is what makes a build reproducible, at the cost of not building on whatever version happens to be current.

The release tooling package exists only to not be published

There is a package manifest whose entire purpose is to say it is not a package.

Its description reads: release tooling, not published, because the app ships as a signed macOS installer, with a pointer to the release configuration.

So the JavaScript in this repository exists to produce signed installers, and the manifest documents that so nobody tries to install it. The dependency list is four packages, all of them release automation: semantic-release with its changelog, exec, and git plugins, plus a conventional commits preset.

That is a small file that tells you a lot. There is no web application, no published library, no node package consumers install. The distribution channel is a signed installer image, which is the right choice for a tool that needs screen recording permissions and a login item, and which also means there is no update path through a package manager.

The Rust side is a workspace of four members: the root package, a core library, an OAuth library, and the tray application. The root package description calls it an ambient developer efficiency tool that keeps Jira, GitHub and one more tracker in sync, which is a more specific claim than the repository name suggests.

An environment file with an optional auth worker, and an explicit bypass

The environment example is nearly empty, and the comments explain why each blank line is there.

There are two variables, both pointing at an OTP service: a URL and a client token. Both are blank, and the first comment says blank means the one-time-code sign-in flow is disabled.

Then the behaviour when it is blank is described in detail, which is the useful part. The wizard's email step reports that it is not configured on the first attempt and lets you continue without signing in. The comment names that shape as the same development bypass the previous authentication key had.

So an unset value does not produce an error. It produces a wizard that tells you the step is unconfigured and moves on. That is the correct way to handle a missing optional service: fail loudly in the message, gracefully in the flow.

The comment also records where the values come from for local work, which is a deployed instance of the worker in the repository's infrastructure directory, either staging or your own, so the real send and verify path can be exercised.

And the header notes that a release bakes this in while a source checkout runs without it, which is how the same file serves both.

Editorial conclusion

Use Meridian if you cannot remember what you worked on three months ago and your standup writing takes longer than the work did. The value is reconstruction from screen activity rather than anything you typed, so it is a record you did not have to maintain. Do not adopt it expecting it to run everywhere: Intel Macs are unsupported in the shipped build even though the source builds on them, and it costs about 20 GB a month until pruning kicks in. Four things to check before you install it. Whether your platform is supported, since Apple silicon and Windows 10 or 11 are. What the retention actually is, because capture is pruned automatically after 30 days, which is a policy rather than a setting. That you are comfortable with an always-on screen watcher, since that is the mechanism, and that diagnostics are opt-out rather than opt-in. And what leaves your machine, since analysis runs through whichever provider you connect and only what a summary needs is sent. Licence is MIT, releases are frequent, and the last push to main is dated 1 October 2026.

Frequently asked questions

Official sources

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