add: adding support for cursor

.cursorrules

@@ -0,0 +1,224 @@
+The name of our company is Protevus
+The name of our project is Platform
+Protevus = Laravel and Platform = Illuminate
+Our Development Langauge is Dart
+Our cross-platform UI Kit is Flutter
+Our Implementation is based on Angel3
+Our Inspiration is based on Laravel
+Our Deployment Target are Windows, MacOS, Linux, iOS, Android, Web, IoT and Edge Devices
+
+Protevus Aims to bring a complete Laravel experience to Dart, and Flutter with a truely Unified Full Stack Experience. We aim to mature the platform to support cross-platform development of complex government, military, financial, medical, supply-chain, enterprise and idustrial applications.
+
+Our 10 Step  Development Lifecycle is as follows: We use a hybrid mix of Interface Driven Development, Test Driven Development and AI Software Engineer Agents to assist in generating efficient and reliable code while also providing help with other task like code reviews, documentation, and testing. We call this approach IDD-AI or Individual Driven Developemt AI.
+
+1. Research - Research the requirements and specifications of the project.
+2. Identify - Identify the key components and technologies that are needed to build the project. (use opensource)
+3. Transform - Transform the requirements and specifications from the code to a langauge agnostic abstract contract (YAML)
+4. Inform - Use the abstract contracts to inform the design of the system and the components.
+5. Generate - Use AI to generate the initial code based on the abstract contracts.
+6. Implement - Implement the code in the codebase.
+7. Test - Test the code to ensure it meets the requirements and specifications.
+8. Iterate - Iterate the code to improve the design and implementation.
+9. Review - Review the code to ensure it meets the requirements and specifications.
+10. Release - Release the code to the public.
+
+Or RITIGITIRR pronounced Rih-tih-gih-tirr
+
+The we wash rinse and repeat for each project. When we are done we have a fully functional and robust implementation of the requirements and specifications we will still follow this pattern for enhancements, bug fixes, and new features.
+
+The API Specifications are in inbox/spec_packagename
+The Concrete Implementations are in inbox/src_packagename
+
+The directory structure for the project is as follows:
+
+config/ = configuration files
+devops/ = docker and kubernetes configuration
+docs/   = documentation
+examples/ = example applications demonstrating using the Platform API
+packages/ = platform packages
+resources = images, icons, and other resources
+scripts/ = utility scripts
+templates/ = starter templates
+tests/ = repository wide integration tests
+tools/ = project wide tools
+utils/ = cli, console, and other utilities
+
+Protevus Platform is a hard-fork of Angel3 that is being refactored and rebranded to be Protevus Platform
+For now all references to Angel3 remain the same, but in the future we will be changing them to Protevus or Platform
+You must always refer to the project as Platform, not Protevus or Angel3
+
+You must always prefer leveraging existing sanctioned angel3 packages as dependencies where possible as most of them will be replace and can't be relied on initially.
+
+You must always prefer leveraging existing standard dart packages as dependencies where possible
+You will always prefer leveraging any packages that we can from pub.dev or github.com dart/flutter ecosystem
+
+Our goal is to reimplement the laravel illuminate packages as angel3 packages in short bringing Laravel to Dart
+Our goal is to reach feature parity with the illuminate api so we must adhere to the specifications of laravel's api as we reimplement the illuminate packages
+
+We will not reimplement any packages that are not part of laravel, such as symfony packages, or any other packages that are not part of the laravel framework as our goal is to have pure dart implementations so we must find packages in the dart ecosystem where possible or create the feature in dart.
+
+We will not be re-implementing some features of laravel that would require reinventing wheels, for example angel3's server system is more then sufficiant and consist of the following angel3 packages which we will be initally keeping. Container, Framework, Route Http_Exception, Mock_Request, Modal. All other Illuminate packages will be reimplemented in dart. This list of keepers may change as we begin our phases of development.
+
+You must always take the following points into consderation when planning and executing your task.
+
+1. Dart and Flutter ecosystem awareness:
+   - Stay updated with the latest Dart language features and best practices.
+   - Consider Flutter compatibility for components that might be used in mobile/web applications.
+   - Utilize popular Dart packages when appropriate, but be mindful of adding unnecessary dependencies.
+
+2. Performance considerations:
+   - Implement benchmarking tools to compare performance with both Laravel and the original Angel3.
+   - Use Dart's profiling tools to identify and optimize bottlenecks.
+   - Consider implementing lazy loading and deferred initialization where appropriate.
+
+3. Asynchronous programming:
+   - Leverage Dart's async/await and Future-based programming extensively.
+   - Implement proper error handling and cancellation for asynchronous operations.
+   - Consider using Streams for reactive programming where appropriate.
+
+4. Code style and structure:
+   - Follow Dart's official style guide and linting rules.
+   - Implement consistent error handling and logging practices across all packages.
+   - Use Dart's strong typing system to its full potential, including generics and type inference.
+
+5. Testing strategy:
+   - Implement both unit and integration tests for all components.
+   - Use mock objects and dependency injection to facilitate easier testing.
+   - Implement property-based testing for complex algorithms or data structures.
+
+6. Documentation:
+   - Use Dart's documentation comments extensively.
+   - Provide examples in documentation for all public APIs.
+   - Create architecture decision records (ADRs) for significant design choices.
+
+7. Internationalization and localization:
+   - Design with i18n in mind from the start.
+   - Use Dart's intl package for formatting dates, numbers, and plurals.
+
+8. Error handling and logging:
+   - Implement a consistent error handling strategy across all packages.
+   - Create custom exception classes where appropriate.
+   - Implement structured logging with different log levels.
+
+9. Security:
+   - Implement security best practices, including input validation, output encoding, and CSRF protection.
+   - Use secure random number generation for cryptographic operations.
+   - Implement rate limiting and throttling mechanisms.
+
+10. Dependency management:
+    - Use Dart's pub tool effectively for package management.
+    - Consider implementing a monorepo structure for managing multiple packages.
+
+11. Compatibility layers:
+    - Implement compatibility layers or wrappers to ease migration from Angel3 to the new framework.
+    - Provide migration scripts or tools where possible.
+
+12. Extensibility:
+    - Design components with extensibility in mind, allowing for easy customization and overriding of default behaviors.
+    - Implement plugin systems where appropriate.
+
+13. Configuration:
+    - Implement a flexible configuration system that supports different environments (development, testing, production).
+    - Support both file-based and environment variable-based configuration.
+
+14. CLI tools:
+    - Develop CLI tools to assist in common development tasks (e.g., generating boilerplate code, running migrations).
+    - Ensure CLI tools are cross-platform compatible.
+
+15. Database abstraction:
+    - Implement database migrations and seeders.
+    - Support multiple database systems, including NoSQL databases.
+
+16. API design:
+    - Follow RESTful principles when designing APIs.
+    - Consider implementing GraphQL support.
+
+17. Caching strategies:
+    - Implement various caching mechanisms (in-memory, file-based, distributed).
+    - Provide cache invalidation strategies.
+
+18. Scalability:
+    - Design components with horizontal scalability in mind.
+    - Implement support for distributed systems and microservices architecture.
+
+19. Metrics and monitoring:
+    - Implement instrumentation for gathering metrics.
+    - Provide hooks for integrating with monitoring systems.
+
+20. Dependency injection:
+    - Implement a robust dependency injection system.
+    - Support both constructor and property injection.
+
+21. Reflection and metadata:
+    - Utilize Dart's reflection capabilities where appropriate.
+    - Implement custom metadata annotations for declarative programming.
+
+22. Error reporting:
+    - Implement integration with error reporting services (e.g., Sentry).
+    - Provide detailed stack traces and context for errors.
+
+23. Code generation:
+    - Utilize Dart's build system for code generation where appropriate.
+    - Implement source code generators for repetitive tasks.
+
+24. Versioning:
+    - Follow semantic versioning principles.
+    - Maintain a detailed changelog.
+
+25. Community engagement:
+    - Set up issue templates and contribution guidelines on GitHub.
+    - Implement a code of conduct for the project.
+
+26. Null Safety
+- Implement sound null safety throughout the entire codebase.
+- Utilize Dart's null safety features, including:
+  - Nullable and non-nullable types
+  - Late variables
+  - Null-aware operators
+- Perform null checks where necessary and provide clear documentation on nullability for all public APIs.
+- Use the `required` keyword for named parameters that must not be null.
+- Leverage the `?`, `!`, and `??` operators appropriately to handle potential null values.
+- Implement proper error handling for cases where null values are unexpected.
+- When interfacing with external code or APIs that are not null-safe:
+  - Use the `dynamic` type or appropriate cast operations cautiously
+- Utilize the `Never` type for functions that never return normally (i.e., always throw an exception or loop forever).
+- Consider using the `late` keyword for variables that are initialized after their declaration but before they're used.
+- When working with collections:
+  - Prefer using nullable item types (e.g., `List<String?>`) over nullable collections (e.g., `List<String>?`) where appropriate
+- Use static analysis tools to catch potential null safety issues early in the development process.
+- When migrating existing code:
+  - Use the Dart migration tool
+  - Carefully review all changes
+- Educate contributors on null safety best practices and include null safety checks in code review processes.
+
+Here are some notes that you should always keep in mind when working with the project
+
+Here's the content formatted in Markdown:
+
+## General Guidelines
+
+- Always consider the idiomatic Dart approach when implementing Laravel features.
+- Maintain compatibility with existing Angel3 applications where possible.
+- Prioritize performance and scalability in all implementations.
+- Write comprehensive tests for each component, aiming for high code coverage.
+- Document all public APIs and provide usage examples.
+- Consider cross-platform compatibility (server, web, mobile) where applicable.
+- Keep security as a top priority, especially when implementing authentication and encryption features.
+- Regularly refactor and optimize code as the project progresses.
+- Engage with the Angel3 community for feedback and contributions throughout the development process.
+
+## Advanced Implementation Considerations
+
+- When implementing advanced features like Telescope or Dusk, consider how they can be adapted to work well in a Dart ecosystem.
+- Pay special attention to how Facades and Macroable traits can be implemented in Dart, as these are core to Laravel's flexibility but may not have direct equivalents in Dart.
+- For packages like Scout and Passport, research Dart-specific best practices for implementing search and OAuth2 functionalities.
+- When working on Blade-like templating, consider how to balance between staying close to Blade's syntax and leveraging Dart's language features.
+
+## Dart-Specific Considerations
+
+- Always consider the implications of Dart's strong typing when implementing dynamic features from Laravel.
+- Look for opportunities to leverage Dart's unique features, such as isolates for concurrency, where appropriate.
+
+The Project Road Map is in @Roadmap Book
+
+You now have access to all the information that all team members need to start working on the project.

.devcontainer/devcontainer.json

@@ -0,0 +1,6 @@
+{
+  "image": "dart:3.4",
+  "forwardPorts": [3000,5000],
+  "features": {
+  }
+}

.fork

@@ -0,0 +1 @@
+Hard-Fork of Angel3 Master Repo 2024-10-01 Will Advance to Version 9.x

.pubignore

@@ -0,0 +1,2 @@
+.DS_Store
+tasks.json

devops/README.md

@@ -0,0 +1,75 @@
+# Protevus Platform DevOps
+
+This directory contains Docker and Kubernetes configurations for the Protevus Platform. It is organized to support our containerization and orchestration needs across different environments.
+
+## Directory Structure
+
+```
+devops/
+├── docker/
+│   ├── Dockerfile
+│   ├── docker-compose.yml
+│   └── .dockerignore
+├── kubernetes/
+│   ├── deployment.yaml
+│   ├── service.yaml
+│   ├── ingress.yaml
+│   └── configmap.yaml
+├── scripts/
+│   ├── docker-build.sh
+│   ├── docker-push.sh
+│   ├── k8s-deploy.sh
+│   └── k8s-rollback.sh
+└── README.md
+```
+
+### docker/
+
+This directory contains Docker-related files for building and running the Protevus Platform in containers.
+
+- `Dockerfile`: Defines the container image for the Protevus Platform.
+- `docker-compose.yml`: Configures multi-container Docker applications for local development.
+- `.dockerignore`: Specifies which files and directories should be excluded when building Docker images.
+
+### kubernetes/
+
+The kubernetes/ directory houses Kubernetes manifests for deploying and managing the Protevus Platform in a Kubernetes cluster.
+
+- `deployment.yaml`: Defines the deployment configuration for the Protevus Platform.
+- `service.yaml`: Specifies the service configuration for exposing the platform.
+- `ingress.yaml`: Configures ingress rules for routing external traffic to the service.
+- `configmap.yaml`: Stores configuration data that can be consumed by pods.
+
+### scripts/
+
+This directory contains utility scripts for Docker and Kubernetes operations.
+
+- `docker-build.sh`: Script for building Docker images.
+- `docker-push.sh`: Script for pushing Docker images to a registry.
+- `k8s-deploy.sh`: Script for deploying the application to a Kubernetes cluster.
+- `k8s-rollback.sh`: Script for rolling back a Kubernetes deployment.
+
+## Usage Guidelines
+
+1. Use the provided scripts in the `scripts/` directory for common Docker and Kubernetes operations.
+2. Ensure all configuration files are properly parameterized for different environments (dev, staging, production).
+3. Keep sensitive information (like passwords and API keys) out of these files and use Kubernetes secrets instead.
+4. Regularly update and test these configurations as the Protevus Platform evolves.
+
+## Deployment Process
+
+1. Build the Docker image using `scripts/docker-build.sh`.
+2. Push the image to the container registry with `scripts/docker-push.sh`.
+3. Deploy to Kubernetes using `scripts/k8s-deploy.sh`.
+4. If needed, rollback the deployment using `scripts/k8s-rollback.sh`.
+
+## Contributing
+
+When contributing to the DevOps configurations:
+
+1. Test all changes thoroughly in a non-production environment before applying to production.
+2. Document any new scripts or significant changes to existing configurations.
+3. Follow Kubernetes and Docker best practices for security and efficiency.
+4. Submit a pull request with a clear description of the changes and their purpose.
+
+For any questions or suggestions regarding the DevOps setup, please contact the Protevus Platform infrastructure team.

devops/docker/README.md

@@ -0,0 +1,172 @@
+# Docker Services
+
+The required applications by the framework can be run using the docker compose files provided in this folder.
+
+## PostreSQL
+
+### Starting the PostreSQL container
+
+    ```bash
+    docker compose -f docker-compose-pg.yml -p pg up -d
+    ```
+
+### Stopping the PostreSQL container
+
+    ```bash
+    docker compose -f docker-compose-pg.yml -p pg stop
+    docker compose -f docker-compose-pg.yml -p pg down
+    ```
+
+### Checking the PostreSQL container log
+
+    ```bash
+    docker logs docker-pg-1 -f
+    ```
+
+### Running psql
+
+    ```bash
+    docker exec -it <container id> /bin/bash
+    psql --username postgres
+    ```
+
+### Create PostgreSQL database, user and grant access
+
+    ```sql
+    create database orm_test;
+    create user test with encrypted password 'test123';
+    grant all privileges on database orm_test to test;
+    ```
+
+## MariaDB
+
+### Starting the MariaDB container
+
+    ```bash
+    docker compose -f docker-compose-mariadb.yml -p maria up -d
+    ```
+
+### Stopping the MariaDB container
+
+    ```bash
+    docker compose -f docker-compose-mariadb.yml -p maria stop
+    docker compose -f docker-compose-mariadb.yml -p maria down
+    ```
+
+### Checking the MariaDB container log
+
+    ```bash
+    docker logs maria-mariadb-1 -f
+    ```
+
+### Create MariaDB database, user and grant access
+
+    ```sql
+    create database orm_test;
+    
+    -- Granting localhost access only
+    create user 'test'@'localhost' identified by 'test123';
+    grant all privileges on orm_test.* to 'test'@'localhost';
+
+    -- Granting localhost and remote access
+    create user 'test'@'%' identified by 'test123';
+    grant all privileges on orm_test.* to 'test'@'%';
+    ```
+
+## MySQL
+
+### Starting the MySQL container
+
+    ```bash
+    docker compose -f docker-compose-mysql.yml -p mysql up -d
+    ```
+
+### Stopping the MySQL container
+
+    ```bash
+    docker compose -f docker-compose-mysql.yml -p mysql stop
+    docker compose -f docker-compose-mysql.yml -p mysql down
+    ```
+
+### Checking the MySQL container log
+
+    ```bash
+    docker logs mysql-mysql-1 -f
+    ```
+
+### Create MySQL database, user and grant access
+
+    ```sql
+    create database orm_test;
+    
+    -- Granting localhost access only
+    create user 'test'@'localhost' identified by 'test123';
+    grant all privileges on orm_test.* to 'test'@'localhost';
+
+    -- Granting localhost and remote access
+    create user 'test'@'%' identified by 'test123';
+    grant all privileges on orm_test.* to 'test'@'%';
+    ```
+
+## MongoDB
+
+### Starting the MongoDB container
+
+    ```bash
+    docker compose -f docker-compose-mongo.yml -p mongo up -d
+    ```
+
+### Stopping the MongoDB container
+
+    ```bash
+    docker compose -f docker-compose-mongo.yml -p mongo stop
+    docker compose -f docker-compose-mongo.yml -p mongo down
+    ```
+
+### Checking the MongoDB container log
+
+    ```bash
+    docker logs mongo-mongo-1 -f
+    ```
+
+## rethinkDB
+
+### Starting the rethinkDB container
+
+    ```bash
+    docker compose -f docker-compose-rethinkdb.yml -p rethink up -d
+    ```
+
+### Stopping the rethinkDB container
+
+    ```bash
+    docker compose -f docker-compose-rethinkdb.yml -p rethink stop
+    docker compose -f docker-compose-rethinkdb.yml -p rethink down
+    ```
+
+### Checking the rethinkDB container log
+
+    ```bash
+    docker logs rethink-rethinkdb-1 -f
+    ```
+
+## Redis
+
+### Starting the Redis container
+
+    ```bash
+    docker compose -f docker-compose-redis.yml -p redis up -d
+    ```
+
+### Stopping the Redis container
+
+    ```bash
+    docker compose -f docker-compose-redis.yml -p redis stop
+    docker compose -f docker-compose-redis.yml -p redis down
+    ```
+
+### Checking the Redis container log
+
+    ```bash
+    docker logs redis-redis-1 -f
+    ```

devops/docker/services/docker-compose-mariadb.yml

@@ -0,0 +1,19 @@
+services:
+  mariadb:
+    image: mariadb:latest
+    restart: "no"
+    ports:
+      - "3306:3306"
+    environment:
+      - MARIADB_ROOT_PASSWORD=Qwerty
+    volumes:
+      - "mariadb:/var/lib/mysql"
+    networks:
+      - appnet
+
+volumes:
+  mariadb:
+    driver: local
+
+networks:
+  appnet:

devops/docker/services/docker-compose-mongo.yml

@@ -0,0 +1,37 @@
+services:
+
+  mongo:
+    image: mongo
+    restart: no
+    ports:
+      - 27017:27017
+    environment:
+      MONGO_INITDB_ROOT_USERNAME: root
+      MONGO_INITDB_ROOT_PASSWORD: Qwerty
+      MONGO_INITDB_DATABASE: local
+    volumes:
+      - "mongo:/data/db"
+    networks:
+      - appnet
+
+  mongo-express:
+    image: mongo-express
+    restart: no
+    depends_on:
+      - mongo
+    ports:
+      - 8081:8081
+    environment:
+      ME_CONFIG_MONGODB_ADMINUSERNAME: root
+      ME_CONFIG_MONGODB_ADMINPASSWORD: Qwerty
+      ME_CONFIG_MONGODB_URL: mongodb://root:Qwerty@mongo:27017/
+      ME_CONFIG_BASICAUTH: false
+    networks:
+      - webnet
+
+volumes:
+  mongo:
+    driver: local
+
+networks:
+  appnet:

devops/docker/services/docker-compose-mysql.yml

@@ -0,0 +1,19 @@
+services:
+  mysql:
+    image: mysql:latest
+    restart: "no"
+    ports:
+      - "3306:3306"
+    environment:
+      - MYSQL_ROOT_PASSWORD=Qwerty
+    volumes:
+      - "mysql:/var/lib/mysql"
+    networks:
+      - appnet
+
+volumes:
+  mysql:
+    driver: local
+
+networks:
+  appnet:

devops/docker/services/docker-compose-pg.yml

@@ -0,0 +1,31 @@
+services:
+  pgdb:
+    image: postgres:latest
+    restart: "no"
+    ports:
+      - "5432:5432"
+    environment:
+      - POSTGRES_USER=postgres
+      - POSTGRES_PASSWORD=postgres
+    volumes:
+      - "db:/var/lib/postgresql/data"
+    networks:
+      - appnet
+
+  pgadmin4:
+    image: dpage/pgadmin4:latest
+    restart: "no"
+    ports:
+      - "5050:80"
+    environment:
+      - PGADMIN_DEFAULT_EMAIL=admin@mydomain.com
+      - PGADMIN_DEFAULT_PASSWORD=Qwerty
+    networks:
+      - appnet
+
+volumes:
+  db:
+    driver: local
+
+networks:
+  appnet:

devops/docker/services/docker-compose-redis.yml

@@ -0,0 +1,20 @@
+services:
+  redis:
+    image: redis:latest
+    restart: "no"
+    ports:
+      - "5432:5432"
+    environment:
+      - POSTGRES_USER=postgres
+      - POSTGRES_PASSWORD=postgres
+    volumes:
+      - "redis:/data"
+    networks:
+      - appnet
+
+volumes:
+  redis:
+    driver: local
+
+networks:
+  appnet:

devops/docker/services/docker-compose-rethinkdb.yml

@@ -0,0 +1,19 @@
+services:
+  rethinkdb:
+    image: rethinkdb:latest
+    restart: "no"
+    ports:
+      - "8080:8080"
+      - "28015:28015"
+      - "29015:29015"
+    volumes:
+      - "rethinkdb:/data"
+    networks:
+      - appnet
+
+volumes:
+  rethinkdb:
+    driver: local
+
+networks:
+  appnet:

docs/Testing.md

@@ -0,0 +1,10 @@
+# Performance Testing
+
+The performance test can be run with the following tools.
+
+## WRT
+
+    ```bash
+    wrk -t12 -c400 -d30s http://localhost:8080/query?queries=20
+    ```
+This runs a benchmark for 30 seconds, using 12 threads, and keeping 400 HTTP connections open.

helpers/README.md

@@ -0,0 +1,68 @@
+
+# Protevus Platform Helpers
+
+This directory contains various helper functionalities, tools, and utilities for the Protevus Platform. It is organized into subdirectories to maintain a clear structure and separation of concerns.
+
+## Directory Structure
+
+```
+helpers/
+├── cli/
+├── console/
+├── tools/
+└── utilities/
+```
+
+### cli/
+
+This directory contains command-line interface tools and scripts specific to the Protevus Platform. These are typically used for development, deployment, or maintenance tasks that are run directly from the command line.
+
+Examples:
+- Database migration scripts
+- Code generation tools
+- Deployment scripts
+
+### console/
+
+The console/ directory houses console commands and utilities, similar to Laravel's Artisan commands. These are interactive tools that provide a user-friendly interface for various platform operations.
+
+Examples:
+- REPL (Read-Eval-Print Loop) for the Protevus Platform
+- Interactive configuration tools
+- Database seeding commands
+
+### tools/
+
+This directory is for larger, more complex helper applications or scripts used in development, testing, or deployment of the Protevus Platform. These tools often combine multiple functionalities or interact with external services.
+
+Examples:
+- Automated testing suites
+- Performance profiling tools
+- Documentation generators
+
+### utilities/
+
+The utilities/ directory contains general-purpose utility functions and smaller helper scripts. These are typically reusable across different parts of the platform and provide common functionality.
+
+Examples:
+- String manipulation functions
+- Date and time helpers
+- File system operations
+
+## Usage Guidelines
+
+1. Place new helpers in the appropriate subdirectory based on their purpose and complexity.
+2. Maintain consistency in naming conventions and file structures within each subdirectory.
+3. Document each helper, tool, or utility with clear comments and usage examples.
+4. Update this README when adding new significant helpers or changing the structure.
+
+## Contributing
+
+When contributing new helpers:
+
+1. Ensure your code follows the Protevus Platform coding standards.
+2. Write tests for your helpers when applicable.
+3. Update or create documentation for new functionalities.
+4. Submit a pull request with a clear description of the new helper and its purpose.
+
+For any questions or suggestions regarding the helpers structure, please contact the Protevus Platform core development team.

platform.code-workspace

@@ -1,60 +0,0 @@
-{
-	"folders": [
-		{
-			"path": "."
-		},
-		{
-			"path": "stubs/protevus"
-		},
-		{
-			"path": "stubs/ignition"
-		},
-		{
-			"path": "stubs/console"
-		},
-		{
-			"path": "stubs/service"
-		},
-		{
-			"path": "stubs/desktop"
-		},
-		{
-			"path": "stubs/web"
-		},
-		{
-			"path": "stubs/mobile"
-		},
-		{
-			"path": "stubs/IoT"
-		},
-		{
-			"path": "resources/branding"
-		},
-		{
-			"path": "resources/ghb-profile"
-		},
-		{
-			"path": "resources/org-profile"
-		},
-		{
-			"path": "resources/per-profile"
-		},
-		{
-			"path": "../resources"
-		}
-	],
-	"settings": {
-        "files.exclude": {
-            "**/resources/**/tests": true
-        },
-        "search.exclude": {
-            "**/resources/**/tests": true
-        },
-        "dart.testExclude": [
-            "**/resourcese/**"
-        ],
-        "files.watcherExclude": {
-            "**/resources/**": true
-        }
-    }
-}

resources/README.md

@@ -0,0 +1,72 @@
+# Protevus Platform Resources
+
+This directory contains various static resources used throughout the Protevus Platform. These resources include images, icons, and other assets that contribute to the platform's visual and functional elements.
+
+## Directory Structure
+
+```
+resources/
+├── images/
+│   ├── logos/
+│   ├── backgrounds/
+│   └── icons/
+├── fonts/
+├── locales/
+└── templates/
+```
+
+### images/
+
+This directory contains all image assets used in the Protevus Platform.
+
+- `logos/`: Contains logo variations for the platform and potentially partner logos.
+- `backgrounds/`: Includes background images used in the UI.
+- `icons/`: Houses individual icon files used throughout the platform.
+
+### fonts/
+
+The fonts/ directory contains custom font files used in the Protevus Platform UI. This ensures consistent typography across different environments.
+
+### locales/
+
+This directory contains localization files for internationalization (i18n) support. Each supported language should have its own subdirectory or file.
+
+### templates/
+
+The templates/ directory houses reusable UI templates or snippets that can be used across different parts of the platform.
+
+## Usage Guidelines
+
+1. Maintain a consistent naming convention for all resources (e.g., kebab-case for image files).
+2. Optimize images for web use to ensure fast loading times.
+3. Use SVG format for icons and logos where possible for better scalability.
+4. Keep font files in web-friendly formats (e.g., WOFF2, WOFF).
+5. Organize localization files in a structured manner, using standard formats like JSON or YAML.
+
+## Adding New Resources
+
+When adding new resources:
+
+1. Place the resource in the appropriate subdirectory.
+2. Ensure the resource doesn't duplicate existing ones.
+3. For images and icons, provide both regular and high-DPI (@2x, @3x) versions if applicable.
+4. Update any relevant asset manifests or indexes.
+
+## Updating Existing Resources
+
+When updating resources:
+
+1. Maintain backwards compatibility where possible.
+2. Update all relevant sizes/versions of the resource.
+3. If replacing a resource, ensure it's not being used elsewhere in the platform before removing the old version.
+
+## Contributing
+
+When contributing new resources:
+
+1. Ensure all assets are properly licensed for use in the Protevus Platform.
+2. Optimize assets for web use before committing.
+3. Update documentation if adding new types of resources or changing existing structures.
+4. Submit a pull request with a clear description of the new or updated resources.
+
+For any questions or suggestions regarding the resources, please contact the Protevus Platform design team.