ldbumble/taskuary

The problem Taskuary reads chat servers (Mattermost, Rocket.Chat, Matrix, Google Chat in taskuary/chatservers.py) and personal messengers (Telegram, WhatsApp in taskuary/messengers.py). Zulip and Signal are planned cards in taskuary/connectorcatalog.json. Zulip's topic-per-stream model is a good test of whether our chat handling is general. Signal has no official API, and its working road looks a lot like our WhatsApp bridge. What a good result looks like Messages that ask the owner something become tasks; chatter does not. Replies go back into the same stream/topic or conversation after approval. Chat rules already exist for this (is_chat and chat_candidates in taskuary/ingest.py): chat asks have no due clock, and the owner's own replies are kept. The new connector should get all of that by declaring itself a chat channel, not by re-implementing it. Decisions that are yours Zulip: whether the stream+topic pair is one thread (it probably should be), and which streams to read by defaul

The problem Support tickets are work that arrives from outside, which is exactly what Taskuary triages. Zendesk and Intercom are planned cards in taskuary/connectorcatalog.json. Today a ticket only reaches Taskuary if its notification email does, and then the reply goes to the notification address, not into the ticket. What a good result looks like New tickets and customer replies that need the owner arrive on the Timeline through normal triage. Each ticket is one thread, so replies attach to the same task. An approved reply is posted back to the ticket as a public reply (or an internal note, if the owner chooses), never sent before approval. Decisions that are yours Which tickets are the owner's: assigned to them, in their groups, or all. Make it a card setting. Threading: the ticket id becomes the thread key, so a later comment never starts a new task (see taskuary/chains.py and how chat channels pass ext/thread ids in taskuary/chatservers.py _ingest). Public reply versus internal n

The problem Closing the Taskuary window quits the app. taskuary/desktop.py says so in its CLOSING IS QUITTING comment: there is no tray, so nothing watches while the window is closed. Notifications only exist inside the browser page (toast and sound). On the roadmap: "Desktop tray controls and native notifications". What a good result looks like Closing the window can leave Taskuary running in the tray, as a choice the owner makes, not a surprise. The tray menu offers at least Open, Pause syncing and Quit. Things that need the owner (an agent asking a question, an urgent item, a reply waiting for approval) can raise an OS notification. Clicking it opens that item. Decisions that are yours The library: pystray, the webview's own tray support, or plain platform APIs. Windows matters most (the packaged exe is Windows), but macOS and Linux should not break. Which events deserve a notification. This is the real design work: too many and people turn them off. There is already a "something

The problem The owner can run the Assistant from a phone chat: WhatsApp or Telegram (taskuary/remote_assistant.py, CHANNELS = ('whatsapp', 'telegram')). A message in their own chat runs the same walk as the Assistant tab: items arrive, and the owner answers approve / skip / later. Many work users live in Teams instead. This is on the roadmap: "Teams as a phone-approval channel alongside Telegram and WhatsApp". Teams already exists as an inbound channel (taskuary/channels.py). What a good result looks like The owner picks a Teams chat with themselves (or a dedicated one) as their doorway. They get the same items, can answer with words or with the action buttons, and handing the walk over from the desktop locks the tab exactly as it does for WhatsApp. Decisions that are yours How the doorway chat is identified and kept private. is_private and own_thread show how WhatsApp avoids answering in a group. Adaptive Cards versus plain text for the choices. Telegram has inline buttons (messenger

The problem knowledge.search() (taskuary/knowledge.py) is SQLite FTS5 keyword search. It works well when the question uses the document's words and misses when it does not: a search for "time off" finds nothing in a policy titled "Leave of absence". The function was built so a vector search could sit behind it later without its callers changing (search, block). What a good result looks like With the option off (the default), nothing changes: same results, no new dependency installed. With it on, a search for "time off" finds the leave policy. Results still come back in the same shape, so block() and every prompt that uses it are untouched. Decisions that are yours The embedder: a small local model first (the app runs offline-first, and the Ollama brain is already supported, see taskuary/llm.py). A hosted embedding API can be a second option. Where vectors live. The knowledge index already has its own SQLite database. Choose between sqlite-vec, a flat numpy file, or plain brute force