Refactor architecture documentation and enhance security features

- Updated architecture constraints documentation to include detailed sections on technical, organizational, regulatory, environmental, and performance constraints.
- Created separate markdown files for each type of constraint for better organization and clarity.
- Revised the architecture scope section to provide a clearer overview of the system's key areas.
- Enhanced the solution strategy documentation with detailed explanations of the client-server architecture, technology choices, trade-offs, and future considerations.
- Added comprehensive descriptions of backend and frontend components, middleware, and utilities in the architecture documentation.
- Migrated UI, templates, and styling notes to a dedicated section for better structure.
- Updated requirements.txt to include missing dependencies.
- Refactored user authentication logic in the users.py and security.py files to improve code organization and maintainability, including the integration of OAuth2 password bearer token handling.

docs/architecture/04_strategy/04_01_client_server_architecture.md

@@ -0,0 +1,10 @@
+---
+title: '04.01 — Client-Server Architecture'
+description: 'Details on the client-server architecture of CalMiner.'
+---
+
+# 04.01 — Client-Server Architecture
+
+- **Backend**: FastAPI serves as the backend framework, providing RESTful APIs for data management, simulation execution, and reporting. It leverages SQLAlchemy for ORM-based database interactions with PostgreSQL.
+- **Frontend**: Server-rendered Jinja2 templates deliver dynamic HTML views, enhanced with Chart.js for interactive data visualizations. This approach balances performance and simplicity, avoiding the complexity of a full SPA.
+- **Middleware**: Custom middleware handles JSON validation to ensure data integrity before processing requests.

docs/architecture/04_strategy/04_02_technology_choices.md

@@ -0,0 +1,15 @@
+---
+title: '04.02 — Technology Choices'
+description: 'Detailed explanation of technology choices in CalMiner.'
+---
+
+# 04.02 — Technology Choices
+
+- **FastAPI**: Chosen for its high performance, ease of use, and modern features like async support and automatic OpenAPI documentation.
+- **PostgreSQL**: Selected for its robustness, scalability, and support for complex queries, making it suitable for handling the diverse data needs of mining project management.
+- **SQLAlchemy**: Provides a flexible and powerful ORM layer, facilitating database interactions while maintaining code readability and maintainability.
+- **Chart.js**: Utilized for its simplicity and effectiveness in rendering interactive charts, enhancing the user experience on the dashboard.
+- **Jinja2**: Enables server-side rendering of HTML templates, allowing for dynamic content generation while keeping the frontend lightweight.
+- **Pydantic**: Used for data validation and serialization, ensuring that incoming request payloads conform to expected schemas.
+- **Docker**: Employed for containerization, ensuring consistent deployment across different environments and simplifying dependency management.
+- **Redis**: Used as an in-memory data store to cache frequently accessed data, improving application performance and reducing database load.

docs/architecture/04_strategy/04_03_trade_offs.md

@@ -0,0 +1,14 @@
+---
+title: '04.03 — Trade-offs'
+description: 'Discussion of trade-offs made in the CalMiner architecture.'
+---
+
+# 04.03 — Trade-offs
+
+- **Server-Rendered vs. SPA**: Opted for server-rendered templates over a single-page application (SPA) to reduce complexity and improve initial load times, at the cost of some interactivity.
+- **Synchronous vs. Asynchronous**: While FastAPI supports async operations, the initial implementation focuses on synchronous request handling for simplicity, with plans to introduce async features as needed.
+- **Monolithic vs. Microservices**: The initial architecture follows a monolithic approach for ease of development and deployment, with the possibility of refactoring into microservices as the system scales.
+- **In-Memory Caching**: Implementing Redis for caching introduces additional infrastructure complexity but significantly enhances performance for read-heavy operations.
+- **Database Choice**: PostgreSQL was chosen over NoSQL alternatives due to the structured nature of the data and the need for complex querying capabilities, despite potential scalability challenges.
+- **Technology Familiarity**: Selected technologies align with the team's existing skill set to minimize the learning curve and accelerate development, even if some alternatives may offer marginally better performance or features.
+- **Extensibility vs. Simplicity**: The architecture is designed to be extensible for future features (e.g., Monte Carlo simulation engine) while maintaining simplicity in the initial implementation to ensure timely delivery of core functionalities.

docs/architecture/04_strategy/04_04_future_considerations.md

@@ -0,0 +1,17 @@
+---
+title: '04.04 — Future Considerations'
+description: 'Future considerations for the CalMiner architecture.'
+---
+
+# 04.04 — Future Considerations
+
+- **Scalability**: As the user base grows, consider transitioning to a microservices architecture and implementing load balancing strategies.
+- **Asynchronous Processing**: Introduce asynchronous task queues (e.g., Celery) for long-running simulations to improve responsiveness.
+- **Enhanced Frontend**: Explore the possibility of integrating a frontend framework (e.g., React or Vue.js) for more dynamic user interactions in future iterations.
+- **Advanced Analytics**: Plan for integrating advanced analytics and machine learning capabilities to enhance simulation accuracy and reporting insights.
+- **Security Enhancements**: Implement robust authentication and authorization mechanisms to protect sensitive data and ensure compliance with industry standards.
+- **Continuous Integration/Continuous Deployment (CI/CD)**: Establish CI/CD pipelines to automate testing, building, and deployment processes for faster and more reliable releases.
+- **Monitoring and Logging**: Integrate monitoring tools (e.g., Prometheus, Grafana) and centralized logging solutions (e.g., ELK stack) to track application performance and troubleshoot issues effectively.
+- **User Feedback Loop**: Implement mechanisms for collecting user feedback to inform future development priorities and improve user experience.
+- **Documentation**: Maintain comprehensive documentation for both developers and end-users to facilitate onboarding and effective use of the system.
+- **Testing Strategy**: Develop a robust testing strategy, including unit, integration, and end-to-end tests, to ensure code quality and reliability as the system evolves.