Teamleadable: от темы Case к личному knowledge hub
Довел первую публичную версию Teamleadable от аккуратной копии Astro-темы до связанного knowledge hub: опубликованы 3 кейса, 10 материалов, 7 решений, 1 статья и 1 встреча, очищен демо-слой, зафиксированы правила публикации и собран Telegram-first маршрут.
Обзор
Проект начался как осторожная доработка копии портфолио на Astro и теме Case. Завершенная граница этого кейса — первая публичная версия Teamleadable: статический сайт с безопасной русской публичной оболочкой, связанными кейсами, материалами, решениями, релизным handoff, приватным по умолчанию контентным процессом и измеримым маршрутом к Telegram.
Проблема
У шаблонного портфолио есть удобная структура, но мало собственной позиции. Если просто заменить тексты, сайт быстро начинает выглядеть как заполненная тема: есть страницы, но не видно системы мышления, правил публикации, границ приватности и связей между опытом, решениями и материалами.
Ограничения
- Работа велась в копии проекта, поэтому каждое изменение должно было быть небольшим, обратимым и проверяемым.
- Одна фича должна жить в одной ветке, с понятным коммитом и проверкой перед merge.
- Демо-контент Case нельзя было оставлять в публичных разделах как будто он реальный.
- Сайт не должен раскрывать секреты, приватные ссылки, внутренние детали клиентов или неподтвержденные метрики.
- Сложные функции вроде graph-view, тренажеров и автоматизированного деплоя нужно было отложить до стабилизации контента и продуктового направления.
Подход
Я вел продуктовую рамку и двигался от production hygiene к контентной архитектуре. Сначала были очищены метаданные, демо-контент, русификация и бренд-обвязка. Затем появились материалы, стандарт кейсов, стандарт решений, основа статического графа, рабочий план, релизный handoff, privacy notice, контур аналитики и реальные связи между разделами. AI-ассистент помогал с реализацией, проверками и черновиками, но приоритеты, safety-правила, финальные формулировки и решения фиксировались мной.
Ключевые решения
Сделать рабочий план источником правды
Без живого плана легко смешать дизайн, контент, инфраструктуру и идеи на потом. `docs/00-work-plan.md` задает порядок работ, правила безопасности, delivery-ритм и критерии, когда можно двигаться к следующей теме.
- Держать план в переписке
- Сразу заводить задачи в отдельном таск-трекере
Расширять Case theme постепенно, а не переписывать сайт с нуля
Astro, MDX и content collections уже давали хорошую основу для статического сайта. Постепенное расширение позволило выйти к публичной версии быстрее и не превратить работу в разработку собственной CMS.
- Собрать полностью кастомный сайт
- Оставить тему почти без изменений
Развести роли кейсов, материалов и решений
Кейсы отвечают за конкретный опыт, материалы — за переиспользуемые знания, решения — за контекст и trade-off'ы. Так сайт показывает не только результат, но и способ мышления.
- Публиковать все в блоге
- Держать только кейсы и контакты
Сначала запустить безопасную публичную версию, а сложные функции строить позже
Graph-view, поиск, тренажеры, CI и VPS полезны только тогда, когда они обслуживают реальную контентную модель и операционный процесс. Для первой версии важнее были чистый публичный слой, понятные маршруты, проверяемая сборка и отсутствие приватных утечек.
- Сделать graph-view как первую заметную фичу
- Сразу проектировать тренажеры без понятных учебных целей
- Сначала заняться VPS и автоматизацией деплоя
Стек
- Astro
- Case theme
- MDX
- Content Collections
- Git / GitHub
- PWA metadata
- SEO metadata
- GoatCounter
Результат и импакт
- 3 кейса: 1 завершенный и 2 в работеПубличные кейсы
- 10 практических материаловПубличные материалы
- 7 decision recordsПубличные решения
- 1 статья и 1 встречаПубличные публикации
- одна фича — одна веткаDelivery-ритм
Первая публичная версия Teamleadable доведена до состояния безопасного knowledge hub: демо-наследие убрано из публичного слоя, появились правила публикации, отдельные коллекции материалов и решений, связанные кейсы, русская публичная оболочка, релизный handoff, privacy notice, Telegram-first главная страница и подготовленный контур аналитики.
Выводы
- Личный профессиональный сайт становится убедительнее, когда показывает не только страницы, но и правила: что публикуется, что остается черновиком, как проверяются claims и как не раскрывается лишнее.
- Материалы, кейсы и решения лучше разделять по роли, иначе все превращается в блог без структуры.
- AI-ассистент полезен как ускоритель реализации и проверки, но приоритеты, безопасность и смысловые решения должны оставаться под контролем владельца сайта.
- Сложные визуальные функции стоит откладывать до момента, когда они обслуживают уже существующие связи в контенте.
Что считалось завершенной границей
Этот кейс не утверждает, что сайт “закончен навсегда”. Завершенный результат — первая публичная версия Teamleadable как профессионального knowledge hub.
В завершенную границу входило:
- убрать демо-наследие Case theme из публичного слоя;
- собрать русскую публичную оболочку с корректными метаданными, SEO, sitemap, robots, PWA-артефактами и 404;
- опубликовать безопасный набор контента: кейсы, материалы, решения, journey, writing, встречи, stack, contact и основу статического графа;
- зафиксировать правила публикации, роли кейсов, формат решений, evidence policy и safety-ограничения;
- сделать Telegram основным публичным маршрутом и оставить email вторичным каналом;
- подготовить релизный handoff, post-deployment checks, analytics notice и измеримый Telegram-first контур.
Что изменилось
До этой работы сайт был аккуратной копией темы, которую нельзя было спокойно считать личным публичным продуктом. В нем оставались риски: демо-контент, не до конца своя структура, слабая связь между разделами, неочевидные правила публикации и отсутствие явного продуктового направления.
После первой публичной итерации Teamleadable стал системой с понятными ролями:
- кейсы показывают работу, ограничения, решения и результат;
- материалы превращают повторяемый опыт в практические заметки;
- решения фиксируют trade-off’ы и последствия;
- рабочий план задает порядок развития и delivery-правила;
- Telegram стал основным каналом продолжения контакта после чтения сайта.
Публичные доказательства
В этом кейсе используются только proof-элементы, которые можно проверить по публичному репозиторию и содержанию сайта.
- Контентная база: 3 публичных кейса, 10 публичных материалов, 7 публичных решений, 1 публичная статья и 1 публичная встреча.
- Правила публикации:
docs/03-content/case-study-standard.md,docs/03-content/decision-record-standard.md,docs/03-content/evidence-policy.mdиdocs/03-content/content-guide.md. - Delivery-рамка:
docs/00-work-plan.md, changelog и последовательность маленьких feature-веток. - Релизная рамка:
docs/05-deployment/production-launch-handoff.md,docs/05-deployment/post-deployment.mdиdocs/05-deployment/production-readiness-audit.md. - Рамка измерений:
docs/05-deployment/analytics-measurement.md, публичная/privacy/notice и Telegram-ссылки по источникам в публичной env-схеме.
Моя роль
Я держал продуктовую рамку: что сайт должен говорить обо мне, какие разделы нужны до публикации, какие идеи стоит отложить и какие правила безопасности обязательны. AI-ассистент помогал читать код, предлагать изменения, писать черновики и проверять сборку, но каждое направление фиксировалось через рабочий план и подтверждение перед изменениями.
Для меня это близко к системному анализу: сначала определить границы, участников, ограничения и риски, затем постепенно уточнять модель и доставлять изменения маленькими проверяемыми шагами.
Что стало основой для следующих итераций
После этой работы у сайта появилась рамка для развития:
- рабочий план как источник актуальных приоритетов;
- draft-режим для незрелого контента;
- материалы как практическая база знаний;
- кейсы со стандартом роли, безопасности и impact;
- решения как журнал trade-off’ов;
- evidence policy для claims, метрик и supporting artifacts;
- cross-links между разделами;
- Telegram-first главная страница и измеримые переходы к каналу;
- отложенные более сложные функции, которые стоит строить только после данных о поведении читателей.
Что осталось следующей итерацией
Завершенная граница первой публичной версии не закрывает развитие продукта. Следующие шаги уже относятся к новой итерации: снять baseline после переезда хостинга и включения публичных build-time значений, создать маршруты по материалам, описать процесс публикации от сайта к Telegram, улучшить информационную архитектуру и добавлять следующие завершенные кейсы только с безопасными доказательствами.