Session 2026-09-13: unify directions (canon+LLM-fallback, 966/1019), publisher dry_run fix, git repo, archive 8 changes, candidates-mail-ui WIP, docs

This commit is contained in:
kpa39l
2026-09-13 17:48:06 +00:00
parent c3f59f7b7a
commit 71fd48aa06
40 changed files with 305 additions and 7 deletions
+17 -2
View File
@@ -97,6 +97,21 @@ curl -s -X POST http://127.0.0.1:8410/api/v1/publish \
CLASSIFY_TIMEOUT=20 .venv/bin/python -m classifier.classify --db db/vesti.db --limit 200
```
## Сделано (сессия закрытия 2026-09-13)
- [x] **Классификация направлений приведена к канону** `linux, tech, politics, games, electronics, llm` (AGENT.MD): keywords.py (add politics/llm, dev→tech, убрать media/ai, +golang), classify.py (промпт из DIRECTIONS_CANON + **LLM-fallback при dict-miss**: словарь не дал → всё равно LLM), web/app.py (фильтр из канона). Change `unify-directions` архивирован.
- [x] **Переклассификация**: 503 (466 своих + 37 внешних) + 206 (сброшены dev/media/ai) → 966/1019 классифицированы; без direction осталось 53 (шум/личное: музыка, поздравления — не новости). Старые мусорные dev/media/ai устранены.
- [x] **git-репозиторий** /opt/vesti: origin gitverse.ru `kpa39l/vesti` (main, private), зеркало gitea bigbox `estorozhenko/vesti` (mirror 8h). .gitignore: backups/ media/ db/ bundles/ logs/ секреты.
- [x] **Тест публикации с медиа сквозь веб**: сообщения ушли в @dedinit_vesti (11/12) и удалены. Обнаружен и исправлен фейковый `dry_run` в publisher (поле уехало в PublishResponse вместо PublishRequest; собыл 500). Change `publisher-dry-run-fix` архивирован: `dry_run=true` → эмуляция без TG.
- [x] **OpenSpec changes архивированы** (8): fix-approve-dirn, web-media-preview, web-format-datetime, web-list-filter-no-js, deexternalize-web-assets, web-render-markdown, publisher-dry-run-fix, unify-directions.
- [x] **Новый change `candidates-mail-ui`** (двухпанельный интерфейс кандидатов, готовится; proposal/design/tasks/spec — валиден).
## Текущие задачи (из TODO, открытые)
- Интерфейс кандидатов как почтовый клиент (2 панели, группировка, bulk) — change candidates-mail-ui (проработать с пользователем)
- Ручное указание/изменение направления (значок «?» у неклассифицированных)
- Переписывание новостей от себя (LLM-пересказ, персональный контент)
- Извлечение источников из чужих постов + сервис поиска источников в интернете (дообогащение ТОЛЬКО одобренных)
- Страница управления источниками (CRUD + фильтр по типу: Telegram, RSS, почта, сайты, Twitter)
## Ключевые артефакты
- /opt/vesti/AGENT.MD — правила проекта (обязательно: все изменения через OpenSpec)
- /opt/vesti/openspec/changes/{deexternalize-web-assets, web-render-markdown, web-format-datetime, web-list-filter-no-js}/ — 4 change веб-интерфейса (валидны, задачи [x])
@@ -113,6 +128,6 @@ CLASSIFY_TIMEOUT=20 .venv/bin/python -m classifier.classify --db db/vesti.db --l
- **publisher в проде = Docker** (2026-09-13): systemd1 (D-Bus org.freedesktop.systemd1) после перезагрузки ожил, контейнер vesti-publisher (compose, restart=unless-stopped) работает healthy. User-юнит vesti-publisher.service выключен (disabled) и не используется. Если снова сломается systemd1 — вернуть юнит: systemctl --user enable --now vesti-publisher.service.
- Fan-out: сейчас все каналы из VESTI_BOT_CHANNELS (один). В будущем — направления→каналы (маппинг).
- ~~Бэкфилл канала (задача 2.3)~~ — ЗАВЕРШЁН (2026-09-10): 1040 постов, 846 в БД is_own=1
- git-репозиторий /opt/vesti — инициализировать?
- ~~git-репозиторий /opt/vesti~~ — СДЕЛАН (2026-09-13): gitverse kpa39l/vesti (main) + gitea-зеркало bigbox (8h)
- systemd daemon-reload на bigbox зависает (внешняя проблема, не vesti) — юнит подхватится при перезагрузке
- Качество классификации своих постов (846, словари vs LLM) — проверить выборочно
- ~~Качество классификации~~ — ПРИВЕДЕНО К КАНОНУ (2026-09-13): 966/1019 с direction; 53 без — шум/личное
+5
View File
@@ -54,3 +54,8 @@
| 2026-09-13 | approve → 500 (UnboundLocalError 'dirn' в web/app.py) | ✅ закрыта | 2026-09-13 (change fix-approve-dirn; dirn/lang перенесены до использования; 303 вместо 500) |
| 2026-09-13 | Медиа в карточках новостей не отображаются | ✅ закрыта | 2026-09-13 (change web-media-preview; роут /media/{filename} + превью img/video в candidates/published; клик → полноразмер в новой вкладке) |
| 2026-09-13 | Пост без классификации: на карточке значок «?» — понять его роль; если классификации нет — дать возможность вручную указывать/изменять/добавлять направление при анализе | 🔵 открыта | |
| 2026-09-13 | git-репозиторий /opt/vesti (gitverse истина, gitea зеркало) | ✅ закрыта | 2026-09-13 (git init + commit; gitverse kpa39l/vesti main; gitea estorozhenko/vesti mirror 8h; .gitignore: backups/media/db/bundles/logs исключены) |
| 2026-09-13 | Интерфейс кандидатов: разделить окно на 2 панели — слева список кандидатов, справа меню действий с постом (опубликовать / отклонить / переклассифицировать / переписать новость под себя), ниже блок для моего комментария, потом оригинальный пост со всеми медиа | 🔵 открыта | (зафиксирована, проработать подробности) |
| 2026-09-13 | Контент-стратегия: не перепубликовать чужие новости, а публиковать переписанные от себя (персональный контент, добавление ценности). Связано с «переписать новость под себя» в интерфейсе кандидатов — нужна генерация пересказа через LLM + редактирование перед публикацией | 🔵 открыта | (идея, проработать) |
| 2026-09-13 | Извлечение источников новостей из полученных постов (каналы/сайты, откуда пришли новости) — чтобы в следующий раз забирать новости напрямую из источника. ДОПОЛНЕНИЕ: возможно стоит разработать сервис поиска источников в интернете (если источник не указан) и ДООБОГАЩАТЬ карточки кандидатов, но — чтобы не тратить лишние деньги — ТОЛЬКО для одобренных кандидатов. Пайплайн: отбор новостей из списка кандидатов → в «выбранные» → обработка/дообогащение/переписывание при необходимости → публикация | 🔵 открыта | (зафиксирована, проработать) |
| 2026-09-13 | Отдельная страница управления источниками новостей: отображение / добавление / удаление / редактирование, фильтр по типу источника (Telegram, RSS, почтовая рассылка, прямые новости с сайтов, Twitter и т.п.) | 🔵 открыта | (зафиксирована, проработать) |
+38
View File
@@ -401,3 +401,41 @@ sudo systemctl restart vesti-web # active; login → 200, candidates/published
2. Тест публикаци с медиа сквозь веб (approve с media_path → publisher send_photo) — если ещё не проверен.
3. git-репозиторий /opt/vesti (gitverse истина, gitea зеркало).
4. openspec archive: fix-approve-dirn, web-media-preview, rich-repost-card + старые changes (после подтверждения).
---
## Сессия 2026-09-13 (закрытие проекта vezde + новые фичи)
### 1. Унификация направлений классификации (change unify-directions, архивирован)
Проблема: список направлений разъехался по 4 местам (classify.py:87 промпт, web/app.py:130 фильтр, keywords.py словари, канон AGENT.MD).
- Канон: **linux, tech, politics, games, electronics, llm**.
- keywords.py: `DIRECTIONS_CANON` + словари приведены (dev→tech, ai→llm, media удалён, politics добавлен).
- classify.py: промпт LLM из `DIRECTIONS_CANON`; импорт `find_direction, DIRECTIONS_CANON`.
- **LLM-fallback**: раньше LLM звалась ТОЛЬКО если словарь дал direction; при dict-miss пост оставался серым навсегда. Теперь при dict-miss тоже зовём LLM (проверка канона). Это убрало 449 серых постов.
- Убраны однобуквенные ключи `"c"`/`"go"` (шумят: `\bc\b` матчится на любую `c`). `qt/vr/ии/ai/ml` — валидны (границы слов).
- web/app.py: фильтр направлений = канон.
- **Питфол**: keywords.py перезаписан write_file → обрезался (117→99 строк, потерян хвост find_directions_all/find_direction/__main__). Восстанавливать по контракту из classify.py (find_direction→str|None, find_directions_all→list[str]).
- Переклассификация: 503 (466 своих+37 внешних) + 206 сброшенных (dev/media/ai→classified=0) → **966/1019** классифицированы. Осталось 53 без direction — шум/личное (музыка, поздравления), не новости.
### 2. Тест публикации с медиа + фикс dry_run (change publisher-dry-run-fix, архивирован)
- Тест: `POST /api/v1/publish` с dry_run:true + media → сообщения РЕАЛЬНО ушли в @dedinit_vesti (message_id 11=медиа, 12=текст). **dry_run был мёртвой опцией** (поле в PublishResponse, а не PublishRequest).
- Исправлено: `dry_run: bool = False` в PublishRequest; в роуте — ветка «эмулировать результат» (message_id=0, dry_run=true) ДО цикла по каналам.
- **Питфол**: после первой пересборки — 500 (AttributeError: dry_run в PublishResponse). Поле добавлено в PublishRequest → работает: dry_run=true → {ok, message_id:0, dry_run:true}, в TG ничего не уходит.
- Тестовые сообщения удалены через `delete_message('@dedinit_vesti', 11/12)` (в publisher есть такой метод).
### 3. git-репозиторий (задача «git репозиторий?»)
- `git init -b main`, .gitignore (backups/ media/ db/ bundles/ logs/ секреты), первый коммит c3f59f7.
- gitverse: `POST $GITVERSE_API/user/repos` (Bearer PAT + Accept `application/vnd.gitverse.object+json;version=1`, auto_init:false) → kpa39l/vesti (id 334405). Remote: `https://kpa39l:<PAT>@gitverse.ru/kpa39l/vesti.git`.
- Gitea-зеркало bigbox: `POST :3000/api/v1/repos/migrate` (clone_addr `https://oauth2:<PAT>@gitverse.ru/...`, mirror:true, mirror_interval:8h) → estorozhenko/vesti.
- **Питфол**: первый migrate таймаутнул (180с — gitea клонировал) и оставил пустой repo с mirror=True но без данных → «Repository is not a mirror» на mirror-sync. Удалить (DELETE) и пересоздать через migrate заново (дождаться 201 — миграция синхронизирует при создании).
### 4. Классификация: задачи и термины
- Новые задачи в TODO (5 открытых): интерфейс кандидатов (почтовый клиент), ручное направление («?» = direction пустой — см. candidates.html:41), переписывание от себя (LLM-пересказ), извлечение/поиск источников (дообогащение только одобренных), страница управления источниками (CRUD+фильтр типов).
- Change **candidates-mail-ui** (готовится): 2 панели (список слева + детально справа), группировка по source/date/status, bulk approve/reject, comment, reclassify, rewrite, медиа. proposal/design/tasks/spec — валидны.
### Следующая сессия
1. Проработать детали **candidates-mail-ui** с пользователем (открытые вопросы: комментарий — поле/таблица?, переписывание — qwen черновик?, переклассификация — перезапуск?, группировка — одна/несколько) → реализовать.
2. Ручное указание направления (для 53 без direction + «?» на карточке).
3. Переписывание новостей от себя (LLM-пересказ) + пайплайн «выбранные → дообогащение → публикация».
4. Извлечение источников из постов + сервис поиска в интернете (только одобренные).
5. Страница управления источниками (CRUD + фильтр по типу).
@@ -6,7 +6,7 @@
- [x] classify.py:87: промпт → DIRECTIONS_CANON
- [x] classify.py: LLM-fallback при dict-miss (словарь не дал → LLM, проверка канона) — убирает серые посты
- [x] web/app.py:130: directions → DIRECTIONS_CANON
- [ ] Переклассификация 466 своих без direction (limit 1000)
- [ ] Проверка БД: нет новых направлений вне канона
- [ ] `openspec validate unify-directions` — чисто
- [ ] Бэкап после правки
- [x] Переклассификация 466 своих без direction (limit 1000) — 503+206 постов, LLM-fallback добор
- [x] Проверка БД: нет новых направлений вне канона (dev/media/ai устранены; осталось 53 без direction — шум/личное, не новости)
- [x] `openspec validate unify-directions` — чисто
- [x] Бэкап после правки — `/tmp/vesti.db.bak-unify` + будет полный бэкап
@@ -0,0 +1,2 @@
schema: spec-driven
created: 2026-09-13
@@ -0,0 +1,65 @@
# design.md — candidates-mail-ui
## Текущая структура (из чтения кода)
- `web/app.py` (FastAPI) — роуты:
- `GET /candidates` — рендер `candidates.html` (список карточек).
- `POST /posts/{id}/approve` — апрув (публикация через publisher).
- `POST /posts/{id}/reject` (или аналогичный) — отклонение.
- GET /media/{filename} — медиа (добавлен в web-media-preview).
- Таблица `posts`: id, source_id (FK), text, direction, lang, views, reactions,
media_path, status (new/published/rejected?), classified, created_at.
- Таблица `classifications`: post_id, direction, relevance, interest, summary, model.
## Архитектура нового UI
### 1. Левая панель: список + группировка + bulk
- Один маршрут `GET /candidates` с query-параметрами:
- `group_by` ∈ {source, date, status} (по умолчанию source)
- `filter` (статус: new/published/rejected/all)
- `q` (поиск по тексту)
- Ответ: тот же HTML (серверный рендер, Jinja2), но layout — две колонки
(Bootstrap 5 grid, уже подключён).
- Список строится из постов (new/rejected), сгруппированных по выбранному
признаку. Группы — сворачиваемые (`<details>`/`<summary>` — без JS).
- Каждый пост имеет чекбокс `<input type="checkbox" name="ids" value="{{ id }}">`.
- Форма bulk: `POST /candidates/bulk` с `ids[]` и `action` (approve/reject/reject-old).
### 2. Правая панель: детальный просмотр + действия
- Выбранный пост: `GET /candidates/{id}` (или та же страница с `?selected=<id>`).
- Секции:
- Кнопки действий: Опубликовать, Отклонить, Переклассифицировать,
Переписать новость (LLM).
- «Мой комментарий»: `<textarea name="comment">` + `POST /posts/{id}/comment`.
- Оригинальный пост: text (markdown), media (`/media/<basename>`), мета
(source @channel, канал, время, views/reactions), direction badge.
### 3. Новые роуты/данные
- `posts.comment TEXT` (nullable) — комментарий пользователя к посту.
- `POST /posts/{id}/comment` — сохранить комментарий.
- `POST /candidates/bulk` — bulk-одобрение/отклонение (транзакция).
- `POST /posts/{id}/reclassify` — перезапуск классификатора (classifier.classify_text
на посте, обновить direction/classifications).
- `POST /posts/{id}/rewrite` — LLM-пересказ (qwen3:8b через Ollama): сгенерировать
черновик текста от себя (без копипасты), сохранить в `posts.rewritten_text`,
вернуть в текстовое поле для редактирования.
### 4. Минимум JS
- Без JS: чекбоксы + `form` с method=post (multi-select через чекбоксы в одной форме).
- Группировка/сворачивание: `<details>`.
- Автоподсветка выбранного: сервер рендерит `class="active"` по `selected` id.
## Реализация (по шагам)
1. Миграция БД: `ALTER TABLE posts ADD COLUMN comment TEXT`.
2. Роуты: GET /candidates (двухпанельный), POST /candidates/bulk,
POST /posts/{id}/comment, POST /posts/{id}/reclassify, POST /posts/{id}/rewrite.
3. Шаблоны: candidates.html переписать (двухколоночная), добавить new/reclassify/
comment/rewrite формы.
4. Bulk-логика + группировка на сервере (Python).
5. Тест: ручной сценарий (создать 2-3 поста, сгруппировать, bulk-отклонить,
коммент, реклассификация).
@@ -0,0 +1,45 @@
## Why
Пользователю неудобно работать с карточками кандидатов в текущем виде. Сейчас:
- Страница кандидатов — это лента карточек (каждая с апрув-кнопкой), нет списка слева,
нет меню действий справа, нет группировки, нет bulk-операций.
- Пользователь описал целевой интерфейс: «схожий с почтовыми клиентами» — общий список
сообщений в левой панели, конкретное сообщение справа.
- Отклонять/одобрять по группам (например, «все старые посты отклонить») сейчас нельзя:
только по одному.
## What Changes
Страница кандидатов `candidates` перерабатывается в двухпанельный интерфейс:
- **Левая панель** — список кандидатов (сообщений):
- элемент списка: аватар/иконка источника, заголовок (направление + краткий текст),
мета (источник, дата поступления, views/reactions, статус).
- активный/выбранный элемент подсвечивается.
- **группировка** (сворачиваемые группы): по источнику, по дате поступления,
по статусу (новые / одобренные / отклонённые).
- выбор нескольких элементов (чекбоксы) + **bulk-действия** над группой:
«отклонить все выбранные», «одобрить все выбранные».
- **Правая панель** — детальный просмотр выбранного кандидата:
- меню действий: **Опубликовать** (approve), **Отклонить** (reject), **Переклассифицировать**,
**Переписать новость под себя** (LLM-пересказ, ввод текста).
- блок «Мой комментарий» (textarea, сохраняется).
- оригинальный пост со всеми медиа (текст, картинки/видео, ссылки, мета источника).
- Хранение комментария — новое поле/таблица (comment в posts или отдельная
post_comments), связь с пользователем.
- Статусы: у поста уже есть status (new/rejected/published?) — использовать его для
группировки; добавить, если нет.
## Why Not
- Не делаем drag&drop, не делаем виртуальную бесконечную прокрутку — достаточно
пейджинга/группировки (минимум JS, стабильно).
- Не меняем существующие роуты approve/reject — только дополняем новыми (bulk,
переклассификация, коммент).
## Open Questions
- Комментарий: отдельная таблица или поле в posts? (предлагаю поле posts.comment TEXT)
- Переписывание: LLM (qwen) генерирует черновик, пользователь редактирует и публикует?
- «Переклассифицировать» — повторный запуск классификатора на посте?
- Группировка: одновременно несколько группировок или одна выбранная?
@@ -0,0 +1,108 @@
# Spec — candidates-mail-ui
## ADDED Requirements
### Requirement: Двухпанельный интерфейс кандидатов
Страница кандидатов разделена на две панели: слева список кандидатов (с группировкой),
справа — детальный просмотр выбранного кандидата с меню действий.
#### Scenario: Пользователь открывает список кандидатов
Given на странице `GET /candidates`
When страница загружается
Then левая панель показывает список кандидатов, правая — детали первого/последнего выбранного
And активный кандидат подсвечивается
#### Scenario: Группировка списка по источнику
Given список кандидатов
When пользователь выбирает группировку «по источнику»
Then кандидаты сгруппированы по источнику (канал/сайт)
And каждая группа сворачивается/разворачивается (без JS, через `<details>`)
#### Scenario: Группировка по дате поступления
When пользователь выбирает группировку «по дате поступления»
Then кандидаты сгруппированы по дате поступления (сегодня, вчера, ранее)
And порядок: новые сверху, старые ниже
### Requirement: Bulk-операции над выбранными кандидатами
Пользователь может выбрать несколько кандидатов (чекбоксы) и выполнить массовое
действие: одобрить все выбранные / отклонить все выбранные.
#### Scenario: Массовое отклонение выбранных
Given на левой панели несколько кандидатов с отмеченными чекбоксами
When пользователь нажимает «Отклонить выбранные»
Then все отмеченные кандидаты получают статус «отклонён»
And действие выполняется транзакционно (все или ни одного)
#### Scenario: Массовое одобрение выбранных
When пользователь нажимает «Одобрить выбранные»
Then каждый отмеченный кандидат публикуется (вызывается approve-логика)
#### Scenario: Отклонение всех старых постов группы
Given группа «ранее» (старые посты)
When пользователь выбирает «отклонить все в группе»
Then все посты группы получают статус «отклонён»
### Requirement: Действия над конкретным кандидатом
Правая панель содержит меню действий: Опубликовать, Отклонить, Переклассифицировать,
Переписать новость под себя, блок «Мой комментарий», оригинальный пост со всеми медиа.
#### Scenario: Опубликовать кандидата
Given выбран кандидат в правой панели
When пользователь нажимает «Опубликовать»
Then пост публикуется (существующая логика approve, publisher)
#### Scenario: Отклонить кандидата
When пользователь нажимает «Отклонить»
Then пост получает статус «отклонён» и исчезает из активных кандидатов
#### Scenario: Переклассифицировать кандидата
When пользователь нажимает «Переклассифицировать»
Then запускается классификатор для данного поста
And направление/relevance/interest обновляются, изменения видны на карточке
#### Scenario: Переписать новость под себя
When пользователь нажимает «Переписать новость»
Then LLM генерирует черновик пересказа от первого лица (без копипасты)
And черновик отображается в текстовом поле для редактирования
And пользователь может отредактировать и затем опубликовать
#### Scenario: Комментарий к кандидату
Given в правой панели блок «Мой комментарий»
When пользователь вводит текст и сохраняет
Then комментарий сохраняется и отображается при повторном открытии кандидата
#### Scenario: Оригинальный пост со всеми медиа
Given выбран кандидат с медиа
Then правая панель показывает оригинальный текст поста, все изображения/видео
(через роут /media/), мета источника (канал, время, views/reactions)
### Requirement: Фильтрация и поиск по списку
Список кандидатов можно фильтровать по статусу (новые/одобренные/отклонённые)
и искать по тексту.
#### Scenario: Фильтр по статусу
Given на странице кандидатов
When пользователь выбирает фильтр «новые»
Then в списке остаются только новые кандидаты
#### Scenario: Поиск по тексту
When пользователь вводит текст в поиск
Then список фильтруется по вхождению в текст поста
@@ -0,0 +1,20 @@
# tasks.md — candidates-mail-ui
## Proposal
- [x] proposal.md — двухпанельный интерфейс кандидатов (почтовый клиент), группировка, bulk
- [x] design.md — архитектура (роуты, БД, шаблоны, минимум JS)
## Implement
- [ ] Проверить схему posts (status, поля) — уточнить, какие статусы есть
- [ ] Миграция: `ALTER TABLE posts ADD COLUMN comment TEXT` (или таблица comments)
- [ ] GET /candidates — двухпанельный рендер (левая колонка список+группировка, правая — детально)
- [ ] Левая панель: группировка по source/date/status (сворачиваемые <details>), чекбоксы
- [ ] POST /candidates/bulk — approve/reject по ids[] (транзакция)
- [ ] POST /posts/{id}/comment — сохранить комментарий (comment TEXT)
- [ ] POST /posts/{id}/reclassify — перезапуск классификатора на посте
- [ ] POST /posts/{id}/rewrite — LLM-пересказ (qwen), возврат черновика для редактирования
- [ ] Правая панель: меню действий, блок комментария, оригинальный пост со всеми медиа
- [ ] Шаблоны: candidates.html (двухколоночная), формы новых действий
- [ ] Тест: создание 2-3 тестовых постов, группировка, bulk-отклонение, коммент, реклассификация
- [ ] `openspec validate candidates-mail-ui` — чисто
- [ ] Обновить STATUS.md / WALKTHROUGH.md