vickybiswas · February 23, 2026 16:20
diff --git a/gistfile1.txt b/gistfile1.txt
 INCLUDE:
 - 1. PRD document
 OUTPUT:
 - 1. openapi.json file in the data component (/data) this file is the basis of this component and the app. 
 - 2. Modular React/Tailwind app implementing PRD UI, built with SRP + DRY and other best practices to build landing page and production ready app for "LinkDem" - A tool to help 1 - 10 member teams manage small 10 - 20 tasks events.
 SPEC:
 - Outcomes
 - - A valid openapi.json file which is used by the data component
 - - React app implementing the attached PRD document and constraints/validations given below. 
 - Constraints
 - - Company Landing Page with Login leading to dashboard, Kanban, settings and other permitted functions for user type with smooth animations (Framer Motion)
 - - Dashboard should allow any user to understand the tasks on their plate and allow them to drill down (link to functions) from there itself to the permitted functions CRD Event, Task, User, etc
 - - Kanban Board: Use draggable tasks between columns as given in PRD, integrated with drag-and-drop functionality with popup for comments and following the direction as defined in PRD (use pragmatic-drag-and-drop). 
 Workflow viewer for admins (use react-flow) to define the tasks so they can be used for Kanban flow (state machine)
 - - Users see only role-relevant tasks as per the logic defined in PRD. They can edit it and add data for each task, and its state if they have access as per ERD
 - Admins can manage the RBAC using the CRUD/Functions screen described in the PRD, and all user logins should respect that.
 - A complete Transition Audit should be saved for an Event, so a complete timeline can be created; the timeline will include warnings and can be seen in UI for any project
 - - When a task is Done the workflow might add new TODO's based on workflow ensure we are checking that.
 - - Data component is a key component which allows exposing openapi.json as functions for the application to use based on setting the function will either make an API call or provide mock data. The mock/api setting will be saved in the local storage and exposed in settings
 - Validations
 - - Ensure validation and sanitization are called when any input is entering the system, after which the application controls the contracts
 - - Ensure the data component will be separate, with an option in settings to switch between frontend mock and backend APIs. The /data folder will contain openapi.json, a complete Swagger definition that is used by data functions in data component with Faker to return data automatically when the setting is set to frontend mock, and sends the call to the backend API when backend mode is enabled. Both options (mock/api) will work as per openapi.json. The swagger is the integration point with proper JWT based login
 - - Ensure ZERO drift between generated data/openapi.json and data layer (mock or api both) based on a clear openapi.json with endpoints and parameters deeply integrated with this spec and PRD. 
 - - Ensure Modular code with best practices including but not limited to SRP, DRY,etc
	INCLUDE:
	- 1. PRD document
	OUTPUT:
	- 1. openapi.json file in the data component (/data) this file is the basis of this component and the app.
	- 2. Modular React/Tailwind app implementing PRD UI, built with SRP + DRY and other best practices to build landing page and production ready app for "LinkDem" - A tool to help 1 - 10 member teams manage small 10 - 20 tasks events.
	SPEC:
	- Outcomes
	- - A valid openapi.json file which is used by the data component
	- - React app implementing the attached PRD document and constraints/validations given below.
	- Constraints
	- - Company Landing Page with Login leading to dashboard, Kanban, settings and other permitted functions for user type with smooth animations (Framer Motion)
	- - Dashboard should allow any user to understand the tasks on their plate and allow them to drill down (link to functions) from there itself to the permitted functions CRD Event, Task, User, etc
	- - Kanban Board: Use draggable tasks between columns as given in PRD, integrated with drag-and-drop functionality with popup for comments and following the direction as defined in PRD (use pragmatic-drag-and-drop).
	Workflow viewer for admins (use react-flow) to define the tasks so they can be used for Kanban flow (state machine)
	- - Users see only role-relevant tasks as per the logic defined in PRD. They can edit it and add data for each task, and its state if they have access as per ERD
	- Admins can manage the RBAC using the CRUD/Functions screen described in the PRD, and all user logins should respect that.
	- A complete Transition Audit should be saved for an Event, so a complete timeline can be created; the timeline will include warnings and can be seen in UI for any project
	- - When a task is Done the workflow might add new TODO's based on workflow ensure we are checking that.
	- - Data component is a key component which allows exposing openapi.json as functions for the application to use based on setting the function will either make an API call or provide mock data. The mock/api setting will be saved in the local storage and exposed in settings
	- Validations
	- - Ensure validation and sanitization are called when any input is entering the system, after which the application controls the contracts
	- - Ensure the data component will be separate, with an option in settings to switch between frontend mock and backend APIs. The /data folder will contain openapi.json, a complete Swagger definition that is used by data functions in data component with Faker to return data automatically when the setting is set to frontend mock, and sends the call to the backend API when backend mode is enabled. Both options (mock/api) will work as per openapi.json. The swagger is the integration point with proper JWT based login
	- - Ensure ZERO drift between generated data/openapi.json and data layer (mock or api both) based on a clear openapi.json with endpoints and parameters deeply integrated with this spec and PRD.
	- - Ensure Modular code with best practices including but not limited to SRP, DRY,etc
No results found