Turnbook

Team project brains: decisions and progress shared with teammates' AIs, per project. Not for the user's own memory or their other PCs: that is brain_folder. A project brain holds what a team's AIs need to know about a project, apart from the user's personal memory and from every other project. Nothing personal is shared through this; only what is published here, when the user asks. Files and notifications stay in Slack, drives and GitHub; a project brain keeps the decisions, the progress, the context and links to where the work is. Always pass `workspace` = your current working folder: a folder bound to a project makes it the default `project`. Publish only when the user asks ("공유해", "프로젝트에 올려줘", "체크포인트 남겨"): that request is the approval, so do not ask again; ask only if the project is ambiguous. Afterwards say exactly what went where. - `projects`: the project brains the user takes part in, with when each was last shared. - `create_project` + `project` (+ `path` = folder to bind): only when the user names one. - `publish` + `type` + `summary` (one line, user's language) + `details` (a handover note: what changed and why, files and functions, test results, links, what is left). Never paste conversation text. `supersedes`=<id> replaces an earlier decision. - `context` (with publish or attach): what changed, where (pages, sections, files, functions), why, verification (test or check results), remaining, review_focus, and the ids it answers (`addresses`) and its `evidence` (commit, PR, test log, Slack or document links). Write only what you know; what is left out reads "not recorded". - `attach` + `path`: a git folder links its commit at the stage it really reached (committed / pushed / pr_open / merged / released; never call work done when the stage says otherwise); a URL (a Slack message, a drive document) is kept as a link. Files are not stored here: if the user wants a file shared, share it in Slack or a drive (with the tools for those) and at…

Answer from the user's past: one bounded text packet to read before replying. The default memory call: use it whenever a request may depend on earlier conversations, facts, preferences, decisions or work. It returns `context`, a size-capped text of the relevant memories and conversation turns, each with its date and source. For structured rows, ids or one thing's history use brain_recall instead. Set `recent=true` whenever the question is about what happened lately or what the user was just doing: "what was I working on?", "where did we leave off?", "what did I do yesterday?", "최근에", "아까", "어제", "지금 뭐 하고 있었지?". Results then come newest first instead of by word overlap; naming something ("what did Kongi do lately") keeps them about that. Set `since` (ISO date or time) to drop anything earlier, e.g. "this week". Set `about_assistant=true` when the user asks what YOU said earlier: "which restaurant did you recommend?", "what were the steps you gave me?", "네가 아까 뭐라고 했지?". Your own past answers are then searched by meaning too, not only by their words. Set `around` when the question is about WHEN WE TALKED: "what did we discuss last week?", "지난달에 얘기한 거" -> resolve it yourself to a date or "start..end" (e.g. "2026-09-23" or "2026-09-01..2026-09-30"). Conversations from then rank first; nothing is dropped. Do not set it for when something HAPPENED ("the event I went to two weeks ago"): people mention events days or weeks before or after, so that date misleads (measured: on dev2 it pushed the answering turn out in 2 of 11 questions and helped 2). Each conversation item is one excerpt of one turn. Never tell the user you don't know without first opening the item most likely to hold the answer: brain_recall(source=<the text after "Source: <app> / ">) returns that turn in full with the turns around it (your reply to that request, the rest of a list, the line before). Open it too when an item you rely on is cut off.

Where the user's own personal memory lives, and which of their own PCs share it. Not for teams: project brains shared with teammates are brain_checkpoint. Anything that changes where the memory goes (`path`, `share_existing`, `export_to`, `import_from`) is not done from here: the tool returns `command`, and the user runs it in a terminal. A web page or file you read can then never move their memory somewhere else. Show the user the command, say what it does, and call this again without arguments after they ran it to confirm. Codes and passwords appear only in that terminal. Call it with `path` when the user names a folder for their memory, e.g. "use my Google Drive's Turnbook folder as my brain". A folder that OneDrive, Google Drive or Dropbox syncs makes the same memory available on every PC where the user chooses it too; nothing else is needed but the password: lines there are encrypted, and the first PC's terminal shows a password the user types on each other PC (the terminal asks for it). Without `path` it reports the current folder and the devices writing to it. `path="local"` keeps the brain in this PC's own Postgres instead, shared the instant it is written (no sync delay). Other PCs: when the user asks to let their other PCs use this brain ("다른 PC도 붙게 해줘"), call it with `path="share"`. It opens this PC's Postgres to the local network and Tailscale (Windows may ask the user to approve a firewall rule once) and returns a `connection_code` in the terminal. On the other PC the user runs `turnbook folder <that code>`; it contains the password, so say not to post it anywhere public. Codes: when the user pastes any Turnbook code ("gm1." for their own other PC, "gmt1." for a team invite), call this with `path=<the code>`; it does the right thing for either (a team invite is joined at once), so never ask the user which kind it is. `share_existing=true` sends what this PC remembers and the shared memory lacks (only that: it also repairs turns that missed a hub t…

Delete what the user wants gone from memory: "delete the password I typed earlier", "그 토큰 지워줘", "forget what I said about my ex". Always two calls. First `query`: what to look for, in general words ("password", "wifi", "DB login"); never repeat a secret the user typed. It returns numbered candidates with masked previews. Show the user exactly those previews and ask which to delete; never quote the original text. Then call again with the `ids` the user picked, and only those. Deleting removes them from this PC, its search indexes, the shared memory and the user's other PCs. This exchange about deleting is not saved either. The AI app's own chat history is separate and untouched (Claude Code keeps ~/.claude/projects).

Raw lookup: the matching memories and turns as structured rows, not a ready context. `source`: open the conversation around one turn. Pass the part after "Source: <app> / " of a conversation item in brain_context's packet. A packet shows one excerpt of each turn; when it is cut off, or the answer is likely in the rest of that exchange (your reply right after the user's request, a list you gave, the line before), this returns those turns in full, in order (`limit` caps how many follow; two come before). To answer the user's question from their past, use brain_context instead; it returns one bounded text packet ready to read. Use brain_recall to inspect or list: the ids and fields of what matched (e.g. before brain_forget or `supersedes_memory_id`), one thing's history in order, or what the store knows about. `entity` answers "what happened to X, in order": every memory about that one thing (the auth module, this project, my address), oldest first, with replaced entries marked and the current one picked out. Similarity search returns only the nearest one or two of four decisions made about one thing in four sessions; this returns all four. With neither `query` nor `entity`, it lists what the store knows about, busiest first. `recent`, `since`, `about_assistant` and `around` mean the same as in brain_context.

Save what the user just told you, in their own words. Call this proactively. A fact that can change later (where they live or work, a pet, a preference, a plan, a number they track): also pass `about` (who or what, e.g. "Kongi", "me") and `attribute` (which property, a short English snake_case name, e.g. "breed", "home_city", "favorite_coffee"). A later value with the same `about` and `attribute` replaces this one and recall shows both: the value now and what it was before. Use the same `attribute` names every time, and never put the value in the name: "last_trip", not "last_trip_paris", or the next trip will not replace it. Use it the moment the user mentions anything about their life, work, plans, preferences, people, places, meals, purchases, health, decisions or events, e.g. "I had kimchi fried rice today", "my dog is called Kongi", "we moved the meeting to Tuesday". Do not ask whether to save it and do not wait to be told "remember this". Only `content` is required: put the user's own sentence there verbatim. Add `entities` (who or what it is about) and `effective_at` (when it happened, ISO time) when you know them. If it updates something remembered earlier, pass that memory's id as `supersedes_memory_id`. Decisions and their reasons are memories too: `memory_type="decision"`, the reason in `content`, the project or component in `entities`. Save silently. Do not tell the user you saved it ("I've noted that", "저장해 뒀어"); just carry on with the conversation. Talk about memory only if the user asks what you remember or whether something was saved.

Code changes the capture service recorded, with diff excerpts, filtered by project, time range (`happened_from`/`happened_to`, ISO), file, symbol or kind. For "what did I change in auth.py last week?" or "when did the parser change?". Empty unless a code folder is being watched (automatic-capture.json, code_workspaces).