| brain_rememberA | 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.
|
| brain_recallA | Raw lookup: the matching memories and turns as structured rows, not a ready context. 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.
|
| brain_contextA | 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).
|
| brain_folderA | 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.
Call it with `path` when the user names a folder for their memory, e.g. "use my Google
Drive's Graph-MIND 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. 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`. Show the user that code and tell them to paste it to the AI on the
other PC; it contains the password, so say not to post it anywhere public.
Codes: when the user pastes any Graph-MIND 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,
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 that was down). It uploads
it to wherever the folder syncs. Set it only when the user has explicitly agreed to that.
`reindex=true` brings the search index up to date (links new memories, embeds unembedded
ones). Saving already does this; it is for a large imported backlog.
Moving a whole memory as one file ("내 기억 파일로 내보내줘", "이 기억 파일 가져와"):
`export_to=<file path>` writes every memory and conversation turn into that file;
`import_from=<file path>` adds such a file's contents to this memory, skipping what is
already here. Only when the user asks. Tell them the file holds their entire memory
(secrets were masked when saved), so keep it private like a diary.
|
| brain_checkpointA | 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 attach the link.
- `timeline`: "누가 어디까지 했어?" — answer from it only: who, what, what is left, and
when it was last shared. Do not guess at anything newer. Follow its `instructions`.
- `retract` + `checkpoint_id` (the publisher, or the project's owner);
`set_instructions` + `instructions` (owner).
- Members. Whoever creates a project owns it. `invite` + `member` + `role` (owner /
editor / viewer) + `projects` returns a code to give them. `members` + `project`;
`remove_member` + `member` + `project` (owner; or yourself, to leave). `audit`
(+ `project`). On a teammate's PC: `join_team` + `code` (+ `name`), `leave_team` +
`project`.
- Where projects live: on a Postgres hub (`host`: make this PC one; teammates on the
office network or over Tailscale), where `invite` on the hub's PC also makes their
account (elsewhere they need an account from the hub's operator first); without a
hub, on this PC alone. Someone in several team hubs and none of their own:
`create_project` + `hub` (an address of it).
- `set_name` + `name`: the name teammates see (else this PC's name). If a result says
NAME_REQUIRED, ask the user for it (their own name, e.g. 고요한), set it, then retry.
If the result says UNAVAILABLE, the hub cannot be reached: tell the user the latest
shared state is unknown right now; never fill in from memory.
|
| brain_forgetA | 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).
|
| code_activityA | 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). |
