- Мульти-провайдер: PAPAYU_LLM_PROVIDERS — сбор планов от нескольких ИИ (Claude, OpenAI), агрегация - Тренды дизайна и иконок: вкладка в модалке, поиск по безопасным доменам (Tavily include_domains) - Snyk Code: PAPAYU_SNYK_SYNC, REST API issues → snyk_findings в agent-sync - Documatic: architecture_summary из .papa-yu/architecture.md в agent-sync - Личная автоматизация: capability personal-automation (терминал git/npm/cargo, открытие URL) - agent_sync расширен: snyk_findings, architecture_summary; analyze_project_cmd и run_batch пишут sync - Документация: SNYK_AND_DOCUMATIC_SYNC.md, SECURITY_AND_PERSONAL_AUTOMATION.md, обновлён CLAUDE_AND_AGENT_SYNC Co-authored-by: Cursor <cursoragent@cursor.com>
113 lines
4.0 KiB
Markdown
113 lines
4.0 KiB
Markdown
# Checklist готовности papa-yu к продаже (Tech Due Diligence)
|
||
|
||
Самопроверка владельца или база для внешнего DD.
|
||
|
||
---
|
||
|
||
## A. Продукт и назначение
|
||
|
||
- [ ] Чётко описано, **что делает продукт** и **для кого**
|
||
- [ ] Определены **ключевые сценарии**
|
||
- [ ] Явно указано, **что продукт НЕ делает** (`LIMITS.md`)
|
||
- [ ] Понятно, что считается **Critical отказом**
|
||
|
||
👉 Если этого нет — покупатель будет сам додумывать (и занизит оценку).
|
||
|
||
---
|
||
|
||
## B. Архитектура
|
||
|
||
- [ ] Есть `ARCHITECTURE.md` с актуальной схемой
|
||
- [ ] Чётко разделены слои (domain / services / adapters / UI)
|
||
- [ ] Нет скрытых «магических» зависимостей
|
||
- [ ] Есть ADR для дорогих решений
|
||
|
||
**Red flag:** архитектура «читается только из кода».
|
||
|
||
---
|
||
|
||
## C. Качество кода
|
||
|
||
- [ ] Единый стиль и правила
|
||
- [ ] Нет систематического дублирования
|
||
- [ ] Ограничена сложность функций
|
||
- [ ] Ошибки обрабатываются консистентно
|
||
|
||
**Важно:** не идеальность, а **предсказуемость**.
|
||
|
||
---
|
||
|
||
## D. Тестирование
|
||
|
||
- [ ] Есть автоматические тесты
|
||
- [ ] Критические сценарии покрыты
|
||
- [ ] Тесты запускаются в CI
|
||
- [ ] Golden tests / regression tests фиксируют поведение
|
||
|
||
**Red flag:** «тесты есть, но мы им не доверяем».
|
||
|
||
---
|
||
|
||
## E. CI/CD и релизы
|
||
|
||
- [ ] Проект собирается с нуля одной командой
|
||
- [ ] CI — обязательный gate
|
||
- [ ] Есть воспроизводимые релизы
|
||
- [ ] Понятно, как откатиться
|
||
|
||
**Green flag:** новый владелец может выпустить релиз без автора.
|
||
|
||
---
|
||
|
||
## F. Security (design & code level)
|
||
|
||
- [ ] Нет секретов в репозитории
|
||
- [ ] Контролируем сетевой доступ (fetch/SSRF)
|
||
- [ ] Зависимости проверяются (audit/deny)
|
||
- [ ] Есть краткое описание threat model
|
||
|
||
**Red flag:** «мы не думали о security, потому что это desktop».
|
||
|
||
---
|
||
|
||
## G. Зависимости и лицензии
|
||
|
||
- [ ] Lock-файлы в репозитории
|
||
- [ ] Понятен список лицензий
|
||
- [ ] Нет критичных GPL/AGPL сюрпризов (если нежелательны)
|
||
- [ ] Нет abandoned-зависимостей без плана
|
||
|
||
---
|
||
|
||
## H. Эксплуатация
|
||
|
||
- [ ] Есть `RUNBOOK.md`
|
||
- [ ] Известны типовые проблемы и обходы
|
||
- [ ] Есть `INCIDENTS.md` (даже минимальный)
|
||
- [ ] Логи и базовые метрики доступны
|
||
|
||
**Green flag:** проблемы задокументированы, а не «в головах».
|
||
|
||
---
|
||
|
||
## I. Bus-factor и передача
|
||
|
||
- [ ] Проект можно передать без автора
|
||
- [ ] Документы объясняют «почему», а не только «как»
|
||
- [ ] Нет «не трогай это» зон без объяснений
|
||
|
||
---
|
||
|
||
## Итог по checklist
|
||
|
||
| Процент | Интерпретация |
|
||
|---------|---------------|
|
||
| >80% | investment-ready |
|
||
| 60–80% | продаваем с дисконтом |
|
||
| <60% | «project», а не «asset» |
|
||
|
||
---
|
||
|
||
> **Оценка papa-yu:** ~87% (investment-ready) — см. `docs/INVESTMENT_READY_REPORT.md`
|
||
> Предыдущая: ~63% — `docs/DUE_DILIGENCE_ASSESSMENT.md`
|