Что делает документ плана в формате markdown хорошим для проекта по разработке программного обеспечения? В чем разница между хорошим планом и отличным? Я всегда говорю о том, что трачу более 85% своего времени и энергии на этапы планирования. Так что же это на самом деле подразумевает? Трудно объяснить в абстрактном виде; вам нужен конкретный пример, чтобы действительно проиллюстрировать нюансы. Поэтому я решил поделиться хорошим примером из сегодняшнего дня. Это также отвечает на недавний вопрос, который я получал о своем подходе. Люди, похоже, думают, что нужно делать все в своем проекте за один раз. И в моем подходе это правда, но только для версии 1! Если вы решите, что хотите добавить новые функции или изменить, как все работает, вы, очевидно, можете это сделать, как только у вас будет работающая версия 1. И способ, которым вы это делаете, такой же, как и создание версии 1: сначала создаете суперподробный план в формате markdown, а затем превращаете его в beads. Итак, я приведу вам пример из Cass, моей программы поиска сессий Coding Agent, которая является довольно сложной программой на Rust, которая автоматически обнаруживает, парсит, хранит и индексирует все ваши предыдущие журналы сессий почти от каждого кодирующего агента. Она предлагает мгновенный поиск "по мере ввода" менее чем за 50 мс по всем этим журналам и имеет много других приятных функций. Я решил, что хотел бы добавить в Cass функцию, аналогичную функции, которую я уже имею в MCP Agent Mail и в beads_viewer (bv): возможность экспортировать вашу настройку как статический веб-сайт, который можно обслуживать с помощью GitHub Pages. Вы можете увидеть пример для bv для этого самого проекта, который является конечным результатом процесса планирования, который я опишу в этом посте: Эта функциональность делает очень быстрым и простым создание и развертывание экспортированного сайта с помощью утилиты gh. Сам сайт обычно состоит из файла sqlite и кучи typescript и wasm, которые полностью работают в браузере, но с очень хорошей производительностью и приятными функциями и стилем, которые вы можете наблюдать в приведенном выше примере. Теперь делиться сообщениями MCP Agent Mail или кучей beads — это одно, но делиться кучей журналов сессий кодирующего агента — это совсем другое; эти вещи часто полны конфиденциальной информации, API-ключей, ругательств/оскорблений (по крайней мере, у меня так!), и другого материала, который вы определенно не хотите выставлять на показ миру. Но GitHub Pages, как бы это ни было приятно, работает только для публичных репозиториев (кстати, мои инструменты также поддерживают страницы Cloudflare, но GH Pages лучше и проще для этого случая). Так как же решить эти проблемы? Ответ — шифрование: пользователь сначала выбирает, каких кодирующих агентов включить, какие папки проектов, временной период и т. д., и создается пакет (обратите внимание, что этот пакет находится в каноническом формате, в который Cass внутренне преобразует все сообщения кодирующих агентов из их оригинальных форматов), а затем пользователь предоставляет пароль для шифрования этого пакета. Идея в том, что хотя репозиторий и веб-страница публичны, все, кроме вас и тех, кому вы скажете пароль, просто увидят поле для ввода пароля и не смогут прочитать ни одно из сообщений. ...