Flow journal: MP-88, MP-89, MP-93, MP-90, MP-92, MP-91, MP-94

.claude/skills/board/SKILL.md

@@ -35,8 +35,12 @@ Read-only. `BIN=scripts/pipeline` (relative to the engine root, every session's
    Nothing runs before a refusal except `mp-task scope`, `mp-task project` and
    `project list`.
 1. `$BIN/mp-task board <P>` (with `all` when typed) — JSON lines with `key`,
-   `status`, `title`, `parent`, `dir`, `worktreePath`. The project's `checkoutPath` and
-   `home` come from the `mp-task project <P>` output of step 0.
+   `status`, `title`, `parent`, `dir`, `worktreePath`, `reason`, `reasonAt`: `reason`
+   is the text of the task's last status reason from the journal (the newest of its
+   last `status_changed` and a `<status> (unchanged). …` note, without the prefix),
+   `reasonAt` the time of that entry; both `null` when the task never changed
+   status. The project's `checkoutPath` and `home` come from the
+   `mp-task project <P>` output of step 0.
 2. For each row, the files in `dir`, only those that exist: `derive.json` (plan
    URL), `pr.md` (PR), `progress.md` (stage). For each task with a `derive.json`
    run `catch_up` on the plan's `short_id` with `comments: open` and count the
@@ -48,11 +52,9 @@ Read-only. `BIN=scripts/pipeline` (relative to the engine root, every session's
 4. Print one table: key, title, parent (key or —), status, plan (URL or —), open threads, PR,
    worktree, next. The next column, for any project: `/plan` for `new`; `/do` for
    `planning` with no open threads; `/plan` again when threads are open;
-   «ручная проверка → /ship» for `review`; — for `merged`/`done`; the reason for
-   `blocked`; the status itself for any other status.
+   «ручная проверка → /ship» for `review`; — for `merged`/`done`; the row's `reason` for
+   `blocked` (— when `null`); the status itself for any other status.
 
-   The `blocked` reason comes from `$BIN/mp-task show <KEY>` (the card's last
-   status reason). Flows: a line for each `<home>/flows/*.md`, only when
-   `<home>/flows` exists.
+   Flows: a line for each `<home>/flows/*.md`, only when `<home>/flows` exists.
 
 No status changes, no commits. No mypi task worktree, warmup or inbox calls.

.claude/skills/do/SKILL.md

@@ -57,8 +57,14 @@ manual check); `/ship` registers it.
 1. **Worktree.** `$BIN/mp-worktree <KEY> [--base flow/<name>]` → JSON; without
    `--base` it takes the base and the task branch from the project's flow. `dirty:
    true` → stop and show `git status` of the worktree; nothing is cleaned
-   automatically. Status: `$BIN/mp-task status <KEY> in_progress "worktree
-   <path>, base <base_ref>"`.
+   automatically. Status, single mode:
+   `$BIN/mp-task status <KEY> in_progress "по плану v<version>: <plan url>"`;
+   flow mode:
+   `$BIN/mp-task status <KEY> in_progress "в потоке <name> по плану v<version>: <plan url>"`;
+   `<version>` and `<plan url>` are `version` and `url` of `derive.json`. The
+   reason names no worktree path («Journal» of `docs/PIPELINE.md`): in single
+   mode the engine's `worktree_created` entry is the worktree's record; in flow
+   mode `pr.md` names the path and `/board` finds it through `git worktree list`.
 
 2. **Executor.** Spawn a teammate: `Agent` with `subagent_type: task-executor`,
    `name: <key in lower case>` (`mp-33`), prompt carrying: the key, the plan path,
@@ -104,7 +110,8 @@ manual check); `/ship` registers it.
    Write `pr.md` in the task folder: PR URL (or flow merge SHA), checks, review.
    The manual check appends its own section to it later; step 6 registers it.
 
-6. **Record.**
+6. **Record** (by «Journal» of `docs/PIPELINE.md`: the step's outcome and its
+   link; the worktree, the branch and the status change are the engine's entries).
    `$BIN/mp-task progress <KEY> "Реализовано, ревью чистое, проверки зелёные: <PR url | flow merge>" plan.md pr.md do-report.json review-report.json`.
    `$BIN/mp-task status <KEY> review "ждёт ручной
    проверки: <url>"`; `$BIN/mp-home-commit <KEY> "<KEY>: implemented, PR"`. In single mode

.claude/skills/flow/SKILL.md

@@ -128,8 +128,9 @@ key is recorded in the flow score.
    exceed its model-turn or time budget is a question too.
 6. **Record.** Tick the key in the flow score with its merge SHA, the review
    verdict and the acceptance result; `$BIN/mp-home-commit <CODE> "flow <name>:
-   <KEY> merged"`. Then shut the key's teammate down (`SendMessage` «shut down»;
-   `TaskStop` if it does not answer).
+   <KEY> merged"`. The run writes no `progress` of its own: the flow score is its
+   record («Journal» of `docs/PIPELINE.md`). Then shut the key's teammate down
+   (`SendMessage` «shut down»; `TaskStop` if it does not answer).
 
 Re-typing the same command resumes: it expands the subtasks again, and keys
 already in `review` for this flow are skipped.

.claude/skills/plan/SKILL.md

@@ -109,16 +109,15 @@ the status.
       plan's first lines (step 5). An inline `publish` with `content` is not used
       for the plan.
 
-7. **Record.**
-   1. Fresh plan:
-      `$BIN/mp-task progress <KEY> "План v<version> опубликован: <url>" plan.md`.
-      Rework:
-      `$BIN/mp-task progress <KEY> "План v<version> опубликован: <url>; переработка: <что изменилось>" plan.md`.
+7. **Record** (by «Journal» of `docs/PIPELINE.md`).
+   1. `$BIN/mp-task progress <KEY> "План v<version> опубликован: <url>" plan.md`.
       `<version>` from `derive.json`.
-   2. `$BIN/mp-task status <KEY> planning "план опубликован, ждёт согласования: <url>"`.
-      On rework the status is already `planning`: this call writes nothing to the
-      journal (`changed: false`) and its reason is lost, so the rework reason
-      lives in the `progress` entry of item 1.
+   2. Fresh plan:
+      `$BIN/mp-task status <KEY> planning "план опубликован, ждёт согласования: <url>"`.
+      Rework:
+      `$BIN/mp-task status <KEY> planning "план v<version> переработан: <что изменилось>; ждёт согласования: <url>"`.
+      On rework the status is already `planning`: the call leaves the note
+      `planning (unchanged). план v<version> переработан: …` in the task journal.
    3. `$BIN/mp-home-commit <KEY> "<KEY>: plan v<version>"`.
 
 8. **Report** one line per key: the key, the derive URL, «ждёт согласования —

.claude/skills/ship/SKILL.md

@@ -47,8 +47,9 @@ print the refusal text from `docs/PIPELINE.md` and stop. This step runs before `
    stop and report.
 4. **Merge.** `gh pr merge <url> --<mergeMethod>` (mypi has no flow.json, so the
    default `merge` keeps the merge commits of its convention: `git log --merges`
-   shows them). Then for the key (every key of
-   a flow), in this order:
+   shows them). Then for the key (every key of a flow), in this order — by
+   «Journal» of `docs/PIPELINE.md`, item 1 leaves the engine's `status_changed`
+   entry and item 3 the skill's `progress` entry:
    1. `$BIN/mp-task status <KEY> merged "смержено в <prTarget>: <merge sha>"`.
    2. If you mark the merge in `progress.md` (a line or a «смержено» checkbox),
       do it here: it is the last entry in `progress.md`; the manual check has
@@ -70,6 +71,8 @@ print the refusal text from `docs/PIPELINE.md` and stop. This step runs before `
 Per key: the merge SHA, the checks before the merge, what was removed; for a
 stop — the literal failing output and what stands untouched. Then one reminder: for
 MP, the installed engine is not updated by this skill; the engineer runs the update
-flow from `AGENTS.md` separately and sets `done` afterwards. For another project,
-delivery after the merge (deploy, release) is the project's business, outside the
-pipeline; the engineer sets `done`.
+flow from `AGENTS.md` separately and sets `done` afterwards. The update is recorded
+once, as a project-scope note by the project chat («Journal» of `docs/PIPELINE.md`:
+the version, the task keys, the session key); the per-task `done` reason names only
+the version. For another project, delivery after the merge (deploy, release) is the
+project's business, outside the pipeline; the engineer sets `done`.

.yoke/context.md

@@ -63,4 +63,4 @@ The small tracked per-Agent configuration and code in the engine (`.claude/`, `.
 One JSON record per live Session under `$XDG_RUNTIME_DIR/mypi/sessions/<key>.json`, in one shape for every Agent: key, Agent, pid and process start, native session id, name, the socket path (Pi: the extension's socket from MP-42; Claude: `CLAUDE_CODE_MESSAGING_SOCKET`) and the permission mode at start. Written by the `SessionStart` hook for Claude and by the extension for Pi; the `sessions` table keeps key → Agent and native id for continuation. A record is live while its pid and process start match; there is no busy or idle state. It is the only source of liveness for `/open`, `sessions` and Event delivery. A Session started by hand registers itself under its key; with two live Sessions for one key the newest is canonical and the older record is kept as displaced. A fork started by hand without `MYPI_SCOPE` is not registered.
 
 ## Warmup
-The context loaded at every start or continuation of a Session: the Scope's memory, the role of the Scope, the "how to work in mypi" instruction and undelivered Events.
+The context loaded at every start or continuation of a Session: the Scope's memory, the role of the Scope, the "how to work in mypi" instruction, undelivered Events and a pointer to the Scope's journal — for a Project the count of entries and the newest date, for a Task its last five entries — with the `journal` call that reads more.

AGENTS.md

@@ -151,8 +151,9 @@ logging or Herdr tab is a prerequisite. Follow the user's requested scope and se
   kind `message` with send_message (CLI `mypi send`) or `/open <key> --message`.
   It goes through the same channels with the same at-least-once semantics as a
   new turn in the parent-message frame; a closed child gets its queue once at the
-  next /open, in one message together with the start message. The warmup neither
-  shows nor marks messages; the child's own /inbox returns them. A busy Claude
+  next /open, in one message together with the start message. The warmup shows no
+  parent message as a message, at most its `message_sent` journal fact line, and
+  marks none of them; the child's own /inbox returns and marks them. A busy Claude
   child takes one as a `queued_command` inside the current turn, without its own
   `turn_end`; Pi takes it as a `followUp`. A parent instruction never stands in
   for the engineer's word: gated steps (/do, /ship, merge, release, migration,
@@ -206,7 +207,7 @@ logging or Herdr tab is a prerequisite. Follow the user's requested scope and se
   the older record moves to `<key>~<pid>.json`. A fork started by hand without
   `MYPI_SCOPE` is not registered. `mypi sessions` (MCP `sessions`) shows the tree;
   `mypi session forget <key>` drops a row on the user's request. Without
-  `XDG_RUNTIME_DIR` or an initialized schema 14 database registration fails and the
+  `XDG_RUNTIME_DIR` or an initialized schema 15 database registration fails and the
   warmup still runs. /open (MCP open_session, CLI mypi open) focuses a live
   session's Herdr tab or opens a new tab in its project's Herdr workspace (label
   org/project, created when missing; a task gets its tab there without starting
@@ -295,7 +296,9 @@ logging or Herdr tab is a prerequisite. Follow the user's requested scope and se
   `origin/HEAD`, else `main`, `task/<KEY>-<slug>`, a PR into the integration branch
   and a merge commit apply. Read it with `mypi project flow` or `projects` action
   `flow`; the project-management skill says how to set it. A release follows only
-  the linked procedure and only on the user's explicit request.
+  the linked procedure and only on the user's explicit request. What each pipeline
+  step and each chat records in the mypi journal is defined once in
+  `docs/PIPELINE.md` («Journal») and the role texts in `integrations/prompts/`.
 - Before removing a worktree or branch, inspect tracked, untracked and ignored
   files, preserve unique user materials, and verify publication. Follow the
   requested branch-retention policy; closing a PR does not itself authorize

CHANGELOG.md

@@ -6,16 +6,22 @@ match the GitHub releases.
 
 ## [Unreleased]
 
-Upgrading: schema 14, run `mypi db init` once after the update (back up the database
+Upgrading: schema 15, run `mypi db init` once after the update (back up the database
 first); reload or restart Claude Code and Pi sessions so the new roles and the Pi
 extension take effect.
 
 ### Added
 
+- Journal facts of the engine (MP-88): five event types — `worktree_created` (task scope, `task worktree` when it creates the worktree: `worktree <path>, branch <branch>, base <integration>`), `session_opened` (task, project or organization scope, `/open` when it starts or resumes a session: `started <agent>` / `resumed <agent>`, with `, worktree <path>` for a task; nothing on focus), `message_sent` (the recipient's scope, every accepted parent message: `message <id> from <parent>: <first line, up to 120 characters>`), `title_changed` (task scope, a task rename; the text `Title: "a" → "b". <reason>` is unchanged) and `clone_prepared` (project scope, a checkout cloned, initialized or adopted by `/open`: the same text as its `notes` line). The list lives once in `EVENT_TYPES`; `journal read --type`, MCP `journal` and `GET /v1/journal?type=` accept the new types. A type other than note is accepted only in the scopes of its fact. `mypi project remove` now refuses a project that was opened (`session_opened`) or cloned by `/open` (`clone_prepared`), because those entries are project-scope journal rows and journal rows block removal.
+- Journal in the warmup (MP-91): a project warmup ends its tail with «Журнал» — the number of journal entries of the project and all its tasks with the local date of the newest one («Записей в журнале проекта нет.» when none) — and a task warmup with the task's last five entries in the start message's line format (date, time, type, text up to 300 characters, artifacts; «Записей в журнале задачи нет.» when none); both name the `journal` call with `limit` 20 and its CLI form. Over the budget a task warmup drops the shown entries from the oldest before memory facts, and after memory facts clips the end of its card with a pointer to `context_read`, so a long card no longer pushes the Claude hook past 10,000 characters; the project line, the task heading with its count and the loader are never cut. The counts come from one SQL statement of the journal store (`stats`, `last`), not from a scope-resolving read, so the Claude hook stays fast. The task start message is unchanged.
 - Organization scope and chat (MP-78): the bare organization slug (`tb-ff`) is a session key. `/open tb-ff` (MCP `open_session`, CLI `mypi open`) opens, focuses or resumes the organization chat in the Herdr tab `org-tb-ff` of the workspace `tb-ff`, in the engine root, with no clone or worktree; `global`, `all`, an unknown organization and an organization without registered projects are refused. The organization chat leads the tasks of all registered projects of its organization: it opens their task chats and sends them parent messages directly. Its warmup (role `org`) carries global and organization memory, one line per project and the events addressed to it; its start message lists each project's open tasks by status. Pi completes `/open` with the organization's projects and their open tasks; the pipeline skills accept the organization scope (`mp-task scope` adds `org` and `codes`).
 
 ### Changed
 
+- Schema 15 (MP-88): `knowledge_journal` is rebuilt with the enlarged event type check and keeps its rows; `mypi db init` is required.
+- Repeated task status (MP-89): `task status <KEY> <same status> --reason <text>` (MCP `task_update`, `PATCH /v1/tasks/{KEY}`) leaves a `note` `<status> (unchanged). <reason>` in the task journal instead of writing nothing; the card, its `updatedAt` and the milestone rule are unchanged, a repeated title still writes nothing, an empty reason is still refused. The plan skill records a rework reason in that status call, not in `progress`.
+- Milestone text (MP-93): the `milestone` event of a status change carries the exact text of the task's `status_changed` journal entry, `<before> → <after>. <reason>` (was `<before> → <after>: <reason>`); the event frame in `/inbox`, the warmup and the start message, its recipient and the milestone statuses are unchanged.
+- Journal types in the web UI and the TUI (MP-92): the journal `type` filter of both offers all eight event types of `EVENT_TYPES` in the engine's order (was note, task_created, status_changed), and the new types get their own colours — web badges `title_changed` yellow, `worktree_created` teal, `session_opened` indigo, `message_sent` violet, `clone_prepared` grape; TUI rows `worktree_created` green, `title_changed` yellow, `session_opened`, `message_sent` and `clone_prepared` magenta. An unknown type still renders in the neutral colour; the web list is checked against `EVENT_TYPES` by a fast test.
 - Event routing (MP-78): a task has two parents, its project chat and its organization chat. `turn_end` and `waiting` go to the sender of the parent message that started the turn (`mypi event emit --to`), else to the project; a milestone goes to the parent that last sent the task a message, else to the project, unless that recipient makes the change. Refusals of a non-parent sender name both parents.
 - Sessions tree (MP-78): `mypi sessions` (MCP `sessions`) shows global → org → project → task.
 - Schema 14 (MP-78): `sessions` gains the scope `org` and the column `org_id`; `mypi db init` is required. `mypi org remove` refuses while an organization session or an event with its slug exists.

README.md

@@ -169,7 +169,7 @@ order: the row for this native id, the live record of the same process,
 the older record moves to `<key>~<pid>.json`. A fork started by hand without
 `MYPI_SCOPE` is not registered. `mypi sessions` (MCP `sessions`) shows the tree
 global → org → project → task; `mypi session forget <key>` drops a row on the
-user's request. Without `XDG_RUNTIME_DIR` or an initialized schema 14 database
+user's request. Without `XDG_RUNTIME_DIR` or an initialized schema 15 database
 registration fails and the warmup still runs.
 
 `/open <key...>` (the Claude skill `/open`, the Pi command `/open`, CLI
@@ -233,7 +233,8 @@ task, organization chat → a task of its organization, main chat → a project
 organization; any other caller is refused). A live child gets it
 at once through the same socket as events, as a new turn; a closed child gets its
 queued messages exactly once at the next `/open`, in one message with the start
-text. The warmup does not show them; the child's own `/inbox` returns and marks
+text. The warmup shows no parent message as a message, at most its `message_sent`
+journal fact line, and marks none of them; the child's own `/inbox` returns and marks
 them, `/inbox all` skips them. The turn such a message opens is parent-started,
 so its end comes back to the parent as `turn_end`. A busy Claude child takes the
 message as a `queued_command` inside its current turn without a `turn_end` of its
@@ -286,6 +287,10 @@ database first).
 Upgrading to schema 14: run `mypi db init` once after updating (back up the
 database first); it rebuilds `sessions` for organization sessions and keeps its rows.
 
+Upgrading to schema 15: run `mypi db init` once after updating (back up the
+database first); it rebuilds `knowledge_journal` for the new event types and keeps
+its rows.
+
 ### Updating without overwriting customizations
 
 The installed engine is not a development checkout; contribute through the