sayan
eeb684b46c
#38 Ipad app production readiness, Colony orchestration, Social posting Co-authored-by: Sayan Datta <sayan@Sayans-MacBook-Air.local> Reviewed-on: #44
4.2 KiB
Introduction for Sayan_ Multi-Surface Platform and Oracle Expansion
Date: 2026-04-16
Status: Team onboarding artifact
Primary Reader: Sayan
Purpose: Provide one entry point into the multi-surface expansion work so you can understand what this project is, where it lives, what already exists, and how to approach it without causing architectural drift.
1. What This Project Is
This project is the next product expansion layer for Project Velocity.
It is not a greenfield app exercise. It is not a mobile hack sprint. It is not a backend rewrite.
It is a structured effort to extend the current Velocity product into:
- a completed iPad field app
- an Android tablet equivalent
- a narrow iPhone edge app
- a narrow Android phone edge app
- a communication-memory and calendar loop for assigned office phones
- a broader Oracle schema and template system
- an inventory loading pipeline
- an admin control plane
2. What Already Exists
The current repo already has real centers of gravity:
- WebOS frontend in
Project_Velocity/app/ - FastAPI backend in
Project_Velocity/backend/ - native iPad app foundation in
Project_Velocity/iOS/velocity/velocity/ - Oracle route and schema direction in
Project_Velocity/backend/oracle/ - inventory seed assets in
Project_Velocity/db assets/Inventory/
This means your job is integration-first.
3. Architectural Truth You Should Assume
Assume these decisions are already closed:
- FastAPI backend remains canonical.
- Oracle remains the current analytical center.
- iPad is the tablet reference implementation.
- Android tablet should mirror iPad structure rather than inventing a new product model.
- Phone edge apps are narrow control and capture surfaces, not full WebOS clones.
- Template catalog and inventory data must live under current backend ownership.
- Admin control must be bounded and auditable.
- Communication memory is a first-class product outcome, but capture must follow supported channels and approved imports.
- Sprint 1 communication scope is centered on cellular calls, WhatsApp messages, WhatsApp voice calls, and calendar-driven follow-up.
4. Why This Work Matters
Right now Velocity has asymmetry:
- WebOS is broad
- iPad is partial but real
- Android tablet is absent
- phone edge surfaces are absent
- Oracle template strategy is incomplete
- inventory ingestion is not yet normalized
- admin operations are too diffuse
If those remain unresolved, the product stays harder to deploy, demo, and scale.
5. Where To Focus First
The highest-value docs for you are:
- Sayan Work Assignment_ Multi-Surface Platform and Oracle Expansion.md
- Sayan Work Assignment_ Sprint 1 Execution Slice.md
- 14 - Platform Reality and Communications Capture Strategy.md
- 05 - Implementation Blueprint_ Multi-Surface Apps WebOS Edge and Oracle Delivery.md
- 09 - Oracle Schema and Root API Spec_ Multi-Surface Platform.md
- 07 - Contracts and JSON Schemas_ Templates Inventory Edge Capture.md
- 13 - Implementation Ticket Breakdown and Dependency Matrix_ Multi-Surface Platform.md
6. What You Must Not Do
- do not create a second backend authority
- do not create a second schema center
- do not assume unsupported mobile call or message capture paths
- do not confuse "critical feature" with "unsupported direct OS interception"
- do not build merge-hostile broad rewrites
- do not treat phone edge apps as mini WebOS copies
7. Bottom Line
Your task is to make the current Velocity product more complete across tablets, phones, Oracle data assets, and admin operations without breaking the current root.