Protected build_application passed for the reviewed Budget candidate.
The import adapter keeps stable intent identity so a retry does not become another salary.
Actual Budget shows the sample household’s purchase, transfer and single salary entry.

One household, three different moments

A phone records a purchase while offline. A laptop transfers money between accounts. A tablet sends a salary import again because the first response was unclear. All three actions can be reasonable, yet a budget can end up with money that nobody actually received.

I built One Budget, Three Realities to follow those everyday actions through real Actual Budget processes. It starts from the MIT-licensed Actual project, with its original history and notices preserved. The work added after October 5 is the release companion, the controlled retry adapter, the independent accounting checks and the GitLab-to-Google-Cloud release path. The duplicate-income defect is an intentional change in our adapter.

Follow the transactions

The fixed synthetic household contains a $42 purchase split into $30 groceries and $12 household, a $150 transfer and one $500 salary intent. In the broken replay, a delivery retry becomes an extra economic action. The repaired version keeps the original intent's identity, so the salary appears once.

The useful result is visible in the records behind the balance. Checking ends at $1,308 and Savings at $2,150, for $3,458 in total. The evaluator reads actual exported SQLite data from three isolated Actual API processes. Its seven declared checks cover balanced transfers, coherent splits, one import intent per transaction, conservation, reconciliation, full-record agreement and accounting for acknowledged actions.

How the repair reaches the application

A fresh GitLab Duo Agent Platform investigation receives the source and failure case and proposes a focused edit to the import adapter. The controller checks the whole output before creating the candidate merge request. GitLab CI verifies the source, a protected build creates the application image, and separately approved staging and production checks exercise the real Actual processes.

This is an Assisted entry. The completed run used eight separately approved operator steps, exercised through authenticated automation. Its successful native proposal led to merge request 5, protected build, stage, promotion, production observation and the exact source merge. The public submission source and its CI are published separately from the private operational release controls.

What was difficult

A matching total can hide a missing transfer side or an incorrectly merged transaction. That is why the evaluator compares economic records and acknowledged intentions as well as balances. I also had to keep browser inspection distinct from the controlled three-process replay: the public evidence room shows the recorded scenario, while the separate Actual browser demo uses the visitor's own browser storage.

An earlier proposal removed the seeded demonstration branch and was rejected. Preserving that failure helped keep the repair honest. The completed October 23 run passed all seven invariants and retained the split purchase, the transfer pair and a single salary entry.

What I learned and what comes next

Retries need a stable meaning. A new HTTP delivery should not automatically become a new paycheck. This project made that lesson concrete by putting the actual records next to the release evidence.

The intended audience is people building financial import and offline-sync tools, and developers maintaining them. The demonstration uses a sample household and has no banking connection. Next I would add currency changes, more reconciliation cases and longer offline schedules, then ask people who use budgeting tools to review the workflow. The public walkthrough, short film, MIT source and deployment code make the current case inspectable.

Try the project | MIT source and CI | Watch the demo