Skip to main content

Product Development Roadmap

Comprehensive roadmap for MVP launch with agent-orchestrated task management.

Last Updated: February 2, 2026
Status: Ready for Agent Orchestration

Overview​

This roadmap addresses critical gaps from the codebase assessment while implementing feature flags for controlled rollouts. All tasks are designed for agent orchestration with clear acceptance criteria.

Key Principles​

  1. Feature Flags First - All new features behind flags for controlled rollout
  2. Agent Orchestration - Tasks designed for multi-agent collaboration
  3. Incremental Delivery - Small, verifiable tasks
  4. Test-Driven - Verification and testing built into workflow

Feature Flags Architecture​

Hybrid Approach​

We use two systems for feature flags:

  1. Custom API System - For business/premium features that users can control
  2. PostHog - For A/B testing and gradual rollout flags

See Feature Flags Strategy for complete details.

Custom API System (Business/Premium Features)​

Location: juniro-api/src/config/feature-flags.ts

Flag Types:

  • Global Flags - Platform-wide features (Admin-controlled)
  • Provider Flags - Per-provider premium features (Provider-controlled)
  • User Flags - Per-user premium features (future)

Storage:

  • Global flags: FeatureFlag table (admin-controlled platform-wide features)
  • Provider flags: ProviderAccount.featureFlags JSON column (provider-controlled premium features)
  • User flags: User.featureFlags JSON column (future)

API Endpoints:

  • GET /config/feature-flags - Get all enabled flags for current user/provider
  • GET /config/feature-flags/global - Admin: Get all global flags
  • PATCH /config/feature-flags/global/:key - Admin: Update global flag
  • GET /config/feature-flags/:providerId - Get provider-specific flags (admin only)
  • PATCH /config/feature-flags/:providerId - Update provider flags (admin override)
  • GET /me/provider/feature-flags - Get my provider's feature flags (provider self-service)
  • PATCH /me/provider/feature-flags - Update my provider's feature flags (provider self-service)

Naming Convention: UPPER_SNAKE_CASE (e.g., PAYMENT_ENABLED)

Booking & Payment Flag Hierarchy​

BOOKING_FLOW_ENABLED (Global, Admin, Default: ON)
       │
       │ OFF → "Booking coming soon" (rare, maintenance mode)
       │
       ▼ ON
PAYMENT_ENABLED (Global, Admin, Default: ON)
       │
       │ OFF → Book without payment (ALL providers)
       │       Payment option hidden from provider settings
       │
       ▼ ON
PAYMENT_ENABLED (Provider, Provider opt-in, Default: OFF)
       │
       │ OFF → Book without payment (this provider)
       │
       ▼ ON (provider opted in)
Show Payment Form (Stripe/Razorpay)

PostHog System (Rollout/A/B Testing)​

Purpose: Platform-controlled gradual rollouts and A/B tests

Examples:

  • booking-flow - Rollout new booking experience
  • reviews - Rollout reviews feature
  • staff-portal - Rollout staff portal
  • attendance - Rollout attendance tracking
  • assignments - Rollout assignments
  • parent-headline-variant - A/B test landing page

Naming Convention: kebab-case (e.g., booking-flow, reviews, staff-portal) Note: No -enabled suffix - flag name itself implies it's a toggle

Integration:

  • Frontend: useFeatureFlag('booking-flow') from posthog-js/react
  • Backend: posthog.isFeatureEnabled('booking-flow', userId)

Phase 1: Foundation & Feature Flags (Week 1)​

Task 1.1: Feature Flags Infrastructure​

ID: TASK-001
Priority: P0
Estimated Effort: 2 days
Agents: @endpoint-builder, @verifier-api
Status: ✅ COMPLETED

Description: Implement feature flags system in API with database schema and endpoints.

Acceptance Criteria:

  • Create FeatureFlag table in Prisma schema (for global admin-controlled flags)
  • Create feature-flags.ts config module
  • Add featureFlags JSON column to ProviderAccount (for provider-controlled flags)
  • Create GET /config/feature-flags endpoint (returns global + provider flags)
  • Create GET /config/feature-flags/:providerId endpoint (admin only)
  • Create PATCH /config/feature-flags/:providerId endpoint (admin override)
  • Create GET /me/provider/feature-flags endpoint (provider self-service)
  • Create PATCH /me/provider/feature-flags endpoint (provider self-service)
  • Add feature flag middleware for route protection
  • Add GET /config/feature-flags/global endpoint (admin: get all global flags)
  • Add PATCH /config/feature-flags/global/:key endpoint (admin: update global flag)
  • Unit tests for flag evaluation logic (deferred)
  • API documentation updated

Feature Flags to Implement:

Global (Admin-Controlled):

  • BOOKING_FLOW_ENABLED - Master switch for booking (default: ON, core feature)
  • PAYMENT_ENABLED - Master switch for payment collection (default: ON)
  • MESSAGING_ENABLED - Master switch for messaging (default: OFF)
  • AI_SEARCH_ENABLED - Master switch for AI search (default: OFF)
  • REVIEWS_ENABLED - Master switch for reviews (default: OFF)
  • ATTENDANCE_ENABLED - Master switch for attendance (default: OFF)
  • ASSIGNMENTS_ENABLED - Master switch for assignments (default: OFF)
  • STAFF_PORTAL_ENABLED - Master switch for staff portal (default: OFF)

Provider-Level (Provider-Controlled, only visible if Global=ON):

  • PAYMENT_ENABLED - Provider payment opt-in (default: OFF, freemium)
  • MESSAGING_ENABLED - Provider messaging opt-in (default: OFF, premium)
  • AI_RECOMMENDATIONS_ENABLED - Provider AI recommendations (default: OFF, premium)

Verification:

  • @verifier-api confirms all endpoints work
  • @reviewer approves code quality
  • Manual testing with Postman/curl

Task 1.2: Frontend Feature Flags Hook​

ID: TASK-002
Priority: P0
Estimated Effort: 1 day
Agents: @component-builder, @verifier-frontend

Description: Create React hook and context for feature flags in all frontend apps.

Acceptance Criteria:

  • Create useFeatureFlags() hook in juniro-design
  • Create FeatureFlagsProvider context
  • Add API client method to fetch flags
  • Add TypeScript types for flags
  • Storybook story for hook
  • Sync to all web apps

Verification:

  • @verifier-frontend confirms hook works
  • @design-audit confirms Storybook story
  • Manual testing in all portals

Task 1.3: API Client Library​

ID: TASK-003
Priority: P0
Estimated Effort: 2 days
Agents: @api-wirer, @verifier-frontend

Description: Create shared API client library for all frontend apps with Supabase Auth integration.

Acceptance Criteria:

  • Create @juniro/api-client package structure
  • Implement Supabase Auth token injection
  • Create typed API methods for all endpoints
  • Add error handling and retry logic
  • Add request/response interceptors
  • Add TypeScript types from OpenAPI spec
  • Sync to all web apps
  • Unit tests for client methods

Verification:

  • @verifier-frontend confirms client works
  • @reviewer approves code quality
  • Manual testing with real API

Phase 2: Authentication & User Management (Week 2)​

Task 2.1: Supabase Auth Integration - Public Site​

ID: TASK-004
Priority: P0
Estimated Effort: 2 days
Agents: @auth-implementer, @verifier-frontend

Description: Add Supabase Auth to public website with signup/login flows.

Acceptance Criteria:

  • Install Supabase client in juniro-web-public
  • Create auth context and hooks
  • Implement signup flow
  • Implement login flow
  • Implement logout flow
  • Add protected route wrapper
  • Sync user to API on signup (POST /auth/sync)
  • Handle auth state persistence
  • Add loading states and error handling
  • E2E tests for auth flows

Verification:

  • @verifier-frontend confirms auth works
  • @verifier-e2e confirms E2E tests pass
  • Manual testing of all auth flows

Task 2.2: Supabase Auth Integration - Parents Portal​

ID: TASK-005
Priority: P0
Estimated Effort: 1 day
Agents: @auth-implementer, @verifier-frontend

Description: Add Supabase Auth to parents portal (reuse patterns from public site).

Acceptance Criteria:

  • Reuse auth context from public site
  • Add auth to parents portal
  • Test login/logout flows
  • Verify API sync works

Verification:

  • @verifier-frontend confirms auth works
  • Manual testing

Task 2.3: Supabase Auth Integration - Providers Portal​

ID: TASK-006
Priority: P0
Estimated Effort: 1 day
Agents: @auth-implementer, @verifier-frontend

Description: Add Supabase Auth to providers portal.

Acceptance Criteria:

  • Reuse auth context
  • Add auth to providers portal
  • Test login/logout flows
  • Verify API sync works

Verification:

  • @verifier-frontend confirms auth works
  • Manual testing

Task 2.4: User Profile Management​

ID: TASK-007
Priority: P0
Estimated Effort: 2 days
Agents: @api-wirer, @verifier-frontend

Description: Wire user profile pages to API (GET /me, PATCH /me).

Acceptance Criteria:

  • Wire profile page to GET /me
  • Wire profile edit to PATCH /me
  • Add form validation
  • Add loading and error states
  • Add success notifications
  • Test in all portals

Verification:

  • @verifier-frontend confirms profile works
  • Manual testing in all portals

Phase 3: Activity Discovery & Search (Week 3)​

Task 3.1: Activity Search - Public Site​

ID: TASK-008
Priority: P0
Estimated Effort: 2 days
Agents: @api-wirer, @verifier-frontend

Description: Wire activity search on public site to GET /activities endpoint.

Acceptance Criteria:

  • Replace mock data with API call
  • Wire search filters (category, location, age)
  • Add pagination
  • Add loading states
  • Add error handling
  • Add empty states
  • Test search performance

Verification:

  • @verifier-frontend confirms search works
  • @perf-audit confirms performance
  • Manual testing with real data

Task 3.2: Activity Detail Page​

ID: TASK-009
Priority: P0
Estimated Effort: 1 day
Agents: @api-wirer, @verifier-frontend

Description: Wire activity detail page to GET /activities/:slug and GET /activities/:id/sessions.

Acceptance Criteria:

  • Replace mock data with API calls
  • Wire activity details
  • Wire available sessions list
  • Add loading states
  • Add error handling
  • Test with various activities

Verification:

  • @verifier-frontend confirms detail page works
  • Manual testing

Task 3.3: Provider Public Profile​

ID: TASK-010
Priority: P0
Estimated Effort: 1 day
Agents: @api-wirer, @verifier-frontend

Description: Wire provider profile page to GET /providers/:slug.

Acceptance Criteria:

  • Replace mock data with API call
  • Wire provider details
  • Wire provider activities list
  • Add loading states
  • Add error handling

Verification:

  • @verifier-frontend confirms profile works
  • Manual testing

Phase 4: Booking Flow (Week 4)​

Task 4.1: Children Management​

ID: TASK-011
Priority: P0
Estimated Effort: 2 days
Agents: @api-wirer, @verifier-frontend

Description: Wire children management to API (GET /me/children, POST /me/children, PATCH /me/children/:id, DELETE /me/children/:id).

Acceptance Criteria:

  • Wire children list
  • Wire add child form
  • Wire edit child form
  • Wire delete child
  • Add form validation
  • Add loading and error states
  • Test in parents portal

Verification:

  • @verifier-frontend confirms children management works
  • Manual testing

Task 4.2: Booking Creation Flow​

ID: TASK-012
Priority: P0
Estimated Effort: 3 days
Agents: @api-wirer, @verifier-frontend, @verifier-e2e

Description: Wire booking creation flow with three-tier feature flag hierarchy.

Acceptance Criteria:

  • Check BOOKING_FLOW_ENABLED flag (Global, default: ON)
    • If OFF: Show "Booking coming soon" message (rare, maintenance mode)
    • If ON: Continue to booking flow (normal operation)
  • Wire booking form to POST /me/bookings
  • Add idempotency key generation
  • Check PAYMENT_ENABLED flag (Global, default: ON)
    • If OFF: Skip payment for ALL bookings, show offline payment message
    • If ON: Continue to provider check
  • Check PAYMENT_ENABLED flag (Provider, default: OFF, opt-in)
    • If OFF: Skip payment for this provider, show offline payment message
    • If ON: Show payment form (Stripe/Razorpay)
  • Add form validation
  • Add loading states
  • Add success/error handling
  • E2E tests for booking flow

Payment Logic Summary:

if (!globalFlags.BOOKING_FLOW_ENABLED) → "Booking coming soon" (rare)
else if (!globalFlags.PAYMENT_ENABLED) → Book without payment (all providers, payment hidden)
else if (!providerFlags.PAYMENT_ENABLED) → Book without payment (provider opted out)
else → Show payment form (provider opted in)

Verification:

  • @verifier-frontend confirms booking works
  • @verifier-e2e confirms E2E tests pass
  • Manual testing with key scenarios:
    • BOOKING_FLOW=OFF → "Booking coming soon" (maintenance mode)
    • PAYMENT(G)=OFF → Book without payment for all (payment feature disabled)
    • PAYMENT(G)=ON, PAYMENT(P)=OFF → Book without payment (provider hasn't opted in)
    • PAYMENT(G)=ON, PAYMENT(P)=ON → Full payment flow (provider opted in)

Task 4.3: Booking Management​

ID: TASK-013
Priority: P0
Estimated Effort: 2 days
Agents: @api-wirer, @verifier-frontend

Description: Wire booking list and details to API.

Acceptance Criteria:

  • Wire bookings list (GET /me/bookings)
  • Wire booking details (GET /me/bookings/:id)
  • Wire cancel booking (POST /me/bookings/:id/cancel)
  • Add loading states
  • Add error handling
  • Test in parents portal

Verification:

  • @verifier-frontend confirms booking management works
  • Manual testing

Phase 5: Provider Dashboard (Week 5)​

Task 5.0: Provider Feature Flags UI (Settings)​

ID: TASK-015A
Priority: P0
Estimated Effort: 3 days
Agents: @component-builder, @api-wirer, @verifier-frontend, @design-audit

Description: Add "Features" section to Provider Settings where providers can enable/disable their own premium feature flags (e.g., PAYMENT_ENABLED, MESSAGING_ENABLED).

Acceptance Criteria:

  • Add "Features" section to Provider Settings menu
  • Create SettingsFeatures component in juniro-design
  • Wire to GET /me/provider/feature-flags (Custom API)
  • Wire to PATCH /me/provider/feature-flags (Custom API)
  • Display Premium Features section:
    • List all provider-controllable flags (PAYMENT_ENABLED, MESSAGING_ENABLED, AI_RECOMMENDATIONS_ENABLED)
    • Show toggle for each flag with description
    • Show feature benefits and pricing (if applicable)
    • Show status (enabled/disabled) with visual indicator
    • Show admin override indicator (if admin has overridden)
    • Add confirmation dialog for disabling features
  • Display Platform Features section (Read-Only):
    • Show PostHog flags (admin-v2, parent-headline-variant, etc.) - read-only
    • Show status (enabled/disabled for their account)
    • Show rollout percentage (if applicable)
    • Informational only (no controls)
  • Add loading states and error handling
  • Storybook story
  • Test in providers portal

Verification:

  • @verifier-frontend confirms UI works
  • @design-audit confirms design system compliance
  • Manual testing of enable/disable flow
  • Verify PostHog flags display correctly (read-only)

Task 5.1: Provider Activities Management​

ID: TASK-014
Priority: P0
Estimated Effort: 3 days
Agents: @api-wirer, @verifier-frontend

Description: Wire provider activities CRUD to API.

Acceptance Criteria:

  • Wire activities list
  • Wire create activity form
  • Wire edit activity form
  • Wire delete activity
  • Wire activity status updates
  • Add form validation
  • Add loading and error states
  • Test in providers portal

Verification:

  • @verifier-frontend confirms activities management works
  • Manual testing

Task 5.2: Provider Sessions Management​

ID: TASK-015
Priority: P0
Estimated Effort: 2 days
Agents: @api-wirer, @verifier-frontend

Description: Wire provider sessions CRUD to API.

Acceptance Criteria:

  • Wire sessions list
  • Wire create session form
  • Wire edit session form
  • Wire delete session
  • Wire capacity management
  • Add form validation
  • Add loading and error states
  • Test in providers portal

Verification:

  • @verifier-frontend confirms sessions management works
  • Manual testing

Task 5.3: Provider Bookings View​

ID: TASK-016
Priority: P0
Estimated Effort: 2 days
Agents: @api-wirer, @verifier-frontend

Description: Wire provider bookings view to API.

Acceptance Criteria:

  • Wire bookings list for provider
  • Wire booking status updates
  • Add filters (status, date range)
  • Add loading states
  • Add error handling
  • Test in providers portal

Verification:

  • @verifier-frontend confirms bookings view works
  • Manual testing

Phase 6: PostHog Integration & Payment (Week 6)​

Task 6.0: PostHog Feature Flags Setup​

ID: TASK-016A
Priority: P1
Estimated Effort: 2 days
Agents: @endpoint-builder, @verifier-api, @verifier-frontend

Description: Set up PostHog for gradual rollout and A/B testing feature flags (not for platform feature toggles).

Acceptance Criteria:

  • Install PostHog Node SDK in API (posthog-node)
  • Create PostHog config module (src/config/posthog.ts)
  • Add PostHog API key to environment variables
  • Create helper functions for PostHog flag checks
  • Add PostHog flag checks for A/B tests (parent-headline-variant, parent-cta-variant)
  • Add PostHog flag checks for gradual rollouts (admin-v2)
  • Document PostHog flag creation process
  • Unit tests for PostHog integration

Note: Platform features (reviews, attendance, assignments, ai-search, booking-flow, staff-portal) are controlled via Custom API, not PostHog.

Verification:

  • @verifier-api confirms PostHog integration works
  • @reviewer approves code quality
  • Manual testing with PostHog dashboard

Phase 6: Payment Integration (Week 6)​

Task 6.1: Payment Webhook Handlers​

ID: TASK-017
Priority: P0
Estimated Effort: 3 days
Agents: @endpoint-builder, @verifier-api

Description: Implement Stripe and Razorpay webhook handlers with feature flag checks.

Acceptance Criteria:

  • Create POST /webhooks/stripe endpoint
  • Create POST /webhooks/razorpay endpoint
  • Verify webhook signatures
  • Handle payment success events
  • Handle payment failure events
  • Update booking status on payment
  • Check PAYMENT_ENABLED flag before processing
  • Add error handling and logging
  • Unit tests for webhook handlers

Verification:

  • @verifier-api confirms webhooks work
  • @reviewer approves code quality
  • Manual testing with Stripe/Razorpay test webhooks

Task 6.2: Payment UI Integration​

ID: TASK-018
Priority: P0
Estimated Effort: 2 days
Agents: @api-wirer, @verifier-frontend

Description: Integrate Stripe/Razorpay payment UI in booking flow (behind three-tier feature flag hierarchy).

Acceptance Criteria:

  • Check PAYMENT_ENABLED (Global) first
    • If OFF: Skip payment for ALL bookings
  • Check PAYMENT_ENABLED (Provider) second
    • If OFF: Skip payment for this provider
    • If ON: Show payment form with Stripe/Razorpay
  • Detect region for payment provider:
    • US: Stripe
    • India: Razorpay
  • Handle payment success/failure
  • Update booking status after payment
  • Add loading states
  • Add error handling
  • Test with all flag combinations

Verification:

  • @verifier-frontend confirms payment UI works
  • Manual testing with test cards
  • Test all flag combinations (see Task 4.2)

Phase 7: Messaging (Week 7) - Feature Flagged​

Task 7.1: Messaging API Endpoints​

ID: TASK-019
Priority: P1
Estimated Effort: 3 days
Agents: @endpoint-builder, @verifier-api

Description: Implement messaging API endpoints behind MESSAGING_ENABLED feature flag.

Acceptance Criteria:

  • Create Message table in Prisma schema
  • Create GET /messages endpoint (list conversations)
  • Create GET /messages/:conversationId endpoint (get messages)
  • Create POST /messages endpoint (send message)
  • Add feature flag check (MESSAGING_ENABLED)
  • Add authentication checks
  • Add rate limiting
  • Unit tests for endpoints

Verification:

  • @verifier-api confirms endpoints work
  • @reviewer approves code quality
  • Manual testing with flag enabled/disabled

Task 7.2: Messaging UI​

ID: TASK-020
Priority: P1
Estimated Effort: 3 days
Agents: @component-builder, @api-wirer, @verifier-frontend

Description: Build messaging UI components and wire to API (behind feature flag).

Acceptance Criteria:

  • Check MESSAGING_ENABLED flag (Custom API - provider-controlled)
  • Check messaging-enabled flag (PostHog - platform rollout)
  • If both enabled: Show messaging UI
  • If either disabled: Hide messaging UI
  • Create message list component
  • Create conversation view component
  • Create message input component
  • Wire to messaging API
  • Add real-time updates (polling or WebSocket)
  • Add loading states
  • Add error handling
  • Storybook stories
  • Test in parents and providers portals

Verification:

  • @verifier-frontend confirms messaging UI works
  • @design-audit confirms Storybook stories
  • Manual testing with flag enabled/disabled

Phase 8: AI Features (Week 8) - Feature Flagged & Mocked​

Task 8.1: AI Search API (Mocked)​

ID: TASK-021
Priority: P1
Estimated Effort: 2 days
Agents: @endpoint-builder, @verifier-api

Description: Implement AI-powered search endpoint with mocked AI responses behind AI_SEARCH_ENABLED flag (Custom API - global, admin-controlled).

Acceptance Criteria:

  • Create POST /ai/search endpoint
  • Check AI_SEARCH_ENABLED feature flag
  • If enabled: Return mocked AI search results
  • If disabled: Return 404 or fallback to regular search
  • Mock response structure matches future real AI response
  • Add authentication
  • Add rate limiting
  • Unit tests for endpoint

Mock Response Structure:

{
  "query": "soccer for 5 year old",
  "results": [
    {
      "activityId": "uuid",
      "relevanceScore": 0.95,
      "reason": "Matches age group and sport preference"
    }
  ],
  "suggestions": ["indoor soccer", "youth soccer leagues"]
}

Verification:

  • @verifier-api confirms endpoint works
  • @reviewer approves code quality
  • Manual testing with flag enabled/disabled

Task 8.2: AI Recommendations API (Mocked)​

ID: TASK-022
Priority: P1
Estimated Effort: 2 days
Agents: @endpoint-builder, @verifier-api

Description: Implement AI recommendations endpoint with mocked responses behind AI_RECOMMENDATIONS_ENABLED flag.

Acceptance Criteria:

  • Create GET /ai/recommendations endpoint
  • Check AI_RECOMMENDATIONS_ENABLED feature flag
  • If enabled: Return mocked recommendations based on user profile
  • If disabled: Return 404 or fallback to popular activities
  • Mock response structure matches future real AI response
  • Add authentication
  • Add rate limiting
  • Unit tests for endpoint

Verification:

  • @verifier-api confirms endpoint works
  • @reviewer approves code quality
  • Manual testing with flag enabled/disabled

Task 8.3: AI Search UI​

ID: TASK-023
Priority: P1
Estimated Effort: 2 days
Agents: @component-builder, @api-wirer, @verifier-frontend

Description: Build AI search UI component and wire to mocked API (behind feature flag).

Acceptance Criteria:

  • Check AI_SEARCH_ENABLED feature flag
  • If enabled: Show AI search input with "AI-powered" badge
  • If disabled: Show regular search
  • Create AI search component
  • Wire to mocked API endpoint
  • Show relevance scores and reasons
  • Add loading states
  • Add error handling
  • Storybook story
  • Test on public site

Verification:

  • @verifier-frontend confirms AI search UI works
  • @design-audit confirms Storybook story
  • Manual testing with flag enabled/disabled

Task 8.4: AI Recommendations UI​

ID: TASK-024
Priority: P1
Estimated Effort: 2 days
Agents: @component-builder, @api-wirer, @verifier-frontend

Description: Build AI recommendations UI component and wire to mocked API (behind feature flag).

Acceptance Criteria:

  • Check AI_RECOMMENDATIONS_ENABLED feature flag (Custom API - provider-controlled premium)
  • If enabled: Show "Recommended for you" section
  • If disabled: Show "Popular activities" section
  • Create recommendations component
  • Wire to mocked API endpoint
  • Show recommendation reasons
  • Add loading states
  • Add error handling
  • Storybook story
  • Test in parents portal

Verification:

  • @verifier-frontend confirms recommendations UI works
  • @design-audit confirms Storybook story
  • Manual testing with flag enabled/disabled

Phase 9: Email Notifications (Week 9)​

Task 9.1: Booking Confirmation Emails​

ID: TASK-025
Priority: P0
Estimated Effort: 2 days
Agents: @endpoint-builder, @verifier-api

Description: Implement booking confirmation email sending via Resend.

Acceptance Criteria:

  • Create email templates (HTML + text)
  • Create email service module
  • Send confirmation email on booking creation
  • Send provider notification email
  • Add error handling and retry logic
  • Unit tests for email service
  • Test with real Resend account

Verification:

  • @verifier-api confirms emails are sent
  • @reviewer approves code quality
  • Manual testing with real email delivery

Phase 10: Testing & Quality (Week 10)​

Task 10.1: E2E Test Coverage​

ID: TASK-026
Priority: P0
Estimated Effort: 3 days
Agents: @verifier-e2e, @qa-coverage

Description: Add comprehensive E2E tests for critical user flows.

Acceptance Criteria:

  • E2E test for signup/login flow
  • E2E test for activity search and booking
  • E2E test for provider activity creation
  • E2E test for booking management
  • E2E test for payment flow (with flag enabled)
  • E2E test for messaging (with flag enabled)
  • E2E test for AI search (with flag enabled)
  • All tests pass in CI/CD

Verification:

  • @verifier-e2e confirms all tests pass
  • @qa-coverage confirms coverage targets met

Task 10.2: Performance Optimization​

ID: TASK-027
Priority: P1
Estimated Effort: 2 days
Agents: @perf-audit, @verifier-frontend

Description: Optimize performance for critical pages and API endpoints.

Acceptance Criteria:

  • Audit Core Web Vitals
  • Optimize activity search performance
  • Optimize booking flow performance
  • Add API response caching where appropriate
  • Optimize bundle sizes
  • Performance budget met

Verification:

  • @perf-audit confirms performance targets met
  • Lighthouse scores > 90

Phase 11: Documentation & Launch Prep (Week 11)​

Task 11.0: Admin Feature Flags UI​

ID: TASK-027A
Priority: P0
Estimated Effort: 4 days
Agents: @component-builder, @api-wirer, @verifier-frontend, @design-audit

Description: Wire up the existing FeatureFlagsManagement component in Admin Portal to manage both Custom API flags and PostHog flags from a unified interface.

Acceptance Criteria:

  • Wire FeatureFlagsManagement component to Custom API
  • Integrate PostHog API for PostHog flags
  • Display Business Features section (Custom API flags):
    • List all provider-level flags (MESSAGING_ENABLED, PAYMENT_ENABLED, AI_RECOMMENDATIONS_ENABLED)
    • Show provider count per flag (how many have it enabled)
    • Allow admin to view all providers and their flag status
    • Allow admin to override provider flags (with confirmation)
    • Show flag usage analytics
  • Display Rollout Features section (PostHog flags):
    • List all PostHog flags (admin-v2, parent-headline-variant, parent-cta-variant, payments-stripe, payments-razorpay)
    • Show current rollout percentage
    • Link to PostHog dashboard
    • Show flag status (enabled/disabled)
    • Show A/B test variants and distribution
  • Create Unified View:
    • Combined list of all flags (both systems)
    • Filter by system (Custom API / PostHog)
    • Filter by type (Premium / Rollout / A/B Test / Regional)
    • Search by flag name
    • Export flag configuration
  • Add loading states and error handling
  • Test in admin portal

Verification:

  • @verifier-frontend confirms UI works
  • @design-audit confirms design system compliance
  • Manual testing of all admin operations
  • Verify PostHog integration works

Task 11.1: Update Product Documentation​

ID: TASK-028
Priority: P0
Estimated Effort: 1 day
Agents: @docs-sync, @roadmap-updater

Description: Update product status and roadmap documentation.

Acceptance Criteria:

  • Update product-status.md with completed features
  • Update product-roadmap-matrix.md
  • Document feature flags usage
  • Update API documentation
  • Create feature flag admin guide

Verification:

  • @docs-audit confirms documentation is accurate
  • @roadmap-updater confirms roadmap is updated

Backlog (P2/P3 - Post-MVP)​

These tasks are important but not critical for MVP launch. Address after core features are stable.

Task B.1: Component Adapter Pattern​

ID: TASK-B001
Priority: P2
Estimated Effort: 3-5 days
Agents: @component-builder, @sync-runner, @verifier-frontend

Description: Replace sed transformations in sync scripts with a proper component adapter pattern. Instead of rewriting props at sync time, create thin adapter components in each portal that map portal-specific props to design system props.

Current State:

  • juniro-infra/scripts/sync-*.sh uses sed to transform imports/props
  • Works but fragile - regex can break on edge cases

Proposed Solution:

// juniro-web-public/src/components/adapters/Button.tsx
import { Button as DSButton } from '@/components/design-system/Button';

export const Button = (props) => {
  // Map portal-specific props to design system props
  const variant = props.variant === 'primary' ? 'default' : props.variant;
  return <DSButton {...props} variant={variant} />;
};

Acceptance Criteria:

  • Create adapter pattern architecture doc
  • Create adapter components for each portal
  • Update sync scripts to not transform props
  • Test sync with new pattern
  • Document adapter pattern for future components

When to Prioritize:

  • If sync bugs arise from regex edge cases
  • If we need portal-specific component behavior
  • When adding new props that need transformation

Verification:

  • @sync-runner confirms sync works with adapters
  • @verifier-frontend confirms all portals build
  • No regression in component behavior

Task B.2: Service Layer Refactoring (Existing Routes)​

ID: TASK-B002
Priority: P3
Estimated Effort: 5-7 days
Agents: @endpoint-builder, @verifier-api, @reviewer

Description: Refactor existing API route handlers to use service layer pattern. Extract business logic from routes into testable service functions in juniro-api/src/services/.

Current State:

  • juniro-api/src/services/ exists but is empty
  • Business logic is inline in route handlers
  • Works but harder to test and maintain

Note: New features (payments, messaging, AI) will be built with services from day 1. This task is for refactoring existing routes.

Routes to Refactor:

  • bookings.ts → BookingService
  • activities.ts → ActivityService
  • sessions.ts → SessionService
  • providers.ts → ProviderService
  • reviews.ts → ReviewService
  • auth.ts → AuthService
  • me.ts → UserService

Acceptance Criteria:

  • Create service layer architecture doc
  • Extract business logic to services
  • Add unit tests for each service
  • Routes become thin (just validation + service call)
  • All existing functionality preserved

Verification:

  • @verifier-api confirms all endpoints work
  • @reviewer approves service architecture
  • Test coverage > 80% for services

Task B.3: Structured Logging​

ID: TASK-B003
Priority: P2
Estimated Effort: 2-3 days
Agents: @endpoint-builder, @verifier-api

Description: Replace console.log statements with structured logging using a proper logging library (e.g., Pino, Winston). Add request tracing, log levels, and JSON formatting for production.

Current State:

  • API uses console.log for logging
  • No structured format
  • No log levels (debug, info, warn, error)
  • No request correlation IDs

Acceptance Criteria:

  • Choose and integrate logging library (recommend Pino for performance)
  • Add log levels (debug, info, warn, error)
  • Add request correlation IDs
  • JSON format for production, pretty print for development
  • Replace all console.log with structured logs
  • Add request/response logging middleware
  • Document logging standards

Verification:

  • @verifier-api confirms logging works
  • @reviewer approves logging patterns
  • Logs are searchable and filterable

Task B.4: Fix Pre-existing TypeScript Errors​

ID: TASK-B004
Priority: P2
Estimated Effort: 2-3 days
Agents: @reviewer, @verifier-api

Description: Fix pre-existing TypeScript errors in juniro-api and juniro-platform that were identified during version standardization.

Current State:

  • juniro-api: Type mismatches in src/routes/sessions.ts, response type incompatibilities with Hono OpenAPI types
  • juniro-platform: TypeScript errors in app/agents/repository-manager/page.tsx, ESLint config issues

Acceptance Criteria:

  • Fix TypeScript errors in juniro-api
  • Fix TypeScript errors in juniro-platform
  • Fix ESLint config in juniro-platform
  • All repos pass bun run build without errors
  • All repos pass bun run typecheck without errors

Verification:

  • @verifier-api confirms API builds cleanly
  • @verifier-frontend confirms platform builds cleanly
  • CI/CD passes on all repos

Task B.5: Security Vulnerability Fixes​

ID: TASK-B005
Priority: P2
Estimated Effort: 1-2 days
Agents: @security-audit, @reviewer

Description: Address npm audit security vulnerabilities identified during version standardization across all repositories.

Current State:

  • Multiple repos have npm audit warnings
  • Vulnerabilities need review and remediation

Acceptance Criteria:

  • Run npm audit on all repos
  • Triage vulnerabilities (critical, high, medium, low)
  • Fix critical and high vulnerabilities
  • Document accepted risks for unfixable issues
  • Add npm audit to CI/CD pipeline

Verification:

  • @security-audit confirms vulnerabilities addressed
  • npm audit shows no critical/high issues
  • Security report documented

Summary​

Total Estimated Effort: 11 weeks​

Priority Breakdown:​

  • P0 (Critical): 20 tasks (8 weeks)
  • P1 (Important): 8 tasks (3 weeks)
  • P2/P3 (Backlog): 5 tasks (post-MVP, ~2 weeks)

Feature Flags:​

Global (Admin-Controlled):

  • ✅ BOOKING_FLOW_ENABLED - Default: ON (maintenance mode flag)
  • ✅ PAYMENT_ENABLED - Default: ON (master switch)
  • ✅ MESSAGING_ENABLED - Default: OFF
  • ✅ AI_SEARCH_ENABLED - Default: OFF
  • ✅ REVIEWS_ENABLED - Default: OFF
  • ✅ ATTENDANCE_ENABLED - Default: OFF
  • ✅ ASSIGNMENTS_ENABLED - Default: OFF
  • ✅ STAFF_PORTAL_ENABLED - Default: OFF

Provider-Controlled (visible only if Global=ON):

  • ✅ PAYMENT_ENABLED - Default: OFF (opt-in)
  • ✅ MESSAGING_ENABLED - Default: OFF (premium)
  • ✅ AI_RECOMMENDATIONS_ENABLED - Default: OFF (premium)

Agent Orchestration Ready:​

  • All tasks have clear acceptance criteria
  • All tasks specify required agents
  • All tasks have verification steps
  • Tasks are sequenced for dependencies

Next Steps:

  1. Review and approve this roadmap
  2. Set up agent orchestration system (see ORCHESTRATION.md)
  3. Create Linear issues for tracking
  4. Begin Phase 1 with agent orchestration