ultimate-brain 0.2.4 → 0.3.1

package/.agents/skills/brain-apply/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: brain-apply
-description: Apply the user's decisions on proposed changes to the brain. Shows pending proposals in chat and applies what the user approves, rejects or edits, or reads the decisions the user made in the Notion Review queue and applies them, then rebuilds and republishes. Use when the user says "apply my reviews", "what needs my decision", "approve the launch change", "apply the Review queue", or after deciding proposals in Notion.
+description: Apply the user's decisions on proposed changes to the brain. Shows pending proposals in chat and applies what the user approves, rejects or edits, or reads the decisions and Notes the user left in the Notion Review queue and applies them, then rebuilds and republishes. Use when the user says "apply my reviews", "what needs my decision", "approve the launch change", "apply the Review queue", or after deciding proposals in Notion.
 ---
 
 # Apply review decisions
@@ -24,18 +24,19 @@ Run every CLI command as `brain <command> --brain <brain> --json`. Exit 1 means
    - `update_fact`: old → new value.
    - `contradiction`: both values, and say approving keeps both as contested, while editing picks the true one.
    - `add_to_note`: the text to add.
-   - `add_link`: what gets linked to what.
+   - `add_link`: what gets linked to what. A grouped row lists every link, lettered: "Acme website: add a) Lucía Fernández, b) Tomás Vidal to People, c) alias 'acme site'".
    - `supersede`: the new note replaces the old one.
    - `merge`: the duplicate is folded into the survivor.
    - `new_item`: the note that would be created.
 
    Look up titles with `brain index --json` instead of showing ids. Mention the ones already decided but not applied.
-3. **Ask** which to approve, reject or edit. Accept replies like "approve 1 and 3, reject 2, edit 4 to 90000 EUR". Edit is only possible for `update_fact`, `contradiction` and `add_to_note`; say so if the user asks to edit another kind. **If a reply is unclear, ask again.** Don't guess.
+3. **Ask** which to approve, reject or edit. Accept replies like "approve 1 and 3, reject 2, edit 4 to 90000 EUR". Edit is only possible for `update_fact`, `contradiction` and `add_to_note`; say so if the user asks to edit another kind. On a grouped `add_link`, "approve 5 except b" approves it with those links excluded. **If a reply is unclear, ask again.** Don't guess.
 4. **Apply.** Write the input and run `brain apply --input <file>`:
    ```json
    { "decisions": [
      { "proposal": "prp-…", "action": "approve", "decided_at": "<now, ISO 8601 UTC>", "decided_by": "chat" },
-     { "proposal": "prp-…", "action": "edit", "value": "90000 EUR", "decided_at": "<now>", "decided_by": "chat" }
+     { "proposal": "prp-…", "action": "edit", "value": "90000 EUR", "decided_at": "<now>", "decided_by": "chat" },
+     { "proposal": "prp-…", "action": "approve", "exclude": [ { "field": "people", "value": "per-…" } ], "decided_at": "<now>", "decided_by": "chat" }
    ] }
    ```
    To apply only what was decided earlier, run `brain apply` with no `--input`.
@@ -45,14 +46,23 @@ Run every CLI command as `brain <command> --brain <brain> --json`. Exit 1 means
 
 1. **Read** the Review database through the Notion MCP: the rows where **Decision** is set and **State** is Pending. Normalize each row into the snapshot format of spec/cli.md §5.14.1:
    - `database: "review"`, the `page_id` and `last_edited`;
-   - the properties Name, Kind, Decision, Edited Value, State and Brain ID.
+   - the properties Name, Kind, Decision, Note, State and Brain ID.
 2. **Plan.** Run `brain sync plan --input <snapshot>`. It writes nothing. Save the reply's **`data` object** (not the whole JSON reply) as the plan file; `sync apply` rejects the full reply. Read:
    - `decisions`: what will be applied;
-   - `conflicts`: e.g. `EDIT_WITHOUT_VALUE`, where Decision is Edit but Edited Value is empty. Tell the user, who fixes it in Notion;
+   - `conflicts`: `NOTE_TO_READ` is an Approve or Reject with a Note: read it as "Reading a Note" below says. Others the user fixes in Notion: `EDIT_WITHOUT_VALUE` (Edit with an empty Note), `EDIT_NOT_ALLOWED` (Edit on a kind that can't be edited, such as a link row: suggest Approve or Reject, with a Note);
    - `ignored`: e.g. `ALREADY_TERMINAL`. Nothing to do.
-3. **Apply.** Run `brain sync apply --input <plan file>`, adding `--record-only` when unattended.
+3. **Apply.** Run `brain sync apply --input <plan file>`, adding `--record-only` when unattended. Then apply the decisions you resolved from Notes with `brain apply --input` (unattended: leave `NOTE_TO_READ` rows for an attended run).
 4. Continue with **Finish** below.
 
+## Reading a Note
+
+The Note is the user's instruction for that one row (decision 0037). The CLI never interprets it; you do, and you **never apply a change the Note doesn't clearly ask for**. Decide each `NOTE_TO_READ` row as one of:
+- **A narrower decision on this row:** "all except Tomás" or "only Ana" on a grouped `add_link` → `approve` with `exclude` listing the other links (by their `{field, value}` in the proposal's `links`). "Yes, but it's March" on an `update_fact` → `edit` with that value. Pass `note` = the Note as written, `decided_at` = the row's `last_edited`, `decided_by: notion`.
+- **A different change** (a role typed on a link row, a fact about another note) → apply this row as its Decision says, and write the other change as its own proposal with `brain proposal new` (`why` = the Note, `source` = the proposal's `source`), so it gets its own Review row.
+- **Unclear** → ask the user, quoting the Note, and leave the row as it is until they answer.
+
+In a catch-up these are decided in its read-only pass and confirmed in its one batch of questions.
+
 ## Finish (both modes)
 
 1. **Read the results** of each item:
@@ -60,13 +70,13 @@ Run every CLI command as `brain <command> --brain <brain> --json`. Exit 1 means
    - **`closed`:** a rejection, or `STALE_PROPOSAL`. Stale means the note changed after the proposal was written (for example your own Notion edit), so the brain did not apply it. Tell the user the current value; the next ingest may propose again.
    - **`recorded`:** decided but not applied (`--record-only`).
    - **`skipped` with `ALREADY_TERMINAL`:** it was already done.
-   - **`failed`:** report the `reason` and `message`. `INVALID_RESULT` means applying it would break a rule, such as a value of the wrong shape. `EDIT_NOT_ALLOWED` means an edit on a kind that can't be edited. `UNKNOWN_ID` means the proposal or its note is gone.
+   - **`failed`:** report the `reason` and `message`. `INVALID_RESULT` means applying it would break a rule, such as a value of the wrong shape. `EDIT_NOT_ALLOWED` means an edit on a kind that can't be edited. `EXCLUDE_UNKNOWN` means an `exclude` named a link the row doesn't have: re-read the Note. `UNKNOWN_ID` means the proposal or its note is gone.
 2. **Rebuild:** run `brain index`, `brain views`, then `brain lint`. If lint reports an error in a file this run changed, stop and report; don't commit.
-3. **Commit:** `apply: <n> applied, <n> closed`, listing the proposal titles in the body. If this run does not publish (step 4), push now: `git push`; if the push fails, say so in the report's last line and carry on (decision 0038).
-4. **Publish** *(Notion mode, attended runs only)*. A chat run does not publish: its changes go out with the next Notion-mode run or `brain sync` (spec/cli.md §6, "Apply in chat"). In Notion mode:
+3. **Commit:** `apply: <n> applied, <n> closed`, listing the proposal titles in the body. If this run does not publish (step 4), push now, per `settings.push` (the brain's AGENTS.md, "Write path").
+4. **Publish** *(Notion mode, attended runs only, per `settings.publish`)*. A chat run does not publish: its changes go out with the next Notion-mode run or `brain sync` (spec/cli.md §6, "Apply in chat"). In Notion mode:
    1. Run `brain sync render --changed`, write the pages through the MCP, then `brain sync record`. The steps are the same as in the brain-ingest skill's references/notion.md "Publish": Review rows move to State Applied or Closed, and the changed notes are updated.
    2. Log it with `brain log publish - pages=<n>`; `sync record` itself does not log (§3.9, §5.14.6).
-   3. Commit: `publish: apply results`, then `git push` (same rule as step 3).
+   3. Commit: `publish: apply results`, then push (same rule as step 3).
 5. **Report** in three lines (decision 0037):
    ```
    Done: 8 applied · 1 closed (stale) · 12 pages published
@@ -79,7 +89,7 @@ Run every CLI command as `brain <command> --brain <brain> --json`. Exit 1 means
 
    **Below the three lines, the report grows with what was applied** (decision 0037, amended 2026-10-18), uncapped, one line each:
    - **What changed:** each applied change in words ("Acme budget is now 95000 EUR", "Ivo joins Acme rollout").
-   - **Check:** each proposal closed as stale, with the note's current value; each failure with its reason in a few words; each Edit the user should look at again.
+   - **Check:** each proposal closed as stale, with the note's current value; each failure with its reason in a few words; each Edit or Note the user should look at again; each change proposed from a Note. Only things the user can act on: a note the render skipped because it has nothing to publish (its type has no database, or nothing changed) is not a finding.
 
    A run with nothing applied stops at three lines. Never ids, file paths, commands or commit names.
 

package/.agents/skills/brain-catch-up/SKILL.md

@@ -0,0 +1,66 @@
+---
+name: brain-catch-up
+description: Do everything that is waiting in one run. Pulls the user's Notion edits, applies the reviews they decided, ingests reviewed meetings, new Inbox rows and the drop folder, publishes and pushes, asking every question once at the start and then finishing without stopping. Use when the user says "catch up", "what's next", "do what's waiting" or "process everything".
+---
+
+# Catch up
+
+One run for everything waiting (decision 0037). It has two halves: a **read-only pass** that finds the work and every question it raises, then **one batch of questions**, then a run that finishes without asking again. Anything that becomes blocked during the run is **skipped** and listed in the report; the rest goes on.
+
+This skill orders the work; the other skills hold the steps. Read each one before running its part: brain-sync (pull and publish), brain-apply (decisions), brain-ingest with its references (meetings, sources, the drop folder). Their rules apply unchanged, including the trust rules in the brain's AGENTS.md.
+
+Run every CLI command as `brain <command> --brain <brain> --json`. If `brain` is not found (`command not found`), install it with `npm install -g ultimate-brain`, then retry.
+
+## 1. Read-only pass
+
+This step changes no knowledge: no note, proposal, `brain.json`, commit, Notion page or drop-folder file. Two writes are allowed because they change nothing the user owns: `brain index` may regenerate a stale `index.md` (generated, rebuilt again later in the run), and the working files (`snapshot.json`, `plan.json`, conversions) go in a temporary folder outside the brain.
+
+1. **Status.** Run `brain status`; run `brain index` if `index_stale`. Note `settings` (absent means `publish: ask`, `push: auto`) and which databases are configured. Each Notion part below needs its database configured; skip the ones that aren't and name them once on the report's Needs you line.
+2. **Pull plan.** Brain-sync "Pull", steps 2–4, with the snapshot and plan in the temporary folder: snapshot the databases brain-sync step 2 reads (Areas, Goals, Key Results, Projects, People, Orgs, Decisions, Questions, Concepts, Review; never Meetings or the Inbox, which `sync plan` rejects), whichever are configured; run `sync plan` once, save `plan.json`. It holds the imports, your corrections, the decided Review rows and the conflicts.
+3. **Notes on Review rows.** For each `NOTE_TO_READ` conflict, read the Note against its proposal and decide what it means (brain-apply, "Reading a Note"). Write down the decision you would apply, or the question it raises.
+4. **Meetings** *(Notion)*. Brain-ingest steps 2 and 3, up to the duplicate check: the Reviewed meetings, oldest first, and each one's pre-check blockers. Minutes files are ingested only when the user names them, never looked for.
+5. **Inbox.** The New rows (brain-ingest references/sources.md, "capture"), oldest first, each with its pre-check blockers. A row with Project or Area set needs no project question.
+6. **Drop folder.** The queue and its question (sources.md, "The drop folder", steps 1–2), without moving anything.
+7. **Pending proposals in chat.** Without a Review database, run `brain proposal list --status pending,approved,edited,rejected`: these go in the batch as chat decisions (brain-apply, chat mode, steps 2–3).
+8. **Your identities.** If `brain.json` has no `owner.person`, add the identities question (brain-connect-notion, step 6).
+
+The pass is done when every input that is waiting has been found and each of its blockers is written down as a question or a default.
+
+## 2. One batch of questions
+
+Ask once, in one message, numbered and grouped by input, each with the answer you will use if the user says "go" (the **default**):
+- sync conflicts (`BOTH_CHANGED`, `MISSING_REQUIRED`, `UNRESOLVED_RELATION`, …) and your corrections, as brain-sync step 5 shows them;
+- each Note you read, as "Note 'all except Tomás' → approve 3 of 4 links (leave out Tomás)";
+- each meeting's and input's pre-check blockers;
+- the pending proposals, as brain-apply's chat list (default: leave them pending);
+- the drop-folder list, all files selected;
+- the identities question (default: skip for now, ask again next catch-up). The user's answer is their approval of those aliases;
+- with `settings.publish: ask`: "Publish to Notion at the end?" (default yes). This is the run's only publish question.
+
+When nothing blocks, don't ask: say what you will do in one line and start. When nothing is waiting at all, give the report with `Done: nothing waiting` and stop.
+
+## 3. Run, in this order
+
+1. **Pull and apply.** `sync apply plan.json` (brain-sync steps 6–8), then with `brain apply --input`: the decisions you resolved from Notes (brain-apply, "Reading a Note"), the chat decisions from the batch (`decided_by: chat`), and the identities. For the identities, run brain-connect-notion step 6 in full, with the batch answer as the user's approval: the owner-ruling source and, when the owner's person note exists, one `add_link` alias proposal per value applied with `decided_by: chat`; when it doesn't, a new person note (`brain note new`) carrying the aliases; then `brain config set owner.person`. Rebuild and commit as brain-apply "Finish", steps 1–3. Conflicts the user didn't answer stay conflicts.
+2. **Meetings,** one at a time: brain-ingest steps 4–10.
+3. **Inbox rows,** one at a time: sources.md steps 3–7.1.
+4. **Drop-folder files** the user chose, one at a time, the same way.
+
+For each input, publishing waits for step 4 below. **Skipped, not asked:** an input whose ingest raises a new question or fails is left as it is (the meeting stays Reviewed, the row New, the file in the queue) and goes on the report's Needs you line. The one hard stop: a lint error in a file this run wrote. Stop the run there, commit nothing more, and report.
+
+## 4. Publish, push, report
+
+1. **Publish** (when `settings.publish` is `auto`, or the user said yes), once for the whole run, following brain-ingest references/notion.md "Publish" for each write, in this order:
+   1. **Pages:** `sync render --changed --plan plan.json`, write every item (pending relations: publish and record those first, then render again, until no item is pending), `sync record`. This publishes the new notes, the proposals, the meetings' relations and every source's Inbox row.
+   2. **Tasks,** now that their projects and Inbox rows exist: `sync tasks --meeting` for each ingested meeting and `sync tasks --source` for each ingested source with owner tasks; create each returned item once; `sync record` its page ids. An item still listing `pending_relations` (a project that isn't in Notion) is not created: list it under Check.
+   3. Set Brain Status = Skipped on the Inbox rows the user skipped.
+   4. Log `brain log publish - pages=<n>` and commit `publish: catch up`.
+2. **Move the drop-folder files** (sources.md, "The drop folder", step 4): after the publish commit, or right after each file's ingest commit when the run doesn't publish.
+3. **Push** per `settings.push` (AGENTS.md, "Write path").
+4. **Report** once, in the shape of brain-ingest step 12, for the whole run, the decisions included:
+   ```
+   Done: 9 applied · 3 captures and 2 files ingested · 12 new notes · 1 task for you
+   Needs you: 3 Review rows (1 grouped) · 2 files skipped (too long, say which parts)
+   Next: decide in Notion, then "catch up"
+   ```
+   Below the three lines: **What came in** and **What changed**, then **Check** (each skipped input with its reason, stale proposals, assumptions), as brain-ingest step 12 and brain-apply "Finish" step 5 define them, uncapped. Offer the `settings.publish` switch here when AGENTS.md says to.

package/.agents/skills/brain-connect-notion/SKILL.md

@@ -1,18 +1,19 @@
 ---
 name: brain-connect-notion
-description: Connect the brain to the user's Notion space after it was built from the notion/ prompts. Finds the Brain Data page and its databases through the Notion connection, checks each has the properties the brain reads and writes, stores their ids in brain.json, and maps the Tasks database. Changes nothing in Notion. Use when the user says "connect the brain to Notion", after building the Notion space, or when a skill reports a Notion database is not configured.
+description: Connect the brain to the user's Notion space after it was built from the notion/ prompts. Gives the agent access to Notion, finds the Brain Data page and its databases, checks each has the properties the brain reads and writes, stores their ids in brain.json, maps the Tasks database and records the owner's identities. Changes nothing in Notion. Use when the user says "connect the brain to Notion", after building the Notion space, when Notion is unreachable, or when a skill reports a Notion database is not configured.
 ---
 
 # Connect the brain to Notion
 
-Find the user's Notion databases and record their ids in `brain.json` (decision 0015). This skill **only reads Notion**. Its single write is `brain.json`, through `brain config set`.
+Find the user's Notion databases and record their ids in `brain.json` (decision 0015). This skill **only reads Notion**. It writes `brain.json` through `brain config set`, and, only in step 6 and only with the user's answer as their approval, the owner's identities: an owner-ruling source note, plus either alias proposals on the owner's person note (applied in chat) or a new person note.
 
 Run CLI commands as `brain <command> --brain <brain> --json`. If `brain` is not found (`command not found`), install it with `npm install -g ultimate-brain`, then retry.
 
 ## Procedure
 
 1. **Check access.** The Notion connection (MCP) must reach the user's workspace. Search for the page **"Brain Data"**:
-   - **Not found:** the integration isn't connected to it. Tell the user to open Brain Data in Notion → `•••` → **Connections** → add the integration, then stop.
+   - **No Notion tools in this session:** the agent isn't connected to Notion. Give the user the steps in "Connect your agent to Notion" below for the agent they are using, and stop.
+   - **Not found:** the connection can't see the page. With the hosted Notion MCP, the user's own Notion account must have access to Brain Data; with an integration token, open Brain Data in Notion → `•••` → **Connections** → add the integration. Then stop.
    - **More than one:** ask which one.
 2. **Find the databases.** List the Brain Data page's child blocks; each `child_database` has a title. Match the titles exactly:
 
@@ -28,7 +29,8 @@ Run CLI commands as `brain <command> --brain <brain> --json`. If `brain` is not
    | Decisions | `decisions` |
    | Questions | `questions` |
    | Review | `review` |
-   | Capture Inbox | `capture_inbox` |
+   | Inbox (called Capture Inbox before 0.3.0) | `inbox` |
+   | Concepts | `concepts` |
    | Tasks | `notion.tasks.database` (below) |
 
    A missing database is reported, not invented. The brain works without it, and the skills that need it say so.
@@ -38,18 +40,44 @@ Run CLI commands as `brain <command> --brain <brain> --json`. If `brain` is not
    - **Don't fix anything in Notion.** Structure changes go through the `brain-notion-change` skill (decision 0022).
 4. **Store the ids.** For each database found, run `brain config set notion.databases.<key> '"<database id>"'`. Store the **database** id, not the data source id; skills resolve the data source when they query.
 5. **Tasks** (decision 0018):
-   - **The default Tasks database on Brain Data:** set `notion.tasks.database` to its id. The template's property mapping (Name, Status, Due, Project, Area, Meeting, Brain ID) already matches it.
-   - **The user's own tasks database:** ask which one, read its properties, and propose a mapping for `title` (required), `status`, `due`, `project`, `area`, `owner`, and either `meeting` (a relation to Meetings, preferred) or `meeting_url` (a URL property).
+   - **The default Tasks database on Brain Data:** set `notion.tasks.database` to its id. The template's mapping (Name, Status, Due, Project, Area, Meeting, Source, Brain ID) already matches it; check `notion.tasks.properties.source` is `"Source"` when the database has that relation (built from 0.3.0 on, or after migration 0005), and set it to `""` when it doesn't, so sync never writes to a missing property.
+   - **The user's own tasks database:** ask which one, read its properties, and propose a mapping for `title` (required), `status`, `due`, `project`, `area`, `owner`, either `meeting` (a relation to Meetings, preferred) or `meeting_url` (a URL property), and `source` (a relation to the Inbox, optional: the backlink for the owner's tasks from documents and emails).
      - Show the mapping and get a yes before running `brain config set notion.tasks '<json>'`.
      - Also set `new_task_status` to the status option new tasks should get.
    - **No tasks database:** leave `notion.tasks.database` empty. The ingest then lists action items in its report instead.
-6. **Verify.** Run `brain status`. `notion.configured` lists the keys you set, and `notion.tasks_database` is true when Tasks is set. Then run `brain lint`: its `brain-config` rule validates the whole file.
-7. **Commit** in the brain repo: `connect: Notion databases`.
-8. **Report:**
+6. **Your identities** (decision 0037), when `brain.json` has no `owner.person`. Ask once: "Which names and work email addresses do you appear under in meetings, documents and emails?" (for example a nickname, a work name, two email addresses). Find the owner's person note in `brain index --json` by the owner name in `brain.json` and its aliases. Then:
+   - add each name and email the note doesn't list yet as an alias, with one `add_link` proposal per value (`field: aliases`, `why` = the user's answer, `source` = an owner-ruling source as in brain-ingest references/extraction.md, "Owner rulings"); the CLI groups them into one Review row, which the user approves here in chat (brain-apply, chat mode). In a catch-up, the answer to its batch question is that approval: apply them with `decided_by: chat` without asking again;
+   - run `brain config set owner.person '"<per- id>"'`.
+   - No person note yet: create it with `brain note new` (a `person` with `title` = the owner name and the answer as `aliases`, citing the owner-ruling source), then set `owner.person`.
+7. **Verify.** Run `brain status`. `notion.configured` lists the keys you set, and `notion.tasks_database` is true when Tasks is set. Then run `brain lint`: its `brain-config` rule validates the whole file.
+8. **Commit** in the brain repo: `connect: Notion databases`.
+9. **Report:**
    - the databases connected;
    - anything missing or different from the design (step 3);
    - what to do next: build the Notion space's missing parts, or run `brain-sync` to import the rows you already created in Notion (0021), then ingest reviewed meetings.
 
+## Connect your agent to Notion
+
+The agent reads and writes Notion through a Notion MCP server (decision 0015). Give the user the steps for their agent; they run them in their own terminal, then restart the agent in the brain folder.
+
+**Hosted Notion MCP (recommended).** Notion runs it; the user signs in with their Notion account, and the agent can reach what that account can.
+- **Claude Code:** `claude mcp add --transport http notion https://mcp.notion.com/mcp`, then in Claude Code run `/mcp`, choose notion and sign in.
+- **Codex:** add to `~/.codex/config.toml`:
+  ```toml
+  [mcp_servers.notion]
+  url = "https://mcp.notion.com/mcp"
+  ```
+  then run `codex mcp login notion` and sign in.
+
+**Integration token (access limited to Brain Data).** For users who want the agent to see only the brain's pages. Notion no longer maintains this server, so prefer the hosted one.
+1. Open notion.so/profile/integrations, create an internal integration for the workspace, and copy its secret (`ntn_…`) from its Configuration tab.
+2. Open **Brain Data** → `•••` → **Connections** → add the integration. Do the same for the **How it works** page if the user wants the agent to update it.
+3. Add the server, with the secret in place of `ntn_…`:
+   - **Claude Code:** `claude mcp add notion --env NOTION_TOKEN=ntn_… -- npx -y @notionhq/notion-mcp-server`
+   - **Codex:** `codex mcp add notion --env NOTION_TOKEN=ntn_… -- npx -y @notionhq/notion-mcp-server`
+
+The secret is a password: the user types it in their own terminal, never in the chat.
+
 ## Re-running
 
 Re-running is safe. Ids that are already correct are left alone, and changed ids are updated (for example, after the user recreated a database). If an id changes for a database the brain has already published to, warn the user. The brain's notes keep their old page ids, and the next sync reports `NOTION_ID_MISMATCH` for them.

package/.agents/skills/brain-howto/references/guide.md

@@ -21,10 +21,10 @@ The navigation on the left of every page lists the Spaces. Each one has tabs tha
 | **Projects** | Keep projects moving | Active · By area · Deadlines · Gone quiet |
 | **Plan** | Check that your work serves your goals | Goals · Key results · Areas · Projects by goal |
 | **Review** | Decide on the changes the brain proposes | Needs my decision · Sources disagree · Approved recently · Rejected |
-| **Knowledge** | Find what the brain knows | Decisions · Questions · People · Orgs · Inbox |
+| **Knowledge** | Find what the brain knows, and everything that came in | Decisions · Questions · Concepts · People · Orgs · Inbox (What's in my inbox?: new captures · What came in?: everything ingested, with what it produced) |
 | **Archive** (under System) | Find finished and archived records | One tab per database |
 
-**Area pages** collect everything for one area: its goals, projects, tasks and meetings in views, and its decisions, questions, people and clients as lists at the top. Open one from Plan → Areas.
+**Area pages** collect everything for one area: its goals, projects, tasks, meetings, decisions and open questions in views, and its people and clients as lists at the top. Open one from Plan → Areas.
 
 **Project pages** show the Brief and Decision log (written by the brain), then the project's tasks, meetings, open questions and people, then your own "My notes".
 
@@ -62,20 +62,23 @@ The brain never changes what it already knows without your yes. Each proposed ch
 1. Set **Decision**:
    - **Approve** applies the change;
    - **Reject** drops it;
-   - **Edit** applies your own value. Open the row and type it in **Edited Value**.
-2. Tell your agent "apply my reviews". The change is made, and the row moves to Approved or Rejected.
+   - **Edit** applies your own value: type it in **Note**.
+2. **Note** is also for anything else you want the brain to know about that row: "all except Tomás" on a row that adds several people, or "she's the product lead, not marketing". The agent reads it, and when it describes a different change, proposes that change as a new row or asks you. It never applies something your Note didn't clearly say.
+3. Tell your agent "apply my reviews" (or "catch up"). The change is made, and the row moves to Approved or Rejected.
+
+Routine links from one input arrive as **one** row: "Acme website: add 3 people (Ana, Ben, Carla)". Approve them all, or approve with a Note saying which to leave out.
 
 | Kind | Approve means | Can you Edit? |
 |---|---|---|
 | Update Fact | The new value replaces the old one; the old one stays in the history | Yes |
 | Add To Note | The text is added to the note | Yes |
-| Add Link | A link between two records is added | No |
+| Add Link | The links listed in After are added (people to a project, an alias to a person) | No: approve with a Note to leave some out |
 | Contradiction | Two sources disagree; both claims are kept as contested | Yes: your value becomes the truth |
 | Supersede | A newer note replaces an older one, which is archived | No |
 | Merge | A duplicate is folded into the record it duplicates | No |
 | New Item | A new note is created as Draft | No |
 
-To see why a change was proposed, open the row: **Why** quotes the sentence from the source, and **Source Meeting** links to the meeting.
+To see why a change was proposed, open the row: **Why** quotes the sentence from the source, and **Source Meeting** links to the meeting when there is one.
 
 A rejected change can come back if a later meeting says the same thing again.
 
@@ -87,14 +90,15 @@ Hover over a property name to see its owner. Each description starts with "Owner
 
 | Owner | Examples | What happens when you edit it |
 |---|---|---|
-| **You** | Status, Priority, Dates, Lifecycle, Archived, Decision, Brain Status on meetings | Your value stands. The brain reads it but never overwrites it |
+| **You** | Status, Priority, Dates, Lifecycle, Archived, Decision, Note, Brain Status on meetings and captures, Project and Area on a capture | Your value stands. The brain reads it but never overwrites it |
 | **Brain** | Summary, Role, Client, Key Facts, Why, Assessment | The next sync reads your edit as a **correction**. Names, summaries and relations change in place; a key fact gets a dated history entry; judgments such as Assessment become a Review proposal |
 | **System** | Brain ID, Last Synced, Ingested At | Don't edit. The brain uses them to match records |
 
 **Page text:**
 - **Brief and Decision log** on project pages are rewritten by the brain on every sync. Anything you type inside them is lost.
 - **My notes**, and everything else on a page, is yours.
-- Decision and Question pages are written entirely by the brain.
+- Decision, Question and Concept pages are written entirely by the brain.
+- A capture's text is yours; the brain only adds its Kind, Summary and what it produced.
 
 **Lifecycle** tells you how far to trust a record:
 - **Draft:** new, not reviewed by you yet;
@@ -110,13 +114,13 @@ Set **Disputed** on anything wrong. The brain stops relying on it, and you can a
 
 | You want to add | Do this |
 |---|---|
-| A quick thought, link or idea | **Quick capture** on Home. It lands in Knowledge → Inbox. Tell your agent "process my capture inbox" |
+| A quick thought, link or idea | **Quick capture** on Home. It lands in Knowledge → Inbox. Set its **Project** if you know it, so the agent doesn't ask. Then "catch up" (or "process my inbox") |
 | A meeting | **New meeting** on Home, or let Notion AI create it when it starts taking notes |
 | A project, area, goal, person or org | Create the row in Notion (**New project** on Home for projects). The next sync imports it into the brain |
 | A document (PDF, Word, PowerPoint, Excel, saved HTML page, image) | Put it in your drop folder and tell your agent "process my drop folder". It lists the files and asks once which to take; each ingested file moves to `processed/` inside the folder, so what's left at the top is what the brain hasn't read yet. Or name one file: "ingest this PDF: ~/Documents/brain-dropbox/proposal.pdf". Word, PowerPoint, Excel and HTML files need MarkItDown installed once: `pipx install 'markitdown[all]'` |
 | A web page | Give your agent the link: "ingest this page: https://…". For a page behind a login, save it as a PDF in your drop folder instead |
-| An email, chat thread or note | Paste it into a **Quick capture** (keep the From, Date and Subject lines), then tell your agent "process my capture inbox". Or paste it straight to your agent: "ingest this email" |
-| A task | Add it in Tasks. Tasks from meetings are created for you |
+| An email, chat thread or note | Paste it into a **Quick capture** (keep the From, Date and Subject lines), then "catch up". Or paste it straight to your agent: "ingest this email" |
+| A task | Add it in Tasks. Action items from meetings, and your own from documents, emails and captures, are created for you |
 
 **Tasks:**
 - New tasks from the brain start as **To Do**.
@@ -137,7 +141,7 @@ Set **Disputed** on anything wrong. The brain stops relying on it, and you can a
 | `/Prep` (on a meeting page) | Past meetings, open questions, tasks and recent decisions for that meeting |
 | `/Weekly review` | What got done and decided, goal and project health, next week |
 | `/Plan check` | Projects without goals, goals without projects, overdue items |
-| `/Tidy capture` (on a capture page) | A cleaner version of the capture; replaces the text after you say yes |
+| `/Tidy capture` (on a new capture in the Inbox) | A cleaner version of the capture; replaces the text after you say yes |
 | "how do I …?" | An answer from this guide |
 
 Brain Assistant reads; your agent in Claude Code or Codex writes. To get something *into* the brain, use the phrases below.
@@ -150,9 +154,10 @@ Run these in Claude Code or Codex, from your brain's folder.
 
 | You want to | Say |
 |---|---|
+| Do everything that's waiting: decided reviews, reviewed meetings, new captures, the drop folder | "catch up". It asks all its questions once at the start, then finishes |
 | Get reviewed meetings into the brain | "ingest my reviewed meetings" |
 | Ingest a file, web page, email or chat | "ingest this PDF: <path>", "ingest this page: <url>", "ingest this email" (then paste it) |
-| Process quick captures | "process my capture inbox" |
+| Process quick captures | "process my inbox" |
 | Process the files in your drop folder | "process my drop folder" |
 | Apply your Review decisions | "apply my reviews" |
 | Bring Notion edits and new rows into the brain, and publish its changes | "sync with Notion" |
@@ -175,4 +180,6 @@ Run these in Claude Code or Codex, from your brain's folder.
 | A new project or person isn't in the brain | It is imported on the next sync | "sync with Notion" |
 | A rejected change came back | A later source said it again | Reject it again, or Edit it to the true value |
 | A record shows Draft | You haven't reviewed it yet | Read it; set **Reviewed**, or **Disputed** if it's wrong |
-| An Area page doesn't list a decision | Decisions reach an area through their project | Link the decision's project to the area |
+| An Area page doesn't list a decision | A decision's Area comes from its project | Link the decision's project to the area, then "sync with Notion" |
+| A Review row with a Note is still pending | The agent couldn't tell what the Note meant, or it described a different change | Answer the agent's question, or look for the new row it proposed |
+| You want to see what the brain made from a document | Every input has a row in Knowledge → Inbox → What came in? | Open the row: Decisions, Questions, Concepts and People list what it produced |

package/.agents/skills/brain-ingest/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: brain-ingest
-description: Ingest into the brain reviewed meeting minutes from Notion or a file, documents (PDF, Word, PowerPoint, Excel, HTML, images), web pages by URL, pasted emails, chat threads and notes, and the Notion Capture Inbox. Snapshots each input as a source, matches it against what the brain already knows, writes new notes (meeting, people, decisions, questions) as drafts, proposes changes to existing knowledge for your review, and creates meeting action items as Notion tasks. Use when the user says "ingest my meetings", "process the reviewed minutes", "ingest this PDF", "ingest this page <url>", "ingest this email", "process my capture inbox", "process my drop folder", or after marking meetings Reviewed.
+description: Ingest into the brain reviewed meeting minutes from Notion or a file, documents (PDF, Word, PowerPoint, Excel, HTML, images), web pages by URL, pasted emails, chat threads and notes, and the Notion Inbox. Snapshots each input as a source, matches it against what the brain already knows, writes new notes (meeting, people, decisions, questions, concepts) as drafts, proposes changes to existing knowledge for your review, and creates action items as Notion tasks. Use when the user says "ingest my meetings", "process the reviewed minutes", "ingest this PDF", "ingest this page <url>", "ingest this email", "process my inbox", "process my drop folder", or after marking meetings Reviewed.
 ---
 
 # Ingest into the brain
@@ -15,7 +15,7 @@ The rules in the brain's AGENTS.md apply throughout (if the brain has none, they
 
 - **Notion mode (default):** meetings come from the Notion Meetings database through the Notion MCP. Run it only when `brain status` shows `notion.configured` includes `meetings`.
 - **Markdown-only mode:** the user gives a minutes file (or pastes the text) plus the meeting's title, date and, if known, project. Skip every step marked *(Notion)*. Use this mode when Notion is not configured or the user asks for it.
-- **Other sources:** a document file, the drop folder, a pasted email, chat thread or note, or the Capture Inbox. Follow [references/sources.md](references/sources.md) instead of the procedure below; it says which of these steps still apply.
+- **Other sources:** a document file, the drop folder, a pasted email, chat thread or note, or the Inbox. Follow [references/sources.md](references/sources.md) instead of the procedure below; it says which of these steps still apply.
 
 ## Procedure (per meeting)
 
@@ -76,16 +76,16 @@ The rules in the brain's AGENTS.md apply throughout (if the brain has none, they
 
 9. **Rebuild and check.** Run `brain index`, `brain views`, then `brain lint`. If lint reports an **error in a file this run wrote**, stop: report it and do not commit. Errors that were already there before the run are not yours to fix here; mention them.
 
-10. **Log and commit.** Run `brain log ingest <mtg-id> created=<n> proposals=<n> tasks=<n>`. Commit in the brain repo: `ingest: <meeting title> <date> (<n> new, <n> proposals)`. If this run does not publish, push now (below); otherwise push after the publish commit in step 11.
+10. **Log and commit.** Run `brain log ingest <mtg-id> created=<n> proposals=<n> tasks=<n>`. Commit in the brain repo: `ingest: <meeting title> <date> (<n> new, <n> proposals)`. If this run does not publish, push now (step 11, "Push"); otherwise push after the publish commit.
 
-11. **Publish** *(Notion)*, following [references/notion.md](references/notion.md):
+11. **Publish** *(Notion, per `settings.publish`: with `ask`, ask once before this step)*, following [references/notion.md](references/notion.md):
     - create the action items as tasks (`brain sync tasks` → MCP → `brain sync record`);
     - publish new and changed notes and the new proposals (`brain sync render --changed` → MCP → `brain sync record`);
     - this sets the meeting's relations, Brain Status = Ingested and Ingested At, and never touches its title or body (decision 0007).
 
     Then commit again: `publish: <meeting title> <date>`.
 
-    **Push** after the run's last commit: `git push`. If the push fails, say so in the report's last line and carry on (decision 0038).
+    **Push** after the run's last commit, per `settings.push` (the brain's AGENTS.md, "Write path").
 
 12. **Report** in three lines (decision 0037), once per run however many inputs it took:
     ```
@@ -95,7 +95,7 @@ The rules in the brain's AGENTS.md apply throughout (if the brain has none, they
     ```
     - **Done:** counts only, and only the ones that aren't zero.
     - **Needs you:** everything waiting on the user, separated by `·`: proposals to decide and where (the Review queue, or "approve in chat"), what was skipped or failed and why in a few words, lint errors that were there before the run, an instruction found in a source and ignored, action items with no task. `Needs you: nothing` when there is none.
-    - **Next:** one action, or one question when the user must decide something. Without Notion, the next action is a sync ("sync with Notion" publishes the new notes and proposals).
+    - **Next:** one action, or one question when the user must decide something. Without Notion, the next action is deciding the proposals in chat ("what needs my decision"), or connecting Notion ("connect the brain to Notion"), after which a sync publishes everything.
 
     **Below the three lines, the report grows with what came in** (decision 0037, amended 2026-10-18). A run that only moved counts stops at three lines. Otherwise add, per input, one line each, and leave nothing out because the list is long:
     - **What came in:** every new project, decision (with its assessment), open question and risk, every fact that changed (old → new), and new people with their role. A one-line summary of what a document or thread is about comes first.

package/.agents/skills/brain-ingest/references/cli-inputs.md

@@ -45,6 +45,7 @@ A document, a web page, then a pasted email:
 - **`file_name`** (the name only, no folder) and **`converter`** (`claude-read <model id>`, `codex-view-image <model id>`, or `markitdown <version>`) are required with a `file:` key.
 - **Web page** (0036): `source_key` is `url:<the https URL as given>`; `kind` `document` and `converter` (`markitdown <version>` or `web-fetch <model id>`) are required; no `file_name`.
 - **Capture:** `source_key` is `notion:<row page id>`, `kind` is `capture`, `origin_edited` is the row's `last_edited_time`.
+- **`summary`** (every kind except minutes, added in the real run of step 6, not the step 3 dry run): one line on what the source taught. It is the Inbox row's Summary.
 - **Title:** `<title> (<kind>)`; for a web page, `<title>` is the page's own title. **`file_date`:** the text's own date (a document's date, a web page's stated publication or update date, an email's sent date); for a capture, the row's Created date; else today.
 - **Dates in the notes:** a new note's timeline `from` is the date the text gives, else the source's `file_date`; `learned` is always today (the day the brain learned it).
 - **Duplicates:** the CLI also skips a source whose `file:` key, or whose `capture` row, was already ingested, even if the text differs.
@@ -95,8 +96,8 @@ Things the CLI checks that are easy to get wrong:
 ] }
 ```
 
-- **Don't send `before`;** the CLI fills it from the current fact. **`from`:** leave it out for a meeting (the CLI uses the meeting's date). For any other source, send it: the date the text gives for the change ("approved on 5 December 2026" → `2026-12-05`), else the source's `file_date`; otherwise the CLI would use today.
-- **`add_link`** (decision 0028) adds one value to a list of an existing note:
+- **Don't send `before`;** the CLI fills it from the current fact. **`from`** (only `update_fact` and `contradiction` have one): leave it out for a meeting (the CLI uses the meeting's date). For any other source, send it: the date the text gives for the change ("approved on 5 December 2026" → `2026-12-05`), else the source's `file_date`; otherwise the CLI would use today.
+- **`add_link`** (decision 0028) adds one value to a list of an existing note. Send one item per link, each with its own `title` and `why`: the CLI groups the items with the same `target` and `source` into one proposal, one Review row (decision 0037), and writes the group's title itself:
   ```json
   { "kind": "add_link", "title": "Acme website: add Lucía Fernández to People", "target": "prj-9x4t1b7e", "field": "people",
     "after": "per-zzvs98vn", "why": "Lucía Fernández (Acme, marketing lead)", "source": "mtg-pcpyn31n" }
@@ -114,6 +115,8 @@ Things the CLI checks that are easy to get wrong:
 
 ## 4. Action items (Notion mode)
 
+From a meeting:
+
 ```json
 { "items": [
   { "title": "Set up the Contentful space", "owner": "Carlos Ruiz", "due": "2026-12-17", "projects": ["prj-9x4t1b7e"] },
@@ -123,6 +126,16 @@ Things the CLI checks that are easy to get wrong:
 
 `brain sync tasks --meeting mtg-pcpyn31n --input <file>` turns these into Notion payloads using the Tasks mapping in `brain.json`. Leave out `due` when the minutes say "no date". `projects` is the project ids the task is about; leave it out when the task is about the meeting's own project(s), and the meeting's projects are used.
 
+From any other source, the owner's tasks only ([extraction.md](extraction.md), "Tasks for the owner"); no `owner`:
+
+```json
+{ "items": [
+  { "title": "Send Carlos the migration plan", "due": "2026-12-05", "projects": ["prj-9x4t1b7e"] }
+] }
+```
+
+`brain sync tasks --source src-5t8n2v6q --input <file>`. A task with no `projects` gets no project. Its backlink is the source's Inbox row: until that row is published, the item lists it in `pending_relations`, so publish the source first ([notion.md](notion.md), "Publish").
+
 ## 5. Log line
 
 ```sh

package/.agents/skills/brain-ingest/references/extraction.md

@@ -4,7 +4,7 @@ How to read one meeting's minutes and decide what becomes a note, what becomes a
 
 ## Who is who
 
-- **The owner:** "I", "me" and descriptions of the owner's role in the minutes ("the new team member" when that is the owner) mean the owner in `brain.json`. Link them to the owner's person note; if there is none, create it in the batch with `title` = the owner name in `brain.json`. Keep the wording verbatim in quoted facts.
+- **The owner:** "I", "me", descriptions of the owner's role ("the new team member" when that is the owner), and every name or work email in the `aliases` of the owner's person note (`owner.person` in `brain.json`, decision 0037) mean the owner. A From line or signature with one of them is the owner. Link them to that person note; if there is none, create it in the batch with `title` = the owner name in `brain.json`. Keep the wording verbatim in quoted facts.
 - **Mentioned people** (named, not attendees) get a person note only when they own a system, deliverable or decision named in the minutes, or have an action item. Otherwise their name stays in the text, with no note.
 - **Projects are per item.** A meeting may touch several projects: set `projects` on each decision and question from what that item is about, and list every one on the meeting. Ask only when an item could belong to two. Action items too: give each its `projects` in the `sync tasks` input ([cli-inputs.md](cli-inputs.md) §4); left out, a task gets the meeting's projects.
 
@@ -32,12 +32,19 @@ Minutes follow the table above. For other sources (references/sources.md) there
 
 | Kind | What it usually yields | Different from minutes |
 |---|---|---|
-| `document` (brief, contract, report, deck) | Facts and their changes, decisions the document records, people with roles, open questions and risks | A decision's `date` is the date the document gives for it, else the document's date. When the document is about a project, propose one `add_to_note` on the project: what the document is, in 1–2 sentences, with a link to the source (relative to the project note). No action items unless the document assigns them |
+| `document` (brief, contract, report, deck) | Facts and their changes, decisions the document records, people with roles, open questions and risks | A decision's `date` is the date the document gives for it, else the document's date. When the document is about a project, propose one `add_to_note` on the project: what the document is, in 1–2 sentences, with a link to the source (relative to the project note). Action items only where the document assigns them |
 | `email`, `chat` | Decisions and facts stated in the thread, people, questions | Who said what matters: attribute a decision to its sender (`deciders`) only when the thread shows they decided. A thread that reports a decision made elsewhere ("the launch moves to March") still yields the decision note if it passes the gate. A quoted earlier message is part of the thread, not a new statement |
 | `note` | Whatever the user wrote: facts, ideas, people | The user's own words: no `^[ambiguous]` against the user's other notes; a disagreement with the brain is a `contradiction` |
-| `capture` | Usually one thing: a fact, an idea, a person, a to-do | A fact about an existing note → `update_fact`; an idea or method → a `concept` note (`summary`, `sources`, and `area`, `projects` or `tags` when the capture says what it belongs to); a new person → a person note; a to-do → listed in the report only. Nothing durable is a valid result. **A capture holding a pasted email or chat thread** is analysed with the `email`/`chat` row instead (sources.md) |
+| `capture` | Usually one thing: a fact, an idea, a person, a to-do | A fact about an existing note → `update_fact`; an idea or method → a `concept` note (`summary`, `sources`, and `area`, `projects` or `tags` when the capture says what it belongs to); a new person → a person note; the owner's own to-do → a task (below). Nothing durable is a valid result. **A capture holding a pasted email or chat thread** is analysed with the `email`/`chat` row instead (sources.md) |
 
-Action items found in any of these are listed in the report, not created as tasks (there is no meeting to attach them to).
+### Tasks for the owner (decision 0037)
+
+In these sources, an action item becomes a Notion **task** only when it is addressed to the **owner**: "can you send me the plan by Friday" in an email to the owner, "I need to book the venue" in the owner's capture. Each task:
+- `title`: the action, as an imperative ("Send Carlos the migration plan");
+- `due`: only when the text gives a date or a day you can date from the source ("by Friday" in an email sent on 2026-12-03 → `2026-12-05`); otherwise leave it out. Never a default;
+- `projects`: the projects the action is about, or the capture row's Project; else none.
+
+They go to `brain sync tasks --source` ([cli-inputs.md](cli-inputs.md) §4). Action items for other people stay in the note text, and the report lists them.
 
 ## Owner rulings (decision 0031)
 

package/.agents/skills/brain-ingest/references/notion.md

@@ -44,17 +44,17 @@ Do these in order, after the ingest commit.
 **Write in parallel** (decision 0037). Within each step, send the writes that don't depend on each other as parallel tool calls in one turn, up to 10 at a time (Notion limits the request rate). Don't read a page back after writing it: the write's response holds its id. Read a page only when the write needs its current content, such as a project's blocks before a section is replaced.
 
 1. **Tasks.** If `brain status` shows `tasks_database: true`:
-   1. Run `brain sync tasks --meeting <mtg-id> --input <items.json>`.
-   2. Create one Notion page per returned item **without** `pending_relations`, in its `database_id` with its `properties`. An item with `pending_relations` names a project not yet in Notion: **don't create it yet**. After step 2 has published and recorded that project, run `sync tasks` again with only those items, and create each once. An `owner` of type `person_name` is written as text, or resolved to a Notion user if the mapped property is a people property.
-   3. Run `brain sync record` with `{ "records": [ { "id": "<mtg-id>", "synced_at": "<now, ISO 8601 UTC>", "tasks": ["<new task page id>", …] } ] }`. `synced_at` is required on every record (spec/cli.md §5.14.6).
+   1. Run `brain sync tasks --meeting <mtg-id> --input <items.json>`, or `--source <src-id>` for the owner's tasks from any other source.
+   2. Create one Notion page per returned item **without** `pending_relations`, in its `database_id` with its `properties`. An item with `pending_relations` names a page not yet in Notion (a project, or the source's own Inbox row): **don't create it yet**. After step 2 has published and recorded it, run `sync tasks` again with only those items, and create each once. An `owner` of type `person_name` is written as text, or resolved to a Notion user if the mapped property is a people property.
+   3. Run `brain sync record` with `{ "records": [ { "id": "<mtg-id or src-id>", "synced_at": "<now, ISO 8601 UTC>", "tasks": ["<new task page id>", …] } ] }`. `synced_at` is required on every record (spec/cli.md §5.14.6).
 2. **Notes, meeting and proposals:**
    1. Run `brain sync render --changed`.
    2. For each item:
       - **`action: create`:** create a page in `database_id` with `properties`.
       - **`action: update`:** update `page_id` with `properties`.
-      - **Meeting relations with `"mode": "add"`:** add the listed pages and keep the existing ones.
+      - **Meeting and Inbox relations with `"mode": "add"`:** add the listed pages and keep the existing ones.
       - **`"mode": "if_empty"`:** write only if the property is empty in Notion.
-      - **`body` (decisions, questions):** replace the page body with it.
+      - **`body` (decisions, questions, concepts):** replace the page body with it. An Inbox item (a source) has no body; a capture's page body is the user's.
       - **`sections` (projects):** replace only the children of the toggle heading with that exact name ("Brief", "Decision log"). Read the page's blocks first (decision 0033):
       - **the page has no toggle headings at all** (created without the template): append a "Brief" and a "Decision log" toggle heading, in that order, at the end of the page, then fill them;
       - **the page has other toggle headings but not this one:** report `SECTION_NOT_FOUND` for that page and change nothing on it (a rename is likely, 0026).