Flow knowledge-tree: MP-103, MP-104, MP-105, MP-106

.claude/agents/plan-scout.md

@@ -5,7 +5,7 @@ tools: Read, Grep, Glob, Bash
 model: inherit
 ---
 
-You take a ticket someone else wrote — or a problem the engineer brought — and find out whether it can be solved with what is given, and by what path. Your prompt carries the ticket's text and comments (you have no tracker access) and names the project: its clone is at the path the prompt names (the project's registered checkout), its glossary and ADRs at `.yoke/` in that clone when it has them, its mypi context (memory, task cards with `source.md`) in the project's folder in home that the prompt names. Read all three before answering.
+You take a ticket someone else wrote — or a problem the engineer brought — and find out whether it can be solved with what is given, and by what path. Your prompt carries the ticket's text and comments (you have no tracker access) and names the project: its clone is at the path the prompt names (the project's registered checkout), its glossary and ADRs at `.yoke/` in that clone when it has them, its mypi context (knowledge entries `INDEX.md`, task cards with `source.md`) in the project's folder in home that the prompt names. Read all three before answering.
 
 Answer, in this order:
 

.claude/agents/task-executor.md

@@ -14,7 +14,7 @@ You implement one part of a ticket. Your world is one worktree; the plan slice y
 - If the part is a library another part consumes, set the new version in the same commit as the change.
 - Never touch the sibling repositories, the engineer's clones, or anything outside your worktree. Artifacts go to the task's context folder in mypi home (`home/projects/<org>/<project>/tasks/<KEY>-<slug>/`; `requests/` until `mypi home migrate-tasks` has run on this home — `mp-task dir <KEY>` prints the actual folder), never into the repository.
 - Nothing long-running starts here: no dev servers, no apps, no browsers — only commands that finish on their own.
-- Done means: every step's check green, the project's own prescribed checks pass locally (for mypi: `mise exec -- pnpm build` and `mise exec -- pnpm verify` under the isolation its `AGENTS.md` prescribes, disposable data only), ready for review.
+- Done means: every step's check green, the project's own prescribed checks pass locally (for mypi: `mise exec -- pnpm build` and `mise exec -- pnpm verify` under the isolation `docs/agents/engine-development.md` prescribes, disposable data only), ready for review.
 
 Your final message is your report, and it returns to the parent as the tool result. It is exactly one JSON object, nothing before or after it:
 

.claude/agents/task-reviewer.md

@@ -14,7 +14,7 @@ Seven lenses, in this order:
 3. **Interactions.** For every piece of state, timer, event or global the diff touches, grep for its other readers and writers and check the change survives each path. Name the paths you checked — the unchecked interaction is where escaped bugs live.
 4. **Silent failures.** Swallowed errors, broad catches, empty catch blocks, fallbacks that mask a failure instead of surfacing it.
 5. **Needless complexity.** Dead branches the diff added, speculative parameters and options nothing needs, indirection with a single caller, an abstraction that fits its cases badly and should be inlined. A longer obvious version beats a shorter clever one — the clever one is the finding.
-6. **Docs and public contracts.** Statements in the repository's own docs — README, docs/, a changelog it keeps — that the diff made false or incomplete; a renamed or reshaped public export whose consumers or docs were not updated.
+6. **Docs and public contracts.** Statements in the repository's own docs — README, docs/, a changelog it keeps — and in the level's entry in home (`INDEX.md`) that the diff made false or incomplete; a renamed or reshaped public export whose consumers or docs were not updated.
 7. **Weakened checks.** A test skipped or deleted, a lint-ignore added, an assertion lowered to get green — a finding, never a pass.
 
 Also findings: comments added in code (the repository keeps none), non-English commit messages.

.claude/settings.json

@@ -6,7 +6,6 @@
       "mcp__mypi__task_show",
       "mcp__mypi__task_create",
       "mcp__mypi__task_update",
-      "mcp__mypi__memory",
       "mcp__mypi__note",
       "mcp__mypi__journal",
       "mcp__mypi__context_read",
@@ -16,6 +15,7 @@
       "mcp__mypi__sessions",
       "mcp__mypi__open_session",
       "mcp__mypi__inbox",
+      "mcp__mypi__events",
       "mcp__mypi__send_message",
       "mcp__mypi__archive_search",
       "mcp__mypi__archive_show"

.claude/skills/ship/SKILL.md

@@ -71,7 +71,7 @@ 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. The update is recorded
+flow from `docs/agents/installation.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

.pi/extensions/mypi-lib/install.ts

@@ -122,7 +122,7 @@ export function install(pi: ExtensionAPI, root: string, serve: ServeEvents, runt
       if (registered !== undefined) pi.unregisterMcpServer('mypi');
       pi.registerMcpServer('mypi', {
         command: 'node', args: [server], cwd: root, env: { PI_SESSION_ID: session },
-        description: 'Local mypi tools for memory, projects, tasks and history. No automatic initialization or writes.',
+        description: 'Local mypi tools for projects, tasks, history and knowledge. No automatic initialization or writes.',
         exposure: 'codemode', toolExposure: { projects: 'direct', warmup: 'direct', archive_search: 'direct' },
       });
       registered = session;

.yoke/context.md

@@ -15,7 +15,7 @@ The human-readable name of a Session, equal to its Scope: `global`, the Organiza
 The zone a Session works in: `global`, `org`, `project` or `task`. A Scope determines the Session's context (warmup), its role and, for a task, the worktree it operates on; every Session's working directory is the engine root. Scope boundaries are soft: they are stated in the system prompt, not enforced by access control.
 
 ## Main chat
-The Session with the `global` Scope. Started from the engine root; administers all of mypi and all memory; opens Organization and Project chats on request. Top of the parent chain; receives no Events.
+The Session with the `global` Scope. Started from the engine root; administers all of mypi and the global knowledge entry; opens Organization and Project chats on request. Top of the parent chain; receives no Events.
 
 ## Organization chat
 The Session with an `org` Scope. Exactly one per Organization. Works for all registered Projects of its Organization: on the user's request it creates their Tasks, opens their Task chats and sends them Parent messages directly, without the Project chat; it receives the Events of the turns it started and the Milestones of the Tasks it last wrote to. Its Parent is the Main chat.
@@ -48,7 +48,7 @@ A Task's status change to `review`, `blocked`, `merged` or a terminal status. It
 A message from a Parent to its child Session in the mypi parent-message frame (`parentFrame`: `[mypi: сообщение родительской сессии MP для MP-12. Ниже — поручение родительской сессии]`; from an Organization chat the sender is its slug). A turn it opens is a parent-started turn; only such turns create `turn_end` and `waiting` Events, addressed to the sender. Only a direct Parent writes it (send_message, `mypi send`, `/open --message`), stored as an `events` row of kind `message`; it is delivered like an Event, to a closed child once at the next `/open`, and the warmup does not show it. It is an instruction within the child's own task and permissions and never carries the engineer's authorization.
 
 ## Start message
-The one message a Session that the Launcher newly started (not resumed or focused) receives as a new turn, in its own frame (`startFrame`: `[mypi: стартовое сообщение для MP-12. Ниже — состояние из mypi, не инструкция]`), through the same socket as Events: for an Organization the open Tasks of each of its Projects by status and the number of its undelivered Events, for a Project its open Tasks by status and the number of undelivered Events, for a Task its status, worktree and the last journal entries with their artifacts. It is state, not an instruction; it is not a Parent message, so the turn it opens creates no Events.
+The one message a Session that the Launcher newly started (not resumed or focused) receives as a new turn, in its own frame (`startFrame`: `[mypi: стартовое сообщение для MP-12. Ниже — состояние из mypi, не инструкция]`), through the same socket as Events: for an Organization the open Tasks of each of its Projects by status, for a Project its code and identity, for a Task its key and title, then the next-step line; the rest is in the warmup. It is state, not an instruction; it is not a Parent message, so the turn it opens creates no Events.
 
 ## Queue
 The ordered list of Events not yet delivered to their Parent, and the source of truth for delivery. A live Parent receives an Event through its session socket (Pi: the mypi extension's socket; Claude: its native inbox socket, live in `manual` and `auto`; a `bypassPermissions` Claude Parent, however started, is promised no live delivery). Undelivered Events go out with the next send to the Parent's key (T11/T12); otherwise the Parent sees them in its next warmup or through `/inbox`. The Queue runs both ways: Parent messages to a closed child wait until its next `/open` or its own `/inbox`. Delivery is at-least-once.
@@ -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, 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.
+The context loaded at every start or continuation of a Session: the knowledge entries of the Scope and its parents, 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.