TaskFlow Platform Extension
TaskFlow grows from a task manager into an enterprise-grade webapp building tool. Four new resources sit under every project: App, AppPage, AppDataSource and AppDeployment, each with its own SQLAlchemy model, Pydantic schema, FastAPI router and a Builder tab in the mobile client. Model a build below, then export the manifest.
Each resource cascades from its parent, mirroring the existing Workspace to Project to Task hierarchy so the architecture stays consistent.
Named application under a project. Carries slug, icon, color, status (draft, live, archived) and position for ordering. Cascade deletes pages, data sources and deployments.
A screen inside an app. Flags one page as is_home; ordered by is_home desc, position asc so the entry point always lists first.
Connection descriptor for an app: REST, database or internal TaskFlow data. Sorted by updated_at so the freshest integration surfaces first.
Immutable release record with environment and version, ordered by created_at desc to read as a release timeline.
A local, working simulation of the new API surface. Create apps, attach pages, data sources and deployments; everything persists in your browser. Use Export to copy the JSON manifest the backend would accept.
Every resource follows the existing router pattern: list with optional filters, create with parent validation via get_*_or_404, then read, patch and delete by id. Filter by resource:
| Method | Path | Purpose |
|---|
The Expo Router client gains one tab. Registration follows the existing screens exactly: a Tabs.Screen entry in app/(tabs)/_layout.tsx with an Ionicons construct glyph, plus typed API helpers in lib/api.ts and interfaces in lib/types.ts.
<Tabs.Screen
name="builder"
options={{
title: "Builder",
tabBarIcon: ({ color, size }) => (
<Ionicons name="construct" size={size} color={color} />
),
}}
/>The Alembic revision only creates four new tables and one relationship. Existing workspaces, projects, tasks and notes tables are untouched, and ProjectDetail simply gains an apps list with a matching selectinload.
On databases where the base tables already exist, the migration guards each create_table so re-running against a stamped alembic_version never collides.
All child foreign keys use ondelete="CASCADE" with ORM cascade="all, delete-orphan", matching the project to task relationship already in place.