Searching a space's history

Searching a space's history

A new chat does not remember earlier chats. With history search the assistant has one extra tool, plank_history_search, that finds what the space already knows. It is on in every space by default (since 2026-10-19), and Plank can switch it off for a space on request. A container that started before it was turned on gets the tool at its next restart, so if you do not see it, explore the usual way.

What it searches

• digest — a short summary of each past turn (what was asked, done, left open, decided), including scheduled and automated runs
• chat — messages of past chats
• log — entries of log.md, one per date
• file — text files in the space (notes, scripts, CSV/JSON, HTML as text)
• source — entries of the sources registry
• page — dashboards and reports
• app — rows of the space's app-data tables (the 30 most recently written tables, the newest 200 rows of each)

It never indexes binaries, uploads/, .git/, node_modules/, .env*, credentials*.json or token.json, a table kept as a channel's message history or named like a log (messages, audit, events, history…), or a column named like a secret (password, token, api_key…). A deleted table row leaves the search within about 30 minutes. It does not change knowledge/memory.md: rules still live there.

A chat you delete leaves search with the delete: its text and the digests of its turns are erased, and the agent no longer finds it. A space brief built earlier refreshes within a day.

When to use it

Search before exploring folders, before saying you do not know, and before asking the person something the space may already record. It matters most when the person points at the past: «как в прошлый раз», «мы же решали», «where is the export script». One or two specific queries (names, ticket ids like ATL-707, file names, topics) beat opening log.md, which is far too large to read.

Search also before you draft a reply or message the space may already have an approved text, template or rule for (a welcome message, a reply to a known kind of question, a status format): the space's own wording beats a well-written guess.

How a Plank feature works, and what Plank already ships (templates, kits, deck builders), is not this space's history: search that with plank_docs_search (see /help/docs-search).

How to call it

plank_history_search takes:

• query (required) — words or a question
• kinds — any of digest, chat, log, file, source, page, app
• since / until — ISO dates (until is exclusive)
• limit — up to 10 (default 8); up to 15 (default 10) with spaces
• spaces — "all" or a list of space slugs: search your other spaces too (see below)

It returns cards: kind, date, title, a ref and a snippet. The top three cards carry the whole matching passage (up to 1 500 characters); the rest carry its first 300.

Cards are ordered by relevance, but one kind cannot crowd out the others: when a table row, a chat, a file or a log day is close enough to the question, up to two of each kind are kept in the answer, in place of the weakest cards of a kind that already has more. An app-data card's text ends with its table and column names, which helps a question that names the field ("score", "deadline", "status") reach the row. Searching with kinds narrows the search to those kinds only.

Searching your other spaces

In your personal container, spaces searches several of your spaces at once: "all" for every space you are a member of, or a list of slugs (the folder names under /spaces/). It is not offered in a shared workspace container, which always searches only its own space.

• Only spaces you are a member of right now are searched; a slug you are not a member of is skipped, never searched.
• A space whose history search is off is skipped too.
• Private chats stay private in every space: you find your own, never another member's.
• At most 60 spaces per search. Each card names its space, (space: <slug>), and the result starts with one line saying which spaces were searched and which were skipped and why.
• Open a file card from another space at /spaces/<slug>/<ref>. A chat or app-data card from another space may not open from here yet: quote its snippet and say which space it is from.

Opening a card

The ref says how to read the full thing:

• chat:<ses_id> — read it with plank_chat_read. With no other argument you get the chat's last messages; a long chat's answer is often far earlier, so pass find with an exact id, name or figure from the snippet (case-sensitive, message text only): you get the newest messages containing it, each with its neighbours. Every answer names a before position to page further back, and says when a message was cut and by how much
• a file path — open it with read
• log.md#YYYY-MM-DD — one day of the work log; log.md is too long to read whole, so find the day with grep -n "^## YYYY-MM-DD" log.md and read from that line
• a digest card ends with Chat: chat:<ses_id> — the chat the turn happened in
• digest:<turn_id> — the summary is the card itself; follow its Chat: line if you need detail
• source:<uuid> / page:<uuid> — find it in the sources registry or the dashboards list
• app:<table>#<id> — one row of that table: read it with plank_app_query (filter by id), and take figures from the table, not the card

Treat a card as a lead, not a verdict: check the file or chat before relying on a detail, and say so when the history contradicts what the person just told you.

Answering from what you found

When a card is the answer, the answer is the source you opened, not your summary of it. Answer every part of the question, and add from the same source what was decided about it and what comes next (the next check, a deadline, the remaining tasks). Carry the specifics over as the source writes them: ticket, PR and version ids, dates and times, figures, names, menu paths and steps. To make it shorter, cut your own words, not those. Add nothing the source does not say. If the person asked for a short answer or a particular form («одной фразой», «без номеров»), that wins.

A search that found cards ends with a one-line reminder of this.

When nothing matches

Cards are ranked by similarity, so a search almost always returns something. A card about something adjacent (another ad channel, another month, a similar ticket) is not the answer. If no card is about what was asked, say first and plainly that the space has no record of it. Only then, if it helps, add one short line on the closest thing you found. Do not ask the person to choose between near matches.

The search also warns when this is likely, in a line above the cards: «Слабое совпадение» when no card stands out from the rest (what a search returns when the space has no record of the question), and «Ни одна карточка не упоминает …» when an id from the query (a ticket or document number such as ATL-1655) appears in none of the cards. The cards are still all shown: open one only if it is about exactly what was asked, and otherwise say there is no record.

The space brief

In spaces where it is turned on, AGENTS.md also carries a short state of this space, written by the platform from recent history: what is in progress, recent decisions, what waits for an answer, and what appeared (dashboards, sources, files). It is a snapshot taken when the chat starts and is rebuilt daily, so it can be out of date: check a figure, id or decision in its source or with plank_history_search before relying on it. It is not memory: rules still live in knowledge/memory.md. In a space with several members it is built only from shared chats, scheduled and automated runs, never from anyone's private chats.

Privacy

A private chat is visible in search only to its owner, and that includes a scheduled or automated run whose chat is private: its messages and its turn summaries are found only by the person it runs for. A shared chat and the space's files are visible to every member. In a shared workspace container (no individual person behind it) private chats are never returned.

Summaries of turns and the space brief are written by an OpenAI model on Plank's own OpenAI subscription (a DeepSeek model stands in when it is unavailable); the search index is built with Qwen3-Embedding-8B, an open embedding model, run by Fireworks AI (a US provider that states it does not store the text it is sent; OpenAI embeddings stand in where Fireworks is not configured). All of them are called by the Plank API, never from a running turn, and nothing is written into the space's files. Each summary counts toward your AI allowance like a small chat turn; when the allowance is used up, new turns are simply not summarised until it resets.