feat: implement visual UI builder, multi-device Android app, Ktor routing sync, and product roadmaps
This commit is contained in:
48
business/product_roadmap.md
Normal file
48
business/product_roadmap.md
Normal file
@@ -0,0 +1,48 @@
|
||||
# WhetForge: High-Level Product Roadmap
|
||||
|
||||
This document outlines the core product milestones, release phases, and sprint mappings for the generic **Lite-Client Platform & Marketplace**.
|
||||
|
||||
---
|
||||
|
||||
## 1. High-Level Release Phases
|
||||
|
||||
```
|
||||
+-----------------------------------------------------------------------------------+
|
||||
| PHASE 1: CLIENT AND BUILDER SOLIDIFICATION (Month 1) |
|
||||
| Focus: Core hardware shells (watches, phones) and responsive visual layout editor.|
|
||||
| Sprints: Sprint 1 (Polish) and Sprint 2 (Responsive Builder) |
|
||||
+-----------------------------------------------------------------------------------+
|
||||
|
|
||||
v
|
||||
+-----------------------------------------------------------------------------------+
|
||||
| PHASE 2: INTEGRATION AND ROUTING ENGINE (Month 2) |
|
||||
| Focus: Local server synchronization, SQLite caching, and API/MCP schemas. |
|
||||
| Sprints: Sprint 3 (Local Sync) and Sprint 4 (Marketplace Core) |
|
||||
+-----------------------------------------------------------------------------------+
|
||||
|
|
||||
v
|
||||
+-----------------------------------------------------------------------------------+
|
||||
| PHASE 3: COMMERCE AND MONETIZATION (Month 3) |
|
||||
| Focus: Stripe billing, mobile In-App Purchases, and public beta release. |
|
||||
| Sprints: Sprint 5 (Payments) and Sprint 6 (Store Deployment & Launch) |
|
||||
+-----------------------------------------------------------------------------------+
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 2. Sprint Roadmap Overview
|
||||
|
||||
* **Sprint 0: Naming & Branding (Data-Driven UX Design)**
|
||||
* Run UX research prompt, select product name, verify domains, establish brand style guide (color palette, typography tokens, tagline options).
|
||||
* **Sprint 1: Native Wearable & Mobile Polish**
|
||||
* Hardware performance validation, smartwatch AOD optimization, background WebSocket connection reliability, and haptic overrides.
|
||||
* **Sprint 2: Builder Porting & Responsive Design**
|
||||
* Migrate visual editor to `:commonMain`. Design the responsive split-screen phone view. Implement **Developer Mode (Tabs)** and **Easy Mode (Wizard)**.
|
||||
* **Sprint 3: Local Sync API & Database Caching**
|
||||
* Store JSON configurations locally in SQLite database on Ktor local backend. Connect CLI script to support rendering layouts by ID.
|
||||
* **Sprint 4: Marketplace Backend & Authentication**
|
||||
* Initialize the `:marketplace` module. Set up PostgreSQL and Exposed ORM schemas. Implement secure JWT user account authentication.
|
||||
* **Sprint 5: Billing & Stripe Integration**
|
||||
* Configure Stripe Checkout on the marketplace. Build Stripe Webhook receiver to unlock purchased profiles.
|
||||
* **Sprint 6: In-App Purchases & Beta Release**
|
||||
* Integrate Google Play Billing and Apple StoreKit. Publish Lite-Client Shells to the official app stores. Launch the "Meatbag" reference app.
|
||||
166
business/sprint_specifications.md
Normal file
166
business/sprint_specifications.md
Normal file
@@ -0,0 +1,166 @@
|
||||
# WhetForge: Detailed Sprint Specifications
|
||||
|
||||
This document outlines the objectives, tasks, and acceptance criteria for all sprints in the WhetForge Lite-Client & Marketplace development timeline.
|
||||
|
||||
---
|
||||
|
||||
## Sprint 0: Naming & Branding (Data-Driven UX Design)
|
||||
|
||||
### Objectives
|
||||
Select a highly compelling, developer-friendly brand name and visual identity for the generic Lite-Client Platform and Marketplace. Use data-driven research to evaluate name options based on brand recall, developer trust, and clarity of purpose.
|
||||
|
||||
### Task List
|
||||
1. **Run the Naming UX Research**: Execute the Deep Research prompt (found below) to analyze name categories and semantic viability.
|
||||
2. **Shortlist and Domain Search**: Narrow down to 3 final name candidates and verify domain availability (.dev, .app, .com) and App Store search conflicts.
|
||||
3. **Design System Tokens**: Define the core color palette (cyberpunk/modern contrast), custom Google Font pairing (Inter/Outfit), and rounded corner token rules.
|
||||
4. **Product Branding Copy**: Write the marketplace landing page header, tagline, and value proposition statement.
|
||||
|
||||
### Acceptance Criteria
|
||||
* A final, trademark-clear name is selected.
|
||||
* Domain names and social handles are acquired or reserved.
|
||||
* A core visual style guide (palette, typography, logo guidelines) is established.
|
||||
|
||||
---
|
||||
|
||||
### Gemini Deep Research Prompt: Naming & Branding UX Report
|
||||
Copy and paste this prompt into Gemini Deep Research to generate a data-driven naming and branding analysis:
|
||||
|
||||
```text
|
||||
Please perform a comprehensive UX Research and Branding Assessment to determine the optimal brand name and visual identity for a new developer platform.
|
||||
|
||||
### 1. Product Description
|
||||
- The product is a generic, developer-facing Server-Driven UI (SDUI) "Lite-Client" platform and marketplace.
|
||||
- It allows developers to build native smartwatch (Wear OS/watchOS), mobile, and TV dashboard widgets using a drag-and-drop builder which exports to serialized JSON configs.
|
||||
- The parent business is called "WhetForge". The first reference application built on it is called "Meatbag" (satirical haptic AI agent approval manager).
|
||||
- The marketplace and platform need a standalone name that is clean, professional, developer-focused, and less edgy than "Meatbag".
|
||||
|
||||
### 2. Naming Research Tasks
|
||||
- **Semantic Mapping**: Analyze name candidates in three distinct semantic categories:
|
||||
1. *Action/Utility-focused* (e.g., DashCast, ShellPress, Viewport, Panelist).
|
||||
2. *Metaphorical/Technical* (e.g., Canvas, Blueprint, Outline, GridForge, Castway).
|
||||
3. *Short/Abstract* (e.g., Velo, Koda, Shell, Outlay).
|
||||
- **Competitor Analysis**: Evaluate naming strategies of adjacent platforms (e.g., Raycast, Retool, Expo, FlutterFlow, Home Assistant, n8n). What linguistic patterns (e.g., suffix, compound word, portmanteau) command the highest trust among developers?
|
||||
- **Developer Psychological Sentiment**: Research what types of names rank highest for developer trust, open-source alignment, and ease of pronunciation.
|
||||
- **Search Engine Optimization (SEO)**: Highlight potential keyword conflicts, search term dilution, and target domain acquisition strategies.
|
||||
|
||||
### 3. Visual & UX Branding Tasks
|
||||
- Analyze color psychology trends in modern developer tooling (e.g., the rise of dark modes, high-contrast neon accents like teal/purple, glassmorphism). Recommend 3 distinct color palettes with hex codes.
|
||||
- Recommend modern font pairings (headers and body) that optimize readability on tiny smartwatch screens and large TV screens.
|
||||
|
||||
### 4. Required Deliverables
|
||||
1. **Top 5 Name Recommendations**: With semantic explanations, developer-trust ratings, and trademark feasibility.
|
||||
2. **Linguistic Competitor Map**: Visualization of adjacent developer tools' naming structures.
|
||||
3. **3 Visual Identity Palettes**: Complete with colors, fonts, and layout recommendations.
|
||||
4. **Tagline Generation**: 5 potential taglines for the developer-facing marketplace homepage.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Sprint 1: Native Wearable & Mobile Polish
|
||||
|
||||
### Objectives
|
||||
Optimize the stateless client shells on physical Android S23 Ultra and Wear OS Watch7 devices for battery efficiency, haptic response, and connection reliability.
|
||||
|
||||
### Task List
|
||||
1. **Background Connection Handler**: Implement persistent background heartbeat sockets to prevent connection drops when screens turn off.
|
||||
2. **Haptic Profile Configurations**: Calibrate physical vibration patterns on the Galaxy Watch7 for the four attention tiers (Silent, Low, Medium, High).
|
||||
3. **Smartwatch Always-On Display (AOD)**: Implement ambient mode callbacks to auto-convert active layouts to low-power desaturated views.
|
||||
4. **Physical Touch Targets**: Adjust button heights and margins in `MeatbagComponentHost` specifically for round watch screens to prevent layout clipping.
|
||||
|
||||
### Acceptance Criteria
|
||||
* The app successfully maintains connection for 1+ hour in background mode on S23 Ultra.
|
||||
* Smartwatch haptics trigger unique, distinct vibration patterns for different alert tiers.
|
||||
* The client shell automatically changes themes when the watch enter AOD/ambient mode.
|
||||
|
||||
---
|
||||
|
||||
## Sprint 2: Builder Porting & Responsive Design
|
||||
|
||||
### Objectives
|
||||
Port the visual editor layout screen from the desktop simulator to the shared code module and design the mobile-responsive phone view.
|
||||
|
||||
### Task List
|
||||
1. **Common Code Migration**: Move `UIBuilderScreen` from `:client/desktopMain` to `:client/commonMain`.
|
||||
2. **Responsive Screen Detection**: Use `BoxWithConstraints` to detect viewport width and branch layouts between Mobile and Desktop.
|
||||
3. **Mobile Layout Builder**: Implement `MobileUIBuilderLayout` utilizing a split-pane layout: Watch Preview on top, Editor card on the bottom.
|
||||
4. **Developer Mode (Tabs)**: Expose the tabbed properties forms inside the mobile editor card.
|
||||
5. **Easy Mode (Wizard)**: Build a guided step-by-step assistant for quick layout generation.
|
||||
6. **Layout Mode Toggle**: Add a header switch in the builder UI to transition between Developer and Easy modes.
|
||||
|
||||
### Acceptance Criteria
|
||||
* The visual builder renders and operates correctly on both desktop and mobile screen sizes.
|
||||
* Toggling between Developer (Tabs) and Easy (Wizard) modes instantly restructures the property configuration controls.
|
||||
* Output JSON matches the shared serialization schema.
|
||||
|
||||
---
|
||||
|
||||
## Sprint 3: Local Sync API & Database Caching
|
||||
|
||||
### Objectives
|
||||
Connect the local Ktor server to support local profile caching, enabling layouts to load dynamically from the local database.
|
||||
|
||||
### Task List
|
||||
1. **SQLite Database Update**: Add a `profiles` table to the local `meatbag.db` storing layout ID, layout JSON, and sync timestamp.
|
||||
2. **Ktor Sync API**: Build the `/api/profiles/sync` POST endpoint to ingest visual configurations from the builder and write them to SQLite.
|
||||
3. **Local Layout Loader**: Implement lookup logic in the shell client to dynamically resolve and render profiles cached in the local database.
|
||||
4. **CLI Integration**: Update `meatbag.py ask` to support requesting a layout by ID (e.g. `python meatbag.py ask --profile git_commit`).
|
||||
|
||||
### Acceptance Criteria
|
||||
* Syncing from the visual builder correctly saves the JSON config to the local SQLite database.
|
||||
* The client shell can load and draw cached layouts on the fly without web browser execution.
|
||||
* The CLI tool can trigger complex layouts via profile IDs instead of raw text prompts.
|
||||
|
||||
---
|
||||
|
||||
## Sprint 4: Marketplace Backend & Authentication
|
||||
|
||||
### Objectives
|
||||
Launch the centralized global marketplace server using Ktor and Postgres to handle developer registrations and profile uploads.
|
||||
|
||||
### Task List
|
||||
1. **Marketplace Module Setup**: Initialize the `:marketplace` module in the Gradle configuration.
|
||||
2. **Postgres Database Schema**: Define database tables using Kotlin Exposed ORM (Users, Developer Profiles, Marketplace Layouts, Purchases).
|
||||
3. **JWT Authentication**: Integrate `ktor-auth-jwt` to handle user signups, logins, and API token generation.
|
||||
4. **Upload Endpoint**: Implement `POST /api/v1/marketplace/publish` allowing developers to upload JSON layouts directly from the visual builder.
|
||||
5. **Search API**: Implement `GET /api/v1/marketplace/profiles` enabling clients to browse available templates.
|
||||
|
||||
### Acceptance Criteria
|
||||
* Users can sign up, log in, and receive secure JWT tokens.
|
||||
* Developers can publish layouts from the builder directly to the global marketplace database.
|
||||
* Layout schemas are validated on the server side prior to saving.
|
||||
|
||||
---
|
||||
|
||||
## Sprint 5: Billing & Stripe Integration
|
||||
|
||||
### Objectives
|
||||
Integrate Stripe Checkout and webhooks to monetize layout profiles on the web store.
|
||||
|
||||
### Task List
|
||||
1. **Stripe SDK Configuration**: Configure the Stripe Java SDK on the marketplace server.
|
||||
2. **Stripe Checkout API**: Implement `/api/v1/checkout/session` to generate payment links for premium layouts.
|
||||
3. **Stripe Webhook Listener**: Build `/api/v1/webhooks/stripe` to handle asynchronous charge events and record successful purchases.
|
||||
4. **Purchase Model**: Implement the purchases verification table in PostgreSQL mapping user accounts to purchased profile IDs.
|
||||
|
||||
### Acceptance Criteria
|
||||
* Tapping purchase on the web store successfully redirects to a secure Stripe Checkout session.
|
||||
* Completing payment triggers the Stripe Webhook, writing the transaction to Postgres.
|
||||
* User account instantly gains access to the purchased profile.
|
||||
|
||||
---
|
||||
|
||||
## Sprint 6: In-App Purchases & Beta Release
|
||||
|
||||
### Objectives
|
||||
Integrate native mobile billing libraries, submit the shells to the public app stores, and launch the platform.
|
||||
|
||||
### Task List
|
||||
1. **Google Play Billing**: Integrate Google Play In-App Purchases into the Android and Wear OS shells.
|
||||
2. **Apple StoreKit**: Integrate Apple In-App Purchases into the iOS and watchOS shells.
|
||||
3. **Store Submissions**: Prepare assets, privacy policies, and submit the Lite-Client Shells to the App Store and Google Play.
|
||||
4. **Beta Launch**: Initiate the marketing campaign for "Meatbag" (the AI-agent confirmation reference app) to drive developer signups.
|
||||
|
||||
### Acceptance Criteria
|
||||
* Purchases made inside the mobile app successfully process via Apple/Google billing.
|
||||
* Client shells are live and downloadable from the public App Store and Google Play.
|
||||
* AI agents can successfully route haptic prompts to active smartwatch users globally.
|
||||
90
business/timeline_and_sprints.md
Normal file
90
business/timeline_and_sprints.md
Normal file
@@ -0,0 +1,90 @@
|
||||
# WhetForge Product Roadmap: Timeline and Sprints
|
||||
|
||||
This document outlines the development timeline and sprint schedules for the WhetForge Lite-Client ecosystem, including the **Meatbag Reference App**, the **Visual Builder**, the **Lite-Client Shells**, and the **Marketplace**.
|
||||
|
||||
---
|
||||
|
||||
## 1. High-Level Timeline (3-Month Horizon)
|
||||
|
||||
```
|
||||
Month 1: Client Shells & Builder Porting
|
||||
[======== Phase 1: Shell Optimization & Mobile Builder Responsive Design ========]
|
||||
|
||||
Month 2: Ktor Core & Local Sync Architecture
|
||||
[======== Phase 2: Ktor Local Server & SQLite Sync Logic ========]
|
||||
|
||||
Month 3: Marketplace Server & Payments
|
||||
[======== Phase 3: Stripe Billing, IAP, & Public Launch ========]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 2. Phase Breakdown
|
||||
|
||||
### Phase 1: Client Shells & Builder (Month 1)
|
||||
* **Goal**: Polish the Wear OS, watchOS, Android, and iOS stateless client shells and make the visual builder responsive.
|
||||
* **Key Milestones**:
|
||||
* Seamless notification companion UI optimized for round watch faces.
|
||||
* Extracted visual builder logic into `:commonMain` with responsive layout (Tabbed Developer Mode + Wizard Easy Mode).
|
||||
|
||||
### Phase 2: Local Server & Sync (Month 2)
|
||||
* **Goal**: Establish the local routing server as the reliable coordinator.
|
||||
* **Key Milestones**:
|
||||
* SQLite schema updates for caching downloaded marketplace layout profiles locally.
|
||||
* Local Ktor synchronization endpoint (`GET /api/profiles/sync`) configured.
|
||||
* High-priority push notification bridges (FCM/APNs) setup.
|
||||
|
||||
### Phase 3: Marketplace & Launch (Month 3)
|
||||
* **Goal**: Deploy the public registry, handle monetization, and publish the shells.
|
||||
* **Key Milestones**:
|
||||
* Ktor-based Marketplace web app deployed (PostgreSQL + Exposed ORM).
|
||||
* Stripe Checkout integration for web purchases.
|
||||
* Google Play Billing & Apple StoreKit integrated into the mobile shells for native IAP checkouts.
|
||||
* Launch "Meatbag" as the viral first application.
|
||||
|
||||
---
|
||||
|
||||
## 3. Detailed Sprint Schedule (2-Week Iterations)
|
||||
|
||||
### Sprint 1: Native Wearable & Mobile Polish (Current)
|
||||
* **Focus**: Android S23 Ultra and Wear OS Watch7 interaction optimization.
|
||||
* **Deliverables**:
|
||||
* Implement persistent background connection checks.
|
||||
* Optimize smartwatch Always-On Display (AOD) ambient layout stripping.
|
||||
* Refactor haptic pattern configurations.
|
||||
|
||||
### Sprint 2: Builder Porting & Responsive Design
|
||||
* **Focus**: Moving the builder to `:commonMain` and making it fit mobile screens.
|
||||
* **Deliverables**:
|
||||
* Relocate `UIBuilderScreen` Composable from `:client/desktopMain` to `:client/commonMain`.
|
||||
* Implement `MobileUIBuilderLayout` (Split Watch Preview + Bottom Sheet).
|
||||
* Build the toggle switch in the builder header to flip between "Developer Mode" (Tabs) and "Easy Mode" (Wizard).
|
||||
|
||||
### Sprint 3: Local Sync API & DB Caching
|
||||
* **Focus**: Local profile storage.
|
||||
* **Deliverables**:
|
||||
* Set up database tables in local Ktor backend for caching profiles (`profiles` table in SQLite).
|
||||
* Build the local JSON parsing pipeline to dynamically load and display cached layouts in the shell when triggered.
|
||||
* Connect CLI `meatbag.py ask` to support requesting layout IDs instead of plain text prompts.
|
||||
|
||||
### Sprint 4: Marketplace Backend & Auth
|
||||
* **Focus**: Setting up the global marketplace Ktor server.
|
||||
* **Deliverables**:
|
||||
* Initialize the `:marketplace` Ktor module.
|
||||
* Set up PostgreSQL database models using Exposed ORM (Users, Profiles, Purchases).
|
||||
* Implement JWT authentication endpoints.
|
||||
|
||||
### Sprint 5: Billing & Stripe Integration
|
||||
* **Focus**: Monetizing the web marketplace.
|
||||
* **Deliverables**:
|
||||
* Configure Stripe Java SDK on the marketplace server.
|
||||
* Implement Stripe Checkout session creation endpoints.
|
||||
* Build the webhook listener to verify purchases and write them to the PostgreSQL database.
|
||||
|
||||
### Sprint 6: In-App Purchases & Beta Release
|
||||
* **Focus**: Enabling mobile checkouts and launching.
|
||||
* **Deliverables**:
|
||||
* Integrate Google Play Billing in the Android shell.
|
||||
* Integrate Apple StoreKit in the iOS shell.
|
||||
* Publish the free Lite-Client Shells to the Play Store and App Store.
|
||||
* Launch the "Meatbag" AI agent marketing campaign.
|
||||
Reference in New Issue
Block a user