From aadf726251685cbb5d1479d11ce11556ebb0b1eb Mon Sep 17 00:00:00 2001
From: syed rayyan <syedrayyan@syeds-MacBook-Air.local>
Date: Tue, 13 Oct 2026 03:45:19 +0530
Subject: [PATCH] docs: correct settings references in assistant and reports
 guides

---
 docs/site/assistant.md   | 2 +-
 docs/site/reports.md     | 2 +-
 site/docs/assistant.html | 2 +-
 site/docs/reports.html   | 2 +-
 site/docs/search.json    | 2 +-
 5 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/docs/site/assistant.md b/docs/site/assistant.md
index 560286b33..063dba312 100644
--- a/docs/site/assistant.md
+++ b/docs/site/assistant.md
@@ -110,7 +110,7 @@ These have no button. Say them, in the app or on your phone.
 | "redraft it shorter" | The draft written again with the change | at once |
 | "yes, go ahead" to a waiting agent | Your answer goes to the agent | you confirm |
 | "run it again" on a report | The report runs again | at once |
-| "remember that…" | A fact kept in Settings → Memory, used by triage and the Assistant | you confirm |
+| "remember that…" | A fact kept in Settings → Verdicts & notes, used by triage and the Assistant | you confirm |
 | "clear all the fyi" | Clears that set from the walk, with the count on the card | you confirm |
 | "set up a report that…" | A walk-through for a report, connection or workflow | you confirm |
 | "stop hiding auto-replies" | The setting is changed, with an undo | at once |
diff --git a/docs/site/reports.md b/docs/site/reports.md
index bd8505176..0af9ab434 100644
--- a/docs/site/reports.md
+++ b/docs/site/reports.md
@@ -188,7 +188,7 @@ Four things shape it:
 - `COUNSEL.md` in Settings → Docs — how it speaks, and how readily it takes a position.
 - The **Advisor** report — what it watches, its schedule, its model.
 - **Settings → Advisor** — thresholds such as how long a reply or task must be quiet.
-- **Settings → Learning** — whether your verdicts feed back into `LEARNED.md`.
+- **Settings → Triage & routing → Learn from your verdicts** — whether your verdicts feed back into `LEARNED.md`.
 - **The outcome ledger** — what came of what Taskuary did: a reply that got more rounds, a close
   that reopened, a promise delivered late, your own next move after an agent stopped. Resolved
   once a day from the store's own facts; reflection reads it as evidence. See
diff --git a/site/docs/assistant.html b/site/docs/assistant.html
index 5930757d0..57a056908 100644
--- a/site/docs/assistant.html
+++ b/site/docs/assistant.html
@@ -368,7 +368,7 @@ <h2 id="words-that-work-typed">Words that work typed<a class="anchor" href="#wor
 </tr>
 <tr>
 <td>&quot;remember that…&quot;</td>
-<td>A fact kept in Settings → Memory, used by triage and the Assistant</td>
+<td>A fact kept in Settings → Verdicts &amp; notes, used by triage and the Assistant</td>
 <td>you confirm</td>
 </tr>
 <tr>
diff --git a/site/docs/reports.html b/site/docs/reports.html
index ac0d3e19c..09148b865 100644
--- a/site/docs/reports.html
+++ b/site/docs/reports.html
@@ -362,7 +362,7 @@ <h2 id="schedules">Schedules<a class="anchor" href="#schedules" aria-label="Link
 <li><code>COUNSEL.md</code> in Settings → Docs — how it speaks, and how readily it takes a position.</li>
 <li>The <strong>Advisor</strong> report — what it watches, its schedule, its model.</li>
 <li><strong>Settings → Advisor</strong> — thresholds such as how long a reply or task must be quiet.</li>
-<li><strong>Settings → Learning</strong> — whether your verdicts feed back into <code>LEARNED.md</code>.</li>
+<li><strong>Settings → Triage &amp; routing → Learn from your verdicts</strong> — whether your verdicts feed back into <code>LEARNED.md</code>.</li>
 <li><strong>The outcome ledger</strong> — what came of what Taskuary did: a reply that got more rounds, a close
 that reopened, a promise delivered late, your own next move after an agent stopped. Resolved
 once a day from the store&#39;s own facts; reflection reads it as evidence. See
diff --git a/site/docs/search.json b/site/docs/search.json
index 6fdee710f..87a5e8288 100644
--- a/site/docs/search.json
+++ b/site/docs/search.json
@@ -1 +1 @@
-[{"t":"Start here","c":"Start here","u":"./","x":"What Taskuary is, how to install it, and what the first hour looks like."},{"t":"What Taskuary is","c":"Start here → What Taskuary is","u":"./#what-taskuary-is","x":""},{"t":"Install on Windows","c":"Start here → Install on Windows","u":"./#install-on-windows","x":""},{"t":"Install with Python","c":"Start here → Install with Python","u":"./#install-with-python","x":""},{"t":"Command-line options","c":"Start here → Command-line options","u":"./#command-line-options","x":""},{"t":"Docker","c":"Start here → Docker","u":"./#docker","x":""},{"t":"Your first run","c":"Start here → Your first run","u":"./#your-first-run","x":""},{"t":"Choosing the AI setup","c":"Start here → Choosing the AI setup","u":"./#choosing-the-ai-setup","x":""},{"t":"Where your data lives","c":"Start here → Where your data lives","u":"./#where-your-data-lives","x":""},{"t":"What leaves your machine","c":"Start here → What leaves your machine","u":"./#what-leaves-your-machine","x":""},{"t":"Updating","c":"Start here → Updating","u":"./#updating","x":""},{"t":"Next","c":"Start here → Next","u":"./#next","x":""},{"t":"How it works","c":"How it works","u":"./how-it-works","x":"One message from arrival to approval: the Timeline, the five roads, and what triage actually decides."},{"t":"The Timeline","c":"How it works → The Timeline","u":"./how-it-works#the-timeline","x":""},{"t":"The five roads a message can take","c":"How it works → The five roads a message can take","u":"./how-it-works#the-five-roads-a-message-can-take","x":""},{"t":"What triage actually decides","c":"How it works → What triage actually decides","u":"./how-it-works#what-triage-actually-decides","x":""},{"t":"Nothing sends itself","c":"How it works → Nothing sends itself","u":"./how-it-works#nothing-sends-itself","x":""},{"t":"Correcting it teaches it","c":"How it works → Correcting it teaches it","u":"./how-it-works#correcting-it-teaches-it","x":""},{"t":"Three brains, one voice","c":"How it works → Three brains, one voice","u":"./how-it-works#three-brains-one-voice","x":""},{"t":"The documents that govern it","c":"How it works → The documents that govern it","u":"./how-it-works#the-documents-that-govern-it","x":""},{"t":"Where the rest of the workspace fits","c":"How it works → Where the rest of the workspace fits","u":"./how-it-works#where-the-rest-of-the-workspace-fits","x":""},{"t":"Connections","c":"Connections","u":"./connections","x":"The accounts Taskuary may read, and the role that says what it may do with each."},{"t":"What a connection is","c":"Connections → What a connection is","u":"./connections#what-a-connection-is","x":""},{"t":"The five roles","c":"Connections → The five roles","u":"./connections#the-five-roles","x":""},{"t":"Mail","c":"Connections → Mail","u":"./connections#mail","x":""},{"t":"Chat","c":"Connections → Chat","u":"./connections#chat","x":""},{"t":"Repositories and trackers","c":"Connections → Repositories and trackers","u":"./connections#repositories-and-trackers","x":""},{"t":"Data and report sources","c":"Connections → Data and report sources","u":"./connections#data-and-report-sources","x":""},{"t":"Coding CLIs and AI providers","c":"Connections → Coding CLIs and AI providers","u":"./connections#coding-clis-and-ai-providers","x":""},{"t":"Adding another of the same kind","c":"Connections → Adding another of the same kind","u":"./connections#adding-another-of-the-same-kind","x":""},{"t":"Pushing something in yourself","c":"Connections → Pushing something in yourself","u":"./connections#pushing-something-in-yourself","x":""},{"t":"Tasks and agents","c":"Tasks and agents","u":"./tasks-and-agents","x":"A task, the agent work on it and the reply to the sender are three separate lives."},{"t":"A task's three lives","c":"Tasks and agents → A task's three lives","u":"./tasks-and-agents#a-tasks-three-lives","x":""},{"t":"Sending work to a coding agent","c":"Tasks and agents → Sending work to a coding agent","u":"./tasks-and-agents#sending-work-to-a-coding-agent","x":""},{"t":"The general agent","c":"Tasks and agents → The general agent","u":"./tasks-and-agents#the-general-agent","x":""},{"t":"Sessions and transcripts","c":"Tasks and agents → Sessions and transcripts","u":"./tasks-and-agents#sessions-and-transcripts","x":""},{"t":"Several agents in one repository","c":"Tasks and agents → Several agents in one repository","u":"./tasks-and-agents#several-agents-in-one-repository","x":""},{"t":"Checklists and closing","c":"Tasks and agents → Checklists and closing","u":"./tasks-and-agents#checklists-and-closing","x":""},{"t":"Replies","c":"Tasks and agents → Replies","u":"./tasks-and-agents#replies","x":""},{"t":"Profiles and playbooks","c":"Tasks and agents → Profiles and playbooks","u":"./tasks-and-agents#profiles-and-playbooks","x":""},{"t":"The task view and the Board","c":"Tasks and agents → The task view and the Board","u":"./tasks-and-agents#the-task-view-and-the-board","x":""},{"t":"The work rail","c":"Tasks and agents → The work rail","u":"./tasks-and-agents#the-work-rail","x":""},{"t":"How work is ordered","c":"Tasks and agents → How work is ordered","u":"./tasks-and-agents#how-work-is-ordered","x":""},{"t":"Assistant buttons","c":"Assistant buttons","u":"./assistant","x":"Every button under an Assistant card, the one question two of them ask, Remind me, and the words that work typed."},{"t":"One screen: the sidebar and the canvas","c":"Assistant buttons → One screen: the sidebar and the canvas","u":"./assistant#one-screen-the-sidebar-and-the-canvas","x":""},{"t":"The buttons on each card","c":"Assistant buttons → The buttons on each card","u":"./assistant#the-buttons-on-each-card","x":""},{"t":"The two buttons that ask one question","c":"Assistant buttons → The two buttons that ask one question","u":"./assistant#the-two-buttons-that-ask-one-question","x":""},{"t":"Pictures, and your voice","c":"Assistant buttons → Pictures, and your voice","u":"./assistant#pictures-and-your-voice","x":""},{"t":"Remind me","c":"Assistant buttons → Remind me","u":"./assistant#remind-me","x":""},{"t":"Everything the task page can do","c":"Assistant buttons → Everything the task page can do","u":"./assistant#everything-the-task-page-can-do","x":""},{"t":"Words that work typed","c":"Assistant buttons → Words that work typed","u":"./assistant#words-that-work-typed","x":""},{"t":"What the Assistant sees","c":"What the Assistant sees","u":"./assistant-tools","x":"Every tool the Assistant has: the summary it gets on every turn, and each tool in detail. Written from the code."},{"t":"The summary, sent every turn","c":"What the Assistant sees → The summary, sent every turn","u":"./assistant-tools#the-summary-sent-every-turn","x":""},{"t":"Table","c":"What the Assistant sees → Table","u":"./assistant-tools#table","x":""},{"t":"Task","c":"What the Assistant sees → Task","u":"./assistant-tools#task","x":""},{"t":"Agents","c":"What the Assistant sees → Agents","u":"./assistant-tools#agents","x":""},{"t":"New","c":"What the Assistant sees → New","u":"./assistant-tools#new","x":""},{"t":"Pipe","c":"What the Assistant sees → Pipe","u":"./assistant-tools#pipe","x":""},{"t":"Reports","c":"What the Assistant sees → Reports","u":"./assistant-tools#reports","x":""},{"t":"App","c":"What the Assistant sees → App","u":"./assistant-tools#app","x":""},{"t":"Look","c":"What the Assistant sees → Look","u":"./assistant-tools#look","x":""},{"t":"Reports and the Advisor","c":"Reports and the Advisor","u":"./reports","x":"Reading the systems you work in on a schedule, and the report whose job is to judge."},{"t":"A report is a pipeline","c":"Reports and the Advisor → A report is a pipeline","u":"./reports#a-report-is-a-pipeline","x":""},{"t":"Sources","c":"Reports and the Advisor → Sources","u":"./reports#sources","x":""},{"t":"Letting the AI write the source cards","c":"Reports and the Advisor → Letting the AI write the source cards","u":"./reports#letting-the-ai-write-the-source-cards","x":""},{"t":"The AI pass","c":"Reports and the Advisor → The AI pass","u":"./reports#the-ai-pass","x":""},{"t":"Where a run goes","c":"Reports and the Advisor → Where a run goes","u":"./reports#where-a-run-goes","x":""},{"t":"Schedules","c":"Reports and the Advisor → Schedules","u":"./reports#schedules","x":""},{"t":"The Advisor","c":"Reports and the Advisor → The Advisor","u":"./reports#the-advisor","x":""},{"t":"Stateful workflows","c":"Reports and the Advisor → Stateful workflows","u":"./reports#stateful-workflows","x":""},{"t":"Sage Intacct, specifically","c":"Reports and the Advisor → Sage Intacct, specifically","u":"./reports#sage-intacct-specifically","x":""},{"t":"API","c":"Reports and the Advisor → API","u":"./reports#api","x":""},{"t":"The Advisor","c":"The Advisor","u":"./advisor","x":"What goes into the brain that says what should happen next, its two clocks, and the outcome ledger that teaches it what worked."},{"t":"What it reads","c":"The Advisor → What it reads","u":"./advisor#what-it-reads","x":""},{"t":"Two clocks","c":"The Advisor → Two clocks","u":"./advisor#two-clocks","x":""},{"t":"What was not followed up","c":"The Advisor → What was not followed up","u":"./advisor#what-was-not-followed-up","x":""},{"t":"A page per person","c":"The Advisor → A page per person","u":"./advisor#a-page-per-person","x":""},{"t":"The outcome ledger","c":"The Advisor → The outcome ledger","u":"./advisor#the-outcome-ledger","x":""},{"t":"The one rule","c":"The Advisor → The one rule","u":"./advisor#the-one-rule","x":""},{"t":"What is built, and what is next","c":"The Advisor → What is built, and what is next","u":"./advisor#what-is-built-and-what-is-next","x":""},{"t":"On your phone","c":"On your phone","u":"./phone","x":"The same assistant over WhatsApp or Telegram, and what it may do there."},{"t":"The doorways","c":"On your phone → The doorways","u":"./phone#the-doorways","x":""},{"t":"What it can do","c":"On your phone → What it can do","u":"./phone#what-it-can-do","x":""},{"t":"The morning line","c":"On your phone → The morning line","u":"./phone#the-morning-line","x":""},{"t":"Handing over","c":"On your phone → Handing over","u":"./phone#handing-over","x":""},{"t":"What it will not do","c":"On your phone → What it will not do","u":"./phone#what-it-will-not-do","x":""},{"t":"Sections, For later and browsing, on the phone","c":"On your phone → Sections, For later and browsing, on the phone","u":"./phone#sections-for-later-and-browsing-on-the-phone","x":""},{"t":"Settings reference","c":"Settings reference","u":"./settings","x":"Every setting, generated from the same file the app and the assistant read."},{"t":"How to read this","c":"Settings reference → How to read this","u":"./settings#how-to-read-this","x":""},{"t":"Triage & agents","c":"Settings reference → Triage & agents","u":"./settings#triage-agents","x":""},{"t":"Triage & routing","c":"Settings reference → Triage & routing","u":"./settings#triage-routing","x":""},{"t":"Replies","c":"Settings reference → Replies","u":"./settings#replies","x":""},{"t":"Assistant","c":"Settings reference → Assistant","u":"./settings#assistant","x":""},{"t":"Assistant on your phone","c":"Settings reference → Assistant on your phone","u":"./settings#assistant-on-your-phone","x":""},{"t":"Advisor","c":"Settings reference → Advisor","u":"./settings#advisor","x":""},{"t":"Coder agent","c":"Settings reference → Coder agent","u":"./settings#coder-agent","x":""},{"t":"Agent permissions","c":"Settings reference → Agent permissions","u":"./settings#agent-permissions","x":""},{"t":"Notifications","c":"Settings reference → Notifications","u":"./settings#notifications","x":""},{"t":"Attachments & images","c":"Settings reference → Attachments & images","u":"./settings#attachments-images","x":""},{"t":"Sync & startup","c":"Settings reference → Sync & startup","u":"./settings#sync-startup","x":""},{"t":"Display","c":"Settings reference → Display","u":"./settings#display","x":""},{"t":"Routing policies","c":"Settings reference → Routing policies","u":"./settings#routing-policies","x":""},{"t":"Verdicts & notes","c":"Settings reference → Verdicts & notes","u":"./settings#verdicts-notes","x":""},{"t":"Audit integrity","c":"Settings reference → Audit integrity","u":"./settings#audit-integrity","x":""},{"t":"When something is wrong","c":"When something is wrong","u":"./troubleshooting","x":"What to check, in the order worth checking it."},{"t":"It will not start","c":"When something is wrong → It will not start","u":"./troubleshooting#it-will-not-start","x":""},{"t":"A connection stopped","c":"When something is wrong → A connection stopped","u":"./troubleshooting#a-connection-stopped","x":""},{"t":"Triage got it wrong","c":"When something is wrong → Triage got it wrong","u":"./troubleshooting#triage-got-it-wrong","x":""},{"t":"A reply has no confirmed delivery","c":"When something is wrong → A reply has no confirmed delivery","u":"./troubleshooting#a-reply-has-no-confirmed-delivery","x":""},{"t":"An agent is stuck","c":"When something is wrong → An agent is stuck","u":"./troubleshooting#an-agent-is-stuck","x":""},{"t":"A report returned nothing","c":"When something is wrong → A report returned nothing","u":"./troubleshooting#a-report-returned-nothing","x":""},{"t":"Reading the audit log","c":"When something is wrong → Reading the audit log","u":"./troubleshooting#reading-the-audit-log","x":""},{"t":"Where the logs are","c":"When something is wrong → Where the logs are","u":"./troubleshooting#where-the-logs-are","x":""},{"t":"Still wrong","c":"When something is wrong → Still wrong","u":"./troubleshooting#still-wrong","x":""},{"t":"","c":"Start here","u":"./","x":"Taskuary is a work assistant that runs on your own machine. It reads the places work arrives — mail, chats, issue trackers, monitoring, your finance system — decides what each thing actually is, and brings you the few that need you. Coding jobs go to a coding agent in your repository. Answers come back as drafts you approve. Nothing is sent without you. It keeps its data in a SQLite file in your home directory and serves its interface at http://127.0.0.1:7787 . There is no account to create and no server to rent. What Taskuary is Three sentences, because the rest of this site is detail: 1. Everything arrives in one Timeline. A vendor's email, a GitHub pull request, a Teams message, a failed nightly export and this morning's spend report are one list, in the order they happened. 2. Each item gets one verdict. A small AI reads it and decides: nothing to do, a sentence settles it, an agent should work it, let's talk it through, or it's yours. That verdict is visible, and arguing with it teaches the next one. 3. Work that can be done is done, and comes back for approval. A coding agent works in your checkout; replies wait on the task. Approving is always a human action. :::rule The one thing to understand Taskuary never sends anything by itself. Replies, comments, invoices and posts all wait for you on the task. The only deliberate exception is an alert you configured, which fires the moment its rule trips — an alert that waits for approval is not an alert. ::: Install on Windows Download [Taskuary.exe](https://github.com/ldbumble/taskuary/releases/latest/download/Taskuary.exe) and open it. It is one file: the app and the desktop shell together, with no Python and no installer. The first run creates %USERPROFILE%\\.taskuary\\ and opens the interface. Install with Python Python 3.10 or newer: The browser opens by itself. For the same interface in a native desktop window: :::note Which platform gets the most use CI runs the full test matrix on Windows, Linux and macOS. Development happens mostly on Windows, so the terminal, the desktop shell and the agent presets are best exercised there; macOS and Linux may still have rough edges. ::: Command line options The everyday options for the Python install are: Option What it does port PORT Overrides the configured server port for this run host HOST Overrides the configured server host; use 0.0.0.0 to listen on all interfaces no browser Starts the server without opening a browser tab debug Enables verbose console logging for requests, report runs and errors Run taskuary help for the complete command reference. Docker Runs Taskuary without putting Python on the host: Open http://127.0.0.1:7787 . Data lives in the taskuary data volume. The container gives you the Timeline, Review, Reports and Connections; coding CLIs and the optional WhatsApp bridge stay host programs, because both need a machine of their own. The compose file binds to localhost. Set TASKUARY_TOKEN before publishing the port anywhere else. Your first run Open Set up Taskuary on the Assistant. The first four steps get you to one useful result: 1. Say who you are. Add the name that signs your drafts, and your email so Taskuary can recognise your own messages. Detailed preferences can wait. 2. Connect one AI. Use an API provider, Ollama, or a signed in coding CLI you already pay for. Test its connection. Keep the current model defaults to start; reviewing every model assignment is optional. 3. Connect one work source. Choose one mailbox, chat, or issue tracker in [Connections](connections). Enable it as an input and test it. You do not need a mailbox if your first source is a tracker such as GitHub. 4. Press Read first items. This starts a real source read and shows its progress. Once items arrive, open one of the first five recent results to check its verdict and any draft. Replies still wait for your approval. If nothing arrives, the step explains how to check the source scope or try a new incoming message. The five items are a review sample, not an import limit: each source keeps its normal read scope and history settings. Starting with one source makes that first review easier. Setup does not overwrite an existing user's model or connection configuration. After that first result, add another source, connect a coding CLI if you want code written, or add a report for numbers you check by hand. The optional models and agents step opens the existing settings whenever you want to adjust cost or use different models for different jobs. Reports and the Hub can wait until you have a workflow that needs them. Two reports exist from the start: the End of day checkup and the Advisor , which looks for useful follow ups and patterns in your work. You can review or remove either in Reports. The Morning digest is available as an optional report. Choosing the AI setup Triage reads many messages cheaply; coding changes a repository rarely and wants a strong model. Taskuary lets those be different brains, and the choice is mostly about what you already pay for. Setup Triage, drafts, summaries Coding sessions Fits you if Two brains (recommended) a small cloud model on an API key your coding CLI's full model you have a low cost API key One brain, two gears the CLI's light model the same CLI's main model you have one CLI subscription and no key One brain, one gear the CLI's full model the same model simplest, and expensive for routine mail Local brain Ollama or any OpenAI compatible local server a coding CLI, optionally the same local model no key, and no mail leaving the machine With no cloud key, set the triage brain to your configured CLI in [Settings](settings triage agents), and give that CLI a light model on its connector card so routine triage does not burn the coding model. Where your data lives The Python and desktop installs keep everything in ~/.taskuary/ : File What it is taskuary.db the SQLite database — messages, tasks, settings, the audit log config.toml local configuration taskuary.log the application log playbooks/ .md one page per kind of job an agent has learned to do context/ the context file each coding session is handed at startup TASKUARY_HOME moves all of it. Docker uses /data inside the container. TASKUARY_HOST , TASKUARY_PORT and TASKUARY_TOKEN override server settings at runtime without being written back to the config file. :::warn Before you expose it beyond localhost Set [server].token in the config or provide TASKUARY_TOKEN , and send that token in the X Taskuary Token header. An unauthenticated Taskuary reachable from the network gives whoever finds it your mail, your repositories and an agent that can run commands. ::: What leaves your machine Taskuary calls the services you configure and nothing else. Hosted AI providers and coding CLIs receive the prompts their work needs. With a model running on your machine, those prompts stay on it too; connected services such as mail still use their own connections either way. Before a prompt reaches a hosted model, a headless CLI run or the first turn of an agent pane, Taskuary replaces recognisable credentials with labelled placeholders. The original message is never altered. A reply that still contains one of those placeholders is refused rather than sent. These are deterministic shape rules — they catch API keys and passwords that look like API keys and passwords, and they cannot catch every secret. Updating Settings → Updates shows the running build and the latest release, and installs it in place: the exe is swapped or pip install runs, and the app reopens. Connections and settings are untouched. For the Python install you can also do it yourself: Next [How it works](how it works) — one message from arrival to approval. [Connections](connections) — what Taskuary may read, and what it may do with it. [Reports and the Advisor](reports) — before you build your first report. The live API reference is at /api/docs while Taskuary is running.","body":true},{"t":"","c":"How it works","u":"./how-it-works","x":"Taskuary's whole behaviour is one loop: something arrives, it gets a verdict, the verdict decides who does the work, and whatever comes out waits for you. This page follows one message the whole way, then explains the machinery underneath it. The Timeline The Timeline is the front door: every connection with a trigger or feed role lands here, in the order things happened. An email from a vendor, a pull request, a Teams message, this morning's spend report and a failed nightly export are one list. Each row shows where it came from above its original time, so mail, chat, GitHub, a SQL report and an Advisor post are told apart at a glance. Calendar entries show the meeting time. Open a row for the full message, its attachments, what triage decided and why, any drafted reply, and the actions available on it. Beside the Timeline, the work rail holds what is actually waiting on you, under Urgent, On you, Goals, Agents working, For later, Reports, Advisor ideas and FYI. A thread or a step gone quiet past that person's usual day is slipped , inside On you, with Chase, Let it go, They answered elsewhere and Remind me under it (see [The Advisor](advisor what was not followed up)). A finished or closed item gets no row: the rail is what still wants something from you, never a history. See [The work rail](tasks and agents the work rail) for what puts a row there and what takes it off. The five roads a message can take Every message gets exactly one verdict, and there are only five places it can go. Road What it means What happens fyi nothing to do filed; it stays readable and nothing is created reply a sentence settles it a draft goes to the task for you to approve coding an agent at a keyboard a CLI session starts in the checkout it picks general worth thinking about a conversation opens on the task; no system is touched task yours to do it lands on your list and nothing works it Three of those — coding , general , task — are kinds stored on the task, and the kind is what routes the work. reply is a kind too. fyi creates nothing at all. Only coding is ever dispatched automatically. A conversation you did not ask for is noise, and a task is yours by definition, so both land on the Board and wait for your click. :::note What \"general\" means It means the assistant's conversation: there is nothing to type at a system, but thinking, reading or research would help — weigh an option, make sense of a thread, work out what to ask. Work a person genuinely has to do in the world (sit a course, sign a form, attend, decide) is the task road instead. ::: What triage actually decides The verdict is the last thing that happens, not the first. Eleven checks run in a fixed order, and only two of them ask a model anything. A gate is deterministic: same input, same answer, no AI call, no cost. Knowing which is which is how you tell \"triage got this wrong\" from \"a rule caught it before triage ever saw it\". Step Gate or AI What it does 1 Dedupe gate A message whose id is already stored is dropped. Nothing below runs. 2 Feed connections gate A connection marked feed lands on the Timeline and stops — no verdict, no AI call, no task. 3 Policy rules gate Your rules, plus whether the sender is known. skip and ignore end it here. 4 Deferral gate Deferred triage lands the message as triaging so the Timeline shows it at once; the rest runs later. 5 Chat opener gate \"hi\", \"you there?\" — filed to wait for the ask it opens, so a greeting never becomes a task. 6 Threading gate (scored) Similarity against open tasks picks attach or create ; then a thread that is not yours is refused. 7 Still the same ask? AI Chats only, and only when step 6 attached: does this line continue that task or start a new one? 8 Your standing ruling gate If you already ruled on this conversation it is filed, quoting your own words. Your rulings outrank the classifier. 9 An agent is waiting gate If a run is live on the attached task, no verdict is asked for — the message goes to the agent as its answer. 10 The verdict gate, then AI Tracker items, obvious noise and calendar invites settle with no call. Everything else is one call reading TRIAGE.md , SOUL.md , JOB.md , LEARNED.md and your past verdicts. 11 Acting on it gate fyi files. A reply files instead of drafting when replies are off for that channel. Anything else becomes a task with its kind. Two rules hold wherever AI is involved. With no AI connector, a message is filed with \"awaiting AI triage\" rather than guessed at. A call that fails, or answers something unreadable, is filed too — never assumed to be work. Triage breaking is quiet and safe, not destructive. So a message that never reached the classifier was stopped by steps 1–6 or 8–9, and the fix is a rule, a feed or a ruling. A message the classifier did judge and got wrong is corrected on the Triage tab. Nothing sends itself Review is the outbound decision queue, and it is the only road out. A drafted reply sits there with the original request beside it; you edit the wording or the recipients, then Approve & send returns it through the channel the conversation started on. You can also ask for a redraft, reject it, or decide no reply is needed. The same gate covers more than mail: a GitHub comment, an invoice, a bill posted to your finance system and a file written to a share are all proposals until you approve them. A connector card ships at a read only authority, and raising it is a deliberate act. :::rule One way to finish A task ends with Mark done — on the task page, on the Assistant's card, or by saying \"done\" in the chat. Sending the reply marks it done too, unless an agent is still working on it or a new message arrived meanwhile. An agent that says it is finished closes its own task, and that result stays on your work rail until you have read it. See [Tasks and agents](tasks and agents who is allowed to close it). ::: Correcting it teaches it The roads on the Triage tab are not decoration. Correcting a verdict writes the reason into TRIAGE.md , the document the classifier reads on the next message — so the correction applies to the next message like this one, rather than becoming a rule about this one sender. Every verdict is evidence. Editing a draft teaches voice; rejecting one teaches what should not be drafted; Not our task teaches where your responsibility ends. The exact decision is kept with its date, sender and subject, so future triage can judge whether a new message is genuinely similar. Repeated patterns become lessons in LEARNED.md . Each machine written line carries its evidence: s is strength. A hypothesis starts at 2 and is promoted at 4 or more, supported by at least three episodes across two people or threads. Contradictions weaken it; stale hypotheses decay. ev names the verdicts that taught it, so you can go and read them. seen is the last date on which it held. Delete a learned line and it is gone. Lines you write yourself carry no machine tag and are never rewritten. An inferred rule that would hide work waits in Proposed rules until you adopt it. SOUL.md always outranks LEARNED.md , and one setting switches the whole loop off. Three brains, one voice Three always on models do the thinking, and you talk to one voice. They are split by what each is allowed to read and to do, not by where they run. What it does What it reads When Acts? Triage Judges each arrival: task, goal, reply, FYI or ignored. Attaches it to the thread's task, names the profile, playbook and repository, assigns the worker TRIAGE.md ; the first 2,500 characters of SOUL.md and of JOB.md ; LEARNED.md 's promoted lines; routing memory; the playbook menu; the recent open tasks every poll makes rows; never sends The assistant The voice and the hands: walks the rail, runs set up, connects things, moves things (assign, route, close, later) through a button or by asking the model for the verb COUNSEL.md , SOUL.md and JOB.md whole; the one item on the table on a turn moves things; never does the work, never proposes The Advisor The brain on the clock: the Advisor report, the morning brief and reflection say what is late, what was not followed up, what worked, which system is worth connecting the head of SOUL.md and JOB.md , COUNSEL.md ; your work as the hub sees it; the calendar; the knowledge base; the sources it watches; its own notes. At reflection: LEARNED.md whole, hypotheses too, and the outcome ledger on its schedule and when the app opens; reflection at launch and after three corrections; and on the event an agent stop or ask, a reply, an attached mail, a PR, a close, a missed day, a report one small prompt that leaves a line and a pill on that item never; it leaves a line, an idea row or a proposal The workers (the coding agent, the general agent) are the fourth kind and not always on: they do the work a task names, in a session you can watch. COUNSEL.md is the voice for the assistant and the Advisor both. The split is a budget: the heavy reader works off the request path, on the clock; the voice that answers on a turn reads the one item on the table, and never recomputes what the Advisor computed. The outcome ledger is the Advisor's newest input. Every other store is written at the moment you click: the documents say what they say, LEARNED.md is what you do when you correct, and the verdict and routing memories stop at the verdict. Nothing recorded what you did next, or what the world did after Taskuary acted. The ledger does: one row per action the app took or proposed a reply sent, a task closed, an agent stopping and your next move in your own words, a pull request merged, a promise made, a sender ignored and a once a day sweep fills in what came of it from facts already in the store: did more mail arrive on the thread, did the task reopen, did the person deliver and when, did the ignored sender's mail become work anyway. No model runs in the sweep. What the facts mean is reflection's: it reads the resolved rows as evidence ( out ids, beside the mem , rv and task ids above) and writes habits into LEARNED.md with the same grammar and the same decay \"green PR from the coder: you merge it, 8 of 8\". A derived line never acts on its own: it changes which button comes first and what a proposal says, and deleting it from LEARNED.md is the whole undo. The whole of it every input, the two clocks, the ledger's row kinds and verdicts is on [The Advisor](advisor). The documents that govern it Taskuary's behaviour is plain Markdown under Settings → Docs . These are not configuration files around the edges — they are what the models are actually told. ![The eight operator documents and who reads them: TRIAGE, STYLE and JOB can be generated from three months of your mail; SOUL, CODER and COUNSEL you write; LEARNED and DIGEST write themselves](img/operator docs.svg \"Three are read out of your mailbox, three you write, two write themselves.\") Document Purpose Read by SOUL.md The constitution: rules, voice, escalation lines, repository map triage, replies, the assistant JOB.md What your job is: mission, responsibilities, who you serve, the cadences, what to protect. It weighs importance, never intent triage, the assistant, the morning brief TRIAGE.md What makes something a task, a reply or an FYI triage STYLE.md Greeting, tone, length, phrasing reply drafts COUNSEL.md How the assistant speaks, and how readily it takes a position the assistant, the morning brief, replies CODER.md How coding agents work and close out coding agents LEARNED.md The profile learned from your verdicts; always below SOUL.md triage, replies, coding agents DIGEST.md The current morning brief you Playbooks One page per kind of job: when it starts, which connections it uses, the steps, what an agent may do alone, what counts as done triage's when line, and the agent working it Playbooks are the ones that grow. CODER.md is the playbook for code; every other kind of job — a card charge to post as a bill, a new hire to set up — gets its own page the first time an agent does ","body":true},{"t":"","c":"Connections","u":"./connections","x":"A connection is one account Taskuary may read — a mailbox, a chat, a repository, a tracker, a database, a bank feed. Each card on the Connections page is one named connection, and its roles decide what Taskuary is allowed to do with what it finds there. Nothing is polled without an enabled role. A card with no role is a saved credential and nothing more. A card's settings its roles, what each repository or source does, processing, the agent's prompts wait for its Save bar, which lists every change before it is kept; Discard puts them back. Leaving the card with changes unsaved asks first. Test, sign in and a new credential still act at once. What a connection is One card is one account, not one kind of system. Rename it for the account or environment it represents — Ops mailbox rather than IMAP — and use Add another on the card to connect the same kind again. Two mailboxes, two GitHub organisations, or separate production and staging databases are all normal, and each keeps its own roles, its own schedule and its own name in every prompt. Secrets are write only in the interface: you can replace a password, never read one back. A database connection string may contain {password} so the saved password stays separate from the readable part of the configuration. The five roles A role is a permission, not a ranking. Role What Taskuary may do trigger Send inbound items through triage — they can become tasks, drafts or FYIs feed Show inbound items on the Timeline, unread by any AI report Make the source available to scheduled reports tool Let agents query it while working a task :::rule Feed is not a quieter trigger feed means no model ever reads those items — cheaper, quieter, and no verdict to argue with. ignore is a judgement about a message and happens further down, in your routing policies. If a source is noisy but you still want to see it, make it a feed. ::: A card can hold more than one role. A mailbox is usually trigger and tool ; a database is usually report and tool . Mail System Notes Outlook Mail and calendar, through Microsoft sign in or a tenant app registration Gmail and IMAP Any IMAP mailbox. Approved replies go back through the provider's SMTP, in thread Taskuary reads your Sent folder as well as your inbox. That is what makes \"has this been answered?\" a real question rather than a guess, and it is what STYLE.md 's Generate from history learns your writing voice from. :::note A shared mailbox needs saying so If the mailbox is shared, mail addressed to the team reads as mail addressed to you unless Taskuary knows otherwise. Name your own addresses in SOUL.md so triage can tell \"someone asked me\" from \"someone asked the team\". ::: Chat System Notes Teams , Slack Messages enter the Timeline through triage Telegram Bot based inbound, approved in chat replies, the Assistant walk on your phone; each chat is opt in WhatsApp A local bridge for inbound messages, approved replies and the Assistant walk on your phone. Unofficial protocol — use a number you can afford to lose Discord Watches selected bot channels and posts approved replies back into the originating channel Apple Messages macOS only. Reads the Mac's local Messages history and replies through Messages.app; needs Full Disk Access and Automation permissions Mattermost , Rocket.Chat A server you host. Each watched channel is its own source, and approved replies post back into it. Rocket.Chat needs two values — the token and the user id issued beside it Matrix Any homeserver, matrix.org or your own. Replies go back as your account rather than a bot, so the account has to have joined the room Google Chat Spaces on the Timeline and replies back into them. Reuses the Gmail card's OAuth client, so there is one registration in Google Cloud rather than two Chat is different from mail in one way that matters: a chat message often has no clock on it. \"Can you look at this when you get a chance\" is a real ask with no deadline, and Taskuary keeps those as their own kind of item rather than inventing urgency for them. A greeting on its own is held until the ask it opens arrives. Repositories and trackers System Notes GitHub Repository discovery, issues and pull requests as triggers, task specific standing prompts GitLab Assigned issues and merge requests, GitLab.com or self hosted Azure DevOps Work items assigned to the connected user, through WIQL @Me Jira, Asana, Monday.com, ClickUp, Todoist Assigned work items enter the Timeline through triage Linear, Trello Assigned issues and cards Notion Pages shared with the integration appear as a feed when they change Sentry, PagerDuty New unresolved errors and open incidents join the same funnel A tracker is the clearest case for trigger : an issue assigned to you is, by definition, work addressed to you, and triage settles most of them without an AI call at all. GitHub: what Close out does The GitHub connection has a Close out step: what finishing a task does on GitHub when you press Close out . These are your choices what each repository requires (branch protection, required checks and reviews) is read from GitHub for every pull request, and the card only offers what it allows. Setting Choices (default first) The token needs Close out on a pull request Merges it · Only closes the task Contents: write Merge method Squash · Merge commit · Rebase used when the repository allows it (same) Red checks the repository does not require Merge anyway, with a note · Stop and ask me Offer Update branch on when the pull request is behind and its author allows maintainer edits Pull requests: write Offer Re run checks on re runs the failed Actions jobs Actions: write Close out on an issue closes it on Issues: write Post your reply as the close out's comment on even with Reply to issue/PR authors off Issues / Pull requests: write Close out anyway, past the repository's own rules off admin tokens only, and only on your press Administration A repository you follow can override the pull request choice, the merge method and Close out anyway. Check the token asks GitHub, per repository, whether the token may do what these settings turn on. Data and report sources The full list is long and grows; these are the ones worth knowing about by shape. Databases and files — SQL Server, SQLite, SharePoint Lists, Google Sheets, a Windows/SMB share, SFTP, REST and RSS, and any MCP server tool. PostgreSQL , MySQL , ClickHouse , Snowflake and BigQuery each have their own card: the same executor with the dialect filled in, the default port known and the missing driver named in the error you actually get. The older Any database (connection string) card is still there for anything else with a SQLAlchemy URL, including raw ODBC through pyodbc. All of them are reads — these cards ship no write verb at all, and the engine's own user is the ceiling, so point them at a read only account. Cloud and monitoring — AWS (S3 buckets, CloudWatch log groups, arbitrary service calls), Azure (blob containers, Log Analytics, arbitrary ARM paths, and it can reuse the Outlook app registration), Microsoft Entra ID, Prometheus, Datadog, WinRM for PowerShell on a remote Windows machine. Finance — Sage Intacct, QuickBooks Online, Zoho Invoice, and bank and card feeds through SimpleFIN or Teller. These are the cards where the read/write distinction bites: each ships at read , so an agent proposes a bill or an invoice and you approve it on the task. Raising a card to write is what lets a routing policy pass small, known items through without you. Markets — Yahoo Finance, CoinGecko, Alchemy, ECB reference rates, SEC EDGAR filings, and a strategy screen that filters another card's rows. With a key: Twelve Data (quotes and computed indicators across stocks, FX and crypto), Alpha Vantage (slow limits, no card, no expiry), Finnhub (quotes plus company news, earnings dates and insider transactions), Polygon.io (bars and full market snapshots), Tiingo (properly adjusted end of day history), Financial Modeling Prep (fundamentals and ratios rather than prices) and Alpaca (a broker's own feed — read only; this card has no order executor at all). FRED needs no key or account whatsoever and is the one a fresh install can use immediately. Which to pick is a question of what you are watching, not of which is best: Finnhub if you follow companies, Tiingo or Polygon if you follow prices, FMP if you follow balance sheets, FRED if you follow the economy. The web — search it or read one page of it, each a single REST call with a key. Exa and Tavily read the web for an agent (Tavily can hand back a written answer with its sources beside it); Brave Search answers from its own index; SerpApi and Serper give back a search engine's page as it was ranked, which matters when the ORDER is the finding. To read one page: Jina Reader (no account at all), Firecrawl (clean markdown), ScrapingBee (for a page that fights back) and Apify (when the crawl is one somebody already wrote). They overlap on purpose — the bill and the terms differ far more than the results do. What is deliberately NOT here is anything that DRIVES a browser — logging in, clicking, filling a form. That runs over CDP through a real browser session and cannot be reached from an API, so a card promising it would be a card that never works. Social — LinkedIn , Bluesky and Mastodon . Nothing from these reaches the Timeline as work: a public timeline is not an inbox, so they are report sources and tools rather than triggers. Like every connection they start at full authority, so an agent can post. A public post cannot be recalled: set the card to read and a post an agent drafts becomes a proposal you approve on the task. Agent tools — treg puts thousands of endpoints across many providers behind one key, billed per call. Searching its catalogue is free and commits nothing, so an agent may do it unattended; calling an endpoint spends real money and can reach services that publish or order. The card starts at full authority like every connection; set it to read and every call becomes a proposal. Your own documents — the Knowledge base card indexes SharePoint library folders and folders on this machine (docx, pptx, xlsx, html, text, and pdf with pypdf ) into Taskuary's own SQLite. Once anything is indexed, a kb_search report answers questions from it on a schedule, agents call the same search as a tool, and the reply drafter, the assistant and coding sessions are handed the passages that bear on a thread. Passages are treated as facts to cite, never as instructions. :::warn Planned is not available The Connections page lists cards that are on the roadmap as well as ones that work — NetSuite, SAP, Workday, ADP, Epic, Cerner, PointClickCare among them. A planned card tells you so on its face. If the assistant suggests connecting one, saying yes is a vote for building it, not a connection. (This callout used to name \"a long tail of market data providers\" here. Eight of them were built and the sentence was not updated, so the docs called working cards planned — the market cards above all work.) ::: Coding CLIs and AI providers AI providers — Anthropic, OpenAI, Azure OpenAI, OpenRouter, Ollama (and any OpenAI compatible local server: LM Studio, llama.cpp, vLLM), and the Meta Model API. Coding CLIs — Claude Code, Codex, Qwen Code, OpenCode, Kimi Code, Gemini, Cursor, Copilot, Muse Code and Devin, plus any CLI that accepts a prompt on stdin. The connector defines its command, arguments, model argument and working directory behaviour. Two practical notes. A headless agent needs its noninteractive or auto approval flag, or it will hang waiting for a click that cannot happen — the presets set this for you. And the card's Test action runs a small prompt through the CLI before it ever receives real work, which is the fastest way to find out that a sign in expired. Every CLI card has a light model as well as a main one. Naming the same CLI as both your coder and your triage brain is normal and cheap, and it is the light ","body":true},{"t":"","c":"Tasks and agents","u":"./tasks-and-agents","x":"A task in Taskuary is three records, not one: the durable job, the agent work done on it, and how it is closed out the reply to whoever asked, and on GitHub the merge or the closed issue. They start and finish independently, and keeping them apart is what stops the word \"done\" meaning three different things. A task's three lives The task page shows them as one numbered workflow — 1 Task → 2 Agent work → 3 Close out — and each stage owns exactly one state badge. Part What it records Main controls What it never does by itself Task The durable job and who owns it owner, kind, priority, Reopen, Mark done Starting or ending an agent session does not complete it Agent work One or more attempts by a coding or non coding agent, plus the saved result harness, model, start, save and end session Ending a session does not mark the task done or send a reply Close out The reply to the person who asked, and the last act where the task lives (merge its pull request, close its issue) write, generate, edit; Close out , Decline , Not yet Sending it marks the task done — unless an agent is still working, a new message came in, or its merge still waits While a terminal or an assistant chat is live, the task collapses to a one line context strip and the workspace takes most of the page. Full controls, saved results and restart choices come back when the agent stops. Who is allowed to close it ![Every way a task ends: you press Mark done, send the reply, tick the last box, hand it to a person or say Not ours; or an agent says it is done or its pull request merges](img/how a task ends.svg \"Every road ends in Mark done, or says why the task stays open.\") There is one close, Mark done , and every road below leads to it. Mark done always does the same five things: the task is done, any unsent draft is kept but retired, a live agent is stopped, it leaves your work rail, and the \"yours to end\" mark comes off. You or an agent does What happens Stays open when Mark done — the task page, the Assistant's button or card, \"done\" or \"close\" in the chat, the phone Mark done never Close out with a reply Sends it, then Mark done an agent is still working on it, or a new message came in while you were answering — it says why Tick the last checklist box Mark done an agent is still working on it Hand it to a person Forwards it, then Mark done never Not ours / Not a task Deleted if nothing was done on it, otherwise Mark done never Mark done on a channel that cannot send (the draft stays unsent) Mark done never An agent says it is finished ( taskuary done ) The session is written up; the task waits for you with its close out (below) and the draft if a reply is owed, otherwise it is done its close out or a reply waits on you, or you opened the session yourself Close out on GitHub, or Decline Merges or closes the pull request, or closes the issue, posts your reply, then Mark done never The pull request or issue it came from is merged or closed Same as an agent saying it is finished, with nothing owed never A task an agent or a merged pull request closed stays on your work rail until you have read it. The close out: what finishes it where it lives Mail is finished by the reply. A pull request is finished by merging it, and an issue by closing it. Whatever the system, the card has the same three buttons only the line under them says what they do there: Button What it does Close out Finishes the task the normal way for its system, sends your reply with it, then Mark done Decline Closes it without doing it, where the system has that difference a pull request closed unmerged Not yet Nothing happens; the task stays open and on you (in the Assistant's walk this is Next ) The task's work is The rail says What Close out does there A pull request the agent opened, or the one the task came from ✉️ ready to close out Merges it the way you set on the GitHub connection (a draft is marked ready first), then posts your reply as its comment. The card reads the pull request from GitHub first: when the repository's rules say it cannot merge yet it says why and offers what fits Update branch , Re run checks , or Close out anyway where you allowed it An issue the task came from ✉️ ready to close out Posts your reply as the closing comment and closes the issue Mail, chat, anything else ✉️ ready to close out Sends your reply If the act is refused, nothing is sent. Merging or closing the pull request on GitHub yourself counts as answering it: the task closes by itself. The buttons are yours, so Agents may push / deploy does not have to be on that switch is about what an agent may do. A task an agent finished before this existed gets its card on the next sync. A session you started yourself is yours to complete: the agent is told so, and if it says it is finished anyway its sentence is filed on the task and the task stays open until you mark it done. These never end a task: You do What happens instead Save and end session The agent stops and its report is written; the task stays open Reject a draft The draft is rejected; the task is untouched Next Read and moved on; open work comes back after a few hours Remind me Put away until the day you pick, then back on your rail that morning A stopped or quiet session Nothing — only you, or the agent saying so, ends a task Reopening a completed task starts a fresh task lifecycle rather than pretending an old terminal is still alive. Sending work to a coding agent Open Agent work , choose the CLI and model, and start. The session is handed the task summary, the incoming messages, the attachments, any saved result from an earlier run and your optional new prompt — plus a context file under ~/.taskuary/context/ holding the thread, relevant sender and topic history, the learned profile, and reports from related closed tasks. Control What it does Start coding session Starts the selected harness and model Start new coding session Picks a different harness after an earlier run stopped or hit a limit; the checkout and history are kept Save and end session Ends the session and writes its result; the task stays open until you mark it done Mark done is stronger than all of them: it closes the task and ends any live session, because a finished task should not leave an orphan process running. What an agent is doing An agent is always in one of six states. Each has one word and one mark, and the work rail, the Timeline, the task page, the Board, the assistant's cards and the phone all use the same ones. Mark State What it means Your move ⏳ waiting to start Handed to an agent, not running yet Start now ⚙️ agent working Running, and needs nothing from you Leave a note for when it stops 👋 agent waiting on you Running, and it asked you something, needs your approval, or is stuck Answer it 💾 session saved You ended it with Save and end session ; its report is written Continue session , or Mark done ⏹ agent stopped It ended without finishing: a crash, a closed pane, Taskuary closing Continue session , or hand it on ✅ agent finished The agent closed the task, or the item it came from was merged or closed Read the result ![How an agent starts: handed off, auto start allowed or not, a free slot or next in line](img/agent start.svg \"Waiting to start always says why.\") ![While it runs: working, or waiting on you a question, an approval, stuck on a limit, quiet at its prompt](img/agent run.svg \"Your answer puts it back to work.\") ![How it ends: agent finished, session saved, the task closed, or agent stopped and Continue session](img/agent end.svg \"Only a session that ended by itself reads as stopped.\") It ended because What you see What brings it back The agent said it was done its Close out card if its work lives on GitHub, then ✅ agent finished ready to close out if a reply is owed a new message on it You pressed Save and end session 💾 session saved the report is written, the task stays open Continue session You pressed Mark done the task is closed and the agent stopped they write again The session crashed or was closed, or Taskuary closed ⏹ agent stopped a reply it had held is back for your yes Continue session , or Run another agent Continue session works for a coding agent (it reopens its own CLI session, or a fresh one seeded with the handover) and a regular agent (its saved conversation). It asks what to tell it as it picks up optional; on the phone the next thing you type is the note, or tap Continue as is . The saved result is deliberately short. Every finished coding session also writes a full Markdown artifact with that result and the complete transcript — Work details → Full artifact on the task page. When the agent opens a browser With the optional agent browser tool installed, the page the agent is on appears live beside the terminal. Take over hands you the mouse and keyboard for a password or a 2FA code the agent must never type; Snapshot keeps the frame on the task as an attachment. On the Wall, a narrow tile shows a \"browser\" chip that opens the page over the session. The general agent Not every job is code. A general task opens a conversation instead of a terminal: research, planning, writing, weighing an option, working out what to ask. No system is touched. You reach it from Talk it through on a Timeline row, from ＋ New → Give an agent a job → Just talk it through , or from Prepare me for it on a calendar invite. General chats save their provider, model and native conversation id across restarts. Claude and Codex resume that exact conversation when it still exists and the provider configuration matches; otherwise the assistant continues from Taskuary's own saved history and says so. Sessions and transcripts Continue previous work on the Assistant page lists unfinished tasks that have saved agent work, each with an excerpt of the latest reply or handover. Resume opens the task and carries on; Review draft opens a pending result. Loading the page starts nothing, and a session already running is opened rather than duplicated. Reopening a pane seeds it from a render of the session, not from raw bytes, so a pane you come back to shows what the screen actually looked like. Several agents in one repository Taskuary can run more than one coding session against a shared checkout, and spends real effort on not letting them collide: Affinity routing asks whether a queued task is likely to touch the same files as a running one. Likely overlap waits, and starts by itself when the first session ends. Tell the agent queues your notes until the CLI is back at its prompt, so a note never lands mid turn or on top of a question waiting for you. Lists drip in one item per stop; pasted screenshots are saved locally and named in the note. The blackboard shows what each session has actually modified, computed from Git and the run trace rather than from what the agent said it would do. A new agent is handed that picture at startup. First in has control. The newcomer is told which files belong to another session and must not edit, revert, stash or commit them. Live handoffs on the Board shows what each agent is working on, what is blocked and what is ready for someone else, with read markers for which agents have seen each note. The Hub is the longer lived version of the same idea: discoveries and decisions by topic, so knowledge outlives the job that produced it. Checklists and closing A task can carry a checklist. Tick the boxes as you go, then press Mark done — ticking the last box does not close the task on its own. Closing a task ticks every remaining box: a closed task with open items is a lie about its own state. Replies The Reply section exists whenever the task has an incoming sender. It shows one of three things: no draft yet, a draft ready, or a reply sent. Open on the task is the only road out — type your own or generate one, edit it, approve it. One reply is special. A clarification stops the active agent when it is sent and moves the task to waiting, because an external answer is now required. An ordinary reply","body":true},{"t":"","c":"Assistant buttons","u":"./assistant","x":"The Assistant walks you through what is waiting: one item at a time, with a few buttons under it. There are eight buttons in all. Anything without a button still works when you ask for it in your own words, in the app or on your phone. One screen: the sidebar and the canvas Taskuary is one screen. The sidebar on the left is your work rail; the canvas on the right is the conversation, and whatever part of the app is in use opens inside it. Where What is there Top of the sidebar New (a task, a report or a workflow), then Reports , Connections , Hub and Settings Under the buttons Work \\ Timeline which rows the rail shows and the filter, then the day's count and Sync now The rail On you , Agents working , For later , Reports , Advisor ideas , FYI click a heading to walk that section The canvas The item on the table: a task opens as its full task view Task, Agent work, Close out with Next under it The top bar Board every agent and its session, full screen and back to the Assistant Reports, Connections, Hub and Settings are browsed in the canvas , by clicks: a button shows that part's sections, a section shows its cards, and a card opens with its own controls Back returns to the list. Ask the Assistant about the card that is open (\"why is this failing?\", \"turn this on\") and it knows which one you mean. An agent's session opens inside the task view, nearly the full height of the canvas; Expand gives it all of it. On a phone the task view is the screen, and Expand takes the session full screen with a back arrow to the chat. The buttons on each card ![Which buttons each kind of card shows](img/assistant buttons.svg \"Next is on every card. Nothing else is offered unless that card can actually do it.\") Button Shown on What it does Runs Next every card Marks it read and moves on. Open work you pass comes back after a few hours (Settings → Passed work comes back after) at once Mark done a draft reply, a finished agent, a task The one close: the task is done, an unsent draft is retired, a live agent is stopped, and it leaves your rail at once Close out a draft reply, a task's close out (a pull request to merge, an issue to close) Finishes the task the normal way for where it lives, then Mark done: sends the draft; on GitHub merges the pull request or closes the issue and posts the reply as its comment. The line under the card says which you confirm Run it an agent's proposal Runs the action the agent proposed you confirm Reply a person's ask, a finished agent with no draft Writes a draft reply. Nothing is sent at once Make a task an ask, an fyi, an idea A task on your own list. No agent starts you confirm Send to agent an ask, an fyi, an idea, a meeting, a report A task and an agent on it. The card asks which agent you confirm Not ours a draft reply, a proposal (not a close out), an ask, an fyi Files it. The card asks how far you confirm Send back to the agent a draft reply on a task (under More actions); a close out GitHub refuses for merge conflicts (the main button) Picks the task's own agent back up with your note or, on a conflict, GitHub's reason as the first thing it hears. The card comes back when it stops at once Save and end session an agent waiting on you Writes up what the session did and stops the agent. The task stays open at once Remind me any card with an open task behind it Asks for a day, then puts the task away until that morning: under For later on your rail, with its day. On the phone the days come as choices you pick the day A handful of fyi comes as one card with its own All read, next button. A close out card for a pull request also shows Decline (close it without merging) on the card only, never as a chat word or a phone choice and no separate Reject: the reply on it is edited or redrafted in place. The two buttons that ask one question ![Not ours asks how far; Send to agent asks which agent](img/assistant questions.svg \"The card asks; nothing runs until you confirm.\") Button Answer What happens Not ours Just this once This message is filed. Its task is deleted if nothing was done on it, otherwise marked done From now on Triage learns to file everything from this sender. Their mail still arrives and stays readable A rule in Settings An exclusion rule: their mail never reaches triage, and what already arrived leaves the Timeline. Reversible Send to agent A coding agent A task and a coding agent in a repository. The card asks which repository when it is not clear A non coding agent A task and an agent for reading, checking, drafting or research Send to agent starts on the agent triage would pick; the other is one click away on the card. Pictures, and your voice Paste a screenshot, drop an image, or use the paperclip in the chat line, in New , and in Continue session . It goes with your words: the Assistant looks at the picture itself, and a coding agent is handed the file to open. PNG, JPEG, GIF and WebP, up to eight at a time. The microphone beside each box dictates into it. Continue session opens as a card under the item, not a popup: type or say what to tell the agent as it picks up, add a picture, or continue as is. Moving on with Next puts the card away with the item. Remind me Every open task has Remind me on its page: tomorrow, next week, in 2 weeks, in a month, or any day from the calendar. Until that day the task waits under For later on your rail, saying when it comes back. That morning a note goes on the task and it is back under On you , however long ago it arrived. Ask the Assistant the same thing — \"bring TQ 0123 back in two weeks\" — and it does it at once, with an undo. Everything the task page can do Anything you can do on a task's page, you can ask the Assistant to do — about the task in front of you, or any task you name (TQ 0123). It shows you a card first, like every other action. It never guesses which task you mean. ![What you can ask about a task, and what each does](img/assistant task tools.svg \"One tool per action on the task page.\") Say, about a task What happens \"make this urgent\", \"rename it\", \"I'll take it\" Priority, title or owner changed \"this is a general job, not coding\" What kind of work it is changes, and a live session is closed if it no longer fits \"this belongs in the ledger repo\" The task moves to that repository \"tick off the first item\" That checklist box is ticked — the last box is Mark done \"add a note that Erin wants it by Friday\" A note on the task \"forward it to Erin\" A hand off is written for your yes — nothing is sent until you approve it \"ask the sender which date range they need\" The question is written for your yes \"start the coding agent on TQ 0123\" An agent starts on that task; it asks which repository when it is not clear \"continue the agent where it left off\" The agent's own last session picks up again \"stop the agent on TQ 0123\" Save and end session on that task's agent \"split this in two\" / \"it's the same job as TQ 0120\" Two tasks, or this one folded into the other \"this isn't a task\" Deleted, and triage learns it was not work \"it's done\" / \"reopen TQ 0123\" Mark done, or open again \"bring it back in two weeks\" Remind me — away until that morning \"send it\" / \"reject that draft\" / \"make it shorter\" The draft is sent, rejected, or written again Words that work typed These have no button. Say them, in the app or on your phone. Say What happens Runs \"reply and tell them…\" A draft with that gist, for your yes at once \"redraft it shorter\" The draft written again with the change at once \"yes, go ahead\" to a waiting agent Your answer goes to the agent you confirm \"run it again\" on a report The report runs again at once \"remember that…\" A fact kept in Settings → Memory, used by triage and the Assistant you confirm \"clear all the fyi\" Clears that set from the walk, with the count on the card you confirm \"set up a report that…\" A walk through for a report, connection or workflow you confirm \"stop hiding auto replies\" The setting is changed, with an undo at once \"what's waiting on me?\" Looked up and answered — tasks, reports, mail, calendar, settings at once \"what's in For later?\" The rail read by its own sections On you, Agents working, For later (with when each comes back), Reports, FYI at once Later and Tomorrow are gone: Next is the \"not now\", and Remind me puts a task away until a day.","body":true},{"t":"","c":"What the Assistant sees","u":"./assistant-tools","x":"<! Written by python m taskuary.toolcatalog from taskuary/toolcatalog.py edit the catalogue, not this page. What the Assistant is told about its tools. It gets the summary on every turn: the buckets, and each tool's name and what it needs. It asks for the detail of a bucket ( tools.list ) or a tool ( tools.describe ) only when a turn needs it. Everything it can change becomes a card you confirm, except the few that can be undone, which run at once with an undo on the receipt. The summary, sent every turn Bucket What it is for Tools, and what each needs table decide about the item on the table reply(text), approve, redraft(text), mine, regular_agent(text, as?, new?), coder(text, as?, new?), not_ours, not_ours_sender, block_sender, not_ours_kind, close, done, next, answer_agent(text), stop_agent, rerun, remember(text), setup(text), confirm, cancel, chase, let_go, elsewhere task change any task the one on the table or one named with ref task.update(priority/title/assignee/due), task.set_kind(kind), task.set_repo(repo), task.check(item, done?), task.checklist(items?, emails?, drop?), task.watch(what?), task.comment(text), task.split(text), task.merge(into), task.reopen, task.not_a_task, task.complete, task.defer(until), task.handoff(who, note?), task.clarify(text), review.approve, review.reject agents start, continue, answer or stop the agent on a task, and teach where work belongs dispatch.prepare(kind, instructions?), agent.continue, agent.answer(text), agent.stop, routing.remember(field, value) new new work with no task yet task.create_from_text(kind, text), task.create_from_message(kind), task.setup(text) pipe the walk and sets of items, and filing mail pipe.clear, item.settle(verb), message.file, message.archive, preference.exclude_sender(scope), preference.sender_rule reports reports and workflows report.create(config), report.run, report.rerun, report.pause, report.resume, report.route(line, how), report.edit(config), report.delete app settings, connections, roles, scripts and kept facts setting.set(setting, value), connection.create(type, name), role.apply(role, portal?, route_mail?), connection.test, connection.pause, connection.resume, script.start(name), memory.remember(note), hub.publish(title, body, topic?, kind?, why_earned?) look look ups they run at once and change nothing task.read, timeline.search, tasks.list, asks.list, message.read, sender.read, docs.search, agents.now, approvals.list, pipe.list, calendar.read, activity.list, errors.list, memory.list, rules.list, missed.check, report.read, reports.list, settings.list, setting.read, connections.list, connection.read, agents.list, repos.list, tools.list, tools.describe, knowledge.search A task you name goes in ref (\"TQ 0123\"); otherwise the tool acts on what is on the table. Table Decide about the item on the table. reply Write a reply to the sender. Nothing is sent. text the gist, in the owner's words <p class=\"runs\" At once a draft, nothing sent.</p approve The owner's yes to what is drafted on the item: sends the reply as it stands on a task's close out (Close out) it merges the pull request or closes the issue FIRST, then sends the reply; on an agent's proposal it runs that action. It never continues an agent's session that is agent.continue. <p class=\"runs\" Waits for your yes on a card.</p redraft Write the draft again. text the change <p class=\"runs\" At once a draft, nothing sent.</p mine Make it a task on the owner's own list no agent. <p class=\"runs\" Waits for your yes on a card.</p regular_agent Send it to a non coding agent it becomes a task of its own. text the job as (optional) a profile from agents.list, only when one fits new (optional) true when the job is NOT about the item on the table <p class=\"runs\" Waits for your yes on a card.</p coder Send it to a coding agent. Not sure which repository is no reason to ask CALL it, and its card offers every repository to pick. text what is wanted as (optional) the repository (repos.list), only when sure new (optional) true when the job is NOT about the item on the table <p class=\"runs\" Waits for your yes on a card.</p not_ours File it, just this once its card asks whether from now on, or as a rule. <p class=\"runs\" Waits for your yes on a card.</p not_ours_sender File everything from this sender from now on their mail still arrives and stays readable. <p class=\"runs\" Waits for your yes on a card.</p block_sender An exclusion rule in Settings: the sender never reaches triage again only when they ask for a rule. <p class=\"runs\" Waits for your yes on a card.</p not_ours_kind An Advisor idea only: put it down AND no more ideas like it the Advisor's next run reads that. <p class=\"runs\" Waits for your yes on a card.</p close Mark done the task behind the item is finished. <p class=\"runs\" At once.</p done The owner handled it Mark done on a task; on an idea, a report or an fyi it is read and settled. <p class=\"runs\" At once.</p next Move on to the next thing. <p class=\"runs\" At once.</p answer_agent Answer the agent waiting on the owner. text <p class=\"runs\" Waits for your yes on a card.</p stop_agent Save and end the agent's session on the item. <p class=\"runs\" At once.</p rerun Run the report on the table again. <p class=\"runs\" Waits for your yes on a card.</p remember Keep a fact. text <p class=\"runs\" Waits for your yes on a card.</p setup Build a report, a connection to another system or an automation. Never a to do. text the request <p class=\"runs\" Waits for your yes on a card.</p confirm The owner's yes to the card already waiting only when one is. <p class=\"runs\" At once.</p cancel The owner's no to it. <p class=\"runs\" At once.</p chase Chase the person who has gone quiet on the item a short nudge in the owner's voice is drafted on the thread, copying whoever the ledger says moves them; nothing is sent. <p class=\"runs\" Waits for your yes on a card.</p let_go Let the quiet item go the step somebody owed is dropped, or the follow up is put down; three on one person and the Advisor stops raising them. <p class=\"runs\" Waits for your yes on a card.</p elsewhere They answered elsewhere; the step somebody owed closes as done, or the follow up is put down. text where (a call, a meeting) <p class=\"runs\" Waits for your yes on a card.</p Task Change any task the one on the table or one named with ref. task.update Change a task's priority, title, owner or due day. Any other value is refused with the allowed ones. priority low normal high urgent title assignee exactly owner (the owner takes it) or agent:<profile (a worker on the roster) due the day the work is due (2026 10 30, \"friday\", \"2 weeks\", or \"none\" to clear it) ref (optional) the task (TQ 0123), when it is not the one on the table <p class=\"runs\" Waits for your yes on a card.</p task.set_kind Say what kind of work a task is. kind task (the owner does it) general (a non coding agent) coding ref (optional) the task (TQ 0123), when it is not the one on the table <p class=\"runs\" Waits for your yes on a card.</p task.set_repo Put a coding task in the repository it belongs in. repo its name, as the repositories list says it ref (optional) the task (TQ 0123), when it is not the one on the table <p class=\"runs\" Waits for your yes on a card.</p task.check Tick a checklist item on a task. item its NUMBER (1 is the first; the facts list them numbered) done (optional) false un ticks ref (optional) the task (TQ 0123), when it is not the one on the table <p class=\"runs\" Waits for your yes on a card.</p task.checklist Change what a task's checklist asks for. items (optional) the full list of item words in order (one left out is removed, emails untouched) emails (optional) [{to, about}] to add emails that must go out before it closes drop (optional) recipients whose email is no longer owed ref (optional) the task (TQ 0123), when it is not the one on the table <p class=\"runs\" Waits for your yes on a card.</p task.watch Tell the owner here when something happens on a task nobody needs to start. what (optional) done (when it is finished) reply (when someone writes on it) any (the default) off ref (optional) the task (TQ 0123), when it is not the one on the table <p class=\"runs\" Runs at once, with an undo on the receipt.</p task.comment File a note on a task. text ref (optional) the task (TQ 0123), when it is not the one on the table <p class=\"runs\" Waits for your yes on a card.</p task.split Split one arrival into two jobs. text <p class=\"runs\" Waits for your yes on a card.</p task.merge Fold a task into the one it duplicates. into the survivor's ref (TQ 0123) ref (optional) the task that is the one folded away <p class=\"runs\" Waits for your yes on a card.</p task.reopen Reopen a task that was marked done. ref (optional) the task (TQ 0123), when it is not the one on the table <p class=\"runs\" Waits for your yes on a card.</p task.not_a_task Delete a task and teach triage it was never work. ref (optional) the task (TQ 0123), when it is not the one on the table <p class=\"runs\" Waits for your yes on a card.</p task.complete Mark done the task is finished (note: optional, what came of it kept on the task) <p class=\"runs\" Waits for your yes on a card.</p task.defer Remind me: put an open task away until a day and bring it back then. \"Remind me about <a task that exists \" named by ref, sender or subject is this, never a new to do. until a date (2026 10 09), \"2 weeks\", \"3 days\", \"monday\", with the time they said kept (\"tomorrow 9am\", \"friday 2pm\"), \"after_meetings\" when they mean once the day's meetings or calls are over (the calendar picks the time), or \"none\" to bring it back now ref (optional) the task (TQ 0123) when it is not the one on the table <p class=\"runs\" Runs at once, with an undo on the receipt.</p task.handoff Hand a task to a PERSON. who a name or address that has written here note (optional) writes the forward for the owner's yes, nothing is sent from this card ref (optional) the task (TQ 0123), when it is not the one on the table <p class=\"runs\" Waits for your yes on a card.</p task.clarify Prepare a question for the task's sender; it waits for the owner's yes, never sent from here. text the question ref (optional) the task (TQ 0123), when it is not the one on the table <p class=\"runs\" Waits for your yes on a card.</p review.approve The owner's yes to what is drafted: sends the reply as it stands and on a task's close out merges the pull request (or closes the issue) FIRST, sending the reply only if that worked. <p class=\"runs\" Waits for your yes on a card.</p review.reject Reject the draft reply waiting on a task nothing is sent, the task stays open. ref (optional) the task <p class=\"runs\" Waits for your yes on a card.</p Agents Start, continue, answer or stop the agent on a task, and teach where work belongs. dispatch.prepare Start an agent on an EXISTING task; a coding task asks which repository when it is not clear. kind coding general instructions (optional) ref the task (TQ 0123) always named, the one on the table included; a new job is task.create_from_text <p class=\"runs\" Waits for your yes on a card.</p agent.continue Pick up the agent's own last session on a task where it left off, coding or not. ref the task (TQ 0123) the one on the table when it has a saved session to reopen note when the owner said what to tell it as it picks up <p class=\"runs\" Waits for your yes on a card.</p agent.answer Answer the agent that is waiting. text ref (optional) its task when it is not the one on the table <p class=\"runs\" Waits for your yes on a card.</p agent.stop Save and end an agent's session the one on the table, or the task ref names; never a guess at which. ref (optional) the task (TQ 0123), when it is not the one on the table <p class=\"runs\" Waits for your yes on a card.</p routing.remember Remember how work like this should be ROUTED next time. kind: coding (an agent in a checkout) general (the assistant) task (the owner, no agent). system: where the work actually lives when no repository here can touch it, named ","body":true},{"t":"","c":"Reports and the Advisor","u":"./reports","x":"Reports are how Taskuary reads the systems you work in. The Advisor is a report with a different job: instead of filing what it read, it decides whether any of it is worth your attention. They share one builder, which is why they share one page here. A report is a pipeline One report is one saved configuration under Reports the sidebar's button, browsed in the canvas built in four steps. Step What it decides Pipeline The title, the sources it reads, and the one prompt that reads all of them Test & preview Test calls a single source; Preview runs the whole pipeline, AI pass included, filing nothing Where each run goes What makes it a task, then the route card: Timeline, alert and send, each every run, ask the AI, when a rule trips, or never Schedule & save How often it runs Sources at the top, one prompt at the bottom. Every source runs on its own connection and query, the results are stacked under labelled headers, and the prompt sees all of them at once. One source failing is named in the bell; the others are filed and sent as usual. :::rule Connections owns the credential, Reports owns the question You do not configure a connection here. A source names the connector card its credentials live on. That separation is why the same database can answer five different reports without five copies of its password. ::: Sources A source card carries a type, an optional label, whatever that type needs to run, and a row cap. The type picker is grouped by where the data lives: this computer, files and sheets, databases, AWS, Azure, Microsoft 365, monitoring, corporate systems, the AI itself, the web, and Taskuary's own data. Three things are worth knowing: label is how the prompt refers to that data. Two queries against the same database are two sources, and without labels the prompt cannot tell them apart. max rows is blank by default, and blank means 200 — a cap nobody chose. When a run is capped the headline says so, so the AI can never describe a truncated slice as complete. Test — show me the data returns the exact text a scheduled run would hand the prompt. Use it before assembling the rest of the pipeline. Drag cards to reorder them; duplicate one to ask the same connection a second question. Letting the AI write the source cards A source card asks you to know things first: which of thirty odd types your data sits behind, what that type's config keys are called, and the query language of whatever is on the other end. Nobody remembers that a GL entry's amount is AMOUNT but a bill's is TOTALENTERED . So you can describe what you want instead, in three places: Where What it writes Describe the report you want , top of Reports A whole report — type, query, prompt and schedule — dropped into the builder let AI fill this in , on any source card That one card, in the type it is already set to Describe what the Advisor should keep an eye on Every source the ask needs, plus the instruction to judge them by Four things keep this from being a wish machine: 1. It may only choose a type whose connection actually exists. The catalogue is built from this install's live connectors, so it cannot answer \"connect to Salesforce\" — only tell you that nothing here reaches Salesforce and what you would have to connect. 2. The config keys come from the executors' own docstrings , so a composed card cannot drift from the keys the code really reads. 3. It reads the real schema before writing a query — an object's field list, a table's columns, which LOCATIONID the site you named actually has. Up to three look ups per ask, each a real call whose result goes back to the model. 4. It is allowed to say it does not know. Questions come back as questions, at most three, each answerable in a few words. A guessed WHERE clause on a finance report is silently wrong forever; a question costs five seconds. Everything it writes is checked before you see it: a real type, a connected one, and the keys that type needs to run at all. Nothing is saved — a composed card lands in the boxes you would have filled in by hand, and Preview runs it for real so you look at actual rows before anything is scheduled. The AI pass The prompt at the bottom of the pipeline turns rows into prose. Leave it empty and the raw rows file as they are. Write a concrete instruction — \"Summarise spend by site; flag any vendor above 10k or new this month\" — not \"summarise the data\". Brain : the triage brain writes it by default; any connector with a saved key can be picked per report. A saved pick that has lost its key stays visible and disabled rather than silently vanishing. With a prompt set but no AI connector active, the raw data files and the builder says so. A summary that fails, or comes back empty, is a failed run the report exists for the summary. When one column is a measure worth plotting, the model that just read every row says so and the run hands back a bar chart beside the text. Where a run goes Every report has one route card: four lines, and each line is every run , ask the AI (a sentence the judge answers yes or no to), when a rule trips (a number or words no AI), or never . ![When a report runs: app start, its own clock, Run due now, or run by hand one run at a time, and a switched off connection fails the run](img/report runs.svg \"A manual run is extra: it never uses up the schedule.\") ![Where a run goes: a failure goes to the bell; otherwise triage reads it, and each line of the card answers every run, the AI, a rule, or never](img/report goes.svg \"No answer from the judge counts as yes.\") Line every run ask the AI when a rule trips never Timeline A row under Reports A row when the judge says your sentence holds A row when the rule trips No row: a task, or nothing Alert Reaches you right away on your channel, no Review When the judge says so When the rule trips Never Send Out to its people, through Review unless set to send without asking When the judge says so When the rule trips Never Rule Trips when anything came back at least one row, or the headline's number is above 0 nothing came back no rows fewer than N · more than N the headline's number rows, or the total a money report leads with it mentions · it never mentions the words, anywhere in the result Send it somewhere — email, Teams, Telegram, WhatsApp, iMessage or Discord. It waits on the task for approval by default. \"Send it without asking\" is the one place in Taskuary where that gate can be switched off, and it is deliberate. Triage reads every run that worked , against TRIAGE.md and the report's own Make it a task when… sentence. A task if it needs doing a bug found, a job that did not run and otherwise a row under Reports, as the Timeline line says. A failed run is in the bell, top right, and nowhere else: no row, never a task, never an alert, never sent to anyone. It clears itself when a run works again. A send or an alert that did not go is in the bell the same way, until the next one goes. A mute covers the alert and the morning brief as well as the rail. Who judges is one setting for every report, under Settings › Triage & agents › Where runs go; blank means the brain that writes the report. try it on the last 5 runs shows what the card would have done, without posting anything. Under each report row, the last run shows what it read, what came out, and the error when it failed. Schedules Pick one or more: every N minutes, daily at HH:MM , a five field cron, or on app start. No clock at all means the report runs only when you press Run now, and its row wears a red border that says so. A slot missed while the app was closed fires once on reopen. Reports have their own clock: turning the mail poll or the startup catch up off does not stop them. Button What it does Run due now Every report that is owed, and nothing else Run now on a row That report, now. It does not use up \"once a day\" or move the next slot A scheduled run that fails is tried again at its next scheduled time, never in between. A report runs one at a time; a second Run now while it runs is told so. :::note Once a day means once a day \"At most once a day\" caps the scheduled runs of the whole report. If the 08:00 slot has already produced today's run, opening the app at 09:00 does not produce a second one. ::: The Advisor The Advisor is a report of type assistant . It runs on its own schedule and when the app opens, and it posts on the Timeline only when it finds something worth saying: an unanswered reply, context for an upcoming meeting, a task gone quiet, a pattern across incoming work, or something in the systems it watches that does not look right. Each suggestion names its evidence and carries the same words everywhere it shows up the Timeline, the Assistant chat, the work rail and your phone. What it reads, its two clocks and the outcome ledger it learns from are on [The Advisor](advisor); this section is the report that runs it. Word What it does to the idea Make a task A task on your own list; no agent starts. If triage already opened one for it, that task is the answer never a second. Send to agent An agent takes it a coding or a non coding one, as its kind says. Remind me Put away until the day you pick; it comes back that morning. Not ours Put down: the Advisor does not raise it again, reworded or not only something new on that thread brings a follow up back. Next Move on; the idea stays as it is. Marking the row done on the rail puts the idea down as handled. An idea never reopens a task that is already done new work it notices becomes a new task, carrying what it saw. Its pipeline is itself, so its Pipeline step looks different from every other report: Systems and data views to check — source cards owned by this check alone. Anything a report can read belongs here, and no saved report needs to stand behind it: the Advisor pulls each one silently and files no intermediate report. …and pull these saved data views too — existing reports it should also read. A report can stay switched off as a standalone schedule and still be pulled here. What should the Advisor surface? — one instruction over all of the above plus its own view of your work. Every post records what it reviewed and leaves a note for its next check, so it does not research the same silence twice or repeat a suggestion you have seen or put down. Each Advisor report keeps its own ideas: one report's open idea never silences another's. Four things shape it: COUNSEL.md in Settings → Docs — how it speaks, and how readily it takes a position. The Advisor report — what it watches, its schedule, its model. Settings → Advisor — thresholds such as how long a reply or task must be quiet. Settings → Learning — whether your verdicts feed back into LEARNED.md . The outcome ledger — what came of what Taskuary did: a reply that got more rounds, a close that reopened, a promise delivered late, your own next move after an agent stopped. Resolved once a day from the store's own facts; reflection reads it as evidence. See [Three brains, one voice](how it works three brains one voice). Delete the Advisor report to switch it off. Its Preview shows exactly what a run would hand the model, which is the fastest way to find out whether a watched source returns what you think it does. The morning brief is a separate report of type digest : it writes DIGEST.md and lands on the Timeline daily. Deleting that report turns the brief off. Ideas it raises Beyond what it watches, the Advisor looks at the shape of your own work and occasionally raises an idea : a system your mail keeps naming that nothing here reads, for instance at most one such system per run, and never one it has raised before. The app's own health (a report failing run after run, a connection erroring) is raised the same way, and counts toward the post's lines like everything else. Stateful workflows Monthly Zoho invoices is the first workflow on the Reports page that is not a query returning one result. One scheduled run opens a batch, the batch holds one row per customer, and each row ","body":true},{"t":"","c":"The Advisor","u":"./advisor","x":"The Advisor is the one of Taskuary's three models that thinks about your work as a whole. Triage judges each arrival and the assistant moves things on a turn; the Advisor reads everything, on a clock, and says what should happen next: what is late, what nobody followed up, which step a mail served, what worked, which system is worth connecting. It never acts. It leaves a line, an idea row or a proposal, and you or the assistant do the rest. COUNSEL.md is its voice and the assistant's both. The operational side the report that runs it, its schedule, the five words under an idea is on [Reports and the Advisor](reports the advisor). This page is what goes into it, and what it learns from. What it reads What one run of the Advisor report hands the model, today: Input What it tells the Advisor SOUL.md and JOB.md , the head of each Who you are and what matters: it weighs a slipped thread by whom it serves, and never contradicts the constitution. The chat reads both whole; the report takes the opening of each COUNSEL.md How it speaks and how readily it takes a position Your work as the hub sees it The threads of the last two days with your own lines marked, what arrived, the open tasks and what closed this week, who is out of office from their auto replies The calendar Who you meet and when: context for a meeting, and a chase that should wait for the one on Thursday The knowledge base What agents have learned, by name, so it does not raise what is already known The sources it watches The systems and saved data views on its report card, pulled silently each run Its own notes What it reviewed last time and what you put down, so it never raises the same silence twice Two more inputs reach the Advisor at reflection , the pass that rewrites LEARNED.md , rather than on a report run: LEARNED.md itself, whole, hypotheses included, and the outcome ledger below. The playbooks and your mutes are designed as inputs and not yet read. None of this is copied into a prompt you cannot see. The report's Preview shows exactly what one run hands the model. Two clocks On the clock, today. The Advisor report runs on its schedule and when the app opens; the morning brief runs daily; reflection runs at launch and after three corrections, and reads the ledger whenever it runs. These find what only a window shows: a promise gone quiet, a task nobody touched, a goal with no movement, a sender you keep hearing from through a system you have not connected. Their findings are rows, judged like any arrival, because a forgotten task is work waiting on you and belongs on the rail where Next reads it in turn. Nothing fires for absence; something has to look. On the event. The same brain also runs when one item changes: an agent stops or asks, a reply arrives on a watched thread, a mail is attached to a task, a pull request opens, a task closes, a due day is missed, a report lands. One small prompt on the light model reads the event, the item's facts, the verbs the item carries, the promoted lines of LEARNED.md and the ledger rows that bear on it, and answers with one verb from the actions the app already has and one line, or nothing. Code checks the verb is one the item offers; a verb it does not is dropped and noted. Those findings are never rows. They attach to the item at its revision and show when the walk reaches it, as ghost text in the prompt box with one pill where the send arrow sits: \"Continue session · 8 of 8 times\". The number is read from the outcome ledger, never written by the model. The pill is the card's own button through the same proposal and the same receipt; typing anything brings the arrow back. A changed item drops its old line by one comparison. The item on the table earns one bigger read, with what the hub knows about the people on it and the month's outcomes. The rail's order does not read advice, by construction: the test that pins it builds the rail with and without advice and asks for the same order. Two settings govern it, in Settings → Advisor: the switch, and a cap on judgements per hour. Seeing what it did. The clock menu on the stage opens the Advisor's notes for the item on the table: a receipt, not a transcript. Each entry says the event, what it decided (the pill and the line) or what it dropped and why (nothing to say, a verb the item did not carry, the hour's cap, no brain), and the evidence it cited by id what it cited, not everything it read. \"Why?\" in the chat is answered from the same line. What was not followed up A thread you wrote on that nobody answered, or a step somebody owes past its day, is slipped once it has been quiet past that person's usual day: half again their median answer, once the ledger has seen them answer three times, and the default from Settings → Advisor until then. Someone whose auto reply says they are away never slips. A slipped row sits inside On you , the pipe count says \"3 slipped\", and when Next brings it up the card offers four answers, each an outcome the ledger keeps: Chase them drafts a short nudge on the thread, in your voice, for your yes copying whoever the ledger has seen get them to answer, when it has. When it goes out, the reply is marked a chase, and how long the answer took is counted against them. Let it go puts it down: the step is dropped, or the follow up closed. Three Let it gos on one person and the Advisor stops raising that person; nothing else changes. They answered elsewhere closes the step as done (its box ticks) and keeps where, in your words. Remind me is the same Remind me as everywhere else. A reply arriving ends it on its own: the follow up closes and the step leaves the lane. The morning brief carries the same facts, one line each, with the person's day named. A page per person Facts about other people go to a page per person, derived from the ledger at reflection and kept under Settings → Docs → People by address: how fast they answer, whether a chase is needed, who on copy moves them, what they deliver late each line with the evidence ids it rests on, and the counted numbers underneath. The lines are the model's reading; the numbers are the ledger's. Your own lines above the block are yours and survive every recompile. The page is read wherever the hub's dossier is read: the reply drafter, triage's context, meeting prep, and the Advisor's bigger read. The outcome ledger Every store Taskuary keeps is written from one signal: your click or your sentence, at the moment you give it. LEARNED.md is what you do when you correct; the verdict and routing memories stop at the verdict. Nothing recorded what you did next, or what the world did after Taskuary acted. That is what the ledger records: one row per action the app took or proposed, filled in two halves. The action, recorded when it happens What the sweep looks for Verdict A reply sent (approved as drafted, or edited first) More material mail from them on the thread in a week. An auto reply and a calendar response are not rounds; your own later mail is not theirs settled · unsettled: N more A task closed, by any road Is it still closed a week on held · reopened An agent stopped (with or without a pull request open) Your next move: a continue, with the words you typed into the pane or the session, or a close; or nothing in two days continued · closed · left A pull request merged Two weeks on, nothing says otherwise held A promise you made in a sent mail, as a task on you with its day Delivered when, against the day you named; or a week past it with nothing kept · kept late · late A sender ignored by a rule Whether their mail became a task anyway in sixty days no regret · regret Two things keep it honest. A stop is one row per stretch of waiting, not one per turn, and it closes the moment you type into the pane: that is your next move, in your words. And resolving a row is bookkeeping, not judgment: did mail arrive, did the task reopen, did the person deliver and when are facts already in the store, and the once a day sweep reads them without a model. What the facts mean is always the model's, at reflection. Reflection distils it into the stores that exist. The resolved rows reach reflection as evidence lines with their own ids, out beside the mem , rv and task ids a learned line already cites. Habits about you go to LEARNED.md with the same grammar, the same strength, the same decay: \"green PR from the coder: you merge it, 8 of 8\"; \"the agent asks 'open the PR?': you always say yes\". A habit carries the one number it never had, the regret count. Facts about other people (\"Ray answers in three days and needs a second chase\") and about kinds of work (\"closing from a thread with an open question reopens 40%; ask first\") are the next two build steps: a page per person derived from the ledger, and work facts proposed into the playbook they belong to. The one rule A derived line never acts on its own. It changes which button comes first, what a proposal says, what triage weighs, which day a chase goes out. Autonomy stays a proposal you click. \"Stop offering\" on any line writes the opposite evidence, and deleting the line from LEARNED.md is the whole undo. Earned autonomy the Advisor proposing to do itself what you have done the same way every time, revocable from the same line is shaped for but not built; every piece here is made so it needs nothing new. What is built, and what is next Built: goals as tasks (a task whose boxes are tasks, a person as an assignee, a promise as a task on you with its day, one row per goal on the rail); the outcome ledger with its daily sweep and reflection reading it; the Advisor on the event, with the prompt box pill and the notes in the clock menu; a page per person and a per person day, with the slipped lane and its four answers. Next: triage naming which goal step a mail serves, and work facts proposed into playbooks.","body":true},{"t":"","c":"On your phone","u":"./phone","x":"The assistant you talk to in the app is reachable from your phone over WhatsApp or Telegram. It is the same conversation and the same assistant — not a notification feed and not a second, weaker bot. It can walk you through your work, answer questions about it, and carry out the things the page can carry out. The doorways A doorway is one chat, on one channel, that the assistant is allowed to speak in. Set it up in Settings → Assistant on your phone , which lists every channel you have connected and lets you pick the chat and whether it may listen. 1. Connect WhatsApp or Telegram under [Connections](connections chat). 2. Send a message to the private chat you want to use — on WhatsApp that is the Message yourself chat. 3. Pick that chat in Settings. Taskuary names it as the Assistant chat and switches on the assistant for it. The Assistant then offers Walk me through them in WhatsApp (or Telegram) for each chat set up this way. Which chat the Assistant offers in the same section picks one — WhatsApp, Telegram, or both. :::rule Only chats you are alone in The picker offers nothing but chats with one member: you. Groups cannot be selected, because an answer may name anything in your workspace. The rule is enforced again when a message arrives, so the picker is a convenience rather than the guard. ::: Only messages sent by the linked owner account, in that exact chat, are accepted. Taskuary marks its own bridge output so its notifications can never loop back in as if you had typed them. What it can do Ask it in plain words. These are real examples, not a command list: \"what needs me?\" \"walk through important email\" \"what is outstanding?\" \"what did the coding agents finish?\" \"reply to Ruth that the numbers are coming tomorrow\" Walk through is the one worth knowing. It is the same turn by turn walk the Assistant page runs: one unresolved item at a time, one question, and it waits for your answer before moving on. The phone is not given a cut down version of it — the walk carries out the page's job, including the actions at the end of each item. Answers you give on the phone land in the desktop conversation too, because it is one conversation with two doors. Choosing The phone is the desktop Assistant in a chat, word for word. Every button the desktop card draws is a numbered line here, and on WhatsApp the same choices come again as a poll under the message, so one tap picks even when the only choice is Next . A number or a tap runs exactly what the desktop's button runs, and no model reads it. Only words you type go to the model. ![A number or a poll tap runs the desktop's action; Not ours asks how far, Send to agent asks which agent, an unclear checkout asks which repository; typed words go to the model](img/phone choices.svg \"A pick is the button; words are words.\") You send What happens a number, or a tap in the poll the desktop button with that name, run at once and if the model is still answering something you typed, that answer is dropped and the pick goes first Not ours \"How far?\" — just this once, from now on, or a rule in Settings; the answer you pick runs Send to agent \"Which agent?\" — triage's pick first, the other one next; the answer you pick runs a coding job with no clear checkout \"Which repository?\" — the best guess first; the one you pick starts Undo (offered under a receipt that can be undone) puts the last change back, once More the rest of a long message or, on a finished agent, its report then the same choices an old number, after you have already replied nothing — a list answers one reply, then its numbers are gone anything typed \"next\", \"undo\" and \"set up\" too the model reads it, with the same tools as the desktop. No typed word is a shortcut; only a number or a poll tap is a pill Typed words are answered by the Assistant's brain the same one, and the same model, as the Assistant in the app (Settings → Triage & agents → Assistant). A Claude Assistant runs at low effort unless its model names one ( claude sonnet 5@medium ): a turn is a short answer, and Sonnet's own default is high. Approving things A drafted reply comes to the chat with its Close out choice the same button as on the desktop, as a number or a poll tap. Nothing goes out without that pick: approving on your phone is the same deliberate act as approving on the page. The chat never pings you on its own: it speaks when you write to it or hand it the walk. The morning line Off unless you switch it on (Settings → Assistant on your phone). Once a day, the assistant can then open with a short line about the day ahead — what slipped, what is waiting, today's meetings. It is the morning brief's voice, cut to the length of something you read while walking. It fires once per day, not once per app start, and it is the same cap the brief itself uses: if today's line has gone out, reopening the app does not produce another. Handing over When a conversation on the phone reaches something better done at a keyboard — a coding session, a long document, a report builder — the assistant hands over rather than pretending. The tab it hands to locks onto that item so you arrive where the conversation left off, and the phone thread says so plainly instead of going quiet. The reverse is true too: a walk started on the page can be picked up on the phone, because the walk's position belongs to the conversation rather than to the surface you started it on. What it will not do It will not speak in a group chat, or in a chat you did not choose. It will not send anything a human has not approved, on any channel. It will not change a setting behind your back. A change you ask for comes back with an undo, or as a card for your yes. It will not answer someone else in your chat — only the linked owner account is heard. :::warn WhatsApp is an unofficial bridge The WhatsApp connector runs a local bridge against an unofficial protocol. It works well, and it is not a supported WhatsApp product: use a number you can afford to lose. Telegram uses a proper bot API and has no such caveat. ::: Sections, For later and browsing, on the phone The morning line and the walk offer the rail's sections as choices Walk On you , Walk For later , Walk Reports , Walk FYI and you stay inside the one you picked until it is empty, whether you press Next or act on the item (Make a task, Send to agent, Remind me). When the section runs out it says so, and the walk carries on. Rows under For later say when they come back (\"back in 3h\"). Connections , Reports , Hub and Settings are choices too the desktop sidebar's four, as picks: Pick You get Connections its sections with a count each, then a section's cards with on / off, then one card: what it does, and \"say set it up \" Reports every report and workflow with its clock and how its last run went, then one: when it runs, where it goes, what the last run said Hub what the agents worked out, newest first, then one entry in full Settings its sections, then each setting with its value, then one setting: what it does, and \"say what it should be\" Each step has Back as a choice. A list longer than a poll can hold (twelve) comes ten at a time with More (N left) and From the top ; a number you type still picks anything you can see. Changing anything is words \"run it now\", \"set it up\", \"make it hourly\" and comes back as a card for your yes, as in the app. A report's rows arrive as rows ( Lakeview · 112 ), laid out like any other table on the phone. Telegram gets the same cards, with its own buttons instead of a poll and no bold.","body":true},{"t":"","c":"Settings reference","u":"./settings","x":"Settings is a rail of pages, each one long page you scroll. This reference covers the Configuration page — every knob, in the sections the app itself shows them in. :::note This page writes itself Everything below the next heading is generated from taskuary/settings_schema.json , the same file the Settings page and the assistant read. A knob added to the app appears here on the next build, with the same name, the same group and the same help text. It cannot drift, and nobody has to remember to update it. ::: The other Settings pages are documented where their subject is: About you and the per channel identities, Routing policies ([the deterministic layer](how it works what triage actually decides)), Verdicts & notes ([the evidence behind LEARNED.md](how it works correcting it teaches it)), Audit integrity , and Updates ([updating](index updating)). How to read this Each setting shows what it does, and its shipped default. A few notes that apply throughout: Blank is meaningful. For a brain or model setting, blank means \"decide from what is connected\" rather than \"off\" — the specific fallback is given per knob. A switch that is off is off for everything , not just the surface you are looking at. Four AI slots — the triage brain, the default coding CLI, the assistant and the general agent, plus the judge that decides where a report run goes — are set on the cards at the top of the Configuration page rather than as plain rows. They appear below with their fallback rows, which is what you see if those cards cannot load. Triage & agents Triage brain triage_ai · type: brain · default: blank · set on a card at the top of the page Which AI reads and classifies inbound messages. TWO BRAINS: a small, fast cloud model (Anthropic / OpenAI / Azure OpenAI) classifies each message in under a second for a fraction of a cent, while your CLI agent — the expensive, capable one — is saved for actually working tasks. ONE BRAIN, TWO GEARS also works well: pick a CLI agent here and set its 'light model' (Docs → Profiles → Manage profiles → Edit) — triage, drafts, summaries and the digest then run on the cheap fast tier (haiku, gemini flash…) while coding sessions keep the agent's main model. No second API key, one bill. Left blank, it is your default brain on its light gear (haiku for Claude) never whichever connector was added first. Obvious automated noise is filtered by cheap heuristics before any AI is called either way. Backup AI connections triage_backup_ai · type: brains · default: blank Ordered alternatives for triage, reply drafts, summaries, reports, and assistant chat when the chosen AI is unavailable. Pick more than one. Taskuary tries them in the order shown when the primary brain hits a session or usage limit, is signed out, has no key, or otherwise refuses the call. A fallback uses its own default model; a model name chosen for Claude is never handed to Codex. This starts blank because crossing from a cloud API to a local CLI can change cost and privacy. Once you name backups, the same chain protects every short/background AI job as well as the non coding assistant. Assistant tab brain concierge_ai · type: brain · set on a card at the top of the page Which AI speaks on the Assistant tab and walks you through the pipe. auto = your default coding agent, on its faster, lighter model. THREE DEFAULTS, side by side in Triage & agents: the triage brain, the default coding CLI, and this one. A CLI agent here can ACT read a task or message, rerun a report, run a data tool because it has a shell; it runs in its own scratch folder on a light model (Claude: haiku, Codex: low effort, Gemini: flash, or the agent's own 'light model' from Docs → Profiles) and picks its conversation back up turn to turn, so only the first turn pays the start up. An API connector answers faster but can only talk. Sending, approving and pushing are your buttons whichever speaks. Assistant tab model concierge_model · type: text · set on a card at the top of the page A different model for the Assistant tab, if you want one (e.g. sonnet, or gpt 5.4 mini). Blank = the faster, lighter default. Add @low, @medium or @high to set how hard it thinks, e.g. claude sonnet 5@medium; a Claude model with nothing added thinks at low. For a CLI this is its model, and model@effort sets its reasoning effort (Claude effort, Codex model_reasoning_effort); for an API connector, its model or deployment name. Changing it starts a fresh CLI conversation. General agent brain assistant_ai · type: brain · default: blank · set on a card at the top of the page Which AI works every general task research, planning, writing, a job with no repository and answers the floating bubble. Your phone talks to the Assistant, not this. Normally set on the General agent card at the top of this tab; this row is the fallback if that panel cannot load. A CLI here can run tools, drive a browser and post to the wall; an API connector has no shell, so it can only read and write quicker, and enough for chat. Blank = the first active API connector, else the default agent. Where runs go judge_ai · type: brain · set on a card at the top of the page Which AI decides whether a finished report lands on your Timeline, your work rail, reaches you right away, or goes out. Normally set on the 'Where runs go' card at the top of this section; this row is the fallback if that panel cannot load. Four yes/nos about a result somebody else wrote, judged against the sentences on the report's own card it never has to write anything, so a decision model belongs here and a chat model is wasted on it. Blank = the brain that writes each report judges its own run. General agent model assistant_model · type: text · default: blank · set on a card at the top of the page Override the model for the brain above. Blank = the provider's own default. For an API connector this is its model or deployment name; for a CLI it is the profile's light model. Changing it starts a fresh CLI conversation. Default AI for agents default_brain · type: text · default: blank Which AI program runs an agent's work when its role does not name one. A role (coder, researcher, analyst) decides the instructions an agent starts with; this decides which program follows them. Blank = each profile's own program. Set from the cards above in normal use — this is the raw value they write. Naming a brain here is what stops a role name being read as a CLI name, which is how TQ 0588's coding work was once routed to Copilot. A role and a brain are different questions and one name cannot answer both. Fallback AI programs backup_brains · type: text · default: Tried in order when the first one has used up its allowance, is signed out, or will not start. = every other one you have set up, in the order they are listed. Failover is for AVAILABILITY failures only — session/usage/rate limits, quota, expired login, a missing executable — never for an agent that simply erred. The task, its messages, attachments, repository and seed prompt all travel to the replacement, which starts a fresh conversation with its own model. A different AI for one role profile_brains · type: text · default: blank For a role that should run on a different AI from the default above. Written as JSON, e.g. {\"researcher\": \"codex\"}. Blank (the default) means every role uses the default. The escape hatch for 'the analyst should run on codex but everything else on claude'. An unknown role name is ignored rather than guessed at. Edited here because it is rare enough not to earn a picker. Default coding CLI default_agent · type: agent · default: coder · set on a card at the top of the page The CLI agent that works tasks when nothing names one. Start session, Send to coding agent and auto dispatch all use this agent unless you pick another in the moment; every agent picker lists it first. The roster itself lives under Docs → Profiles → Manage profiles, where the default row wears the star. GitHub specific permissions (may agents open issues? push?) are on the GitHub connector card, because they are decisions about how your team uses GitHub, not about Taskuary. Triage & routing Intent triage intent_classify_enabled · type: switch · default: on Classify every new message: a task to DO, a question to ANSWER, or FYI to file. The heart of the funnel. Every inbound message is read (by the triage brain in Triage & agents, the section above, guided by SOUL.md) and classified: task = something must be done, so an agent can be dispatched; reply_only = answering IS the work, so a reply is drafted for your approval; fyi = informational, filed with no task and no draft. Off: every message becomes a task, which turns newsletters into work items. Leave this on unless you are debugging triage itself. Learn from your verdicts learn_enabled · type: switch · default: on Your corrections teach LEARNED.md — style, responsibilities, what deserves a task. Every correction you make — editing a draft before sending, rejecting one, reclassifying a task as a question, promoting something triage filed, 'Not a task' / 'Not our task' — is distilled into LEARNED.md (Settings → Docs): first as a hypothesis with a strength counter and the evidence behind it, promoted into the active profile only once it keeps holding across separate episodes. The active sections ride into every triage call, draft and agent run; SOUL.md always outranks them. Rules that would HIDE mail (treat as fyi, never a task) never activate themselves — they wait in the doc's 'Proposed rules' for you to adopt or delete. Off: nothing new is learned; the doc stays as it is and is still injected. Your mail goes to default_profile · type: profile · default: blank The worker that takes a non coding task when triage names no specialist for it. Blank leaves it unassigned for you to pick. Set this to the role you do, and the mail you get lands on the worker built for it. An accounts payable rep picks ap : a vendor asking where a payment is becomes a task for the AP worker, which looks it up in the ledger and drafts the answer for you to approve. Triage still names a specialist when one fits better (a researcher for outside information), and coding tasks always go to the coding agent. Docs → Profiles → Start from a role sets this for you. Replies Draft replies on reply_channels · type: channels · default: email,teams,slack,telegram,whatsapp,imessage,discord,github Which channels get a drafted reply at all. Switch one off and its questions just file. Options: email , teams , slack , telegram , whatsapp , imessage , discord , github A question arriving somewhere you never answer from should not open a reply task whose draft has nowhere to go. Turn a channel off and messages from it still land on the Timeline and can still become real tasks — they simply never get a draft, and the funnel says so in the row's reason ('replies are off for slack'). One answer for the whole app: triage uses it to decide whether a question becomes a reply task, the coder wrap up uses it to decide whether to draft at all, and the approval buttons on the task use it to decide whether Approve can actually send. They cannot disagree. Two rules are not yours to change here: GitHub also needs 'Reply to issue/PR authors' on its own card (a reply there is a PUBLIC comment), and the read only trackers — Jira, Linear, Sentry, PagerDuty and friends — can never carry a reply because Taskuary only reads them. Check your calendar when a reply is about time calendar_enabled · type: switch · default: on \"Tuesday at 1 works for me\" is only drafted if Tuesday at 1 is free. Reads the Outlook card's calendars (needs the Calendars.Read application permission) and a Google calendar if its OAuth fields are on the Gmail card. When the thread mentions a day, a time, a meeting or availability, the responder fetches your busy slots for the next 14 days and is told: never offer a busy time; if the asked time is busy, say so and offer the nearest free one; if the calendar could not be read, say","body":true},{"t":"","c":"When something is wrong","u":"./troubleshooting","x":"Most things that go wrong in Taskuary go wrong quietly and safely — a message gets filed instead of guessed at, a run reports its error in place instead of taking the report down. That is by design, and it means the answer to \"why did nothing happen?\" is usually written down somewhere. This page is where to look, in the order worth looking. It will not start Nothing opens. Taskuary serves http://127.0.0.1:7787 . If the browser shows nothing, check whether the process is running and, more usefully, what is actually listening: More than one Taskuary can run against the same database, and their command lines look alike. The listening port is the only reliable way to tell which one is serving you — a second instance on another port will happily keep polling and triaging with older code. The port is taken. If another Taskuary owns the port, the CLI opens that instance. If a different process owns it, the CLI automatically selects a free port and prints the new address. Use taskuary port PORT or set TASKUARY_PORT when you need a specific port instead. It started and immediately closed. A corrupt config.toml is the common cause, and it fails before Taskuary can write the useful error to taskuary.log . If you started Taskuary from pip, read the traceback in the terminal where you ran taskuary . If you started the desktop app, read ~/.taskuary/desktop error.log . Rename a corrupt config.toml and Taskuary writes a fresh default. A connection stopped A connector card shows its own last poll and its last error, and that is the first place to look. Symptom Usual cause Nothing new since a fixed time The sign in expired. Reconnect on the card \"could not read your channels\" The app is older than the page expects — restart it Mail arrives but no replies go out Replies are off for that channel, or the card has no send authority A tracker connected but silent Nothing is assigned to the connected user — that is what it reads WhatsApp went quiet The bridge lost its session. Re pair it; the unofficial protocol does this periodically If the card looks healthy and items still are not appearing, check the card's roles . A connection with no trigger or feed role is never polled, which looks exactly like a broken connection from the Timeline. Triage got it wrong First, work out whether triage ever saw it. Open the row: it says what decided the outcome and why. [What triage actually decides](how it works what triage actually decides) lists the eleven steps and which of them are deterministic gates. Stopped by a gate (a feed connection, a policy rule, your own standing ruling, an agent already waiting) — the fix is that rule, that role or that ruling. The classifier was never asked. Judged and wrong — correct it on the Triage tab. The correction is written into TRIAGE.md and applies to the next message like this one. \"Awaiting AI triage\" — there is no AI connector active, so nothing was guessed. Add a key, and the retry sweep picks it up. \"Triage failed\" — the call failed or returned something unreadable. It was filed rather than assumed to be work; the row keeps the error. :::note A verdict you disagree with is not a bug Triage is supposed to be argued with. The correction loop exists because the right general rule is rarely knowable from one message — and a correction teaches the class, not the sender. ::: A reply has no confirmed delivery Approval stays pending while Taskuary sends the reply. Repeated clicks do not start another send, and a task closes only after the provider confirms delivery. Delivery unknown means the provider timed out, the process stopped during sending, or a receipt could not be verified. Check the provider's sent messages before taking any further action. Approving again checks the original attempt; it does not resend just because a receipt is missing. Providers that cannot verify the attempt leave it pending for you to investigate. Sending failed means the attempt was rejected or blocked. Fix the connection or send permission, then review and approve the draft again. An agent is stuck It is waiting on you. A raised hand on the Studio floor, or a 👋 agent waiting on you row on the Board or the work rail, all mean the same thing: the session asked something. Open the task and answer it. It is waiting on its CLI. A headless agent without its noninteractive flag hangs forever on a prompt that cannot be answered. The connector presets set the flag; a custom CLI needs it added. The card's Test action reproduces it in ten seconds. It hit a limit. The saved result says so. Start new coding session picks a different harness and keeps the checkout and the history. It says there is no local path for the repository. Map that repository to its checkout on the AI CLI agent card, or make the checkout discoverable. A task naming a repository cannot fall back to an unrelated default working folder. It is gone. If the process died, the row reads ⏹ agent stopped and is forced unread, so it comes back to you rather than disappearing. Only Later holds it. Save and end session ends the session, files what it did and drafts the reply for you to approve; it leaves the task state alone and sends nothing. If you want the task closed, Mark done does both. A report returned nothing Open the report row: the last run shows what it read, what came out, and the error if it failed. One source failed — it is reported in place and the rest of the pipeline still ran. Fewer rows than you expected — check max rows . Blank means 200, which is a cap nobody chose, and a capped run says so in its headline. The prose does not match the numbers — Test — show me the data on the source card returns the exact text the prompt was handed. That is almost always where the surprise is. It never ran — a slot missed while the app was closed fires once on reopen, not once per missed slot. Run due now forces everything owed. Reading the audit log Settings → Audit integrity is the answer to \"why did this happen\" and \"who did this\". Every consequential action is one row: routed, filed, replied, opened, saved, deleted — with the actor, the time, and the thing it happened to. Verify recomputes the hash chain from the first row and tells you whether the record has been altered since it was written. \"Out of order\" is benign — two writers raced once. \"Contents altered\" is not, and it names the rows. Where the logs are Thing Where Application log ~/.taskuary/taskuary.log Desktop startup crash ~/.taskuary/desktop error.log The database ~/.taskuary/taskuary.db Configuration ~/.taskuary/config.toml A coding session's full transcript the task page → Work details → Full artifact The context an agent was handed ~/.taskuary/context/ Playbooks ~/.taskuary/playbooks/ .md Under Docker, all of it is /data inside the container. TASKUARY_HOME moves it anywhere. Still wrong The live API reference at /api/docs shows exactly what the app exposes, and is the fastest way to check whether a thing you expect is actually there. Issues: [github.com/ldbumble/taskuary/issues](https://github.com/ldbumble/taskuary/issues). Security problems go through [SECURITY.md](https://github.com/ldbumble/taskuary/blob/master/SECURITY.md), not a public issue.","body":true}]
\ No newline at end of file
+[{"t":"Start here","c":"Start here","u":"./","x":"What Taskuary is, how to install it, and what the first hour looks like."},{"t":"What Taskuary is","c":"Start here → What Taskuary is","u":"./#what-taskuary-is","x":""},{"t":"Install on Windows","c":"Start here → Install on Windows","u":"./#install-on-windows","x":""},{"t":"Install with Python","c":"Start here → Install with Python","u":"./#install-with-python","x":""},{"t":"Command-line options","c":"Start here → Command-line options","u":"./#command-line-options","x":""},{"t":"Docker","c":"Start here → Docker","u":"./#docker","x":""},{"t":"Your first run","c":"Start here → Your first run","u":"./#your-first-run","x":""},{"t":"Choosing the AI setup","c":"Start here → Choosing the AI setup","u":"./#choosing-the-ai-setup","x":""},{"t":"Where your data lives","c":"Start here → Where your data lives","u":"./#where-your-data-lives","x":""},{"t":"What leaves your machine","c":"Start here → What leaves your machine","u":"./#what-leaves-your-machine","x":""},{"t":"Updating","c":"Start here → Updating","u":"./#updating","x":""},{"t":"Next","c":"Start here → Next","u":"./#next","x":""},{"t":"How it works","c":"How it works","u":"./how-it-works","x":"One message from arrival to approval: the Timeline, the five roads, and what triage actually decides."},{"t":"The Timeline","c":"How it works → The Timeline","u":"./how-it-works#the-timeline","x":""},{"t":"The five roads a message can take","c":"How it works → The five roads a message can take","u":"./how-it-works#the-five-roads-a-message-can-take","x":""},{"t":"What triage actually decides","c":"How it works → What triage actually decides","u":"./how-it-works#what-triage-actually-decides","x":""},{"t":"Nothing sends itself","c":"How it works → Nothing sends itself","u":"./how-it-works#nothing-sends-itself","x":""},{"t":"Correcting it teaches it","c":"How it works → Correcting it teaches it","u":"./how-it-works#correcting-it-teaches-it","x":""},{"t":"Three brains, one voice","c":"How it works → Three brains, one voice","u":"./how-it-works#three-brains-one-voice","x":""},{"t":"The documents that govern it","c":"How it works → The documents that govern it","u":"./how-it-works#the-documents-that-govern-it","x":""},{"t":"Where the rest of the workspace fits","c":"How it works → Where the rest of the workspace fits","u":"./how-it-works#where-the-rest-of-the-workspace-fits","x":""},{"t":"Connections","c":"Connections","u":"./connections","x":"The accounts Taskuary may read, and the role that says what it may do with each."},{"t":"What a connection is","c":"Connections → What a connection is","u":"./connections#what-a-connection-is","x":""},{"t":"The five roles","c":"Connections → The five roles","u":"./connections#the-five-roles","x":""},{"t":"Mail","c":"Connections → Mail","u":"./connections#mail","x":""},{"t":"Chat","c":"Connections → Chat","u":"./connections#chat","x":""},{"t":"Repositories and trackers","c":"Connections → Repositories and trackers","u":"./connections#repositories-and-trackers","x":""},{"t":"Data and report sources","c":"Connections → Data and report sources","u":"./connections#data-and-report-sources","x":""},{"t":"Coding CLIs and AI providers","c":"Connections → Coding CLIs and AI providers","u":"./connections#coding-clis-and-ai-providers","x":""},{"t":"Adding another of the same kind","c":"Connections → Adding another of the same kind","u":"./connections#adding-another-of-the-same-kind","x":""},{"t":"Pushing something in yourself","c":"Connections → Pushing something in yourself","u":"./connections#pushing-something-in-yourself","x":""},{"t":"Tasks and agents","c":"Tasks and agents","u":"./tasks-and-agents","x":"A task, the agent work on it and the reply to the sender are three separate lives."},{"t":"A task's three lives","c":"Tasks and agents → A task's three lives","u":"./tasks-and-agents#a-tasks-three-lives","x":""},{"t":"Sending work to a coding agent","c":"Tasks and agents → Sending work to a coding agent","u":"./tasks-and-agents#sending-work-to-a-coding-agent","x":""},{"t":"The general agent","c":"Tasks and agents → The general agent","u":"./tasks-and-agents#the-general-agent","x":""},{"t":"Sessions and transcripts","c":"Tasks and agents → Sessions and transcripts","u":"./tasks-and-agents#sessions-and-transcripts","x":""},{"t":"Several agents in one repository","c":"Tasks and agents → Several agents in one repository","u":"./tasks-and-agents#several-agents-in-one-repository","x":""},{"t":"Checklists and closing","c":"Tasks and agents → Checklists and closing","u":"./tasks-and-agents#checklists-and-closing","x":""},{"t":"Replies","c":"Tasks and agents → Replies","u":"./tasks-and-agents#replies","x":""},{"t":"Profiles and playbooks","c":"Tasks and agents → Profiles and playbooks","u":"./tasks-and-agents#profiles-and-playbooks","x":""},{"t":"The task view and the Board","c":"Tasks and agents → The task view and the Board","u":"./tasks-and-agents#the-task-view-and-the-board","x":""},{"t":"The work rail","c":"Tasks and agents → The work rail","u":"./tasks-and-agents#the-work-rail","x":""},{"t":"How work is ordered","c":"Tasks and agents → How work is ordered","u":"./tasks-and-agents#how-work-is-ordered","x":""},{"t":"Assistant buttons","c":"Assistant buttons","u":"./assistant","x":"Every button under an Assistant card, the one question two of them ask, Remind me, and the words that work typed."},{"t":"One screen: the sidebar and the canvas","c":"Assistant buttons → One screen: the sidebar and the canvas","u":"./assistant#one-screen-the-sidebar-and-the-canvas","x":""},{"t":"The buttons on each card","c":"Assistant buttons → The buttons on each card","u":"./assistant#the-buttons-on-each-card","x":""},{"t":"The two buttons that ask one question","c":"Assistant buttons → The two buttons that ask one question","u":"./assistant#the-two-buttons-that-ask-one-question","x":""},{"t":"Pictures, and your voice","c":"Assistant buttons → Pictures, and your voice","u":"./assistant#pictures-and-your-voice","x":""},{"t":"Remind me","c":"Assistant buttons → Remind me","u":"./assistant#remind-me","x":""},{"t":"Everything the task page can do","c":"Assistant buttons → Everything the task page can do","u":"./assistant#everything-the-task-page-can-do","x":""},{"t":"Words that work typed","c":"Assistant buttons → Words that work typed","u":"./assistant#words-that-work-typed","x":""},{"t":"What the Assistant sees","c":"What the Assistant sees","u":"./assistant-tools","x":"Every tool the Assistant has: the summary it gets on every turn, and each tool in detail. Written from the code."},{"t":"The summary, sent every turn","c":"What the Assistant sees → The summary, sent every turn","u":"./assistant-tools#the-summary-sent-every-turn","x":""},{"t":"Table","c":"What the Assistant sees → Table","u":"./assistant-tools#table","x":""},{"t":"Task","c":"What the Assistant sees → Task","u":"./assistant-tools#task","x":""},{"t":"Agents","c":"What the Assistant sees → Agents","u":"./assistant-tools#agents","x":""},{"t":"New","c":"What the Assistant sees → New","u":"./assistant-tools#new","x":""},{"t":"Pipe","c":"What the Assistant sees → Pipe","u":"./assistant-tools#pipe","x":""},{"t":"Reports","c":"What the Assistant sees → Reports","u":"./assistant-tools#reports","x":""},{"t":"App","c":"What the Assistant sees → App","u":"./assistant-tools#app","x":""},{"t":"Look","c":"What the Assistant sees → Look","u":"./assistant-tools#look","x":""},{"t":"Reports and the Advisor","c":"Reports and the Advisor","u":"./reports","x":"Reading the systems you work in on a schedule, and the report whose job is to judge."},{"t":"A report is a pipeline","c":"Reports and the Advisor → A report is a pipeline","u":"./reports#a-report-is-a-pipeline","x":""},{"t":"Sources","c":"Reports and the Advisor → Sources","u":"./reports#sources","x":""},{"t":"Letting the AI write the source cards","c":"Reports and the Advisor → Letting the AI write the source cards","u":"./reports#letting-the-ai-write-the-source-cards","x":""},{"t":"The AI pass","c":"Reports and the Advisor → The AI pass","u":"./reports#the-ai-pass","x":""},{"t":"Where a run goes","c":"Reports and the Advisor → Where a run goes","u":"./reports#where-a-run-goes","x":""},{"t":"Schedules","c":"Reports and the Advisor → Schedules","u":"./reports#schedules","x":""},{"t":"The Advisor","c":"Reports and the Advisor → The Advisor","u":"./reports#the-advisor","x":""},{"t":"Stateful workflows","c":"Reports and the Advisor → Stateful workflows","u":"./reports#stateful-workflows","x":""},{"t":"Sage Intacct, specifically","c":"Reports and the Advisor → Sage Intacct, specifically","u":"./reports#sage-intacct-specifically","x":""},{"t":"API","c":"Reports and the Advisor → API","u":"./reports#api","x":""},{"t":"The Advisor","c":"The Advisor","u":"./advisor","x":"What goes into the brain that says what should happen next, its two clocks, and the outcome ledger that teaches it what worked."},{"t":"What it reads","c":"The Advisor → What it reads","u":"./advisor#what-it-reads","x":""},{"t":"Two clocks","c":"The Advisor → Two clocks","u":"./advisor#two-clocks","x":""},{"t":"What was not followed up","c":"The Advisor → What was not followed up","u":"./advisor#what-was-not-followed-up","x":""},{"t":"A page per person","c":"The Advisor → A page per person","u":"./advisor#a-page-per-person","x":""},{"t":"The outcome ledger","c":"The Advisor → The outcome ledger","u":"./advisor#the-outcome-ledger","x":""},{"t":"The one rule","c":"The Advisor → The one rule","u":"./advisor#the-one-rule","x":""},{"t":"What is built, and what is next","c":"The Advisor → What is built, and what is next","u":"./advisor#what-is-built-and-what-is-next","x":""},{"t":"On your phone","c":"On your phone","u":"./phone","x":"The same assistant over WhatsApp or Telegram, and what it may do there."},{"t":"The doorways","c":"On your phone → The doorways","u":"./phone#the-doorways","x":""},{"t":"What it can do","c":"On your phone → What it can do","u":"./phone#what-it-can-do","x":""},{"t":"The morning line","c":"On your phone → The morning line","u":"./phone#the-morning-line","x":""},{"t":"Handing over","c":"On your phone → Handing over","u":"./phone#handing-over","x":""},{"t":"What it will not do","c":"On your phone → What it will not do","u":"./phone#what-it-will-not-do","x":""},{"t":"Sections, For later and browsing, on the phone","c":"On your phone → Sections, For later and browsing, on the phone","u":"./phone#sections-for-later-and-browsing-on-the-phone","x":""},{"t":"Settings reference","c":"Settings reference","u":"./settings","x":"Every setting, generated from the same file the app and the assistant read."},{"t":"How to read this","c":"Settings reference → How to read this","u":"./settings#how-to-read-this","x":""},{"t":"Triage & agents","c":"Settings reference → Triage & agents","u":"./settings#triage-agents","x":""},{"t":"Triage & routing","c":"Settings reference → Triage & routing","u":"./settings#triage-routing","x":""},{"t":"Replies","c":"Settings reference → Replies","u":"./settings#replies","x":""},{"t":"Assistant","c":"Settings reference → Assistant","u":"./settings#assistant","x":""},{"t":"Assistant on your phone","c":"Settings reference → Assistant on your phone","u":"./settings#assistant-on-your-phone","x":""},{"t":"Advisor","c":"Settings reference → Advisor","u":"./settings#advisor","x":""},{"t":"Coder agent","c":"Settings reference → Coder agent","u":"./settings#coder-agent","x":""},{"t":"Agent permissions","c":"Settings reference → Agent permissions","u":"./settings#agent-permissions","x":""},{"t":"Notifications","c":"Settings reference → Notifications","u":"./settings#notifications","x":""},{"t":"Attachments & images","c":"Settings reference → Attachments & images","u":"./settings#attachments-images","x":""},{"t":"Sync & startup","c":"Settings reference → Sync & startup","u":"./settings#sync-startup","x":""},{"t":"Display","c":"Settings reference → Display","u":"./settings#display","x":""},{"t":"Routing policies","c":"Settings reference → Routing policies","u":"./settings#routing-policies","x":""},{"t":"Verdicts & notes","c":"Settings reference → Verdicts & notes","u":"./settings#verdicts-notes","x":""},{"t":"Audit integrity","c":"Settings reference → Audit integrity","u":"./settings#audit-integrity","x":""},{"t":"When something is wrong","c":"When something is wrong","u":"./troubleshooting","x":"What to check, in the order worth checking it."},{"t":"It will not start","c":"When something is wrong → It will not start","u":"./troubleshooting#it-will-not-start","x":""},{"t":"A connection stopped","c":"When something is wrong → A connection stopped","u":"./troubleshooting#a-connection-stopped","x":""},{"t":"Triage got it wrong","c":"When something is wrong → Triage got it wrong","u":"./troubleshooting#triage-got-it-wrong","x":""},{"t":"A reply has no confirmed delivery","c":"When something is wrong → A reply has no confirmed delivery","u":"./troubleshooting#a-reply-has-no-confirmed-delivery","x":""},{"t":"An agent is stuck","c":"When something is wrong → An agent is stuck","u":"./troubleshooting#an-agent-is-stuck","x":""},{"t":"A report returned nothing","c":"When something is wrong → A report returned nothing","u":"./troubleshooting#a-report-returned-nothing","x":""},{"t":"Reading the audit log","c":"When something is wrong → Reading the audit log","u":"./troubleshooting#reading-the-audit-log","x":""},{"t":"Where the logs are","c":"When something is wrong → Where the logs are","u":"./troubleshooting#where-the-logs-are","x":""},{"t":"Still wrong","c":"When something is wrong → Still wrong","u":"./troubleshooting#still-wrong","x":""},{"t":"","c":"Start here","u":"./","x":"Taskuary is a work assistant that runs on your own machine. It reads the places work arrives — mail, chats, issue trackers, monitoring, your finance system — decides what each thing actually is, and brings you the few that need you. Coding jobs go to a coding agent in your repository. Answers come back as drafts you approve. Nothing is sent without you. It keeps its data in a SQLite file in your home directory and serves its interface at http://127.0.0.1:7787 . There is no account to create and no server to rent. What Taskuary is Three sentences, because the rest of this site is detail: 1. Everything arrives in one Timeline. A vendor's email, a GitHub pull request, a Teams message, a failed nightly export and this morning's spend report are one list, in the order they happened. 2. Each item gets one verdict. A small AI reads it and decides: nothing to do, a sentence settles it, an agent should work it, let's talk it through, or it's yours. That verdict is visible, and arguing with it teaches the next one. 3. Work that can be done is done, and comes back for approval. A coding agent works in your checkout; replies wait on the task. Approving is always a human action. :::rule The one thing to understand Taskuary never sends anything by itself. Replies, comments, invoices and posts all wait for you on the task. The only deliberate exception is an alert you configured, which fires the moment its rule trips — an alert that waits for approval is not an alert. ::: Install on Windows Download [Taskuary.exe](https://github.com/ldbumble/taskuary/releases/latest/download/Taskuary.exe) and open it. It is one file: the app and the desktop shell together, with no Python and no installer. The first run creates %USERPROFILE%\\.taskuary\\ and opens the interface. Install with Python Python 3.10 or newer: The browser opens by itself. For the same interface in a native desktop window: :::note Which platform gets the most use CI runs the full test matrix on Windows, Linux and macOS. Development happens mostly on Windows, so the terminal, the desktop shell and the agent presets are best exercised there; macOS and Linux may still have rough edges. ::: Command line options The everyday options for the Python install are: Option What it does port PORT Overrides the configured server port for this run host HOST Overrides the configured server host; use 0.0.0.0 to listen on all interfaces no browser Starts the server without opening a browser tab debug Enables verbose console logging for requests, report runs and errors Run taskuary help for the complete command reference. Docker Runs Taskuary without putting Python on the host: Open http://127.0.0.1:7787 . Data lives in the taskuary data volume. The container gives you the Timeline, Review, Reports and Connections; coding CLIs and the optional WhatsApp bridge stay host programs, because both need a machine of their own. The compose file binds to localhost. Set TASKUARY_TOKEN before publishing the port anywhere else. Your first run Open Set up Taskuary on the Assistant. The first four steps get you to one useful result: 1. Say who you are. Add the name that signs your drafts, and your email so Taskuary can recognise your own messages. Detailed preferences can wait. 2. Connect one AI. Use an API provider, Ollama, or a signed in coding CLI you already pay for. Test its connection. Keep the current model defaults to start; reviewing every model assignment is optional. 3. Connect one work source. Choose one mailbox, chat, or issue tracker in [Connections](connections). Enable it as an input and test it. You do not need a mailbox if your first source is a tracker such as GitHub. 4. Press Read first items. This starts a real source read and shows its progress. Once items arrive, open one of the first five recent results to check its verdict and any draft. Replies still wait for your approval. If nothing arrives, the step explains how to check the source scope or try a new incoming message. The five items are a review sample, not an import limit: each source keeps its normal read scope and history settings. Starting with one source makes that first review easier. Setup does not overwrite an existing user's model or connection configuration. After that first result, add another source, connect a coding CLI if you want code written, or add a report for numbers you check by hand. The optional models and agents step opens the existing settings whenever you want to adjust cost or use different models for different jobs. Reports and the Hub can wait until you have a workflow that needs them. Two reports exist from the start: the End of day checkup and the Advisor , which looks for useful follow ups and patterns in your work. You can review or remove either in Reports. The Morning digest is available as an optional report. Choosing the AI setup Triage reads many messages cheaply; coding changes a repository rarely and wants a strong model. Taskuary lets those be different brains, and the choice is mostly about what you already pay for. Setup Triage, drafts, summaries Coding sessions Fits you if Two brains (recommended) a small cloud model on an API key your coding CLI's full model you have a low cost API key One brain, two gears the CLI's light model the same CLI's main model you have one CLI subscription and no key One brain, one gear the CLI's full model the same model simplest, and expensive for routine mail Local brain Ollama or any OpenAI compatible local server a coding CLI, optionally the same local model no key, and no mail leaving the machine With no cloud key, set the triage brain to your configured CLI in [Settings](settings triage agents), and give that CLI a light model on its connector card so routine triage does not burn the coding model. Where your data lives The Python and desktop installs keep everything in ~/.taskuary/ : File What it is taskuary.db the SQLite database — messages, tasks, settings, the audit log config.toml local configuration taskuary.log the application log playbooks/ .md one page per kind of job an agent has learned to do context/ the context file each coding session is handed at startup TASKUARY_HOME moves all of it. Docker uses /data inside the container. TASKUARY_HOST , TASKUARY_PORT and TASKUARY_TOKEN override server settings at runtime without being written back to the config file. :::warn Before you expose it beyond localhost Set [server].token in the config or provide TASKUARY_TOKEN , and send that token in the X Taskuary Token header. An unauthenticated Taskuary reachable from the network gives whoever finds it your mail, your repositories and an agent that can run commands. ::: What leaves your machine Taskuary calls the services you configure and nothing else. Hosted AI providers and coding CLIs receive the prompts their work needs. With a model running on your machine, those prompts stay on it too; connected services such as mail still use their own connections either way. Before a prompt reaches a hosted model, a headless CLI run or the first turn of an agent pane, Taskuary replaces recognisable credentials with labelled placeholders. The original message is never altered. A reply that still contains one of those placeholders is refused rather than sent. These are deterministic shape rules — they catch API keys and passwords that look like API keys and passwords, and they cannot catch every secret. Updating Settings → Updates shows the running build and the latest release, and installs it in place: the exe is swapped or pip install runs, and the app reopens. Connections and settings are untouched. For the Python install you can also do it yourself: Next [How it works](how it works) — one message from arrival to approval. [Connections](connections) — what Taskuary may read, and what it may do with it. [Reports and the Advisor](reports) — before you build your first report. The live API reference is at /api/docs while Taskuary is running.","body":true},{"t":"","c":"How it works","u":"./how-it-works","x":"Taskuary's whole behaviour is one loop: something arrives, it gets a verdict, the verdict decides who does the work, and whatever comes out waits for you. This page follows one message the whole way, then explains the machinery underneath it. The Timeline The Timeline is the front door: every connection with a trigger or feed role lands here, in the order things happened. An email from a vendor, a pull request, a Teams message, this morning's spend report and a failed nightly export are one list. Each row shows where it came from above its original time, so mail, chat, GitHub, a SQL report and an Advisor post are told apart at a glance. Calendar entries show the meeting time. Open a row for the full message, its attachments, what triage decided and why, any drafted reply, and the actions available on it. Beside the Timeline, the work rail holds what is actually waiting on you, under Urgent, On you, Goals, Agents working, For later, Reports, Advisor ideas and FYI. A thread or a step gone quiet past that person's usual day is slipped , inside On you, with Chase, Let it go, They answered elsewhere and Remind me under it (see [The Advisor](advisor what was not followed up)). A finished or closed item gets no row: the rail is what still wants something from you, never a history. See [The work rail](tasks and agents the work rail) for what puts a row there and what takes it off. The five roads a message can take Every message gets exactly one verdict, and there are only five places it can go. Road What it means What happens fyi nothing to do filed; it stays readable and nothing is created reply a sentence settles it a draft goes to the task for you to approve coding an agent at a keyboard a CLI session starts in the checkout it picks general worth thinking about a conversation opens on the task; no system is touched task yours to do it lands on your list and nothing works it Three of those — coding , general , task — are kinds stored on the task, and the kind is what routes the work. reply is a kind too. fyi creates nothing at all. Only coding is ever dispatched automatically. A conversation you did not ask for is noise, and a task is yours by definition, so both land on the Board and wait for your click. :::note What \"general\" means It means the assistant's conversation: there is nothing to type at a system, but thinking, reading or research would help — weigh an option, make sense of a thread, work out what to ask. Work a person genuinely has to do in the world (sit a course, sign a form, attend, decide) is the task road instead. ::: What triage actually decides The verdict is the last thing that happens, not the first. Eleven checks run in a fixed order, and only two of them ask a model anything. A gate is deterministic: same input, same answer, no AI call, no cost. Knowing which is which is how you tell \"triage got this wrong\" from \"a rule caught it before triage ever saw it\". Step Gate or AI What it does 1 Dedupe gate A message whose id is already stored is dropped. Nothing below runs. 2 Feed connections gate A connection marked feed lands on the Timeline and stops — no verdict, no AI call, no task. 3 Policy rules gate Your rules, plus whether the sender is known. skip and ignore end it here. 4 Deferral gate Deferred triage lands the message as triaging so the Timeline shows it at once; the rest runs later. 5 Chat opener gate \"hi\", \"you there?\" — filed to wait for the ask it opens, so a greeting never becomes a task. 6 Threading gate (scored) Similarity against open tasks picks attach or create ; then a thread that is not yours is refused. 7 Still the same ask? AI Chats only, and only when step 6 attached: does this line continue that task or start a new one? 8 Your standing ruling gate If you already ruled on this conversation it is filed, quoting your own words. Your rulings outrank the classifier. 9 An agent is waiting gate If a run is live on the attached task, no verdict is asked for — the message goes to the agent as its answer. 10 The verdict gate, then AI Tracker items, obvious noise and calendar invites settle with no call. Everything else is one call reading TRIAGE.md , SOUL.md , JOB.md , LEARNED.md and your past verdicts. 11 Acting on it gate fyi files. A reply files instead of drafting when replies are off for that channel. Anything else becomes a task with its kind. Two rules hold wherever AI is involved. With no AI connector, a message is filed with \"awaiting AI triage\" rather than guessed at. A call that fails, or answers something unreadable, is filed too — never assumed to be work. Triage breaking is quiet and safe, not destructive. So a message that never reached the classifier was stopped by steps 1–6 or 8–9, and the fix is a rule, a feed or a ruling. A message the classifier did judge and got wrong is corrected on the Triage tab. Nothing sends itself Review is the outbound decision queue, and it is the only road out. A drafted reply sits there with the original request beside it; you edit the wording or the recipients, then Approve & send returns it through the channel the conversation started on. You can also ask for a redraft, reject it, or decide no reply is needed. The same gate covers more than mail: a GitHub comment, an invoice, a bill posted to your finance system and a file written to a share are all proposals until you approve them. A connector card ships at a read only authority, and raising it is a deliberate act. :::rule One way to finish A task ends with Mark done — on the task page, on the Assistant's card, or by saying \"done\" in the chat. Sending the reply marks it done too, unless an agent is still working on it or a new message arrived meanwhile. An agent that says it is finished closes its own task, and that result stays on your work rail until you have read it. See [Tasks and agents](tasks and agents who is allowed to close it). ::: Correcting it teaches it The roads on the Triage tab are not decoration. Correcting a verdict writes the reason into TRIAGE.md , the document the classifier reads on the next message — so the correction applies to the next message like this one, rather than becoming a rule about this one sender. Every verdict is evidence. Editing a draft teaches voice; rejecting one teaches what should not be drafted; Not our task teaches where your responsibility ends. The exact decision is kept with its date, sender and subject, so future triage can judge whether a new message is genuinely similar. Repeated patterns become lessons in LEARNED.md . Each machine written line carries its evidence: s is strength. A hypothesis starts at 2 and is promoted at 4 or more, supported by at least three episodes across two people or threads. Contradictions weaken it; stale hypotheses decay. ev names the verdicts that taught it, so you can go and read them. seen is the last date on which it held. Delete a learned line and it is gone. Lines you write yourself carry no machine tag and are never rewritten. An inferred rule that would hide work waits in Proposed rules until you adopt it. SOUL.md always outranks LEARNED.md , and one setting switches the whole loop off. Three brains, one voice Three always on models do the thinking, and you talk to one voice. They are split by what each is allowed to read and to do, not by where they run. What it does What it reads When Acts? Triage Judges each arrival: task, goal, reply, FYI or ignored. Attaches it to the thread's task, names the profile, playbook and repository, assigns the worker TRIAGE.md ; the first 2,500 characters of SOUL.md and of JOB.md ; LEARNED.md 's promoted lines; routing memory; the playbook menu; the recent open tasks every poll makes rows; never sends The assistant The voice and the hands: walks the rail, runs set up, connects things, moves things (assign, route, close, later) through a button or by asking the model for the verb COUNSEL.md , SOUL.md and JOB.md whole; the one item on the table on a turn moves things; never does the work, never proposes The Advisor The brain on the clock: the Advisor report, the morning brief and reflection say what is late, what was not followed up, what worked, which system is worth connecting the head of SOUL.md and JOB.md , COUNSEL.md ; your work as the hub sees it; the calendar; the knowledge base; the sources it watches; its own notes. At reflection: LEARNED.md whole, hypotheses too, and the outcome ledger on its schedule and when the app opens; reflection at launch and after three corrections; and on the event an agent stop or ask, a reply, an attached mail, a PR, a close, a missed day, a report one small prompt that leaves a line and a pill on that item never; it leaves a line, an idea row or a proposal The workers (the coding agent, the general agent) are the fourth kind and not always on: they do the work a task names, in a session you can watch. COUNSEL.md is the voice for the assistant and the Advisor both. The split is a budget: the heavy reader works off the request path, on the clock; the voice that answers on a turn reads the one item on the table, and never recomputes what the Advisor computed. The outcome ledger is the Advisor's newest input. Every other store is written at the moment you click: the documents say what they say, LEARNED.md is what you do when you correct, and the verdict and routing memories stop at the verdict. Nothing recorded what you did next, or what the world did after Taskuary acted. The ledger does: one row per action the app took or proposed a reply sent, a task closed, an agent stopping and your next move in your own words, a pull request merged, a promise made, a sender ignored and a once a day sweep fills in what came of it from facts already in the store: did more mail arrive on the thread, did the task reopen, did the person deliver and when, did the ignored sender's mail become work anyway. No model runs in the sweep. What the facts mean is reflection's: it reads the resolved rows as evidence ( out ids, beside the mem , rv and task ids above) and writes habits into LEARNED.md with the same grammar and the same decay \"green PR from the coder: you merge it, 8 of 8\". A derived line never acts on its own: it changes which button comes first and what a proposal says, and deleting it from LEARNED.md is the whole undo. The whole of it every input, the two clocks, the ledger's row kinds and verdicts is on [The Advisor](advisor). The documents that govern it Taskuary's behaviour is plain Markdown under Settings → Docs . These are not configuration files around the edges — they are what the models are actually told. ![The eight operator documents and who reads them: TRIAGE, STYLE and JOB can be generated from three months of your mail; SOUL, CODER and COUNSEL you write; LEARNED and DIGEST write themselves](img/operator docs.svg \"Three are read out of your mailbox, three you write, two write themselves.\") Document Purpose Read by SOUL.md The constitution: rules, voice, escalation lines, repository map triage, replies, the assistant JOB.md What your job is: mission, responsibilities, who you serve, the cadences, what to protect. It weighs importance, never intent triage, the assistant, the morning brief TRIAGE.md What makes something a task, a reply or an FYI triage STYLE.md Greeting, tone, length, phrasing reply drafts COUNSEL.md How the assistant speaks, and how readily it takes a position the assistant, the morning brief, replies CODER.md How coding agents work and close out coding agents LEARNED.md The profile learned from your verdicts; always below SOUL.md triage, replies, coding agents DIGEST.md The current morning brief you Playbooks One page per kind of job: when it starts, which connections it uses, the steps, what an agent may do alone, what counts as done triage's when line, and the agent working it Playbooks are the ones that grow. CODER.md is the playbook for code; every other kind of job — a card charge to post as a bill, a new hire to set up — gets its own page the first time an agent does ","body":true},{"t":"","c":"Connections","u":"./connections","x":"A connection is one account Taskuary may read — a mailbox, a chat, a repository, a tracker, a database, a bank feed. Each card on the Connections page is one named connection, and its roles decide what Taskuary is allowed to do with what it finds there. Nothing is polled without an enabled role. A card with no role is a saved credential and nothing more. A card's settings its roles, what each repository or source does, processing, the agent's prompts wait for its Save bar, which lists every change before it is kept; Discard puts them back. Leaving the card with changes unsaved asks first. Test, sign in and a new credential still act at once. What a connection is One card is one account, not one kind of system. Rename it for the account or environment it represents — Ops mailbox rather than IMAP — and use Add another on the card to connect the same kind again. Two mailboxes, two GitHub organisations, or separate production and staging databases are all normal, and each keeps its own roles, its own schedule and its own name in every prompt. Secrets are write only in the interface: you can replace a password, never read one back. A database connection string may contain {password} so the saved password stays separate from the readable part of the configuration. The five roles A role is a permission, not a ranking. Role What Taskuary may do trigger Send inbound items through triage — they can become tasks, drafts or FYIs feed Show inbound items on the Timeline, unread by any AI report Make the source available to scheduled reports tool Let agents query it while working a task :::rule Feed is not a quieter trigger feed means no model ever reads those items — cheaper, quieter, and no verdict to argue with. ignore is a judgement about a message and happens further down, in your routing policies. If a source is noisy but you still want to see it, make it a feed. ::: A card can hold more than one role. A mailbox is usually trigger and tool ; a database is usually report and tool . Mail System Notes Outlook Mail and calendar, through Microsoft sign in or a tenant app registration Gmail and IMAP Any IMAP mailbox. Approved replies go back through the provider's SMTP, in thread Taskuary reads your Sent folder as well as your inbox. That is what makes \"has this been answered?\" a real question rather than a guess, and it is what STYLE.md 's Generate from history learns your writing voice from. :::note A shared mailbox needs saying so If the mailbox is shared, mail addressed to the team reads as mail addressed to you unless Taskuary knows otherwise. Name your own addresses in SOUL.md so triage can tell \"someone asked me\" from \"someone asked the team\". ::: Chat System Notes Teams , Slack Messages enter the Timeline through triage Telegram Bot based inbound, approved in chat replies, the Assistant walk on your phone; each chat is opt in WhatsApp A local bridge for inbound messages, approved replies and the Assistant walk on your phone. Unofficial protocol — use a number you can afford to lose Discord Watches selected bot channels and posts approved replies back into the originating channel Apple Messages macOS only. Reads the Mac's local Messages history and replies through Messages.app; needs Full Disk Access and Automation permissions Mattermost , Rocket.Chat A server you host. Each watched channel is its own source, and approved replies post back into it. Rocket.Chat needs two values — the token and the user id issued beside it Matrix Any homeserver, matrix.org or your own. Replies go back as your account rather than a bot, so the account has to have joined the room Google Chat Spaces on the Timeline and replies back into them. Reuses the Gmail card's OAuth client, so there is one registration in Google Cloud rather than two Chat is different from mail in one way that matters: a chat message often has no clock on it. \"Can you look at this when you get a chance\" is a real ask with no deadline, and Taskuary keeps those as their own kind of item rather than inventing urgency for them. A greeting on its own is held until the ask it opens arrives. Repositories and trackers System Notes GitHub Repository discovery, issues and pull requests as triggers, task specific standing prompts GitLab Assigned issues and merge requests, GitLab.com or self hosted Azure DevOps Work items assigned to the connected user, through WIQL @Me Jira, Asana, Monday.com, ClickUp, Todoist Assigned work items enter the Timeline through triage Linear, Trello Assigned issues and cards Notion Pages shared with the integration appear as a feed when they change Sentry, PagerDuty New unresolved errors and open incidents join the same funnel A tracker is the clearest case for trigger : an issue assigned to you is, by definition, work addressed to you, and triage settles most of them without an AI call at all. GitHub: what Close out does The GitHub connection has a Close out step: what finishing a task does on GitHub when you press Close out . These are your choices what each repository requires (branch protection, required checks and reviews) is read from GitHub for every pull request, and the card only offers what it allows. Setting Choices (default first) The token needs Close out on a pull request Merges it · Only closes the task Contents: write Merge method Squash · Merge commit · Rebase used when the repository allows it (same) Red checks the repository does not require Merge anyway, with a note · Stop and ask me Offer Update branch on when the pull request is behind and its author allows maintainer edits Pull requests: write Offer Re run checks on re runs the failed Actions jobs Actions: write Close out on an issue closes it on Issues: write Post your reply as the close out's comment on even with Reply to issue/PR authors off Issues / Pull requests: write Close out anyway, past the repository's own rules off admin tokens only, and only on your press Administration A repository you follow can override the pull request choice, the merge method and Close out anyway. Check the token asks GitHub, per repository, whether the token may do what these settings turn on. Data and report sources The full list is long and grows; these are the ones worth knowing about by shape. Databases and files — SQL Server, SQLite, SharePoint Lists, Google Sheets, a Windows/SMB share, SFTP, REST and RSS, and any MCP server tool. PostgreSQL , MySQL , ClickHouse , Snowflake and BigQuery each have their own card: the same executor with the dialect filled in, the default port known and the missing driver named in the error you actually get. The older Any database (connection string) card is still there for anything else with a SQLAlchemy URL, including raw ODBC through pyodbc. All of them are reads — these cards ship no write verb at all, and the engine's own user is the ceiling, so point them at a read only account. Cloud and monitoring — AWS (S3 buckets, CloudWatch log groups, arbitrary service calls), Azure (blob containers, Log Analytics, arbitrary ARM paths, and it can reuse the Outlook app registration), Microsoft Entra ID, Prometheus, Datadog, WinRM for PowerShell on a remote Windows machine. Finance — Sage Intacct, QuickBooks Online, Zoho Invoice, and bank and card feeds through SimpleFIN or Teller. These are the cards where the read/write distinction bites: each ships at read , so an agent proposes a bill or an invoice and you approve it on the task. Raising a card to write is what lets a routing policy pass small, known items through without you. Markets — Yahoo Finance, CoinGecko, Alchemy, ECB reference rates, SEC EDGAR filings, and a strategy screen that filters another card's rows. With a key: Twelve Data (quotes and computed indicators across stocks, FX and crypto), Alpha Vantage (slow limits, no card, no expiry), Finnhub (quotes plus company news, earnings dates and insider transactions), Polygon.io (bars and full market snapshots), Tiingo (properly adjusted end of day history), Financial Modeling Prep (fundamentals and ratios rather than prices) and Alpaca (a broker's own feed — read only; this card has no order executor at all). FRED needs no key or account whatsoever and is the one a fresh install can use immediately. Which to pick is a question of what you are watching, not of which is best: Finnhub if you follow companies, Tiingo or Polygon if you follow prices, FMP if you follow balance sheets, FRED if you follow the economy. The web — search it or read one page of it, each a single REST call with a key. Exa and Tavily read the web for an agent (Tavily can hand back a written answer with its sources beside it); Brave Search answers from its own index; SerpApi and Serper give back a search engine's page as it was ranked, which matters when the ORDER is the finding. To read one page: Jina Reader (no account at all), Firecrawl (clean markdown), ScrapingBee (for a page that fights back) and Apify (when the crawl is one somebody already wrote). They overlap on purpose — the bill and the terms differ far more than the results do. What is deliberately NOT here is anything that DRIVES a browser — logging in, clicking, filling a form. That runs over CDP through a real browser session and cannot be reached from an API, so a card promising it would be a card that never works. Social — LinkedIn , Bluesky and Mastodon . Nothing from these reaches the Timeline as work: a public timeline is not an inbox, so they are report sources and tools rather than triggers. Like every connection they start at full authority, so an agent can post. A public post cannot be recalled: set the card to read and a post an agent drafts becomes a proposal you approve on the task. Agent tools — treg puts thousands of endpoints across many providers behind one key, billed per call. Searching its catalogue is free and commits nothing, so an agent may do it unattended; calling an endpoint spends real money and can reach services that publish or order. The card starts at full authority like every connection; set it to read and every call becomes a proposal. Your own documents — the Knowledge base card indexes SharePoint library folders and folders on this machine (docx, pptx, xlsx, html, text, and pdf with pypdf ) into Taskuary's own SQLite. Once anything is indexed, a kb_search report answers questions from it on a schedule, agents call the same search as a tool, and the reply drafter, the assistant and coding sessions are handed the passages that bear on a thread. Passages are treated as facts to cite, never as instructions. :::warn Planned is not available The Connections page lists cards that are on the roadmap as well as ones that work — NetSuite, SAP, Workday, ADP, Epic, Cerner, PointClickCare among them. A planned card tells you so on its face. If the assistant suggests connecting one, saying yes is a vote for building it, not a connection. (This callout used to name \"a long tail of market data providers\" here. Eight of them were built and the sentence was not updated, so the docs called working cards planned — the market cards above all work.) ::: Coding CLIs and AI providers AI providers — Anthropic, OpenAI, Azure OpenAI, OpenRouter, Ollama (and any OpenAI compatible local server: LM Studio, llama.cpp, vLLM), and the Meta Model API. Coding CLIs — Claude Code, Codex, Qwen Code, OpenCode, Kimi Code, Gemini, Cursor, Copilot, Muse Code and Devin, plus any CLI that accepts a prompt on stdin. The connector defines its command, arguments, model argument and working directory behaviour. Two practical notes. A headless agent needs its noninteractive or auto approval flag, or it will hang waiting for a click that cannot happen — the presets set this for you. And the card's Test action runs a small prompt through the CLI before it ever receives real work, which is the fastest way to find out that a sign in expired. Every CLI card has a light model as well as a main one. Naming the same CLI as both your coder and your triage brain is normal and cheap, and it is the light ","body":true},{"t":"","c":"Tasks and agents","u":"./tasks-and-agents","x":"A task in Taskuary is three records, not one: the durable job, the agent work done on it, and how it is closed out the reply to whoever asked, and on GitHub the merge or the closed issue. They start and finish independently, and keeping them apart is what stops the word \"done\" meaning three different things. A task's three lives The task page shows them as one numbered workflow — 1 Task → 2 Agent work → 3 Close out — and each stage owns exactly one state badge. Part What it records Main controls What it never does by itself Task The durable job and who owns it owner, kind, priority, Reopen, Mark done Starting or ending an agent session does not complete it Agent work One or more attempts by a coding or non coding agent, plus the saved result harness, model, start, save and end session Ending a session does not mark the task done or send a reply Close out The reply to the person who asked, and the last act where the task lives (merge its pull request, close its issue) write, generate, edit; Close out , Decline , Not yet Sending it marks the task done — unless an agent is still working, a new message came in, or its merge still waits While a terminal or an assistant chat is live, the task collapses to a one line context strip and the workspace takes most of the page. Full controls, saved results and restart choices come back when the agent stops. Who is allowed to close it ![Every way a task ends: you press Mark done, send the reply, tick the last box, hand it to a person or say Not ours; or an agent says it is done or its pull request merges](img/how a task ends.svg \"Every road ends in Mark done, or says why the task stays open.\") There is one close, Mark done , and every road below leads to it. Mark done always does the same five things: the task is done, any unsent draft is kept but retired, a live agent is stopped, it leaves your work rail, and the \"yours to end\" mark comes off. You or an agent does What happens Stays open when Mark done — the task page, the Assistant's button or card, \"done\" or \"close\" in the chat, the phone Mark done never Close out with a reply Sends it, then Mark done an agent is still working on it, or a new message came in while you were answering — it says why Tick the last checklist box Mark done an agent is still working on it Hand it to a person Forwards it, then Mark done never Not ours / Not a task Deleted if nothing was done on it, otherwise Mark done never Mark done on a channel that cannot send (the draft stays unsent) Mark done never An agent says it is finished ( taskuary done ) The session is written up; the task waits for you with its close out (below) and the draft if a reply is owed, otherwise it is done its close out or a reply waits on you, or you opened the session yourself Close out on GitHub, or Decline Merges or closes the pull request, or closes the issue, posts your reply, then Mark done never The pull request or issue it came from is merged or closed Same as an agent saying it is finished, with nothing owed never A task an agent or a merged pull request closed stays on your work rail until you have read it. The close out: what finishes it where it lives Mail is finished by the reply. A pull request is finished by merging it, and an issue by closing it. Whatever the system, the card has the same three buttons only the line under them says what they do there: Button What it does Close out Finishes the task the normal way for its system, sends your reply with it, then Mark done Decline Closes it without doing it, where the system has that difference a pull request closed unmerged Not yet Nothing happens; the task stays open and on you (in the Assistant's walk this is Next ) The task's work is The rail says What Close out does there A pull request the agent opened, or the one the task came from ✉️ ready to close out Merges it the way you set on the GitHub connection (a draft is marked ready first), then posts your reply as its comment. The card reads the pull request from GitHub first: when the repository's rules say it cannot merge yet it says why and offers what fits Update branch , Re run checks , or Close out anyway where you allowed it An issue the task came from ✉️ ready to close out Posts your reply as the closing comment and closes the issue Mail, chat, anything else ✉️ ready to close out Sends your reply If the act is refused, nothing is sent. Merging or closing the pull request on GitHub yourself counts as answering it: the task closes by itself. The buttons are yours, so Agents may push / deploy does not have to be on that switch is about what an agent may do. A task an agent finished before this existed gets its card on the next sync. A session you started yourself is yours to complete: the agent is told so, and if it says it is finished anyway its sentence is filed on the task and the task stays open until you mark it done. These never end a task: You do What happens instead Save and end session The agent stops and its report is written; the task stays open Reject a draft The draft is rejected; the task is untouched Next Read and moved on; open work comes back after a few hours Remind me Put away until the day you pick, then back on your rail that morning A stopped or quiet session Nothing — only you, or the agent saying so, ends a task Reopening a completed task starts a fresh task lifecycle rather than pretending an old terminal is still alive. Sending work to a coding agent Open Agent work , choose the CLI and model, and start. The session is handed the task summary, the incoming messages, the attachments, any saved result from an earlier run and your optional new prompt — plus a context file under ~/.taskuary/context/ holding the thread, relevant sender and topic history, the learned profile, and reports from related closed tasks. Control What it does Start coding session Starts the selected harness and model Start new coding session Picks a different harness after an earlier run stopped or hit a limit; the checkout and history are kept Save and end session Ends the session and writes its result; the task stays open until you mark it done Mark done is stronger than all of them: it closes the task and ends any live session, because a finished task should not leave an orphan process running. What an agent is doing An agent is always in one of six states. Each has one word and one mark, and the work rail, the Timeline, the task page, the Board, the assistant's cards and the phone all use the same ones. Mark State What it means Your move ⏳ waiting to start Handed to an agent, not running yet Start now ⚙️ agent working Running, and needs nothing from you Leave a note for when it stops 👋 agent waiting on you Running, and it asked you something, needs your approval, or is stuck Answer it 💾 session saved You ended it with Save and end session ; its report is written Continue session , or Mark done ⏹ agent stopped It ended without finishing: a crash, a closed pane, Taskuary closing Continue session , or hand it on ✅ agent finished The agent closed the task, or the item it came from was merged or closed Read the result ![How an agent starts: handed off, auto start allowed or not, a free slot or next in line](img/agent start.svg \"Waiting to start always says why.\") ![While it runs: working, or waiting on you a question, an approval, stuck on a limit, quiet at its prompt](img/agent run.svg \"Your answer puts it back to work.\") ![How it ends: agent finished, session saved, the task closed, or agent stopped and Continue session](img/agent end.svg \"Only a session that ended by itself reads as stopped.\") It ended because What you see What brings it back The agent said it was done its Close out card if its work lives on GitHub, then ✅ agent finished ready to close out if a reply is owed a new message on it You pressed Save and end session 💾 session saved the report is written, the task stays open Continue session You pressed Mark done the task is closed and the agent stopped they write again The session crashed or was closed, or Taskuary closed ⏹ agent stopped a reply it had held is back for your yes Continue session , or Run another agent Continue session works for a coding agent (it reopens its own CLI session, or a fresh one seeded with the handover) and a regular agent (its saved conversation). It asks what to tell it as it picks up optional; on the phone the next thing you type is the note, or tap Continue as is . The saved result is deliberately short. Every finished coding session also writes a full Markdown artifact with that result and the complete transcript — Work details → Full artifact on the task page. When the agent opens a browser With the optional agent browser tool installed, the page the agent is on appears live beside the terminal. Take over hands you the mouse and keyboard for a password or a 2FA code the agent must never type; Snapshot keeps the frame on the task as an attachment. On the Wall, a narrow tile shows a \"browser\" chip that opens the page over the session. The general agent Not every job is code. A general task opens a conversation instead of a terminal: research, planning, writing, weighing an option, working out what to ask. No system is touched. You reach it from Talk it through on a Timeline row, from ＋ New → Give an agent a job → Just talk it through , or from Prepare me for it on a calendar invite. General chats save their provider, model and native conversation id across restarts. Claude and Codex resume that exact conversation when it still exists and the provider configuration matches; otherwise the assistant continues from Taskuary's own saved history and says so. Sessions and transcripts Continue previous work on the Assistant page lists unfinished tasks that have saved agent work, each with an excerpt of the latest reply or handover. Resume opens the task and carries on; Review draft opens a pending result. Loading the page starts nothing, and a session already running is opened rather than duplicated. Reopening a pane seeds it from a render of the session, not from raw bytes, so a pane you come back to shows what the screen actually looked like. Several agents in one repository Taskuary can run more than one coding session against a shared checkout, and spends real effort on not letting them collide: Affinity routing asks whether a queued task is likely to touch the same files as a running one. Likely overlap waits, and starts by itself when the first session ends. Tell the agent queues your notes until the CLI is back at its prompt, so a note never lands mid turn or on top of a question waiting for you. Lists drip in one item per stop; pasted screenshots are saved locally and named in the note. The blackboard shows what each session has actually modified, computed from Git and the run trace rather than from what the agent said it would do. A new agent is handed that picture at startup. First in has control. The newcomer is told which files belong to another session and must not edit, revert, stash or commit them. Live handoffs on the Board shows what each agent is working on, what is blocked and what is ready for someone else, with read markers for which agents have seen each note. The Hub is the longer lived version of the same idea: discoveries and decisions by topic, so knowledge outlives the job that produced it. Checklists and closing A task can carry a checklist. Tick the boxes as you go, then press Mark done — ticking the last box does not close the task on its own. Closing a task ticks every remaining box: a closed task with open items is a lie about its own state. Replies The Reply section exists whenever the task has an incoming sender. It shows one of three things: no draft yet, a draft ready, or a reply sent. Open on the task is the only road out — type your own or generate one, edit it, approve it. One reply is special. A clarification stops the active agent when it is sent and moves the task to waiting, because an external answer is now required. An ordinary reply","body":true},{"t":"","c":"Assistant buttons","u":"./assistant","x":"The Assistant walks you through what is waiting: one item at a time, with a few buttons under it. There are eight buttons in all. Anything without a button still works when you ask for it in your own words, in the app or on your phone. One screen: the sidebar and the canvas Taskuary is one screen. The sidebar on the left is your work rail; the canvas on the right is the conversation, and whatever part of the app is in use opens inside it. Where What is there Top of the sidebar New (a task, a report or a workflow), then Reports , Connections , Hub and Settings Under the buttons Work \\ Timeline which rows the rail shows and the filter, then the day's count and Sync now The rail On you , Agents working , For later , Reports , Advisor ideas , FYI click a heading to walk that section The canvas The item on the table: a task opens as its full task view Task, Agent work, Close out with Next under it The top bar Board every agent and its session, full screen and back to the Assistant Reports, Connections, Hub and Settings are browsed in the canvas , by clicks: a button shows that part's sections, a section shows its cards, and a card opens with its own controls Back returns to the list. Ask the Assistant about the card that is open (\"why is this failing?\", \"turn this on\") and it knows which one you mean. An agent's session opens inside the task view, nearly the full height of the canvas; Expand gives it all of it. On a phone the task view is the screen, and Expand takes the session full screen with a back arrow to the chat. The buttons on each card ![Which buttons each kind of card shows](img/assistant buttons.svg \"Next is on every card. Nothing else is offered unless that card can actually do it.\") Button Shown on What it does Runs Next every card Marks it read and moves on. Open work you pass comes back after a few hours (Settings → Passed work comes back after) at once Mark done a draft reply, a finished agent, a task The one close: the task is done, an unsent draft is retired, a live agent is stopped, and it leaves your rail at once Close out a draft reply, a task's close out (a pull request to merge, an issue to close) Finishes the task the normal way for where it lives, then Mark done: sends the draft; on GitHub merges the pull request or closes the issue and posts the reply as its comment. The line under the card says which you confirm Run it an agent's proposal Runs the action the agent proposed you confirm Reply a person's ask, a finished agent with no draft Writes a draft reply. Nothing is sent at once Make a task an ask, an fyi, an idea A task on your own list. No agent starts you confirm Send to agent an ask, an fyi, an idea, a meeting, a report A task and an agent on it. The card asks which agent you confirm Not ours a draft reply, a proposal (not a close out), an ask, an fyi Files it. The card asks how far you confirm Send back to the agent a draft reply on a task (under More actions); a close out GitHub refuses for merge conflicts (the main button) Picks the task's own agent back up with your note or, on a conflict, GitHub's reason as the first thing it hears. The card comes back when it stops at once Save and end session an agent waiting on you Writes up what the session did and stops the agent. The task stays open at once Remind me any card with an open task behind it Asks for a day, then puts the task away until that morning: under For later on your rail, with its day. On the phone the days come as choices you pick the day A handful of fyi comes as one card with its own All read, next button. A close out card for a pull request also shows Decline (close it without merging) on the card only, never as a chat word or a phone choice and no separate Reject: the reply on it is edited or redrafted in place. The two buttons that ask one question ![Not ours asks how far; Send to agent asks which agent](img/assistant questions.svg \"The card asks; nothing runs until you confirm.\") Button Answer What happens Not ours Just this once This message is filed. Its task is deleted if nothing was done on it, otherwise marked done From now on Triage learns to file everything from this sender. Their mail still arrives and stays readable A rule in Settings An exclusion rule: their mail never reaches triage, and what already arrived leaves the Timeline. Reversible Send to agent A coding agent A task and a coding agent in a repository. The card asks which repository when it is not clear A non coding agent A task and an agent for reading, checking, drafting or research Send to agent starts on the agent triage would pick; the other is one click away on the card. Pictures, and your voice Paste a screenshot, drop an image, or use the paperclip in the chat line, in New , and in Continue session . It goes with your words: the Assistant looks at the picture itself, and a coding agent is handed the file to open. PNG, JPEG, GIF and WebP, up to eight at a time. The microphone beside each box dictates into it. Continue session opens as a card under the item, not a popup: type or say what to tell the agent as it picks up, add a picture, or continue as is. Moving on with Next puts the card away with the item. Remind me Every open task has Remind me on its page: tomorrow, next week, in 2 weeks, in a month, or any day from the calendar. Until that day the task waits under For later on your rail, saying when it comes back. That morning a note goes on the task and it is back under On you , however long ago it arrived. Ask the Assistant the same thing — \"bring TQ 0123 back in two weeks\" — and it does it at once, with an undo. Everything the task page can do Anything you can do on a task's page, you can ask the Assistant to do — about the task in front of you, or any task you name (TQ 0123). It shows you a card first, like every other action. It never guesses which task you mean. ![What you can ask about a task, and what each does](img/assistant task tools.svg \"One tool per action on the task page.\") Say, about a task What happens \"make this urgent\", \"rename it\", \"I'll take it\" Priority, title or owner changed \"this is a general job, not coding\" What kind of work it is changes, and a live session is closed if it no longer fits \"this belongs in the ledger repo\" The task moves to that repository \"tick off the first item\" That checklist box is ticked — the last box is Mark done \"add a note that Erin wants it by Friday\" A note on the task \"forward it to Erin\" A hand off is written for your yes — nothing is sent until you approve it \"ask the sender which date range they need\" The question is written for your yes \"start the coding agent on TQ 0123\" An agent starts on that task; it asks which repository when it is not clear \"continue the agent where it left off\" The agent's own last session picks up again \"stop the agent on TQ 0123\" Save and end session on that task's agent \"split this in two\" / \"it's the same job as TQ 0120\" Two tasks, or this one folded into the other \"this isn't a task\" Deleted, and triage learns it was not work \"it's done\" / \"reopen TQ 0123\" Mark done, or open again \"bring it back in two weeks\" Remind me — away until that morning \"send it\" / \"reject that draft\" / \"make it shorter\" The draft is sent, rejected, or written again Words that work typed These have no button. Say them, in the app or on your phone. Say What happens Runs \"reply and tell them…\" A draft with that gist, for your yes at once \"redraft it shorter\" The draft written again with the change at once \"yes, go ahead\" to a waiting agent Your answer goes to the agent you confirm \"run it again\" on a report The report runs again at once \"remember that…\" A fact kept in Settings → Verdicts & notes, used by triage and the Assistant you confirm \"clear all the fyi\" Clears that set from the walk, with the count on the card you confirm \"set up a report that…\" A walk through for a report, connection or workflow you confirm \"stop hiding auto replies\" The setting is changed, with an undo at once \"what's waiting on me?\" Looked up and answered — tasks, reports, mail, calendar, settings at once \"what's in For later?\" The rail read by its own sections On you, Agents working, For later (with when each comes back), Reports, FYI at once Later and Tomorrow are gone: Next is the \"not now\", and Remind me puts a task away until a day.","body":true},{"t":"","c":"What the Assistant sees","u":"./assistant-tools","x":"<! Written by python m taskuary.toolcatalog from taskuary/toolcatalog.py edit the catalogue, not this page. What the Assistant is told about its tools. It gets the summary on every turn: the buckets, and each tool's name and what it needs. It asks for the detail of a bucket ( tools.list ) or a tool ( tools.describe ) only when a turn needs it. Everything it can change becomes a card you confirm, except the few that can be undone, which run at once with an undo on the receipt. The summary, sent every turn Bucket What it is for Tools, and what each needs table decide about the item on the table reply(text), approve, redraft(text), mine, regular_agent(text, as?, new?), coder(text, as?, new?), not_ours, not_ours_sender, block_sender, not_ours_kind, close, done, next, answer_agent(text), stop_agent, rerun, remember(text), setup(text), confirm, cancel, chase, let_go, elsewhere task change any task the one on the table or one named with ref task.update(priority/title/assignee/due), task.set_kind(kind), task.set_repo(repo), task.check(item, done?), task.checklist(items?, emails?, drop?), task.watch(what?), task.comment(text), task.split(text), task.merge(into), task.reopen, task.not_a_task, task.complete, task.defer(until), task.handoff(who, note?), task.clarify(text), review.approve, review.reject agents start, continue, answer or stop the agent on a task, and teach where work belongs dispatch.prepare(kind, instructions?), agent.continue, agent.answer(text), agent.stop, routing.remember(field, value) new new work with no task yet task.create_from_text(kind, text), task.create_from_message(kind), task.setup(text) pipe the walk and sets of items, and filing mail pipe.clear, item.settle(verb), message.file, message.archive, preference.exclude_sender(scope), preference.sender_rule reports reports and workflows report.create(config), report.run, report.rerun, report.pause, report.resume, report.route(line, how), report.edit(config), report.delete app settings, connections, roles, scripts and kept facts setting.set(setting, value), connection.create(type, name), role.apply(role, portal?, route_mail?), connection.test, connection.pause, connection.resume, script.start(name), memory.remember(note), hub.publish(title, body, topic?, kind?, why_earned?) look look ups they run at once and change nothing task.read, timeline.search, tasks.list, asks.list, message.read, sender.read, docs.search, agents.now, approvals.list, pipe.list, calendar.read, activity.list, errors.list, memory.list, rules.list, missed.check, report.read, reports.list, settings.list, setting.read, connections.list, connection.read, agents.list, repos.list, tools.list, tools.describe, knowledge.search A task you name goes in ref (\"TQ 0123\"); otherwise the tool acts on what is on the table. Table Decide about the item on the table. reply Write a reply to the sender. Nothing is sent. text the gist, in the owner's words <p class=\"runs\" At once a draft, nothing sent.</p approve The owner's yes to what is drafted on the item: sends the reply as it stands on a task's close out (Close out) it merges the pull request or closes the issue FIRST, then sends the reply; on an agent's proposal it runs that action. It never continues an agent's session that is agent.continue. <p class=\"runs\" Waits for your yes on a card.</p redraft Write the draft again. text the change <p class=\"runs\" At once a draft, nothing sent.</p mine Make it a task on the owner's own list no agent. <p class=\"runs\" Waits for your yes on a card.</p regular_agent Send it to a non coding agent it becomes a task of its own. text the job as (optional) a profile from agents.list, only when one fits new (optional) true when the job is NOT about the item on the table <p class=\"runs\" Waits for your yes on a card.</p coder Send it to a coding agent. Not sure which repository is no reason to ask CALL it, and its card offers every repository to pick. text what is wanted as (optional) the repository (repos.list), only when sure new (optional) true when the job is NOT about the item on the table <p class=\"runs\" Waits for your yes on a card.</p not_ours File it, just this once its card asks whether from now on, or as a rule. <p class=\"runs\" Waits for your yes on a card.</p not_ours_sender File everything from this sender from now on their mail still arrives and stays readable. <p class=\"runs\" Waits for your yes on a card.</p block_sender An exclusion rule in Settings: the sender never reaches triage again only when they ask for a rule. <p class=\"runs\" Waits for your yes on a card.</p not_ours_kind An Advisor idea only: put it down AND no more ideas like it the Advisor's next run reads that. <p class=\"runs\" Waits for your yes on a card.</p close Mark done the task behind the item is finished. <p class=\"runs\" At once.</p done The owner handled it Mark done on a task; on an idea, a report or an fyi it is read and settled. <p class=\"runs\" At once.</p next Move on to the next thing. <p class=\"runs\" At once.</p answer_agent Answer the agent waiting on the owner. text <p class=\"runs\" Waits for your yes on a card.</p stop_agent Save and end the agent's session on the item. <p class=\"runs\" At once.</p rerun Run the report on the table again. <p class=\"runs\" Waits for your yes on a card.</p remember Keep a fact. text <p class=\"runs\" Waits for your yes on a card.</p setup Build a report, a connection to another system or an automation. Never a to do. text the request <p class=\"runs\" Waits for your yes on a card.</p confirm The owner's yes to the card already waiting only when one is. <p class=\"runs\" At once.</p cancel The owner's no to it. <p class=\"runs\" At once.</p chase Chase the person who has gone quiet on the item a short nudge in the owner's voice is drafted on the thread, copying whoever the ledger says moves them; nothing is sent. <p class=\"runs\" Waits for your yes on a card.</p let_go Let the quiet item go the step somebody owed is dropped, or the follow up is put down; three on one person and the Advisor stops raising them. <p class=\"runs\" Waits for your yes on a card.</p elsewhere They answered elsewhere; the step somebody owed closes as done, or the follow up is put down. text where (a call, a meeting) <p class=\"runs\" Waits for your yes on a card.</p Task Change any task the one on the table or one named with ref. task.update Change a task's priority, title, owner or due day. Any other value is refused with the allowed ones. priority low normal high urgent title assignee exactly owner (the owner takes it) or agent:<profile (a worker on the roster) due the day the work is due (2026 10 30, \"friday\", \"2 weeks\", or \"none\" to clear it) ref (optional) the task (TQ 0123), when it is not the one on the table <p class=\"runs\" Waits for your yes on a card.</p task.set_kind Say what kind of work a task is. kind task (the owner does it) general (a non coding agent) coding ref (optional) the task (TQ 0123), when it is not the one on the table <p class=\"runs\" Waits for your yes on a card.</p task.set_repo Put a coding task in the repository it belongs in. repo its name, as the repositories list says it ref (optional) the task (TQ 0123), when it is not the one on the table <p class=\"runs\" Waits for your yes on a card.</p task.check Tick a checklist item on a task. item its NUMBER (1 is the first; the facts list them numbered) done (optional) false un ticks ref (optional) the task (TQ 0123), when it is not the one on the table <p class=\"runs\" Waits for your yes on a card.</p task.checklist Change what a task's checklist asks for. items (optional) the full list of item words in order (one left out is removed, emails untouched) emails (optional) [{to, about}] to add emails that must go out before it closes drop (optional) recipients whose email is no longer owed ref (optional) the task (TQ 0123), when it is not the one on the table <p class=\"runs\" Waits for your yes on a card.</p task.watch Tell the owner here when something happens on a task nobody needs to start. what (optional) done (when it is finished) reply (when someone writes on it) any (the default) off ref (optional) the task (TQ 0123), when it is not the one on the table <p class=\"runs\" Runs at once, with an undo on the receipt.</p task.comment File a note on a task. text ref (optional) the task (TQ 0123), when it is not the one on the table <p class=\"runs\" Waits for your yes on a card.</p task.split Split one arrival into two jobs. text <p class=\"runs\" Waits for your yes on a card.</p task.merge Fold a task into the one it duplicates. into the survivor's ref (TQ 0123) ref (optional) the task that is the one folded away <p class=\"runs\" Waits for your yes on a card.</p task.reopen Reopen a task that was marked done. ref (optional) the task (TQ 0123), when it is not the one on the table <p class=\"runs\" Waits for your yes on a card.</p task.not_a_task Delete a task and teach triage it was never work. ref (optional) the task (TQ 0123), when it is not the one on the table <p class=\"runs\" Waits for your yes on a card.</p task.complete Mark done the task is finished (note: optional, what came of it kept on the task) <p class=\"runs\" Waits for your yes on a card.</p task.defer Remind me: put an open task away until a day and bring it back then. \"Remind me about <a task that exists \" named by ref, sender or subject is this, never a new to do. until a date (2026 10 09), \"2 weeks\", \"3 days\", \"monday\", with the time they said kept (\"tomorrow 9am\", \"friday 2pm\"), \"after_meetings\" when they mean once the day's meetings or calls are over (the calendar picks the time), or \"none\" to bring it back now ref (optional) the task (TQ 0123) when it is not the one on the table <p class=\"runs\" Runs at once, with an undo on the receipt.</p task.handoff Hand a task to a PERSON. who a name or address that has written here note (optional) writes the forward for the owner's yes, nothing is sent from this card ref (optional) the task (TQ 0123), when it is not the one on the table <p class=\"runs\" Waits for your yes on a card.</p task.clarify Prepare a question for the task's sender; it waits for the owner's yes, never sent from here. text the question ref (optional) the task (TQ 0123), when it is not the one on the table <p class=\"runs\" Waits for your yes on a card.</p review.approve The owner's yes to what is drafted: sends the reply as it stands and on a task's close out merges the pull request (or closes the issue) FIRST, sending the reply only if that worked. <p class=\"runs\" Waits for your yes on a card.</p review.reject Reject the draft reply waiting on a task nothing is sent, the task stays open. ref (optional) the task <p class=\"runs\" Waits for your yes on a card.</p Agents Start, continue, answer or stop the agent on a task, and teach where work belongs. dispatch.prepare Start an agent on an EXISTING task; a coding task asks which repository when it is not clear. kind coding general instructions (optional) ref the task (TQ 0123) always named, the one on the table included; a new job is task.create_from_text <p class=\"runs\" Waits for your yes on a card.</p agent.continue Pick up the agent's own last session on a task where it left off, coding or not. ref the task (TQ 0123) the one on the table when it has a saved session to reopen note when the owner said what to tell it as it picks up <p class=\"runs\" Waits for your yes on a card.</p agent.answer Answer the agent that is waiting. text ref (optional) its task when it is not the one on the table <p class=\"runs\" Waits for your yes on a card.</p agent.stop Save and end an agent's session the one on the table, or the task ref names; never a guess at which. ref (optional) the task (TQ 0123), when it is not the one on the table <p class=\"runs\" Waits for your yes on a card.</p routing.remember Remember how work like this should be ROUTED next time. kind: coding (an agent in a checkout) general (the assistant) task (the owner, no agent). system: where the work actually lives when no repository here can touch it, named ","body":true},{"t":"","c":"Reports and the Advisor","u":"./reports","x":"Reports are how Taskuary reads the systems you work in. The Advisor is a report with a different job: instead of filing what it read, it decides whether any of it is worth your attention. They share one builder, which is why they share one page here. A report is a pipeline One report is one saved configuration under Reports the sidebar's button, browsed in the canvas built in four steps. Step What it decides Pipeline The title, the sources it reads, and the one prompt that reads all of them Test & preview Test calls a single source; Preview runs the whole pipeline, AI pass included, filing nothing Where each run goes What makes it a task, then the route card: Timeline, alert and send, each every run, ask the AI, when a rule trips, or never Schedule & save How often it runs Sources at the top, one prompt at the bottom. Every source runs on its own connection and query, the results are stacked under labelled headers, and the prompt sees all of them at once. One source failing is named in the bell; the others are filed and sent as usual. :::rule Connections owns the credential, Reports owns the question You do not configure a connection here. A source names the connector card its credentials live on. That separation is why the same database can answer five different reports without five copies of its password. ::: Sources A source card carries a type, an optional label, whatever that type needs to run, and a row cap. The type picker is grouped by where the data lives: this computer, files and sheets, databases, AWS, Azure, Microsoft 365, monitoring, corporate systems, the AI itself, the web, and Taskuary's own data. Three things are worth knowing: label is how the prompt refers to that data. Two queries against the same database are two sources, and without labels the prompt cannot tell them apart. max rows is blank by default, and blank means 200 — a cap nobody chose. When a run is capped the headline says so, so the AI can never describe a truncated slice as complete. Test — show me the data returns the exact text a scheduled run would hand the prompt. Use it before assembling the rest of the pipeline. Drag cards to reorder them; duplicate one to ask the same connection a second question. Letting the AI write the source cards A source card asks you to know things first: which of thirty odd types your data sits behind, what that type's config keys are called, and the query language of whatever is on the other end. Nobody remembers that a GL entry's amount is AMOUNT but a bill's is TOTALENTERED . So you can describe what you want instead, in three places: Where What it writes Describe the report you want , top of Reports A whole report — type, query, prompt and schedule — dropped into the builder let AI fill this in , on any source card That one card, in the type it is already set to Describe what the Advisor should keep an eye on Every source the ask needs, plus the instruction to judge them by Four things keep this from being a wish machine: 1. It may only choose a type whose connection actually exists. The catalogue is built from this install's live connectors, so it cannot answer \"connect to Salesforce\" — only tell you that nothing here reaches Salesforce and what you would have to connect. 2. The config keys come from the executors' own docstrings , so a composed card cannot drift from the keys the code really reads. 3. It reads the real schema before writing a query — an object's field list, a table's columns, which LOCATIONID the site you named actually has. Up to three look ups per ask, each a real call whose result goes back to the model. 4. It is allowed to say it does not know. Questions come back as questions, at most three, each answerable in a few words. A guessed WHERE clause on a finance report is silently wrong forever; a question costs five seconds. Everything it writes is checked before you see it: a real type, a connected one, and the keys that type needs to run at all. Nothing is saved — a composed card lands in the boxes you would have filled in by hand, and Preview runs it for real so you look at actual rows before anything is scheduled. The AI pass The prompt at the bottom of the pipeline turns rows into prose. Leave it empty and the raw rows file as they are. Write a concrete instruction — \"Summarise spend by site; flag any vendor above 10k or new this month\" — not \"summarise the data\". Brain : the triage brain writes it by default; any connector with a saved key can be picked per report. A saved pick that has lost its key stays visible and disabled rather than silently vanishing. With a prompt set but no AI connector active, the raw data files and the builder says so. A summary that fails, or comes back empty, is a failed run the report exists for the summary. When one column is a measure worth plotting, the model that just read every row says so and the run hands back a bar chart beside the text. Where a run goes Every report has one route card: four lines, and each line is every run , ask the AI (a sentence the judge answers yes or no to), when a rule trips (a number or words no AI), or never . ![When a report runs: app start, its own clock, Run due now, or run by hand one run at a time, and a switched off connection fails the run](img/report runs.svg \"A manual run is extra: it never uses up the schedule.\") ![Where a run goes: a failure goes to the bell; otherwise triage reads it, and each line of the card answers every run, the AI, a rule, or never](img/report goes.svg \"No answer from the judge counts as yes.\") Line every run ask the AI when a rule trips never Timeline A row under Reports A row when the judge says your sentence holds A row when the rule trips No row: a task, or nothing Alert Reaches you right away on your channel, no Review When the judge says so When the rule trips Never Send Out to its people, through Review unless set to send without asking When the judge says so When the rule trips Never Rule Trips when anything came back at least one row, or the headline's number is above 0 nothing came back no rows fewer than N · more than N the headline's number rows, or the total a money report leads with it mentions · it never mentions the words, anywhere in the result Send it somewhere — email, Teams, Telegram, WhatsApp, iMessage or Discord. It waits on the task for approval by default. \"Send it without asking\" is the one place in Taskuary where that gate can be switched off, and it is deliberate. Triage reads every run that worked , against TRIAGE.md and the report's own Make it a task when… sentence. A task if it needs doing a bug found, a job that did not run and otherwise a row under Reports, as the Timeline line says. A failed run is in the bell, top right, and nowhere else: no row, never a task, never an alert, never sent to anyone. It clears itself when a run works again. A send or an alert that did not go is in the bell the same way, until the next one goes. A mute covers the alert and the morning brief as well as the rail. Who judges is one setting for every report, under Settings › Triage & agents › Where runs go; blank means the brain that writes the report. try it on the last 5 runs shows what the card would have done, without posting anything. Under each report row, the last run shows what it read, what came out, and the error when it failed. Schedules Pick one or more: every N minutes, daily at HH:MM , a five field cron, or on app start. No clock at all means the report runs only when you press Run now, and its row wears a red border that says so. A slot missed while the app was closed fires once on reopen. Reports have their own clock: turning the mail poll or the startup catch up off does not stop them. Button What it does Run due now Every report that is owed, and nothing else Run now on a row That report, now. It does not use up \"once a day\" or move the next slot A scheduled run that fails is tried again at its next scheduled time, never in between. A report runs one at a time; a second Run now while it runs is told so. :::note Once a day means once a day \"At most once a day\" caps the scheduled runs of the whole report. If the 08:00 slot has already produced today's run, opening the app at 09:00 does not produce a second one. ::: The Advisor The Advisor is a report of type assistant . It runs on its own schedule and when the app opens, and it posts on the Timeline only when it finds something worth saying: an unanswered reply, context for an upcoming meeting, a task gone quiet, a pattern across incoming work, or something in the systems it watches that does not look right. Each suggestion names its evidence and carries the same words everywhere it shows up the Timeline, the Assistant chat, the work rail and your phone. What it reads, its two clocks and the outcome ledger it learns from are on [The Advisor](advisor); this section is the report that runs it. Word What it does to the idea Make a task A task on your own list; no agent starts. If triage already opened one for it, that task is the answer never a second. Send to agent An agent takes it a coding or a non coding one, as its kind says. Remind me Put away until the day you pick; it comes back that morning. Not ours Put down: the Advisor does not raise it again, reworded or not only something new on that thread brings a follow up back. Next Move on; the idea stays as it is. Marking the row done on the rail puts the idea down as handled. An idea never reopens a task that is already done new work it notices becomes a new task, carrying what it saw. Its pipeline is itself, so its Pipeline step looks different from every other report: Systems and data views to check — source cards owned by this check alone. Anything a report can read belongs here, and no saved report needs to stand behind it: the Advisor pulls each one silently and files no intermediate report. …and pull these saved data views too — existing reports it should also read. A report can stay switched off as a standalone schedule and still be pulled here. What should the Advisor surface? — one instruction over all of the above plus its own view of your work. Every post records what it reviewed and leaves a note for its next check, so it does not research the same silence twice or repeat a suggestion you have seen or put down. Each Advisor report keeps its own ideas: one report's open idea never silences another's. Four things shape it: COUNSEL.md in Settings → Docs — how it speaks, and how readily it takes a position. The Advisor report — what it watches, its schedule, its model. Settings → Advisor — thresholds such as how long a reply or task must be quiet. Settings → Triage & routing → Learn from your verdicts — whether your verdicts feed back into LEARNED.md . The outcome ledger — what came of what Taskuary did: a reply that got more rounds, a close that reopened, a promise delivered late, your own next move after an agent stopped. Resolved once a day from the store's own facts; reflection reads it as evidence. See [Three brains, one voice](how it works three brains one voice). Delete the Advisor report to switch it off. Its Preview shows exactly what a run would hand the model, which is the fastest way to find out whether a watched source returns what you think it does. The morning brief is a separate report of type digest : it writes DIGEST.md and lands on the Timeline daily. Deleting that report turns the brief off. Ideas it raises Beyond what it watches, the Advisor looks at the shape of your own work and occasionally raises an idea : a system your mail keeps naming that nothing here reads, for instance at most one such system per run, and never one it has raised before. The app's own health (a report failing run after run, a connection erroring) is raised the same way, and counts toward the post's lines like everything else. Stateful workflows Monthly Zoho invoices is the first workflow on the Reports page that is not a query returning one result. One scheduled run opens a batch, the batch holds ","body":true},{"t":"","c":"The Advisor","u":"./advisor","x":"The Advisor is the one of Taskuary's three models that thinks about your work as a whole. Triage judges each arrival and the assistant moves things on a turn; the Advisor reads everything, on a clock, and says what should happen next: what is late, what nobody followed up, which step a mail served, what worked, which system is worth connecting. It never acts. It leaves a line, an idea row or a proposal, and you or the assistant do the rest. COUNSEL.md is its voice and the assistant's both. The operational side the report that runs it, its schedule, the five words under an idea is on [Reports and the Advisor](reports the advisor). This page is what goes into it, and what it learns from. What it reads What one run of the Advisor report hands the model, today: Input What it tells the Advisor SOUL.md and JOB.md , the head of each Who you are and what matters: it weighs a slipped thread by whom it serves, and never contradicts the constitution. The chat reads both whole; the report takes the opening of each COUNSEL.md How it speaks and how readily it takes a position Your work as the hub sees it The threads of the last two days with your own lines marked, what arrived, the open tasks and what closed this week, who is out of office from their auto replies The calendar Who you meet and when: context for a meeting, and a chase that should wait for the one on Thursday The knowledge base What agents have learned, by name, so it does not raise what is already known The sources it watches The systems and saved data views on its report card, pulled silently each run Its own notes What it reviewed last time and what you put down, so it never raises the same silence twice Two more inputs reach the Advisor at reflection , the pass that rewrites LEARNED.md , rather than on a report run: LEARNED.md itself, whole, hypotheses included, and the outcome ledger below. The playbooks and your mutes are designed as inputs and not yet read. None of this is copied into a prompt you cannot see. The report's Preview shows exactly what one run hands the model. Two clocks On the clock, today. The Advisor report runs on its schedule and when the app opens; the morning brief runs daily; reflection runs at launch and after three corrections, and reads the ledger whenever it runs. These find what only a window shows: a promise gone quiet, a task nobody touched, a goal with no movement, a sender you keep hearing from through a system you have not connected. Their findings are rows, judged like any arrival, because a forgotten task is work waiting on you and belongs on the rail where Next reads it in turn. Nothing fires for absence; something has to look. On the event. The same brain also runs when one item changes: an agent stops or asks, a reply arrives on a watched thread, a mail is attached to a task, a pull request opens, a task closes, a due day is missed, a report lands. One small prompt on the light model reads the event, the item's facts, the verbs the item carries, the promoted lines of LEARNED.md and the ledger rows that bear on it, and answers with one verb from the actions the app already has and one line, or nothing. Code checks the verb is one the item offers; a verb it does not is dropped and noted. Those findings are never rows. They attach to the item at its revision and show when the walk reaches it, as ghost text in the prompt box with one pill where the send arrow sits: \"Continue session · 8 of 8 times\". The number is read from the outcome ledger, never written by the model. The pill is the card's own button through the same proposal and the same receipt; typing anything brings the arrow back. A changed item drops its old line by one comparison. The item on the table earns one bigger read, with what the hub knows about the people on it and the month's outcomes. The rail's order does not read advice, by construction: the test that pins it builds the rail with and without advice and asks for the same order. Two settings govern it, in Settings → Advisor: the switch, and a cap on judgements per hour. Seeing what it did. The clock menu on the stage opens the Advisor's notes for the item on the table: a receipt, not a transcript. Each entry says the event, what it decided (the pill and the line) or what it dropped and why (nothing to say, a verb the item did not carry, the hour's cap, no brain), and the evidence it cited by id what it cited, not everything it read. \"Why?\" in the chat is answered from the same line. What was not followed up A thread you wrote on that nobody answered, or a step somebody owes past its day, is slipped once it has been quiet past that person's usual day: half again their median answer, once the ledger has seen them answer three times, and the default from Settings → Advisor until then. Someone whose auto reply says they are away never slips. A slipped row sits inside On you , the pipe count says \"3 slipped\", and when Next brings it up the card offers four answers, each an outcome the ledger keeps: Chase them drafts a short nudge on the thread, in your voice, for your yes copying whoever the ledger has seen get them to answer, when it has. When it goes out, the reply is marked a chase, and how long the answer took is counted against them. Let it go puts it down: the step is dropped, or the follow up closed. Three Let it gos on one person and the Advisor stops raising that person; nothing else changes. They answered elsewhere closes the step as done (its box ticks) and keeps where, in your words. Remind me is the same Remind me as everywhere else. A reply arriving ends it on its own: the follow up closes and the step leaves the lane. The morning brief carries the same facts, one line each, with the person's day named. A page per person Facts about other people go to a page per person, derived from the ledger at reflection and kept under Settings → Docs → People by address: how fast they answer, whether a chase is needed, who on copy moves them, what they deliver late each line with the evidence ids it rests on, and the counted numbers underneath. The lines are the model's reading; the numbers are the ledger's. Your own lines above the block are yours and survive every recompile. The page is read wherever the hub's dossier is read: the reply drafter, triage's context, meeting prep, and the Advisor's bigger read. The outcome ledger Every store Taskuary keeps is written from one signal: your click or your sentence, at the moment you give it. LEARNED.md is what you do when you correct; the verdict and routing memories stop at the verdict. Nothing recorded what you did next, or what the world did after Taskuary acted. That is what the ledger records: one row per action the app took or proposed, filled in two halves. The action, recorded when it happens What the sweep looks for Verdict A reply sent (approved as drafted, or edited first) More material mail from them on the thread in a week. An auto reply and a calendar response are not rounds; your own later mail is not theirs settled · unsettled: N more A task closed, by any road Is it still closed a week on held · reopened An agent stopped (with or without a pull request open) Your next move: a continue, with the words you typed into the pane or the session, or a close; or nothing in two days continued · closed · left A pull request merged Two weeks on, nothing says otherwise held A promise you made in a sent mail, as a task on you with its day Delivered when, against the day you named; or a week past it with nothing kept · kept late · late A sender ignored by a rule Whether their mail became a task anyway in sixty days no regret · regret Two things keep it honest. A stop is one row per stretch of waiting, not one per turn, and it closes the moment you type into the pane: that is your next move, in your words. And resolving a row is bookkeeping, not judgment: did mail arrive, did the task reopen, did the person deliver and when are facts already in the store, and the once a day sweep reads them without a model. What the facts mean is always the model's, at reflection. Reflection distils it into the stores that exist. The resolved rows reach reflection as evidence lines with their own ids, out beside the mem , rv and task ids a learned line already cites. Habits about you go to LEARNED.md with the same grammar, the same strength, the same decay: \"green PR from the coder: you merge it, 8 of 8\"; \"the agent asks 'open the PR?': you always say yes\". A habit carries the one number it never had, the regret count. Facts about other people (\"Ray answers in three days and needs a second chase\") and about kinds of work (\"closing from a thread with an open question reopens 40%; ask first\") are the next two build steps: a page per person derived from the ledger, and work facts proposed into the playbook they belong to. The one rule A derived line never acts on its own. It changes which button comes first, what a proposal says, what triage weighs, which day a chase goes out. Autonomy stays a proposal you click. \"Stop offering\" on any line writes the opposite evidence, and deleting the line from LEARNED.md is the whole undo. Earned autonomy the Advisor proposing to do itself what you have done the same way every time, revocable from the same line is shaped for but not built; every piece here is made so it needs nothing new. What is built, and what is next Built: goals as tasks (a task whose boxes are tasks, a person as an assignee, a promise as a task on you with its day, one row per goal on the rail); the outcome ledger with its daily sweep and reflection reading it; the Advisor on the event, with the prompt box pill and the notes in the clock menu; a page per person and a per person day, with the slipped lane and its four answers. Next: triage naming which goal step a mail serves, and work facts proposed into playbooks.","body":true},{"t":"","c":"On your phone","u":"./phone","x":"The assistant you talk to in the app is reachable from your phone over WhatsApp or Telegram. It is the same conversation and the same assistant — not a notification feed and not a second, weaker bot. It can walk you through your work, answer questions about it, and carry out the things the page can carry out. The doorways A doorway is one chat, on one channel, that the assistant is allowed to speak in. Set it up in Settings → Assistant on your phone , which lists every channel you have connected and lets you pick the chat and whether it may listen. 1. Connect WhatsApp or Telegram under [Connections](connections chat). 2. Send a message to the private chat you want to use — on WhatsApp that is the Message yourself chat. 3. Pick that chat in Settings. Taskuary names it as the Assistant chat and switches on the assistant for it. The Assistant then offers Walk me through them in WhatsApp (or Telegram) for each chat set up this way. Which chat the Assistant offers in the same section picks one — WhatsApp, Telegram, or both. :::rule Only chats you are alone in The picker offers nothing but chats with one member: you. Groups cannot be selected, because an answer may name anything in your workspace. The rule is enforced again when a message arrives, so the picker is a convenience rather than the guard. ::: Only messages sent by the linked owner account, in that exact chat, are accepted. Taskuary marks its own bridge output so its notifications can never loop back in as if you had typed them. What it can do Ask it in plain words. These are real examples, not a command list: \"what needs me?\" \"walk through important email\" \"what is outstanding?\" \"what did the coding agents finish?\" \"reply to Ruth that the numbers are coming tomorrow\" Walk through is the one worth knowing. It is the same turn by turn walk the Assistant page runs: one unresolved item at a time, one question, and it waits for your answer before moving on. The phone is not given a cut down version of it — the walk carries out the page's job, including the actions at the end of each item. Answers you give on the phone land in the desktop conversation too, because it is one conversation with two doors. Choosing The phone is the desktop Assistant in a chat, word for word. Every button the desktop card draws is a numbered line here, and on WhatsApp the same choices come again as a poll under the message, so one tap picks even when the only choice is Next . A number or a tap runs exactly what the desktop's button runs, and no model reads it. Only words you type go to the model. ![A number or a poll tap runs the desktop's action; Not ours asks how far, Send to agent asks which agent, an unclear checkout asks which repository; typed words go to the model](img/phone choices.svg \"A pick is the button; words are words.\") You send What happens a number, or a tap in the poll the desktop button with that name, run at once and if the model is still answering something you typed, that answer is dropped and the pick goes first Not ours \"How far?\" — just this once, from now on, or a rule in Settings; the answer you pick runs Send to agent \"Which agent?\" — triage's pick first, the other one next; the answer you pick runs a coding job with no clear checkout \"Which repository?\" — the best guess first; the one you pick starts Undo (offered under a receipt that can be undone) puts the last change back, once More the rest of a long message or, on a finished agent, its report then the same choices an old number, after you have already replied nothing — a list answers one reply, then its numbers are gone anything typed \"next\", \"undo\" and \"set up\" too the model reads it, with the same tools as the desktop. No typed word is a shortcut; only a number or a poll tap is a pill Typed words are answered by the Assistant's brain the same one, and the same model, as the Assistant in the app (Settings → Triage & agents → Assistant). A Claude Assistant runs at low effort unless its model names one ( claude sonnet 5@medium ): a turn is a short answer, and Sonnet's own default is high. Approving things A drafted reply comes to the chat with its Close out choice the same button as on the desktop, as a number or a poll tap. Nothing goes out without that pick: approving on your phone is the same deliberate act as approving on the page. The chat never pings you on its own: it speaks when you write to it or hand it the walk. The morning line Off unless you switch it on (Settings → Assistant on your phone). Once a day, the assistant can then open with a short line about the day ahead — what slipped, what is waiting, today's meetings. It is the morning brief's voice, cut to the length of something you read while walking. It fires once per day, not once per app start, and it is the same cap the brief itself uses: if today's line has gone out, reopening the app does not produce another. Handing over When a conversation on the phone reaches something better done at a keyboard — a coding session, a long document, a report builder — the assistant hands over rather than pretending. The tab it hands to locks onto that item so you arrive where the conversation left off, and the phone thread says so plainly instead of going quiet. The reverse is true too: a walk started on the page can be picked up on the phone, because the walk's position belongs to the conversation rather than to the surface you started it on. What it will not do It will not speak in a group chat, or in a chat you did not choose. It will not send anything a human has not approved, on any channel. It will not change a setting behind your back. A change you ask for comes back with an undo, or as a card for your yes. It will not answer someone else in your chat — only the linked owner account is heard. :::warn WhatsApp is an unofficial bridge The WhatsApp connector runs a local bridge against an unofficial protocol. It works well, and it is not a supported WhatsApp product: use a number you can afford to lose. Telegram uses a proper bot API and has no such caveat. ::: Sections, For later and browsing, on the phone The morning line and the walk offer the rail's sections as choices Walk On you , Walk For later , Walk Reports , Walk FYI and you stay inside the one you picked until it is empty, whether you press Next or act on the item (Make a task, Send to agent, Remind me). When the section runs out it says so, and the walk carries on. Rows under For later say when they come back (\"back in 3h\"). Connections , Reports , Hub and Settings are choices too the desktop sidebar's four, as picks: Pick You get Connections its sections with a count each, then a section's cards with on / off, then one card: what it does, and \"say set it up \" Reports every report and workflow with its clock and how its last run went, then one: when it runs, where it goes, what the last run said Hub what the agents worked out, newest first, then one entry in full Settings its sections, then each setting with its value, then one setting: what it does, and \"say what it should be\" Each step has Back as a choice. A list longer than a poll can hold (twelve) comes ten at a time with More (N left) and From the top ; a number you type still picks anything you can see. Changing anything is words \"run it now\", \"set it up\", \"make it hourly\" and comes back as a card for your yes, as in the app. A report's rows arrive as rows ( Lakeview · 112 ), laid out like any other table on the phone. Telegram gets the same cards, with its own buttons instead of a poll and no bold.","body":true},{"t":"","c":"Settings reference","u":"./settings","x":"Settings is a rail of pages, each one long page you scroll. This reference covers the Configuration page — every knob, in the sections the app itself shows them in. :::note This page writes itself Everything below the next heading is generated from taskuary/settings_schema.json , the same file the Settings page and the assistant read. A knob added to the app appears here on the next build, with the same name, the same group and the same help text. It cannot drift, and nobody has to remember to update it. ::: The other Settings pages are documented where their subject is: About you and the per channel identities, Routing policies ([the deterministic layer](how it works what triage actually decides)), Verdicts & notes ([the evidence behind LEARNED.md](how it works correcting it teaches it)), Audit integrity , and Updates ([updating](index updating)). How to read this Each setting shows what it does, and its shipped default. A few notes that apply throughout: Blank is meaningful. For a brain or model setting, blank means \"decide from what is connected\" rather than \"off\" — the specific fallback is given per knob. A switch that is off is off for everything , not just the surface you are looking at. Four AI slots — the triage brain, the default coding CLI, the assistant and the general agent, plus the judge that decides where a report run goes — are set on the cards at the top of the Configuration page rather than as plain rows. They appear below with their fallback rows, which is what you see if those cards cannot load. Triage & agents Triage brain triage_ai · type: brain · default: blank · set on a card at the top of the page Which AI reads and classifies inbound messages. TWO BRAINS: a small, fast cloud model (Anthropic / OpenAI / Azure OpenAI) classifies each message in under a second for a fraction of a cent, while your CLI agent — the expensive, capable one — is saved for actually working tasks. ONE BRAIN, TWO GEARS also works well: pick a CLI agent here and set its 'light model' (Docs → Profiles → Manage profiles → Edit) — triage, drafts, summaries and the digest then run on the cheap fast tier (haiku, gemini flash…) while coding sessions keep the agent's main model. No second API key, one bill. Left blank, it is your default brain on its light gear (haiku for Claude) never whichever connector was added first. Obvious automated noise is filtered by cheap heuristics before any AI is called either way. Backup AI connections triage_backup_ai · type: brains · default: blank Ordered alternatives for triage, reply drafts, summaries, reports, and assistant chat when the chosen AI is unavailable. Pick more than one. Taskuary tries them in the order shown when the primary brain hits a session or usage limit, is signed out, has no key, or otherwise refuses the call. A fallback uses its own default model; a model name chosen for Claude is never handed to Codex. This starts blank because crossing from a cloud API to a local CLI can change cost and privacy. Once you name backups, the same chain protects every short/background AI job as well as the non coding assistant. Assistant tab brain concierge_ai · type: brain · set on a card at the top of the page Which AI speaks on the Assistant tab and walks you through the pipe. auto = your default coding agent, on its faster, lighter model. THREE DEFAULTS, side by side in Triage & agents: the triage brain, the default coding CLI, and this one. A CLI agent here can ACT read a task or message, rerun a report, run a data tool because it has a shell; it runs in its own scratch folder on a light model (Claude: haiku, Codex: low effort, Gemini: flash, or the agent's own 'light model' from Docs → Profiles) and picks its conversation back up turn to turn, so only the first turn pays the start up. An API connector answers faster but can only talk. Sending, approving and pushing are your buttons whichever speaks. Assistant tab model concierge_model · type: text · set on a card at the top of the page A different model for the Assistant tab, if you want one (e.g. sonnet, or gpt 5.4 mini). Blank = the faster, lighter default. Add @low, @medium or @high to set how hard it thinks, e.g. claude sonnet 5@medium; a Claude model with nothing added thinks at low. For a CLI this is its model, and model@effort sets its reasoning effort (Claude effort, Codex model_reasoning_effort); for an API connector, its model or deployment name. Changing it starts a fresh CLI conversation. General agent brain assistant_ai · type: brain · default: blank · set on a card at the top of the page Which AI works every general task research, planning, writing, a job with no repository and answers the floating bubble. Your phone talks to the Assistant, not this. Normally set on the General agent card at the top of this tab; this row is the fallback if that panel cannot load. A CLI here can run tools, drive a browser and post to the wall; an API connector has no shell, so it can only read and write quicker, and enough for chat. Blank = the first active API connector, else the default agent. Where runs go judge_ai · type: brain · set on a card at the top of the page Which AI decides whether a finished report lands on your Timeline, your work rail, reaches you right away, or goes out. Normally set on the 'Where runs go' card at the top of this section; this row is the fallback if that panel cannot load. Four yes/nos about a result somebody else wrote, judged against the sentences on the report's own card it never has to write anything, so a decision model belongs here and a chat model is wasted on it. Blank = the brain that writes each report judges its own run. General agent model assistant_model · type: text · default: blank · set on a card at the top of the page Override the model for the brain above. Blank = the provider's own default. For an API connector this is its model or deployment name; for a CLI it is the profile's light model. Changing it starts a fresh CLI conversation. Default AI for agents default_brain · type: text · default: blank Which AI program runs an agent's work when its role does not name one. A role (coder, researcher, analyst) decides the instructions an agent starts with; this decides which program follows them. Blank = each profile's own program. Set from the cards above in normal use — this is the raw value they write. Naming a brain here is what stops a role name being read as a CLI name, which is how TQ 0588's coding work was once routed to Copilot. A role and a brain are different questions and one name cannot answer both. Fallback AI programs backup_brains · type: text · default: Tried in order when the first one has used up its allowance, is signed out, or will not start. = every other one you have set up, in the order they are listed. Failover is for AVAILABILITY failures only — session/usage/rate limits, quota, expired login, a missing executable — never for an agent that simply erred. The task, its messages, attachments, repository and seed prompt all travel to the replacement, which starts a fresh conversation with its own model. A different AI for one role profile_brains · type: text · default: blank For a role that should run on a different AI from the default above. Written as JSON, e.g. {\"researcher\": \"codex\"}. Blank (the default) means every role uses the default. The escape hatch for 'the analyst should run on codex but everything else on claude'. An unknown role name is ignored rather than guessed at. Edited here because it is rare enough not to earn a picker. Default coding CLI default_agent · type: agent · default: coder · set on a card at the top of the page The CLI agent that works tasks when nothing names one. Start session, Send to coding agent and auto dispatch all use this agent unless you pick another in the moment; every agent picker lists it first. The roster itself lives under Docs → Profiles → Manage profiles, where the default row wears the star. GitHub specific permissions (may agents open issues? push?) are on the GitHub connector card, because they are decisions about how your team uses GitHub, not about Taskuary. Triage & routing Intent triage intent_classify_enabled · type: switch · default: on Classify every new message: a task to DO, a question to ANSWER, or FYI to file. The heart of the funnel. Every inbound message is read (by the triage brain in Triage & agents, the section above, guided by SOUL.md) and classified: task = something must be done, so an agent can be dispatched; reply_only = answering IS the work, so a reply is drafted for your approval; fyi = informational, filed with no task and no draft. Off: every message becomes a task, which turns newsletters into work items. Leave this on unless you are debugging triage itself. Learn from your verdicts learn_enabled · type: switch · default: on Your corrections teach LEARNED.md — style, responsibilities, what deserves a task. Every correction you make — editing a draft before sending, rejecting one, reclassifying a task as a question, promoting something triage filed, 'Not a task' / 'Not our task' — is distilled into LEARNED.md (Settings → Docs): first as a hypothesis with a strength counter and the evidence behind it, promoted into the active profile only once it keeps holding across separate episodes. The active sections ride into every triage call, draft and agent run; SOUL.md always outranks them. Rules that would HIDE mail (treat as fyi, never a task) never activate themselves — they wait in the doc's 'Proposed rules' for you to adopt or delete. Off: nothing new is learned; the doc stays as it is and is still injected. Your mail goes to default_profile · type: profile · default: blank The worker that takes a non coding task when triage names no specialist for it. Blank leaves it unassigned for you to pick. Set this to the role you do, and the mail you get lands on the worker built for it. An accounts payable rep picks ap : a vendor asking where a payment is becomes a task for the AP worker, which looks it up in the ledger and drafts the answer for you to approve. Triage still names a specialist when one fits better (a researcher for outside information), and coding tasks always go to the coding agent. Docs → Profiles → Start from a role sets this for you. Replies Draft replies on reply_channels · type: channels · default: email,teams,slack,telegram,whatsapp,imessage,discord,github Which channels get a drafted reply at all. Switch one off and its questions just file. Options: email , teams , slack , telegram , whatsapp , imessage , discord , github A question arriving somewhere you never answer from should not open a reply task whose draft has nowhere to go. Turn a channel off and messages from it still land on the Timeline and can still become real tasks — they simply never get a draft, and the funnel says so in the row's reason ('replies are off for slack'). One answer for the whole app: triage uses it to decide whether a question becomes a reply task, the coder wrap up uses it to decide whether to draft at all, and the approval buttons on the task use it to decide whether Approve can actually send. They cannot disagree. Two rules are not yours to change here: GitHub also needs 'Reply to issue/PR authors' on its own card (a reply there is a PUBLIC comment), and the read only trackers — Jira, Linear, Sentry, PagerDuty and friends — can never carry a reply because Taskuary only reads them. Check your calendar when a reply is about time calendar_enabled · type: switch · default: on \"Tuesday at 1 works for me\" is only drafted if Tuesday at 1 is free. Reads the Outlook card's calendars (needs the Calendars.Read application permission) and a Google calendar if its OAuth fields are on the Gmail card. When the thread mentions a day, a time, a meeting or availability, the responder fetches your busy slots for the next 14 days and is told: never offer a busy time; if the asked time is busy, say so and offer the nearest free one; if the calendar could not be read, say","body":true},{"t":"","c":"When something is wrong","u":"./troubleshooting","x":"Most things that go wrong in Taskuary go wrong quietly and safely — a message gets filed instead of guessed at, a run reports its error in place instead of taking the report down. That is by design, and it means the answer to \"why did nothing happen?\" is usually written down somewhere. This page is where to look, in the order worth looking. It will not start Nothing opens. Taskuary serves http://127.0.0.1:7787 . If the browser shows nothing, check whether the process is running and, more usefully, what is actually listening: More than one Taskuary can run against the same database, and their command lines look alike. The listening port is the only reliable way to tell which one is serving you — a second instance on another port will happily keep polling and triaging with older code. The port is taken. If another Taskuary owns the port, the CLI opens that instance. If a different process owns it, the CLI automatically selects a free port and prints the new address. Use taskuary port PORT or set TASKUARY_PORT when you need a specific port instead. It started and immediately closed. A corrupt config.toml is the common cause, and it fails before Taskuary can write the useful error to taskuary.log . If you started Taskuary from pip, read the traceback in the terminal where you ran taskuary . If you started the desktop app, read ~/.taskuary/desktop error.log . Rename a corrupt config.toml and Taskuary writes a fresh default. A connection stopped A connector card shows its own last poll and its last error, and that is the first place to look. Symptom Usual cause Nothing new since a fixed time The sign in expired. Reconnect on the card \"could not read your channels\" The app is older than the page expects — restart it Mail arrives but no replies go out Replies are off for that channel, or the card has no send authority A tracker connected but silent Nothing is assigned to the connected user — that is what it reads WhatsApp went quiet The bridge lost its session. Re pair it; the unofficial protocol does this periodically If the card looks healthy and items still are not appearing, check the card's roles . A connection with no trigger or feed role is never polled, which looks exactly like a broken connection from the Timeline. Triage got it wrong First, work out whether triage ever saw it. Open the row: it says what decided the outcome and why. [What triage actually decides](how it works what triage actually decides) lists the eleven steps and which of them are deterministic gates. Stopped by a gate (a feed connection, a policy rule, your own standing ruling, an agent already waiting) — the fix is that rule, that role or that ruling. The classifier was never asked. Judged and wrong — correct it on the Triage tab. The correction is written into TRIAGE.md and applies to the next message like this one. \"Awaiting AI triage\" — there is no AI connector active, so nothing was guessed. Add a key, and the retry sweep picks it up. \"Triage failed\" — the call failed or returned something unreadable. It was filed rather than assumed to be work; the row keeps the error. :::note A verdict you disagree with is not a bug Triage is supposed to be argued with. The correction loop exists because the right general rule is rarely knowable from one message — and a correction teaches the class, not the sender. ::: A reply has no confirmed delivery Approval stays pending while Taskuary sends the reply. Repeated clicks do not start another send, and a task closes only after the provider confirms delivery. Delivery unknown means the provider timed out, the process stopped during sending, or a receipt could not be verified. Check the provider's sent messages before taking any further action. Approving again checks the original attempt; it does not resend just because a receipt is missing. Providers that cannot verify the attempt leave it pending for you to investigate. Sending failed means the attempt was rejected or blocked. Fix the connection or send permission, then review and approve the draft again. An agent is stuck It is waiting on you. A raised hand on the Studio floor, or a 👋 agent waiting on you row on the Board or the work rail, all mean the same thing: the session asked something. Open the task and answer it. It is waiting on its CLI. A headless agent without its noninteractive flag hangs forever on a prompt that cannot be answered. The connector presets set the flag; a custom CLI needs it added. The card's Test action reproduces it in ten seconds. It hit a limit. The saved result says so. Start new coding session picks a different harness and keeps the checkout and the history. It says there is no local path for the repository. Map that repository to its checkout on the AI CLI agent card, or make the checkout discoverable. A task naming a repository cannot fall back to an unrelated default working folder. It is gone. If the process died, the row reads ⏹ agent stopped and is forced unread, so it comes back to you rather than disappearing. Only Later holds it. Save and end session ends the session, files what it did and drafts the reply for you to approve; it leaves the task state alone and sends nothing. If you want the task closed, Mark done does both. A report returned nothing Open the report row: the last run shows what it read, what came out, and the error if it failed. One source failed — it is reported in place and the rest of the pipeline still ran. Fewer rows than you expected — check max rows . Blank means 200, which is a cap nobody chose, and a capped run says so in its headline. The prose does not match the numbers — Test — show me the data on the source card returns the exact text the prompt was handed. That is almost always where the surprise is. It never ran — a slot missed while the app was closed fires once on reopen, not once per missed slot. Run due now forces everything owed. Reading the audit log Settings → Audit integrity is the answer to \"why did this happen\" and \"who did this\". Every consequential action is one row: routed, filed, replied, opened, saved, deleted — with the actor, the time, and the thing it happened to. Verify recomputes the hash chain from the first row and tells you whether the record has been altered since it was written. \"Out of order\" is benign — two writers raced once. \"Contents altered\" is not, and it names the rows. Where the logs are Thing Where Application log ~/.taskuary/taskuary.log Desktop startup crash ~/.taskuary/desktop error.log The database ~/.taskuary/taskuary.db Configuration ~/.taskuary/config.toml A coding session's full transcript the task page → Work details → Full artifact The context an agent was handed ~/.taskuary/context/ Playbooks ~/.taskuary/playbooks/ .md Under Docker, all of it is /data inside the container. TASKUARY_HOME moves it anywhere. Still wrong The live API reference at /api/docs shows exactly what the app exposes, and is the fastest way to check whether a thing you expect is actually there. Issues: [github.com/ldbumble/taskuary/issues](https://github.com/ldbumble/taskuary/issues). Security problems go through [SECURITY.md](https://github.com/ldbumble/taskuary/blob/master/SECURITY.md), not a public issue.","body":true}]
\ No newline at end of file