65e95a458d
- Мульти-провайдер: 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>
165 lines
4.6 KiB
Markdown
165 lines
4.6 KiB
Markdown
# Technical Investment Memo — papa-yu
|
||
|
||
## 1. Executive Summary
|
||
|
||
papa-yu is a desktop application built with Tauri and Rust, designed to orchestrate LLM-driven workflows involving structured file editing (PATCH/EDIT) and controlled external research.
|
||
|
||
The project demonstrates a high level of technical maturity:
|
||
|
||
- deterministic behavior enforced via protocol versioning and golden traces
|
||
- strong CI/CD quality gates
|
||
- explicit security controls around network access (SSRF-safe design)
|
||
- clear separation between UI, domain logic, and IO
|
||
|
||
The codebase is maintainable, testable, and transferable with moderate onboarding effort. No critical technical blockers for further development or transfer of ownership were identified.
|
||
|
||
---
|
||
|
||
## 2. Product Overview (Technical Perspective)
|
||
|
||
### Purpose
|
||
|
||
The system automates and orchestrates complex workflows driven by LLM output, with a focus on reproducibility, safety, and long-term maintainability.
|
||
|
||
### Target usage
|
||
|
||
- Desktop environments
|
||
- Controlled workloads (non–real-time, non–high-concurrency)
|
||
- Users requiring deterministic behavior over flexibility
|
||
|
||
### Explicit non-goals
|
||
|
||
- Server-side, high-concurrency workloads
|
||
- Real-time processing
|
||
- Execution of untrusted plugins
|
||
|
||
(See `docs/LIMITS.md` for details.)
|
||
|
||
---
|
||
|
||
## 3. Architecture Overview
|
||
|
||
### High-level design
|
||
|
||
- Desktop application using Tauri
|
||
- Core logic implemented in Rust
|
||
- UI is a thin client without direct filesystem or network access
|
||
|
||
### Key architectural principles
|
||
|
||
- All IO is centralized and controlled
|
||
- Domain logic is isolated from side effects
|
||
- Observable behavior is locked via golden traces
|
||
|
||
### Core modules
|
||
|
||
- `net` — single entry point for outbound network access with SSRF protection
|
||
- `llm_planner` — orchestration and planning logic
|
||
- `online_research` — external data integration via safe adapters
|
||
- `commands/*` — Tauri boundary layer
|
||
|
||
Architecture documentation is available in `docs/ARCHITECTURE.md`.
|
||
|
||
---
|
||
|
||
## 4. Code Quality and Testing
|
||
|
||
### Testing strategy
|
||
|
||
- >100 automated tests
|
||
- Golden traces for protocol versions v1, v2, v3
|
||
- Regression detection is enforced in CI
|
||
|
||
### CI/CD
|
||
|
||
- Formatting and linting enforced (`cargo fmt`, `clippy`)
|
||
- Automated test execution
|
||
- Dependency vulnerability scanning (`cargo audit`)
|
||
- Reproducible builds from a clean checkout
|
||
|
||
The CI pipeline serves as a hard quality gate.
|
||
|
||
---
|
||
|
||
## 5. Security Posture (Design & Code Level)
|
||
|
||
Security is addressed at the architectural level:
|
||
|
||
- Centralized network access via `net::fetch_url_safe`
|
||
- SSRF mitigations:
|
||
- scheme allowlist (http, https)
|
||
- denial of private/loopback IP ranges
|
||
- request size limit (1 MB)
|
||
- timeout (15 seconds)
|
||
- No secrets stored in the repository
|
||
- Dependency vulnerability scanning in CI
|
||
|
||
**Scope limitation:**
|
||
|
||
- No penetration testing performed
|
||
- Security review limited to design and code analysis
|
||
|
||
(See `docs/adr/ADR-003-ssrf.md` for rationale.)
|
||
|
||
---
|
||
|
||
## 6. Dependencies and Supply Chain
|
||
|
||
- Dependencies are locked via `Cargo.lock` and `package-lock.json`
|
||
- Automated vulnerability scanning is enabled
|
||
- Planned addition: license policy enforcement via `cargo deny`
|
||
|
||
No known blocking license risks identified at this stage.
|
||
|
||
---
|
||
|
||
## 7. Operational Maturity
|
||
|
||
- Project can be built and run via documented steps
|
||
- Common failure modes are documented in `docs/INCIDENTS.md`
|
||
- Deterministic behavior simplifies debugging and reproduction
|
||
- Runbook documentation (`docs/RUNBOOK.md`) provides basic operational guidance
|
||
|
||
---
|
||
|
||
## 8. Known Risks and Technical Debt
|
||
|
||
Known risks are explicitly documented:
|
||
|
||
- Sensitivity of LLM planning to malformed input
|
||
- Rigid PATCH/EDIT protocol trade-offs
|
||
- Desktop-centric architecture limits scalability
|
||
|
||
Technical debt is tracked and intentional where present. No unbounded or hidden debt has been identified.
|
||
|
||
---
|
||
|
||
## 9. Roadmap (Technical)
|
||
|
||
### Short-term
|
||
|
||
- License policy enforcement (`cargo deny`)
|
||
- Further documentation hardening
|
||
|
||
### Mid-term
|
||
|
||
- Reduction of bus-factor through onboarding exercises
|
||
- Optional expansion of test coverage in edge cases
|
||
|
||
### Long-term
|
||
|
||
- Additional protocol versions
|
||
- New research adapters via existing extension points
|
||
|
||
---
|
||
|
||
## 10. Transferability Assessment
|
||
|
||
From a technical perspective:
|
||
|
||
- The system is explainable within days, not weeks
|
||
- No single undocumented "magic" components exist
|
||
- Ownership transfer risk is considered low to moderate
|
||
|
||
Overall technical readiness supports both continued independent development and potential acquisition.
|