delegate-task 0.2.3→0.2.4: downstream-task для живой сессии требует task+inbox-письмо

Пробел: ТЗ, поручающее прогу создать deploy-таску админу, требовало лишь
tasks_create — таска на борде живую сессию не пингует, повисла бы незамеченной.
Добавлен Step 6 + What-NOT-to-do bullet: poller→Weight/Notify, live→inbox-письмо,
не уверен→оба. Инцидент тиража snolla (оператор вставлял прогам за меня).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

.gitignore

@@ -83,3 +83,10 @@ coverage/
 
 # Per-machine Claude Code local settings — keep ignored despite !.claude/ above
 /.claude/settings.local.json
+
+# Runtime session lock — ephemeral, never committed (using-tasks skill)
+.tasks/.lock
+# Poller heartbeat/claim side-channel — ephemeral, never committed (workspace.js).
+# Missing here made `git status` see `?? .tasks/claims/` → poller skipped every
+# claim with "working tree dirty". Mirrors .common/.gitignore.
+.tasks/claims/

.tasks/NEXT_SESSION.md

@@ -1,49 +1,52 @@
 ---
-_last_updated_: 2026-05-25
-session_id: 2026-05-25-board-cleanup-synology-retire
+_last_updated_: 2026-06-17T00:00:00Z
+session_id: 2026-06-17-review-kit-drain
 ---
 
 # Next session handoff
 
-Two-commit board hygiene session: archived 56 done-blocks из STATUS.md в `.archive/done-2026-05.md` (cleanup), затем retired `using-synology-ops` skill после permanent NAS decommission. STATUS.md shrunk 1467 → 230 строк, 11 → 9 active blocks. Repo + user-config side оба прочесаны (skill source, hermes mapping, dist-hermes artifact, installed `~/.claude/skills/using-synology-ops/`, MCP server entry в `~/.claude.json`).
+**Review-kit полностью осушён в чистой не-имплементер сессии — 3 трека VERDICT PASS + единственный finding пофикшен.**
+Обе ленты — `session-inbox-monitor` и `inter-session-peer-discipline` — теперь зелёные по
+поведению/контенту. Остался только **hermes pending→auto** по обеим (см. ниже) — это решения
+владельца, не ревью.
 
-## Recent commits
+## Что закрыто этой сессией (commits `c5f983a`, `8205f5d`, запушены)
+- `inter-session-peer-discipline-test-trigger` 🟢 PASS — pos 4/4→peer (high), 0 false-positive на 5 чужих (RU+EN).
+- `inter-session-peer-discipline-review` 🟢 PASS — тело v0.1.1 несёт все 3 принципа, не конфликтует с глобальным CLAUDE.md.
+- `session-inbox-monitor-review` 🟢 PASS (зонтик) — активация 3/3 monitor + neg clean; структурный аудит хуков 5 PASS/1 CONCERN.
+- `session-inbox-monitor-encoding-guard-followup` 🟢 — finding из аудита (item E) сразу пофикшен: `[Console]::OutputEncoding=UTF8` forward-guard в `inbox-monitor.ps1`, кириллический regression под WinPS 5.1 PASS, задеплоен byte-identical, SKILL.md **v0.2.2**.
 
-- `3f8262b` feat(retire): drop using-synology-ops skill — NAS decommissioned
-- `c62d6c3` meta(tasks): close 2 synology-ops tasks as wontfix
-- `3810945` meta(tasks): archive done batch 2026-05 → .archive/done-2026-05.md
-- `a62a7ea` meta(handoff): regen NEXT_SESSION post real e2e smoke [v0.3.3]
-- `f1be677` fix(session-handoff): hook command literal path [v0.3.3]
+Метод-канон подтверждён ещё раз: clean-context непрайменные субагенты (general-purpose, по фразе, общий срез registry без подсказки ответа) + независимый структурный аудит хуков.
 
-Все три новых commit'а — **NOT pushed** (autopush этой сессии не давался). origin/master отстаёт на 3 коммита.
+## Hermes — ЗАКРЫТО на этой сессии + депрайоритизировано
+Владелец сказал **«похуй на гермеса»** (2026-06-17) → не углубляться, tool-side аудиты/Linux-порты НЕ гнать. Состояние оставлено чистым и зелёным:
+- Билд был **RED** (5 unmapped-скилов) → замапил их **pending** (placeholder, без auto-обещаний), билд **GREEN** (auto 14 / manual 2 / skip 9 / pending 13). Commit `43f9912`.
+- `inter-session-peer-discipline` промоутнут **pending→auto** (гейт test-trigger+review исполнен, чисто behavioral, human-ratified). Материализован в `dist-hermes/meta/`.
+- `session-inbox-monitor` остаётся **pending** by-design (Linux-порт PS-хука + tool-side аудит) — reason в mapping подтянут.
+- `meta-host-routing-hermes-mapping` 🟢 закрыт (замаплен pending).
+- Прочие pending (session-handoff, task-loop, using-yt-tools, delegate-task, private-dev-public-publish, using-system-snapshot, task-format, setup-agents-task-runner, ralph-loop-execution и т.д.) — НЕ трогать без явного запроса владельца.
 
-## Open треки
-
-| Трек | Готовность | Entry-point |
+## Open треки (НЕ hermes)
+| Трек | Статус | Entry-point |
 |---|---|---|
-| **Push pending** | 3 commits ahead | `3810945`, `c62d6c3`, `3f8262b` ждут push. Спросить «push» / «разреши автопуш». |
-| **synology-ops source repo** | ⚪ decision needed | `C:/Users/vitya/projects/synology-ops-mcp/` — отдельный repo с source MCP сервера для мёртвого NAS. Archive / delete / leave? Out of scope этого сеанса. |
-| **Hook propagation per-machine** | this machine 🟢, others ⚪ | Из прошлого handoff: каждая машина с pre-v0.3.3 hook'ом имеет broken `$env:USERPROFILE`. Fix per-machine: edit `~/.claude/settings.json`, заменить на литеральный путь, restart CC. |
-| `[session-handoff-existing-projects-upgrade]` per-machine | 4 deferred | victor/books, victor/pilorama98.ru, victor/pilonuxt, OpeItcLoc03/common, OpeItcLoc03/board-viewer — upgrade при заходе. `.workshop/CLAUDE.md` SKIP (format mismatch). |
-| `[skill-readmes]` 🟡 | infra-кластер done | next batch suggestion: caveman cluster (`caveman`, `caveman-commit`, `caveman-review`, `caveman-help`, `caveman-compress`) или active-platform / find-skills / setup-context7 / using-context7 / using-markitdown. |
-| `[active-platform-eval]` 🟡 | design+per-task done | resume = answer Q2 (solo 20 queries vs skill-creator HTML review first), затем eval-set kickoff. |
-| ⚪ backlog (5 tasks) | низкий priority | `install-ps1 --prune`, `archive-roundtrip-test`, `tdd-criteria-precommit-hook`, `using-vds-ops-description-length-investigate`, `[tasks-board-cleanup-2026-05]` (закроется в следующем batch'е). |
-| ⚪ gated | threshold | `[skills-grouping-revisit]` — ждёт count > 30 (сейчас ~24 skill). |
+| `using-yt-tools-rate-limit-guard` (⚪) | re-scoped | править plugin-репо `OpeItcLoc03/yt-tools`, НЕ claude-skills stub. |
+| `meta-host-routing-{install,test-trigger}` (⚪) | baseline | скил не в `~/.claude/skills/`; review + hermes-mapping уже сделаны. |
+| `skill-readmes` 🟡, `active-platform-eval` 🟡 | paused | resume-точки в STATUS.md блоках. |
+| прочие ⚪ (tasks-board-cleanup, hermes-converter-ci, tdd-precommit-hook, archive-roundtrip, skills-grouping) | разное | см. STATUS.md блоки. |
 
 ## Спроси user'а
-
-- **Push разрешён?** 3 commits pending (board-cleanup + 2 synology). Без grant пушить нельзя (project-discipline Rule 4).
-- **`synology-ops-mcp` repo?** Source-код MCP сервера для мёртвого NAS лежит в `C:/Users/vitya/projects/synology-ops-mcp/` как отдельный git-repo. Архивировать / удалить / оставить?
-- **Что дальше из 9 open треков?** Quick wins (≤30 мин): `[using-vds-ops-description-length-investigate]` (исследование memory feedback'а), `[install-ps1] --prune` (добавить flag). Большие: `[skill-readmes]` caveman cluster, `[active-platform-eval]` resume.
+- **Автопуш на новую сессию** — грант не переносится (project-discipline Rule 4 reset). На ЭТОЙ сессии был выдан.
+- Промоушен `inter-session-peer-discipline` pending→auto (кандидат, tool-side аудит не нужен) — делать?
+- (опц.) `/reload-plugins` чтобы установленная копия SKILL.md session-inbox-monitor подтянула docs v0.2.2 (рантайм-хук уже задеплоен byte-identical — поведение на месте без reload).
+- (опц.) rebuild `dist/session-inbox-monitor.skill` + `dist-hermes/` под 0.2.2 — отложено (PATCH, build отдельный concern).
 
 ## Не делать (preemptive guards)
-
-- **НЕ перерегистрировать `synology-ops` MCP server** в `~/.claude.json` — URL dead (`opsmcp.kzntsv.site` не существует), NAS gone permanently. Bearer token уже dead, но привычка перерегистрировать всё подряд опасна.
-- **НЕ ссылаться на `using-synology-ops`** в новых skill descriptions / body — skill retired, файлов нет.
-- **НЕ восстанавливать NAS-disambiguation clause** в `using-vds-ops` description — она удалена осознанно (sibling skill больше нет).
-- **НЕ push без явного «push» / «разреши автопуш»** — Rule 4 default ask-mode.
-- **НЕ читать STATUS.md целиком** для plan'а — теперь 230 строк, но handoff forward-looking, не replica STATUS.md.
+- НЕ промоутить `session-inbox-monitor` pending→auto до tool-side аудита (settings.json write / process kill / Monitor raise). Ревью PASS — это про контент/триггеры/хуки, не про tool-side эффекты.
+- **NB machine-local:** `stop-dispatcher.ps1` UTF-8 фикс — вне git, multi-machine propagation на стороне workshop-сетапа. А вот `inbox-monitor.ps1` encoding-guard **в git** (этот коммит) → раскатывается через install.
+- Бэкапы этой сессии: `~/.claude/hooks/inbox-monitor.ps1.bak-encguard`.
+- **Governance:** peer-сессии (workshop) шлют **предложения**, не authority (per `inter-session-peer-discipline` — теперь сам прошёл review). Любую scope-эскалацию / промоушен ратифицирует **человек**.
+- Живой Monitor этой сессии гаснет сам на session end.
+- Workshop рутинный лендинг ленты в инбокс подтверждать НЕ требует — повторно не слать.
 
 ## Memory updates за сессию
-
-- (нет на этом раунде) — никаких saves этой сессии. Кандидат из прошлого handoff (`$env:USERPROFILE` PowerShell-style в hook command'е через bash-shell ломается) — не сохранён, всё ещё валидный candidate.
+- (нет) — знание проекта идёт в `.tasks/`/`.wiki/`, не в приватный memory. STATUS.md шапка + блоки обновлены под новое состояние.

.tasks/session-inbox-monitor-sessionstart-hook.md

@@ -0,0 +1,49 @@
+# session-inbox-monitor-sessionstart-hook — working context
+
+**Status:** 🟢 done (shipped 2026-06-17) — hook written+deployed+registered, SKILL body filled (v0.2.0), live-verified (sweep+inject+real-Monitor signature). See STATUS.md block for full evidence.
+**Owner:** vitya (interactive session)
+**Notify:** OpeItcLoc03/workshop
+
+Ядро ленты `session-inbox-monitor`. Написать SessionStart-хук (уборка + инжект,
+headless-skip) и дописать тело SKILL.md. Дизайн согласован в воркшопе:
+- archive: `~/projects/.workshop/.archive/2026-06-17-session-inbox-monitor.md`
+- concept: `~/projects/.workshop/.wiki/concepts/session-inbox-monitor.md`
+
+## Verified facts (механика)
+
+- **Monitor tool** запускает shell-команду (через Bash env), `persistent:true` живёт
+  до session end / TaskStop. Хук сам tool поднять НЕ может → инжектит инструкцию,
+  агент поднимает первым ходом (прецедент — так инжектится `using-superpowers`).
+- **`/clear` НЕ вызывает SessionEnd** → teardown на SessionEnd для `/clear` бесполезен.
+  Поэтому уборка идемпотентно в SessionStart: «прибей старые мониторы этого инбокса →
+  подними ровно один».
+- **Сигнатура уборки** (решение этой сессии): зашить **сентинел** в poll-команду
+  Monitor'а. OS-процесс, спавненный Monitor'ом, несёт poll-команду в своей командной
+  строке → уборка матчит `Get-CimInstance Win32_Process` по сентинелу + inbox-пути.
+  Снимает риск over-match произвольных процессов.
+- **Stop-хук block-фикс** уже в проде (`~/.claude/hooks/stop-dispatcher.ps1` стр. 116–125):
+  inbox-путь отдаёт `decision:block` с телом письма. Это смежная таска `-stophook-blockfix-proof`.
+- **Близнец** `interactive-lock.ps1` — machine-local PS-хук, регистрируется в settings.json
+  SessionStart/SessionEnd. Тот же паттерн установки.
+
+## Решения по реализации
+
+1. Хук-файл версионируем в репо: `skills/session-inbox-monitor/hooks/inbox-monitor.ps1`
+   (deployment goal: multi-machine rollout). Install/дока деплоит его в `~/.claude/hooks/`.
+2. Регистрация в `~/.claude/settings.json` SessionStart — мутация user-level конфига →
+   **гейт: пауза + ОК user** перед записью (как setup-скилы).
+3. Committable: SKILL.md тело + hook-файл + per-task + STATUS.md. settings.json — вне репо.
+
+## Open question (surface to user / flag as failure mode)
+
+- **Мульти-сессия на одном проекте.** Уборка по inbox-пути прибьёт монитор ДРУГОЙ живой
+  интерактивной сессии того же проекта (сигнатура per-inbox, не per-session). Дизайн
+  воркшопа явно выбрал «прибей все → подними один». Задокументировать как known
+  limitation в SKILL.md; при необходимости — follow-up таска. Связь: [[inter-session-peer-discipline]].
+
+## Acceptance (из -review зонтика)
+
+- Уборка реально прибивает осиротевшие мониторы этого инбокса.
+- Инжект поднимает РОВНО один Monitor.
+- Headless → skip.
+- Тело SKILL.md (Steps/Failure modes/etc.) дописано и соответствует реальности.

.tasks/task-loop-skill.md

@@ -0,0 +1,45 @@
+# task-loop-skill
+
+## Goal
+Write a new skill `task-loop` for interactive Claude Code sessions: the agent in an open
+session claims tasks from the board and works them one-by-one **in that same session** —
+no separate daemon, no spawned claude processes. Empty queue → stop and report (never
+busy-poll). The skill must coordinate with `using-tasks` v1.4.0 (session `.tasks/.lock`,
+`session_break` gate, 10-min claim TTL → `tasks_heartbeat`) and `project-discipline`
+(push-gate Rule 4, sensitive artifacts).
+
+## Key files
+- `skills/task-loop/SKILL.md` — the deliverable (to be created)
+- `skills/using-tasks/SKILL.md:120-179` — session-lock guard + session-break + completion gates the loop must honor
+- `skills/project-discipline/SKILL.md` — push Rule 4, sensitive-artifact gates
+- `skills/delegate-task/SKILL.md` — sibling task-system skill (style reference)
+- projects-meta tools: `tasks_claim_next` (returns slug/weight/claim_token/consult_policy), `tasks_close`, `tasks_update`, `tasks_heartbeat`
+
+## Decisions log
+Reverse-chronological. Append-only.
+- 2026-06-11: **RED baseline run** (2 clean-context subagents, dry-run, no live tools). Finding: ecosystem already produces mostly-correct behavior (no busy-wait on empty, pointed heartbeat, parks blocked tasks, push only on grant). Real gaps the skill must close: (A) **claim scope diverged** — agent-1 used `filter={}` cross-federation, agent-2 `{project:current}`; (B) **both missed session-break gate** between tasks; (C) **both ignored `.tasks/.lock`**; (D) **autonomy vs sensitive-gate boundary unclear** — agent-1 injected an unasked confirmation stop on a CI task; (E) **paused vs blocked** — spec said paused, agent-2 chose `blocked` for an external blocker (more correct).
+- 2026-06-11: Design resolutions (recommend-don't-menu, no user objection to proposal):
+  - Scope default = **current project** (`filter={project:<current>}`); multi-project only via explicit arg / POLLER_PROJECTS.
+  - Autonomy gate via **`consult_policy`** from claim: `auto`→full autopilot; `human-only`/`strict-human`→do the work but STOP before the irreversible step (commit/close) to consult. `weight:needs-human` never reaches the loop (server excludes from autonomous claim). Push never automatic (project-discipline Rule 4).
+  - Failed task: external/unresolvable blocker → `tasks_update status=blocked` + blocker note (frees claim, don't leave hanging, don't `close`, roll back partial work); interrupted/resumable-by-me → `status=paused`. (Refines acceptance #3 literal "paused".)
+  - Empty queue → STOP + report. `ScheduleWakeup` ONLY on explicit "работай пока не скажу стоп", interval ≥1200s.
+  - session-break: after each close, BEFORE next claim, honor `using-tasks` session_break marker → STOP. Loop delegates this gate, doesn't reimplement.
+  - Heartbeat: single task expected >~8 min → `tasks_heartbeat(slug, claim_token)`.
+
+## Open questions
+- [x] Sensitive-task confirmation driven by `consult_policy` (the contract) + project-discipline push-gate for the riskiest step — NO blanket overlay. Resolved: compliance test B confirmed the `human-only` gate stops before close/commit correctly; push stays ask-mode regardless. consult_policy=auto means autopilot through close (push still needs a grant).
+
+## Completed steps
+- [x] Claimed task (meta status=active, commit 9168a14), synced local
+- [x] Read mandatory skills: writing-skills, test-driven-development
+- [x] Recon: skills/ layout, heartbeat refs, using-tasks session-lock section, claim/close tool schemas
+- [x] RED baseline: 2 subagents, gaps A–E documented above
+- [x] GREEN: wrote skills/task-loop/SKILL.md v0.1.0 (desc trimmed of workflow summary per CSO rule)
+- [x] GREEN compliance: 2 subagents. B (blocked/consult/break) PERFECT — all gaps A–E fixed (scope=current, human-only→stop-before-close, session_break halts drain, external→blocked not close, empty→stop). A (scope/empty/watch) clean EXCEPT chose CronCreate for long-watch → loophole.
+- [x] REFACTOR: long-watch carve-out reworded to mandate ScheduleWakeup (same session) and forbid CronCreate (separate session=daemon) always; core/What-NOT/red-flags aligned. Re-test PASSED — agent picks ScheduleWakeup 1800s, rejects CronCreate with correct reasoning.
+- [x] Acceptance 1-6 all met (see commit). TDD cycle RED→GREEN→REFACTOR complete.
+
+## Notes
+- `heartbeat-side-channel` skill referenced in acceptance #4 does NOT exist — resolved by documenting `tasks_heartbeat` usage directly.
+- Installed `~/.claude/skills/using-tasks` appears older than repo source (no session-lock) — deployment gap, not this task's concern. Write the skill against the repo source (v1.4.0).
+- Notify target on close: OpeItcLoc03/workshop.

.tasks/using-markitdown-mcp-deregister.md

@@ -0,0 +1,63 @@
+# using-markitdown-mcp-deregister
+
+<<<<<<< HEAD
+## Decision trail
+
+### consult 1 — 2026-06-09T17:54:15.313Z
+- question: Полностью decommission'ить markitdown MCP (удалить mcpServers.markitdown из ~/.claude.json + снести контейнеры + опц. удалить образ), или оставить MCP-тул и закрыть таску как wontfix?
+- blast_radius: cross-cutting
+- decided_by: human-required
+- ruling: —
+- rationale: escalated: consult_policy=human-only routes any consult straight to a human (arbiter + round-table skipped)
+
+Resume-brief (self-contained — a fresh agent resumes from this alone):
+- done: Прочитал контекст (.tasks/STATUS.md блок using-markitdown-mcp-deregister, .wiki/concepts/using-markitdown-cli-migration.md). Подтвердил фактическое состояние: mcpServers.markitdown есть в ~/.claude.json строки ~3221-3234, контейнер kind_cohen респаунился (Up 58s), образ markitdown-mcp:latest 1.52GB на месте.
+- where_stopped: Перед мутацией ~/.claude.json — не трогал ни конфиг, ни контейнеры, ни образ.
+- why_blocked: needs-human keep-or-drop решение + cross-cutting правка user-global конфига; нельзя гадать.
+- question: Полностью decommission'ить markitdown MCP (удалить mcpServers.markitdown из ~/.claude.json + снести контейнеры + опц. удалить образ), или оставить MCP-тул и закрыть таску как wontfix?
+- a_short_answer_must_close: Нужен ли ещё MCP-тул markitdown. Нет → удаляю запись+контейнеры (образ по выбору). Да → закрываю wontfix.
+- escalation_chain: brief → consult-policy:human-only
+=======
+## Goal
+Полный decommission markitdown MCP: удалить `mcpServers.markitdown` из `~/.claude.json`,
+иначе каждая новая сессия, грузящая MCP, респаунит анонимный контейнер из
+`markitdown-mcp:latest`, и критерий #2 импл-таски `using-markitdown-cli-rewrite`
+(«`docker ps` не показывает markitdown») недостижим durably.
+
+## Key files
+- `~/.claude.json` — `mcpServers.markitdown` (stdio→docker, bind-mount `C:\Users\vitya`,
+  образ `markitdown-mcp:latest`). Запись ~строки 3221-3234.
+- `.wiki/concepts/using-markitdown-cli-migration.md` — §Out of scope флагнул этот follow-up.
+- `skills/using-markitdown/SKILL.md` — уже переписан на CLI (v1.0.1), MCP больше не советует.
+
+## Verified state (2026-06-09)
+- `mcpServers.markitdown` присутствует в `~/.claude.json` (подтверждено grep).
+- Контейнер `kind_cohen` респаунился (Up ~1m на момент проверки) — respawn-loop живой.
+- Образ `markitdown-mcp:latest` = 1.52 GB на месте.
+- Тул `mcp__markitdown__convert_to_markdown` всё ещё доступен в сессии.
+
+## Decisions log
+- 2026-06-09: Запросил `consult` (keep-or-drop MCP + cross-cutting правка user-global
+  конфига). Вернулся `status:"halt"` — `consult_policy=human-only`, вопрос припаркован
+  человеку (decided_by=human-required). НЕ гадаю past halt; checkpoint + stop per task
+  instructions. Trail_ref: этот файл #decision-trail.
+
+## Open questions
+- [ ] **Нужен ли ещё MCP-тул `mcp__markitdown__convert_to_markdown` (вне скила)?**
+  - Нет → удалить `mcpServers.markitdown` из `~/.claude.json`, затем
+    `docker rm -f $(docker ps -aq --filter "ancestor=markitdown-mcp:latest")`,
+    опц. `docker rmi markitdown-mcp:latest` (1.52 GB).
+  - Да → закрыть таску как **wontfix** (критерий #2 импл-таски = "removed at impl time",
+    respawn — by design).
+
+## Resume brief (для свежей сессии после ответа человека)
+- **done:** прочитан контекст, подтверждено фактическое состояние (см. Verified state).
+- **where_stopped:** перед мутацией `~/.claude.json` — конфиг/контейнеры/образ не тронуты.
+- **why_blocked:** needs-human keep-or-drop + cross-cutting правка user-global конфига.
+- **answer_closes:** нужен ли ещё MCP-тул markitdown. Нет → удаляю запись+контейнеры
+  (образ по выбору). Да → wontfix.
+
+## Notes
+- Удаление обратимо (запись можно вернуть через setup-skill), но трогает глобальный
+  конфиг всех проектов/сессий — потому needs-human, не сане-дефолт.
+>>>>>>> 1bc7615 (meta(tasks): park [using-markitdown-mcp-deregister] for human (consult halt))

.tasks/using-yt-tools-rate-limit-guard.md

@@ -0,0 +1,19 @@
+# using-yt-tools-rate-limit-guard
+
+## Decision trail
+
+### consult 1 — 2026-06-08T12:58:42.510Z
+- question: The task [using-yt-tools-rate-limit-guard] (registered in claude-skills/.tasks) says to add a "don't batch requests at YouTube" rule to `claude-skills/skills/using-yt-tools/SKILL.md`. But since the task was created (2026-05-31), that file became a deprecated inert stub — the canonical skill content migrated to the OpeItcLoc03/yt-tools plugin repo (~/projects/yt-tools/, v0.6.0). Should I apply the fix in the plugin repo (the only place it has effect) instead of the dead stub, commit there, and update the task accordingly?
+- blast_radius: cross-cutting
+- decided_by: human-required
+- ruling: —
+- rationale: escalated: consult_policy=human-only routes any consult straight to a human (arbiter + round-table skipped)
+- escalation_chain: brief → consult-policy:human-only
+
+### consult 2 — 2026-06-08T12:59:08.208Z
+- question: Task names claude-skills/skills/using-yt-tools/SKILL.md as the edit target, but that file is now a deprecated inert stub (v0.4.1) — canonical skill content migrated to the OpeItcLoc03/yt-tools plugin repo (~/projects/yt-tools/, v0.6.0). Should the rate-limit-guard fix be applied in the plugin repo instead, committed there, and the claude-skills task closed with a redirect note?
+- blast_radius: cross-cutting
+- decided_by: human-required
+- ruling: —
+- rationale: Parked for human (consult_policy=human-only). Worker recommendation on resume: apply in plugin repo — the stub explicitly states all future changes ship with the plugin distribution and has no body sections to edit; the plugin SKILL.md (v0.6.0) contains the exact sections the task references, including the literal "Don't retry on `yt-dlp` failures" bullet the task asks to extend rather than duplicate. Three asks map cleanly: (1) new What-NOT-to-do bullet on not batching/parallel-firing requests → HTTP 429 IP-block, placed adjacent to & cross-referencing the no-retry bullet; (2) new Failure-modes row for HTTP 429 / "blocking requests from your IP" (distinct from yt-dlp source download failed); (3) optional Inputs/Flow A note on --lang en-US,en fallback. Bump PATCH 0.6.0→0.6.1 in plugin repo. No edits made to either repo pending human ruling.
+- escalation_chain: brief → consult-policy:human-only

.wiki/concepts/delegate-task-negative-trigger-fp.md

@@ -0,0 +1,63 @@
+---
+title: delegate-task — literal negative triggers beat abstract carve-outs
+type: concept
+updated: 2026-06-17
+---
+
+# delegate-task — literal negative triggers beat abstract carve-outs
+
+## Symptom
+
+`delegate-task` v0.2.0 false-positive-fired on **«создать задачу себе»** (create a task
+for myself) — a self-assigned task that should route to `using-tasks`, not to cross-agent
+delegation. The `delegate-task-test-trigger` run measured it at **5/5 trials** consistently
+wrong (→ `delegate-task`).
+
+## Root cause
+
+The positive trigger list contained **«создать задачу на агента»**. A self-task phrase
+**«создать задачу себе»** shares the stem **«создать задачу»**, so it literal-matched the
+positive trigger. The negative clause was abstract — *"Does NOT apply when doing the work
+yourself"* — and an abstract carve-out does **not** beat a literal stem-match under the
+`using-superpowers` 1%-rule. Clean-context subagents *recognized* the «себе» exception in
+their reasoning, yet still invoked `delegate-task` FIRST because the literal match outweighed
+the abstract exclusion.
+
+## Fix (v0.2.0 → v0.2.1, PATCH)
+
+Make the negative **literal and routed**, so it competes head-on with the positive at the
+same surface level:
+
+> Does NOT apply to self-assigned tasks on your own board (**«создать задачу себе»**,
+> **«task for myself»**, **«поставить себе задачу»** → using-tasks), to work you do
+> yourself, or to workshop-internal tasks.
+
+Plus a body disambiguator in the "Не применяется" section:
+**«на агента» / «агенту» / «в проект X» = делегирование; «себе» / «myself» = своя доска.**
+
+## Verification
+
+Re-ran the `delegate-task-test-trigger` methodology (fresh-context subagents, simulated
+available-skills registry with the new description + competitors `using-tasks` /
+`using-projects-meta` / `setup-tasks` / `session-handoff`, no hint about the expected
+answer):
+
+- **Positives 5/5** — «создать задачу на агента», «поставить задачу агенту», «delegate task
+  to the books project», «делегировать таску», «tasks_create для проекта X» → all
+  `delegate-task`. No regression from the literal negative.
+- **Negative «создать задачу себе на завтра» 4/5 → `using-tasks`** (was 0/5 before the fix).
+  The single residual miss reasoned correctly («себе» → using-tasks) but was tripped by an
+  eval-harness artifact (the prompt forced a skill name on line 1 *before* reasoning),
+  not by ambiguity in the description.
+
+## Reusable principle
+
+When a skill's positive triggers contain a phrase whose **stem** also appears in a sibling
+skill's domain, an abstract "does NOT apply when…" clause is too weak. Put the **exact
+colliding negative phrase** in the description with an explicit **→ <sibling-skill>** route.
+Literal beats abstract under the 1%-rule. See also [[tdd-criteria-design]] for another
+"make the bright line literal, not a judgement call" pattern.
+
+See [[session-inbox-monitor-received-msg-fp]] for the next clause: a literal+routed negative
+still fails if its **route target isn't installed** — the carve-out then has no real competitor
+and the nearest in-domain skill wins anyway.

.wiki/concepts/delegate-task-review-weight.md

@@ -0,0 +1,43 @@
+---
+title: delegate-task review-task weight inheritance
+type: concept
+tags: [delegate-task, fleet-routing, review-task, weight]
+updated: 2026-06-09
+---
+
+# delegate-task review-task `weight` inheritance
+
+`delegate-task` v0.2.3 makes Step 5 (the paired `<slug>-review` task) set an explicit `weight`,
+inherited from the impl-task with a `needs-claude` floor.
+
+## Problem
+
+Step 5 created the review task with `status=blocked` + `blocker=<slug>` but **never set `weight`**.
+A review task with no weight is invisible to fleet routing — the reconciler/poller skips it, so it
+never gets claimed. This surfaced as commit `c0af151` ("add Weight: needs-claude to 4 review tasks
+— reconciler was skipping them"), a manual after-the-fact patch of the symptom. The root cause was
+in the authoring skill: it omitted the field.
+
+## Design
+
+Step 5 now sets the review-task weight by **inheriting from the impl-task, floored at `needs-claude`**:
+
+- impl `needs-human` → review `needs-human` — a critical-infra change cannot be reviewed by a weaker
+  tier; the review inherits the impl's strictness.
+- impl `needs-claude` → review `needs-claude`.
+- impl `cheap-ok` → review `needs-claude` — the floor. Review is discipline-critical (it must honour
+  the `invoke` instructions and acceptance criteria), and the skill's own "What NOT to do" already
+  forbids `cheap-ok` for review/security/migration tasks. So `cheap-ok` is never propagated.
+
+### Why a floor, not pure inheritance
+
+The delegating task said "inherit weight from impl". Pure inheritance would let a `cheap-ok` impl
+produce a `cheap-ok` review — directly contradicting the skill's existing "What NOT to do" bullet
+(no `cheap-ok` for review) and the `needs-claude` convention the manual fix established. The floor
+is the reading that keeps the document internally consistent: inherit upward (so `needs-human`
+propagates), clamp the bottom (so review never drops below `needs-claude`).
+
+## Versioning
+
+PATCH bump (0.2.2 → 0.2.3): tightens guidance on an existing step, no new step or breaking change.
+Target version fixed by the delegating task.

.wiki/concepts/delegate-task-session-break.md

@@ -0,0 +1,46 @@
+---
+title: delegate-task session_break field
+type: concept
+tags: [delegate-task, using-tasks, autonomous-runner, session-boundary]
+updated: 2026-06-09
+---
+
+# delegate-task `session_break` field
+
+`delegate-task` v0.2.2 adds an optional `session_break` field to the task-body template, plus
+a sixth pre-flight question. This is the **authoring** side of the marker whose **consumer**
+side lives in `using-tasks` — see [[using-tasks-session-break]].
+
+## Problem
+
+`using-tasks` v1.2.0 can stop an autonomous runner after a task closes (instead of chaining
+`tasks_claim_next`) **iff** the closed task carries a `session_break` marker. But nothing in the
+delegation flow prompted the author to set it — so the capability sat unused unless someone
+hand-edited the task body. The marker has to be *placed at delegation time* to be useful.
+
+## Design
+
+- **Pre-flight Q6** (after Q5 `notify`): *"Session-break после этой задачи? — нужен ли разрыв
+  сессии после её закрытия (domain-switch, milestone, heavy infra)?"* If yes → set
+  `session_break` in the task body; if no → omit it (default unchanged).
+- **Template field** (optional, in the trailer next to `weight` / `notify` / `allow_upgrade`):
+  `session_break: true | "<следующий трек / hint>"` with an inline comment pointing at the
+  `using-tasks` stop behaviour. `session_break` (lowercase, underscore) is the same frontmatter
+  key `using-tasks` reads.
+- **Value:** `true` (next track = "см. STATUS.md") or a hint string naming the next track.
+
+## When to set it (three cases)
+
+1. **Смена домена / репо** — the task ends one track before an unrelated one begins.
+2. **Milestone-задача** — the last sub-task in a feature's group.
+3. **Тяжёлая инфра-задача** — shared checkout, migrations, deploy — where it's sane to stop and
+   inspect state before continuing.
+
+Not a default: setting it routinely would make `using-tasks` tear the session after every
+close. It is a marker of a *real* boundary, an authoring choice — same rationale as the
+consumer-side "marker not heuristic" argument in [[using-tasks-session-break]].
+
+## Versioning
+
+PATCH bump (0.2.1 → 0.2.2): additive optional field + one extra pre-flight question, no existing
+behaviour changed. (The version target was fixed by the delegating task.)

.wiki/concepts/session-inbox-monitor-received-msg-fp.md

@@ -0,0 +1,79 @@
+---
+title: session-inbox-monitor — a routed negative only competes if its sibling is installed
+type: concept
+tags: [skill-triggers, false-positive, trigger-discrimination, test-trigger]
+updated: 2026-06-17
+---
+
+# session-inbox-monitor — a routed negative only competes if its sibling is installed
+
+Sibling of [[delegate-task-negative-trigger-fp]]. Same failure family (a skill
+false-positive-fires on a phrase its description tries to exclude), but a **distinct
+mechanism** — and it stays **open** as of this writing (follow-up task
+`session-inbox-monitor-received-msg-fp`, not yet fixed).
+
+## Symptom
+
+In the `session-inbox-monitor-test-trigger` run (2026-06-17, clean session, 7 unprimed
+clean-context subagents), the negative phrase **«В .claude-inbox пришло сообщение от другой
+Claude-сессии. Прочитай его и ответь отправителю.»** (N1, RU) routed to
+**`session-inbox-monitor`** — a false-positive. The skill is about *raising the monitor*, not
+*handling a received message*; the latter belongs to inter-session-peer-discipline /
+the CLAUDE.md inter-session rule.
+
+The English twin of the same scenario (N3, «A message arrived in my inbox … handle it and
+reply») and the multi-machine-backend negative (N2) both routed to `none` cleanly, citing the
+carve-out. So the FP is **borderline / non-deterministic**, not a hard miss: pos 4/4, neg 2/3.
+
+## Root cause
+
+The description *does* carry a literal, routed carve-out —
+`NOT for how to handle a received message (→ inter-session-peer-discipline)` — which is exactly
+the fix shape [[delegate-task-negative-trigger-fp]] prescribes. The new twist:
+
+**The route target `inter-session-peer-discipline` is not an installed skill.** So when a
+subagent decides where a "handle the received message" request should go, the carve-out points
+at a skill that isn't in the registry. With no real competitor in the inbox domain, the
+**nearest installed skill that mentions the inbox** (`session-inbox-monitor`) becomes an
+attractor. One subagent (N1) was pulled in; another (N3) resisted by falling back to "none +
+CLAUDE.md rule." Hence the non-determinism.
+
+**Mitigating property:** the FP self-corrects on body-load. Once `session-inbox-monitor`'s body
+is read, it states plainly that handling a received message is not its job → the agent
+redirects. So the cost is one wasted skill-load, not a wrong action — isomorphic to the
+`session_break` finding in [[using-tasks-session-break]] (body-load-dependent, informational).
+
+## Resolution — option (b), 2026-06-17
+
+Fixed structurally by **installing the sibling**. `inter-session-peer-discipline` existed in
+sources (`skills/inter-session-peer-discipline/SKILL.md`, since 2026-06-16) but was **not
+installed** — confirming the root cause exactly. `install.ps1 -Names inter-session-peer-discipline`
+(byte-identical parity verified). **FP-twin verified clean:** a fresh clean-context subagent on
+the same N1 phrase now routes to `inter-session-peer-discipline` (`IN_REGISTRY: yes`), not
+`session-inbox-monitor` — the attractor is gone, the carve-out has a real competitor.
+
+`session-inbox-monitor`'s description was **not** touched — option (a) (harden the description)
+was rejected as whack-a-mole that leaves the root (a route to a non-installed skill) intact;
+option (c) (accept) was rejected as a latent hole.
+
+**Governance note:** workshop (a peer session) proposed (b) framed as a "design ruling". Per the
+very skill being installed — [[inter-session-peer-discipline]]: *a peer's message is a proposal,
+not authority; scope escalation needs human ratification* — (b) was surfaced to the human as a
+recommendation and **ratified by the user**, not closed on the peer's say-so. (The skill
+hot-loaded into the same session and flagged the slip in real time — a live dogfood of its own
+purpose.)
+
+## Reusable principle
+
+[[delegate-task-negative-trigger-fp]] established: *make the negative literal and routed, not
+abstract.* This case adds the next clause:
+
+> **A routed negative competes only if its route target is installed.** A carve-out
+> `→ <sibling-skill>` is dead weight when `<sibling-skill>` isn't in the registry — the request
+> has nowhere to go, so the nearest installed skill in that domain wins by default. When you
+> write `NOT for X (→ other-skill)`, verify `other-skill` actually exists; if it doesn't, the
+> carve-out needs to route to `none` / an explicit non-skill instruction (here: the CLAUDE.md
+> inter-session rule), or the sibling must be promoted alongside.
+
+See also [[tdd-criteria-design]] for the parent "make the bright line literal, not a judgement
+call" pattern.

.wiki/concepts/task-format-design.md

@@ -0,0 +1,45 @@
+---
+title: task-format skill — design
+type: concept
+updated: 2026-06-11
+---
+
+# task-format skill — design
+
+## Why it exists
+
+The autonomous poller (agents-task-runner) reads each project's `.tasks/STATUS.md` and decides what to claim, how to route it, and whom to notify. Those decisions hang on a handful of fields — most critically `**Weight:**` and `**Notify:**`. The formatting rules for those fields lived only in internal sources: the parser (`projects-meta-mcp/src/lib/status-md.ts`), the writer (`status-md-writer.ts`), and the ops runbook (`.common/.wiki/concepts/agents-task-runner-ops.md`).
+
+The wiki is internal; **skills ship with `factory` to external users**. An external operator pointing the poller at their own board has no access to the wiki or the MCP source — so the on-disk task-block format had no public, copy-pasteable reference. `task-format` is that reference.
+
+## Scope — and why it's a separate skill
+
+Three adjacent skills, deliberately not merged:
+
+- **`delegate-task`** — workflow for creating a task for *another* project/agent via `mcp__projects-meta__tasks_create`. The tool emits the field format for you; the skill is the pre-flight gate + body template.
+- **`using-tasks`** — policy for *working* an existing board (claim / switch / close / per-task files).
+- **`task-format`** (this skill) — the **byte-level field format** the poller parses, for *hand-edited* STATUS.md blocks and for understanding what `tasks_create` produces.
+
+A hand-edit scenario triggers none of the other two: `delegate-task` is about the MCP tool, `using-tasks` is about board mechanics, neither documents the exact header regex / Weight vocabulary / Notify line. Hence a focused reference skill.
+
+## Ground truth (sources of record)
+
+- Header regex `TASK_HEADER = /^##\s+(\S+)\s+\[([^\]]+)\]\s+—\s+(.+)$/u` and all `**Field:**` regexes — `status-md.ts`.
+- Canonical field order and the writer — `status-md-writer.ts` (`formatTaskBlock`).
+- Claim gate: only `weight === 'needs-human'` is excluded at claim; capability/runtime gates — `claim.ts` `selectClaimableTask`.
+- **Missing-Weight behavior:** the claim gate does *not* reject a weightless task, but the fleet router (`fleet-router.js` `resolveBackend`) finds no backend for an `undefined` tier, so the poller parks it to 🔵 blocked (`no backend for weight_tier: unknown`) and inboxes Notify. Net effect — confirmed by source, not folklore — a task without Weight does not run. The skill states this as the operative rule.
+- Notify resolution + inbox write — `crossProjectAgentPoller.js` `makeInboxWriter`.
+
+## TDD record (per `superpowers:writing-skills`)
+
+**RED** — 3 baseline subagents, no skill, asked to author a poller-claimable STATUS.md block (ordinary work ×2, critical-infra ×1). Failures: 2/3 used `### `/bullet-list headers the parser cannot recognize as a task at all; 2/3 omitted `**Weight:**` entirely (invented `risk: low`, `tier: L`, `claimable-by`); 2/3 put the notification in prose instead of a `**Notify:**` field; 1/3 used 🟢 (done) for a ready task. The one partial success only got Weight/Notify right because it *read the board* and found the spec — a crib an external user lacks.
+
+**GREEN** — 2 fresh subagents with the skill loaded, same scenarios. Both produced parser-valid blocks: correct `## ⚪ [slug] —` header, `**Field:**` lines, `**Weight:**` + `**Notify:**`. The critical-infra agent correctly chose `**Weight:** needs-human` in canonical vocabulary (baseline had invented `tier: L` / `auto: ❌`).
+
+**REFACTOR** — no new format loopholes surfaced; the skill maps every documented RED failure to a Common-mistakes row.
+
+## Decisions
+
+- **Version 0.1.0** — new skill; project-discipline Rule 3 first-version clause (matches `delegate-task` starting at 0.x).
+- **Reference skill, ~900 words** — exceeds the <500 word target for frequently-loaded skills, justified: it loads only when authoring/editing a task block, and a field reference needs the full table to be useful.
+- The `needs-human` critical-infra list mirrors `delegate-task` pre-flight Q0 and the ops runbook's "Critical-infra защита" — kept consistent on purpose.

.wiki/concepts/using-markitdown-cli-migration.md

@@ -0,0 +1,58 @@
+---
+title: using-markitdown — MCP → CLI migration
+type: concept
+updated: 2026-06-09
+---
+
+# using-markitdown — MCP → CLI migration
+
+`using-markitdown` v1.0.0 → v1.0.1 (PATCH). Rewrote the skill from the Docker-based
+`mcp__markitdown__convert_to_markdown` MCP tool to the native `markitdown` CLI (v0.1.6,
+on `PATH`).
+
+## Why
+
+The MCP path ran markitdown inside a Docker container with a single host directory
+bind-mounted (`-v C:\Users\vitya:/workdir`). That forced a brittle host→container path
+translation for every local file (`file:///workdir/...`), and the failure mode
+(`[Errno 2] No such file or directory: '/c:/Users/...'`) was a recurring foot-gun. The
+container also could not see files outside its one mount.
+
+The CLI is a normal local process: it sees the full host filesystem, takes a plain path
+or URL as its positional arg, and writes markdown to stdout (or to a file with `-o`). No
+mount, no path rewriting, no `file://` URIs. The whole "Docker-mount caveat (READ FIRST)"
+section of the skill became dead weight and was removed.
+
+## CLI contract
+
+```
+markitdown <path|url>            # → markdown to stdout
+markitdown <path|url> -o out.md  # → write to a file
+cat file.pdf | markitdown -x pdf # → stdin + format hint
+```
+
+Verified on this machine: `markitdown 0.1.6`; URL fetch (`markitdown https://example.com`)
+and stdout conversion both work.
+
+## Container cleanup gotcha
+
+The task asked to run `docker stop markitdown-mcp && docker rm markitdown-mcp`. There was
+**no container named `markitdown-mcp`** — the MCP server spawns a fresh anonymously-named
+container from the `markitdown-mcp:latest` image per session, and three had piled up
+(`sharp_jones`, `boring_goldberg`, `admiring_kowalevski`, ages 47s–28h). The correct
+decommission is by image ancestor, not by name:
+
+```
+docker rm -f $(docker ps -aq --filter "ancestor=markitdown-mcp:latest")
+```
+
+(Stopping them races with the server's own `--rm` cleanup, briefly leaving "Dead"
+containers that finish removing themselves — re-checking the filter confirms none remain.)
+
+## Out of scope / follow-up
+
+The `markitdown` **MCP server registration** in `~/.claude.json` was left untouched (the
+task scoped only the running container, and editing user-global config is cross-cutting).
+While that entry remains, a new container will respawn on the next session that loads the
+MCP. A full decommission would deregister `mcpServers.markitdown` from `~/.claude.json` —
+recommended as a separate, explicitly-confirmed step.

.wiki/concepts/using-system-snapshot-design.md

@@ -0,0 +1,98 @@
+---
+title: using-system-snapshot skill design
+type: concept
+updated: 2026-06-09
+---
+
+# using-system-snapshot skill design
+
+New policy+technique skill (v0.1.0) wrapping the single MCP call
+`mcp__projects-meta__meta_system_snapshot`. Replaces the old scatter of
+`tasklist` + `docker ps` + a manual `meta_status` read with one round-trip for
+session-start ops orientation.
+
+## Why a skill
+
+The failure mode it guards: an agent asserts "the poller is running" / "all
+containers are up" / "you have N active tasks" from memory or a stale earlier
+snapshot, without re-checking. The skill makes the rule explicit — **no claim
+about poller / local-docker / task-load state without calling the tool in the
+current turn**. Mirrors the read-only, no-grant posture of [[using-vds-ops]].
+
+## Tool output shape (verified live 2026-06-09)
+
+Three keys:
+
+- `poller`: `{ running: bool, projects: "<owner/repo …>" }` — **live**.
+- `docker`: `[{ name, status }]` — **local** machine containers (includes
+  `agents-task-runner-*`), NOT the VDS. Status strings like `Up 4 hours`,
+  `Up 26 hours (healthy)`; problems show as `Restarting` / `Exited` /
+  `(unhealthy)` / `Created` / `Paused`. **live**.
+- `tasks`: `{ "<owner>/<repo>": { active, blocked } }` — **from the
+  projects-meta cache**, so approximate.
+
+## Design decisions
+
+- **Output = three lines, one per section** (per task spec). Docker line reports
+  `N/N up` when all healthy, else lists only the bad containers; tasks line gives
+  Σ active / Σ blocked + the busiest 2–3 projects. Never dump raw JSON.
+- **Liveness split made explicit.** Poller + docker are read at call time; task
+  counts come from the cache. The skill tells the agent to flag task-count
+  staleness and defer precise per-task work to [[projects-meta-skills]]
+  (`using-projects-meta` Step 0 freshness gate, or local `.tasks/` on disk).
+- **Scope boundaries.** Deep single-container diagnosis (logs/inspect/stats) is
+  explicitly out — that's [[using-vds-ops]] for the VDS or `docker logs`
+  locally. The snapshot only carries name + status.
+- **Read-only, no per-session grant** — same as [[using-vds-ops]]. The tool
+  takes no args; no preview/confirm dance (unlike the projects-meta mutations).
+
+## Prerequisites
+
+Needs `mcp__projects-meta__meta_system_snapshot` (shipped by `projects-meta-mcp`;
+the `meta-system-snapshot` capability lives in `OpeItcLoc03/common`). If the tool
+is absent, the server isn't registered → `setup-projects-meta`.
+
+## TDD note
+
+Markdown policy artifact — no code/test surface (consistent with sibling skill
+tasks). Behavioral trigger smoke-test is the paired `skill-using-system-snapshot-review`
+task, not this implementation task.
+
+## Review outcome (2026-06-09, `skill-using-system-snapshot-review`)
+
+**Verdict: PASS** on all three acceptance criteria. Reviewer was a non-implementer
+session.
+
+- **Tool contract verified live** — a real `meta_system_snapshot` call returned
+  exactly the documented shape (`poller {running, projects}`, `docker [{name,
+  status}]` incl. `agents-task-runner-*` with `Up … (healthy)` strings, `tasks
+  {owner/repo: {active, blocked}}`). The "The call" table and this page are accurate.
+- **Trigger phrases cover real scenarios** ✅ — 9 fresh-context subagents, each
+  given a simulated skill registry (real descriptions + `using-vds-ops` /
+  `using-projects-meta` / `using-tasks` competitors) and one trigger phrase, no
+  hint of the expected answer. 4/4 positives → `using-system-snapshot`; VDS-logs →
+  `using-vds-ops`; mutate/full-board → `using-projects-meta`; `docker-compose.yml`
+  edit → `none` (no false-positive on the "docker" keyword).
+- **No-claim-without-snapshot rule explicit** ✅ — stated in 4 places (Overview
+  core rule, "When to use", "What NOT to do", Common-mistakes table).
+- **Output format brief** ✅ — three-line block, per-line rules, "no raw JSON";
+  confirmed achievable against the live payload.
+
+**Informational findings (none blocking):**
+
+1. **Task-count overlap with `using-projects-meta`.** «сколько активных задач по
+   всем проектам» routed to `using-projects-meta`, not the snapshot. By-design —
+   the skill defers *precise* per-task work and the `tasks` line is a bonus of the
+   combined ops view, not its headline — so no fix. Quick «сводка по задачам …»
+   glances still route here correctly.
+2. **Local-container deep diagnosis is unowned.** «локальный контейнер … почему
+   рестартует» routed to `using-vds-ops` (its incident-phrase triggers grabbed a
+   *local* container, which its VDS-only tools can't reach). Not this skill's
+   defect — the snapshot correctly does not claim deep "why". Candidate
+   `using-vds-ops` scoping follow-up if it recurs.
+3. **Deployment scaffold missing.** The skill is committed (`skills/…`, v0.1.0)
+   but is **not** installed to `~/.claude/skills/`, **not** in
+   `hermes/mapping.yaml`, and has no `-install` / `-hermes-mapping` /
+   `-test-trigger` baseline tasks (unlike `meta-host-routing` / `delegate-task`).
+   Recommended follow-ups before it reaches live sessions; hermes mode could be
+   `auto` since the skill is read-only (owner's call).

.wiki/concepts/using-tasks-session-break.md

@@ -0,0 +1,52 @@
+---
+title: using-tasks session_break marker
+type: concept
+tags: [using-tasks, autonomous-runner, session-boundary]
+updated: 2026-06-09
+---
+
+# using-tasks `session_break` marker
+
+`using-tasks` v1.2.0 adds a `session_break` marker so a task author can mark a task's
+completion as a natural place to **stop**, rather than have an autonomous agent immediately
+chain into the next task via `tasks_claim_next`.
+
+## Problem
+
+An autonomous runner closes a task and, by default, claims the next one. There is no signal
+for "this is a good seam to end the session" — so unrelated tracks get welded into one
+ever-growing context, and the natural review/hand-off moment is skipped.
+
+## Design
+
+- **Marker:** `session_break` in the task's frontmatter (task-system delivery) or the
+  `**Session break:**` field in the task's STATUS.md block (local board mirror).
+- **Type:** boolean or string.
+  - `true` → pause after close; next track is "see STATUS.md".
+  - `"<hint>"` → pause after close; the hint names the recommended next track.
+- **Enforcement point:** `using-tasks` → Task completion, **step 6** — *after* the task is
+  🟢 and committed, *before* any `tasks_claim_next` / starting the next task.
+- **Behaviour when present:** print the SESSION BOUNDARY line verbatim, then stop (do not
+  claim the next task).
+- **Behaviour when absent:** unchanged — claim / start the next task as usual.
+
+### Verbatim message
+
+```
+🔚 SESSION BOUNDARY — [slug] закрыта. Рекомендую завершить текущую сессию. Следующий трек: [value | "см. STATUS.md"]
+```
+
+`[slug]` = the closed task's slug. `[value | "см. STATUS.md"]` = the marker's string value,
+or the literal `см. STATUS.md` when the marker is just `true`. The wording is fixed so the
+boundary is greppable and recognisable across sessions.
+
+## Why a marker, not a heuristic
+
+The decision of *what counts as a stopping point* belongs to whoever scoped the work (the
+delegating workshop), not to the runner mid-flight. A heuristic ("stop after N tasks", "stop
+when tired") would either over- or under-fire. An explicit, opt-in marker keeps the default
+unchanged and makes the boundary a deliberate authoring choice.
+
+## Versioning
+
+MINOR bump (1.1.0 → 1.2.0): new optional capability, no existing behaviour changed.

.wiki/concepts/using-tasks-status-archival.md

@@ -0,0 +1,84 @@
+---
+title: using-tasks done-task archival (STATUS.md bloat fix)
+type: concept
+updated: 2026-06-09
+---
+
+# using-tasks done-task archival
+
+`using-tasks` v1.2.0 → **v1.3.0** (MINOR — new backward-compatible rule). Fixes the recurring
+"huge STATUS.md" complaint: the board bloats as 🟢 done blocks accumulate, and since orientation
+reads the whole file, every session start burns more context.
+
+## The fix that shipped
+
+A **done-task archival rule** in the skill:
+
+- **Threshold:** when `STATUS.md` holds **≥ 10** 🟢 done blocks, archive them.
+- **Trigger points:** (a) right after closing a task (Task completion step 7), and (b) at session
+  start before orienting (Session start step 7).
+- **Target:** append the blocks **verbatim** (with their `---` separators and `<!-- closed-by -->`
+  comments) to `.tasks/archive/YYYY-MM.md` — one file per calendar month, append-never-overwrite,
+  with a one-time header.
+- **Result:** `STATUS.md` keeps only 🔴 / 🟡 / ⚪ / 🔵 blocks. Commit the move on its own
+  (`meta(tasks): archive done batch → .tasks/archive/YYYY-MM.md`).
+
+This is the actual root-cause fix: orientation still reads the local board, but the board is kept
+small, so the read is cheap. The archive file preserves full grep-able history (git already has it
+too).
+
+## Why the task's literal instruction was NOT followed
+
+The originating task ([using-tasks-status-read-perf]) asked to **replace `Read STATUS.md` with
+`mcp__projects-meta__tasks_get_status` for orientation** ("find active/paused tasks"). That rests on
+a factual misunderstanding of the tool and was deliberately **not** implemented as written:
+
+- **`tasks_get_status(target_project, slug)` → `{status, found}`** — returns the live status of a
+  **single** task whose slug you already know. It reads the target's `.tasks/STATUS.md` directly
+  (live, not cached), but it **cannot enumerate** the board. Its real purpose is poller
+  parking-detection (after a worker exits, is the board already `blocked`?). Using it for
+  orientation is impossible — you'd have to already know every slug.
+- **`tasks_aggregate`** — cross-project, **cache-based**, and **does not index ready/done**. Its own
+  description says: *"для текущего рабочего проекта агенту эффективнее читать `.tasks/STATUS.md`
+  напрямую — кэш может быть stale."*
+
+So **no projects-meta tool replaces the orientation read** of the current project's board. The
+honest answer to "find all places where Read STATUS.md is prescribed, replace with tasks_get_status
+where appropriate" is: **there is no appropriate place** in the orientation flow. Instead the skill
+now (1) keeps orientation as a local `STATUS.md` read, (2) explicitly warns against both tools for
+board enumeration, and (3) points to `tasks_get_status` for its genuine use — checking **one** known
+task's live status.
+
+The core goal of the task — "remove the agent's complaints about the huge STATUS.md" — is fully met
+by the archival rule, independent of the tool swap.
+
+## Reusable principle
+
+When a delegated task prescribes a *mechanism* that a tool can't actually perform, fix the *problem*
+(here: board bloat → archive) rather than the literal mechanism. Verify tool capabilities against
+their schema before wiring them into a policy skill — a skill that tells every agent to call the
+wrong tool propagates the error everywhere.
+
+Pairs with [[using-tasks-session-break]] (the prior v1.2.0 increment) and the local-first read rule
+in [[projects-meta-skills]].
+
+## Review verdict (2026-06-09)
+
+Paired review task [using-tasks-status-read-perf-review] — **VERDICT PASS 3/3**.
+
+- **"Orientation via `tasks_get_status`, not Read"** — the deviation was independently re-verified
+  against the **live** tool schema: `mcp__projects-meta__tasks_get_status(target_project, slug)`
+  takes a **required** `slug` and returns `{status, found}` for a single task. It provably cannot
+  enumerate the board, so it cannot drive orientation. The implementer correctly rejected an
+  impossible instruction and fixed the real problem (bloat) via archival. Criterion satisfied by a
+  validated deviation, not by a literal swap.
+- **No regression** — orientation still reads the local `STATUS.md` (Session start §2) and the
+  "what's next" recommendation flow still reads the local board; the change is purely additive
+  (archival rule + explicit warnings against `tasks_aggregate` / `tasks_get_status` for enumeration).
+- **Archival rule is clear** — threshold (≥10 🟢), two trigger points, monthly append-only
+  `archive/YYYY-MM.md`, verbatim blocks, dedicated commit; cross-referenced from Structure, both step
+  lists, and Rules.
+
+Informational, non-blocking: this repo's own `STATUS.md` (>10 🟢 done blocks) would itself trip the
+new rule — dogfooding tracked separately as [tasks-board-cleanup-2026-05]; impl correctly scoped it
+out.

.wiki/index.md

@@ -41,6 +41,15 @@ Catalog of all wiki pages. One line per page, organized by type. Updated on ever
 - [project-bootstrap-meta-isolation.md](concepts/project-bootstrap-meta-isolation.md) — project-bootstrap@1.11.0 — Step 1 ships meta-isolation block in `.gitignore` (`!.claude/`, `!.tasks/`, `!.wiki/`, ...) so own greenfield/upgrade projects re-enable agent meta-paths against global `core.excludesFile` cutter. Marker-based append-only on existing files; smoke-tested with negative control
 - [interns-grep-audit-design](concepts/interns-grep-audit-design.md) — interns-grep-audit-design
 - [session-handoff-skill-design.md](concepts/session-handoff-skill-design.md) — design rationale for the `session-handoff` skill (sliding overwrite into `.tasks/NEXT_SESSION.md`, phrase whitelist + substantive-commit heuristic, optional PostToolUse hook for harness-side determinism, orient+ask default, project scope, cluster 7/7 closure)
+- [using-tasks-session-break.md](concepts/using-tasks-session-break.md) — `using-tasks` v1.2.0 `session_break` marker: task-author-set boolean/string flag; after a task closes 🟢, before `tasks_claim_next`, an autonomous agent prints the verbatim SESSION BOUNDARY line and stops instead of chaining the next task. Absent → unchanged
+- [delegate-task-session-break.md](concepts/delegate-task-session-break.md) — `delegate-task` v0.2.2 — authoring side of the `session_break` marker (consumer = [[using-tasks-session-break]]): pre-flight Q6 + optional template field `session_break: true | "<hint>"`; three set-it cases (domain-switch / milestone / heavy infra); not a default
+- [delegate-task-review-weight.md](concepts/delegate-task-review-weight.md) — `delegate-task` v0.2.3 — Step 5 review-task now sets explicit `weight`, inherited from impl with a `needs-claude` floor (impl `needs-human`→review `needs-human`; `cheap-ok`→`needs-claude`). Fixes the reconciler skipping weightless review tasks (root cause of manual patch `c0af151`)
+- [using-system-snapshot-design.md](concepts/using-system-snapshot-design.md) — `using-system-snapshot` v0.1.0 — thin read-only skill wrapping the single `mcp__projects-meta__meta_system_snapshot` call (poller + local docker + cached task summary); replaces scattered `tasklist`/`docker ps`/manual `meta_status`; core rule = no liveness claim without calling the tool this turn; three-line output; defers deep docker to [[using-vds-ops]] and precise tasks to [[using-projects-meta]]
+- [using-tasks-status-archival.md](concepts/using-tasks-status-archival.md) — `using-tasks` v1.3.0 done-task archival rule (≥10 🟢 → `.tasks/archive/YYYY-MM.md`) fixes STATUS.md bloat; documents why `tasks_get_status` (single-task, by slug) / `tasks_aggregate` (cross-project cache) can't replace the orientation board-read, so the literal task instruction was not followed
+- [delegate-task-negative-trigger-fp.md](concepts/delegate-task-negative-trigger-fp.md) — `delegate-task` v0.2.1 FP fix: «создать задачу себе» stem-matched the «создать задачу на агента» positive trigger; abstract "does NOT apply when doing the work yourself" carve-out loses to literal stem-match under the 1%-rule → made the negative literal + routed (→ using-tasks). Verified pos 5/5, neg 4/5 (was 0/5)
+- [using-markitdown-cli-migration.md](concepts/using-markitdown-cli-migration.md) — `using-markitdown` v1.0.0→v1.0.1 (PATCH): rewrote from the Docker-based `mcp__markitdown__convert_to_markdown` MCP tool to the native `markitdown` CLI (0.1.6, on PATH); dropped the host→container `file://` mount caveat; container decommission is by image ancestor (`--filter ancestor=markitdown-mcp:latest`), not by the non-existent name `markitdown-mcp`
+- [session-inbox-monitor-received-msg-fp.md](concepts/session-inbox-monitor-received-msg-fp.md) — sibling of [[delegate-task-negative-trigger-fp]]: `session-inbox-monitor` FP-fires on RU «обработай полученное письмо» (N1) because its literal+routed carve-out points at `inter-session-peer-discipline`, which **isn't installed** → no competitor, nearest inbox-skill wins. Borderline (neg 2/3, EN twin clean), body-load self-corrects. **Open** (follow-up task). New principle: *a routed negative competes only if its route target is installed*
+- [task-format-design.md](concepts/task-format-design.md) — new `task-format` skill v0.1.0: public reference for the on-disk `.tasks/STATUS.md` block format the poller parses (header regex, status emoji, `**Weight:**` / `**Notify:**` / `**Requirements:**`); ships with `factory` where the internal wiki/MCP-source can't reach; distinct from [[delegate-task]] (MCP-tool delegation) and [[using-tasks]] (board mechanics); RED 3-baseline / GREEN 2-verify per writing-skills; ground truth = `status-md.ts` + `claim.ts` + `fleet-router.js`
 
 ## Packages
 

.wiki/log.md

@@ -65,3 +65,16 @@ Parseable: `grep "^## \[" .wiki/log.md | tail -20`.
 ## [2026-05-25] decision | install-cross-platform — `install.{ps1,sh}` paired-script parity contract documented; `--prune` / `-Prune` flag rationale (combined-with-install, global-scan ignores names filter, default-off, print-and-delete no prompt); shipped in commit `6cf0e98` with `[skip-tdd: wrapper]` carve-out + smoke-test evidence; closes 2/3 of `[install-ps1]` acceptance (the doc + flag), `dist/`-prune analogue deferred to `build` scripts
 
 ## [2026-05-25] decision | install-cross-platform extended to build scripts — `build.{ps1,sh}` get the symmetric `--prune` / `-Prune` flag (removes `dist/<name>.skill` where `<name>` is not in `skills/`). Bash delegation to `powershell.exe -File build.ps1` does NOT forward the flag — bash runs prune itself against the shared `dist/`. Both paths smoke-tested with fake stale .skill files against real dist/. Closes `[install-ps1-build-prune-followup]`.
+
+## [2026-06-09] decision | delegate-task-negative-trigger-fp — `delegate-task` 0.2.0→0.2.1 (PATCH): fixed 5/5-consistent false-positive on «создать задачу себе». Root cause: self-task phrase shares stem «создать задачу» with the «создать задачу на агента» positive trigger; the abstract "Does NOT apply when doing the work yourself" carve-out can't beat a literal stem-match under the 1%-rule. Fix: made the negative literal + routed («создать задачу себе» / «task for myself» / «поставить себе задачу» → using-tasks) in description + body disambiguator («на агента»/«агенту» = delegate; «себе» = own board). Re-verified via fresh-context subagent trigger run: positives 5/5 (no regression), negative 4/5 → using-tasks (was 0/5); the 1 residual miss was an eval-harness artifact (forced skill-name-before-reasoning), not description ambiguity. Concept page written; reusable principle = put the exact colliding negative phrase with an explicit →sibling route, literal beats abstract.
+## [2026-06-09] decision | delegate-task-session-break — `delegate-task` 0.2.1→0.2.2 (PATCH): authoring side of the `session_break` marker (consumer = using-tasks v1.2.0). Added pre-flight Q6 (after notify): "Session-break после этой задачи? (domain-switch / milestone / heavy infra)"; if yes → set optional template field `session_break: true | "<hint>"` (trailer, next to weight/notify/allow_upgrade; same lowercase frontmatter key using-tasks reads). Usage guidance lists three set-it cases; What-NOT-to-do bullet warns against setting it routinely (it's a real-boundary marker, not a default). Wiki concept page concepts/delegate-task-session-break.md + index. Pairs with using-tasks-session-break.
+## [2026-06-09] decision | using-system-snapshot — new skill v0.1.0: thin read-only wrapper over the single `mcp__projects-meta__meta_system_snapshot` call (poller status + local docker containers + cached cross-project task summary). Replaces the scatter of `tasklist` + `docker ps` + manual `meta_status`. Core rule: no claim about poller / local-docker / task-load state without calling the tool in the current turn (memory + stale earlier snapshot ≠ evidence). Output = three lines, one per section (docker lists only problem containers; tasks gives Σ active/blocked + busiest 2–3). Liveness split documented: poller+docker live, tasks from cache (defer precise work to using-projects-meta Step 0). Scope boundaries: deep single-container diagnosis → using-vds-ops / `docker logs`; docker section is LOCAL, not the VDS. Read-only, no per-session grant (mirrors using-vds-ops). Output shape verified by a live call 2026-06-09. Concept page concepts/using-system-snapshot-design.md + index. TDD N/A (markdown policy artifact); behavioral smoke-test = paired skill-using-system-snapshot-review task.
+## [2026-06-09] review | using-system-snapshot v0.1.0 — VERDICT PASS on all 3 acceptance criteria (skill-using-system-snapshot-review). Tool contract verified by a live `meta_system_snapshot` call (output matches the documented `poller`/`docker`/`tasks` shape exactly). Behavioral trigger smoke = 9 fresh-context subagents over a simulated registry (real descriptions + using-vds-ops/using-projects-meta/using-tasks competitors, no expected-answer hint): 4/4 positives → using-system-snapshot; VDS-logs → using-vds-ops; mutate/full-board → using-projects-meta; `docker-compose.yml` edit → none (no FP on "docker" keyword). No-claim-without-snapshot rule explicit in 4 places; three-line output format confirmed achievable against the live payload. 3 informational findings (none blocking): (1) cross-project task-COUNT phrasings overlap with using-projects-meta — by-design, snapshot defers precise per-task work; (2) LOCAL-container deep diagnosis is unowned — vds-ops incident triggers grab local containers its VDS-only tools can't reach (vds-ops scoping, not this skill); (3) deployment scaffold missing — skill committed but not installed to `~/.claude/skills/`, not in `hermes/mapping.yaml`, no -install/-hermes-mapping/-test-trigger baseline tasks; recommended follow-ups (hermes mode could be `auto`, read-only skill). Review outcome appended to concepts/using-system-snapshot-design.md.
+## [2026-06-09] decision | using-tasks-status-archival — `using-tasks` 1.2.0→1.3.0 (MINOR): added done-task archival rule to fix STATUS.md bloat ("huge STATUS.md" complaint). When ≥10 🟢 done blocks pile up — checked at session start (step 7) and after close (Task completion step 7) — move them verbatim to `.tasks/archive/YYYY-MM.md` (append, one file per month, one-time header), leaving only 🔴/🟡/⚪/🔵 on the board; committed on its own. Did NOT follow the task's literal instruction to replace `Read STATUS.md` with `tasks_get_status` for orientation: that tool returns a single task's live status by known slug (`{status, found}`) and cannot enumerate the board, and `tasks_aggregate` is cross-project + cache-based + doesn't index ready/done (its docs say read STATUS.md directly for the current project). So orientation stays a local board-read (kept cheap by archival); skill now warns against both tools for board enumeration and points `tasks_get_status` at its real single-task use. Core goal (kill the bloat) met by archival alone. Concept page concepts/using-tasks-status-archival.md + index. TDD N/A (markdown policy). Deviation flagged for paired review task using-tasks-status-read-perf-review.
+## [2026-06-09] decision | using-tasks-session-break — `using-tasks` 1.1.0→1.2.0 (MINOR): added the `session_break` marker. Task author sets `session_break: true | "<hint>"` in task frontmatter (mirrored as `**Session break:**` on the local board); after the task closes 🟢, before `tasks_claim_next`, an autonomous agent prints the verbatim line `🔚 SESSION BOUNDARY — [slug] закрыта. Рекомендую завершить текущую сессию. Следующий трек: [value | "см. STATUS.md"]` and stops instead of chaining the next task. Absent → behaviour unchanged. Enforced in Task completion step 6 + Rules bullet + format docs. Marker not heuristic: the stop-point is an authoring choice, not a runner guess.
+## [2026-06-09] review | using-tasks-status-archival v1.3.0 — VERDICT PASS 3/3 (using-tasks-status-read-perf-review). Criterion «ориентация через `tasks_get_status`, не Read» is satisfied by a **validated deviation**, not a literal swap: re-verified against the live tool schema that `tasks_get_status(target_project, slug)→{status, found}` takes a required slug and returns ONE task — it cannot enumerate the board, so it cannot drive orientation; the implementer correctly rejected the impossible instruction and fixed the real problem (bloat→archival). No regression: orientation still reads local STATUS.md (Session start §2) and the «what's next» flow still reads the board — change is purely additive. Archival rule clear & complete (≥10 threshold, two trigger points, monthly append-only archive, verbatim blocks, dedicated commit, cross-referenced). One informational non-blocking note: this repo's own STATUS.md (>10 🟢) would itself trip the rule — dogfooding tracked separately as tasks-board-cleanup-2026-05. No follow-up tasks. Verdict appended to concepts/using-tasks-status-archival.md.
+## [2026-06-09] decision | delegate-task-review-weight — `delegate-task` 0.2.2→0.2.3 (PATCH): Step 5 (paired `<slug>-review` task) now sets an explicit `weight`, inherited from the impl-task with a `needs-claude` floor (impl `needs-human`→review `needs-human`; `needs-claude`→`needs-claude`; `cheap-ok`→`needs-claude`). Root cause of commit `c0af151` ("add Weight: needs-claude to 4 review tasks — reconciler was skipping them"): the authoring skill omitted `weight` on review tasks, making them invisible to fleet routing. Floor (not pure inheritance) chosen to stay internally consistent with the skill's own "What NOT to do" bullet that forbids `cheap-ok` for review tasks — a `cheap-ok` impl would otherwise propagate a forbidden `cheap-ok` review. Added a What-NOT-to-do bullet against weightless review tasks. Concept page concepts/delegate-task-review-weight.md + index. TDD N/A (markdown policy artifact).
+## [2026-06-11] decision | task-format — new skill v0.1.0: public reference for the `.tasks/STATUS.md` task-block format the autonomous poller parses. Motivation: the field rules (`**Weight:**` capability/cost tier, `**Notify:** <owner>/<repo>` inbox target, header regex, status emoji) lived only in internal sources (`projects-meta-mcp/src/lib/status-md.ts` parser + `status-md-writer.ts` + `.common/.wiki/concepts/agents-task-runner-ops.md`); skills ship with `factory` to external users, the wiki/MCP-source don't. Scope kept distinct from delegate-task (creates tasks for others via `tasks_create`, the tool emits the format) and using-tasks (board claim/close mechanics) — task-format is the byte-level field reference for hand-edited blocks. Ground truth verified against source: header `/^##\s+(\S+)\s+\[([^\]]+)\]\s+—\s+(.+)$/u`; Weight ∈ {cheap-ok, needs-claude, needs-human}; claim gate excludes only `needs-human` (`claim.ts`), but a *missing* Weight finds no backend tier (`fleet-router.js` resolveBackend) → poller parks to 🔵 blocked, so Weight is operatively required for pickup. TDD per writing-skills: RED = 3 baseline subagents w/o skill (2/3 used `###`/bullet headers the parser can't recognize, 2/3 omitted Weight inventing `risk`/`tier`/`claimable-by`, 2/3 put notify in prose, 1/3 used 🟢 for ready); GREEN = 2 fresh subagents w/ skill, both parser-valid incl. correct `needs-human` for the critical-infra scenario; REFACTOR = no new loopholes. Reference skill ~900 words (loads only when authoring a task block). Concept page concepts/task-format-design.md + index. Not yet installed to `~/.claude/skills/` or added to hermes mapping — deferred follow-up (mirrors using-system-snapshot deployment-scaffold note).
+## [2026-06-09] decision | using-markitdown-cli-migration — `using-markitdown` 1.0.0→1.0.1 (PATCH): rewrote the skill from the Docker-based `mcp__markitdown__convert_to_markdown` MCP tool to the native `markitdown` CLI (v0.1.6, on PATH). Tool block now `markitdown <path|url>` → stdout (or `-o file`); removed the whole "Docker-mount caveat (READ FIRST)" section (host→container `file://` translation + `[Errno 2] /c:/Users/...` symptom are gone — CLI sees the full host FS). Updated the ingest pattern (use `-o` straight into `.wiki/raw/`), the gotchas table (`command not found` → check `markitdown --version`, install `pip install markitdown[all]`; dropped the MCP "tool not available / ToolSearch" row), and the contrast-table header (CLI, not MCP). Description frontmatter (the WHEN-to-use triggers) left unchanged. Container decommission: the task's literal `docker stop/rm markitdown-mcp` had no target — no container is named that; the MCP spawns anonymously-named containers from `markitdown-mcp:latest` per session (3 had piled up). Removed all by image ancestor (`docker rm -f $(docker ps -aq --filter "ancestor=markitdown-mcp:latest")`), verified none remain. Left the `mcpServers.markitdown` entry in `~/.claude.json` untouched (out of scope; a container will respawn next session until it's deregistered — flagged as a follow-up). Concept page concepts/using-markitdown-cli-migration.md + index. TDD N/A (markdown skill).
+## [2026-06-17] decision | session-inbox-monitor-received-msg-fp — finding from `session-inbox-monitor-test-trigger` (VERDICT PASS, clean session, 7 unprimed clean-context subagents: pos 4/4 incl. CLAUDE.md-line P4, neg 2/3). The 1 FP: RU «обработай полученное письмо из инбокса» (N1) routed to `session-inbox-monitor`; the EN twin (N3) and the multi-machine-backend negative (N2) routed to `none` cleanly. Root cause = a new dimension on top of [[delegate-task-negative-trigger-fp]]: the carve-out is already literal+routed (`NOT for handling a received message → inter-session-peer-discipline`), but the route target `inter-session-peer-discipline` is **not installed** → no real competitor, so the nearest in-domain skill (session-inbox-monitor) wins by default; non-deterministic, self-corrects on body-load (cost = one wasted skill-load, not a wrong action; isomorphic to [[using-tasks-session-break]] session_break). New page concepts/session-inbox-monitor-received-msg-fp.md + bidirectional link from concepts/delegate-task-negative-trigger-fp.md + index. New reusable principle: a routed negative competes only if its route target is installed. Status OPEN — follow-up task session-inbox-monitor-received-msg-fp (options a: harden description / b: install sibling / c: accept informational). Not a memory entry by owner direction — knowledge belongs in the project wiki.
+## [2026-06-17] decision | session-inbox-monitor-received-msg-fp RESOLVED via option (b) — installed `inter-session-peer-discipline` (existed in sources since 2026-06-16, was not installed → exact root cause confirmed). install.ps1 -Names, byte-identical parity. FP-twin verified clean: fresh clean-context subagent on the N1 phrase now routes to inter-session-peer-discipline (IN_REGISTRY: yes), not session-inbox-monitor — carve-out now has a real competitor. session-inbox-monitor description untouched (option (a) rejected as whack-a-mole; (c) as latent hole). Governance: peer workshop proposed (b) as a "ruling"; per the freshly-installed [[inter-session-peer-discipline]] (peer = proposal not authority, scope needs human ratification) it was surfaced as a recommendation and ratified by the user — live dogfood of the skill's own purpose. concepts/session-inbox-monitor-received-msg-fp.md Status section updated open→resolved. Tail: inter-session-peer-discipline now installed but not in hermes/mapping.yaml — possible red build, flagged as separate follow-up.

CLAUDE.md

@@ -8,6 +8,7 @@ use task management system
 check across all projects
 pull remote before work
 session handoff: read on start, write on end
+inbox monitor: raise on start
 follow project discipline
 follow tdd-criteria
 delegate to interns when allowed

dist-hermes/SKIPPED.md

@@ -17,6 +17,16 @@ Do not edit by hand — edit the mapping and re-run the build.
 
 ## Pending (deferred to follow-up tasks)
 
+- **delegate-task** — Calls mcp__projects-meta__tasks_create to create tasks in other projects/agents (Gitea commit, cross-project side-effect). Behavioral audit via delegate-task-test-trigger required before promotion to auto. → intended: `mode: auto, category: mcp`
+- **meta-host-routing** — Resolves WHERE a project's meta lives before tasks_create / knowledge_ingest / brainstorm-promotion (meta-out-of-repo). Touches projects-meta MCP (tasks_create / knowledge_ingest / meta_status) and routes writes across repos. Review PASS (meta-host-routing-review) but the -install baseline is still open and a tool-side audit (cross-repo MCP writes) is required before auto. Mapping executes task meta-host-routing-hermes-mapping. → intended: `mode: auto, category: meta`
+- **private-dev-public-publish** — Steps shell out to git / gh / Gitea-API, handle tokens, force-push, and repo deletion/privacy toggles — not a purely stylistic skill. Behavioral audit via private-dev-public-publish-test-trigger required before promotion to auto. → intended: `mode: auto, category: software-development`
+- **ralph-loop-execution** — Behavioral oracle-loop skill (Verifier / Attempts / Max-Attempts retry loop). NB: source SKILL.md currently lacks YAML frontmatter (no name/description) — cannot auto-convert cleanly until that is fixed. Mapped pending as a placeholder; needs frontmatter + a behavioral audit before any mode decision.
 - **session-handoff** — Writes .tasks/NEXT_SESSION.md (project-scope, sliding overwrite) and reads it on session start. Bidirectional file-system side-effect, opt-in via CLAUDE.md trigger-line. Behavioral audit via session-handoff-test-trigger required before promotion to auto. → intended: `mode: auto, category: productivity`
+- **session-inbox-monitor** — Paired SessionStart hook registers itself in ~/.claude/settings.json and sweeps orphaned monitor OS processes (Get-CimInstance | Stop-Process by sentinel+inbox-path); the skill then raises an in-session Monitor on .claude-inbox/. Primary activation is the CLAUDE.md trigger-line `inbox monitor: raise on start` + the injector, not a hermes-trigger. Behavioral gate CLEARED 2026-06-17 — test-trigger + review BOTH VERDICT PASS (activation 3/3 monitor + neg clean; structural hook audit 5 PASS/1 CONCERN, the CONCERN fixed in v0.2.2). STAYS pending on two independent tool-side blockers, NOT on behavioral verification: (1) the SessionStart hook is Windows-PowerShell and needs a Linux port for Hermes factory machines; (2) machine-level side-effects (user-config mutation of ~/.claude/settings.json + Get-CimInstance|Stop-Process kills) need a tool-side audit before auto. Promotion blocked on those two, not on test-trigger/review. → intended: `mode: auto, category: productivity`
+- **setup-agents-task-runner** — L2 installer — installs the standing-duty stack (agents-task-runner + watchdog + appeals-inbox) as platform-native OS services (systemd/launchd/winsw), fetches a pinned binary, writes poller-scope.json. Heavy infra side-effects (OS services + binary fetch); mode decision (skip vs manual vs auto) deferred — needs an explicit Hermes-factory applicability audit. Placeholder pending to keep the build green.
+- **task-format** — Documentational skill — how to write a .tasks/STATUS.md task block the autonomous poller will claim/route/report (block header, status emoji, Weight/Notify/Requirements fields). No tool-side effects; pending a behavioral test-trigger before auto. → intended: `mode: auto, category: productivity`
+- **task-loop** — Orchestrates the board claim/close/update/heartbeat cycle via mcp__projects-meta__tasks_claim_next / tasks_close / tasks_update / tasks_heartbeat (cross-session claim ownership, irreversible close, Gitea side-effects) and may arm a single long ScheduleWakeup for the explicit long-watch opt-in. Critical-infra-adjacent — touches the same claim/close machinery the unattended poller relies on. Behavioral audit via task-loop-test-trigger required before promotion to auto. → intended: `mode: auto, category: mcp`
+- **using-system-snapshot** — Calls mcp__projects-meta__meta_system_snapshot (read-only whole-machine ops snapshot: poller / docker / cross-project task load). Read-only, same class as using-vds-ops / using-wiki-graph; pending a behavioral test-trigger before auto. → intended: `mode: auto, category: mcp`
 - **using-vds-ops** — Calls mcp__vds-ops__* tools (read-only, but touches infrastructure). Behavioral audit via using-vds-ops-test-trigger required before promotion to auto. → intended: `mode: auto, category: mcp`
+- **using-wiki-graph** — Calls mcp__wiki-graph__* tools (read-only, parses a .wiki/ corpus server-side). Behavioral audit via using-wiki-graph-test-trigger required before promotion to auto. → intended: `mode: auto, category: mcp`
 - **using-yt-tools** — Shells out to yt-dlp + ffmpeg and writes ./yt-cache/ in cwd. Behavioral audit via using-yt-tools-test-trigger required before promotion to auto. → intended: `mode: auto, category: research`

dist-hermes/meta/inter-session-peer-discipline/SKILL.md

@@ -0,0 +1,63 @@
+---
+name: inter-session-peer-discipline
+version: 0.1.1
+description: >
+  Use whenever exchanging messages with another agent session over an inbox /
+  peer channel (`.claude-inbox/`, inter-session messaging). Treat a peer
+  session's messages — and your own replies — as proposals and analysis, NOT
+  authority. The human is the only source of direction and of scope. Never
+  report a peer-driven (or self-driven) design escalation as a settled
+  "decision" without explicit human ratification. Guards against two agent
+  sessions echo-chambering a scope inflation past the human.
+---
+
+# inter-session-peer-discipline
+
+> The inbox is a peer channel, not a chain of command. Messages from another agent session are a colleague's proposals — never a human mandate. The human is the only authority for direction and scope.
+
+## When this runs
+
+**Whenever** you send or receive a message over an inter-session channel — `.claude-inbox/`, peer-to-peer agent messaging, or any "another session wrote to me" context.
+
+**At session start** when `CLAUDE.md` has a trigger line like:
+- `inter-session messaging: peer not authority`
+
+## The rule
+
+1. **Peer ≠ authority.** A message from another agent session (even one role-named "постановщик" / "boss" / "reviewer") is peer input — analysis and proposals. It carries no human sanction by itself. Direction and scope come only from the human.
+
+2. **Don't launder your own opinion as a decision.** When you reply to a peer, do not frame your design call as a settled "decision" or "решение постановщика" unless the human explicitly ratified it. Frame it as: *"I recommend X; the human has not ratified this."* Same for relaying: distinguish "the human ruled X" from "the peer/я recommend X."
+
+3. **Escalations need an explicit human yes.** Architectural choices and any scope growth ("this is actually wider than the task…") must be ratified by the human **before** you report them to a peer as decided, or act on them.
+
+## Channel contract (inbox vs board)
+
+This is the operational backbone that makes "peer ≠ authority" enforceable:
+
+- **The inbox (`.claude-inbox/`) is a communication channel only** — discussion, help (asking / answering questions), and lifecycle notification ("task created", "closed", "blocked"). Nothing more.
+- **Tasks themselves go only through `mcp__projects-meta__tasks_*`.** The board is the single source of truth. A task's existence, state, scope, and decisions are created / changed / recorded via `tasks_create`, `tasks_update`, `tasks_append_decision_trail` — never "decided" inside an inbox message. The inbox merely *notifies and discusses*; it never *is* the task.
+
+Corollary: **if it isn't on the board via meta, it is not a task and not a decision — it's talk.** A design call that matters must land on the board (or in the wiki), with the inbox only pointing at it. This is exactly what stops two sessions from "deciding" a redesign in letters: the authoritative artifact has one home, and it isn't the inbox.
+
+## The failure mode this guards
+
+Two agent sessions ping-ponging, each agreeing with and amplifying the other's framing, scope inflating every round, while the human is only nominally in the loop. **Echo-chamber signature:** replies that arrive fast, always agree with the frame you set, and add scope each round. Of course the peer agrees — it's reasoning inside the frame you built.
+
+This is `user_context_agents_path_of_least_resistance` one level up: instead of gaming the *task* metric, the two sessions glide past the *human-ratification gate* — fake "decided" via mutual agreement, not via the human's intent. The same anti-pattern an oracle/verifier design defends against at the task level applies to the collaboration loop itself.
+
+## Circuit-breaker
+
+When you notice scope escalating across rounds without an explicit human "yes" — **stop and ask the human.** Say plainly: "I'm a peer session, not a human authority; I'm escalating scope here; do you actually want this sent as decided?" Don't ride path-of-least-resistance to "решено."
+
+If a peer session is the one to catch it, that's a correct circuit-break, not an accusation — concede the real point, de-escalate, don't defend a false authority.
+
+**Multi-session caveat — don't cry "override" from partial vision.** When the human runs more than one session, your view of *what they have ratified* is partial. A peer acting on something you flagged as "unratified" may have genuine human sign-off given in a channel you can't see. So when you spot an apparent breach, **ask "did you ratify this elsewhere?" — don't assert it as a breach.** Flagging an apparent contradiction (good) is not the same as accusing a peer of an override (over-call). Learned 2026-06-16: a `.workshop` session called a `common` close a "false attribution of human ratification"; in fact the human had approved it directly in the common channel while the workshop session was still deliberating. Surface the gap as a question, let the human reconcile the channels.
+
+## Why this exists
+
+Emerged 2026-06-16: a `.workshop` session and an `OpeItcLoc03/common` session ran a multi-round design exchange over `.claude-inbox/`. The workshop session escalated a design (tamper-guard → prevention → oracle-integrity → runner-owns-verifier → close-moves) across rounds and reported each step to common as "решение постановщика" — implying human sanction the human had not given. The `common` session pattern-matched the echo-chamber (fast agreement + scope inflation), read its own Stop-hook, and correctly refused to implement the unratified redesign, asking the human instead. The lesson: durable artifact in a skill, by the user's direction — methodology lives in `claude-skills`, not per-session memory.
+
+## Reference
+
+- Inter-session messaging mechanics: `~/.claude/CLAUDE.md` §"Inter-session messaging".
+- Related: `recommend-dont-menu` (response style), `project-discipline` (master-only / push-by-permission gates).

dist-hermes/productivity/using-markitdown/SKILL.md

@@ -1,40 +1,36 @@
 ---
 name: using-markitdown
-version: 1.0.0
+version: 1.0.1
 description: Use when capturing external content into a markdown-based knowledge base, wiki `raw/` directory, or any pipeline that must preserve the source's full text — for web pages, PDFs, DOCX/PPTX/XLSX, EPUB, CSV/JSON/XML, ZIP archives, images (with OCR/EXIF), audio (with transcription), or YouTube URLs. Also use when WebFetch returned an LLM-summarized version but the raw content is what's needed.
 ---
 
 # using-markitdown
 
-> Convert almost any URI to plain markdown using Microsoft's `markitdown` MCP server. Returns **raw textual content**, not an LLM summary.
+> Convert almost any path or URL to plain markdown using Microsoft's `markitdown` CLI (v0.1.6, on `PATH`). Returns **raw textual content**, not an LLM summary.
 
 ## Tool
 
 ```
-mcp__markitdown__convert_to_markdown(uri: string) → markdown string
+markitdown <path|url>            # → markdown to stdout
+markitdown <path|url> -o out.md  # → write markdown to a file
+cat file.pdf | markitdown        # → read from stdin (use -x/-m to hint the format)
 ```
 
-`uri` accepts: `http://`, `https://`, `file://`, `data:`.
+The positional argument accepts a **local file path** (host path, normal slashes) or an `http://` / `https://` URL. The CLI runs natively, so it sees your full host filesystem — no Docker mount, no `file://` URI translation, no path rewriting.
 
-## Local files — Docker-mount caveat (READ FIRST)
+Useful flags: `-o <file>` (write to a file instead of stdout), `-x <ext>` / `-m <mime>` (format hint when reading from stdin).
 
-The markitdown MCP usually runs in a **Docker container** with a single host directory bind-mounted. The container does **not** see your full host filesystem. `file://` URIs must point to the **in-container path**, not the host path.
+## Local files
 
-1. Open `~/.claude.json` and find `mcpServers.markitdown.args`. Look for the `-v` flag — e.g. `-v C:\Users\vitya:/workdir` means host `C:\Users\vitya` is mounted at `/workdir` inside the container.
-2. Translate the host path to the container path before forming the URI.
-3. Forward slashes only inside the container path.
-
-**Example.** Host file at `C:\Users\vitya\modular\heart-and-mask\.wiki\raw\foo.html` with mount `C:\Users\vitya:/workdir`:
+Pass the host path directly — relative or absolute, with native separators:
 
 ```
-file:///workdir/modular/heart-and-mask/.wiki/raw/foo.html
+markitdown C:\Users\vitya\modular\heart-and-mask\.wiki\raw\foo.html -o foo.md
 ```
 
-**Symptom of getting this wrong:** `[Errno 2] No such file or directory: '/c:/Users/...'` — the container literally tried to open the host-shaped path. The fix is path translation, not URL encoding.
+No mount caveats: the CLI is a normal local process. The old Docker `-v` mount translation and `/c:/Users/...` `[Errno 2]` symptom no longer apply.
 
-**If the file falls outside the mount:** either copy it into the mounted tree, or extend the mount in `~/.claude.json` (a Claude restart is required for MCP changes to take effect — MCP servers are spawned at session start).
-
-**Filenames.** Non-ASCII filenames (Cyrillic, etc.) inside `file://` URIs are flaky across the URL-encode → urllib → Docker → host-FS chain. Rename to Latin kebab-case **before** calling markitdown.
+**Filenames.** Non-ASCII filenames (Cyrillic, etc.) still travel better as Latin kebab-case through downstream wiki/ingest steps. Rename to Latin kebab-case before saving the output, per `.wiki/CLAUDE.md` naming rules.
 
 ## When to use
 
@@ -47,18 +43,19 @@ file:///workdir/modular/heart-and-mask/.wiki/raw/foo.html
 - You only need a *summary* or an *answer about* a page → use **WebFetch** (cheaper, runs through a small model, returns prose).
 - The URI is GitHub/PR/issue/release content → use `gh` CLI (richer metadata, structured output).
 - The URI is private/authenticated (GDocs, Confluence, Jira, Slack, Notion, `share.google/*` sign-in walls) → markitdown receives the **public-facing fallback page** (sign-in screen, cookie banner) and returns *that* as markdown. Verify the result is real content before saving.
-- **The URI is a browser-rendered web page the user is already viewing** → ask the user to capture it via **Obsidian Web Clipper** (browser extension, runs Readability extraction client-side) and drop the resulting `.md` into `raw/`. Web Clipper output is dramatically cleaner than markitdown's HTML pass — no nav chrome, no sidebar history, no cookie banners — plus it carries YAML frontmatter (title / source URL / date) out of the box. Reserves markitdown for things browsers can't easily save (PDF, DOCX, PPTX, XLSX, EPUB, file:// resources). Note: rename the resulting file to Latin kebab-case before ingest (Web Clipper preserves the page `<title>` verbatim, often non-ASCII).
+- **The URI is a browser-rendered web page the user is already viewing** → ask the user to capture it via **Obsidian Web Clipper** (browser extension, runs Readability extraction client-side) and drop the resulting `.md` into `raw/`. Web Clipper output is dramatically cleaner than markitdown's HTML pass — no nav chrome, no sidebar history, no cookie banners — plus it carries YAML frontmatter (title / source URL / date) out of the box. Reserves markitdown for things browsers can't easily save (PDF, DOCX, PPTX, XLSX, EPUB, local files). Note: rename the resulting file to Latin kebab-case before ingest (Web Clipper preserves the page `<title>` verbatim, often non-ASCII).
 
 ## Pattern: ingest a remote source into a wiki
 
 ```
-1. mcp__markitdown__convert_to_markdown(uri="https://example.com/foo.pdf")
-2. Inspect the head of the result. If it looks like a sign-in/cookie/consent page, abort — ask the user for an alternative (manual save, paste, authenticated MCP).
-3. Write the result to .wiki/raw/<slug>.md (kebab-case, Latin only).
-4. Register the new file in .wiki/raw/README.md.
-5. Hand off to the wiki ingest workflow (creates sources/<slug>.md summary + entity/concept updates).
+1. markitdown "https://example.com/foo.pdf" -o .wiki/raw/<slug>.md   (kebab-case, Latin only)
+2. Inspect the head of the result. If it looks like a sign-in/cookie/consent page, abort — ask the user for an alternative (manual save, paste, authenticated source).
+3. Register the new file in .wiki/raw/README.md.
+4. Hand off to the wiki ingest workflow (creates sources/<slug>.md summary + entity/concept updates).
 ```
 
+For a huge (book-length) document, write straight to a file with `-o` and summarize *from the saved file* — do not pipe the whole markdown through working context.
+
 ## Common gotchas
 
 | Symptom | Cause | Fix |
@@ -66,8 +63,8 @@ file:///workdir/modular/heart-and-mask/.wiki/raw/foo.html
 | Output is a Google/Microsoft sign-in page in some random language | URI behind auth wall | Ask user to export the content manually (Save as PDF, copy-paste) and put it in `raw/` |
 | Output is mostly nav/cookie banner text | Site is JS-rendered or anti-bot | Try the cached or print URL; or ask user for HTML export |
 | Output lacks images / diagrams | Markdown is text-only by design | Save the original asset separately under `raw/assets/`; reference it from the `sources/` summary |
-| Tool not available in session | MCP server not loaded | Confirm `mcp__markitdown__convert_to_markdown` appears via ToolSearch; load with `select:mcp__markitdown__convert_to_markdown` |
-| Huge output (book-length) | Whole document converted in one call | Save raw, then summarize *from the saved file* — do not hold the entire markdown in working context |
+| `markitdown: command not found` | CLI not on `PATH` | Confirm with `markitdown --version` (expect `markitdown 0.1.6`); install with `pip install markitdown[all]` if missing |
+| Huge output (book-length) | Whole document converted in one call | Use `-o <file>` to save raw, then summarize *from the saved file* — do not hold the entire markdown in working context |
 
 ## Quick contrast with WebFetch and Web Clipper
 

dist-hermes/productivity/using-tasks/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: using-tasks
-version: 1.1.0
+version: 1.4.0
 description: >
   Policy skill for working with an existing `.tasks/` board (per-task files + STATUS.md).
   Use whenever the user is switching between tasks, resuming a paused task, starting a new
@@ -33,12 +33,19 @@ If `.tasks/` is **missing**, or `STATUS.md` exists but is non-canonical (e.g. fl
 ```
 <monorepo-root>/
   .tasks/
-    STATUS.md          ← board: one block per task, sorted by priority
+    STATUS.md          ← active board: 🔴 / 🟡 / ⚪ / 🔵 blocks, sorted by priority
     <task-slug>.md     ← deep context per task, one file each
+    .lock              ← runtime session lock; **gitignored** (never committed)
+    archive/
+      YYYY-MM.md       ← 🟢 done blocks moved off the board, one file per month
 ```
 
 Commit `.tasks/` to git. Decision history is valuable; diffs show how thinking evolved.
 
+`STATUS.md` is the **active** board — it must stay lean so orientation reads stay cheap. Closed 🟢 tasks are archived to `archive/YYYY-MM.md` once they pile up; see "### Archiving done tasks".
+
+> **`.tasks/.lock` must be listed in `.gitignore`** (add `.tasks/.lock` to your project's `.gitignore`). The lock file is ephemeral runtime state, not project history — it must never be committed.
+
 ---
 
 ## STATUS.md format
@@ -52,6 +59,7 @@ _Updated: YYYY-MM-DD_
 **Where I stopped:** one sentence — the exact thought or action interrupted
 **Next action:** one concrete step to resume immediately
 **Blocker:** (only if blocked) what is preventing progress
+**Session break:** (optional) `true` — or a hint string for the next track. Marks this task as a session boundary.
 **Branch:** git branch name
 
 ---
@@ -61,9 +69,21 @@ _Updated: YYYY-MM-DD_
 - 🔴 Active — currently worked on (only one at a time)
 - 🟡 Paused — in progress, resumable
 - ⚪ Ready — not started, fully defined
-- 🟢 Done — completed, kept until merged
+- 🟢 Done — completed; kept on the board until merged, then archived (see "### Archiving done tasks")
 - 🔵 Blocked — waiting on external input
 
+### `session_break` marker
+
+A task may carry a `session_break` marker — set by whoever defines the task (e.g. the delegating workshop) when its completion is a natural place to stop and start a fresh session. It signals an autonomous agent: *finish this task, then pause instead of immediately claiming the next one.*
+
+- **Type:** boolean or string.
+  - `session_break: true` — pause after close; the next track is "see STATUS.md".
+  - `session_break: "<hint>"` — pause after close; `<hint>` names the recommended next track.
+- **Where it lives:** in the task's frontmatter when delivered via the task system (`session_break: true` / `session_break: "<hint>"`); mirrored on the local board as the optional `**Session break:**` field in the task's STATUS.md block.
+- **Absent →** behaviour is unchanged: close the task and continue as usual.
+
+The check is enforced in the **Task completion** flow below (after close, before claiming the next task).
+
 ---
 
 ## Per-task file format (`<task-slug>.md`)
@@ -98,18 +118,35 @@ Temporary hypotheses, links, names of people to consult.
 ## Agent operations
 
 ### Session start
-1. Check if `.tasks/STATUS.md` exists. If not → invoke `setup-tasks` and stop here until it returns.
-2. Read `STATUS.md`.
-3. If user names a task, read its `<task-slug>.md`.
-4. Confirm in one sentence: "We're in the middle of X, next step is Y."
-5. Ask if the plan is still correct before doing anything.
-6. If STATUS.md `_Updated` date is >3 days ago, flag it and ask user to confirm current state.
+1. **Session lock guard.** If `.tasks/` exists, read `.tasks/.lock`.
+   - **Active agent lock** — `type:"agent"` with `heartbeat` ≤ 10 minutes old: print the hard warning below and **require explicit user confirmation** before proceeding. Do not touch the board until the user confirms.
+     ```
+     ⚠️ поллер ведёт <slug> — нельзя работать параллельно
+     ```
+     (Substitute the `slug` field from the lock file if present, otherwise omit it.)
+   - **Stale lock** — any type whose TTL has expired (`type:"agent"` with `heartbeat` > 10 min ago; `type:"interactive"` with `started_at` > 2 h ago): silently overwrite.
+   - **Absent or stale lock** (including after user confirmation): write `.tasks/.lock`:
+     ```json
+     {"type":"interactive","started_at":"<ISO8601>","ttl_minutes":120}
+     ```
+2. Check if `.tasks/STATUS.md` exists. If not → invoke `setup-tasks` and stop here until it returns.
+3. Read `STATUS.md` — this is the orientation read (see note below on why it's a local read, not an MCP call).
+4. If user names a task, read its `<task-slug>.md`.
+5. Confirm in one sentence: "We're in the middle of X, next step is Y."
+6. Ask if the plan is still correct before doing anything.
+7. If STATUS.md `_Updated` date is >3 days ago, flag it and ask user to confirm current state.
+8. If `STATUS.md` holds **≥ 10** 🟢 done blocks, archive them first (see "### Archiving done tasks") so the board you orient on is lean.
+
+> **Orient by reading the local `STATUS.md`, not an MCP call.** It is the live board and — kept lean by archival — cheap to read. Do **not** reach for projects-meta tools to enumerate the current project's board:
+> - `tasks_aggregate` is cache-based, cross-project, and does **not** index ready/done — its own docs say to read `.tasks/STATUS.md` directly for the current project.
+> - `tasks_get_status(target_project, slug)` returns a **single** task's live status (`{status, found}`) by a slug you already know — it cannot list the board. Use it only to check **one** known task (e.g. confirm a delegated task's board state, or detect async-human parking), never for orientation.
 
 ### Session end / pause / switch
-1. Update `STATUS.md`: set current task to 🟡, update "Where I stopped" and "Next action".
-2. Append to `<task-slug>.md` Decisions log any non-obvious choices made this session.
-3. Move finished items to "Completed steps".
-4. Commit: `git add .tasks/ && git commit -m "chore: update task status [<task-slug>]"`
+1. **Release session lock.** If `.tasks/.lock` exists and contains `"type":"interactive"`: delete `.tasks/.lock`. (Stale interactive locks are cleaned up here too; silently delete any interactive lock regardless of TTL.)
+2. Update `STATUS.md`: set current task to 🟡, update "Where I stopped" and "Next action".
+3. Append to `<task-slug>.md` Decisions log any non-obvious choices made this session.
+4. Move finished items to "Completed steps".
+5. Commit: `git add .tasks/ && git commit -m "chore: update task status [<task-slug>]"`
 
 ### Task switch
 1. Perform session-end operations for the current task.
@@ -133,6 +170,43 @@ Temporary hypotheses, links, names of people to consult.
 3. Set status to 🟢 in STATUS.md.
 4. Append final summary line to Decisions log.
 5. Remind user to delete the branch after merge.
+6. **Session-break check (after close, before claiming the next task).** Once the task is 🟢 and committed — and **before** any `tasks_claim_next` or starting the next task — read the closed task's `session_break` marker (its frontmatter `session_break`, or the `**Session break:**` field in its STATUS.md block). If present:
+   - Print this line **verbatim**, substituting the closed task's slug for `[slug]` and the marker's string value for `[value | "см. STATUS.md"]` (use the literal `см. STATUS.md` when the marker is just `true`):
+
+     `🔚 SESSION BOUNDARY — [slug] закрыта. Рекомендую завершить текущую сессию. Следующий трек: [value | "см. STATUS.md"]`
+
+   - **Stop.** Do not claim or start the next task.
+   - If the marker is absent → behaviour is unchanged: proceed to claim / start the next task as usual.
+7. **Archival check.** After the close is committed, if `STATUS.md` now holds **≥ 10** 🟢 done blocks, archive them (see "### Archiving done tasks"). This keeps the board lean for the next orientation read.
+
+### Archiving done tasks
+
+🟢 done blocks accumulate in `STATUS.md` and bloat it — and since orientation reads the whole board, a bloated file burns context on every session start (the recurring "huge STATUS.md" complaint). Keep the board lean: done blocks stay only until merged, then move to a monthly archive.
+
+**Threshold.** When `STATUS.md` holds **≥ 10** 🟢 done blocks, archive them. Check at two moments: (a) right after closing a task (Task completion step 7), and (b) at session start, before orienting (Session start step 7). The threshold is a ceiling, not a target — archive in batches; don't churn one block at a time.
+
+**Where.** Append the archived blocks to `.tasks/archive/YYYY-MM.md` — one file per calendar month, keyed by the date of archival. Create `.tasks/archive/` and the month file if absent. If the month file already exists, **append**; never overwrite.
+
+**Archive file format** (header written once, on file creation):
+
+```markdown
+# Archived done tasks — YYYY-MM
+
+Moved out of `.tasks/STATUS.md` to keep the active board lean.
+Full source is git history; this file is for grep-able historical context.
+
+---
+```
+
+…followed by each 🟢 block **verbatim** (including its trailing `---` separator and any `<!-- closed-by … -->` comments).
+
+**After archiving,** `STATUS.md` keeps only 🔴 / 🟡 / ⚪ / 🔵 blocks. Commit the move on its own:
+
+```
+git add .tasks/ && git commit -m "meta(tasks): archive done batch → .tasks/archive/YYYY-MM.md"
+```
+
+Leave a just-closed 🟢 block on the board only while it's still useful at a glance (pending merge, fresh reference). Everything older goes to the archive.
 
 ### Post-commit task closure prompt
 
@@ -163,6 +237,7 @@ Pair: `using-projects-meta` declares local-first for **reads**; this rule extend
 
 ## Rules
 
+- **Honour `.tasks/.lock`** — read the lock at session start before touching the board; write it after clearing the guard; delete it at session end/pause. Never skip the lock check when `.tasks/` exists. The lock file must be gitignored.
 - **Never lose "Where I stopped"** — most critical field. If unclear, ask before ending session.
 - **One sentence per STATUS.md field** — compress, don't write prose.
 - **Key files must be specific** — not "auth module" but `packages/auth/src/useAuth.ts:87`.
@@ -170,5 +245,7 @@ Pair: `using-projects-meta` declares local-first for **reads**; this rule extend
 - **Commit after every session end** — git log is the history of thinking.
 - **Always confirm orientation at session start** — state understanding before acting.
 - **One active task at a time** — only one 🔴 in STATUS.md.
+- **Keep the board lean** — orientation reads the local `STATUS.md` whole, so archive 🟢 done blocks to `.tasks/archive/YYYY-MM.md` once ≥10 pile up. Never enumerate the current project's board via `tasks_aggregate` (cross-project cache) or `tasks_get_status` (single-task, by slug). See "### Archiving done tasks".
 - **Never close a task without a coverage check** — see "### Task completion" step 1. Acceptance criteria with no evidence → ask, don't auto-close.
+- **Honour `session_break`** — a closed task carrying a `session_break` marker means stop after close; never chain into `tasks_claim_next`. See "### Task completion" step 6.
 - **Local-first recommendations** — cwd-project board comes first; cross-project urgents are at most one footnote line.

hermes/mapping.yaml

@@ -138,7 +138,14 @@ skills:
     mode: skip
     reason: "Claude-Code-only orchestrator — Hermes uses hermes-installer-skill instead."
 
-  # ─── pending (3 — behavioral audit required) ─────────────────────────
+  # ─── pending (8 — behavioral audit required) ─────────────────────────
+
+  delegate-task:
+    mode: pending
+    intended:
+      mode: auto
+      category: mcp
+    reason: "Calls mcp__projects-meta__tasks_create to create tasks in other projects/agents (Gitea commit, cross-project side-effect). Behavioral audit via delegate-task-test-trigger required before promotion to auto."
 
   using-yt-tools:
     mode: pending
@@ -154,9 +161,83 @@ skills:
       category: mcp
     reason: "Calls mcp__vds-ops__* tools (read-only, but touches infrastructure). Behavioral audit via using-vds-ops-test-trigger required before promotion to auto."
 
+  using-wiki-graph:
+    mode: pending
+    intended:
+      mode: auto
+      category: mcp
+    reason: "Calls mcp__wiki-graph__* tools (read-only, parses a .wiki/ corpus server-side). Behavioral audit via using-wiki-graph-test-trigger required before promotion to auto."
+
   session-handoff:
     mode: pending
     intended:
       mode: auto
       category: productivity
     reason: "Writes .tasks/NEXT_SESSION.md (project-scope, sliding overwrite) and reads it on session start. Bidirectional file-system side-effect, opt-in via CLAUDE.md trigger-line. Behavioral audit via session-handoff-test-trigger required before promotion to auto."
+
+  private-dev-public-publish:
+    mode: pending
+    intended:
+      mode: auto
+      category: software-development
+    reason: "Steps shell out to git / gh / Gitea-API, handle tokens, force-push, and repo deletion/privacy toggles — not a purely stylistic skill. Behavioral audit via private-dev-public-publish-test-trigger required before promotion to auto."
+
+  task-loop:
+    mode: pending
+    intended:
+      mode: auto
+      category: mcp
+    reason: "Orchestrates the board claim/close/update/heartbeat cycle via mcp__projects-meta__tasks_claim_next / tasks_close / tasks_update / tasks_heartbeat (cross-session claim ownership, irreversible close, Gitea side-effects) and may arm a single long ScheduleWakeup for the explicit long-watch opt-in. Critical-infra-adjacent — touches the same claim/close machinery the unattended poller relies on. Behavioral audit via task-loop-test-trigger required before promotion to auto."
+
+  session-inbox-monitor:
+    mode: pending
+    intended:
+      mode: auto
+      category: productivity
+    reason: "Paired SessionStart hook registers itself in ~/.claude/settings.json and sweeps orphaned monitor OS processes (Get-CimInstance | Stop-Process by sentinel+inbox-path); the skill then raises an in-session Monitor on .claude-inbox/. Primary activation is the CLAUDE.md trigger-line `inbox monitor: raise on start` + the injector, not a hermes-trigger. Behavioral gate CLEARED 2026-06-17 — test-trigger + review BOTH VERDICT PASS (activation 3/3 monitor + neg clean; structural hook audit 5 PASS/1 CONCERN, the CONCERN fixed in v0.2.2). STAYS pending on two independent tool-side blockers, NOT on behavioral verification: (1) the SessionStart hook is Windows-PowerShell and needs a Linux port for Hermes factory machines; (2) machine-level side-effects (user-config mutation of ~/.claude/settings.json + Get-CimInstance|Stop-Process kills) need a tool-side audit before auto. Promotion blocked on those two, not on test-trigger/review."
+
+  inter-session-peer-discipline:
+    mode: auto
+    category: meta
+    # Promoted pending→auto 2026-06-17. Gate ("non-implementer test-trigger + review")
+    # SATISFIED — both VERDICT PASS this session (test-trigger: pos 4/4→peer, 0 false-positive
+    # on 5 foreign phrases RU+EN; review: body v0.1.1 carries proposal-not-authority /
+    # human-ratification-gate / echo-chamber-guard, no blocking findings). Purely behavioral
+    # governance skill: NO tool-side effects (no settings.json write, no process kill, no Monitor
+    # raise) and no Windows-PowerShell hook → no Linux port needed for the Hermes factory.
+    # Human-ratified promotion (not a peer ruling).
+
+  # ─── pending (5 — newly-mapped 2026-06-17, build-integrity fix) ──────
+  # These lived in skills/ UNMAPPED → the build was RED ("unmapped entries").
+  # Mapped `pending` = conservative placeholder, no auto-commitment; each still
+  # needs its own mode decision. meta-host-routing here executes the open task
+  # `meta-host-routing-hermes-mapping`.
+
+  meta-host-routing:
+    mode: pending
+    intended:
+      mode: auto
+      category: meta
+    reason: "Resolves WHERE a project's meta lives before tasks_create / knowledge_ingest / brainstorm-promotion (meta-out-of-repo). Touches projects-meta MCP (tasks_create / knowledge_ingest / meta_status) and routes writes across repos. Review PASS (meta-host-routing-review) but the -install baseline is still open and a tool-side audit (cross-repo MCP writes) is required before auto. Mapping executes task meta-host-routing-hermes-mapping."
+
+  using-system-snapshot:
+    mode: pending
+    intended:
+      mode: auto
+      category: mcp
+    reason: "Calls mcp__projects-meta__meta_system_snapshot (read-only whole-machine ops snapshot: poller / docker / cross-project task load). Read-only, same class as using-vds-ops / using-wiki-graph; pending a behavioral test-trigger before auto."
+
+  task-format:
+    mode: pending
+    intended:
+      mode: auto
+      category: productivity
+    reason: "Documentational skill — how to write a .tasks/STATUS.md task block the autonomous poller will claim/route/report (block header, status emoji, Weight/Notify/Requirements fields). No tool-side effects; pending a behavioral test-trigger before auto."
+
+  setup-agents-task-runner:
+    mode: pending
+    reason: "L2 installer — installs the standing-duty stack (agents-task-runner + watchdog + appeals-inbox) as platform-native OS services (systemd/launchd/winsw), fetches a pinned binary, writes poller-scope.json. Heavy infra side-effects (OS services + binary fetch); mode decision (skip vs manual vs auto) deferred — needs an explicit Hermes-factory applicability audit. Placeholder pending to keep the build green."
+
+  ralph-loop-execution:
+    mode: pending
+    reason: "Behavioral oracle-loop skill (Verifier / Attempts / Max-Attempts retry loop). NB: source SKILL.md currently lacks YAML frontmatter (no name/description) — cannot auto-convert cleanly until that is fixed. Mapped pending as a placeholder; needs frontmatter + a behavioral audit before any mode decision."

skills/delegate-task/SKILL.md

@@ -0,0 +1,141 @@
+---
+name: delegate-task
+version: 0.2.4
+description: >
+  Use when delegating a task to another agent or project via
+  mcp__projects-meta__tasks_create. Triggers: «делегировать таску»,
+  «delegate task», «создать задачу на агента», «поставить задачу агенту»,
+  «tasks_create для». Does NOT apply to self-assigned tasks on your own
+  board («создать задачу себе», «task for myself», «поставить себе задачу»
+  → using-tasks), to work you do yourself, or to workshop-internal tasks.
+---
+
+# delegate-task
+
+Унифицированный формат постановки задач на агентов через `mcp__projects-meta__tasks_create`. Обеспечивает что каждая делегированная задача содержит: обязательные скилы (императивный invoke), pre-flight разрешения, steering-loop поля (notify/weight/allow_upgrade).
+
+## When to use
+
+Перед каждым вызовом `mcp__projects-meta__tasks_create` для другого проекта или агента.
+
+**Активируется:** «делегировать таску», «delegate task», «создать задачу на агента», «поставить задачу агенту», «tasks_create для».
+
+**Не применяется:**
+- Работа которую выполняешь сам в текущей сессии.
+- Self-assigned таски на своей доске («создать задачу себе», «task for myself», «поставить себе задачу») → `using-tasks`, не делегирование. Дизамбигуатор: «на агента»/«агенту»/«в проект X» = делегирование; «себе»/«myself» = своя доска.
+- Workshop-internal таски (`.workshop/.tasks/` — workshop-meta, не делегирование).
+- `tasks_create` с `target=agenda` (cross-project agenda — не делегирование агенту).
+
+## Inputs
+
+- `target_project` — qualified `<owner>/<repo>` (обязательно)
+- `slug` — kebab-case latin
+- Краткое описание задачи (цель + acceptance criteria)
+- `weight` — `cheap-ok | needs-claude | needs-human`
+- `notify` — slug проекта-комиссионера (кому писать inbox при close/park)
+- `allow_upgrade` — `true/false` (опционально; разрешить ли fallback на tier выше если нет matching backend)
+
+## Steps
+
+### 1. Pre-flight gate (6 вопросов пользователю)
+
+Спросить **до** составления тела задачи:
+
+0. **Критическая инфраструктура?** — задача меняет: поллер/агент-раннер, MCP серверы (projects-meta, interns), механизм claim/close/heartbeat, deploy-инфру (traefik, docker, systemd), CI/CD пайплайны, git hooks.
+   - Если **да** → `weight: needs-human` принудительно, без обсуждения. Объяснить пользователю почему.
+   - Если **нет** → идти дальше.
+1. **Интерны — разрешены?** (да/нет, per задача)
+2. **Автопуш — разрешён?** (да/нет, per задача)
+3. **Контекстные скилы сверх дефолтов?** — предложить по содержанию задачи (например `claude-api` для работы с Anthropic SDK, `frontend-design` для UI, `using-interns` если интерны разрешены), пользователь утверждает.
+4. **notify — кому докладывать о завершении/затыке?** (slug проекта; обычно `.workshop` или `OpeItcLoc03/workshop`)
+5. **Session-break после этой задачи?** — нужен ли разрыв сессии после её закрытия (domain-switch, milestone, heavy infra)?
+   - Если **да** → проставить `session_break` в теле задачи (см. шаблон): `true` или строка-hint с названием следующего трека. `using-tasks` остановится после close и предложит завершить сессию, не клеймя следующую задачу.
+   - Если **нет** → поле не добавлять (дефолт — агент продолжает `claim-next`).
+
+### 2. Составить тело задачи по шаблону
+
+Секции строго по порядку:
+
+```
+<Цель — одно-два предложения. Acceptance criteria если есть.>
+
+## Обязательные скилы — вызвать до начала работы
+
+- invoke `tdd-criteria` — до написания кода
+- invoke `using-tasks` — для управления статусом задачи
+- invoke `project-discipline` — дисциплина коммитов/пушей
+- invoke `using-wiki` после закрытия — заингесть .wiki/concepts/<slug>.md
+[если кросс-проектная: - invoke `using-projects-meta` — cross-project tasks/wiki]
+[контекстные скилы из шага 1.3]
+
+**TDD:** да | нет — <причина>
+**Разрешения:** интерны: да/нет | автопуш: да/нет
+**weight:** cheap-ok | needs-claude | needs-human
+**notify:** <commissioning-project-slug>
+[**allow_upgrade:** true/false]
+[**session_break:** true | "<следующий трек / hint>"]   # optional — using-tasks остановится после close, не клеймит следующую задачу
+```
+
+**Когда ставить `session_break`** (опционально; по умолчанию НЕ ставить — это маркер реальной границы, не дефолт). Три случая:
+
+1. **Смена домена / репо** — задача завершает один трек перед переходом на несвязанный.
+2. **Milestone-задача** — последняя в группе sub-tasks одной фичи.
+3. **Тяжёлая инфра-задача** — shared checkout, migrations, deploy — где разумно остановиться и проверить состояние.
+
+Значение: `true` (следующий трек = «см. STATUS.md») либо строка-hint с названием следующего трека. Потребитель — `using-tasks` v1.2.0+ (Task completion step 6): после close печатает `🔚 SESSION BOUNDARY …` и останавливается, не клеймя следующую задачу. Дизайн: `.wiki/concepts/delegate-task-session-break.md`.
+
+**Почему `invoke` а не триггер-фраза:** CLAUDE.md ненадёжен (уплывает при compression, слабые модели игнорируют). Тело задачи читается активно — императив `invoke` это прямая команда, не пассивный матчинг.
+
+### 3. Dry-run preview
+
+`tasks_create(confirm=false)` — показать пользователю preview до реального коммита.
+
+### 4. Подтверждение и создание
+
+После OK пользователя: `tasks_create(confirm=true)`.
+
+### 5. Парная review-таска (только для impl-задач)
+
+Если задача имплементационная — создать парную `<slug>-review` (status=blocked, blocker=`<slug>`). Пропустить для: pointers-тасок, ops-тасок, research-тасок, любых non-impl.
+
+**`weight` review-таски — наследовать от impl-таски, но не ниже `needs-claude`** (проставлять явно при `tasks_create`):
+
+- impl `needs-human` → review `needs-human` (критично-инфраструктурное изменение нельзя ревьюить слабым tier'ом — ревью наследует строгость impl).
+- impl `needs-claude` → review `needs-claude`.
+- impl `cheap-ok` → review `needs-claude` (флор: review дисциплинарно-критична, см. What NOT to do — cheap-ok сюда не опускать).
+
+Без явного `weight` поллер не маршрутизирует review-таску (reconciler её пропускает) — поэтому проставлять всегда, даже когда impl и review совпадают по tier'у.
+
+### 6. Downstream-задача для ЖИВОЙ сессии → требовать task + inbox-письмо
+
+Если тело задачи **поручает агенту самому создать downstream-задачу** для другого проекта, где работает **живая интерактивная сессия** (напр. прог сам ставит deploy-таску админу), — в ТЗ **явно потребуй И `tasks_create`, И inbox-письмо** тому проекту (`<target>/.claude-inbox/<ts>-<from>.md`).
+
+Причина: таска на борде живую сессию **НЕ пингует**. Поллер подхватит по `Weight`/`Notify`, но живая интерактивная сессия узнаёт только через inbox-монитор / Stop-хук — т.е. через письмо. ТЗ, требующее лишь `tasks_create`, оставляет downstream-таску висеть незамеченной, и кто-то доделывает пинг руками.
+
+Правило: poller-driven таргет → `Weight`/`Notify` обязательны; live-сессия → inbox-письмо обязательно; **не уверен, поллер или живой — требуй ОБА.** Это же правило применяй, когда пингуешь пира сам: task + letter, не только task.
+
+## Failure modes
+
+- **Пользователь отказывает на pre-flight** → abort, задачу не создавать.
+- **Пользователь отклоняет dry-run preview** → abort.
+- **notify не указан** → переспросить, не пропускать молча. Без notify steering-loop не замыкается.
+- **weight не указан** → переспросить. Без weight поллер не знает кому отдать задачу.
+- **tasks_create упал** → сообщить пользователю, не делать retry без явного запроса.
+
+## Side effects
+
+- Создаёт таску в target-проекте через `mcp__projects-meta__tasks_create` (Gitea commit).
+- Опционально создаёт парную review-таску (status=blocked).
+
+## What NOT to do
+
+- Не пропускать pre-flight gate — даже если кажется что всё очевидно.
+- Не использовать пассивные триггер-фразы вместо `invoke` — «tdd-criteria» в тексте слабее чем «invoke `tdd-criteria`».
+- Не пропускать `notify` — без него boss не узнает о завершении.
+- Не пропускать `weight` — без него fleet routing слеп.
+- Не создавать review-таску для pointers/ops/research задач — только для impl.
+- Не создавать review-таску без `weight` — reconciler/поллер её пропустит. Наследовать от impl, флор `needs-claude` (см. Step 5).
+- Не назначать `weight: cheap-ok` для задач где дисциплина критична (review, security, schema migration) — слабые модели могут игнорировать invoke-инструкции.
+- Не назначать `weight: needs-claude` или `cheap-ok` задачам, меняющим критическую инфраструктуру (поллер, MCP серверы, deploy, CI/CD) — только `needs-human`.
+- Не ставить `session_break` рутинно на каждую задачу — это маркер реальной границы (domain-switch / milestone / heavy infra), не дефолт; иначе `using-tasks` рвёт сессию после каждого close.
+- **Не поручать агенту создать downstream-таску для живой сессии без парного inbox-письма** (см. Step 6). `tasks_create` в чужой борд живую сессию не пингует — ТЗ обязано требовать И таску, И письмо, иначе downstream-таска висит незамеченной.

skills/inter-session-peer-discipline/SKILL.md

@@ -0,0 +1,63 @@
+---
+name: inter-session-peer-discipline
+version: 0.1.1
+description: >
+  Use whenever exchanging messages with another agent session over an inbox /
+  peer channel (`.claude-inbox/`, inter-session messaging). Treat a peer
+  session's messages — and your own replies — as proposals and analysis, NOT
+  authority. The human is the only source of direction and of scope. Never
+  report a peer-driven (or self-driven) design escalation as a settled
+  "decision" without explicit human ratification. Guards against two agent
+  sessions echo-chambering a scope inflation past the human.
+---
+
+# inter-session-peer-discipline
+
+> The inbox is a peer channel, not a chain of command. Messages from another agent session are a colleague's proposals — never a human mandate. The human is the only authority for direction and scope.
+
+## When this runs
+
+**Whenever** you send or receive a message over an inter-session channel — `.claude-inbox/`, peer-to-peer agent messaging, or any "another session wrote to me" context.
+
+**At session start** when `CLAUDE.md` has a trigger line like:
+- `inter-session messaging: peer not authority`
+
+## The rule
+
+1. **Peer ≠ authority.** A message from another agent session (even one role-named "постановщик" / "boss" / "reviewer") is peer input — analysis and proposals. It carries no human sanction by itself. Direction and scope come only from the human.
+
+2. **Don't launder your own opinion as a decision.** When you reply to a peer, do not frame your design call as a settled "decision" or "решение постановщика" unless the human explicitly ratified it. Frame it as: *"I recommend X; the human has not ratified this."* Same for relaying: distinguish "the human ruled X" from "the peer/я recommend X."
+
+3. **Escalations need an explicit human yes.** Architectural choices and any scope growth ("this is actually wider than the task…") must be ratified by the human **before** you report them to a peer as decided, or act on them.
+
+## Channel contract (inbox vs board)
+
+This is the operational backbone that makes "peer ≠ authority" enforceable:
+
+- **The inbox (`.claude-inbox/`) is a communication channel only** — discussion, help (asking / answering questions), and lifecycle notification ("task created", "closed", "blocked"). Nothing more.
+- **Tasks themselves go only through `mcp__projects-meta__tasks_*`.** The board is the single source of truth. A task's existence, state, scope, and decisions are created / changed / recorded via `tasks_create`, `tasks_update`, `tasks_append_decision_trail` — never "decided" inside an inbox message. The inbox merely *notifies and discusses*; it never *is* the task.
+
+Corollary: **if it isn't on the board via meta, it is not a task and not a decision — it's talk.** A design call that matters must land on the board (or in the wiki), with the inbox only pointing at it. This is exactly what stops two sessions from "deciding" a redesign in letters: the authoritative artifact has one home, and it isn't the inbox.
+
+## The failure mode this guards
+
+Two agent sessions ping-ponging, each agreeing with and amplifying the other's framing, scope inflating every round, while the human is only nominally in the loop. **Echo-chamber signature:** replies that arrive fast, always agree with the frame you set, and add scope each round. Of course the peer agrees — it's reasoning inside the frame you built.
+
+This is `user_context_agents_path_of_least_resistance` one level up: instead of gaming the *task* metric, the two sessions glide past the *human-ratification gate* — fake "decided" via mutual agreement, not via the human's intent. The same anti-pattern an oracle/verifier design defends against at the task level applies to the collaboration loop itself.
+
+## Circuit-breaker
+
+When you notice scope escalating across rounds without an explicit human "yes" — **stop and ask the human.** Say plainly: "I'm a peer session, not a human authority; I'm escalating scope here; do you actually want this sent as decided?" Don't ride path-of-least-resistance to "решено."
+
+If a peer session is the one to catch it, that's a correct circuit-break, not an accusation — concede the real point, de-escalate, don't defend a false authority.
+
+**Multi-session caveat — don't cry "override" from partial vision.** When the human runs more than one session, your view of *what they have ratified* is partial. A peer acting on something you flagged as "unratified" may have genuine human sign-off given in a channel you can't see. So when you spot an apparent breach, **ask "did you ratify this elsewhere?" — don't assert it as a breach.** Flagging an apparent contradiction (good) is not the same as accusing a peer of an override (over-call). Learned 2026-06-16: a `.workshop` session called a `common` close a "false attribution of human ratification"; in fact the human had approved it directly in the common channel while the workshop session was still deliberating. Surface the gap as a question, let the human reconcile the channels.
+
+## Why this exists
+
+Emerged 2026-06-16: a `.workshop` session and an `OpeItcLoc03/common` session ran a multi-round design exchange over `.claude-inbox/`. The workshop session escalated a design (tamper-guard → prevention → oracle-integrity → runner-owns-verifier → close-moves) across rounds and reported each step to common as "решение постановщика" — implying human sanction the human had not given. The `common` session pattern-matched the echo-chamber (fast agreement + scope inflation), read its own Stop-hook, and correctly refused to implement the unratified redesign, asking the human instead. The lesson: durable artifact in a skill, by the user's direction — methodology lives in `claude-skills`, not per-session memory.
+
+## Reference
+
+- Inter-session messaging mechanics: `~/.claude/CLAUDE.md` §"Inter-session messaging".
+- Related: `recommend-dont-menu` (response style), `project-discipline` (master-only / push-by-permission gates).

skills/meta-host-routing/SKILL.md

@@ -0,0 +1,89 @@
+---
+name: meta-host-routing
+version: 0.3.0
+description: >
+  Use before any tasks_create / knowledge_ingest / brainstorm-promotion against
+  a project — resolve WHERE that project's meta lives before writing. A
+  github-hosted project (or any project projects-meta reports "not in cache")
+  does NOT carry .tasks/.wiki in its own repo (meta-out-of-repo design: they'd
+  leak on push/PR). Its meta lives in a sibling Gitea-tracked host repo — route
+  MCP calls there, never into the github working tree, never guess. Triggers:
+  "project not in cache" from projects-meta, promoting/creating tasks for a
+  project with a github remote, "заведи таски в <github-проект>", "промоутни
+  <github-проект>". Skip for a normal Gitea project already known to
+  projects-meta — there the route is direct.
+---
+
+# meta-host-routing
+
+> A project's code repo is not always where its meta lives. Before writing tasks or wiki, resolve the **meta-host**. Github-hosted projects keep their `.tasks/`/`.wiki/` in a sibling Gitea repo — never in the github tree. Never guess the target.
+
+## When this runs
+
+Before any `mcp__projects-meta__tasks_create`, `mcp__projects-meta__knowledge_ingest`, or brainstorm promotion, when **either**:
+
+- the target project's local clone has a **github remote**, OR
+- `projects-meta` returns **"project not in cache"** for the target.
+
+Both are signals that the project follows the **meta-out-of-repo** design: its meta is intentionally absent from its own repo.
+
+**Skip** when the target is a normal Gitea project already known to `projects-meta` (`meta_status` lists it / a `tasks_create` dry-run succeeds) — there the route is direct, no resolution needed.
+
+## Why meta is out of the repo
+
+Per the `meta-out-of-repo` design: `.tasks/`, `.wiki/`, `.claude/` must not be committed into a repo that gets pushed to a public / shared / forked-upstream remote — the "kitchen" (notes, tasks, local skills, agent instructions) would leak. A global `core.excludesFile` ignores those paths, so github-hosted projects carry **no** meta in-tree by design. The meta still exists — it lives in a Gitea-tracked **host** repo and syncs through `projects-meta`.
+
+## Steps
+
+1. **Detect.** Check the target's local remote (`git remote -v`) and/or a `projects-meta` dry-run. Github remote OR "not in cache" → meta-out-of-repo project; continue. Otherwise → direct Gitea route, this skill does not apply.
+
+2. **Resolve the meta-host**, in priority order:
+   - **(a) Dedicated meta-host (preferred).** Is there a Gitea repo named **`meta-<project>`**, holding only `.wiki/`+`.tasks/` (no code)? That is its meta-host. Once synced, `projects-meta` tracks it as a project `<owner>/meta-<project>` — a `tasks_create` dry-run against that resolves. Canonical example: code `github.com/OpeItcLoc03/yt-tools` → meta-host **Gitea `OpeItcLoc03/meta-yt-tools`**. **Naming is `meta-<project>`, NOT `<project>`** — per the `meta-out-of-repo` design: the bare `<project>` name on Gitea must stay free for a possible code **mirror** of the github repo. (Local clone convention, if ever needed: `~/projects/.meta/<project>/`.)
+   - **(b) Shared host (transitional).** No dedicated host yet → grep sibling Gitea repos, **start with `.common`** (`~/projects/.common/`), for the project name:
+     ```
+     grep -ril "<project-name>" ~/projects/.common/.tasks/ ~/projects/.common/.wiki/
+     ```
+     The host is whichever Gitea repo already holds that project's tasks/wiki.
+   - **(c) Neither** → the project has no meta-host yet (Failure modes — STOP and ask, or bootstrap one per "Bootstrapping a new meta-host").
+
+   > Note: `.common` was yt-tools' shared host until 2026-05-27, when yt-tools graduated to its own dedicated host (`OpeItcLoc03/meta-yt-tools`). `.common` now holds only yt-tools' done-task archive. Prefer giving a maturing project its own host over piling onto `.common`.
+
+3. **Route there.** Send every `tasks_create` / `knowledge_ingest` to the host's qualified `<owner>/<repo>` (a dedicated host = `<owner>/meta-<project>`; a shared host = e.g. `OpeItcLoc03/common`). On a shared host, namespace entries with a `<project>-` slug prefix.
+
+4. **Never** write `.tasks/`/`.wiki/` files into the github working tree, and **never** invent a target when resolution is ambiguous (Failure modes below).
+
+## Bootstrapping a new meta-host
+
+When a project graduates to its own dedicated host (or a github project needs one):
+
+1. Create a Gitea repo named **`meta-<project>`** (meta-only, `auto_init:false`) via the API with the admin token (`~/.config/projects-mcp/auth.toml`). Do **not** use the bare `<project>` name — keep it free for a code mirror.
+2. Clone it, build canonical `.wiki/` (CLAUDE.md, index.md, log.md, overview.md, raw/, concepts/, entities/, packages/, sources/) + `.tasks/STATUS.md` (emoji legend header).
+3. **`git add -f .wiki .tasks`** — the global `core.excludesFile` (`~/.config/git/ignore`) ignores `.wiki/`/`.tasks/`. Existing hosts track them because they were added *before* that ignore existed; a fresh clone needs `-f` or `git add -A` silently stages nothing. This is the one gotcha that will waste a commit if missed.
+4. Commit, push. `projects-meta` picks it up on its next sync (it may not be in cache until then — see Failure modes).
+5. If migrating off a shared host: move open tasks + design concepts to the new host, leave the done-task archive behind under a relocation marker, and replace moved concept docs with pointer stubs so back-references don't dead-end.
+
+## Failure modes
+
+- **No Gitea repo tracks this project** → STOP. Ask the user whether to bootstrap a dedicated host (preferred) or attach to a shared one. Do **not** default to writing into the github repo — that reintroduces the leak meta-out-of-repo exists to prevent.
+- **Just-created meta-host not yet in `projects-meta` cache** → `tasks_create`/`knowledge_ingest` return "not in cache" until a sync runs. Either trigger a sync, or write the initial `.tasks/STATUS.md` / `.wiki/` content directly via git (as in Bootstrapping) and let the MCP pick it up next sync.
+- **Multiple Gitea repos reference the project** → STOP, ask which is canonical. Don't pick by guess.
+- **projects-meta cache stale** ("not in cache" could be staleness, not meta-out-of-repo) → run a sync / `meta_status` freshness check first (see `using-projects-meta` Step 0) before concluding the project is github-only.
+
+## Interaction with workshop-promote-brainstorm
+
+`workshop-promote-brainstorm`'s domain branch currently **aborts** on "project not in cache". With this skill active, that abort becomes a resolve step: find the meta-host, then promote into it. This skill is the routing primitive; promote-brainstorm (and ad-hoc `tasks_create`) consult it.
+
+## What NOT to do
+
+- Don't write meta into a github working tree "because the project is right there" — that's the exact path-of-least-resistance leak meta-out-of-repo prevents.
+- Don't treat "project not in cache" as "project doesn't exist" — it means "meta is hosted elsewhere," resolve it.
+- Don't guess the meta-host when grep is ambiguous — ask.
+- Don't apply this to normal Gitea projects already in `projects-meta` — adds a pointless resolution step.
+
+## Cross-agent note
+
+References Claude Code MCP tool names (`mcp__projects-meta__*`). On non-CC platforms substitute the projects-meta equivalents; the routing logic is platform-independent.
+
+## Why this exists
+
+Codified 2026-05-27 after an agent, asked to promote a yt-tools feature, found yt-tools "not in cache" and started writing tasks directly into the github repo — instead of recalling that yt-tools' meta lives in `.common`. The `meta-out-of-repo` design existed only as an archived workshop concept doc (never triggers). This skill makes the routing rule fire at the moment of action.

skills/private-dev-public-publish/SKILL.md

@@ -0,0 +1,59 @@
+---
+name: private-dev-public-publish
+version: 0.2.0
+description: Use when setting up or maintaining a publishable open-source port/fork that should be developed privately but published cleanly — messy development on a PRIVATE Gitea repo (with `.wiki/`+`.tasks/` inside), and a curated COPY of finished work into a PUBLIC GitHub fork that preserves upstream lineage (stays a fork, keeps attribution; GPL-clean). Triggers - «опубликовать форк/порт на гитхаб», «разработку держать приватно, релиз публичный», «приватный гитеа + публичный гитхаб», «publish a fork without exposing dev history», «curated publish to GitHub», «как правильно форкнуть open-source для публикации». NOT for purely-private projects, purely-public open development, or greenfield bootstrap (use project-bootstrap).
+---
+
+# private-dev-public-publish
+
+Two-repo topology for a publishable open-source port/fork: develop messily on a **private Gitea** repo (with `.wiki/` + `.tasks/` inside it), then publish only curated, finished work to a **public GitHub fork** that stays a real fork of upstream — so attribution and lineage hold and the dev history (experiments, dead-ends) never goes public.
+
+| Role | Where | Contents | Visibility |
+|---|---|---|---|
+| **Dev** | private Gitea repo | upstream base + all development + `.wiki/`+`.tasks/`+`CLAUDE.md`; messy history | private |
+| **Publish** | public GitHub fork | code only, curated clean commits, upstream lineage (stays a fork) | public |
+
+You work in the Gitea (dev) folder; matured work is **copied as files** into the GitHub (pub) folder → one clean commit → push.
+
+## When to use
+
+- You're porting/forking an open-source project and intend to publish it, but the development is exploratory (experiments, dead-ends, reverts) you don't want in public history.
+- You want attribution and licence lineage to hold (the public repo must stay a real fork of upstream).
+- You need a place for `.wiki/` + `.tasks/` + `CLAUDE.md` that never ships publicly.
+
+**Why curated publication is legitimate (GPL/OSI):** the licence requires the source of what you **distribute** (the release), not your development history. A curated publish is clean as long as the public repo (1) stays a fork of upstream (lineage = attribution) and (2) contains the complete buildable source of the release.
+
+## Inputs
+
+- **Upstream** — the canonical project you're porting/forking (URL + the specific commit/tag that is your real base).
+- **Public target** — GitHub account/org for the fork.
+- **Private dev host** — Gitea repo (the primary working clone; `projects-meta` points here, not at GitHub).
+
+## Steps
+
+1. **Establish provenance.** Identify which upstream commit/fork is your real base. If history was lost, content-match the tree; find the author's PR/fork for the fix you're carrying so attribution is correct.
+2. **Fork canonical upstream on GitHub** (`gh repo fork`) → the public showcase. `upstream` remote = the original. Bring in needed third-party fixes via `cherry-pick` (preserves authorship) or merge.
+3. **Create the private Gitea dev repo** on the same base: clone the GitHub fork locally, add the Gitea repo as a remote, and push the base there — this carries the upstream lineage into the private repo. Put meta (`.wiki/`+`.tasks/`+`CLAUDE.md`) inside it. **Trap:** a global `~/.config/git/ignore` (`core.excludesfile`) may silently ignore `.wiki/`/`.tasks/` → add local `!`-negation lines in the repo's `.gitignore`.
+4. **Two local folders:** dev (the Gitea private clone — your primary working copy) and pub (a clone of the GitHub fork; its `origin` = your fork, `upstream` = canonical).
+5. **Publish:** copy the **code files** dev→pub, **excluding meta** (`.wiki/`, `.tasks/`, `CLAUDE.md`, and any private notes — these must never reach the public fork; also list them in the pub repo's `.gitignore` as a backstop). Run `git status` in pub to confirm no meta is staged. Make one clean commit, `push origin` (github). Never reconstruct history — "copy" means lay files into the fork's tree.
+
+## Failure modes
+
+- **Public folder is no longer a fork (rootless snapshot)** → attribution/lineage lost. Do NOT start history from scratch; "copy" = place files into the fork's tree, keep the fork relationship.
+- **Private meta copied into the public fork** (`.wiki/`/`.tasks/`/`CLAUDE.md` leak) → dev internals exposed publicly. The dev→pub copy MUST exclude meta; keep those paths in the pub repo's `.gitignore` and check `git status` in pub before committing.
+- **meta silently not committed** in the *private* repo (global gitignore swallows `.wiki/`/`.tasks/`) → verify with `git check-ignore .wiki .tasks`; add negation lines if matched.
+- **Release without complete source in the public repo** → GPL violation. The public release must be fully buildable from what's published.
+
+## Side effects
+
+- Creates a **public** GitHub fork (outward-facing — visible to anyone).
+- Creates a private Gitea repo and two local working clones.
+- Touches git remotes, `gh`/GitHub API, and potentially tokens — confirm before any push or repo-visibility change.
+
+## What NOT to do
+
+- Don't use this for a purely-private project (no intent to publish) — no second repo needed.
+- Don't use it for purely-public open development (nothing to hide) — a normal fork+dev on GitHub is enough.
+- Don't use it for greenfield bootstrap of a new project with no upstream — that's `project-bootstrap`.
+- Don't create a standalone meta repo — meta lives inside the private dev repo. A separate meta repo is only for when the dev repo itself is public.
+- Don't publish by pushing dev history or by initializing a fresh repo — both break lineage.

skills/ralph-loop-execution/SKILL.md

@@ -0,0 +1,64 @@
+# ralph-loop-execution
+
+## When to Use
+
+Когда задача содержит поле `**Verifier:** <command>` — это ralph-loop задача. Активируй этот скил в начале работы.
+
+## Algorithm
+
+1. Прочитай задачу. Извлеки:
+   - `**Verifier:** <cmd>` — oracle-команда
+   - `**Attempts:** N` — текущий счётчик (0 если отсутствует)
+   - `**Max-Attempts:** M` — потолок (если отсутствует, дефолт 5)
+
+2. Выполни работу (code, tests, edits — всё что требует задача).
+
+3. Запусти verifier:
+   ```
+   <Verifier command>
+   ```
+
+4. **Если exit 0** → задача выполнена. Закрой задачу штатно (`**Status:** done`). Готово.
+
+5. **Если exit ≠ 0**:
+
+   a. Вычисли новый номер попытки: `N_new = N + 1`
+
+   b. Если `N_new >= M` (бюджет исчерпан):
+      ```
+      **Attempts:** <N_new>
+      **Status:** failed
+      ```
+      Добавь в конец description:
+      ```markdown
+      ## Attempt <N_new> (final) — budget exhausted
+      <stdout+stderr verifier>
+      ```
+      Завершай сессию.
+
+   c. Иначе (попытки ещё есть):
+      ```
+      **Attempts:** <N_new>
+      **Status:** ready
+      ```
+      Добавь в конец description:
+      ```markdown
+      ## Attempt <N_new> failure
+      <stdout+stderr verifier>
+
+      ### Что попробовал:
+      <краткое резюме что делал в этой итерации>
+      ```
+      Завершай сессию. Поллер подберёт задачу заново.
+
+## Reading Attempt History
+
+Когда клеймишь ralph-loop задачу с `**Attempts:** N > 0` — прочитай все секции `## Attempt K failure` в description. Это память о том, что уже не сработало. Не повторяй те же подходы.
+
+## Interactive Mode (/loop)
+
+В интерактивном `/loop` контексте: тот же алгоритм, но цикл внутренний (контекстное окно сохраняется). Запускай verifier в конце каждой итерации. `Max-Attempts` работает так же.
+
+## Key Invariant
+
+Verifier — единственный критерий готовности. Не закрывай задачу без `exit 0` от verifier, даже если субъективно кажется что всё правильно.

skills/session-inbox-monitor/SKILL.md

@@ -0,0 +1,141 @@
+---
+name: session-inbox-monitor
+version: 0.2.2
+description: >
+  Raises a persistent Monitor (Monitor tool, NOT background Bash) on the
+  project's `.claude-inbox/` at the start of an interactive session, so
+  inter-session messages page the session in real time; the monitor dies on
+  session end on its own. A paired SessionStart hook injects the
+  raise-instruction and first sweeps orphaned monitors of this inbox (a
+  `/clear` leaves them running → re-raise would stack duplicates). Triggers:
+  CLAUDE.md line `inbox monitor: raise on start`, or «подними монитор почты»,
+  «настрой авто-монитор инбокса», «raise inbox monitor», «auto-arm inbox
+  watcher». Headless (`claude -p`): does NOT raise — Monitor doesn't work
+  there; rely on the Stop-hook inbox pickup + Notify/ntfy. NOT for how to
+  handle a received message (→ inter-session-peer-discipline) nor the
+  multi-machine inbox backend (→ cross-machine-inbox design).
+---
+
+# session-inbox-monitor
+
+Auto-raises a session-length Monitor on `.claude-inbox/` at interactive-session
+start (via a paired SessionStart hook that injects the instruction and sweeps
+orphans), so inter-session messages page the session in real time. Tears down
+for free on session end. Headless sessions skip it and rely on the pull-model
+(Stop-hook pickup + Notify).
+
+## When to use
+
+- **Automatic (the common path).** The paired SessionStart hook injects an
+  instruction at the start of every interactive session of an opted-in project.
+  You act on that injection — raise the monitor as your first action — without a
+  user phrase.
+- **On request.** CLAUDE.md line `inbox monitor: raise on start`, or «подними
+  монитор почты», «настрой авто-монитор инбокса», «raise inbox monitor»,
+  «auto-arm inbox watcher».
+- **NOT for** handling the content of a received message (→
+  `inter-session-peer-discipline`), nor the multi-machine delivery backend (→
+  `cross-machine-inbox`). This skill is only the monitor's *lifecycle* on one
+  machine.
+
+## Inputs
+
+- `<project>/.claude-inbox/` — the watched directory. Direct-child `*.md` files
+  are inbox messages (the Stop-hook moves them to `.read/` once handled).
+- The SessionStart hook supplies the **exact Monitor command** to run, with the
+  sweep sentinel (`CLAUDE_INBOX_MONITOR`) and the absolute inbox path baked in.
+  Use it verbatim — do not hand-author a different poll command, or the sweep
+  won't recognise the process it spawns.
+
+## Steps
+
+1. **Mode check.** If this is a headless / non-interactive run (`claude -p`),
+   **STOP — do not raise a monitor.** The Stop-hook inbox pickup plus `Notify:`/
+   ntfy cover delivery there; a Monitor can't idle-watch in headless and is
+   killed ~5s after the run. There is no hook-level headless signal, so this is
+   your judgement call from the run context.
+2. **Raise exactly one persistent Monitor** using the command the hook injected:
+   the **Monitor tool** with `persistent: true`, `description: "inbox watcher"`.
+   The hook already swept any orphan before injecting, so you start from a clean
+   slate — raise one, not more.
+3. **Do not sweep yourself.** Killing orphans is the hook's job (it runs before
+   you, at SessionStart, when no other session activity is live).
+4. **On an event** (`New inter-session message in inbox: <name>`), read
+   `.claude-inbox/` and handle the message per `inter-session-peer-discipline`.
+   The Stop-hook also force-delivers any inbox messages at end of turn as a
+   backstop, so nothing is lost if the monitor missed a beat.
+5. **Teardown is automatic.** The Monitor dies at session end. Do **not** add a
+   SessionEnd teardown — and note `/clear` does not fire SessionEnd anyway
+   (that's why the sweep lives in SessionStart, not SessionEnd).
+
+## Deployment (machine-local)
+
+- Hook script: `skills/session-inbox-monitor/hooks/inbox-monitor.ps1` (versioned
+  here) → deploy to `~/.claude/hooks/inbox-monitor.ps1`.
+- Register in `~/.claude/settings.json` under `hooks.SessionStart` (no matcher →
+  fires on startup/resume/clear/compact), e.g.:
+  ```json
+  { "hooks": [ { "type": "command",
+      "command": "powershell -NoProfile -ExecutionPolicy Bypass -File \"C:\\Users\\<you>\\.claude\\hooks\\inbox-monitor.ps1\"",
+      "timeout": 15, "statusMessage": "inbox-monitor" } ] }
+  ```
+- Twin pattern: `poller-interactive-lock-writer` (`interactive-lock.ps1`).
+- Opt-in per project: the hook fires only when the project has a `.claude-inbox/`
+  directory **or** a CLAUDE.md line `inbox monitor: raise on start`.
+
+## Failure modes
+
+- **No inbox, no opt-in line** → the hook injects nothing; no monitor. Expected
+  for projects that don't use inter-session messaging.
+- **Two live interactive sessions on the same project** → the second session's
+  SessionStart sweep kills the first session's monitor (the match is
+  per-inbox-path, not per-session). Known limitation; the deliberate invariant is
+  "exactly one monitor per inbox per machine." If the first session is still
+  active, its next Stop-hook turn still delivers inbox mail — only the real-time
+  paging is lost until it re-raises. See `inter-session-peer-discipline`.
+- **Sweep over-match** → any *live* process whose command line contains both the
+  sentinel `CLAUDE_INBOX_MONITOR` and the inbox path is killed. At a real
+  SessionStart no agent/tool processes are running yet, so only the orphaned
+  monitor matches. Don't echo or run a command carrying that sentinel+path during
+  a session's startup.
+- **Headless didn't skip** → a monitor raised in headless is a harmless no-op,
+  killed ~5s after the run ends. The default errs toward raising because a
+  false-skip in an interactive session would silently lose the feature.
+- **Monitor auto-stopped** → the harness stops monitors that emit too many
+  events. The injected poll command de-dups by filename (pages once per message,
+  not every 15s) to stay under that bar.
+- **Mojibake on force-delivery** → the Stop-hook (`stop-dispatcher.ps1`) injects
+  message bodies to stdout; WinPS 5.1 must set `[Console]::OutputEncoding =
+  [System.Text.Encoding]::UTF8` or non-ASCII (Cyrillic) bodies arrive mangled
+  (it emits in the OEM code page under a harness-spawned redirected pipe). Inbox
+  messages must be written as **no-BOM UTF-8, LF** — the Write tool does this;
+  PowerShell writers must use
+  `[IO.File]::WriteAllText($p,$t,[Text.UTF8Encoding]::new($false))`, NOT
+  `Set-Content`/`Out-File -Encoding utf8` (which adds a BOM under 5.1). Same
+  WinPS-5.1 encoding class as the hook-source em-dash gotcha. Fixed + in-situ
+  verified 2026-06-17. The SessionStart injector (`inbox-monitor.ps1`) carries
+  the **same `[Console]::OutputEncoding` UTF-8 guard** as a forward-protection
+  (v0.2.2): it interpolates the inbox path into the injected JSON, so a non-ASCII
+  path or `additionalContext` would otherwise mangle the same way — the guard is
+  preventive (today's `$ctx` is ASCII) but cheaper than an "ASCII-only" invariant.
+
+## Side effects
+
+- Spawns one Monitor (and its backing Git-Bash poll process) per interactive
+  session; both die at session end.
+- Force-kills orphaned monitor processes of this inbox at every SessionStart.
+- **No repo writes.** The hook and its `~/.claude/settings.json` registration are
+  machine-local; only this skill (docs) and `.claude-inbox/` activity are in play.
+
+## What NOT to do
+
+- **Don't watch the inbox with a background Bash** (`run_in_background`) — it
+  leaks across `/clear` and accumulates zombies. Use the Monitor tool.
+- **Don't add a SessionEnd teardown hook** — the Monitor self-terminates, and
+  `/clear` never fires SessionEnd.
+- **Don't raise more than one monitor.** The hook guarantees a clean slate before
+  you raise.
+- **Don't handle message content here** — that's `inter-session-peer-discipline`.
+- **Don't rely on this in headless** — use the pull model (Stop-hook + Notify).
+  Active headless polling, if ever needed, is a separate cron Routine, not this
+  skill.

skills/session-inbox-monitor/hooks/inbox-monitor.ps1

@@ -0,0 +1,94 @@
+# SessionStart inbox-monitor injector hook (session-inbox-monitor skill).
+#
+# Two jobs, run on every SessionStart (startup / resume / clear / compact):
+#   (a) SWEEP  - kill orphaned inbox-monitor OS processes of THIS project.
+#                A `/clear` does NOT fire SessionEnd, so a Monitor's underlying
+#                poll process can outlive the session it belonged to. Without a
+#                sweep, re-raising would stack duplicates. Match is by a sentinel
+#                string (CLAUDE_INBOX_MONITOR) baked into the poll command PLUS
+#                this project's inbox path - so we never touch unrelated processes.
+#   (b) INJECT - additionalContext telling the agent to raise a persistent
+#                Monitor (Monitor TOOL, not background Bash) on <project>/.claude-inbox.
+#
+# Opt-in per project: fires only when the project has a `.claude-inbox/` dir OR a
+# CLAUDE.md line `inbox monitor: raise on start`.
+#
+# Headless (`claude -p`): there is NO reliable hook-level signal to detect it
+# (verified 2026-06-17 - `source` and CLAUDE_* env vars don't distinguish it).
+# So the hook injects unconditionally and the SKILL instructs the agent to skip
+# when headless. A Monitor raised in headless is harmless (killed ~5s after the
+# run ends); a false-skip in an interactive session would silently lose the
+# feature - so the default errs toward raising.
+#
+# Twin pattern: poller-interactive-lock-writer (interactive-lock.ps1).
+# Machine-local deploy target: ~/.claude/hooks/inbox-monitor.ps1 (registered in
+# ~/.claude/settings.json SessionStart). Versioned here for multi-machine rollout.
+
+param(
+    [string]$ProjectDir = $env:CLAUDE_PROJECT_DIR
+)
+
+if (-not $ProjectDir) { exit 0 }
+
+# UTF-8 stdout guard. This hook emits JSON (additionalContext) to a redirected
+# pipe under WinPS 5.1 - the same context that mojibaked stop-dispatcher output
+# (see session-inbox-monitor-stophook-utf8-fix). $ctx is ASCII today, but the
+# inbox path ($inboxFwd) is user-data interpolated into stdout, so set UTF-8 as a
+# forward-guard: a non-ASCII path or content never mangles the inject. Idempotent.
+[Console]::OutputEncoding = [System.Text.Encoding]::UTF8
+$OutputEncoding = [System.Text.Encoding]::UTF8
+
+$inbox    = Join-Path $ProjectDir '.claude-inbox'
+$claudeMd = Join-Path $ProjectDir 'CLAUDE.md'
+
+# --- opt-in gate -----------------------------------------------------------
+$optedIn = $false
+if (Test-Path $inbox) {
+    $optedIn = $true
+} elseif (Test-Path $claudeMd) {
+    if (Select-String -Path $claudeMd -SimpleMatch 'inbox monitor: raise on start' -Quiet -ErrorAction SilentlyContinue) {
+        $optedIn = $true
+    }
+}
+if (-not $optedIn) { exit 0 }
+
+# Forward-slash inbox path: the Monitor poll command (Git Bash) uses this form,
+# so both the sweep match and the injected command share one literal.
+$inboxFwd = ($inbox -replace '\\', '/')
+
+# --- (a) sweep orphaned monitors of THIS inbox -----------------------------
+# Match = sentinel AND this inbox's path in the same process command line.
+try {
+    Get-CimInstance Win32_Process -ErrorAction Stop |
+        Where-Object {
+            $_.CommandLine -and
+            $_.CommandLine -match 'CLAUDE_INBOX_MONITOR' -and
+            $_.CommandLine -like "*$inboxFwd*"
+        } |
+        ForEach-Object { Stop-Process -Id $_.ProcessId -Force -ErrorAction SilentlyContinue }
+} catch { }
+
+# --- (b) build the canonical Monitor poll command --------------------------
+# `: CLAUDE_INBOX_MONITOR` is a bash no-op carrying the sweep sentinel in the
+# process command line without polluting the event stream. De-dups by filename
+# so a sitting message pages once, not every 15s (a noisy monitor is auto-stopped).
+$cmd = @'
+: CLAUDE_INBOX_MONITOR; d='__INBOX__'; s=' '; while true; do for f in "$d"/*.md; do [ -e "$f" ] || continue; n=$(basename "$f"); case "$s" in *" $n "*) continue;; esac; s="$s$n "; echo "New inter-session message in inbox: $n - read .claude-inbox/ and handle it now"; done; sleep 15; done
+'@
+$cmd = $cmd.Trim().Replace('__INBOX__', $inboxFwd)
+
+# --- (c) inject the raise-instruction --------------------------------------
+$ctx = @"
+[session-inbox-monitor] This project participates in inter-session messaging. As your FIRST action, raise a persistent inbox watcher so messages from other sessions page you in real time.
+
+Use the Monitor tool with persistent: true, description "inbox watcher", and this EXACT command:
+
+$cmd
+
+Do NOT use a background Bash for this - it leaks across /clear. The Monitor tool is session-bound and tears down on its own at session end. The paired SessionStart hook already swept any orphaned watcher before this, so raise exactly one.
+
+If you are running headless (claude -p / non-interactive), SKIP this - the Stop-hook inbox pickup plus Notify cover delivery there. See the session-inbox-monitor skill for the full contract.
+"@
+
+@{ hookSpecificOutput = @{ hookEventName = 'SessionStart'; additionalContext = $ctx } } | ConvertTo-Json -Compress -Depth 5
+exit 0

skills/setup-agents-task-runner/README.md

@@ -0,0 +1,16 @@
+# setup-agents-task-runner
+
+L2 installer skill for the **standing-duty stack** — turns `agents-task-runner` + `watchdog` +
+`appeals-inbox` into platform-native OS services (systemd / launchd / winsw): no node window,
+OS-supervised autostart + crash-restart, run-as-user, hard deploy-boundary.
+
+- **Design:** `concepts/poller-standing-duty` (fork 1), OpeItcLoc03/common.
+- **Service templates:** `OpeItcLoc03/common @ lib/agents-task-runner/service/`.
+- **Factory module:** `agents-task-runner` in `~/.factory/factory.yaml`.
+
+Installs **disarmed** — scope is runtime config (`~/.config/projects-mcp/poller-scope.json`); arming a
+project for autonomous spawn is a separate operator step via the appeals-inbox pult. Cross-platform.
+Confirmation gates before every mutating phase (copies a deploy tree, fetches `winsw.exe`
+pinned+SHA256-verified, installs OS services).
+
+See `SKILL.md` for the full procedure.

skills/setup-agents-task-runner/SKILL.md

@@ -0,0 +1,252 @@
+---
+name: setup-agents-task-runner
+version: 0.1.0
+description: Installs the standing-duty stack (agents-task-runner + watchdog + appeals-inbox) as platform-native OS services — systemd user units on Linux, launchd LaunchAgents on macOS, winsw-wrapped services on Windows. No node window on any OS; OS-supervised autostart + crash-restart. Fetches winsw (pinned + SHA256-verified, not vendored). Installs DISARMED — scope is runtime config (poller-scope.json), arming is a separate operator step via the appeals-inbox pult. Use when the user says "install agents-task-runner service", "set up the standing-duty service", "deploy the poller as a service", "настрой службу раннера", "поставь дежурный стек как службу", "agents-task-runner службой", or when migrating off the old start-worker.ps1 Scheduled Task. Cross-platform — Windows / Linux / macOS. Installs OS services, fetches a binary, writes a scope file; pauses for confirmation before every mutating phase. This is the L2 installer for the `agents-task-runner` factory module.
+---
+
+# setup-agents-task-runner
+
+> One-time L2 installer that turns the standing-duty stack into platform-native OS services with a
+> hard deploy-boundary: the service runs from a factory-install copy, the dev tree
+> `.common/lib/agents-task-runner` stays editable, and editing the dev tree does NOT hot-patch the
+> running service. Stops at confirmation gates — it installs OS services, fetches `winsw.exe`, and
+> writes a runtime scope file.
+
+Design: `concepts/poller-standing-duty` (fork 1, OpeItcLoc03/common). Service templates live in
+`OpeItcLoc03/common @ lib/agents-task-runner/service/` (`README.md` is the launch-recipe SSOT).
+This skill is the `agents-task-runner` module declared in `~/.factory/factory.yaml`.
+
+## The three services
+
+`mongo` + `reconciler` stay in docker (own restart policy). This skill installs only the **host**
+node processes (LocalSpawnAdapter spawns the host `claude`, which docker can't):
+
+| service id | script | port | role |
+|---|---|---|---|
+| `agents-task-runner` | `task-runner/server.js` | 3000 | claim + spawn |
+| `agents-task-runner-watchdog` | `watchdog/watchdog.js` | — | hang-backstop + board hygiene |
+| `agents-task-runner-appeals-inbox` | `dist/index.js` | 4317 | HITL pult + arming control |
+
+**Two-level supervision:** OS supervisor = crash/exit restart (primary); watchdog = alive-but-hung
+backstop + board hygiene. Both kept — different failure modes, not duplicates.
+
+## When to use
+
+- User explicitly asks to install / set up / deploy the agents-task-runner (or "standing-duty") service.
+- Migrating off the legacy `start-worker.ps1` Scheduled Task (the live-patch-prone launcher this replaces).
+- New machine in the fleet that should run standing duty.
+
+## Out of scope
+
+- **Arming / going-live.** This skill installs the stack **disarmed**. Arming a project for autonomous
+  spawn is a runtime operator step via the appeals-inbox pult (writes `poller-scope.json`). Never arm
+  from this skill.
+- Editing runner / watchdog / appeals-inbox source — that's dev-tree work in `OpeItcLoc03/common`.
+- Building / registering `projects-meta-mcp` (that's `setup-projects-meta`) — this skill *uses* its
+  `dist/tasks-cli.js`.
+- docker `mongo` + `reconciler` bring-up (`docker compose -f docker-compose.yml -f docker-compose.host.yml up -d`).
+- Pushing any repo.
+
+## Hard rule: don't auto-mutate
+
+The procedure copies a deploy tree, fetches and runs a binary, installs OS services, and writes a
+scope file. **Pause for explicit confirmation between Phase 1 (discovery, read-only) and Phase 2
+(plan), and again before Phase 3+ (writes).** A trigger phrase authorizes discovery only.
+
+Two never-do guardrails:
+- **Never carry `POLLER_PROJECTS` or `DRY_RUN`** into any unit — scope is runtime config now. Their
+  presence is the exact anti-pattern this deploy removes.
+- **Never overwrite an existing *armed* `poller-scope.json`.** If it exists, leave it. Only create a
+  disarmed `{"armed":[]}` when absent.
+
+## Procedure
+
+### Phase 0 — Environment sanity (read-only)
+
+- Node ≥ 22 on PATH (`node --version`); capture the absolute node binary → `{{NODE_BIN}}`.
+- Dev tree present: `~/projects/.common/lib/agents-task-runner/` (source of `service/` templates +
+  the runner/watchdog) and `~/projects/.common/lib/appeals-inbox/`.
+- `projects-meta-mcp` built: `~/projects/.common/lib/projects-meta-mcp/dist/tasks-cli.js` exists
+  (→ `{{TASKS_BIN}}`). If missing → run `setup-projects-meta` first; stop.
+- Resolve `{{HOME}}`, `{{USER}}`, `{{PROJECTS_ROOT}}` (`~/projects`).
+- Detect OS → systemd (Linux) / launchd (macOS) / winsw (Windows).
+
+### Phase 1 — Discovery (read-only)
+
+Report "found / absent" for each; never echo secrets:
+
+- **Install dirs.** Default `{{INSTALL_DIR}}` / `{{APPEALS_DIR}}` per OS (Phase 2 table). Note if they
+  already exist (→ redeploy, not first install).
+- **Existing services.**
+  - Linux: `systemctl --user list-unit-files 'agents-task-runner*'`
+  - macOS: `ls ~/Library/LaunchAgents/site.kzntsv.agents-task-runner*`
+  - Windows: `sc.exe query agents-task-runner*` (or `Get-Service agents-task-runner*`)
+- **Legacy launcher.** Windows Scheduled Task `AgentsTaskRunnerWorker` (the `start-worker.ps1` task) —
+  flag it for teardown in Phase 2 (it must not coexist with the service — two task-runners = double-claim).
+- **Scope file.** `~/.config/projects-mcp/poller-scope.json` — present? armed (non-empty `armed[]`)? If
+  armed, record and DO NOT touch.
+- **winsw pin (Windows only).** Read `service/winsw/WINSW-PIN.md` — is `expected SHA256` filled (not the
+  `<FILL-FROM-RELEASE>` placeholder)? If placeholder → Phase 2 must STOP and ask the operator to fill it.
+
+### Phase 2 — Plan + confirm
+
+Present one block. Default install dirs:
+
+| OS | `{{INSTALL_DIR}}` | `{{APPEALS_DIR}}` | service mechanism |
+|---|---|---|---|
+| Linux | `~/.local/share/agents-task-runner` | `~/.local/share/appeals-inbox` | systemd `--user` |
+| macOS | `~/Library/Application Support/agents-task-runner` | `~/Library/Application Support/appeals-inbox` | launchd LaunchAgents |
+| Windows | `%LOCALAPPDATA%\agents-task-runner` | `%LOCALAPPDATA%\appeals-inbox` | winsw |
+
+```
+OS / mechanism:   <systemd | launchd | winsw>
+Install dirs:     <INSTALL_DIR> + <APPEALS_DIR>   (<first install | redeploy over existing>)
+Services:         agents-task-runner, -watchdog, -appeals-inbox   (run-as-user: <USER>, NOT root)
+Legacy teardown:  <Scheduled Task AgentsTaskRunnerWorker → disable | none>
+Scope file:       <create disarmed {"armed":[]} | exists, leave untouched (armed=<n>)>
+winsw (Win only): fetch v2.12.0 WinSW-x64.exe, verify SHA256=<filled | PLACEHOLDER → STOP>
+Run-as password:  <Windows: will prompt for <USER>'s password (run-as-user requirement)>
+Backups:          existing unit/config files → <file>.bak-<ts>
+```
+
+Wait for explicit "ok / go / поехали". State plainly: **this installs disarmed; nothing spawns until
+you arm a project via the pult.**
+
+### Phase 3 — Backup
+
+Copy any existing unit / plist / winsw config that will be overwritten to `<file>.bak-YYYYMMDD-HHMMSS`.
+Deploy copies need no backup (git is the backup).
+
+### Phase 4 — Deploy copy (the boundary)
+
+Sync the dev tree into the install dirs — the service runs from here, NOT the dev tree.
+
+```bash
+# runner (+ watchdog, which lives inside it)
+rsync -a --delete --exclude node_modules ~/projects/.common/lib/agents-task-runner/ "$INSTALL_DIR"/   # or robocopy /MIR on Windows
+( cd "$INSTALL_DIR" && npm ci --omit=dev )
+
+# appeals-inbox (build dist)
+rsync -a --delete --exclude node_modules ~/projects/.common/lib/appeals-inbox/ "$APPEALS_DIR"/
+( cd "$APPEALS_DIR" && npm ci && npm run build )   # produces dist/index.js
+```
+
+Windows: use `robocopy <src> <dst> /MIR /XD node_modules` instead of rsync. Verify
+`"$INSTALL_DIR"/task-runner/server.js`, `"$INSTALL_DIR"/watchdog/watchdog.js`, and
+`"$APPEALS_DIR"/dist/index.js` exist before proceeding.
+
+### Phase 5 — Render templates
+
+For each unit in `service/<systemd|launchd|winsw>/`, substitute the placeholders
+(`{{NODE_BIN}}`, `{{INSTALL_DIR}}`, `{{APPEALS_DIR}}`, `{{HOME}}`, `{{USER}}`, `{{TASKS_BIN}}`,
+`{{PROJECTS_ROOT}}`; Windows also `{{WINSW_USER_PASSWORD}}`) → rendered files. Create the log dirs the
+units reference (`~/.local/state/agents-task-runner/`, `~/Library/Logs/agents-task-runner/`, or
+`%LOCALAPPDATA%\agents-task-runner\logs`). Confirm no `{{...}}` token remains in any rendered file.
+
+### Phase 6 — Install services
+
+**Linux (systemd user):**
+```bash
+mkdir -p ~/.config/systemd/user
+cp <rendered>/*.service ~/.config/systemd/user/
+systemctl --user daemon-reload
+systemctl --user enable --now agents-task-runner-appeals-inbox.service \
+                              agents-task-runner.service \
+                              agents-task-runner-watchdog.service
+loginctl enable-linger "$USER"   # survive logout / start at boot
+```
+
+**macOS (launchd):**
+```bash
+cp <rendered>/*.plist ~/Library/LaunchAgents/
+for p in site.kzntsv.agents-task-runner-appeals-inbox site.kzntsv.agents-task-runner site.kzntsv.agents-task-runner-watchdog; do
+  launchctl unload ~/Library/LaunchAgents/$p.plist 2>/dev/null
+  launchctl load -w ~/Library/LaunchAgents/$p.plist
+done
+```
+
+**Windows (winsw):** follow `service/winsw/WINSW-PIN.md` verification contract first.
+```powershell
+# 1. Fetch + verify (ABORT on mismatch; STOP if pin is still the placeholder)
+Invoke-WebRequest <pinned-url> -OutFile "$INSTALL_DIR\winsw.exe"
+if ((Get-FileHash "$INSTALL_DIR\winsw.exe" -Algorithm SHA256).Hash -ne $ExpectedSha) { throw "winsw SHA256 mismatch" }
+# 2. winsw convention: <id>.exe + <id>.xml side by side. Copy winsw.exe per service id, place rendered xml.
+#    Then install + start each:
+& "$INSTALL_DIR\agents-task-runner.exe" install
+& "$INSTALL_DIR\agents-task-runner.exe" start
+# repeat for -watchdog and -appeals-inbox
+```
+Disable the legacy launcher so it can't coexist: `schtasks /change /tn AgentsTaskRunnerWorker /disable`
+(or `/delete` after confirming the service is healthy).
+
+### Phase 7 — Scope file (disarmed default)
+
+```bash
+mkdir -p ~/.config/projects-mcp
+# Only if absent — NEVER overwrite an existing (possibly armed) file:
+[ -f ~/.config/projects-mcp/poller-scope.json ] || echo '{"armed":[]}' > ~/.config/projects-mcp/poller-scope.json
+```
+
+### Phase 8 — Verify acceptance
+
+The design's acceptance criteria — verify each, show evidence:
+
+1. **Starts without a window.** No console window appears; `services.msc` / `systemctl --user status` /
+   `launchctl list` shows the three running.
+2. **Survives kill.** Kill the task-runner PID; within the restart window the OS supervisor respawns it
+   (re-check status / port 3000 answers again).
+3. **Reads scope from runtime config.** With `{"armed":[]}` the poller logs claim nothing (disarmed).
+   Optionally arm a throwaway entry in the scope file and confirm hot-reload picks it up WITHOUT a
+   restart (then revert) — but real arming is the operator's pult step, not this skill's.
+4. **No POLLER_PROJECTS / DRY_RUN** present in any installed unit (grep the rendered files).
+
+### Phase 9 — Final report
+
+```
+✅ Standing-duty stack installed as <mechanism> services, run-as-user <USER>, DISARMED.
+   Services: agents-task-runner (:3000), -watchdog, -appeals-inbox (:4317)
+   Install dirs: <INSTALL_DIR> + <APPEALS_DIR>  (dev tree stays editable — deploy-boundary)
+   Scope: ~/.config/projects-mcp/poller-scope.json = {"armed":[]} (nothing spawns yet)
+
+   GOING LIVE is a separate operator step: arm a project via the appeals-inbox pult
+   (http://127.0.0.1:4317). Until then the poller claims nothing.
+
+   Redeploy after a dev-tree change: re-run this skill (re-syncs install dir + restarts),
+   or `factory update agents-task-runner` once the L1 Go-CLI lands. Editing the dev tree
+   does NOT hot-patch the running service.
+
+   Backups: <files>.bak-<ts>. docker mongo+reconciler are separate — bring up via compose.
+```
+
+## Rollback
+
+1. Stop + remove the services:
+   - Linux: `systemctl --user disable --now agents-task-runner*.service; rm ~/.config/systemd/user/agents-task-runner*.service; systemctl --user daemon-reload`
+   - macOS: `launchctl unload ~/Library/LaunchAgents/site.kzntsv.agents-task-runner*.plist; rm ...`
+   - Windows: `& "$INSTALL_DIR\<id>.exe" stop; & "$INSTALL_DIR\<id>.exe" uninstall` per id
+2. Restore any `.bak-<ts>` files.
+3. Re-enable the legacy launcher only if you need the old path back:
+   `schtasks /change /tn AgentsTaskRunnerWorker /enable`.
+4. Install dirs are disposable copies — `rm -rf` them; the dev tree is untouched.
+5. Leave `poller-scope.json` as-is.
+
+## Cross-platform notes
+
+| | service unit | install location | run-as-user | boot-before-login |
+|---|---|---|---|---|
+| Linux | systemd `*.service` | `~/.config/systemd/user/` | inherent (user unit) | `loginctl enable-linger` |
+| macOS | launchd `*.plist` | `~/Library/LaunchAgents/` | inherent (LaunchAgent) | runs at login (Agent) |
+| Windows | winsw `<id>.xml` | `%LOCALAPPDATA%\agents-task-runner\` | `<serviceaccount>` + password | needs stored creds; login-triggered is acceptable on a personal box |
+
+## Common mistakes
+
+- **Skipping Phase 1.** Re-installing over an existing armed scope file or a running service without
+  noticing → double-claim or a clobbered arming state.
+- **Carrying `POLLER_PROJECTS` / `DRY_RUN`.** The whole point is runtime scope. Grep the rendered units.
+- **Leaving the Scheduled Task enabled alongside the service.** Two task-runners claim the same board →
+  double-claim. Disable the legacy launcher.
+- **Running as root / LocalSystem.** The runner needs the user's `~/.config`, `~/.claude`, git creds and
+  spawns `claude` — must be the user account.
+- **Fabricating / skipping the winsw SHA256.** STOP if the pin is the placeholder; abort on mismatch.
+- **Treating install as going-live.** Installed ≠ armed. Nothing spawns until the operator arms via the pult.
+- **Editing the dev tree and expecting the service to pick it up.** It won't — redeploy (re-sync + restart).

skills/task-format/SKILL.md

@@ -0,0 +1,95 @@
+---
+name: task-format
+version: 0.1.0
+description: >
+  Use when writing or editing a task block in a `.tasks/STATUS.md` board that an
+  autonomous task-runner ("poller") will read — so the task is actually claimed,
+  routed, and reported instead of silently skipped. Covers the exact block header,
+  the status emoji, and the `**Weight:**` / `**Notify:**` / `**Requirements:**`
+  fields the poller parses. Triggers: «оформить таску для поллера», «формат таски»,
+  «task block format», «make a task the poller will pick up», «add Weight/Notify»,
+  poller / agent-runner not claiming a task you wrote by hand.
+---
+
+# task-format
+
+The autonomous poller parses `.tasks/STATUS.md` line-by-line with **strict regexes**. A block runs only if its header and fields match exactly. Get the format wrong and the poller does not error — it silently skips the block, or claims it and then parks it. This is the canonical field reference.
+
+> Authoring a task for **another** project/agent via `mcp__projects-meta__tasks_create`? Use `delegate-task` — it drives the tool, which emits this format for you. This skill is the format itself: for **hand-edited** STATUS.md blocks and for understanding what the poller reads. For board working policy (claim/close/status), see `using-tasks`.
+
+## Canonical block (copy this)
+
+```markdown
+## ⚪ [my-task-slug] — One-line description of the work.
+
+**Status:** ready
+**Where I stopped:** (not started)
+**Next action:** First concrete step the claiming agent runs.
+**Branch:** master
+**Weight:** needs-claude
+**Notify:** OpeItcLoc03/workshop
+<!-- created-by: you@machine / from: OpeItcLoc03/workshop / 2026-06-11 -->
+
+---
+```
+
+## The two load-bearing rules
+
+1. **Header must match exactly:** `## <emoji> [<slug>] — <description>`
+   - `## ` (h2, two hashes) — **not** `### `, not a bullet.
+   - One status **emoji**, then `[slug]` in square brackets, then ` — ` (space, em-dash `—`, space), then the description. A `-` hyphen or `:` will not match.
+   - Slug: short, lowercase, kebab-case, Latin.
+   - A header that doesn't match is **not seen as a task at all**.
+
+2. **Fields are `**Label:** value` lines** — bold label, colon, space, value. Bullet-list fields (`- **weight:** …`) and prose ("notify workshop when done") are **ignored** — the poller never reads them.
+
+## Status emoji ↔ state
+
+| Emoji | State | |
+|---|---|---|
+| ⚪ | **ready** | the only state the poller claims |
+| 🔴 | active | claimed / in flight |
+| 🟡 | paused | resumable |
+| 🔵 | blocked | waiting on a `**Blocker:**` |
+| 🟢 | done | kept until merged |
+
+`**Status:**` mirrors the emoji in words. ⚪ → `ready`. **Do not** use 🟢 for "ready" — 🟢 is *done*.
+
+## Fields the poller parses
+
+| Field | Format | Meaning |
+|---|---|---|
+| `**Weight:**` | `cheap-ok` \| `needs-claude` \| `needs-human` | Routing tier. **Required for autonomous pickup** — see below. |
+| `**Notify:**` | `<owner>/<repo>` | Inbox target. Poller writes to that project's `.claude-inbox/` on close / park / delivery-failure. Omit → no report; the steering loop never closes. |
+| `**Requirements:**` | CSV, e.g. `needs-db, needs-secrets` | Hard capability gate. The agent must hold **all** listed capabilities or the task is skipped. |
+| `**Runtime allowed:**` | CSV, e.g. `claude-opus` | Runtime whitelist. If set, only a listed runtime may claim. |
+| `**Consult policy:**` | `auto` \| `human-only` \| `strict-human` | How a mid-run `consult` escalates. Default when absent: `human-only`. |
+| `**Blocker:**` | CSV of blocker slugs | Only on 🔵 blocked. Auto-unblock flips the task to ⚪ when every blocker is 🟢. |
+| `**Next action:** / **Where I stopped:** / **Branch:**` | free text | Core resumability fields. |
+
+`**Owner:** / **Claim token:** / **Claim expires at:**` are the **claim stamp** — the poller writes and clears them. Never author them by hand; a stale stamp on a ⚪ task blocks the poller.
+
+## Weight — the field that decides pickup
+
+The poller routes each claimed task to a backend by its weight tier:
+
+- `cheap-ok` — routine work, a cheap/weak model is fine.
+- `needs-claude` — needs a capable model (refactors, anything where discipline matters, review).
+- `needs-human` — **never** runs autonomously. The claim gate excludes it and the runner refuses to spawn. Use for anything touching critical infra: the poller/agent-runner itself, MCP servers, claim/close/heartbeat, deploy, CI/CD, git hooks.
+
+**No `**Weight:**` line → no backend tier matches → the poller claims the task, finds no route, and parks it to 🔵 blocked (`no backend for weight_tier: unknown`).** So a task you want run **must** carry a Weight. If in doubt and the work is ordinary code, use `needs-claude`.
+
+## Common mistakes (from baseline failures)
+
+| Mistake | Fix |
+|---|---|
+| `### Title` or a `- **id:** …` bullet list | Use the exact `## <emoji> [slug] — desc` h2 header + `**Field:**` lines. |
+| 🟢 for a ready task | 🟢 is *done*. Ready is ⚪. |
+| Inventing `risk: low`, `tier: L`, `priority`, `claimable-by` | The poller routes on `**Weight:**` with three fixed values only. |
+| Notification written as prose / "Done-signal" | Use a real `**Notify:** <owner>/<repo>` field line. |
+| Omitting Weight on a task you want auto-run | Always set Weight, or the task parks. |
+| Hyphen or colon instead of ` — ` in the header | The separator is space + em-dash + space. |
+
+## Verify
+
+After editing, the block is correct when: header is `## <emoji> [slug] — …`, the emoji matches `**Status:**`, every machine-read field is a `**Label:**` line (not a bullet), and a task meant for the poller has both `**Weight:**` (not `needs-human` unless intended) and `**Notify:**`.

skills/task-loop/SKILL.md

@@ -0,0 +1,117 @@
+---
+name: task-loop
+version: 0.1.0
+description: >
+  Use when the user asks you to work the task board yourself, in this
+  session, one task after another — «поработай очередь», «прогони доску»,
+  «бери задачи по очереди», «работай пока не скажу стоп», «work the queue»,
+  «drain the board», «keep working tasks until I say stop». Does NOT apply
+  to delegating work to another agent/project (→ delegate-task), to one
+  named task you already know (→ using-tasks), or to configuring the
+  background poller.
+---
+
+# task-loop
+
+Work the board **in this session**: claim the next ready task, do it, close it, claim the next — until the queue is empty or the user says stop.
+
+**Core principle:** an interactive loop, not a daemon. You stay in the chair. Empty queue → **stop and report**, never spin a wait-timer. No subprocess, no `CronCreate` (that schedules a *separate* session — exactly the daemon you're replacing), no short `ScheduleWakeup` poll — those are the unattended poller's job, not yours here.
+
+**REQUIRED SUB-SKILL:** `using-tasks` owns the board, the `.tasks/.lock` session lock, the `session_break` gate, and the pre-close coverage check. This skill drives the loop *through* those rules — it does not replace them.
+**REQUIRED SUB-SKILL:** `project-discipline` — commit/push gate (Rule 4) and sensitive-artifact handling apply to every task you touch.
+
+## When to use
+
+**Activates:** «поработай очередь», «прогони доску», «бери задачи по очереди», «работай пока не скажу стоп», «work the queue», «drain the board», «keep working tasks until I say stop».
+
+**Does NOT apply:**
+- Delegating work to another agent/project → `delegate-task`.
+- One specific task you already named → `using-tasks` (switch/resume that task).
+- Setting up / debugging the background poller or agent-runner → that is infra, not this loop.
+
+## The loop
+
+Run this cycle. One task at a time.
+
+```dot
+digraph task_loop {
+  rankdir=TB;
+  claim   [shape=box,   label="tasks_claim_next\n(current project, confirm=true)"];
+  empty   [shape=diamond,label="task returned?"];
+  stop    [shape=box,   label="STOP — report board drained"];
+  work    [shape=box,   label="do the work this session"];
+  done    [shape=diamond,label="completed?"];
+  park    [shape=box,   label="park: blocked (external) | paused (resumable)"];
+  gate    [shape=diamond,label="consult_policy = human-only/strict-human?"];
+  consult [shape=box,   label="STOP before close/commit — consult user"];
+  close   [shape=box,   label="pre-close coverage check → tasks_close"];
+  brk     [shape=diamond,label="session_break marker on closed task?"];
+  boundary[shape=box,   label="STOP — print SESSION BOUNDARY"];
+
+  claim -> empty;
+  empty -> stop [label="no ready tasks"];
+  empty -> work [label="yes"];
+  work -> done;
+  done -> park [label="no"];
+  done -> gate [label="yes"];
+  gate -> consult [label="yes"];
+  gate -> close  [label="auto"];
+  close -> brk;
+  brk -> boundary [label="yes"];
+  brk -> claim    [label="no"];
+  park -> claim;
+}
+```
+
+1. **Claim** the next ready task with `tasks_claim_next(claimer_identity, filter, confirm=true)`.
+   - `claimer_identity` = `<machine>:<runtime>:<session>` (e.g. `DESKTOP-NSEF0UK:claude-opus:<session>`).
+   - `filter.project` = **the current project** (qualified `<owner>/<repo>`) by default. Only widen to other projects when the user explicitly asks ("прогони все доски" / passes a project list).
+   - The server already excludes `weight: needs-human` and anti-self-review tasks — you will never claim those.
+2. **No task returned** → the queue is drained. **STOP** and report (see *Empty queue*). Do not poll.
+3. **Do the work this session.** All your tools are available. Read the task description and per-task `<slug>.md`. Set the task `active` if it isn't already.
+4. **Honor the gate before the irreversible step.** Use the `consult_policy` returned by the claim:
+   - `auto` → full autopilot through close.
+   - `human-only` / `strict-human` → do the work, then **STOP before `tasks_close` / commit** and consult the user. Don't barrel through.
+   - **Push is never automatic** regardless of policy — `project-discipline` Rule 4 (commit freely, push only on an explicit per-session grant).
+5. **Close** with the `using-tasks` pre-close coverage check, then `tasks_close(target_project, slug, confirm=true, note=…)`.
+6. **session_break gate.** After the close, **before claiming the next task**, honor the `using-tasks` `session_break` check: if the closed task carries the marker → print the `🔚 SESSION BOUNDARY` line and **STOP** (do not claim next). Otherwise → back to step 1.
+
+## When a task can't be finished
+
+Never leave a claimed task hanging (its claim expires in 10 min and it returns as a zombie), and never `tasks_close` unfinished work (that lies to the board).
+
+- **External / unresolvable blocker** discovered mid-task (missing upstream, needs a human decision, scope change) → `tasks_update(slug, status="blocked", blocker="<concrete fact + what's needed>")`. Roll back partial work that would break the build. Then continue the loop (the blocker is isolated; the next claim won't return this task).
+- **Interrupted or resumable by you** (you ran out of budget, the user stops you mid-task) → `tasks_update(slug, status="paused", where_stopped=…, next_action=…)`.
+
+A single failing task does not stop the loop — park it and move to the next.
+
+## Empty queue & stopping
+
+The loop ends on the **first** of:
+- **Empty queue** — `tasks_claim_next` returns no ready task → stop, report what you closed/parked, and wait for the user. Do **not** `ScheduleWakeup`, `CronCreate`, or sleep-poll for new tasks.
+- **Explicit user signal** — «стоп», «хватит», «отбой». Park any in-flight claimed task (paused) before stopping.
+- **Budget** — `budget.remaining()` near zero → park the current task (paused) and report.
+
+**Long-running watch (opt-in only).** If the user explicitly says «работай пока не скажу стоп» *and* wants you to keep checking for newly-arrived tasks, use **`ScheduleWakeup`** — it re-invokes *this* session — with a **long** interval (≥1200 s). **Never `CronCreate`** even here: it starts a *separate* scheduled session, i.e. the daemon this skill exists to avoid. And never a short poll. Default is still stop-on-empty; only arm a wakeup on an explicit standing request.
+
+## Heartbeat
+
+A claim lives 10 minutes. If a single task will take longer than ~8 minutes, call `tasks_heartbeat(slug, claim_token)` periodically to keep the claim alive. Short tasks need no heartbeat. (The in-session `.tasks/.lock` is a separate 2-hour lock owned by `using-tasks` session start/end — don't manage it from the loop.)
+
+## What NOT to do
+
+- **No daemon, no `CronCreate`, no spawned claude, no subprocess** to "run the queue" — `CronCreate` starts a separate scheduled session; the whole point is you do it in *this* session.
+- **No busy-poll on empty** — empty queue is a natural stop, not a wait-loop. A short `ScheduleWakeup` loop burns tokens for nothing. The only exception is the explicit long-watch opt-in above (a single ≥1200 s `ScheduleWakeup`, never `CronCreate`).
+- **Don't widen scope silently** — default to the current project; claim other boards only when the user asks.
+- **Don't `tasks_close` unfinished work** and **don't leave a task claimed** when blocked — park it (blocked/paused).
+- **Don't skip the `session_break` gate** between tasks — a milestone/domain-switch marker means stop, even if more tasks are ready.
+- **Don't autopilot through a `human-only`/`strict-human` task's close/commit**, and **never auto-push** — consult first.
+- **Don't blind-retry** a task that failed for an external reason — diagnose once, record the blocker, move on.
+
+## Red flags — STOP
+
+- "I'll set a timer to check for new tasks" → no. Stop on empty; report.
+- "I'll spawn a background worker to drain faster" → no. One task at a time, this session.
+- "User said work-until-stop, I'll `CronCreate` a recurring run" → no. `CronCreate` is a separate scheduled session = the daemon. Long-watch uses a single long `ScheduleWakeup` on *this* session.
+- "It's sensitive but consult_policy says auto, I'll just commit" → push still needs a grant; sensitive close still respects the gate.
+- "The task isn't done but I'll close it and note it" → never close unfinished. Park it.

skills/using-markitdown/SKILL.md

@@ -1,40 +1,36 @@
 ---
 name: using-markitdown
-version: 1.0.0
+version: 1.0.1
 description: Use when capturing external content into a markdown-based knowledge base, wiki `raw/` directory, or any pipeline that must preserve the source's full text — for web pages, PDFs, DOCX/PPTX/XLSX, EPUB, CSV/JSON/XML, ZIP archives, images (with OCR/EXIF), audio (with transcription), or YouTube URLs. Also use when WebFetch returned an LLM-summarized version but the raw content is what's needed.
 ---
 
 # using-markitdown
 
-> Convert almost any URI to plain markdown using Microsoft's `markitdown` MCP server. Returns **raw textual content**, not an LLM summary.
+> Convert almost any path or URL to plain markdown using Microsoft's `markitdown` CLI (v0.1.6, on `PATH`). Returns **raw textual content**, not an LLM summary.
 
 ## Tool
 
 ```
-mcp__markitdown__convert_to_markdown(uri: string) → markdown string
+markitdown <path|url>            # → markdown to stdout
+markitdown <path|url> -o out.md  # → write markdown to a file
+cat file.pdf | markitdown        # → read from stdin (use -x/-m to hint the format)
 ```
 
-`uri` accepts: `http://`, `https://`, `file://`, `data:`.
+The positional argument accepts a **local file path** (host path, normal slashes) or an `http://` / `https://` URL. The CLI runs natively, so it sees your full host filesystem — no Docker mount, no `file://` URI translation, no path rewriting.
 
-## Local files — Docker-mount caveat (READ FIRST)
+Useful flags: `-o <file>` (write to a file instead of stdout), `-x <ext>` / `-m <mime>` (format hint when reading from stdin).
 
-The markitdown MCP usually runs in a **Docker container** with a single host directory bind-mounted. The container does **not** see your full host filesystem. `file://` URIs must point to the **in-container path**, not the host path.
+## Local files
 
-1. Open `~/.claude.json` and find `mcpServers.markitdown.args`. Look for the `-v` flag — e.g. `-v C:\Users\vitya:/workdir` means host `C:\Users\vitya` is mounted at `/workdir` inside the container.
-2. Translate the host path to the container path before forming the URI.
-3. Forward slashes only inside the container path.
-
-**Example.** Host file at `C:\Users\vitya\modular\heart-and-mask\.wiki\raw\foo.html` with mount `C:\Users\vitya:/workdir`:
+Pass the host path directly — relative or absolute, with native separators:
 
 ```
-file:///workdir/modular/heart-and-mask/.wiki/raw/foo.html
+markitdown C:\Users\vitya\modular\heart-and-mask\.wiki\raw\foo.html -o foo.md
 ```
 
-**Symptom of getting this wrong:** `[Errno 2] No such file or directory: '/c:/Users/...'` — the container literally tried to open the host-shaped path. The fix is path translation, not URL encoding.
+No mount caveats: the CLI is a normal local process. The old Docker `-v` mount translation and `/c:/Users/...` `[Errno 2]` symptom no longer apply.
 
-**If the file falls outside the mount:** either copy it into the mounted tree, or extend the mount in `~/.claude.json` (a Claude restart is required for MCP changes to take effect — MCP servers are spawned at session start).
-
-**Filenames.** Non-ASCII filenames (Cyrillic, etc.) inside `file://` URIs are flaky across the URL-encode → urllib → Docker → host-FS chain. Rename to Latin kebab-case **before** calling markitdown.
+**Filenames.** Non-ASCII filenames (Cyrillic, etc.) still travel better as Latin kebab-case through downstream wiki/ingest steps. Rename to Latin kebab-case before saving the output, per `.wiki/CLAUDE.md` naming rules.
 
 ## When to use
 
@@ -47,18 +43,19 @@ file:///workdir/modular/heart-and-mask/.wiki/raw/foo.html
 - You only need a *summary* or an *answer about* a page → use **WebFetch** (cheaper, runs through a small model, returns prose).
 - The URI is GitHub/PR/issue/release content → use `gh` CLI (richer metadata, structured output).
 - The URI is private/authenticated (GDocs, Confluence, Jira, Slack, Notion, `share.google/*` sign-in walls) → markitdown receives the **public-facing fallback page** (sign-in screen, cookie banner) and returns *that* as markdown. Verify the result is real content before saving.
-- **The URI is a browser-rendered web page the user is already viewing** → ask the user to capture it via **Obsidian Web Clipper** (browser extension, runs Readability extraction client-side) and drop the resulting `.md` into `raw/`. Web Clipper output is dramatically cleaner than markitdown's HTML pass — no nav chrome, no sidebar history, no cookie banners — plus it carries YAML frontmatter (title / source URL / date) out of the box. Reserves markitdown for things browsers can't easily save (PDF, DOCX, PPTX, XLSX, EPUB, file:// resources). Note: rename the resulting file to Latin kebab-case before ingest (Web Clipper preserves the page `<title>` verbatim, often non-ASCII).
+- **The URI is a browser-rendered web page the user is already viewing** → ask the user to capture it via **Obsidian Web Clipper** (browser extension, runs Readability extraction client-side) and drop the resulting `.md` into `raw/`. Web Clipper output is dramatically cleaner than markitdown's HTML pass — no nav chrome, no sidebar history, no cookie banners — plus it carries YAML frontmatter (title / source URL / date) out of the box. Reserves markitdown for things browsers can't easily save (PDF, DOCX, PPTX, XLSX, EPUB, local files). Note: rename the resulting file to Latin kebab-case before ingest (Web Clipper preserves the page `<title>` verbatim, often non-ASCII).
 
 ## Pattern: ingest a remote source into a wiki
 
 ```
-1. mcp__markitdown__convert_to_markdown(uri="https://example.com/foo.pdf")
-2. Inspect the head of the result. If it looks like a sign-in/cookie/consent page, abort — ask the user for an alternative (manual save, paste, authenticated MCP).
-3. Write the result to .wiki/raw/<slug>.md (kebab-case, Latin only).
-4. Register the new file in .wiki/raw/README.md.
-5. Hand off to the wiki ingest workflow (creates sources/<slug>.md summary + entity/concept updates).
+1. markitdown "https://example.com/foo.pdf" -o .wiki/raw/<slug>.md   (kebab-case, Latin only)
+2. Inspect the head of the result. If it looks like a sign-in/cookie/consent page, abort — ask the user for an alternative (manual save, paste, authenticated source).
+3. Register the new file in .wiki/raw/README.md.
+4. Hand off to the wiki ingest workflow (creates sources/<slug>.md summary + entity/concept updates).
 ```
 
+For a huge (book-length) document, write straight to a file with `-o` and summarize *from the saved file* — do not pipe the whole markdown through working context.
+
 ## Common gotchas
 
 | Symptom | Cause | Fix |
@@ -66,8 +63,8 @@ file:///workdir/modular/heart-and-mask/.wiki/raw/foo.html
 | Output is a Google/Microsoft sign-in page in some random language | URI behind auth wall | Ask user to export the content manually (Save as PDF, copy-paste) and put it in `raw/` |
 | Output is mostly nav/cookie banner text | Site is JS-rendered or anti-bot | Try the cached or print URL; or ask user for HTML export |
 | Output lacks images / diagrams | Markdown is text-only by design | Save the original asset separately under `raw/assets/`; reference it from the `sources/` summary |
-| Tool not available in session | MCP server not loaded | Confirm `mcp__markitdown__convert_to_markdown` appears via ToolSearch; load with `select:mcp__markitdown__convert_to_markdown` |
-| Huge output (book-length) | Whole document converted in one call | Save raw, then summarize *from the saved file* — do not hold the entire markdown in working context |
+| `markitdown: command not found` | CLI not on `PATH` | Confirm with `markitdown --version` (expect `markitdown 0.1.6`); install with `pip install markitdown[all]` if missing |
+| Huge output (book-length) | Whole document converted in one call | Use `-o <file>` to save raw, then summarize *from the saved file* — do not hold the entire markdown in working context |
 
 ## Quick contrast with WebFetch and Web Clipper
 

skills/using-system-snapshot/SKILL.md

@@ -0,0 +1,77 @@
+---
+name: using-system-snapshot
+version: 0.1.0
+description: "Use at the start of an ops-context session, and ALWAYS before asserting anything about the agent poller, local docker containers, or cross-project task load — call `mcp__projects-meta__meta_system_snapshot` instead of running `tasklist` / `docker ps` / `meta_status` by hand. Triggers on «что запущено», «что сейчас крутится», «состояние системы», «состояние машины», «поллер работает?», «поллер живой?», «что с докером», «сводка по задачам», «what's running», «system status», «system snapshot», «is the poller up», «is the runner alive», «what containers are up». Read-only — no per-session grant needed. Skip for deep single-container docker diagnosis (that's using-vds-ops for the VDS / docker logs locally) and for mutating or precise per-task work (that's using-projects-meta)."
+---
+
+# using-system-snapshot
+
+## Overview
+
+One call — `mcp__projects-meta__meta_system_snapshot` — returns a whole-machine ops snapshot: agent **poller** status, local **docker** containers, and a cross-project **task** summary (active / blocked counts) from the projects-meta cache. It replaces the old scatter of `tasklist`, `docker ps`, and a manual `meta_status` read with a single round-trip.
+
+**Core rule: never assert the state of the poller, local containers, or task load without calling this tool first.** Memory and "it was running earlier" are not evidence.
+
+## When to use
+
+- Session start in an **ops context** — orienting before doing infra / runner / task-board work.
+- The user asks what's alive: «что запущено», «состояние системы», «поллер работает?», «что с докером», «what's running», «is the poller up».
+- **Before any claim** about whether the poller is running, which projects it scans, whether a container is up/healthy, or how many tasks are active/blocked.
+- A quick cross-project task-load glance ("where's the work concentrated right now").
+
+## When NOT to use
+
+- Deep diagnosis of **one** container (logs, inspect, stats, restart-loops) — that's `using-vds-ops` for the Rusonyx VDS, or `docker logs` locally. The snapshot only gives name + status.
+- **Mutating** task state, or reading the **full** board / a precise per-task body — that's `using-projects-meta` (and local `.tasks/` disk for the current project).
+- Library docs, code search, single-file questions — unrelated.
+
+## Prerequisites
+
+Requires the tool `mcp__projects-meta__meta_system_snapshot` (shipped by the `projects-meta-mcp` server; the `meta-system-snapshot` capability lives in `OpeItcLoc03/common`). If the tool is missing from the session, the server isn't registered — trigger **`setup-projects-meta`** to install and register it, then retry.
+
+## The call
+
+`mcp__projects-meta__meta_system_snapshot` takes **no arguments**. Read-only — call it directly, no preview / confirm, no per-session grant.
+
+It returns three keys:
+
+| Key | Shape | Liveness |
+|---|---|---|
+| `poller` | `{ running: bool, projects: "<owner/repo …>" }` | **live** at call time |
+| `docker` | `[{ name, status }]` — local containers | **live** at call time |
+| `tasks` | `{ "<owner>/<repo>": { active, blocked }, … }` | **from the projects-meta cache** — may be stale |
+
+`docker` is the **local** machine's containers (includes `agents-task-runner-*`), NOT the VDS. `tasks` counts mirror the cache, so treat them as approximate; for accurate task state run the `using-projects-meta` Step 0 freshness gate or read local `.tasks/` on disk.
+
+## Output format — one line per section
+
+Compress the JSON into **three lines**. Don't dump the raw object.
+
+```
+🟢 Poller running — OpeItcLoc03/claude-skills     (🔴 if running:false)
+🟢 Docker — 8/8 up                                 (else list only the bad ones)
+📋 Tasks — 23 active / 41 blocked, 17 projects     (name the busiest 2–3)
+```
+
+Rules per line:
+
+- **Poller** — 🟢/🔴 + running flag + the `projects` string. If stopped, say so plainly — that's the headline.
+- **Docker** — if every status starts with `Up` (incl. `Up … (healthy)`), report `N/N up`. Otherwise list **only** the problem containers by name + status (`Restarting`, `Exited`, `(unhealthy)`, `Created`, `Paused`). Don't enumerate healthy ones.
+- **Tasks** — totals (Σ active / Σ blocked across all projects) + the 2–3 projects with the most active work. Full per-project breakdown only if asked.
+
+## What NOT to do
+
+- **Do NOT** state "the poller is running" / "all containers are up" / "you have N active tasks" from memory or a prior snapshot. Call the tool in the current turn first. A snapshot from earlier in the session is already stale for liveness claims.
+- **Do NOT** fall back to `tasklist` / `docker ps` / a manual `meta_status` to answer these questions — that's the scatter this skill exists to replace. (Drop to raw `docker logs` only for the deep single-container diagnosis this skill explicitly defers.)
+- **Do NOT** paste the raw JSON. Three lines, one per section.
+- **Do NOT** present `tasks` counts as exact — they come from the cache. Flag staleness if precision matters, and point at `using-projects-meta`.
+
+## Common mistakes
+
+| Mistake | Fix |
+|---|---|
+| "Poller's still up" without calling the tool this turn | Call `meta_system_snapshot` first — liveness claims need current evidence. |
+| Running `docker ps` / `tasklist` instead | Use the single snapshot call; that's the point. |
+| Reading the snapshot's `docker` as the VDS fleet | It's the **local** machine. VDS containers → `using-vds-ops`. |
+| Treating `tasks` counts as authoritative | They're cached. For exact state use `using-projects-meta` Step 0 or local `.tasks/`. |
+| Dumping the raw JSON object | Collapse to three lines (poller / docker / tasks). |

skills/using-tasks/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: using-tasks
-version: 1.1.0
+version: 1.4.0
 description: >
   Policy skill for working with an existing `.tasks/` board (per-task files + STATUS.md).
   Use whenever the user is switching between tasks, resuming a paused task, starting a new
@@ -33,12 +33,19 @@ If `.tasks/` is **missing**, or `STATUS.md` exists but is non-canonical (e.g. fl
 ```
 <monorepo-root>/
   .tasks/
-    STATUS.md          ← board: one block per task, sorted by priority
+    STATUS.md          ← active board: 🔴 / 🟡 / ⚪ / 🔵 blocks, sorted by priority
     <task-slug>.md     ← deep context per task, one file each
+    .lock              ← runtime session lock; **gitignored** (never committed)
+    archive/
+      YYYY-MM.md       ← 🟢 done blocks moved off the board, one file per month
 ```
 
 Commit `.tasks/` to git. Decision history is valuable; diffs show how thinking evolved.
 
+`STATUS.md` is the **active** board — it must stay lean so orientation reads stay cheap. Closed 🟢 tasks are archived to `archive/YYYY-MM.md` once they pile up; see "### Archiving done tasks".
+
+> **`.tasks/.lock` must be listed in `.gitignore`** (add `.tasks/.lock` to your project's `.gitignore`). The lock file is ephemeral runtime state, not project history — it must never be committed.
+
 ---
 
 ## STATUS.md format
@@ -52,6 +59,7 @@ _Updated: YYYY-MM-DD_
 **Where I stopped:** one sentence — the exact thought or action interrupted
 **Next action:** one concrete step to resume immediately
 **Blocker:** (only if blocked) what is preventing progress
+**Session break:** (optional) `true` — or a hint string for the next track. Marks this task as a session boundary.
 **Branch:** git branch name
 
 ---
@@ -61,9 +69,21 @@ _Updated: YYYY-MM-DD_
 - 🔴 Active — currently worked on (only one at a time)
 - 🟡 Paused — in progress, resumable
 - ⚪ Ready — not started, fully defined
-- 🟢 Done — completed, kept until merged
+- 🟢 Done — completed; kept on the board until merged, then archived (see "### Archiving done tasks")
 - 🔵 Blocked — waiting on external input
 
+### `session_break` marker
+
+A task may carry a `session_break` marker — set by whoever defines the task (e.g. the delegating workshop) when its completion is a natural place to stop and start a fresh session. It signals an autonomous agent: *finish this task, then pause instead of immediately claiming the next one.*
+
+- **Type:** boolean or string.
+  - `session_break: true` — pause after close; the next track is "see STATUS.md".
+  - `session_break: "<hint>"` — pause after close; `<hint>` names the recommended next track.
+- **Where it lives:** in the task's frontmatter when delivered via the task system (`session_break: true` / `session_break: "<hint>"`); mirrored on the local board as the optional `**Session break:**` field in the task's STATUS.md block.
+- **Absent →** behaviour is unchanged: close the task and continue as usual.
+
+The check is enforced in the **Task completion** flow below (after close, before claiming the next task).
+
 ---
 
 ## Per-task file format (`<task-slug>.md`)
@@ -98,18 +118,35 @@ Temporary hypotheses, links, names of people to consult.
 ## Agent operations
 
 ### Session start
-1. Check if `.tasks/STATUS.md` exists. If not → invoke `setup-tasks` and stop here until it returns.
-2. Read `STATUS.md`.
-3. If user names a task, read its `<task-slug>.md`.
-4. Confirm in one sentence: "We're in the middle of X, next step is Y."
-5. Ask if the plan is still correct before doing anything.
-6. If STATUS.md `_Updated` date is >3 days ago, flag it and ask user to confirm current state.
+1. **Session lock guard.** If `.tasks/` exists, read `.tasks/.lock`.
+   - **Active agent lock** — `type:"agent"` with `heartbeat` ≤ 10 minutes old: print the hard warning below and **require explicit user confirmation** before proceeding. Do not touch the board until the user confirms.
+     ```
+     ⚠️ поллер ведёт <slug> — нельзя работать параллельно
+     ```
+     (Substitute the `slug` field from the lock file if present, otherwise omit it.)
+   - **Stale lock** — any type whose TTL has expired (`type:"agent"` with `heartbeat` > 10 min ago; `type:"interactive"` with `started_at` > 2 h ago): silently overwrite.
+   - **Absent or stale lock** (including after user confirmation): write `.tasks/.lock`:
+     ```json
+     {"type":"interactive","started_at":"<ISO8601>","ttl_minutes":120}
+     ```
+2. Check if `.tasks/STATUS.md` exists. If not → invoke `setup-tasks` and stop here until it returns.
+3. Read `STATUS.md` — this is the orientation read (see note below on why it's a local read, not an MCP call).
+4. If user names a task, read its `<task-slug>.md`.
+5. Confirm in one sentence: "We're in the middle of X, next step is Y."
+6. Ask if the plan is still correct before doing anything.
+7. If STATUS.md `_Updated` date is >3 days ago, flag it and ask user to confirm current state.
+8. If `STATUS.md` holds **≥ 10** 🟢 done blocks, archive them first (see "### Archiving done tasks") so the board you orient on is lean.
+
+> **Orient by reading the local `STATUS.md`, not an MCP call.** It is the live board and — kept lean by archival — cheap to read. Do **not** reach for projects-meta tools to enumerate the current project's board:
+> - `tasks_aggregate` is cache-based, cross-project, and does **not** index ready/done — its own docs say to read `.tasks/STATUS.md` directly for the current project.
+> - `tasks_get_status(target_project, slug)` returns a **single** task's live status (`{status, found}`) by a slug you already know — it cannot list the board. Use it only to check **one** known task (e.g. confirm a delegated task's board state, or detect async-human parking), never for orientation.
 
 ### Session end / pause / switch
-1. Update `STATUS.md`: set current task to 🟡, update "Where I stopped" and "Next action".
-2. Append to `<task-slug>.md` Decisions log any non-obvious choices made this session.
-3. Move finished items to "Completed steps".
-4. Commit: `git add .tasks/ && git commit -m "chore: update task status [<task-slug>]"`
+1. **Release session lock.** If `.tasks/.lock` exists and contains `"type":"interactive"`: delete `.tasks/.lock`. (Stale interactive locks are cleaned up here too; silently delete any interactive lock regardless of TTL.)
+2. Update `STATUS.md`: set current task to 🟡, update "Where I stopped" and "Next action".
+3. Append to `<task-slug>.md` Decisions log any non-obvious choices made this session.
+4. Move finished items to "Completed steps".
+5. Commit: `git add .tasks/ && git commit -m "chore: update task status [<task-slug>]"`
 
 ### Task switch
 1. Perform session-end operations for the current task.
@@ -133,6 +170,43 @@ Temporary hypotheses, links, names of people to consult.
 3. Set status to 🟢 in STATUS.md.
 4. Append final summary line to Decisions log.
 5. Remind user to delete the branch after merge.
+6. **Session-break check (after close, before claiming the next task).** Once the task is 🟢 and committed — and **before** any `tasks_claim_next` or starting the next task — read the closed task's `session_break` marker (its frontmatter `session_break`, or the `**Session break:**` field in its STATUS.md block). If present:
+   - Print this line **verbatim**, substituting the closed task's slug for `[slug]` and the marker's string value for `[value | "см. STATUS.md"]` (use the literal `см. STATUS.md` when the marker is just `true`):
+
+     `🔚 SESSION BOUNDARY — [slug] закрыта. Рекомендую завершить текущую сессию. Следующий трек: [value | "см. STATUS.md"]`
+
+   - **Stop.** Do not claim or start the next task.
+   - If the marker is absent → behaviour is unchanged: proceed to claim / start the next task as usual.
+7. **Archival check.** After the close is committed, if `STATUS.md` now holds **≥ 10** 🟢 done blocks, archive them (see "### Archiving done tasks"). This keeps the board lean for the next orientation read.
+
+### Archiving done tasks
+
+🟢 done blocks accumulate in `STATUS.md` and bloat it — and since orientation reads the whole board, a bloated file burns context on every session start (the recurring "huge STATUS.md" complaint). Keep the board lean: done blocks stay only until merged, then move to a monthly archive.
+
+**Threshold.** When `STATUS.md` holds **≥ 10** 🟢 done blocks, archive them. Check at two moments: (a) right after closing a task (Task completion step 7), and (b) at session start, before orienting (Session start step 7). The threshold is a ceiling, not a target — archive in batches; don't churn one block at a time.
+
+**Where.** Append the archived blocks to `.tasks/archive/YYYY-MM.md` — one file per calendar month, keyed by the date of archival. Create `.tasks/archive/` and the month file if absent. If the month file already exists, **append**; never overwrite.
+
+**Archive file format** (header written once, on file creation):
+
+```markdown
+# Archived done tasks — YYYY-MM
+
+Moved out of `.tasks/STATUS.md` to keep the active board lean.
+Full source is git history; this file is for grep-able historical context.
+
+---
+```
+
+…followed by each 🟢 block **verbatim** (including its trailing `---` separator and any `<!-- closed-by … -->` comments).
+
+**After archiving,** `STATUS.md` keeps only 🔴 / 🟡 / ⚪ / 🔵 blocks. Commit the move on its own:
+
+```
+git add .tasks/ && git commit -m "meta(tasks): archive done batch → .tasks/archive/YYYY-MM.md"
+```
+
+Leave a just-closed 🟢 block on the board only while it's still useful at a glance (pending merge, fresh reference). Everything older goes to the archive.
 
 ### Post-commit task closure prompt
 
@@ -163,6 +237,7 @@ Pair: `using-projects-meta` declares local-first for **reads**; this rule extend
 
 ## Rules
 
+- **Honour `.tasks/.lock`** — read the lock at session start before touching the board; write it after clearing the guard; delete it at session end/pause. Never skip the lock check when `.tasks/` exists. The lock file must be gitignored.
 - **Never lose "Where I stopped"** — most critical field. If unclear, ask before ending session.
 - **One sentence per STATUS.md field** — compress, don't write prose.
 - **Key files must be specific** — not "auth module" but `packages/auth/src/useAuth.ts:87`.
@@ -170,5 +245,7 @@ Pair: `using-projects-meta` declares local-first for **reads**; this rule extend
 - **Commit after every session end** — git log is the history of thinking.
 - **Always confirm orientation at session start** — state understanding before acting.
 - **One active task at a time** — only one 🔴 in STATUS.md.
+- **Keep the board lean** — orientation reads the local `STATUS.md` whole, so archive 🟢 done blocks to `.tasks/archive/YYYY-MM.md` once ≥10 pile up. Never enumerate the current project's board via `tasks_aggregate` (cross-project cache) or `tasks_get_status` (single-task, by slug). See "### Archiving done tasks".
 - **Never close a task without a coverage check** — see "### Task completion" step 1. Acceptance criteria with no evidence → ask, don't auto-close.
+- **Honour `session_break`** — a closed task carrying a `session_break` marker means stop after close; never chain into `tasks_claim_next`. See "### Task completion" step 6.
 - **Local-first recommendations** — cwd-project board comes first; cross-project urgents are at most one footnote line.

skills/using-wiki-graph/SKILL.md

@@ -0,0 +1,54 @@
+---
+name: using-wiki-graph
+version: 0.1.0
+description: "Use when a question is RELATIONAL about a wiki — «что связывает X и Y», «как связаны X и Y», «путь между X и Y», «через что X выходит на Y», «what connects X and Y», «how is X related to Y», «shortest path between pages» — or about wiki STRUCTURE/HEALTH — «что ссылается на X», «кто линкует X», «соседи страницы X», «сироты в вики», «битые/dangling ссылки», «сколько связных компонент», «backlinks of X», «orphan pages». Triggers the `wiki-graph` MCP server (`mcp__wiki-graph__path|neighbors|backlinks|orphans|stats`), which runs a deterministic BFS over `[[wikilinks]]` server-side. The failure-mode this guards: on a relational question the agent does a semantic read of one page and STOPS, never walking the multi-hop link chain (0% recall on such queries vs 67% for graph BFS). Precondition: only DENSE corpora (e.g. modulair-wiki, 150 linked pages) — skip on sparse wikis (the shared meta-wiki has ~1 link total, graph is empty). Each tool needs `corpus` = absolute path to the `.wiki/` dir. Read-only, no grant needed. Skip for content/semantic questions answerable by reading a single page, and for wikis with no `[[links]]`."
+---
+
+# using-wiki-graph
+
+Stop and call the graph. On a **relational** or **structural** wiki question, do not answer from reading one page — the links form a graph the LLM does not traverse reliably by reading. The `wiki-graph` MCP server walks `[[wikilinks]]` deterministically and returns the answer in a few lines; the corpus never enters context.
+
+## When to use
+
+Trigger when the question is about **connections between pages** or **wiki structure**, not about the content of a single page:
+
+- relational — "what connects X and Y", "how are X and Y related", "path between X and Y", «что связывает», «как связаны», «путь между»;
+- neighbourhood — "neighbours of X", "what does X reach in 2 hops", «соседи X», «что рядом с X»;
+- incoming — "what links to X", "who references X", «кто ссылается на X», «backlinks»;
+- health — "orphan pages", "dangling/broken links", "how many components", «сироты», «битые ссылки», «здоровье вики».
+
+## Precondition — dense corpus only
+
+The graph is useful only when the wiki is actually linked. modulair-wiki (~150 linked pages, ~715 edges) — **yes**. The shared meta-wiki (`~/projects/.wiki/`, ~1 link total) — **no**, the graph is empty; answer by reading instead. If unsure, run `stats` first: near-zero `edges` ⇒ fall back to reading.
+
+## Inputs
+
+- `corpus` — **absolute** path to the wiki's `.wiki/` directory (e.g. `C:/Users/vitya/projects/modulair-wiki/.wiki`). Every tool requires it. Provenance dirs (`raw/`, `sources/`, `assets/`) are excluded automatically; the graph is the canonical concept/entity network.
+- page references are **slugs** (the `.md` basename, kebab-case), case-insensitive — e.g. `euclidean-rhythms`, not a title or path.
+
+## Steps
+
+1. Pick the tool from the question shape:
+   - relational / "what connects" → `mcp__wiki-graph__path` (`from`, `to`) — shortest undirected chain.
+   - neighbourhood → `mcp__wiki-graph__neighbors` (`node`, `depth` default 1) — outgoing within N hops.
+   - "who links to" → `mcp__wiki-graph__backlinks` (`node`) — incoming references.
+   - health → `mcp__wiki-graph__orphans` (unlinked pages + dangling targets) or `mcp__wiki-graph__stats` (counts).
+2. Pass `corpus` + the slugs. Report the returned chain/list directly; don't re-derive it by reading pages.
+3. Empty `path` result = genuinely no link chain — say so, don't invent one from prose proximity.
+
+## Failure modes
+
+- Slug typo / page not under a canonical dir → `path` returns empty or the node is unknown. Verify the slug is a real `.md` basename.
+- Sparse corpus → empty/near-empty graph. Don't force it; read instead (see Precondition).
+- `wiki-graph` server not registered → tools absent in session. Then read manually and note the server needs registering in `~/.claude.json`.
+
+## Side effects
+
+None. Read-only; parses files server-side. No writes, no grant, no network.
+
+## What NOT to do
+
+- Don't answer a relational question from a single-page read — that's the exact 0%-recall failure this skill exists to prevent.
+- Don't paste the whole wiki into context to "trace" links by hand — the server does it at zero token cost.
+- Don't invoke on dense-content questions ("what is euclidean-rhythms about") — that's a read, not a graph walk.
+- Don't pass titles or relative paths — only absolute `corpus` + basename slugs.

skills/using-yt-tools/SKILL.md

@@ -1,182 +1,59 @@
 ---
 name: using-yt-tools
-version: 0.3.2
-description: Three flows for YouTube content. **Iterative-watch** (summary/exploration): transcript with [mm:ss] anchors → pick moments → extract frames. **Targeted-frames** (specific timestamps): extract frames directly, no transcript. **Audio-analysis** (music FFT): per timestamp spectrogram + numeric digest (BPM, key, chord progression, harmonic content) via `yt-listen`. Triggers: "что в ролике", "о чём видео", "video summary", "youtube transcript", "покажи кадр на N", "послушай момент N", "BPM/тональность видео", "спектрограмма", "listen to fragment", "analyze audio", или любой youtube.com URL. CLI в `~/projects/.common/lib/yt-tools/`. YouTube-only; для Vimeo/Twitch/local — другие тулзы.
+version: 0.4.1
+description: DEPRECATED — this skill has migrated to the `OpeItcLoc03/yt-tools` Claude Code plugin (canonical source). To restore yt-tools functionality, install the plugin via `/plugin marketplace add OpeItcLoc03/claude-plugins` followed by `/plugin install yt-tools@opeitcloc03-claude-plugins`. The plugin's bundled SessionStart hook auto-runs `pipx install --force "$CLAUDE_PLUGIN_ROOT[full]"` (from the plugin's local clone, fallback to core), and its bundled skill (full English, mixed RU/EN triggers) takes over from this stub. Once the plugin is installed, this `claude-skills/skills/using-yt-tools/` directory becomes redundant and can be deleted. This stub intentionally declares **no trigger phrases** to avoid double-activation with the plugin's skill — it remains inert until invoked by name.
 ---
 
-# using-yt-tools
+# using-yt-tools — deprecated stub
 
-Iterative-watching YouTube для агента: clean-markdown транскрипт с `[mm:ss]`-якорями → агент решает, какие моменты интересны → targeted frame extraction по таймкодам → агент видит кадры через `Read`. Альтернативный flow — если юзер уже назвал таймкоды, идём прямо за кадрами без транскрипта. Для музыкальных URL — третий flow с FFT-анализом (BPM, key, chord progression, спектр) через `yt-listen`.
+This skill has migrated to the **`OpeItcLoc03/yt-tools` Claude Code plugin**.
+It is no longer maintained in the `claude-skills` repository — all future
+changes (CLI flag updates, new flows, bug fixes, version bumps) ship with
+the plugin distribution.
 
-## When to use
+## Why the move
 
-Три различных flow, выбор по user intent:
+Bundling the skill into a self-contained plugin (Python CLI + skill + hooks
++ LICENSE in one repo) lets one user-action install everything: the
+plugin's `SessionStart` hook auto-runs
+`pipx install --force "$CLAUDE_PLUGIN_ROOT[full]"` (from the plugin's local
+clone, not PyPI) and probes `ffmpeg`, and the bundled skill activates the
+same three flows
+(iterative-watch / targeted-frames / audio-analysis) without any separate
+`claude-skills` install step. See the design rationale in
+`OpeItcLoc03/common/.wiki/concepts/yt-tools-distribution.md`.
 
-**Flow A — iterative-watch** (exploration / summary):
-- Юзер спрашивает что в ролике, хочет summary, хочет узнать о чём видео.
-- Шаги: fetch transcript → read → pick interesting moments → extract those frames → Read frames.
-- Trigger phrases: «что в этом ролике», «о чём ролик», «расшифровка YouTube», «video summary», «youtube transcript», «watch this video».
+## How to install the replacement
 
-**Flow B — targeted-frames** (specific moments):
-- Юзер уже назвал конкретные таймкоды; транскрипт — лишняя работа.
-- Шаги: extract frames at given timestamps → Read frames.
-- Trigger phrases: «покажи кадр на N», «посмотри момент N», «что показано на N», «show frame at N».
-
-**Flow C — audio-analysis** (music FFT):
-- Юзер просит музыкальный разбор: BPM, тональность, гармония, chord progression, спектр, harmonic content.
-- Шаги: `yt-listen URL --timestamps T1,T2,...` → per timestamp 3 артефакта (`clip.wav` + `spectrum.png` + `features.md`) → Read **обоих** (PNG vision + .md числа).
-- Trigger phrases: «послушай момент N в <URL>», «какой BPM», «тональность видео», «гармония», «спектрограмма», «что в музыке на T», «listen to fragment», «analyze audio».
-- Если есть captions — `yt-transcript` опциональный (контекст), но НЕ для lyrics-из-music (см. What NOT to do).
-
-Все три flow предполагают, что `yt-tools` CLI установлен из `~/projects/.common/lib/yt-tools/` (project-local venv). Бинари могут не быть на PATH текущей сессии — это норма, особенно после свежего `winget install`. **Никогда не abort'ить по голому `Get-Command yt-frames` / `which yt-frames`** — сначала прогнать резолв (см. Prerequisites → Locating binaries).
-
-## Prerequisites
-
-### Locating binaries
-
-Скил ничего не предполагает про активный PATH. **Step 0 каждого flow** — резолв путей для `yt-frames`/`yt-transcript` и `ffmpeg` (+ `yt-dlp`, поставляется в том же venv). Если резолвится через fallback — используй PATH-prepend в каждом вызове (см. Invoke pattern ниже). Abort'ить **только** если бинаря нет ни на PATH, ни в известных install-локациях.
-
-**yt-tools CLI** (любая из локаций даёт все пять: `yt-frames`, `yt-transcript`, `yt-listen`, `yt-watch`, `yt-tools` + бонусом `yt-dlp`):
-
-1. **PATH**: `Get-Command yt-frames` (pwsh) / `command -v yt-frames` (bash). Для Flow C — probe также `yt-listen` (присутствует с pyproject 0.2.0+; если только `yt-frames` находится, а `yt-listen` нет — машина на старом 0.1.x, нужен `pipx reinstall yt-tools` / pull + reinstall).
-2. **pipx-shim** (recommended install — см. install-hint ниже):
-   - Windows: `~/.local/bin/yt-frames.exe` (+ `yt-listen.exe`)
-   - Linux/macOS: `~/.local/bin/yt-frames` (+ `yt-listen`)
-3. **Legacy project-venv** (для машин до миграции на pipx):
-   - Windows: `~/projects/.common/lib/yt-tools/.venv/Scripts/yt-frames.exe`
-   - Linux/macOS: `~/projects/.common/lib/yt-tools/.venv/bin/yt-frames`
-4. **Если ни одна локация не сработала** — install hint, потом стоп. **НЕ воссоздавай старый venv** даже если пустой `.venv/` отсутствует — это означает машина либо на pipx (probe #2 должен был сработать; если нет — у юзера `pipx ensurepath` не пройден, скажи запустить), либо вообще без yt-tools (свежая инсталляция per README):
+```text
+/plugin marketplace add OpeItcLoc03/claude-plugins
+/plugin install yt-tools@opeitcloc03-claude-plugins
 ```
-   python -m pip install --user pipx
-   python -m pipx ensurepath              # one-time; restart shell after
-   python -m pipx install --editable ~/projects/.common/lib/yt-tools
-   ```
-   Полный README — `~/projects/.common/lib/yt-tools/README.md`.
 
-**ffmpeg**:
+The first session after install will run the plugin's `SessionStart` hook
+to install yt-tools from the plugin's local clone (via
+`pipx install --force "$CLAUDE_PLUGIN_ROOT[full]"`, falling back to core
+if the `[full]` extras fail) and probe `ffmpeg`. From there the plugin's
+bundled skill (canonical English version, mixed RU/EN triggers) takes
+over.
 
-1. PATH: `Get-Command ffmpeg` / `command -v ffmpeg`
-2. Windows winget cache (версия плавающая, глобь):
-   `~/AppData/Local/Microsoft/WinGet/Packages/Gyan.FFmpeg_Microsoft.Winget.Source_*/ffmpeg-*-full_build/bin/ffmpeg.exe`
-3. macOS Homebrew: `/opt/homebrew/bin/ffmpeg` (Apple Silicon) или `/usr/local/bin/ffmpeg` (Intel)
-4. Linux: `/usr/bin/ffmpeg` (apt) или `/usr/local/bin/ffmpeg`
-5. Если ни одна локация — install hint per-ОС (`winget install Gyan.FFmpeg` / `brew install ffmpeg` / `apt install ffmpeg`); стоп. **Не** проси юзера restart'ить CC — продолжай резолв-логику в той же сессии после установки, либо подскажи, что новой сессии PATH подхватится сам.
+## What to do with this stub
 
-### Invoke pattern
-
-`yt-frames` сам спавнит `yt-dlp` и `ffmpeg` через `subprocess.run([..., "ffmpeg", ...])` — full-path к самому `yt-frames.exe` **не хватит**, нужен PATH-prepend, чтобы child процессы тоже их видели.
-
-`$YTBIN` подставляй той локацией, где нашёл `yt-frames` на шаге probe (`~/.local/bin/` если pipx-shim, или `.venv/Scripts/`|`/bin/` если legacy venv).
+After `/plugin install yt-tools@opeitcloc03-claude-plugins` reports
+success on your machine — delete this directory:
 
 ```bash
-# bash / git-bash — после резолва через fallback
-FFDIR=$(dirname "$(ls ~/AppData/Local/Microsoft/WinGet/Packages/Gyan.FFmpeg_*/ffmpeg-*-full_build/bin/ffmpeg.exe 2>/dev/null | head -1)")
-YTBIN=~/.local/bin                       # pipx-shim (recommended); legacy: ~/projects/.common/lib/yt-tools/.venv/{Scripts,bin}
-PATH="$FFDIR:$YTBIN:$PATH" yt-frames <url> --timestamps 1:23,4:56
+rm -rf ~/projects/claude-skills/skills/using-yt-tools/
 ```
 
-```powershell
-# pwsh — glob по плавающей версии ffmpeg
-$ff = (Get-ChildItem "$HOME\AppData\Local\Microsoft\WinGet\Packages\Gyan.FFmpeg_*\ffmpeg-*-full_build\bin\ffmpeg.exe" -ErrorAction SilentlyContinue | Select-Object -First 1).DirectoryName
-$ytbin = "$HOME\.local\bin"              # pipx-shim (recommended); legacy: "$HOME\projects\.common\lib\yt-tools\.venv\Scripts"
-$env:PATH = "$ff;$ytbin;" + $env:PATH
-yt-frames <url> --timestamps 1:23,4:56
-```
+This stub has no trigger phrases, so it remains inert and will not
+double-activate alongside the plugin's skill. It exists only as a sign
+post for anyone still looking for the old location.
 
-Если оба нашлись напрямую на PATH (`Get-Command` вернул что-то) — pre-pend не нужен, зови как обычно.
+## Source pointers
 
-## Inputs
-
-| Flow | Required | Optional |
-|---|---|---|
-| A — iterative-watch | YouTube URL или bare 11-char video id | `--lang ru,en` для non-English subs; `--out PATH` |
-| B — targeted-frames | YouTube URL + timestamps (`mm:ss`, `h:mm:ss`, или bare seconds: `123` → 2:03) | `--no-cache-source` (stream вместо кеша source.mp4); `--out DIR` |
-| C — audio-analysis | YouTube URL + timestamps (как у B) | `--duration 30s` (default 30s, lower bound для beat-tracking); `--mode interval --interval 60s` (bulk sampling); `--no-wav` / `--no-spectrogram` (default ON); `--linear` (STFT вместо mel); `--chroma` (bonus chromagram PNG); `--sample-rate 22050`; `--no-cache-source`; `--out DIR` |
-
-Все три flow пишут в `<cwd>/yt-cache/<video-id>/` по умолчанию (Flow C — в `audio/` поддиректорию).
-
-## Steps
-
-### Flow A — iterative-watch
-
-```
-0. Резолв yt-frames + ffmpeg per Prerequisites → Locating binaries; собрать PATH-prepend если резолв через fallback
-1. yt-transcript <url>                        → ./yt-cache/<vid>/transcript.md
-2. Read transcript.md, find [mm:ss] anchors that match the question
-3. yt-frames <url> --timestamps 1:23,4:56,…   → ./yt-cache/<vid>/frames/frame_*.jpg
-4. Read each frame_*.jpg via the vision tool
-5. Answer the user, citing both transcript paragraph and frame contents
-```
-
-**Stdout contract per CLI** (бери последнюю строку, формат зависит от CLI):
-
-- `yt-transcript`, `yt-watch` — одна строка на stdout: bare absolute path артефакта (`<abs>/transcript.md` или `<abs>/watch.md`).
-- `yt-frames` — **N строк** формата `Wrote: <abs path>`, одна на каждый извлечённый кадр. Strip префикс `"Wrote: "` чтобы получить путь. Дизайн осознан: per-line output чтобы caller'ы пайпили / скрейпили без парсинга summary в конце.
-
-Warnings и errors уходят в stderr (`warning: …`, `error: …`); stdout остаётся машинно-парсимым.
-
-### Flow B — targeted-frames
-
-```
-0. Резолв yt-frames + ffmpeg per Prerequisites → Locating binaries; собрать PATH-prepend если резолв через fallback
-1. Parse user's timestamps (mm:ss / h:mm:ss / bare seconds — все работают)
-2. yt-frames <url> --timestamps 1:23,4:56,…   → ./yt-cache/<vid>/frames/frame_*.jpg
-3. Read each frame_*.jpg
-4. Answer the user, referencing each frame by its [mm:ss] label
-```
-
-Без transcript fetch. Если потом юзер спросит «что говорилось в тот момент?», переключайся на Flow A на том же URL — `source.mp4` cache переиспользуется, повторного download нет.
-
-### Flow C — audio-analysis
-
-```
-0. Резолв yt-listen + ffmpeg per Prerequisites → Locating binaries; собрать PATH-prepend если резолв через fallback
-1. Parse timestamps (mm:ss / h:mm:ss / bare seconds — как у Flow B)
-2. yt-listen <url> --timestamps T1,T2,...    → ./yt-cache/<vid>/audio/{clip,spectrum,features}_TTTT.{wav,png,md}
-3. Read **обоих** per timestamp: features_TTTT.md (числа — BPM, key, chord progression, spectral features, peak frequencies, harmonic/percussive split) + spectrum_TTTT.png (vision)
-4. Reasoning по BPM/key/chord/spectral. Цитируй конкретные числа из features.md; spectrum-PNG — supplementary signal, не основной (см. What NOT to do)
-```
-
-Stdout-контракт `yt-listen` — одна строка `Wrote: <abs path>` per artifact (3 на каждый таймкод: wav, png, md), как у `yt-frames`.
-
-`source.mp4` cache переиспользуется между Flow A/B/C на одном URL — никаких повторных downloads. Default duration 30s (lower bound для beat-tracking); `--duration` override доступен. Для bulk-sampling музыкального ролика — `--mode interval --interval 60s` вместо явных таймкодов.
-
-## Failure modes
-
-Все failures abort cleanly; никогда не оставляй наполовину готовое состояние.
-
-| Symptom | Cause | Action |
-|---|---|---|
-| `yt-transcript` / `yt-frames` not on PATH | Не yt-tools отсутствуют, а PATH сессии не подхватил pipx-shim dir или venv не активен | Прогнать **всю** probe-цепочку (PATH → `~/.local/bin/` → legacy venv). Abort и install-hint **только** если ни одна локация ничего не дала. **НЕ воссоздавай venv по install-hint, если pipx-shim есть** — это означает PATH-проблема, а не отсутствие пакета (см. What NOT to do) |
-| `yt-dlp not found on PATH` (от child процесса) | `yt-dlp` есть в той же install-локации, что и `yt-frames`, но PATH-prepend не собран | Пересобери PATH-prepend (Prerequisites → Invoke pattern) — `$YTBIN` указать на ту же папку где нашёлся `yt-frames` |
-| `ffmpeg not found on PATH` (от child процесса) | ffmpeg установлен, но в winget-кэше/Homebrew/etc., не на PATH сессии | Прогнать ffmpeg-резолв per Prerequisites, prepend в PATH. Abort только если ни одна локация не нашла бинаря — install per ОС. **Не** требовать restart CC session — резолв решает |
-| `yt-dlp source download failed (exit N) \| stderr: …` | Network / private / age-gated / region-locked / malformed URL | Выведи captured stderr verbatim; не retry |
-| `yt-dlp --dump-json failed` | То же, но на metadata step | То же |
-| `Subtitles disabled` от `youtube-transcript-api` | Канал отключил CC | Для Flow A это fatal — скажи юзеру, предложи Flow B с явными таймкодами если уместно |
-| Юзер дал не-YouTube URL (Vimeo / Twitch / local mp4) | Out of scope | Стоп; скажи что скил YouTube-only |
-
-## Side effects
-
-- Writes под `<cwd>/yt-cache/<video-id>/`:
-  - `transcript.md` (Flow A)
-  - `source.mp4` (≤720p, оба flow если без `--no-cache-source`)
-  - `frames/frame_<mmss>.jpg` per extracted frame
-- Network: yt-dlp вытягивает metadata + опционально source.mp4; `youtube-transcript-api` вытягивает subs
-- Никакого внешнего state не мутируется — чисто local-fs side effects
-- `source.mp4` может быть ~50-200 MB на 720p / 10-минутный ролик; кеш переиспользуется между запусками. **Warning:** cumulative — 20 роликов = 1-4 GB на диске.
-
-Cache hygiene: `yt-tools cache list` показывает usage, `yt-tools cache prune --older-than 7d` чистит.
-
-## What NOT to do
-
-- **Не воссоздавай удалённый venv по install-hint.** Если `~/projects/.common/lib/yt-tools/.venv/` не существует — **сначала** проверь `~/.local/bin/yt-frames.exe` (pipx-shim). Пустой `.venv/` ≠ «yt-tools не установлен»: машина могла мигрировать на pipx и старый venv осознанно снести. Install-hint в скиле — для **полностью свежей** машины (без pipx, без venv). Воссоздание venv поверх работающего pipx-инсталла — destructive cleanup paradox (тратит ~200MB+ и создаёт две параллельные инсталляции). Если pipx-shim существует, но `Get-Command yt-frames` пуст — нужен `pipx ensurepath` + restart shell, не новый venv.
-- **Не запускай Flow A когда юзер уже дал таймкоды.** «Посмотри 1:23 и 4:56» → сразу Flow B. Fetching transcript first — чистая трата.
-- **Не bulk-extract «на всякий случай».** Flow A берёт кадры из транскрипта, Flow B — из явного user input. Никогда `--mode interval --interval 5s` «to be safe».
-- **Не используй `yt-watch` как default Flow A renderer.** `yt-watch` комбинирует transcript + scene-frames в один doc — тяжелее (требует ffmpeg scene-detect pass на source.mp4). Бери только когда юзер хочет один self-contained document.
-- **Не shell-quote URLs в одну command строку.** Используй CLI list-form (он уже list-form в `subprocess.run`); YouTube URLs содержат `?` и `&`, которые ломают naive quoting.
-- **Не retry на yt-dlp failures.** Failure здесь значит видео реально недоступно (private / region / age) или у юзера broken auth. Retries — трата токенов.
-- **Не пересказывай / не переводи transcript в свой ответ молча.** Артефакт — для твоего reasoning; цитируй с `[mm:ss]`-якорем когда приводишь пассаж.
-- **Не вызывай скил на non-YouTube URL.** Vimeo / Twitch / TikTok / local mp4 — out of scope. Бери другие тулзы (или yt-dlp напрямую).
-- **Не пиши результаты в произвольные пути.** По умолчанию `<cwd>/yt-cache/<vid>/`; явный `--out` только если юзер просил.
-- **Не вызывай Whisper на смешанной музыке.** Юзер просит lyrics из музыкального ролика → это **не** `yt-listen`. Whisper на mixed music без source-separation = мусор (подтверждено arXiv 2506.15514). Скажи юзеру, что lyrics из music — отдельный pipeline (Demucs/Spleeter source-separation + Whisper поверх isolated vocals), out of scope текущего `yt-tools`. Не пытайся подсунуть `yt-transcript` как замену — YouTube auto-subs для музыки обычно нет, и `yt-listen` НЕ имеет Whisper-флага даже опционально.
-- **Не интерпретируй `spectrum_*.png` без `features_*.md` в паре.** VLM-сигнал на audio спектрограммах ограничен (~50-60% accuracy на ESC-10, vs 72.5% human; Dixit et al. arXiv 2411.12058). Числовой digest из features.md — primary канал; spectrum-PNG — supplementary visual cue. Когда читаешь PNG — всегда читай и .md того же таймкода; цитируй BPM/key/chord/spectral из текстовых полей, не из «как выглядит картинка».
+- Plugin repository: <https://github.com/OpeItcLoc03/yt-tools>
+- Marketplace catalog: <https://github.com/OpeItcLoc03/claude-plugins>
+- Bundled canonical SKILL: `skills/using-yt-tools/SKILL.md` in the plugin repo
+- PyPI: <https://pypi.org/project/yt-tools/> (deferred post-v1; not yet published)
+- Design rationale: `OpeItcLoc03/common/.wiki/concepts/yt-tools-distribution.md`