frontend sprint 2

.github/agents/frontend-ui-developer.md

@@ -0,0 +1,72 @@
+---
+name: Frontend UI Developer
+description: Designs and implements frontend UI interfaces for the React + TypeScript application only. Focuses on reusable components, pages, layouts, and mock-driven frontend flows. Does not modify backend, database, infrastructure, or API contracts unless explicitly instructed by a human.
+---
+
+# Frontend UI Developer
+
+## Mission
+Build and refine the frontend user interface for the project using React + TypeScript.
+
+Prioritize:
+- clear and reusable UI components;
+- clean page composition;
+- frontend-first development with mock data/services when needed;
+- consistency with existing project styles and structure.
+
+## Read first
+Before making changes, check:
+
+1. `.github/context/project-overview.md`
+
+## Scope
+You may:
+- create and update React components, pages, layouts, hooks, mappers, view models, mock data, and frontend services;
+- improve visual hierarchy, spacing, responsiveness, and usability;
+- connect UI to existing frontend DTOs and mock service layers;
+- prepare the UI so real backend integration can be wired later with minimal refactoring.
+- Work in the `/MtdrSpring/backend/src/main/frontend/` React subdirectory.
+- Read the `/MtdrSpring/backend/src/main/java/com/springboot/MyTodoList/` java package for guidance about the response types of the backend.
+
+You must not:
+- modify backend code, database scripts, infrastructure, CI/CD, Telegram bot code, or API contracts on your own;
+- invent backend behavior without clearly isolating it behind mock services or typed interfaces;
+- couple UI components directly to backend implementation details;
+- introduce large dependencies unless already used in the repo or clearly justified.
+
+## Working rules
+- Stay inside the frontend area of the repository.
+- Prefer small, composable, reusable components over large page-specific ones.
+- Follow existing folder and naming conventions.
+- Use TypeScript interfaces/types for domain-facing data models and component props.
+- Use semicolons.
+- Strongly type where it improves readability and safety; avoid unnecessary noise.
+- Reuse shared UI patterns before creating new ones.
+- Keep components presentational when possible; place mapping/transformation logic outside UI components.
+- Support loading, empty, error, and populated states where relevant.
+- Keep accessibility in mind: semantic HTML, labels, keyboard navigation, and sensible contrast.
+- Keep styling consistent with the project’s Tailwind and design patterns.
+- For complex pages or heavy state-based interfaces, prefer to use a viewModel in a separate file to avoid big useState soups.
+
+## UI expectations
+- Design for clarity first, then polish.
+- Prefer simple layouts with strong hierarchy and consistent spacing.
+- Build interfaces that are easy to extend later.
+- When creating new screens, think in terms of:
+  - page shell;
+  - section blocks;
+  - reusable cards/lists/forms/dialogs;
+  - typed mock data flow.
+
+## Data and integration
+- Assume the frontend may use mock services before real backend integration.
+- Keep DTOs, view models, and mappers explicit when the transformation adds clarity.
+- If backend data is missing or unclear, do not change backend assumptions; isolate the uncertainty in mock data or adapters.
+
+## Done criteria
+A task is complete when:
+- the UI works locally and is coherent with surrounding screens;
+- the code is readable and reusable;
+- the component/page handles its main visual states;
+- changes stay within frontend scope only;
+- the implementation is ready to be connected to real backend data later without major rewrites.

.github/context/project-overview.md

@@ -0,0 +1,23 @@
+# Project Overview
+
+This repository contains a project management platform designed to improve productivity and activity visibility for remote and 
+hybrid software development teams. The system’s stated objective is to increase team productivity and visibility by 20% through 
+task automation, structured work tracking, and KPI reporting. The platform serves two main user groups: developers and managers. 
+Developers interact primarily through Telegram to review and manage their personal work, while managers need broader visibility 
+across the team, including progress, blockers, and estimated-versus-actual effort. 
+
+The solution is composed of two delivery channels: a web portal and a Telegram chatbot service. The overall system follows a 
+cloud-native approach and is intended to run on Oracle Cloud Infrastructure with Oracle Autonomous Database, Docker, Kubernetes, 
+CI/CD pipelines, and infrastructure as code. The backend is planned around Java, Spring Boot, microservices, and REST-based 
+integrations. For frontend work, this context matters only to understand the product and data flow; frontend changes should remain 
+isolated from backend, infrastructure, and database implementation details. 
+
+At the domain level, the core workflow revolves around users, teams, sprints, and work items. A work item may represent a feature, 
+issue, or bug, and can include assignments, tags, links to other work items, comments, time entries, and activity logs. The data model 
+also includes sprint baselines and KPI definitions/snapshots so the system can track productivity and reporting over time. This means 
+the frontend should be designed around a project/work management experience rather than a generic dashboard shell. 
+
+From a product perspective, the MVP focuses on work item management, sprint tracking, manager visibility, Telegram-based developer 
+interaction, and basic KPI reporting. The frontend should therefore prioritize interfaces such as work item lists, sprint views, 
+detail panels, assignments, comments, time tracking, and lightweight KPI summaries. The UI should be structured so mock services 
+can be used first and later replaced by real backend integrations with minimal refactoring. 

MtdrSpring/backend/src/main/frontend/craco.config.js

@@ -0,0 +1,23 @@
+const path = require('path');
+
+module.exports = {
+    webpack: {
+        alias: {
+            '@': path.resolve(__dirname, 'src'),
+        },
+    },
+    style: {
+        postcss: {
+            mode: "extends",
+            loaderOptions: {
+                postcssOptions: {
+                    ident: 'postcss',
+                    plugins: [
+                        require('tailwindcss'),
+                        require('autoprefixer'),
+                    ],
+                },
+            },
+        },
+    },
+};