Art Quest · Horror Cinema · MORPHEUS
Close it once.It closes everywhere.
For a three-brand company, money lived in one system, deals in a second, tasks in a third and server health in a fourth. Every morning the head of the company toured every one of them and built the day by hand. We built the command centre: a macOS app that pulls 15 sources into a single day plan. A “done” mark passes through a ledger and a delivery queue, then closes the item in Asana, and after that in the day plan and the CRM.
In daily use · since 10 October 2026 · figures as of 29 October
Close it once
- 1 · MarkA chat or a screen
You tell an assistant in a chat that it is done, or tick it in the app.
- 2 · LedgerThe done ledger
The closure is written to the queue on disk. Quit the app mid-action and anything undelivered goes out at the next start.
- 3 · QueueDelivery with retries
It sends every 20 seconds. If that fails, it waits 30 seconds, 2 minutes, 10 minutes, an hour, then 6 hours each time.
- AsanaTask closed
- Day planItem cleared
- CRMDeal step closed
- 248 of 248
- closures delivered, 0 lost
- 5.5 s
- average time to confirmation
- 2
- needed a second attempt
- 248 of 248closures delivered to Asana0 lost, 19–29 October
- 5.5 saverage time from mark to confirmation
- 11,229 → 548signals turned into action cards327 cards closed
- 15sources in one day plan14 screens in the app
Mornings began with a tour of systems
Mornings began with a tour. The till and payouts sat in one system. Deals in the CRM. Tasks in Asana. Server health in monitoring. Then mail, the calendar and client chats. Each system answered one slice of “what do I do today”.
Closed items were the worst part. A task was marked done in a chat, yet Asana still showed it. The day plan was rebuilt and the item came back the next morning. The head of the company closed the same thing twice.
We moved everything into one place. The command centre reads the sources itself, turns them into cards and keeps a single day plan. A closed item does not return to the plan.

Before
- A tour of every system each morning
- Closed in a chat, still open in Asana
- Items return when the plan is rebuilt
- Money, deals, tasks and servers in four systems
After
- 15 sources in one day plan
- One mark closes the item everywhere
- Finished work is never suggested again
- Thousands of signals filtered into hundreds of action cards
Close it once
The core idea is simple. You mark an item done in one place and the system does the rest. The mark goes into the done ledger, and from there into a delivery queue.
The ledger keeps marks for 14 days, up to 300 entries. It also stops the day plan from suggesting finished work again. If a rebuild rewords an item, the mark still finds it by its link and shared words.
- 248 of 248closures reached Asana0 lost and 0 rejected
- 241 of 248delivered within 10 seconds247 of 248 within a minute
- 0.8 son average at the first attemptoverall average 5.5 s
What the queue does when the connection drops
Asana does not always answer. The network drops, the service asks you to wait, a laptop lid closes mid-action. A closure that “left but never arrived” is worse than a manual one, because nobody knows it was lost.
So a closure is written to the queue on disk: when a CRM deal task is closed, the queue entry and the local change are saved in one transaction. The queue sends closures at start-up, after every action and every 20 seconds. Over 11 days (19 to 29 October) it sent 248 closures. Two needed a second attempt. The other 246 arrived first time.
Queue on disk
Closing a deal task and its delivery job are saved in one transaction. Closures not yet sent stay in the queue on disk and go out at the next start.
Retries without duplicates
A closure sets the state to “done” rather than pressing a button. Sending it twice cannot break the task. Before a retry the queue reads what Asana already shows.
Growing pauses
Retries run after 30 seconds, 2 minutes, 10 minutes, an hour, then every 6 hours. After 12 attempts the closure is marked undelivered.
Failure shows
On the Today screen a badge counts closures waiting for confirmation and those Asana rejected. A closure does not vanish silently.
- 39closures on 26 October
- 102closures on 27 Octoberthe peak of the period
- 0closures lost on either day
11,229 signals become 548 action cards
Sources are noisy. A server blips, a payment lands, a till total does not match, an email waits for a reply. In three weeks, 9 to 29 October, the command centre accumulated 11,229 signals from 11 sources (the earliest events are dated 14 September). Nobody can read that in order.
It merges repeats and duplicates into episodes and shows one card with its history. 1,786 signals landed in 548 action cards, and noise rules hid another 9,443: they stay visible under “Quietly hidden”. Of the cards, 327 are closed, 217 open and 4 dismissed.
Where signals come from
- 7,911server monitoring
- 1,611money
- 724tasks
- 545payroll
- 264cash desks
- 98mail
- 35payments and ads
- 41bridge, reconciler, work board
Server monitoring sends the most signals, 7,911: 70% of the stream. Of these, 42 landed in cards and the rest were hidden by noise rules.
Chat assistants see the same plan
Assistants in chats plug into the command centre. Before new work, an assistant checks whether it has already been done. When it starts, it leaves a trace on the work board. When it finishes, it closes the day-plan item and the Asana task.
The command centre offers chat tools for this. One call closes up to 20 Asana tasks. The assistant reads open tasks from a local copy that refreshes every 2 minutes, so reading never calls Asana.
Another check runs on the plan itself. After every day build, an AI model compares each unfinished item with the facts: has the client replied since the step date, has the payment arrived, is there a mark in the ledger. A finished item is marked done, and items tied to an Asana task get a note.
- Find
Never twice
Before starting, the assistant searches the board and the day plan for similar work and reads open Asana tasks from the local copy.
- Leave a trace
Every stage visible
Started, blocked, done: a short comment on the work-board card.
- Close
No tour of systems
One call queues up to 20 Asana tasks for closing and writes to the done ledger; the day-plan item closes once Asana confirms.
14 screens and three weeks of figures
The app has 14 screens: overview, today, tasks, decisions, done, money, systems, assistants, bridge, journal, sources, geo reports, CRM and checked. A small CRM inside holds deals, payments and the next step for each client.
The command centre also tracks the company’s numbers. From 9 to 29 October it gathered 42,502 points across 32 indicators and saved 115 reports.

- 42,502metric points32 indicators, 9–29 October
- 115saved reports
- 14days of marks in the done ledger
- 1 h 10 minthe “Sales” mini-CRM plus loading 20 deals into it13 October, 11:35–12:45 Tashkent time
- about 2 hthe done ledger, the closure check and two new sources16 October, payroll and chats
How it was built
Built one loop at a time
By 10 October money, deals, tasks, the work board, server health, payments and ads, and the calendar and capacity were running on live data. Cash desks followed on 15 October, payroll and chats on 16 October.
The mini-CRM with its first load of deals took 1 hour 10 minutes; the done ledger, closure check and two sources took about two hours. On 19 October the delivery queue replaced direct sending to Asana. The head of the company has worked in it every day since 10 October.
- Head of the companyDecides which sources matter and what counts as closed. Uses the app every day.
- SemCueThe app, source collection, ledger, delivery queue and chat tools.
- Chat assistantsFind work, leave traces and close items through the command centre’s tools.
For technical readers
Under the hood
- App
- Native macOS: Swift and SwiftUI with a local SQLite database.
- Delivery
- A closure queue on disk, written in the same transaction as the local change for CRM deal tasks; retries with growing pauses, up to 12 attempts.
- Signals
- Repeats merged into episodes, action cards, freshness per source.
- For chats
- A tool server: work search, board traces, the day plan, closing up to 20 Asana tasks per call, CRM.
- Item check
- An AI model compares unfinished items with chats, payments and the ledger after every day build.
Where the numbers come from
Sources
- Aggregates from the app’s local database as of 29 October 2026, 18:44 Tashkent time: delivery queue, signals, action cards, metric points, reports. Counts and averages only, no records with names.
- The project’s decision log and the chat-tool documentation: rules for the ledger, queue and check.
- The app’s source code: retry settings and the list of screens.
- The estimates log for 13 and 16 October 2026.
- Dates in the database are stored in UTC.
Next system
Our own CRM instead of amoCRM →