- Мульти-провайдер: 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>
88 lines
3.9 KiB
Markdown
88 lines
3.9 KiB
Markdown
# Buyer-style Q&A
|
||
|
||
Вопросы, которые реально задают на сделке. Использовать как подготовку к разговору или self-check.
|
||
|
||
---
|
||
|
||
## Q1. «Насколько проект зависит от одного человека?»
|
||
|
||
**Ответ:** Критические знания формализованы: архитектура, ключевые решения (ADR), инциденты и runbook задокументированы. Bus-factor оценивается как 1.5–2 и может быть снижен further без изменения кода.
|
||
|
||
---
|
||
|
||
## Q2. «Что здесь самое рискованное технически?»
|
||
|
||
**Ответ:** Основные риски осознаны и задокументированы:
|
||
|
||
- чувствительность LLM-планирования к некорректному вводу
|
||
- жёсткость PATCH/EDIT протокола
|
||
- desktop-ориентированная архитектура
|
||
|
||
Эти риски не скрыты и управляемы.
|
||
|
||
---
|
||
|
||
## Q3. «Что будет, если продукт начнут использовать не по назначению?»
|
||
|
||
**Ответ:** Границы использования явно описаны в `docs/LIMITS.md`. Сценарии вне design scope считаются unsupported и не маскируются.
|
||
|
||
---
|
||
|
||
## Q4. «Почему Rust и Tauri, а не Electron / Web?»
|
||
|
||
**Ответ:** Решение принято осознанно и зафиксировано в ADR-001:
|
||
|
||
- меньшая attack surface
|
||
- контроль над IO
|
||
- производительность
|
||
- строгие архитектурные границы
|
||
|
||
Цена — более высокая инженерная дисциплина, но это снижает долгосрочные риски.
|
||
|
||
---
|
||
|
||
## Q5. «Насколько безопасна работа с сетью и внешними данными?»
|
||
|
||
**Ответ:** Все сетевые операции централизованы и проходят через SSRF-safe модуль. Неконтролируемый сетевой доступ архитектурно запрещён. См. ADR-003.
|
||
|
||
---
|
||
|
||
## Q6. «Как вы предотвращаете регрессии?»
|
||
|
||
**Ответ:** Через golden traces, версионирование протоколов и обязательный CI. Изменения observable behavior без обновления тестов невозможны.
|
||
|
||
---
|
||
|
||
## Q7. «Есть ли скрытый техдолг?»
|
||
|
||
**Ответ:** Техдолг зафиксирован и осознан. Отсутствуют зоны «не трогать, потому что никто не знает как работает».
|
||
|
||
---
|
||
|
||
## Q8. «Сколько времени нужно новому владельцу, чтобы начать изменения?»
|
||
|
||
**Ответ:** Оценка: 3–5 рабочих дней для инженера с опытом Rust/Tauri до первого осмысленного изменения.
|
||
|
||
---
|
||
|
||
## Q9. «Можно ли развивать продукт дальше без переписывания?»
|
||
|
||
**Ответ:** Да. Архитектура предусматривает точки расширения:
|
||
|
||
- новые protocol versions
|
||
- новые research adapters
|
||
- альтернативные planners
|
||
|
||
---
|
||
|
||
## Q10. «Почему этот проект — актив, а не просто код?»
|
||
|
||
**Ответ:** Потому что:
|
||
|
||
- риски названы
|
||
- поведение детерминировано
|
||
- качество проверяется автоматически
|
||
- знания зафиксированы
|
||
|
||
Это снижает uncertainty — главный дисконт на сделках.
|