---
name: fiksiruy
description: Фиксирует статус и события по проекту в единый журнал решений. Триггерится на команды «фиксируй», «запиши», «залогируй», «зафиксируй решение», «это в журнал», «снимок статуса», а также на неявные сигналы — принятое архитектурное решение, изменение scope, выявленная блокер-проблема, релиз, демо. Создаёт / обновляет `LOG.md` в корне проекта и, если нужно, отдельные ADR-файлы.
---

# fiksiruy

## Когда триггерится
- явная команда: «фиксируй», «запиши это», «добавь в лог», «сделай снимок», «зафиксируй решение»;
- в речи принято архитектурное / продуктовое решение («ок, делаем через Postgres», «уходим от Redis», «ЦА — эмигранты в Турции»);
- появился блокер / риск;
- сменился статус (milestone, релиз, демо, интеграция);
- перед тем как долго копать — «зафиксируй гипотезу» (чтобы потом не забыть, что тестировали).

## Что делает
Создаёт/обновляет человекочитаемый журнал `LOG.md` в корне проекта. Каждая запись — атомарная, датированная, с одним из типов:

- `DECISION` — принято решение (что, почему, альтернативы, последствия);
- `STATUS` — снимок состояния (что сделано / что в работе / что болит);
- `RISK` — замеченный риск или блокер;
- `ASSUMPTION` — гипотеза, которую потом надо проверить;
- `RELEASE` — факт релиза / демо / выкладки;
- `NOTE` — произвольная заметка, которая важна на будущее.

Для крупных архитектурных решений дополнительно создаётся отдельный ADR-файл в `docs/adr/NNNN-{slug}.md`.

## Какой контекст подкладывает
- путь к `LOG.md` (создать, если нет);
- путь к `docs/adr/` (создать, если нет);
- шаблон записи (см. ниже);
- правило «одна запись — одна мысль»;
- правило «каждая запись содержит дату в ISO 8601»;
- правило «DECISION должен содержать поле `supersedes` или быть связан с предыдущим DECISION по теме»;
- при отсутствии контекста спросить, к какому проекту относится фиксация.

## Шаблон записи в `LOG.md`

```
---
### 2026-04-22 · DECISION · Переходим на Postgres для хранения профилей
**Контекст.** MVP работал на JSON-файлах, с 5k пользователей начал тормозить rebuild профилей.
**Решение.** Хранить `user_feature_values` и `events` в Postgres 16, оставить JSON-кэш для serving.
**Альтернативы.** (а) оставить файлы + индексы; (б) SQLite; (в) Clickhouse.
**Последствия.** +зависимость psycopg; миграции через alembic; latency serving сохраняется за счёт кэша.
**Ссылки.** `app/repositories/postgres_repository.py`, ADR-0004.
```

```
### 2026-04-22 · STATUS · Снимок недели
- done: questionnaire audit pipeline, backtest v1
- doing: миграция профилей в Postgres
- blocked: нет размеченных диетологом тегов, ждём Машу
- next: демо под клиентский кейс Х
```

```
### 2026-04-22 · RISK · Нет прав на меню ресторана
Юр-риск: сейчас парсим меню без договора. Митигация — подписать акт с рестораном-пилотом до 15 мая.
```

## Шаблон ADR (`docs/adr/NNNN-{slug}.md`)

```
# ADR-0004: Postgres для хранения профилей

- Дата: 2026-04-22
- Статус: accepted
- Supersedes: —

## Контекст
...

## Решение
...

## Альтернативы
...

## Последствия
### Плюсы
...
### Минусы
...

## Открытые вопросы
...
```

## Алгоритм работы скилла
1. Понять тип записи (DECISION / STATUS / RISK / ASSUMPTION / RELEASE / NOTE).
2. Спросить/вывести недостающие поля по шаблону.
3. Найти / создать `LOG.md`. Проставить дату в ISO.
4. Добавить запись **сверху**, чтобы свежее было наверху.
5. Если это DECISION и он значимый (нарушает/меняет архитектуру) — параллельно создать ADR-файл с инкрементным номером, сослаться на него из `LOG.md`.
6. Если запись `supersedes` старую — добавить в старую запись пометку `superseded by ...`.
7. Вернуть короткое подтверждение пользователю: что записано, где, какой номер ADR.

## Правила скилла
- никогда не переписывать прошлые записи «ретроактивно», только добавлять `amendment` / `superseded by`;
- каждая запись должна читаться вне контекста чата: минимум «что решили + почему + что из этого следует»;
- не фиксировать то, что уже зафиксировано ранее — если запись дублирует предыдущую, скилл говорит об этом и предлагает её обновить;
- при STATUS — всегда блоки done / doing / blocked / next, даже если какой-то пустой.

## Что НЕ делает
- не ведёт календарь и задачник — для этого есть трекер;
- не пишет красивый changelog для релиз-нот — это отдельный скилл;
- не делает выводов и не рекомендует — только фиксирует.