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.

The other Settings pages are documented where their subject is: About you and the per-channel identities, Routing policies (the deterministic layer), Verdicts & notes (the evidence behind LEARNED.md), Audit integrity, and Updates (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 · 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.

auto = the first active AI connector holding a key. Obvious automated noise is filtered by cheap heuristics before any AI is called either way.

Backup brains#

triage_backup_ai · type: brains

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's CLI on its quick gear.

THREE DEFAULTS, one place each: the triage brain (Triage & routing), the default coding agent (Coder agent), 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

Override the quick gear for the brain above (e.g. sonnet, gpt-5.4-mini@low). Blank = the default.

For a CLI this is its --model (Codex takes model@effort); for an API connector, its model or deployment name. Changing it starts a fresh CLI conversation.

General agent brain#

assistant_ai · type: brain · 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 and the WhatsApp doorway.

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 · 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 brain#

default_brain · type: text

Which CLI actually executes a worker when its role names none. A ROLE picks the document a session is seeded with (coder, researcher, analyst); a BRAIN is the executable that runs it. Blank = each profile's own command.

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.

Backup brains#

backup_brains · type: text

Ordered alternates when the first brain is out of sessions, signed out, or cannot start. * = every other configured one, in roster order. This is the live successor to the old 'Backup coding CLIs', which named profiles and no longer does anything.

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.

Per-role brain overrides#

profile_brains · type: text

JSON, e.g. {"researcher": "codex"} — one role that should run on a different brain from the default above. Blank (the default) means every role uses the default brain.

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 · 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

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 below, 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.

When no rule matches#

default_action · type: select

The fallback when no routing policy claims a message.

Options: draft, task_only, escalate

draft = reply-only questions get an AI draft waiting in Review; task_only = file a task, draft nothing; escalate = always put it in front of you undecided.

This is only the FALLBACK: your routing policies (Settings → Routing policies) always win, and messages triaged as real tasks go to the coder regardless.

Learn from your verdicts#

learn_enabled · type: switch

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 (Docs tab): 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.

Replies#

Draft replies on#

reply_channels · type: channels

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 Review buttons 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

"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 you will confirm. The task gets a note that the calendar was checked.

Agents can read the same thing: POST /api/tools/run with type "calendar".

Draft replies automatically#

auto_draft_enabled · type: switch

Questions get their AI draft the moment they arrive, waiting in Review.

Retired: a message triaged as a question always lands in Review with its draft requested at once, and a draft that could not be written says so with a retry. Nothing sends itself — approving is always yours.

Acknowledge chat asks at once#

chat_ack_enabled · type: switch

The moment an agent starts on something asked in Teams, WhatsApp, Telegram or Messages, one line goes back into the chat so they know somebody is on it.

In chat, an ask is a task AND a question - and until the agent wraps up and its reply is approved, the person hears nothing. On: when a chat line becomes a task and an agent actually starts, the line below is sent into the same chat right away. It is fixed text, never a drafted answer, so it promises attention and nothing else.

Not twice within half an hour on the same chat, and never when your own last line there is that recent - they have already heard from you. Off for a channel when its replies are off (above). Mail never gets one: an email thread can wait for the real answer.

The acknowledgement#

chat_ack_text · type: text

The one line that goes back. Keep it honest - it is sent before anything has been looked at.

Written in your voice, since it arrives from your account. Something like "On it - I'll get back to you here." A question mark invites an answer you are not there to read yet.

Assistant#

Lines per post, at most#

assistant_max_lines · type: number

The assistant checks in every 30 minutes and on startup (the 'Assistant' report on the Reports tab — edit its prompt for what it watches for, change the cadence, delete it to turn it off) and posts only when it has something to say. How it SPEAKS is COUNSEL.md on the Docs tab: edit that to change its voice, how bold it is, what it takes a position on. This caps how much one post says. 5 by default.

One AI call per post, and none when there is nothing new. Every line has a key and a state, so it never says the same thing twice. Talk back under a suggestion to correct it or ask a follow-up; the answer and your correction stay with the idea and inform later checks. 'Follow up' drafts the chase in your voice into Review — nothing is sent by itself; 'Make it a task' starts the agent. Voice: COUNSEL.md (Docs tab); what to watch for: the report's prompt. Without an AI connector the facts still post, in the hub's own words. 'Run now' on the Reports tab's Assistant row posts regardless of the schedule.

Silence before a follow-up#

assistant_followup_hours · type: number

Hours after your last reply on a thread — one that asked for or promised something — before 'no answer yet, follow up?' appears. 24 by default.

Only your own last word counts, and only when it asked or promised something ('could you send', 'by Friday', a question mark). A plain thanks that goes unanswered is not a follow-up. The chase itself is drafted only when you click.

Quiet days before a task has 'gone cold'#

assistant_cold_days · type: number

Open work with no comment, message or run for this many days gets a line. 3 by default.

A task with a live agent on it is never cold. One with a draft waiting in Review is named as waiting on you.

What it looks for#

assistant_producers · type: channels

followup = your unanswered asks · promise = what you said you would do and have not · prep = meetings in the next two days, with what came before them · cold = tasks gone quiet · idea = the model's own thoughts from the day's mail, guided by the report's prompt.

Options: followup, promise, prep, cold, idea

Switch a kind off and it never appears in a post again; lines already posted keep their actions and conversation. 'idea' is the only one that needs an AI connector — the others are read straight off the hub's own tables and your calendar. With 'idea' off no model is called at all: the facts post in the hub's own words.

The pipe reaches back (hours)#

funnel_hours · type: number

How far back ordinary mail, reports and fyi enter the pipe the assistant walks you through. Drafts waiting for your yes and agents waiting on you always enter.

A first launch must not surface a year of never-triaged mail. Twelve hours is a working day; set it to 48 after a long weekend.

The pipe holds at most#

funnel_max · type: number

How many items the pipe shows at once. The rest wait their turn and slide in as you clear it.

Order is kept: an agent waiting on you or a draft for your yes is never the one held back.

An open task comes back after (minutes)#

task_return_minutes · type: number

How long a task you cleared from Work stays quiet before it is raised again. Sixty by default.

Done takes a task off the work tab, it does not close it — the task stays open in Tasks. Rather than let it sit there unseen, the work tab raises it again once it has been quiet this long, and keeps doing so until somebody closes it. Use the Completed button on the card to end it for good. Later and Skip still outrank this: a task you put down until tomorrow stays down.

FYI read together#

fyi_batch · type: number

How many fyi the assistant puts in front of you at once. 1 to 10; four by default.

An fyi needs no action, so they come in a batch rather than one at a time. At 1 they arrive singly, which is the slow read-everything walk; at 10 you clear the noise in one card. Anything outside 1-10 is clamped - a 0 would take the fyi lane out of the walk entirely.

Keep past chats (days)#

chat_keep_days · type: number

Archived assistant chats older than this are removed once a day. Fifteen by default.

Only the chat transcript goes. What a chat said about a task stays on the task, and memories, rules and correction evidence are never touched.

Assistant on your phone#

Chat with the assistant in WhatsApp or Telegram#

phone_assistant · type: switch · set on a card at the top of the page

The default for a channel that has never been asked. Each channel above answers for itself once you set it.

Name the Assistant chat on the WhatsApp or Telegram card under Connections first. Taskuary then listens only to messages you send in that exact private chat. Other people, other chats and groups cannot command it. This is separate from the Notifications role, so the Assistant chat is not subscribed to ordinary Taskuary alerts.

It is the SAME walk the Assistant tab runs, on the same conversation and the same pipe: the item on the table stays where it was, a reply you ask for is drafted, and a yes sends it. The choices arrive as words because a chat has no buttons.

This switch is the standing permission. The Assistant tab's own "in WhatsApp" button hands the walk over for a session whether or not it is on, and locks the tab while the walk is there.

Because answers can contain private workspace information, use a chat only you can read — WhatsApp's Message yourself, or your own private chat with the Telegram bot. Off (default) leaves your messages ignored as before.

A morning line in the chat#

phone_morning_line · type: switch

Once a day, the assistant's chat says what is waiting and offers the three ways in: walk me through my tasks, set up Taskuary, set up a report.

On (the default once a chat is chosen): the first check after 6:00 sends one line to the Assistant chat on every channel that has one - the count in the pipe and how many are on you, then the three scripts as numbered options, so one reply starts the walk there. Quiet on a day the pipe is empty; never twice in a day. Set-up is always offered: there is always more to set up, and from a chat it opens on what is connected.

Off: the chat speaks first only for a hand-off, a review ping or a report aimed at it.

Coder agent#

Hand answers to the working agent#

answer_to_agent · type: select

An agent asks a question mid-task, Taskuary asks the person, and their reply lands back on the same task. This is what happens next. ask = Review offers one click, 'Type this into the agent's session'. auto = it is typed in the moment it arrives, as if you relayed it. off = it just sits on the task.

Options: ask, auto, off

Only a LIVE session is ever typed into. If the agent already exited nothing happens and the answer simply waits on the task, so auto cannot lose anything.

The reason this is a choice rather than always-on: auto puts someone else's words into your agent's session without you reading them first. That is usually what you want on your own team's mail and rarely what you want from a stranger's reply, and Taskuary cannot tell the difference well enough to decide for you.

How finished work lands#

git_flow · type: select

A draft pull request, or the commits pushed straight onto the default branch.

Options: pr, direct

pr (default) = a DRAFT pull request from the task's branch; you review and merge it yourself, and Taskuary never merges. direct = the commits already in the checkout are pushed straight onto the default branch — no PR, no review ceremony, which is usually what you want on your own repository.

Direct mode is deliberately narrow: it pushes commits that ALREADY EXIST. A dirty checkout is refused rather than committed for you (Taskuary will not write a commit message over work nobody has read), nothing ahead of the remote is simply 'nothing to do', and a rejected push is reported for you to pull and rebase — it never force-pushes.

Either way 'Agents may push / deploy' on the GitHub card is what allows anything to leave the machine at all, and CI watching follows the work to wherever it landed.

Watch CI on the task's pull request#

ci_watch · type: select

A red build goes back to the agent that wrote the code, with the failing check named.

Options: off, feedback, watch

Once a task has a draft pull request (open it from the task, or let the agent propose one), every sync refreshes its checks.

feedback = a failing build is typed into the live session — 'these checks failed, fix the cause and push again, do not merge' — and recorded on the task; if no session is live the task returns to 'open' so it lands on you. watch = the state is shown on the proof card but nothing is handed back. off (default) = no polling at all.

Each distinct failure reaches the agent ONCE per commit, never on every poll. Taskuary opens drafts and never merges.

Agents may propose actions#

proposals_enabled · type: switch

An agent can ASK to open a PR, comment publicly, close an issue or run a tool — each waits for your approval.

High-impact actions come off the auto-approve road entirely. Instead of doing them, the agent writes a typed proposal in its transcript (TASKUARY-PROPOSE {"action": "open_pr", …}); when the session wraps up, each valid one becomes a pending review saying what it wants and why. Approving RUNS it; rejecting does nothing.

Every proposal is re-validated at execution, so approving never grants a permission you have switched off — an open_pr proposal still needs 'Agents may push / deploy', a public comment still needs the GitHub card's reply switch. Malformed or unpermitted proposals are refused and recorded on the task rather than dropped silently.

Tell-the-agent notes land one per stop#

waitroom_drip · type: switch

On: a queue of prompts drips in - each time the agent stops, the next one is typed in, the rest wait their turn. Off: everything queued goes in as one batch.

The waiting room is a funnel: paste twenty prompts and each becomes its own note, in order. With the drip on, the agent gets one at a time with its full attention - it is told how many wait behind it and that the next comes when it stops again, so it never goes looking. Turn it off to hand over the whole list in one message instead.

Auto-start the coding agent#

coder_auto_enabled · type: switch

Every new coding task immediately opens a live CLI session in its repository. Off: the task waits on the Board for you to send it.

On: the moment triage says 'this is work' your CLI opens in the task's repository (picked from the SOUL.md repo map) with the full ask seeded: visible on the Board, watchable, interruptible. General work uses the separate assistant auto-start switch. Only plain questions (a reply is drafted instead) and notices (filed) stay out of it. Off: tasks queue as 'needs you' and you press Start session yourself.

A first-time sender from outside your domains never starts an agent by itself - the task lands, you press the button. Requires the CLI installed and signed in on this machine. Nothing ships or sends without your approval either way.

Auto-start the assistant on general tasks#

general_auto_enabled · type: switch

Every new general task (research, a question to think through, a job with no keyboard) opens its own assistant session with the ask already put. Off: the task waits for you to open it.

Both worker kinds start by themselves by default; each has its own switch. The same holds apply to both: a first-time sender waits for your click (release it from the task), a coding job whose repository is unclear waits for your choice, and a missing AI provider is said on the task instead of failing quietly. A hold never hides the task - it is still triaged and on the Board.

Who may start a worker without you#

trust_own_domain · type: flags

An inbound message can open a task AND start the agent on it unattended. These are the three rules that allow it; a sender matching none of them still gets triaged and lands on the Board, and only the unattended start waits for your click.

One control over: your own domains (trust_own_domain), people you have written to (trust_sent_history), chat channels (trust_non_email)

Three separate switches until 2026-09-16, which meant reading all three to know the answer to one question.

your own domains — every connected mailbox's domain and the owner address.

people you have written to — checked in your own records first, then asked of the mail server once per address and remembered. Earlier INCOMING mail is never evidence: a stranger's second message is still a stranger's. A lookup that fails is not proof either way, so the task says so and waits.

chat channels — Teams, Slack, Telegram, WhatsApp, iMessage, Discord.

Turn all three off and nothing ever starts by itself; every task waits on the Board for you. Turning them off does not stop triage, drafting or filing - only the unattended start.

Write the agent a context file#

coder_context_file · type: switch

Each session gets ~/.taskuary/context/TQ-xxxx.md: this sender's recent mail and what you last wrote them, the topic elsewhere, your calendar, the assistant's read, the learned profile, the whole thread - and the reports of closed tasks on the same sender, subject or repo. The seed says 'read it first'.

The seed prompt is one command line (Windows caps it at 32,767 characters, and when it overflows the ask is what gets cut), so the two-line read rides in the prompt and the rest lives in this file. It is written under Taskuary's own home, never inside a checkout - a stray file in a shared checkout gets staged. Off: the seed carries what it always did and no file is written.

Write Claude Code hooks into your checkouts#

agent_hooks · type: switch

Taskuary adds four hook entries to .claude/settings.local.json in each repository a session opens, so the Board reads the agent's real tool calls instead of guessing from the screen. Switch it off to leave your checkouts untouched — the Board then falls back to reading the terminal.

The decision here is whether Taskuary may WRITE to your repositories, not whether the Board should be accurate — it should, which is why this ships on.

The file is the project-LOCAL settings Claude itself gitignores, so nothing is committed. Existing hooks are kept and only Taskuary's own entries (marked by the /api/hooks/claude endpoint) are replaced. Removing them by hand is safe; they are rewritten the next time a session opens.

CLAUDE CODE ONLY. The hook format is Claude's, so on codex, copilot, qwen, devin or any other CLI this switch does nothing at all — those sessions are read from the terminal whatever it says.

Let a finished agent close its own task#

agent_self_close · type: select

An agent that has finished wraps itself up: the report is written from its transcript and the reply to whoever asked is drafted for your approval.

Options: 1, ask, 0

Done was a button, which meant a task finished at 2am produced no report and the person who asked heard nothing until somebody opened the tab. The agent knows it has finished long before you look, so it says so.

The explicit road is a command every session is told about in its prompt: taskuary --done with one sentence. That closes the task, files the report from what is on screen, and drafts the reply - which still waits for YOUR approval before it leaves.

yes = that, plus a safety net: when a Claude Code session stops talking, the end of its transcript is read and the task closes only if it plainly reads as finished. A session parked on a question never closes - the screen is checked for one first, and an unsure judge does nothing.

only when it says so = the command works, the silent ending does not. never = the Done button, exactly as before.

Agents at once#

auto_sessions · type: number

How many unattended agent sessions may run together. The rest queue.

The one number that decides how much work this machine takes on at once. Four is the default because four live CLI sessions in four checkouts is about what a laptop stays responsive under — each one is a real process with a real model behind it.

Past the limit nothing is dropped: a dispatched task joins the queue and starts the moment a session ends, and the Board shows it waiting with the reason. The Board's floor view is drawn to this number, so raising it widens the room instead of crowding it.

Raise it if the machine has headroom and your tasks rarely touch the same files; lower it to one if you would rather watch a single agent at a time. Sessions you start yourself are never blocked by this.

Notifications#

Push to your chat#

notify_level · type: select

Ping a Telegram / WhatsApp / Teams chat instead of you watching the tab.

Options: needs_me, all, off

Give a chat connector the Notifications role (its Role step) and name the chat in its config; this decides what gets pushed there.

needs me (default) = only what is genuinely waiting on YOU: a question to answer, a task nobody was dispatched at, and — the one that matters — 'the work is done, the reply is drafted and waiting in Review'. everything = every new timeline item. off = never push.

Events that happened in the notify chat itself are never echoed back into it, so one channel can safely be both input and output.

Sound when an agent raises its hand#

hand_sound · type: sound

A session that stops at its prompt, or asks you a question, plays this - from any tab. Off silences it.

The moment worth a sound: the thing you delegated is now waiting on you. It fires once, on the transition from working to waiting, never while you already have the task open in front of you. Sounds are synthesised in the browser - nothing to download.

The desktop notification below is separate: it is the browser's own, so it reaches you when Taskuary is behind other windows, and the first time it asks for permission.

Desktop notification when an agent raises its hand#

hand_desktop · type: switch

The browser's notification, so it reaches you when Taskuary is behind other windows. Click it to jump to the task.

Answer agents & approve from phone#

phone_approvals · type: switch

Reply to a tagged ping to answer that live agent, approve a draft, reject it, or write the reply yourself.

On: when a live coding agent stops or asks, its chat ping carries a [tqN] tag. Reply to that ping and your words go straight into that exact agent session. Pending-reply pings carry the DRAFT and an [rvN] tag: 'approve' sends the draft, 'reject' / 'no reply' land those verdicts, and ANY OTHER TEXT is sent instead of the draft. Confirmations come back into the chat.

Needs a Telegram or WhatsApp connector with the NOTIFY role and its notify chat set — and the connector polled (trigger or feed role on). Answers and verdicts are intercepted before triage, so they never become new work. Quoting the [tqN] ping is required for agent answers because several agents may be waiting at once.

Off (default): pings stay read-only.

Attachments & images#

AI reads attached images#

vision_enabled · type: switch

Screenshots go to the triage AI — "see below" mail is read, not guessed at.

Half of "see below" mail says nothing in its body: the screenshot IS the request. On: attached images (PNG/JPEG/GIF/WebP, up to 4 per message, 5MB each) ride along into triage when the model has vision, and coding sessions get the local file paths to open themselves.

Off: only text is ever sent to the AI — the setting to use if your model lacks vision or images must never leave the machine. The panel still displays attachments either way.

Charts on reports#

report_images_enabled · type: switch

Reports hand back a bar chart alongside the spreadsheet.

A report's rows always come back as an .xlsx; with this on they also become an .svg bar chart drawn in the panel — and the summarizing model, which just read every row, picks which column to plot (better than a heuristic grabbing the id column). Off: spreadsheet only.

Sync & startup#

Background sync (minutes)#

poll_minutes · type: number

How often the app checks your connections while it is open. 0 turns it off.

The server keeps this clock, so it runs whichever tab you are on and whether or not you are looking at the app - it is also what makes a SCHEDULED REPORT fire on time, since reports are checked on the same pass.

It used to live in the Timeline tab instead: the countdown died the moment you opened Board or Tasks, restarted itself every time you changed a filter, and with the window closed nothing polled at all - so a report set for 8am Monday only ran if somebody happened to be sitting on the Timeline at 8am on Monday.

10 is the default. Lower it if you want mail sooner and do not mind the API calls; 0 turns recurring background polling off. Sync now, startup catch-up, and an action that must refresh chat context can still fetch.

Chat connectors (Teams, Slack, Telegram, WhatsApp, iMessage, Discord) also have a separate recurring fast clock - every 30 seconds unless their card says otherwise. 0 here disables both recurring clocks; manual Sync now, startup catch-up, and action-time refreshes remain available.

Catch-up window (days)#

startup_sync_days · type: number

How far back the app reaches when it opens, for what arrived while it was closed.

Taskuary is a window you open, not a service — at 5:30am it is closed, so 'anything since I last polled' misses the weekend. On startup every trigger connection is asked for this many days; the window only ever WIDENS (a source last polled a month ago is not pulled forward), and duplicates are never re-ingested.

The Timeline shows the catch-up running and refreshes when it lands. The daily DIGEST.md synthesis runs right after it. 0 = plain incremental poll on startup.

Mark items read at the source#

mark_read_enabled · type: switch

Once the funnel has taken a message in, mark it read where it came from — the mail seen, the chat read.

Off (default): Taskuary is a pure reader — your inbox still shows every message bold, so nothing about your mailbox changes because you connected it. On: anything the funnel ingests is marked read at the source, so the bold rows left over are exactly the ones the hub never saw.

WHERE IT APPLIES: Outlook mail (needs the Mail.ReadWrite consent), Gmail/IMAP mailboxes (the \Seen flag), Slack channels (the read cursor moves to the newest line taken), Teams (Graph marks the whole CHAT read — there is no per-message read state there) and WhatsApp (blue ticks, via the bridge).

WHERE IT CANNOT: Telegram and Discord bots have no read state to set, and the trackers — Jira, Linear, GitHub, Sentry and friends — have nothing to mark. The switch is simply a no-op for them.

Marking always runs AFTER the message is safely stored and is best-effort: a refused permission is logged and never costs you the ingest.

Display#

Timezone#

timezone · type: timezone

The zone the app's clock speaks. Blank = this machine's local time.

Timestamps are stored in the server machine's local time. Name that zone here and every displayed time wears its label (2:44 PM EDT) — and a browser opened from another timezone still reads the stamps correctly instead of silently reinterpreting them in its own zone.

Use an IANA name (America/New_York, Europe/London, Asia/Jerusalem). Takes effect on the next page load.

Fade bottom of Timeline#

timeline_fade · type: select

How tall the soft fade is at the bottom edge of the Timeline viewport.

Options: off, gentle, normal, sharp

Rows are never dimmed because they are old. A row only gets lighter while it passes through the bottom edge, then returns to full contrast as you scroll it upward. Gentle, normal, and sharp change the height of that band; off removes it. Purely visual - nothing is hidden or removed.

Timeline lookback (days)#

feed_days · type: number

How many days the Timeline shows. Display only — nothing is deleted.

Purely the Timeline's window. Older messages stay in the database, in task histories, and in search.

Routing policies#

Rules evaluated before any AI touches a message; no model confidence overrides them. Precedence runs ignore → escalate → auto_answer → draft → task_only, and within one action the lowest order number wins.

Kinds: keyword (pipe-separated substrings matched against subject and body), sender (exact addresses), sender_domain, noreply (a built-in matcher for automated addresses), and first_time_sender (fires when the address has never been seen).

Actions: ignore files it with no task, and it stays visible; escalate puts it in front of you and marks the task urgent — this is the only thing that marks one urgent, so name the senders whose mail should jump your queue; auto_answer auto-approves the draft, which is still never sent; draft is the targeted default; task_only files a task and drafts nothing.

Nothing writes into this table by itself. Not a task teaches a verdict in Verdicts & notes, not a rule here, and muting a sender is Skip this sender.

Verdicts & notes#

Two layers, one loop. LEARNED.md on the Docs tab is the general profile — your style, your responsibilities, what deserves a task — written by a nightly pass. This page is the evidence that pass reads: one dated line per verdict you gave, plus notes you write yourself, each tied to a sender, a domain, a subject, or everyone.

When a message arrives, the lines that bear on it ride into triage and into the reply draft, and the model judges how alike the new message really is — the same sender asking the same thing is binding, a shared word is not.

Toggle off a line that was learned wrong: it stays for the record, is never injected again, and the next distillation drops it too.

Audit integrity#

Every consequential thing Taskuary does is one row in an append-only log: a message routed or filed and why, a verdict, a reply sent, an agent session opened or wrapped, a connector saved, a setting changed, a task deleted.

Each row stores a hash of its own contents plus the hash of the row before it, so the rows form a chain. Change any row after the fact — even one character in the database — and its hash no longer matches, and every row after it points at a parent that no longer exists.

Verify recomputes the whole chain from the first row:

The history below it is that log, newest first: when, who, what was done, and to what. It is the answer to "why did this happen" and "who did this" for anything on the Timeline or the Board.