ultimate-brain 0.4.0 → 0.5.0

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

@@ -1,11 +1,11 @@
 ---
 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 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.
+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 fixes, or reads the calls and What to fix texts 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
 
-Proposals are changes the brain wants to make to existing notes (decision 0003). The user decides each one: approve, reject, or edit (edit means approve, but with the user's own value). This skill records those decisions and applies them through the CLI. Only the user decides. Never approve, reject or edit on their behalf, and never infer a decision from the minutes or from earlier chat.
+Proposals are changes the brain wants to make to existing notes (decision 0003). The user decides each one: **Approve**, **Reject**, or **Fix** (apply it, corrected as the user says in plain words; decision 0045). This skill records those decisions and applies them through the CLI. Only the user decides. Never approve, reject or fix on their behalf, and never infer a decision from the minutes or from earlier chat.
 
 Run every CLI command as `brain <command> --brain <brain> --json`. Exit 1 means some items need attention; read them. Exit 2 or 4 means your command or input was wrong: fix it. Exit 3 or 5 means stop and report. Exit 10: report a bug. If `brain` is not found (`command not found`), install it with `npm install -g ultimate-brain`, then retry.
 
@@ -22,24 +22,26 @@ Run every CLI command as `brain <command> --brain <brain> --json`. Exit 1 means
    `3. Acme website: budget 80000 EUR → 95000 EUR. "Budget raised to 95000 EUR to cover the CMS licence." (Acme launch review, 10 Dec)`
    For each kind:
    - `update_fact`: old → new value.
-   - `contradiction`: both values, and say approving keeps both as contested, while editing picks the true one.
+   - `contradiction`: both values, and say approving keeps both as contested, while a fix picks the true one.
    - `add_to_note`: the text to add.
+   - `update_body` (decision 0045): the reference note and the lines that change, `-` old and `+` new.
    - `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.
-   - `review_notes` (decisions 0041, 0043): the new notes and routine links of one input, lettered as the Review row's After letters them: notes first, then links. "Accept 6 new notes from Acme launch review, and 2 links: a) Decision: Use Contentful as the blog CMS, b) Question: …, g) People on Acme website: Lucía Fernández, h) Aliases on Maria López: Mari López". Approving makes the notes `reviewed` and applies the links; rejecting archives the notes still `draft` and closes the links.
+   - `review_notes` (decisions 0041, 0043, 0045): everything one input proposes, lettered as the Review row's Proposed letters them: the **changes** first (every fact change marked ⚠, a new fact as `(new) → <value>`; then new text for a reference; then text added to a note), then the new **notes**, then the **links**. "From Acme launch review: a) ⚠ Launch date on Acme website: 2027-02 → 2027-03, b) Add to Row-level security: Carlos will use RLS…, c) Decision: Use Contentful as the blog CMS, …, h) People on Acme website: Lucía Fernández". End the line with the source and date ("(Acme sync, 3 Dec)"), with no quote: each item has its own `why`, shown when the user asks. Approving applies the changes, makes the notes `reviewed` and applies the links; rejecting archives the notes still `draft` and applies nothing.
    - `answer`: the question and its answer, and the note that answers it: "Who owns the mobile app? → Carlos Ruiz owns it (decision: Carlos owns the mobile app)". Approving closes the question; it shows as Answered in Notion.
 
    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`, `add_to_note` and `answer` (the user's text becomes the answer); say so if the user asks to edit another kind. On a grouped `add_link` or a `review_notes`, "approve 5 except b" approves it with those items excluded. **If a reply is unclear, ask again.** Don't guess.
+3. **Ask** which to approve, reject or fix. Accept replies like "approve 1 and 3, reject 2, fix 4: 90000 EUR", "approve 5 except b" or "fix 5: a is March, c belongs to Acme app". Fix works on every kind: read the user's words into `fixes` as "Reading What to fix" below says. On a grouped `add_link` or a `review_notes`, "except b" leaves those items out: on a `review_notes` they move to a new pending row (deferred, not rejected). When a reply names a row by its source and two rows share it, the letter or title only one of them has settles it; otherwise ask. **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": "fix", "note": "90000 EUR", "fixes": [ { "value": "90000 EUR" } ], "decided_at": "<now>", "decided_by": "chat" },
      { "proposal": "prp-…", "action": "approve", "exclude": [ { "field": "people", "value": "per-…" } ], "decided_at": "<now>", "decided_by": "chat" },
-     { "proposal": "prp-…", "action": "approve", "note": "all except b, h", "exclude": [ { "note": "que-…" }, { "target": "per-…", "field": "aliases", "value": "Mari López" } ], "decided_at": "<now>", "decided_by": "chat" }
+     { "proposal": "prp-…", "action": "approve", "note": "all except a, h", "exclude": [ { "change": 0 }, { "target": "per-…", "field": "aliases", "value": "Mari López" } ], "decided_at": "<now>", "decided_by": "chat" },
+     { "proposal": "prp-…", "action": "fix", "note": "a is March", "fixes": [ { "change": 0, "value": "2027-03" } ], "decided_at": "<now>", "decided_by": "chat" }
    ] }
    ```
    To apply only what was decided earlier, run `brain apply` with no `--input`.
@@ -47,22 +49,32 @@ Run every CLI command as `brain <command> --brain <brain> --json`. Exit 1 means
 
 ## Notion mode
 
-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:
+1. **Read** the Review database through the Notion MCP: the rows where **Your call** 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, Note, State and Brain ID.
+   - the properties Name, Kind, Your call, What to fix, State and Brain ID. A space not yet migrated (migration 0009) still has Decision and Note: send them under those names, and the CLI reads them the same way, Edit as Fix.
 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`: `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 or a Review notes row: suggest Approve or Reject, with a Note);
+   - `conflicts`: `NOTE_TO_READ` is an Approve or Reject with text in What to fix, and `FIX_TO_READ` a Fix with its text: read each as "Reading What to fix" below says. `FIX_WITHOUT_TEXT` is a Fix with What to fix empty: the user says what's wrong in Notion (or here);
    - `ignored`: e.g. `ALREADY_TERMINAL`. Nothing to do.
-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).
+3. **Apply.** Run `brain sync apply --input <plan file>`, adding `--record-only` when unattended. Then apply the decisions you resolved from What to fix with `brain apply --input <file>` (unattended: leave `NOTE_TO_READ` and `FIX_TO_READ` rows for an attended run).
 4. Continue with **Finish** below.
 
-## Reading a Note
+## Reading What to fix
 
-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`). "All except b, e" on a **Review notes** row → `approve` with one `exclude` entry per letter, counted as the row's After letters them: `notes` first, in order, as `{ "note": "<id>" }`, then `links`, in order, as `{ "target", "field", "value" }`. Read the letters against the proposal's own `notes` and `links` (`brain proposal list --target <a note id>`), never against what you remember of the row. A letter the row doesn't have → ask. A Note naming a note by title ("all except the risk") works the same way. "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.
+What to fix is the user's instruction for that one row, in plain words (decisions 0037, 0045). The CLI never interprets it; you do, and you **never apply a change the text doesn't clearly ask for**. Read the letters against the proposal itself (`brain proposal list --target <a note id>`, then its `changes`, `notes` and `links`), never against what you remember of the row. Letters run over the items in the order of spec/schema.md §11.3: every entry of `changes` (as stored), then `notes`, then `links`; `a` is `{ "change": 0 }` when the row has changes. A letter the row doesn't have → ask. A title works like a letter ("all except the risk"). Every decision you write carries `note` = the text as written, `decided_at` = the row's `last_edited`, `decided_by: notion` (in chat: now and `chat`).
+
+- **Approve with a narrower scope** ("all except b, e", "only Ana"): `approve` with one `exclude` entry per item left out: `{ "change": <index> }`, `{ "note": "<id>" }` or `{ "target", "field", "value" }` on a Review notes row, `{ "field", "value" }` from `links` on an `add_link` row. On a Review notes row the excluded items move to a new pending row; say so in the report.
+- **Fix** (Your call is Fix, or an Approve whose text corrects a value: "yes, but it's March"): `fix` with `fixes`, by kind (spec/schema.md §11.3):
+  - a fact, a contradiction, text to add, a reference's new text or an answer: one `{ "value": … }`, the corrected value or text. For a fact, write the value in the shape the fact has (`2027-03`, not "March");
+  - a supersede or merge: one `{ "value": "<id>" }`, the note it should be instead;
+  - a possible new note: `{ "field": "title" | <a frontmatter key>, "value": … }`;
+  - an add_link row: `{ "link": { "field", "value" }, "value": <the corrected value> }`;
+  - a Review notes row: `{ "change": <index>, "value": … }` for a change ("a: March"), `{ "note": "<id>", "field", "value" }` for a new note ("c belongs to Acme app" → `field: projects`, `value: ["prj-…"]`; a title, summary or area works the same way), `{ "link": { "target", "field", "value" }, "value": … }` for a link ("Lucía is on Acme website, not Acme app").
+
+  A fix and an "except" can come together ("all except b, and a is March"): `fix` with both `fixes` and `exclude`, never on the same item. Names become ids through `brain index --json`; a name that matches no note, or two → ask.
+- **Reject with a reason** ("wrong meeting"): `reject`; the reason is kept in `note`.
+- **A different change** (a role typed on a link row, a fact about another note) → apply this row as Your call says, and write the other change as its own proposal with `brain proposal new` (`why` = the text, `source` = the proposal's `source`), so it gets its own Review row.
+- **Unclear** → ask the user, quoting the text, 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.
 
@@ -73,8 +85,8 @@ In a catch-up these are decided in its read-only pass and confirmed in its one b
    - **`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.
-   - **`review_notes` items** also list `notes`, one result each: `reviewed`, `archived` (rejected), `kept_draft` (excluded) and `unchanged` (no longer `draft` when applied: the user changed its Lifecycle in Notion). Name the `kept_draft` and `unchanged` notes once, under Check.
-   - **`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 or note the row doesn't have: re-read the Note. `UNKNOWN_ID` means the proposal or its note is gone.
+   - **`review_notes` items** also list `notes`, one result each: `reviewed`, `archived` (rejected), `kept_draft` (excluded) and `unchanged` (no longer `draft` when applied: the user changed its Lifecycle in Notion). An applied one lists `changes`, each `applied`, `dropped` (`STALE_PROPOSAL`: its note changed since the row was written, so only that item was closed) or `deferred` (excluded), and `deferred`: the new pending row that holds the excluded items. Name the `kept_draft`, `unchanged`, dropped and deferred items once, under Check.
+   - **`failed`:** report the `reason` and `message`. `INVALID_RESULT` means applying it would break a rule, such as a value of the wrong shape. `FIX_UNKNOWN` means a fix named an item the row doesn't have, and `EXCLUDE_UNKNOWN` the same for an "except": re-read What to fix against the proposal. `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, 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:
@@ -84,8 +96,8 @@ In a catch-up these are decided in its read-only pass and confirmed in its one b
 5. **Report** in three lines (decision 0037):
    ```
    Done: 8 applied · 1 closed (stale) · 12 pages published
-   Needs you: 1 failed (EDIT_NOT_ALLOWED on "add Ivo to Acme rollout") · 2 rows still pending
-   Next: fix that row in Notion, then "apply my reviews"
+   Needs you: 1 failed ("all except k" on Acme launch review: the row has no k) · 2 rows still pending
+   Next: say which item you meant, here or in What to fix
    ```
    - **Done:** counts only, and only the ones that aren't zero.
    - **Needs you:** what failed and why in a few words, a stale proposal with the note's current value, what is still pending. `Needs you: nothing` when there is none.
@@ -93,12 +105,13 @@ In a catch-up these are decided in its read-only pass and confirmed in its one b
 
    **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", "6 notes from Acme launch review accepted", "Who owns the mobile app? answered: Carlos Ruiz").
-   - **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.
+   - **Fixes:** every correction you read and applied, repeated back with its letter and row ("Acme launch review, a: launch set to 2027-03, not 2027-02"; "c: Use Contentful now belongs to Acme app"), so the user can check you read them right.
+   - **Check:** each item or proposal closed as stale, with the note's current value; each deferred row, with what it holds; each failure with its reason in a few words; each What to fix the user should look at again; each change proposed from What to fix. 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.
 
 ## Don'ts
 
 - **Don't apply anything the user didn't decide in this chat or in Notion.**
-- **Don't edit notes directly** to "help" a proposal along. If a proposal is wrong, the user rejects it.
+- **Don't edit notes directly** to "help" a proposal along. If a proposal is wrong, the user rejects or fixes it.
 - **Don't re-run `apply` after a failure** without changing the input. Apply is atomic per item, and the failed item is unchanged; fix the cause first.

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

@@ -1,6 +1,6 @@
 ---
 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, their attachments, the drop folder and linked repos, writes the reports asked for on Ask rows and the full texts asked for on Inbox rows, 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".
+description: Do everything that is waiting in one run. Pulls the user's Notion edits, applies the reviews they decided (Fix included), ingests reviewed meetings, Inbox rows that are Ready, their attachments, the drop folder and linked repos, reads again the inputs the user corrected, writes and refreshes the reports asked for on Ask and Report rows and the full texts asked for on Inbox rows, 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
@@ -9,7 +9,7 @@ One run for everything waiting (decision 0037). It has two halves: a **read-only
 
 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, attachments, the drop folder, linked repos), brain-query (reports). Their rules apply unchanged, including the trust rules in the brain's AGENTS.md.
 
-**The bar** (decision 0043): over two meetings and one capture, from "go" to the report in under 5 minutes, without the session running out of context. So each input is analysed in its own sub-agent (step 3), Notion is written in one batch at the end (step 4), and nothing already in Notion is written twice.
+**The bar** (decision 0043): over two meetings and one capture, from "go" to the report in under 5 minutes, without the session running out of context. So each input is analysed in its own sub-agent (step 3), Notion is written in one batch at the end (step 4), and nothing already in Notion is written twice. Note the time when the user says "catch up" (or the run starts), and count the notes whose full text the run and its sub-agents read: the run logs both at the end (decision 0045).
 
 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.
 
@@ -18,17 +18,19 @@ Run every CLI command as `brain <command> --brain <brain> --json`. If `brain` is
 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), whichever are configured, plus the **Inbox rows whose Full text box is ticked** (with their Full text and Brain ID properties only); run `sync plan` once, save `plan.json`. It holds the imports, your corrections, the decided Review rows, the conflicts, and `full_text_requests`: one per ticked box on a source the brain wrote.
-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. A row with Kind = **Ask** is a request for a report, not a capture: never ingest it; note its question (the Name) and its Project or Area for the report ("Run", step 6). A capture that repeats a source the brain already has: default skip, naming that source and linking its row (sources.md, "Pre-check").
-   **Attachments** on the New rows and the Reviewed meetings: list each file (sources.md, "Attachments"), all selected by default.
-6. **Drop folder.** The queue and its question (sources.md, "The drop folder", steps 1–2), without moving anything.
+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, References, Review; never Meetings), whichever are configured, plus the **Inbox rows whose Full text box is ticked** and the **Report rows with Refresh ticked or a What to fix**, with only the properties brain-sync step 2 names; run `sync plan` once, save `plan.json`. It holds the imports, your corrections, the decided Review rows, the conflicts, `full_text_requests` (one per ticked box on a source the brain wrote), `refresh_requests` and `report_fixes`.
+3. **What to fix on Review rows.** For each `NOTE_TO_READ` and `FIX_TO_READ` conflict, read What to fix against its proposal and decide what it means (brain-apply, "Reading What to fix"). Write down the decision you would apply ("a: launch 2027-03"), or the question it raises. A `FIX_WITHOUT_TEXT` row goes in the batch as a question: "Acme launch review: Fix, but What to fix is empty: what's wrong?"
+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. A meeting the brain already ingested and that is Reviewed again is a **re-read** (decision 0045): the user fixed its minutes; say so in the batch ("Acme sync, read again: only what changed"). Minutes files are ingested only when the user names them, never looked for.
+5. **Inbox.** The rows **ready to take in** (brain-ingest references/sources.md, "capture"; decision 0045): Brain Status **Ready**, and captures still **New** a day or more after they were created. Never a Skipped row, nor a New document, email, chat or note row: those wait for Ready. Oldest first, each with its pre-check blockers. A Ready row with a Brain ID is a **re-read**, as for meetings. A row with Project or Area set needs no project question. A document's empty **Keep** goes in the batch: "Acme requirements (document): what do you want from it? all / just …" (default all). A capture that repeats a source the brain already has: default skip, naming that source and linking its row (sources.md, "Pre-check").
+   **Ask rows** (Kind = Ask, Brain Status New) are requests for a report, not captures, and need no Ready: never ingest one; note its question (the Name), its Project or Area and its **Refresh report** relation, if set, for the report ("Run", step 6).
+   **Attachments** on the rows taken in and the Reviewed meetings: list each file (sources.md, "Attachments"), all selected by default, each with its row's Keep.
+6. **Drop folder.** The queue and its question (sources.md, "The drop folder", steps 1–2: what to keep from each file, and whether one is a new version), without moving anything.
 7. **Linked repos.** For each entry of `repos` in `brain status`: `brain repo changes <name>` (sources.md, "Linked repos"). A repo with `found: false` is named on the Needs you line. More than 10 files: they go in the batch as a list, default all.
 8. **The full-text choice.** For each input that will get its own Inbox row (not a capture, an attachment or minutes), the default by kind: emails and chats full, documents and decks digest. Without an Inbox database (`inbox` missing), there is no row: leave the choice out of the batch, and the CLI's default stands for a later publish.
-9. **The backlog.** `brain proposal backlog --dry-run`: the Review notes rows the run will write once for notes from before 0.4.0. They need no question; name them in the batch's opening line ("I'll also write 2 Review notes rows for older notes").
-10. **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).
-11. **Your identities.** If `brain.json` has no `owner.person`, add the identities question (brain-connect-notion, step 6).
+9. **Reports.** From `plan.json`: each `refresh_requests` item, and each `report_fixes` item with the proposals its text would become (brain-query, "What to fix on a report"), written down like a Review row's What to fix. Also each report whose last `fixes` entry lists only proposals now applied, rejected or closed, and that wasn't refreshed since: it is due a refresh.
+10. **The backlog.** `brain proposal backlog --dry-run`: the Review notes rows the run will write once for notes from before 0.4.0. They need no question; name them in the batch's opening line ("I'll also write 2 Review notes rows for older notes").
+11. **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).
+12. **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.
 
@@ -36,13 +38,14 @@ The pass is done when every input that is waiting has been found and each of its
 
 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 What to fix you read, as "Acme sync: 'all except b' → approve the rest, b waits in a row of its own" or "Acme sync: Fix 'a: March' → launch date 2027-03";
 - 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;
 - each attachment, all selected, and each linked repo's files when there are more than 10;
 - the full-text choice, one line per input that gets an Inbox row, saying what it puts in Notion: "4. Requirements doc (40 p) → **digest**: Notion gets a summary and key points; to read the document itself you open the file. Say "4 full" to have the whole text in Notion." Parts work too: "5 full, slides 3–9";
-- each Ask row, as "Report on <its question> (default: yes)";
+- each document's Keep, when its row's Keep is empty (default all), and each likely new version (default yes);
+- each Ask row, as "Report on <its question> (default: yes)", or "Refresh <report> for <its question>" when its Refresh report is set; each Report row to refresh, and each report What to fix with the proposals it becomes ("Acme launch report: 'Lucía left Acme in June' → Lucía's org: Acme → none, from June");
 - 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` and Notion configured: "Publish to Notion at the end?" (default yes). This is the run's only publish question. Without Notion there is nothing to publish: leave it out.
 
@@ -51,29 +54,34 @@ When nothing blocks, don't ask: say what you will do in one line and start. When
 ## 3. Run, in this order
 
 0. **The backlog, once** (decision 0041): `brain proposal backlog`. On a brain from before 0.4.0, the first run writes one Review notes row per source over its `draft` notes; every later run writes nothing. Commit any rows it wrote: `review: <n> Review notes rows for the backlog`.
-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.
+1. **Pull and apply.** `brain sync apply --input plan.json` (brain-sync steps 6–8), then with `brain apply --input <file>`: the decisions you resolved from What to fix (brain-apply, "Reading What to fix"), 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 '"<per- id>"'`. Rebuild and commit as brain-apply "Finish", steps 1–3. Conflicts the user didn't answer stay conflicts.
 2. **Full texts asked for:** `brain source full-text <source> [--parts …]` for each of `plan.json`'s `full_text_requests`, and for each "full text for …" the user asked in chat. Commit: `full-text: <n> sources`.
-3. **Analyse each input in its own sub-agent** (decision 0043): each meeting, Inbox row (with its attachments) and chosen file. A run with one input, or inputs of a page or two each, can analyse them inline instead, one at a time: the sub-agents are there to keep long inputs out of the run's context. Inline is also the way when the session can't start sub-agents. Give each one the brain path, the input (or how to read it), its batch answers and the brain-ingest skill with its references, and have it run, read-only, brain-ingest steps 4–6 and the dry runs of step 7, then return the `note new` batch, the `proposal new` batch (with the input's one `review_notes` and any `answer`), the task items and the report lines. A sub-agent never runs a write, a commit or a Notion call. Run up to 4 at a time.
+3. **Analyse each input in its own sub-agent** (decision 0043): each meeting, Inbox row (with its attachments) and chosen file. A run with one input, or inputs of a page or two each, can analyse them inline instead, one at a time: the sub-agents are there to keep long inputs out of the run's context. Inline is also the way when the session can't start sub-agents. Give each one the brain path, the input (or how to read it), its batch answers and the brain-ingest skill with its references, and have it run, read-only, brain-ingest steps 4–6 and the dry runs of step 7, then return the `note new` batch, the `proposal new` batch (with the input's one `review_notes` and any `answer`), the task items and the report lines. A sub-agent never runs a write, a commit or a Notion call. Run up to 4 at a time. A **re-read** is analysed inline in step 4 instead: its diff needs the new source written first (brain-ingest references/sources.md, "Re-reads and new versions"), and the changed lines are short.
 4. **Write them, one input at a time,** in the order of step 1 (meetings oldest first, then Inbox rows, then files): before each batch, check its new notes against what the inputs before it wrote (`brain index`): a person, project or concept another input already created is linked to that note instead of created twice. Then brain-ingest steps 7.3–10 (the real `note new`, `proposal new`, rebuild, check, log, commit). On `INPUT_INVALID` from a path that changed since the dry run, run the dry run again and fix the links.
 5. **Linked repos:** their files are inputs of steps 3–4 too; after a repo's last file, `brain repo record`, unless a file failed or the user wants some later (sources.md, "Linked repos", step 4).
-6. **Reports:** for each Ask row the user didn't decline, brain-query "Report mode" with `asked_in` = the row's page id, its Project and Area. Commit: `report: <title>`.
+6. **Reports,** with brain-query "Report mode":
+   1. each report What to fix: its proposals and `brain report fix` (brain-query, "What to fix on a report"). Commit: `report: fix <title>`;
+   2. each refresh: a Report row with Refresh ticked, an Ask row with Refresh report set (with `asked_in` = that row's page id), or a report whose last `fixes` entry lists only proposals that are applied, rejected or closed (one recorded with `--record-only` waits). Commit: `report: refresh <title>`;
+   3. each other Ask row the user didn't decline: a new report with `asked_in` = the row's page id, its Project and Area. Commit: `report: <title>`.
 
-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.
+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 or Ready, 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. Run `brain views` first, so the project and area Briefs are current:
-   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, every source's Inbox row with its digest and full text, the report rows (then each Ask row's Brain Status to Processed), the cleared Full text boxes, and the project and area Briefs. Write in parallel, up to 10 at a time, and never read a page back after writing it.
+   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, every source's Inbox row with its digest and full text, the report rows (then each Ask row's Brain Status to Processed), the cleared Full text boxes, the project and area Briefs, a question's Status = Open, and the Review rows decided more than 30 days ago (`action: trash`, moved to Notion's trash; decision 0045). Write in parallel, up to 10 at a time, and never read a page back after writing it.
    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`.
+   5. A meeting read again keeps Brain Status Reviewed until you set it back to **Ingested** through the MCP (brain-ingest step 11): do it for each re-read meeting.
 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:
+3. **Log the run:** `brain log catch-up - notes_read=<n> seconds=<s>`, the notes whose full text the run and its sub-agents read and the seconds from "catch up" to here (decision 0045). Commit it: `log: catch up`.
+4. **Push** per `settings.push` (AGENTS.md, "Write path").
+5. **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
+   Done: 9 applied · 3 captures and 2 files ingested · 12 new notes · 1 task for you · 5 old Review rows trashed
    Needs you: 3 Review rows (2 Review notes rows, 1 answer) · 2 files skipped (too long, say which parts)
    Next: decide in Notion, then "catch up"
    ```
    Without Notion, the Next line is deciding in chat ("what needs my decision"), and "connect the brain to Notion" goes on the Needs you line.
-   Below the three lines: **What came in** (with each input's Notion choice: "digest" or "full text") and **What changed**, then the **reports written**, each with its row, then **Check** (each skipped input with its reason, each attachment that couldn't be read, the notes kept as drafts or left unchanged by a Review notes row, 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.
+   Below the three lines: **What came in** (with each input's Notion choice: "digest" or "full text"; each re-read with what changed) and **What changed**, then the **Fixes** you read, repeated back (brain-apply "Finish" step 5), then the **reports written or refreshed**, each with its row, then **Check** (each skipped input with its reason, each attachment that couldn't be read, the notes kept as drafts or left unchanged by a Review notes row, 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-howto/SKILL.md

@@ -9,7 +9,7 @@ Answer how-to questions about the system from [references/guide.md](references/g
 
 ## Procedure
 
-1. **Read the guide section** that matches the question. Its headings: The Spaces · The meeting flow · Deciding in Review · What you can edit · Adding things · What to say to your agent · When something looks wrong.
+1. **Read the guide section** that matches the question. Its headings: The Spaces · The meeting flow · Deciding in Review · Correcting what came in (a meeting, a capture, a report; refreshing a report) · What you can edit · Adding things · What to say to your agent · When something looks wrong.
 
 2. **If the question is about something that happened** ("why didn't…", "where did … go", "is my … set up"), check the live state before answering:
    - `brain status --brain . --json` (or without `--brain` in a linked repo). It reports pending proposals, Notion databases configured or missing, stale views, and the last log line.

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

@@ -21,12 +21,12 @@ 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, 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) |
+| **Knowledge** | Find what the brain knows, and everything that came in | Decisions · Questions · Concepts · References · People · Orgs · Inbox (What's in my inbox?: captures New or Ready · 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, meetings, decisions and open questions in views, and its people and clients as lists at the top. The brain adds a **Brief** toggle at the end: the area's projects with their status, and its recent decisions and open questions. 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, "What came in?" (every input filed under the project) and "What do we know?" (its decisions and concepts), then your own "My notes".
+**Project pages** show the Brief and Decision log (written by the brain), then the project's tasks, meetings, open questions and people, "What came in?" (every input filed under the project), "What do we know?" (its decisions, concepts and references) and **Reports** (the project's reports), then your own "My notes".
 
 **A Brief shows only what you reviewed.** Decisions and questions still in Draft stay out of it until you accept them in Review. When a section has nothing reviewed yet, it says how many notes are waiting: "Nothing reviewed yet: 4 notes waiting in Review".
 
@@ -44,12 +44,13 @@ Every meeting moves through **Brain Status**:
    - minutes follow the format;
    - minutes checked and corrected.
 
-   Then set Brain Status to **Reviewed**.
+   Check the minutes, fix them, then set Brain Status to **Reviewed**. What the minutes get wrong, fix here: it's cheaper than fixing what the brain read from them.
 4. **Ingest:** tell your agent "ingest my reviewed meetings". The brain reads the minutes and sets the meeting to **Ingested**. Then:
    - new notes (decisions, questions, people) arrive as **Draft**, with one **Review notes** row in Review to accept them all;
    - changes to things the brain already knew go to **Review**, and so does an answer it found to one of your open questions;
    - action items become **Tasks** (status To Do).
 5. Set **Skipped** for a meeting the brain should never read.
+6. **Fixed the minutes after the brain read them?** Set Brain Status back to **Reviewed**. The next catch-up reads the meeting again, compares it with what it read before, and proposes only what changed, in one Review row. The earlier version stays in the brain's history.
 
 The brain only ingests meetings you marked **Reviewed**, and only when you ask: nothing runs on its own. It never edits the meeting page itself.
 
@@ -59,69 +60,90 @@ The brain only ingests meetings you marked **Reviewed**, and only when you ask:
 
 ## Deciding in Review
 
-The brain never changes what it already knows without your yes. Each proposed change is a row in **Review → Needs my decision**, showing what it was (**Before**) and what it would become (**After**).
+**What approving does:** it makes the brain's notes **trusted**. Approved notes appear in your Briefs and in the brain's answers; until then, the brain treats them as unconfirmed. Start from Home → **Needs you → What's waiting for you?**: it counts what waits, by Kind, and each row's **About Page** opens the meeting or Inbox row it came from.
 
-1. Set **Decision**:
-   - **Approve** applies the change;
+The brain never changes what it already knows without your yes. Each row in **Review → Needs my decision** says what it is **About**, what it is **Now** and what is **Proposed**, and **Why** quotes the source.
+
+1. Set **Your call**:
+   - **Approve** applies it;
    - **Reject** drops it;
-   - **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.
+   - **Fix** applies it, corrected: say what's wrong in **What to fix**, in your own words ("it's March, not February", "Lucía is on Acme website, not Acme app").
+2. **What to fix** also works with Approve, to leave items out: "all except b, e".
+3. Tell your agent "apply my reviews" (or "catch up"). The agent reads What to fix, applies it, and repeats every correction back to you in its report ("a: launch set to March, not February"), so you can check it read you right. It never applies something you didn't clearly say; when unsure, it asks.
+4. **30 days after you decide,** the next catch-up moves the row to Notion's trash, so Review holds only what's recent. The brain keeps every decision, and Notion keeps the trash for 30 more days.
 
-**One Review notes row per input.** Every meeting or document the brain reads brings one row: "Accept 6 new notes from Acme launch review, and 2 links". Its After lists every new note and routine link, lettered:
+**One row per meeting, email or document.** Everything one input brings is one row, "From Acme launch review: 2 changes, 6 new notes and 2 links", with its items lettered in **Proposed**:
 
 ```
-a) Decision: Use Contentful as the blog CMS
-b) Question: Who signs off the launch post?
+a) ⚠ Launch date on Acme website: 2027-02 → 2027-03
+b) Add to Row-level security: Carlos will use RLS for the auth migration.
+c) Decision: Use Contentful as the blog CMS
+d) Question: Who signs off the launch post?
 …
-g) People on Acme website: Lucía Fernández
+h) People on Acme website: Lucía Fernández
 ```
 
-- **Approve** accepts them all: the notes become **Reviewed** and appear in the Briefs, and the links are added.
-- **Approve** with a Note "all except b, g" accepts the rest; b stays Draft and g isn't added.
-- **Reject** archives the notes that are still Draft and drops the links. Nothing is deleted.
+Changes to what the brain already knew come first, and a changed fact is marked ⚠: those are the ones to read closely.
+- **Approve** accepts them all: the changes are made, the notes become **Reviewed** and appear in the Briefs, and the links are added.
+- **Approve** with "all except b, h" accepts the rest. b and h aren't rejected: they move to a new row, "Deferred from Acme launch review", for you to decide later.
+- **Fix** with "a: March" applies everything, with a corrected.
+- **Reject** applies nothing, and archives the notes that are still Draft. Nothing is deleted.
+- If a fact changed since the row was written (you edited it in Notion, say), only that item is dropped, and the report says so. The rest applies.
 
-Changes to what a note says (a new fact, added text, two sources disagreeing) and answers get their own rows.
+**Rows of their own** are for the calls that need your judgment: two sources that disagree, a new decision replacing an older one, a possible duplicate, and an answer to one of your open questions.
 
-**Answer rows.** When new material answers one of your open questions, an Answer row says so: "Who owns the mobile app? → Carlos Ruiz owns it". Approve it and the question shows as **Answered** in Notion; Edit it to write the answer yourself; Reject it and the question stays open.
+**Answer rows.** When new material answers one of your open questions, an Answer row says so: "Who owns the mobile app? → Carlos Ruiz owns it". Approve it and the question shows as **Answered** in Notion; Fix it to give the answer yourself; Reject it and the question stays open.
 
-**Your corrections go in Note.** Target says what changes; typing there does nothing.
+**Type your corrections in What to fix,** never in About, Now or Proposed: those are the brain's, and typing there does nothing.
 
-| 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 | 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 |
-| Review Notes | The notes listed become Reviewed and the links are added; Reject archives the Draft ones | No: approve with a Note ("all except b, d") |
-| Answer | The question gets this answer and shows as Answered | Yes: your text becomes the answer |
-
-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.
+| Kind | Approve means |
+|---|---|
+| Review Notes | Everything listed: the changes are made, the notes become Reviewed, the links are added. Reject archives the Draft notes |
+| Update Fact | The new value replaces the old one; the old one stays in the history |
+| Add To Note | The text is added to the note |
+| Update Body | A reference note's text is replaced by its new version; Proposed shows the lines that change (`-` old, `+` new) |
+| Add Link | The links listed are added (people to a project, an alias to a person) |
+| Contradiction | Two sources disagree; both claims are kept as contested. Fix with the true value |
+| Supersede | A newer note replaces an older one, which is archived |
+| Merge | A duplicate is folded into the record it duplicates |
+| New Item | A new note is created as Draft |
+| Answer | The question gets this answer and shows as Answered |
+
+**Fix works on every kind.** 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.
 
 ---
 
+## Correcting what came in
+
+**How do I correct what came from a meeting?** It depends on where the mistake is:
+- **The minutes are wrong** (a misheard name, a wrong date): fix the minutes on the meeting page, then set Brain Status back to **Reviewed**. The next catch-up reads the meeting again and proposes only what changed, in one Review row. The same goes for a capture: fix its text and set its Brain Status to **Ready**.
+- **The minutes are right, but the brain read them wrong** (the wrong project, a suggestion taken as a decision): on the Review row, set Your call to **Fix** and say what's wrong in What to fix ("c is a suggestion, not a decision", "a belongs to Acme app"). If the row was already approved, tell your agent what's wrong, or set the note's Lifecycle to **Disputed**.
+
+**How do I refresh a report?** Tick **Refresh** on the Report row in the Inbox, then "catch up": the brain rewrites that report in place, as of today, and clears the box. Or create an **Ask the brain** row with **Refresh report** set to the report: the catch-up updates that report and links your question to it. An Ask row with Refresh report empty makes a new report. The earlier versions stay in the brain's history.
+
+**A report says something wrong?** Write it in the Report row's **What to fix** ("Lucía left Acme in June"). The mistake lives in the notes the report rests on, so the next catch-up turns it into Review rows on those notes. Once you approve them, it refreshes the report.
+
+---
+
 ## What you can edit, and what the brain owns
 
 Hover over a property name to see its owner. Each description starts with "Owner: you", "Owner: brain" or "Owner: system".
 
 | Owner | Examples | What happens when you edit it |
 |---|---|---|
-| **You** | Status, Priority, Dates, Lifecycle, Archived, Decision, Note, Brain Status on meetings and captures, Project and Area on a capture, Full text on an Inbox row | Your value stands. The brain reads it but never overwrites it |
+| **You** | Status, Priority, Dates, Lifecycle, Archived, Your call, What to fix, Brain Status on meetings and captures, Project, Area and Keep on an Inbox row, Full text, Refresh | Your value stands. The brain reads it but never overwrites it; it clears Full text, Refresh and a report's What to fix once it has acted on them |
 | **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, and the **Brief** on area 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, Question and Concept pages are written entirely by the brain.
+- Decision, Question, Concept and Reference pages are written entirely by the brain.
 - A capture's text is yours; the brain only adds its Kind, Summary and what it produced. An Ask row's text is yours too.
 - **Inbox rows the brain creates** (a document, email, web page, a repo file) get a **digest** in their body: what the input is, a summary and the key points, with figures and dates as stated. Emails and chats also get their whole text in a **Full text** toggle. For a document, tick **Full text** on its row (or say "full text for …") and the next catch-up adds it. Both are written once and never read back, so an edit you make there stays in Notion. The original file is the real copy.
-- A question's **Status** is yours, except that the brain sets **Answered** once, when you approve an Answer row.
+- A question's **Status** is yours. The brain sets it twice at most: **Open** when it creates the question, and **Answered** once, when you approve an Answer row.
 
 **Lifecycle** tells you how far to trust a record:
 - **Draft:** new, not reviewed by you yet;
@@ -137,15 +159,15 @@ 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. Set its **Project** if you know it, so the agent doesn't ask. Then "catch up" (or "process my inbox") |
+| A quick thought, link or idea | **Quick capture** on Home. It lands in Knowledge → Inbox as **New**. Set its **Project** if you know it, so the agent doesn't ask. Set Brain Status to **Ready** when it's ready; a capture still New a day later is taken in anyway. 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 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, and **what to keep** from each: "all", or "just the requirements". With a Keep, the brain writes one **Reference** note holding just that (a list or a table), linked to its project, and nothing else; a new version of the document later proposes only the lines that changed. Then, 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 |
-| A file from your phone | Attach it to a **Quick capture** (or to the meeting page), with Project set if you know it. The next catch-up reads it with the row. Files on project and area pages are not read |
+| A file from your phone | Attach it to a **Quick capture** (or to the meeting page), with Project set if you know it, and **Keep** to say what you want from the file. Set the row to **Ready**; the next catch-up reads the file with the row. Files on project and area pages are not read |
 | A repo's knowledge (decisions, docs, changelog) | "link the repo at ~/code/acme-api to the area Clients, files decisions/** and docs/*.md". Each catch-up then reads the files changed since the last one; the first time, it asks which to take. The brain never writes to the repo |
-| A question for a full report | **Ask the brain** on Home: type the question as the Name ("Where do we stand with the Acme launch?"). The next catch-up answers with a **Report** row in the Inbox, linked from yours |
-| 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 question for a full report | **Ask the brain** on Home: type the question as the Name ("Where do we stand with the Acme launch?"). The next catch-up answers with a **Report** row in the Inbox, linked from yours, and on the project's or area's page under **Reports**. To bring it up to date later, tick **Refresh** on it ("Correcting what came in") |
+| An email, chat thread or note | Paste it into a **Quick capture** (keep who sent it and when). For a thread, run **`/Clean email`** on the page: Brain Assistant gives each message a heading with names and date ("Tomás Vidal → Lucía Fernández · 3 Dec 2026"), its own text word for word below it, and a divider before the next, newest first. It drops addresses, signatures, disclaimers, quoted copies and Teams, Zoom or Meet blocks, and rewrites the page right away (the page history keeps the original), asking first only when something is truly unclear. Then set the row to **Ready** and "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:**
@@ -168,6 +190,7 @@ Set **Disputed** on anything wrong. The brain stops relying on it, and you can a
 | `/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 new capture in the Inbox) | A cleaner version of the capture; replaces the text after you say yes |
+| `/Clean email` (on a new capture holding a pasted email thread) | Each message under a heading of names and date, its own text word for word, a divider between messages, newest first; no addresses, signatures, disclaimers, quoted copies or meeting blocks; rewrites the page directly and asks only on a serious doubt |
 | "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.
@@ -188,7 +211,7 @@ Run these in Claude Code or Codex, from your brain's folder.
 | Apply your Review decisions | "apply my reviews" |
 | Bring Notion edits and new rows into the brain, and publish its changes | "sync with Notion" |
 | Ask what the brain knows | "what did we decide about …?", "who is …?", "when is the … launch?" |
-| Get a report on a subject: where it stands, a timeline, decisions, open questions, people and gaps | "report on the Acme launch". It includes notes you haven't reviewed, marked *(not reviewed)*, and is published as a Report row. A report is a snapshot: ask again for a fresh one |
+| Get a report on a subject: where it stands, a timeline, decisions, open questions, people and gaps | "report on the Acme launch". It includes notes you haven't reviewed, marked *(not reviewed)*, and is published as a Report row. "refresh the Acme launch report" rewrites it as of today |
 | Have a document's whole text in Notion | "full text for the Acme brief", or "slides 3–9 of the launch deck" (or tick Full text on its Inbox row) |
 | Read a repo into the brain | "link the repo at <path> to the area <name>, files <patterns>" |
 | Ask how the system works | "how do I …?", "why didn't … ?" (or ask Brain Assistant in Notion) |
@@ -207,10 +230,14 @@ Run these in Claude Code or Codex, from your brain's folder.
 | Text you typed in a project's Brief disappeared | The brain rewrites Brief and Decision log on every sync | Put your notes in **My notes** |
 | Your edit to a Summary or Role changed back | Brain-owned fields are read as corrections only on the next sync | "sync with Notion" before the next ingest |
 | 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 rejected change came back | A later source said it again | Reject it again, or Fix 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 | 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 |
+| A Review row with What to fix is still pending | The agent couldn't tell what it meant, or it described a different change | Answer the agent's question, or look for the new row it proposed |
+| A Fix row is still pending | What to fix is empty | Say what's wrong in What to fix |
+| A row "Deferred from …" appeared | You approved a row "all except …": the items you left out wait there | Decide it like any other row |
+| A capture wasn't taken in | It is still New and less than a day old, or it is Skipped; a document, email or note waits for Ready | Set it to **Ready**, then "catch up" |
+| You fixed the minutes after the ingest, and nothing changed | The meeting is still Ingested | Set it back to **Reviewed**, then "catch up" |
 | You want to see what the brain made from a document | Every input has a row in Knowledge → Inbox → What came in?, and on its project's page | Open the row: the body has the digest, and Decisions, Questions, Concepts and People list what it produced |
 | A Brief says "Nothing reviewed yet" | Its notes are still Draft | Approve their Review notes rows, then "catch up" |
 | A document's row shows only the digest | Documents and decks get a digest by default | Tick **Full text** on the row, then "catch up" |