Publication and Redaction Policy

Обновлено: 2026-07-16

Зачем публиковать рендер

Публичный рендер playbook делает правила понятными и проверяемыми. Команда показывает не репозиторий и историю внутренних обсуждений, а безопасный результат: как сформулировать outcome, создать SDD, довести vertical slice и предъявить evidence.

Публичный сайт помогает:

• объяснить качество работы заказчику и кандидату;
• получать внешнюю критику и улучшения;
• быстрее подключать нового человека или агента;
• отделить повторяемый метод от закрытой реализации.

Исходный репозиторий, pull requests, промежуточные материалы и review history остаются приватными.

Что публикуется

• общие product, design, engineering и security principles;
• обезличенные workflow examples;
• SDD, ADR, memory bank и task templates;
• quality gates и verification patterns;
• принятые решения самого playbook.

Что остаётся приватным

• product-specific roadmap, backlog и коммерческие приоритеты;
• закрытые SDD, pricing experiments и customer contracts;
• source data, prompts и generated artifacts с ограниченными правами;
• credentials, cookies, private keys и local authentication details;
• internal hosts, server addresses и operational access instructions;
• customer, employee и partner personal data;
• incident details до завершения remediation;
• скриншоты закрытых кабинетов и непубличных интерфейсов.

Redaction gate

Перед публикацией примера:

1. Указать учебный outcome примера.
2. Заменить private project/customer names на нейтральные.
3. Удалить credentials, IDs, emails, internal URLs, IP и local paths.
4. Удалить private source text и copyrighted inputs без разрешения.
5. Свести pricing и business metrics к диапазону или вымышленным данным.
6. Проверить screenshots на tabs, notifications, account names и browser data.
7. Запустить make check.
8. Просмотреть staged diff как внешний читатель.

Если после обезличивания пример теряет смысл, он не публикуется.

Safe evidence

Публично можно показывать:

• структуру acceptance criteria;
• названия и итог тестов без private fixtures;
• sanitized screenshot публичного или demo UI;
• относительное улучшение без закрытых абсолютных metrics;
• ADR с нейтральным контекстом;
• ссылку на публичный release.

Нельзя выдавать отсутствие найденного regex-secret за полный security review. Автоматический audit — только последний страховочный слой после ручной редакции.