Що робить документ з планом зниження цінності для проєкту розробки програмного забезпечення? У чому різниця між хорошим планом і чудовим? Я постійно розповідаю, що витрачаю 85%+ свого часу та енергії на етапи планування. А що це означає насправді? Це важко пояснити абстрактно; Потрібен конкретний приклад, щоб справді проілюструвати нюанси. Тож я вирішив поділитися хорошим прикладом із сьогоднішнього дня. Це також відповідає на нещодавнє питання, яке я отримав щодо мого підходу. Здається, люди думають, що потрібно робити все в проєкті за один раз. І в моєму підході це правда, але лише для першої версії! Якщо ви вирішите додати нові функції або змінити спосіб роботи, звісно, можна це зробити, коли у вас буде працююча версія 1. І це відбувається так само, як ви створюєте v1: спочатку створюєте дуже детальний план розмітки, а потім перетворюєте його на намистини. Тож я наведу приклад із Cass, моєї програми Coding Agent Session Search, яка є досить складною програмою на Rust, що автоматично виявляє, парсить, зберігає та індексує всі ваші попередні журнали сесій майже з усіх програмних агентів. Він пропонує миттєвий «пошук під час набору» менш ніж за 50 мс у всіх цих журналах і має багато інших корисних функцій. Я вирішив додати функцію до Cass, схожу на функцію, яку я вже маю в MCP Agent Mail і в beads_viewer (bv): можливість експортувати вашу систему як статичний вебсайт, який можна обслуговувати через GitHub Pages. Ви можете побачити приклад BV саме для цього проєкту, який є фінальним результатом процесу планування, який я опишу в цьому дописі: Ця функціональність робить дуже швидким і простим створення та розгортання експортованого сайту за допомогою утиліти gh. Сам сайт зазвичай складається зі sqlite-файлу та великої кількості typescript і wasm, які повністю працюють у браузері, але з дуже хорошою продуктивністю та приємними функціями та стилем, що ви можете побачити на наведеному прикладі. Обмін повідомленнями агента MCP або купою бісерів — це одне, а спільне використання багатьох журналів сесій агента кодування — зовсім інше; ці речі часто наповнені конфіденційною інформацією, ключами API, лайками/інвективами (принаймні моїми!) та іншими матеріалами, які ви точно не захочете розкривати світу. Але GitHub Pages, яким би зручним він не був, працює лише для публічних репозиторій (до речі, мої інструменти також підтримують сторінки Cloudflare, але GH Pages кращий і простіший для цього випадку). То як же впоратися з цими проблемами? Відповідь — це шифрування: користувач спочатку обирає, які кодові агенти включати, які папки проєкту, часовий період тощо, і генерується пакет (зверніть увагу, що цей пакет знаходиться у канонічному форматі, у який Cass внутрішньо конвертує всі повідомлення агента кодування з їхніх оригінальних рідних форматів), а потім користувач надає пароль для шифрування цього набору. Ідея в тому, що хоча репозиторій і веб-сторінка є публічними, усі, крім вас і тих, кому ви даєте пароль, просто побачать поле пароля і не зможуть прочитати жодне повідомлення. Після введення пароля відкривається красивий, чутливий інтерфейс, який дозволяє легко шукати повідомлення майже так само швидко і ефективно, як це робить Касс. А якщо вам справді нема чого приховувати, можна залишити пароль відкритим і зробити все публічним. ...