Frontend Implementation Guide Creator

If all settings are covered in WBS_Analysis.md, proceed without asking.

Step 3 — Extract requirements from WBS Analysis

From WBS_Analysis.md, extract:

• All modules / epics and their hierarchy
• All features and sub-features under each module
• All screens / pages implied by the features
• All user roles and their permission scope
• All data entities (forms, lists, records, relationships)
• All navigation flows (screen-to-screen transitions)
• All non-functional requirements (performance, accessibility, responsiveness, etc.)

Step 4 — Create frontend_implementation_guide.md

Write a comprehensive frontend_implementation_guide.md document with the sections below. Apply all constraints listed in Step 5.

4.1 — Project Overview

• Project name and description
• Selected tech stack, UI framework, state management, form control, networking, design style, and code quality tools
• High-level architecture summary

4.2 — Project Setup Guide

• Step-by-step environment setup instructions (no code samples)
• Required tools, runtimes, and their versions
• Environment variables and configuration files needed
• How to run the project locally and connect to backend services

4.3 — Project Structure

• Recommended folder and file structure
• Purpose of each top-level directory and key files
• Naming conventions for files, folders, components, and modules

4.4 — Architecture & Design

• High-level system design and module interactions
• Component hierarchy and composition strategy
• State management architecture (global vs. local state boundaries)
• Routing strategy and route definitions
• Authentication and authorization flow on the frontend
• Error handling and user feedback strategy
• Design style guidelines (Flat Design principles and conventions)

4.5 — Database Schema

• Complete schema for all data entities relevant to the frontend
• Field definitions: name, type, constraints (required, unique, default, etc.)
• Relationships between entities (one-to-one, one-to-many, many-to-many)
• How entities map to frontend data models and API payloads

4.6 — User Roles & Permissions

• Define each role and its access scope
• Map roles to screens and features they can access
• Describe route guards and conditional UI rendering per role
• Role hierarchy and inheritance if applicable

4.7 — Feature Specifications

For each feature, document:

• Feature name and description
• Module it belongs to
• User roles that can access it
• Screens / pages involved
• Form field definitions (name, type, validation rules, required/optional)
• Data models used by the feature
• Business rules and validation logic
• User interactions and expected behavior

4.8 — Screen Flow

For each feature, describe:

• Screen-to-screen navigation and user flow
• Entry points (how the user reaches each screen)
• User actions available on each screen
• Transitions and outcomes (success, error, cancel)
• Conditional flows based on user role or data state

4.9 — Non-Functional Requirements

• Performance targets (load times, bundle size)
• Accessibility requirements
• Responsiveness and supported breakpoints
• Browser compatibility
• Internationalization considerations (if applicable)

Step 5 — Constraints

• No code samples — focus exclusively on clear, structured, and actionable documentation for developers. Describe what to build, not how to code it.
• Focus areas — prioritize Architecture & Design, Setup Instructions, and Database Schema.
• Completeness — every module and feature from WBS_Analysis.md must appear; nothing may be omitted or summarized away.
• Structured hierarchy — preserve the module → feature → sub-feature tree from the source analysis.
• Field definitions — include field definitions for all forms and data models (name, type, constraints).
• Screen flows — every feature must include a screen flow describing navigation and user journey.
• No assumptions — do not add features, screens, or entities not present in WBS_Analysis.md; flag ambiguities as open questions.
• Format — use Markdown with clear headings (##, ###, ####), tables where appropriate, and bullet lists for details.
• Summary section — end with a summary table showing total count of modules, features, screens, data entities, and user roles.