Постоянно сталкиваюсь с новыми проектами, и каждый раз нужно настраивать Rules для cursor.com. Простой гуглеж показал что можно не выдумывать, а подобрать уже готовое - https://cursor.directory/rules. Не благодарите

Facebook выпустили новую модель, которая предсказывает ветвление кода.
Хорошее подспорье для ИИ-агентов, так как зачастую проверить работоспособность можно только через запуск тестов или другим рантаймом. Если работает как ожидается - модели такого класса снизят потребление вычислительных мощностей, что удешивит их эксплуатацию.
Забрать можно тут - https://huggingface.co/facebook/cwm.
На Ollama пока не появилось, соответственно в Turbo Mode потестировать не получится

cursor.com изменили ценовую политику на свои тарифные планы. Тем кто не успел до 15 сентября оплатить годовую подписку (а судя по всему на это и был расчет), в следующем биллинге включат новую систему ценообразования (https://cursor.com/blog/aug-2025-pricing). Ваш покорный не успел, и теперь, чтобы оставаться таким же быстрым и эффективным надо покупать Ultra. Хотя, годом раньше/годом позже, все равно пришлось бы. Халяве конец

Написав ряд велосипедов для ИИ-агентов на temporal.io, пришло понимание что надо подняться на уровень выше, и как-то структурировать свои подходы. Набрел на https://github.com/dynamiq-ai/dynamiq, и понял что можно в очередной раз переписать то, что уже и так работает.

Что понравилось
1) Есть возможность работать со своими локальными моделями
2) Есть готовый туллинг (простой, но пока его достаточно)
3) Примитивы готовы к работе, и понятно структурированы (не то что я тоже самое не выделял ранее, но когда мысли совпадают - приятно)

Продолжаю развлекаться с temporal.io. Сегодня речь пойдет про его функционал расписаний — https://docs.temporal.io/develop/go/schedules. Основное зачем использую — у меня в проекте есть активность которая по запросу индексирует документы для RAG. Но есть неприятность — люди иногда эти документы обновляют и требуется перестраивать весь RAG раз в какое-то время (от 2 часов до суток). По старинке такое обычнно добавляют в crontab и живут себе припеваючи. Но, в моем случае надо чтобы

1. одинаковые источники не запускались в один момент времени. Тогда городим огород из flock

# не запускать второй экземпляр, если первый ещё идёт
* * * * * /usr/bin/flock -n /var/lock/myjob.lock -c "/usr/local/bin/job --param A"

2. Вторая проблема — этих источников N. Управляем ими из админки, и поэтому, либо надо в расписание добавлять кучу кронов с разными параметрами. Или умный контроллер на входе их запускает параллельно. Но это тоже не выход, расписания у всех разные

На помощь приходит Temporal где уже написанную активность просто ставим через API в нужное нам расписание, и оно запускается на выделенном вокере строго по нему.

Джыпытя мне тут кратко рассказала что еще оно умеет, прошу ознакомиться

Ключевые возможности (Temporal Schedules, Go SDK)

* Гибкий Spec: календарные правила, интервалы, cron-строки, объединение нескольких правил и исключения; поддержка таймзон (по умолчанию UTC), аккуратность с DST, есть jitter.
* Жизненный цикл из коробки: Create / Describe / List / Update / Delete через ScheduleClient/Handle.
* Пауза/возобновление: Pause / Unpause для временной остановки будущих запусков.
* Ручной триггер: Trigger() — немедленный запуск по расписанию (с учётом overlap-политики).
* Backfill: дозапуск “пропущенных” окон с выбором политики пересечений.
* Политики пересечений (overlap): Skip, BufferOne, BufferAll, AllowAll, CancelOther, TerminateOther.
* One-shot отложенный старт: StartDelay для единичного запуска в будущем.
* Автоудаление: когда расписание “выработано”, сервис удаляет его (момент не гарантируется).

Инструменты

* Доступно в SDK (Go/TS/Python/.NET) и в Temporal CLI для администрирования.

Ссылки

* Schedules — Go SDK: [https://docs.temporal.io/develop/go/schedules](https://docs.temporal.io/develop/go/schedules)
* Temporal CLI, schedule: [https://docs.temporal.io/cli/schedule](https://docs.temporal.io/cli/schedule)

Сегодня поговорим про DevLog. DevLog - то как я его вижу, это записи по мере разработки проекта. До эпохи нейросетей обычно такие вещи мы отражали во внутренней документации проекта. Сегодня можно отдать рутину по саммаризации правок ИИ агентам, и они будут сами выполнять эту важную, но монотонную работу.

Зачем вам он вообще нужен? Ну, во-первых, понять во времени как менялся проект. Вам это позволит совершенствоваться, или вспомнить позже какое-то удачное решение. Во-вторых, он нужен ИИ агентам, чтобы иметь контекст разработки в целом, и навигацию по основным этапам. Так как в конечном счете это все равно текст, он будет успешно обработан и агент будет руководстоваться логикой правок, который был описан в логе.

Ну и правило для Cursor как бонус

---
alwaysApply: true
---

# DevLog Documentation Rule

## Когда создавать DevLog файлы

При завершении работы над задачей, фиксом или значительным изменением в коде, всегда создавай файл с кратким описанием в директории [docs/devlog/](mdc:docs/devlog/).

## Формат названия файла

Название файла должно следовать формату:

XXXX-краткое-описание-изменений.md


Где:
- XXXX - четырёхзначный порядковый номер (0001, 0002, 0003, и т.д.)
- - - дефис-разделитель после номера
- краткое-описание-изменений - описание строчными буквами (lowercase), слова разделены дефисами
- .md - расширение Markdown файла

### Примеры правильных названий:
- ✅ 0001-multi-source-search-implementation.md
- ✅ 0002-fix-authentication-bug.md
- ✅ 0003-add-gitlab-integration.md
- ✅ 0123-optimize-qdrant-queries.md

### Примеры неправильных названий:
- ❌ MULTI_SOURCE_SEARCH_SUMMARY.md (нет индекса, заглавные буквы, подчёркивания)
- ❌ fix-bug.md (нет индекса)
- ❌ 1-Fix-Bug.md (индекс не 4 цифры, заглавные буквы)

## Определение следующего номера

Перед созданием нового файла:
1. Проверь содержимое директории [docs/devlog/](mdc:docs/devlog/)
2. Найди файл с максимальным индексом (например, `0042-...`)
3. Используй следующий номер (`0043`)
4. Если директория пуста, начни с 0001

## Структура DevLog файла

Файл должен содержать:

1. Заголовок - краткое название задачи/фикса
2. Проблема (🎯) - описание проблемы или задачи
3. Решение (✅) - описание реализованного решения
4. Изменённые файлы (📝) - список изменённых файлов с кратким описанием
5. Как протестировать (🚀) - инструкции для проверки изменений
6. Важные детали (⚙️) - дополнительная информация, особенности реализации
7. Итог (🎉) - краткий summary результата

### Пример структуры:


# Краткое описание задачи

## 🎯 Проблема
Описание проблемы...

## ✅ Решение
Описание решения...

## 📝 Изменённые файлы
1. путь/к/файлу.py - что изменено
2. путь/к/другому/файлу.ts - что изменено

## 🚀 Как протестировать
Инструкции для тестирования...

## ⚙️ Важные детали
Дополнительная информация...

## 🎉 Итог
Краткий summary...


## Когда НЕ создавать DevLog

Не создавай DevLog файлы для:
- Мелких опечаток или исправлений форматирования
- Обновления документации без изменений в коде
- Рефакторинга без изменения функциональности (если только это не большой рефакторинг)

## Примеры использования

### Пример 1: Исправление бага
Файл: docs/devlog/0001-fix-search-single-source-bug.md
Содержание: Описание проблемы с поиском только в одном источнике и реализованное решение

### Пример 2: Новая фича
Файл: docs/devlog/0002-add-jira-integration.md
Содержание: Описание интеграции с Jira

### Пример 3: Оптимизация
Файл: docs/devlog/0003-optimize-embedding-performance.md
Содержание: Описание оптимизации производительности embeddings

## Важно

- Всегда проверяй существующие файлы в [docs/devlog/](mdc:docs/devlog/) перед созданием нового
- Используй строчные буквы в названии (lowercase)
- Разделяй слова дефисами, не используй underscores или CamelCase
- Пиши на русском языке в содержимом файла (если это основной язык проекта)
- Используй эмодзи для визуальной структуры (🎯 ✅ 📝 🚀 ⚙️ 🎉)

Наконец-то появился Plan-Mode в Cursor.

Кто не в курсе, обычный эффективный цикл работы с агентами - создаем MD-план на проект, описываем в директории docs/ все этапы разработки, и идем по чеклисту, скрамливая по файлику за раз агенту, и тот реализует требования. Просто и понятно.

Кто был ленивый - использовал MCP TaskMaster. Но проблема его была в том, что он генерил тонну не нужных реализаций и надо было вычищать.

Посмотрим что можно сделать в реализации от Cursor

https://cursor.com/blog/plan-mode

Неплохая статья подумать о том куда все идет. У самого есть пара идей, выложу на medium.com как допишу и соберу все мысли во едино. https://www.ibm.com/think/insights/artificial-intelligence-future

Накидал статью по мотивам - https://medium.com/@vinogradoff/effective-ai-87325da67a38

В Cursor завезли Debug-режим. Раньше тоже самое можно было сделать через режим планирования, где ты описываешь проблему, и просишь ее исследовать. Теперь флоу упростился - скидываешь логи, контекст и ждешь решения. Работает не с первого раза, много пишет отладочных логов, надо за этим следить. Но в целом направление верное. Давно такого не хватало. https://cursor.com/blog/debug-mode

Моя ачивка за год от Cursor.com xD