mirror of
https://github.com/rennf93/roboco.git
synced 2026-08-03 07:23:24 +02:00
172 lines
4.7 KiB
Markdown
172 lines
4.7 KiB
Markdown
---
|
|
|
|
# CEO Directive: API-First Architecture Initiative
|
|
|
|
**From:** CEO
|
|
**To:** Board (Product Owner, Head of Marketing, Auditor)
|
|
**Priority:** High
|
|
**Date:** 2024-12-23
|
|
|
|
---
|
|
|
|
## Strategic Context
|
|
|
|
We're positioning RoboCo for a two-phase growth strategy:
|
|
|
|
**Phase B (Now):** Two products, one backend. RoboCo Panel (full experience) and Codepanion (lightweight CLI, open source). Both consume the same API.
|
|
|
|
**Phase C (Future):** Platform play. The orchestration API becomes the product. Third parties build on us.
|
|
|
|
For this to work, **the API must be the only way in.** No backdoors. No direct DB access from frontends. No "just this once" shortcuts.
|
|
|
|
If we can't use our own API to build our own products, no one else can either.
|
|
|
|
---
|
|
|
|
## Objective
|
|
|
|
**Establish API-first architecture across the entire system.**
|
|
|
|
This means:
|
|
1. Every action the Panel takes goes through the public API
|
|
2. Every action Codepanion will take goes through the public API
|
|
3. Internal services communicate through well-defined interfaces
|
|
4. The API is documented, consistent, and pleasant to use
|
|
|
|
---
|
|
|
|
## Success Criteria
|
|
|
|
- [ ] Zero direct database access from Panel frontend
|
|
- [ ] Zero direct core imports that bypass API in frontend code
|
|
- [ ] Codepanion can connect and perform basic operations (create session, send message, retrieve history)
|
|
- [ ] API documentation covers all endpoints Codepanion needs
|
|
- [ ] Auditor has verified no backdoors remain in critical paths
|
|
|
|
---
|
|
|
|
## Board Responsibilities
|
|
|
|
### Product Owner
|
|
|
|
1. **Define the API contract** for Codepanion integration
|
|
- What endpoints does Codepanion need?
|
|
- What's the minimal surface area?
|
|
- What can wait for v2?
|
|
|
|
2. **Prioritize the cleanup work**
|
|
- Which backdoors are blockers vs. nice-to-have?
|
|
- What's the MVP for "API-first"?
|
|
|
|
3. **Approve the architecture decisions**
|
|
- Review proposals from Main PM
|
|
- Sign off on API design
|
|
|
|
### Head of Marketing
|
|
|
|
1. **Prepare positioning for Codepanion**
|
|
- Open source CLI angle
|
|
- "Works standalone, better connected" messaging
|
|
- Developer-first tone
|
|
|
|
2. **Draft initial README/landing content**
|
|
- What does Codepanion do?
|
|
- Why would a dev use it?
|
|
- How does it connect to RoboCo?
|
|
|
|
3. **Identify launch channels**
|
|
- Where do we announce?
|
|
- What's the content calendar?
|
|
|
|
### Auditor
|
|
|
|
1. **Conduct the backdoor audit**
|
|
- Review all frontend → backend communication
|
|
- Flag every direct DB access
|
|
- Flag every import that bypasses API layer
|
|
- Produce audit report with file, line, severity
|
|
|
|
2. **Verify fixes**
|
|
- After cleanup, re-audit critical paths
|
|
- Confirm API-first compliance
|
|
|
|
3. **Establish ongoing monitoring**
|
|
- How do we prevent new backdoors?
|
|
- What checks should be part of code review?
|
|
|
|
---
|
|
|
|
## Deliverables to Main PM
|
|
|
|
Once board alignment is complete, hand off to Main PM:
|
|
|
|
1. **Audit Report** (from Auditor)
|
|
- List of all backdoors with severity ratings
|
|
|
|
2. **API Specification** (from Product Owner)
|
|
- Endpoints needed for Codepanion MVP
|
|
- Request/response schemas
|
|
- Authentication approach
|
|
|
|
3. **Prioritized Task List** (from Product Owner)
|
|
- Ordered by: blockers first, then high-value, then nice-to-have
|
|
|
|
4. **Marketing Brief** (from Head of Marketing)
|
|
- Positioning document for Codepanion
|
|
- README draft
|
|
- Launch plan outline
|
|
|
|
---
|
|
|
|
## Constraints
|
|
|
|
- **Timeline:** Codepanion MVP should be shippable within 2 weeks of Main PM receiving handoff
|
|
- **Scope:** Fix what's necessary for Codepanion. Don't boil the ocean.
|
|
- **Principle:** If in doubt, expose it through API. We'd rather have a slightly larger API surface than hidden backdoors.
|
|
|
|
---
|
|
|
|
## Notes on Documentation
|
|
|
|
For now:
|
|
- Task documentation lives in the task's session (tied via session-task link)
|
|
- Technical documentation (API docs, architecture) should be markdown in the repo
|
|
- User-facing documentation (README, guides) prepared by Documenter roles, reviewed by PM
|
|
|
|
Future consideration: dedicated documentation system. But not now.
|
|
|
|
---
|
|
|
|
## Notes on Git Integration
|
|
|
|
Git integration is coming. For this initiative:
|
|
- All code changes go through PRs
|
|
- PRs link to task IDs in commit messages
|
|
- Once git integration lands, this becomes automated
|
|
|
|
For now, manual discipline.
|
|
|
|
---
|
|
|
|
## Communication
|
|
|
|
- Board discussions in `management` channel
|
|
- Main PM coordination in `cross-cell` channel
|
|
- Cell work in respective cell channels (`backend-cell`, `frontend-cell`, `uxui-cell`)
|
|
- Each task gets its own session within the appropriate channel
|
|
- Journals capture decisions, learnings, blockers
|
|
|
|
---
|
|
|
|
## Final Word
|
|
|
|
This is the foundation. If we get API-first right, everything else becomes easier — Codepanion, platform expansion, third-party integrations, even our own Panel development.
|
|
|
|
If we get it wrong, we're building on sand.
|
|
|
|
Make it solid.
|
|
|
|
---
|
|
|
|
**CEO**
|