git_admin/obsidian-vault
1
0 Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

[2026-10-18] eagle: personal/projects/personal-os/personal-os-action-plan-2026-10-05.md personal/projects/personal-os/personal-os-system-review-index.md

Browse Source
This commit is contained in:
Alexey Martemyanov committed 2026-10-18 18:55:56 +06:00
1 parent e7137a5555
commit b6ae658694
2 files changed
+64 -60
Download Patch File Download Diff File Expand all files Collapse all files

No files matched your search

personal/projects/personal-os/personal-os-action-plan-2026-10-05.md
+63 -59
View File
@@ -2,17 +2,17 @@
## Рабочий план 18.10.2026: оценка модели и три прикладных процесса
Статус: план реализации по запросу Алекса от 18.10.2026. Этот раздел задаёт ближайшие работы вместо общих формулировок E2–E5 ниже. Новые имена обработчиков, таблиц и параметры далее — предлагаемые контракты, а не существующий runtime. Изменение документа не включает расписаний или ИИ-исполнения.
Статус: план реализации по запросу Алекса от 18.10.2026. Этот раздел задаёт ближайшие работы вместо общих формулировок E2–E5 ниже. **Формат планов и ответов — без таблиц. Обязательное ограничение: оркестрация — Windmill; новые шаги — Python и SQL. Новых JS/TypeScript-обработчиков, Node-сервисов и отдельного оркестратора не создавать.** Имена обработчиков ниже обозначают Python/SQL-шаги соответствующих Windmill flows. Новые таблицы и параметры — предлагаемые контракты. Изменение документа не включает расписаний или ИИ-исполнения.
### A. Общий data flow и управляющий процесс
### A. Общий data flow и оркестрация в Windmill
```text
Asana / GitHub / Mattermost / Zoom / заметки
→ versioned source records
→ проверка извлечения + нормализация предметов, действий, участников и времени
→ work_facts + work_actions + work_relations + work_search_index
→ work_director получает source_changed / action_changed / run_changed /
calendar_changed / focus_changed / user_changed / timer
→ Windmill flows получают changed work/action/run IDs и версии входов;
Windmill schedules запускают дневные, недельные и минутные проверки
├─ week_planner → weekly_plan → day_planner → human_queue + ai_run_specs
├─ day_observer → observed_intervals → signal_policy → local_signal_inbox
└─ career_matcher → contribution_ledger + career_opportunities
@@ -21,7 +21,18 @@ Asana / GitHub / Mattermost / Zoom / заметки
Единица планирования — конкретное действие, единица ИИ-исполнения — run с проверяемым результатом, единица наблюдения — временной интервал, единица карьерного анализа — вклад/возможность, связанная с актуальной целью. `work_id` связывает их с корневой работой; `task_gid`, `action_id`, `run_id` сохраняют конкретный объект.
**Управляющий процесс `work_director`** — proposed wrapper для planned `f/attend/roles_importance_e4` и `f/attend/attention_loop_e5`. Один durable dispatcher читает события с cursor/lease; heartbeat 60 с обслуживает таймеры и восстановление. Повтор события определяется по `(kind, object_id, source_revision, policy_version)`; пересчёт затрагивает только зависимые работы. Collector Asana и claim updater сохраняют своих владельцев; директор не дублирует их опрос.
**Управление выполняют Windmill flows и schedules.** Изменившийся work ID передаётся следующему flow выходом предыдущего шага; parent flow связывает нормализацию, действия и пересчёт. Windmill jobs сохраняют статусы, очередность, retries и результаты; SQL-ограничение `(kind, object_id, source_revision, policy_version)` обеспечивает идемпотентность предметной обработки. Одноминутное расписание относится к flow наблюдения дня, а не к отдельному dispatcher. Collector Asana и claim updater сохраняют своих владельцев.
- **`f/analyse/corpus_and_gold_e2`**. Шаги реализации: SQL-выборка + Python-проверки/разметка/метрики. Запуск → результат: Ручной audit и проверка новой версии метода → evaluation artifacts.
- **`f/analyse/work_context`**. Шаги реализации: SQL current records → Python resolve/index/actor steps → SQL upsert. Запуск → результат: После source/claim revision → facts, relations, index.
- **`f/analyse/work_actions`**. Шаги реализации: SQL facts/requests → Python decomposition/validation → SQL action DAG. Запуск → результат: После work context → конкретные human/AI actions.
- **`f/attend/week_plan`**. Шаги реализации: SQL ready actions → Python budget/order → SQL versioned plan. Запуск → результат: Первый рабочий старт недели и принятые существенные изменения → недельный план.
- **`f/attend/attention_loop_e5`**. Шаги реализации: SQL day state/actions → Python day plan/observe/signal policy → SQL inbox. Запуск → результат: Старт дня; наблюдение раз в 60 с; run/action changes → дневной план и сигналы.
- **`f/execute/workflow_run`**. Шаги реализации: SQL read accepted spec → Python handler → SQL events/artifacts. Запуск → результат: Только допущенный run spec → результат и waiting_review/action event.
- **`f/attend/roles_importance_e4`**. Шаги реализации: SQL profile/contributions/open works → Python match/check → SQL opportunities. Запуск → результат: Profile/contribution change и перед week plan → вклад и карьерные кандидаты.
Это целевые flows плана. Реализация новых шагов — Python/SQL внутри Windmill; в flow предусмотрены ограничение параллелизма, retries и таймаут. Общий локальный model lock сохраняется для inference. Доступ к Mac-local ActivityWatch/артефактам задаётся входным ресурсом конкретного Python-шага; отдельный JS runner этим планом не вводится.
Состояния дня: `off`, `available`, `focus`, `meeting`, `break`. При старте рабочей недели строится week plan, при старте дня — day plan. Изменения источников объединяются по работе за 60 с и обновляют кандидатов; во время focus новый обычный план публикуется как предложение на границе блока. Явная правка пользователя применяется сразу. Новые ИИ-runs и обычные сигналы выдаются только внутри рабочего интервала. Уже работающий run может завершиться и сохранить результат; его review поступает в ближайшее рабочее окно.
@@ -42,12 +53,11 @@ Asana / GitHub / Mattermost / Zoom / заметки
5. Сначала сохранить ожидаемые объекты, решения/отмены, роли, даты и существенные пропуски из оригиналов; затем сопоставить с ответом. Для задач поиска составить 40 контрольных запросов и ожидаемые связанные материалы. Факты могут иметь `supported`, `contradicted`, `insufficient_source`; недостающий факт в доступном входе учитывается как пропуск.
6. Итоговые артефакты в локальном приватном evaluation-каталоге: `audit_manifest.json`, `checks.jsonl`, `gold.jsonl`, `split.json`, `error_patterns.json`, `holdout_metrics.json`. Каждый вердикт содержит work/run/claim ID, версию входа, цитату, объяснение, evaluator и policy version. Неоднозначность сохраняется как unresolved; независимую оценку той же моделью не подменять её самооценкой.
| Прикладной допуск | Начальный критерий для holdout | Что показывается в результате |
|---|---|---|
| Извлечение утверждений | precision ≥95%, recall существенных фактов ≥90% | Числитель/знаменатель по классам, ошибки и интервалы неопределённости с группировкой по работам |
| Критические решения/attribution | 0 обнаруженных случаев «отмена = реализация» и «чужой вклад = вклад Алекса» | Конкретные regression cases; ноль на выборке не объявляется гарантией на весь корпус |
| Поиск контекста | recall@20 ≥90% на 40 запросах | Найденные/пропущенные материалы и выигрыш относительно поиска без модельных полей |
| Отказ при нехватке данных | `insufficient_source` с указанием пробела | Отдельная оценка; отказ не скрывает пропуск, если ответ был в доступном источнике |
- **Извлечение утверждений**. Начальный критерий для holdout: precision ≥95%, recall существенных фактов ≥90%. Что показывается в результате: Числитель/знаменатель по классам, ошибки и интервалы неопределённости с группировкой по работам.
- **Критические решения/attribution**. Начальный критерий для holdout: 0 обнаруженных случаев «отмена = реализация» и «чужой вклад = вклад Алекса». Что показывается в результате: Конкретные regression cases; ноль на выборке не объявляется гарантией на весь корпус.
- **Поиск контекста**. Начальный критерий для holdout: recall@20 ≥90% на 40 запросах. Что показывается в результате: Найденные/пропущенные материалы и выигрыш относительно поиска без модельных полей.
- **Отказ при нехватке данных**. Начальный критерий для holdout: `insufficient_source` с указанием пробела. Что показывается в результате: Отдельная оценка; отказ не скрывает пропуск, если ответ был в доступном источнике.
Это предлагаемые пороги первого допуска. Польза и допуск оцениваются отдельно по полю и потребителю: полезный поисковый компонент не разрешает автоматически признавать ответственность или релиз. Основную разметку и разбор выполняет Codex; чтение Алекcом всего каталога не является этапом плана. Личные цели и выбор приоритетов отражаются отдельной явной пользовательской настройкой, а не объявляются фактом моделью.
@@ -55,17 +65,16 @@ Asana / GitHub / Mattermost / Zoom / заметки
### C. Куда идут существующие поля
| Поля schema v2 | Обработчик и конкретная операция | Выход/потребитель |
|---|---|---|
| `subject`, `components[]` | `index_work`: нормализовать aliases компонентов в IDs, построить FTS по предмету и проверенным statements | `work_search_index(work_id, component_ids, competency_ids, search_text tsvector, source_revision)` для поиска контекста и карьерных кандидатов |
| `claims[].state/statement/evidence` | `resolve_facts`: проверить основание, выделить `subject_key`, `scope/platform`, время действия и supersession; сопоставить отмену с тем же предметом | `work_facts` → допустимые решения/ограничения для action builder, краткого обзора и contribution ledger |
| `claims[].confirmed` | `audit_model`: сравнить самооценку с проверкой; посчитать ошибки уверенности | Диагностика метода; публикацию определяет verdict проверки |
| `timeline[].date/event/evidence` | `resolve_facts`: восстановить порядок по event time и источникам | История решений/участия; вход проверки актуальности, а не сортировка по времени загрузки |
| `people[].name/role`, `alex.mentioned/assignee/author` | `resolve_actor`: сопоставить с task/story/account IDs; отделить участие в конкретной подзадаче от корня | Подтверждённые actor/action relations |
| `alex.responsible/relevance/intersection_kind` | `resolve_responsibility`: проверить адресата и основание; значения none/awareness/review/dependency/commitment/owner/unknown различать | Кандидаты ролей → проверенные обязанности/консультации/контекст для E4 |
| `explicit_links[]` | `link_sources`: URL → object ID → чтение объекта → проверка отношения | `work_relations`; поиск сначала по точным связям |
| `unknowns[]` | `fetch_context`: создать адресную задачу дочитывания, максимум 3 попытки на вопрос и версию входа | Новый evidence packet либо видимый unresolved gap |
| `current_state` | `render_work`: заново собрать резюме из текущих разрешённых facts | Краткая карточка; archived summary остаётся сравнительным материалом |
- **`subject`, `components[]`**. Обработчик и конкретная операция: `index_work`: нормализовать aliases компонентов в IDs, построить FTS по предмету и проверенным statements. Выход/потребитель: `work_search_index(work_id, component_ids, competency_ids, search_text tsvector, source_revision)` для поиска контекста и карьерных кандидатов.
- **`claims[].state/statement/evidence`**. Обработчик и конкретная операция: `resolve_facts`: проверить основание, выделить `subject_key`, `scope/platform`, время действия и supersession; сопоставить отмену с тем же предметом. Выход/потребитель: `work_facts` → допустимые решения/ограничения для action builder, краткого обзора и contribution ledger.
- **`claims[].confirmed`**. Обработчик и конкретная операция: `audit_model`: сравнить самооценку с проверкой; посчитать ошибки уверенности. Выход/потребитель: Диагностика метода; публикацию определяет verdict проверки.
- **`timeline[].date/event/evidence`**. Обработчик и конкретная операция: `resolve_facts`: восстановить порядок по event time и источникам. Выход/потребитель: История решений/участия; вход проверки актуальности, а не сортировка по времени загрузки.
- **`people[].name/role`, `alex.mentioned/assignee/author`**. Обработчик и конкретная операция: `resolve_actor`: сопоставить с task/story/account IDs; отделить участие в конкретной подзадаче от корня. Выход/потребитель: Подтверждённые actor/action relations.
- **`alex.responsible/relevance/intersection_kind`**. Обработчик и конкретная операция: `resolve_responsibility`: проверить адресата и основание; значения none/awareness/review/dependency/commitment/owner/unknown различать. Выход/потребитель: Кандидаты ролей → проверенные обязанности/консультации/контекст для E4.
- **`explicit_links[]`**. Обработчик и конкретная операция: `link_sources`: URL → object ID → чтение объекта → проверка отношения. Выход/потребитель: `work_relations`; поиск сначала по точным связям.
- **`unknowns[]`**. Обработчик и конкретная операция: `fetch_context`: создать адресную задачу дочитывания, максимум 3 попытки на вопрос и версию входа. Выход/потребитель: Новый evidence packet либо видимый unresolved gap.
- **`current_state`**. Обработчик и конкретная операция: `render_work`: заново собрать резюме из текущих разрешённых facts. Выход/потребитель: Краткая карточка; archived summary остаётся сравнительным материалом.
`work_claim_entities` даёт текущие версии claims; архивный `result_json` даёт subject/components для первого индекса. При изменении источников индекс и резюме перестраиваются с новым source revision. Старые subject/components не маскируются как актуальные. Свободные `statement` и `alex`-JSON не являются прямым входом планировщика: следующий явный шаг — выделение действий и actor relations из оригиналов и проверенных фактов.
@@ -75,15 +84,14 @@ Asana / GitHub / Mattermost / Zoom / заметки
**Вход:** текущие открытые Asana tasks, адресные неразрешённые requests/reviews, PR situations, подтверждённые действия/зависимости, доступные окна, принятые личные priorities и career opportunities.
| Шаг/обработчик | Точный отбор и операция | Выход |
|---|---|---|
| `build_actions` после source/work revision | Взять `completed=false AND assignee=Alex`; добавить прямые адресные requests, requested review и run events `needs_human=true`. Сопоставить ответ именно с запросом/тредом и предметом: произвольный поздний комментарий не закрывает все запросы задачи | Дедуплицированные actions с основанием и конкретным ожидаемым результатом |
| `decompose_work` при новом действии/изменении scope | По оригиналу, разрешённым facts и acceptance разбить работу на DAG действий. Разделить human decision/review и AI-шаги. Назначить AI только шагу с существующим handler, входами, output contract и разрешёнными capabilities | Action DAG: кто делает каждый шаг и какие предыдущие результаты нужны |
| `compute_capacity` при calendar/day change | На каждый день объединить busy intervals, пересечь с рабочим временем и now..work_end; вычесть перерывы. Выделить 30% остатка как резерв. Планируемое human work + human review ≤70% остатка. AI wall time учитывается отдельно от человеческого времени | Доступные human windows и очереди compute/review |
| `week_planner` первый рабочий старт недели + существенная deadline/capacity change | `status=ready`, все `depends_on` выполнены; действия со сроком до конца недели, carried-over из прошлого плана, priority_pin; карьерные кандидаты в пределах discretionary budget. `blocked` видны отдельно, в исполнение идут их unblock actions | Weekly plan: до 3 основных результатов, actions, human/AI budget, резерв и основания порядка |
| `day_planner` work_start + изменение плана на границе focus/review window | Из weekly plan взять ready actions, помещающиеся в свободные окна и review budget; отдельно добавить срочные подтверждённые обязанности текущего дня | Day plan: 1 основное human action, до 2 резервных, окна review и список AI run drafts |
| `prepare_run` при готовности AI action | Построить run spec и recheck source/base SHA. Уникальность `(action_id, spec_hash)`. Запускать после принятой execution policy в пределах compute/review budget | `workflow_run` с проверяемым артефактом; human review — отдельное действие |
| `reconcile_plan` после run result / принятого review / изменения task | Проверить acceptance, обновить только соответствующий action и зависящий DAG, учесть фактическое время | Следующий ready шаг; завершение run само по себе не закрывает родительскую Asana task |
- **`build_actions` после source/work revision**. Точный отбор и операция: Взять `completed=false AND assignee=Alex`; добавить прямые адресные requests, requested review и run events `needs_human=true`. Сопоставить ответ именно с запросом/тредом и предметом: произвольный поздний комментарий не закрывает все запросы задачи. Выход: Дедуплицированные actions с основанием и конкретным ожидаемым результатом.
- **`decompose_work` при новом действии/изменении scope**. Точный отбор и операция: По оригиналу, разрешённым facts и acceptance разбить работу на DAG действий. Разделить human decision/review и AI-шаги. Назначить AI только шагу с существующим handler, входами, output contract и разрешёнными capabilities. Выход: Action DAG: кто делает каждый шаг и какие предыдущие результаты нужны.
- **`compute_capacity` при calendar/day change**. Точный отбор и операция: На каждый день объединить busy intervals, пересечь с рабочим временем и now..work_end; вычесть перерывы. Выделить 30% остатка как резерв. Планируемое human work + human review ≤70% остатка. AI wall time учитывается отдельно от человеческого времени. Выход: Доступные human windows и очереди compute/review.
- **`week_planner` первый рабочий старт недели + существенная deadline/capacity change**. Точный отбор и операция: `status=ready`, все `depends_on` выполнены; действия со сроком до конца недели, carried-over из прошлого плана, priority_pin; карьерные кандидаты в пределах discretionary budget. `blocked` видны отдельно, в исполнение идут их unblock actions. Выход: Weekly plan: до 3 основных результатов, actions, human/AI budget, резерв и основания порядка.
- **`day_planner` work_start + изменение плана на границе focus/review window**. Точный отбор и операция: Из weekly plan взять ready actions, помещающиеся в свободные окна и review budget; отдельно добавить срочные подтверждённые обязанности текущего дня. Выход: Day plan: 1 основное human action, до 2 резервных, окна review и список AI run drafts.
- **`prepare_run` при готовности AI action**. Точный отбор и операция: Построить run spec и recheck source/base SHA. Уникальность `(action_id, spec_hash)`. Запускать после принятой execution policy в пределах compute/review budget. Выход: `workflow_run` с проверяемым артефактом; human review — отдельное действие.
- **`reconcile_plan` после run result / принятого review / изменения task**. Точный отбор и операция: Проверить acceptance, обновить только соответствующий action и зависящий DAG, учесть фактическое время. Выход: Следующий ready шаг; завершение run само по себе не закрывает родительскую Asana task.
Предлагаемая очередность ready actions: ближайший жёсткий deadline/отрицательный slack → явный priority_pin → адресное обязательство/разблокирование коллег → source priority → career relevance внутри оставшегося класса. Карьерный вес не перемещает несрочную возможность выше обязательного срока. Если обязательства не помещаются, план сохраняет overflow с требуемым решением, а не увеличивает рабочий день.
@@ -121,14 +129,13 @@ ActivityWatch window/AFK/editor/browser + accepted worktree bindings + run event
`day_observer` читает локальные ActivityWatch данные, а не делает полный внешний sync каждую минуту. Browser task/PR ID, accepted worktree→work link и явный focus override связывают интервал с работой; неизвестный интервал сохраняется отдельно и не приписывается ближайшей задаче. Window/AFK старше 90 с прекращают положительную классификацию текущей работы. Продолжительность считается по объединению интервалов без двойного счёта; AFK и meetings учитываются отдельно от focus.
| Сигнал | Фильтр/порог первой версии | Когда доставлять | Для чего |
|---|---|---|---|
| `run_needs_review` | Подтверждённый run state `waiting_review`, `needs_human=true`, artifact существует | Ближайшее review window или конец focus блока | Открыть конкретный результат AI и продолжить DAG |
| `deadline_capacity_conflict` | Действие имеет подтверждённый deadline, а доступные окна до него меньше remaining human + review minutes | Однократно при обнаружении; показать конкретный конфликт | Перепланировать объём/очередность |
| `action_overrun` | Тот же action дольше `max(1.5 × planned_minutes, planned_minutes + 15)` | На границе блока, не повторять до изменения action | Предложить остановку, продолжение либо новый run расследования |
| `context_switching` | ≥5 переходов между известными work IDs за 15 мин; исключить AFK и meetings | В ближайшее окно обзора | Показать фактические переключения и предложить закрепить фокус |
| `break_due` | 50 мин непрерывной наблюдаемой активности без AFK ≥5 мин | В момент порога, мягкая локальная карточка | Напомнить о перерыве; это таймер активности, не вывод о здоровье/усталости |
| `day_end` | `now >= work_end`; один сигнал на дату | На границе рабочего дня | Сохранить незавершённое и ближайшее продолжение для следующего дня |
- **`run_needs_review`**. Фильтр/порог первой версии: Подтверждённый run state `waiting_review`, `needs_human=true`, artifact существует. Когда доставлять: Ближайшее review window или конец focus блока. Для чего: Открыть конкретный результат AI и продолжить DAG.
- **`deadline_capacity_conflict`**. Фильтр/порог первой версии: Действие имеет подтверждённый deadline, а доступные окна до него меньше remaining human + review minutes. Когда доставлять: Однократно при обнаружении; показать конкретный конфликт. Для чего: Перепланировать объём/очередность.
- **`action_overrun`**. Фильтр/порог первой версии: Тот же action дольше `max(1.5 × planned_minutes, planned_minutes + 15)`. Когда доставлять: На границе блока, не повторять до изменения action. Для чего: Предложить остановку, продолжение либо новый run расследования.
- **`context_switching`**. Фильтр/порог первой версии: ≥5 переходов между известными work IDs за 15 мин; исключить AFK и meetings. Когда доставлять: В ближайшее окно обзора. Для чего: Показать фактические переключения и предложить закрепить фокус.
- **`break_due`**. Фильтр/порог первой версии: 50 мин непрерывной наблюдаемой активности без AFK ≥5 мин. Когда доставлять: В момент порога, мягкая локальная карточка. Для чего: Напомнить о перерыве; это таймер активности, не вывод о здоровье/усталости.
- **`day_end`**. Фильтр/порог первой версии: `now >= work_end`; один сигнал на дату. Когда доставлять: На границе рабочего дня. Для чего: Сохранить незавершённое и ближайшее продолжение для следующего дня.
Параметры 90 с, 5/15 мин, 50 мин, 1.5×/+15 мин — proposed defaults для пятидневного пилота, не измеренные личные нормы. Focus/review/break boundaries фиксируются отдельным day state. Обычные action/run/context signals при focus ожидают его границы; day_end и наступление work boundaries обслуживаются таймером.
@@ -172,33 +179,30 @@ LIMIT 20;
### G. Что критически добавить: проверенный разрыв и ближайшая поставка
Read-only сверка 18.10: в основной БД есть `work_claim_*`, `work_update_*`, `work_demands`, `work_items`, `work_situations`, `day_state`, `focus_feedback`, `activity_daily`, старые executor tables. Контракты `work_actions`, актуальных plans, workflow run events, calendar, signal delivery и career profile/ledger выше — следующие добавочные части. Наличие старой executor-таблицы не доказывает выполнение нового run contract.
Read-only сверка 18.10: в основной БД есть `work_claim_*`, `work_update_*`, `work_demands`, `work_items`, `work_situations`, `day_state`, `focus_feedback`, `activity_daily`, старые executor tables. Контракты `work_actions`, актуальных plans, workflow run events, calendar, signal delivery и career profile/ledger выше — следующие добавочные части, реализуемые SQL-миграциями и Python/SQL-шагами Windmill. Наличие старой executor-таблицы не доказывает выполнение нового run contract.
- **Источник времени для week/day**. Что уже есть / где проверено: `source-snapshot.js`: calendar unknown; `capacity-model.js` принимает meetings/workEndAt. Минимальная поставка и проверка: Calendar adapter с полным горизонтом следующей недели, cancelled/overlap/updated_at; work_schedule + override. Union/clip meetings даёт воспроизводимые свободные окна.
- **Из текста работы в исполнимый шаг**. Что уже есть / где проверено: `work-demand.js`: assignment/request/dependency candidates; claims schema v2. Минимальная поставка и проверка: Action builder + нормализация предмета/времени/actor + acceptance + human/review estimates. На пяти реальных работах получается DAG с конкретным следующим шагом.
- **Разделение моей и AI-работы**. Что уже есть / где проверено: `agent-run-adapters.js` содержит normalizer; sessions metadata сохраняют state/needs_human unknown. Минимальная поставка и проверка: Registry и один реальный runner adapter: spec → run events → artifact → review action. Replay событий не создаёт двойной run/review.
- **Ограниченный план и пересчёт**. Что уже есть / где проверено: `day-coordinator.js`: shadow actions и capacity; полноценного week/action plan нет. Минимальная поставка и проверка: Week/day planner с budget, dependencies, overflow и версиями; изменение deadline/run/calendar пересчитывает затронутые actions.
- **Привязка наблюдения к работе**. Что уже есть / где проверено: `work-timeline.js` связывает редактор в основном через PR; accepted work_items уже есть. Минимальная поставка и проверка: Подключить accepted worktree→work/action, local 60-сек observer; проверить 20 интервалов по реальным URL/path/AFK, unknown остаётся отдельным.
- **Доставка сигнала и его жизнь**. Что уже есть / где проверено: `generate-attention.js` создаёт feed; `day-coordinator.js` пишет delivery none. Минимальная поставка и проверка: Signal inbox + local UI transport + dedupe/seen/snooze/resolved. Проверить run review, конфликт срока и day_end сквозным replay.
- **Карьерный профиль и возможности**. Что уже есть / где проверено: `agent/career-notes.md`: апрельские goals имеют оговорку о давности; Obsidian profile содержит отдельные факты. Минимальная поставка и проверка: Profile importer + active rubric/goals + ledger + top-3 opportunities со specific action/evidence. Новая opportunity присоединяется к week plan только через принятое решение.
- **Допуск смысловых полей**. Что уже есть / где проверено: Схема, локальный inference, архив, patch updater, ручной review API. Минимальная поставка и проверка: Audit всего архива + 60/40 оценка; решения по каждому классу, source/version lineage для projections.
| Разрыв из конкретного data flow | Что уже есть / где проверено | Минимальная поставка и проверка |
|---|---|---|
| Источник времени для week/day | `source-snapshot.js`: calendar unknown; `capacity-model.js` принимает meetings/workEndAt | Calendar adapter с полным горизонтом следующей недели, cancelled/overlap/updated_at; work_schedule + override. Union/clip meetings даёт воспроизводимые свободные окна |
| Из текста работы в исполнимый шаг | `work-demand.js`: assignment/request/dependency candidates; claims schema v2 | Action builder + нормализация предмета/времени/actor + acceptance + human/review estimates. На пяти реальных работах получается DAG с конкретным следующим шагом |
| Разделение моей и AI-работы | `agent-run-adapters.js` содержит normalizer; sessions metadata сохраняют state/needs_human unknown | Registry и один реальный runner adapter: spec → run events → artifact → review action. Replay событий не создаёт двойной run/review |
| Ограниченный план и пересчёт | `day-coordinator.js`: shadow actions и capacity; полноценного week/action plan нет | Week/day planner с budget, dependencies, overflow и версиями; изменение deadline/run/calendar пересчитывает затронутые actions |
| Привязка наблюдения к работе | `work-timeline.js` связывает редактор в основном через PR; accepted work_items уже есть | Подключить accepted worktree→work/action, local 60-сек observer; проверить 20 интервалов по реальным URL/path/AFK, unknown остаётся отдельным |
| Доставка сигнала и его жизнь | `generate-attention.js` создаёт feed; `day-coordinator.js` пишет delivery none | Signal inbox + local UI transport + dedupe/seen/snooze/resolved. Проверить run review, конфликт срока и day_end сквозным replay |
| Карьерный профиль и возможности | `agent/career-notes.md`: апрельские goals имеют оговорку о давности; Obsidian profile содержит отдельные факты | Profile importer + active rubric/goals + ledger + top-3 opportunities со specific action/evidence. Новая opportunity присоединяется к week plan только через принятое решение |
| Допуск смысловых полей | Схема, локальный inference, архив, patch updater, ручной review API | Audit всего архива + 60/40 оценка; решения по каждому классу, source/version lineage для projections |
### H. Порядок выполнения и критерии старта
| Пакет | Работа | Проверяемый результат |
|---|---|---|
| P0 | Зафиксировать входы; audit всего архива; начать 60/40; нормализовать пять реальных работ. Параллельно обследовать calendar и актуальные career sources | Error-pattern table + action DAGs + конкретный способ чтения busy intervals и profile/rubric inputs |
| P1 | Ввести общий event/action/source-version contract; calendar/work boundaries; read-only registry/run adapter | На одной работе: вход → action DAG → AI run draft → replay waiting_review → human action с артефактом |
| P2 | Day observer и local signal inbox; затем week/day planner | Replay одного рабочего дня даёт непротиворечивый план, интервалы и три проверяемых сигнала; человеческое время и review не превышают доступные окна |
| P3 | Profile/ledger/opportunities, подключение к weekly plan | Три карьерных кандидата с active goal, конкретным участием, evidence и time budget; принятый кандидат появляется в discretionary плане |
| P4 | Ограниченный пилот пяти рабочих дней после отдельного включения нужных процессов | Замер поиска контекста, выполненных/перенесённых actions, review backlog, полезных/лишних сигналов и времени обслуживания; затем изменение конкретных правил |
- **P0**. Работа: Зафиксировать входы; audit всего архива; начать 60/40; нормализовать пять реальных работ. Параллельно обследовать calendar и актуальные career sources. Проверяемый результат: Error-pattern table + action DAGs + конкретный способ чтения busy intervals и profile/rubric inputs.
- **P1**. Работа: Ввести SQL event/action/source-version contract; Windmill parent/child flows; рабочие границы; Python registry/run adapter. Проверяемый результат: На одной работе: вход → action DAG → AI run draft → replay waiting_review → human action с артефактом.
- **P2**. Работа: Day observer и local signal inbox; затем week/day planner. Проверяемый результат: Replay одного рабочего дня даёт непротиворечивый план, интервалы и три проверяемых сигнала; человеческое время и review не превышают доступные окна.
- **P3**. Работа: Profile/ledger/opportunities, подключение к weekly plan. Проверяемый результат: Три карьерных кандидата с active goal, конкретным участием, evidence и time budget; принятый кандидат появляется в discretionary плане.
- **P4**. Работа: Ограниченный пилот пяти рабочих дней после отдельного включения нужных процессов. Проверяемый результат: Замер поиска контекста, выполненных/перенесённых actions, review backlog, полезных/лишних сигналов и времени обслуживания; затем изменение конкретных правил.
Для старта детерминированного планирования и сигналов нужны P1–P2 на ограниченном scope; полный архив и оценка всех семантических классов могут проверяться параллельно. Смысловые рекомендации подключаются только для прошедшего оценку класса. Для карьерной подсветки добавляются актуальные goals/rubric и P3. Операции этой итерации — план и подготовка; rollout migrations, schedules, runner permissions и каналы доставки оформляются конкретными изменениями отдельно.
Основания реализации: [action demands](/Users/admin/Developer/personal-os/work-demand.js), [day coordinator](/Users/admin/Developer/personal-os/day-coordinator.js), [capacity](/Users/admin/Developer/personal-os/capacity-model.js), [timeline](/Users/admin/Developer/personal-os/work-timeline.js), [run normalizer](/Users/admin/Developer/personal-os/agent-run-adapters.js), [snapshot](/Users/admin/Developer/personal-os/source-snapshot.js), [attention feed](/Users/admin/Developer/personal-os/generate-attention.js), [career notes](/Users/admin/Developer/personal-os/agent/career-notes.md), [Obsidian profile](/Users/admin/obsidian/personal/career/profile.md), [flow map](/Users/admin/Developer/personal-os/windmill/system-map.yaml).
Инвентаризация существующего legacy-кода (ссылки ниже показывают текущие входы и правила; новые шаги реализуются на Python/SQL, JS-модули не становятся новым orchestration layer): [action demands](/Users/admin/Developer/personal-os/work-demand.js), [day coordinator](/Users/admin/Developer/personal-os/day-coordinator.js), [capacity](/Users/admin/Developer/personal-os/capacity-model.js), [timeline](/Users/admin/Developer/personal-os/work-timeline.js), [run normalizer](/Users/admin/Developer/personal-os/agent-run-adapters.js), [snapshot](/Users/admin/Developer/personal-os/source-snapshot.js), [attention feed](/Users/admin/Developer/personal-os/generate-attention.js), [career notes](/Users/admin/Developer/personal-os/agent/career-notes.md), [Obsidian profile](/Users/admin/obsidian/personal/career/profile.md), [flow map](/Users/admin/Developer/personal-os/windmill/system-map.yaml).
---
personal/projects/personal-os/personal-os-system-review-index.md
+1 -1
View File
@@ -28,7 +28,7 @@ updated: '2026-10-18'
| [[work-claims-results-2026-10-12]] | Каталог 486 работ с исходными ответами локальной модели и ссылками на источники; результат архивного прохода процесса анализа. |
| [[personal-os-windmill-system-map-2026-10-10]] | Карта системы в Windmill: 21 поток по стадиям fetch/observe/analyse/publish/attend, обзорный холст, источник `windmill/system-map.yaml`. |
| [[personal-os-db-browser]] | Локальный браузер БД: запуск на `127.0.0.1:4317`, источник `personal_os` на `localhost:5432`, проверка read-only SQL и доступных локальных решений. |
| [[personal-os-action-plan-2026-10-05]] | Рабочий план 18.10, A–H: аудит 486 результатов и 60/40 проверка; контракт полей; единый director; неделя/день и AI-runs; наблюдение/доставка сигналов; карьерные цели, вклад и возможности; SQL/триггеры/выходы, критические разрывы и P0–P4. Ниже сохранена история E1–E5. |
| [[personal-os-action-plan-2026-10-05]] | Рабочий план 18.10, A–H: аудит 486 результатов и 60/40 проверка; контракт полей; Windmill flows/schedules и Python/SQL; неделя/день и AI-runs; наблюдение/доставка сигналов; карьерные цели, вклад и возможности; SQL/триггеры/выходы, критические разрывы и P0–P4. Ниже сохранена история E1–E5. |
| [[personal-os-system-review-2026-10-04]] | Полный план: роли, data flow, инструкции, расписания, SC1–SC8, AC01–AC16 и R0–R4. |
| [[personal-os-evidence-graph-design-2026-10-04]] | Конкретные таблицы, ключи, typed relations, время, discovery, принятие claims, lineage и публикация. Заменяет ранний иллюстративный DDL. |
| [[personal-os-architecture-decision-2026-10-04]] | Единый выбранный стек и порядок поставки для утверждения. |