List allowed projects and their default Telegram destinations.

Send a formatted message with provenance metadata.

Prefer format='html' for human-facing text. Use raw Telegram HTML tags: , , , , , , , , and . Never encode tags as <b>. brief is the default: concise, self-contained, client-ready copy without process or internal technical details. For an explanation, structure the text by named objects and list their concrete steps, properties, result, and limits. Do not replace details with a general conclusion or a prose comparison. standard adds necessary context; detailed is used only when explicitly requested and must still fit Telegram's 4096-character limit.

Send a concise, client-ready structured update.

brief is the default. Write for a recipient who has not followed the project: put the concrete subject and current result in one self-contained summary using plain everyday language. Replace jargon and internal names with their practical meaning. Add only blockers, decisions, questions, or the next action needed now; completed is omitted when the summary already says what was done. Keep every field inside the exact subject requested by the user; never append unrelated project health. Include a client question only if the answer is not already available, the recipient controls it, and progress on the subject stops without it now. Build the dependency chain internally and ask only the first unresolved dependency, not questions about later steps. Omit the question section when nothing passes this test. Address the recipient directly. For client copy, put a required choice in client_questions, not the internal decisions_needed section. Do not include chronology, review or test logs, implementation details, tool names, or internal reasoning unless they change a client decision, risk, cost, or deadline. The server enforces preset-specific length and item limits and renders safe Telegram HTML.

Send copy-ready text addressed directly to the client.

This is the default tool when a manager should be able to copy the body without understanding the project or rewriting it. Each topic title must be a concrete subject taken from the client message or current project, such as "Оплата" or "Фотографии". Never use fixed report headings such as "Проблемы", "Нужно решить", or "Вопросы". Preserve all subjects raised by the client that are inside the requested scope; brevity removes internal reasoning, not necessary facts.

Put concrete facts, proposals, and next actions in details. Address the client directly. Add question only when its answer blocks the next action now, and ask only the earliest unresolved dependency. Omit question when no answer is needed. Do not shorten by a fixed word or item count. Keep all facts the client needs; the only hard content limit is Telegram's 4096 visible characters.

Send an explicitly requested local file or image with a concise caption.

The path must resolve under files.allowed_roots. kind=auto sends supported, small images as Telegram photos and everything else as documents. Use raw Telegram HTML in an HTML caption and keep it within the 1024-character limit.

Send a concise formatted completion notice when explicitly requested.

Prefer format='html' and raw Telegram HTML tags, never escaped tag text. Use brief by default and state the concrete completed result without an emoji, greeting, or generic "done" preface. Select standard or detailed only when the user explicitly requests more context.

Summarise what the capture daemon has buffered, without fetching content.

Check this before inbox_fetch: it reports volume per chat and the age of the oldest unprocessed message, so a range can be chosen deliberately. last_poll is the daemon's heartbeat - if it is hours old the daemon is down and Telegram will start dropping undelivered updates after about a day.

Fetch buffered messages for a time range and mark them as taken.

since and until are ISO-8601 timestamps compared against the message date in UTC. Rows carry the forwarded-message origin, so a forwarded quote keeps its real author instead of the person who forwarded it. Fetching does not remove anything: call inbox_done once the messages are recorded in the archive.

Set include_taken to see messages handed out earlier but never archived - that is how a batch interrupted halfway is recovered.

Mark messages as archived, which deletes their downloaded copies.

Call this only after the messages are in the archive with their hashes: the buffer copy of a file is redundant from that moment and is what actually grows on disk. Each key is {"chat_id": int, "message_id": int}. Rows survive for the configured TTL so a mistake stays recoverable.

Write a self-contained folder for a range, ready to import into an archive.

Prefer this over inbox_fetch whenever the messages are going into the archive: it copies the attachments next to inbox.json and rewrites their paths to be relative, which is the only form an archive will accept. Passing raw rows instead files every attachment as missing while the bytes are still on disk. Messages are marked taken; call inbox_done once they are recorded.

target must be a fresh directory. Set include_taken to rebuild a bundle for messages handed out earlier but never archived - that is the only route by which their attachments can still reach the archive.