docs: BEEPs 2-6

* Add 3 BEEP lessgo

* Agents proposal

* Add a new proposal for remote imports

website/proposals/0002-project-target/index.mdx

@@ -0,0 +1,69 @@
+---
+title: BEEP 2 - Target and User Persona
+authors: [NickSeagull]
+date: 2024-01-25T00:00
+---
+
+:::tip STATUS - ACCEPTED
+:::
+
+## Introduction
+
+This document defines the target audience and [user persona](<https://en.wikipedia.org/wiki/Persona_(user_experience)>) for the Booster Framework project, aligning it with its current usage and user base.
+
+While maintaining a focus on guiding the design and development process of the Booster Framework, this definition is not an exclusionary rule but a strategic tool for decision-making. The framework is inclusive and welcomes a diverse range of users, though particular emphasis is placed on specific user groups in design and functionality.
+
+## Target Audience
+
+The primary target audience for the Booster Framework is developers in large-scale enterprise environments, familiar with enterprise technologies like Java, .NET, or similar. This includes those working in Fortune 500 companies, especially those transitioning from traditional enterprise technologies to TypeScript in complex projects such as financial transactions.
+
+Additionally, the Booster Framework is gaining traction among hobbyist developers for personal projects, thanks to its ease of use and efficient learning curve. This secondary audience appreciates the framework for its quick setup, minimal configuration, and straightforward deployment, which are ideal for smaller-scale, personal projects.
+
+### Who's not the target audience
+
+- Developers deeply invested in exploring advanced theoretical concepts in programming without practical application.
+- Those who prefer frameworks with a steep learning curve or require extensive configuration.
+
+## User Persona
+
+### Primary Persona: Enterprise Developer
+- **Name**: Aarya
+- **Role**: Senior Enterprise Software Developer
+
+#### Actions, Motivations, and Pains
+
+- **What do I do?**
+  - Work on large-scale TypeScript projects, transitioning from a background in traditional enterprise technologies.
+  - Develop robust applications for sectors like finance, requiring high security and reliability.
+- **Why do I do it?**
+  - To apply my experience in enterprise technologies in new, dynamic environments.
+  - To contribute significantly to business-critical projects.
+- **What do I want?**
+  - A framework that bridges my existing knowledge with modern development practices.
+  - Tools that ensure efficiency, security, and compatibility with enterprise standards.
+- **What's stopping me?**
+  - Adapting to new technologies while maintaining high standards of enterprise development.
+  - Balancing rapid development with regulatory and security requirements.
+
+### Secondary Persona: Hobbyist Developer
+- **Name**: Navin
+- **Role**: Hobbyist Developer
+
+#### Actions, Motivations, and Pains
+
+- **What do I do?**
+  - Develop personal projects in my spare time, exploring new technologies and ideas.
+  - Seek tools that enable quick and easy project setup and deployment.
+- **Why do I do it?**
+  - To learn new skills and stay updated with the latest technology trends.
+  - To bring personal project ideas to life efficiently.
+- **What do I want?**
+  - A user-friendly framework that doesn't require extensive setup or configuration.
+  - Resources that help me quickly understand and apply the framework.
+- **What's stopping me?**
+  - Overly complex tools that require significant time investment to learn.
+  - Lack of clear, beginner-friendly documentation and community support.
+
+## Conclusion
+
+This document outlines the dual focus of the Booster Framework's target audience and user personas. Our development and design efforts are directed towards supporting both the enterprise developers transitioning from traditional technologies to TypeScript, and the growing community of hobbyist developers seeking an accessible and easy-to-use framework for personal projects. This approach ensures the Booster Framework remains versatile and relevant across different scales and scopes of software development.

website/proposals/0003-principles-of-design/index.mdx

@@ -0,0 +1,53 @@
+---
+title: BEEP 3 - Principles of Design
+authors: [NickSeagull]
+date: 2024-01-25T00:01
+---
+
+:::tip STATUS - ACCEPTED
+:::
+
+## Introduction
+
+This document lays out the design principles guiding the design and implementation processes of the Booster Framework. These principles are crucial in steering both high-level and low-level decision-making within the project. They are pivotal in ensuring that the project remains focused on the correct aspects of design and implementation, always keeping in mind [the target audience and user persona](/blog/0002-project-target), as they are the most important stakeholders of the project.
+
+## Principle of Least Astonishment
+
+The Principle of Least Astonishment, also known as the Principle of Least Surprise, is a fundamental guideline in user interface and software design. It stresses the importance of creating systems that behave in ways consistent with user expectations, minimizing surprise and confusion. This principle is crucial in the Booster Framework, ensuring that the framework's components and functionalities align with the conventions familiar to both enterprise and hobbyist developers, thereby enhancing their experience and usability. It is particularly relevant in a context where developers are transitioning from traditional enterprise technologies to modern TypeScript-based environments, as it aids in reducing the learning curve and preventing user astonishment.
+
+### Examples
+
+- Favoring JSON or YAML for configuration over more complex formats, aligning with common industry practices.
+- Integrating with popular version control systems like Git and widely-used platforms such as GitHub or GitLab.
+- Recommending mainstream IDEs like Visual Studio Code, which are familiar to a broad range of developers.
+- Ensuring that the framework's functionalities and syntax are intuitive and align with common programming practices.
+
+## Principle of Developer Happiness
+
+The Principle of Developer Happiness is centered around creating an environment and culture that aligns with developers' professional and personal expectations, thereby enhancing satisfaction and retention. This principle is key in the Booster Framework, focusing on an engaging experience and a supportive culture where developers, regardless of their background, feel valued and connected to the project's mission. It also involves using efficient tools and technologies to streamline the development process and saving time, along with continuously assessing developer efficiency and satisfaction.
+
+### Examples
+
+- **Comprehensive Documentation**: Providing clear and user-friendly documentation with practical examples for both enterprise and hobbyist developers.
+- **Active Community Engagement**: Encouraging participation and collaboration within the open-source community.
+- **Transparent Decision-Making**: Keeping language development and framework enhancement decisions transparent.
+- **Inclusive Onboarding**: Offering learning resources and support for developers of varying skill levels.
+- **Acknowledgement of Contributions**: Recognizing and valuing contributions from the community, regardless of their scale.
+- **Open Feedback Channels**: Maintaining open channels for feedback, suggestions, and issue reporting from users and contributors.
+
+## Principle of Least Effort
+
+The Principle of Least Effort emphasizes the idea that entities will naturally gravitate towards the solution that requires the least amount of work or complexity. In the context of the Booster Framework, this principle is applied to create systems and interfaces that are straightforward, easy to comprehend, and simple to interact with. This reduces the cognitive and operational load on users, particularly those transitioning from different technology backgrounds. For developers, it encourages the creation of code and architectures that are clean, efficient, and easy to understand and modify. By adhering to this principle, the Booster Framework aims to offer user-friendly applications and sustainably maintainable codebases, promoting efficient interactions for all users.
+
+### Examples
+
+- **Intuitive Syntax and Features**: Designing the framework with a simple, intuitive syntax that reduces cognitive load, particularly for those new to TypeScript.
+- **Streamlined Documentation**: Providing clear, concise documentation that helps users quickly understand and utilize the framework.
+- **Robust Standard Libraries**: Including comprehensive standard libraries that simplify common development tasks.
+- **Effective Error Handling**: Implementing user-friendly error messages and handling mechanisms for efficient problem-solving.
+- **Strong Community Support**: Building a supportive community for knowledge sharing and collaboration, reducing the effort needed to overcome challenges.
+- **Simplified Version Management**: Facilitating easy version management and updates for seamless adoption of new features and improvements.
+
+## Conclusion
+
+The design principles outlined for the Booster Framework serve as a guiding light for the project's development and implementation processes. The Principle of Least Astonishment ensures system behavior aligns with user expectations, enhancing usability. The Principle of Developer Happiness focuses on creating a fulfilling environment for developers, while the Principle of Least Effort promotes simplicity and efficiency. These principles collectively ensure that the Booster Framework remains attuned to the needs of its diverse user base, from enterprise developers to hobbyist programmers, ensuring a user-centric, efficient, and developer-friendly journey throughout its development.

website/proposals/0004-semantic-versioning/index.mdx

@@ -0,0 +1,36 @@
+---
+title: BEEP 4 - Semantic Versioning
+authors: [NickSeagull]
+date: 2024-01-25T00:03
+---
+
+:::tip STATUS - ACCEPTED
+:::
+
+## Introduction
+
+In the context of the Booster Framework ecosystem, we adopt the [Semantic Versioning](https://semver.org/) (SemVer) schema. SemVer is a system of rules and guidelines for assigning and incrementing version numbers within our software development process. By using SemVer, the Booster Framework aims to manage the complexities of dependencies as the ecosystem evolves. The primary goal of implementing Semantic Versioning is to ensure that our version numbers are transparent and informative, effectively communicating the nature of changes in our software to both enterprise and hobbyist developers.
+
+## Impact on Principle of Least Astonishment
+
+Semantic Versioning positively impacts the Principle of Least Astonishment. It is a widely recognized and used schema in numerous open-source projects. Adhering to a clear and consistent version numbering system (Major.Minor.Patch) reduces confusion and surprise for developers and users alike. This predictability in versioning enhances the user experience and facilitates the management of software dependencies.
+
+## Impact on Principle of Developer Happiness
+
+Semantic Versioning aligns with the Principle of Developer Happiness by offering a systematic and standardized approach to versioning. This method simplifies the process of releasing and updating software packages, allowing developers to confidently implement changes. Knowing that version numbers accurately reflect the impact of changes reduces the stress related to dependency management and enables developers to concentrate on innovation and software improvement.
+
+## Impact on Principle of Least Effort
+
+Semantic Versioning supports the Principle of Least Effort by making the management of software dependencies more straightforward. By adhering to SemVer, developers can introduce backward-compatible changes without needing new major releases, thereby minimizing the effort needed for maintaining and updating software. Additionally, the clear documentation of public APIs and the use of version numbers to indicate compatibility simplify the integration of dependencies, reducing the effort needed for seamless software interactions.
+
+## Usage of SemVer in Early Development Phases
+
+During the initial development phases of Booster Framework projects, the major version will remain at 0. This indicates that breaking changes are likely to be frequent as the project evolves. Once the project achieves a stable state, the major version will be incremented to 1, signifying a reduction in the frequency of breaking changes.
+
+## Standardizing the Use of SemVer
+
+We advise using the Semantic Versioning schema as a standard across all Booster Framework projects. This uniformity will ensure coherence within the ecosystem. The Booster CLI tool should facilitate version management by inspecting exported functions and types, suggesting the next version based on the changes made.
+
+## Considerations
+
+It's important to note that changes in the implementation of a function, even without altering the API, can produce different results and are considered breaking changes. These should be reflected in the version number accordingly. For more information and examples, please refer to this [GitHub thread](https://github.com/semver/semver/issues/311).

website/proposals/0005-agent-codebase/index.mdx

@@ -0,0 +1,91 @@
+---
+title: BEEP 5 - Agent-Based Codebase Structure
+authors: [NickSeagull]
+date: 2024-01-25T00:04
+---
+
+:::tip STATUS - DRAFT
+:::
+
+## Introduction
+
+This document proposes a significant reorganization of the Booster Framework's folder structure to address current challenges in codebase management and to align with the principles of modularity and scalability. The current structure, `src/{commands,events,entities,read-models}/*.ts`, while functional, has shown limitations in managing complexity as the framework and the team grow.
+
+This proposal introduces a new structure based on the concept of "Agents" in event sourcing/event-driven systems, aiming to bring conceptual clarity and improved organization to the codebase. It can be thought as **the microservices approach, but more tailored to the event-driven** nature of Booster Framework.
+
+## Current Challenges
+
+The existing folder structure in the Booster Framework presents several challenges:
+
+- **Lack of Modularity**: The mixed nature of components (commands, events, entities, read-models) in a flat structure leads to difficulties in isolating specific functionalities or use cases.
+- **Scalability Concerns**: As the team and the codebase grow, the lack of hierarchical organization makes it increasingly challenging to manage and navigate the codebase.
+- **Interdependency Issues**: The current structure does not clearly delineate dependencies and relationships between different components, leading to potential conflicts and complexities.
+
+## Proposed Folder Structure
+
+The new folder structure is organized around the concept of "Agents", where each use case is encapsulated within its own subfolder. This approach mirrors the modular and event-driven nature of the Booster Framework.
+
+### Structure Overview
+
+- `src/`
+  - `agents/`
+    - `agent-name-1/`
+      - `commands/`
+      - `events/`
+      - `entities/`
+      - `read-models/`
+    - `agent-name-2/`
+      - `commands/`
+      - `events/`
+      - `entities/`
+      - `read-models/`
+    - ...
+  - `shared/`
+    - `common-entities/`
+    - `utilities/`
+    - ...
+
+### Guidelines for Naming Subfolders
+
+- **Reflective of Use Case**: Each subfolder (agent) should be named in a way that clearly reflects its specific use case or domain.
+- **Consistent Naming Convention**: A uniform naming convention should be adopted across all agents to maintain consistency and readability.
+
+## Benefits of the Reorganization
+
+- **Improved Modularity**: Each agent acts as a self-contained module, enhancing the clarity and separation of different aspects of the codebase.
+- **Enhanced Scalability**: This structure supports the growth of the team and the codebase, allowing for easier navigation and management.
+- **Facilitated Collaboration**: Teams can focus on specific agents without interfering with others, simplifying collaboration and reducing the risk of conflicts.
+- **Repository Splitting**: The modular nature of this structure allows for splitting the codebase into separate repositories if necessary for better scalability and management.
+
+## Addressing Potential Challenges
+
+### Interaction and Communication Between Agents
+
+- **Well-Defined Interfaces**: Clear interfaces and communication protocols between agents must be established to ensure smooth interactions.
+- **Shared Resources Management**: The `shared/` folder will house common entities and utilities, accessible to all agents while maintaining their independence.
+
+### Technical and Implementation Considerations
+
+- **Incremental Transition**: A phased approach to migrating to the new structure is recommended to minimize disruption.
+  - The team can start by putting everything in the `shared/` folder, then gradually move to the new structure.
+- **Documentation and Communication**: The team should be in charge of having documentation and communication sessions in order to ensure that everyone is on the same page and responsibilities are not duplicated.
+
+## Additional Ideas
+
+### Integration of AI Agents
+
+In line with the event-driven architecture of the Booster Framework, an intriguing extension to the proposed semantic codebase structure is the **incorporation of AI agents**. These agents, mirroring the structure of traditionally-programmed agents with `commands`, `events`, `read-models`, etc., would have their internal logic powered by **Large Language Models (LLMs)**.
+
+This integration aligns with the scalable and modular design of the framework, allowing AI agents to **autonomously handle specific tasks or workflows within their domain**. The use of AI agents could significantly enhance the framework's capabilities in areas such as:
+
+- **Automated decision-making**
+- **Predictive analytics**
+- **Personalized user interactions**
+
+Each AI agent would operate within its designated subfolder, ensuring a **clear delineation and manageable interaction** with regular agents, while adhering to the same communication protocols and interface standards established in the overall framework.
+
+This innovative approach opens new avenues for efficiency, creativity, and advanced functionalities within the Booster Framework ecosystem.
+
+## Conclusion
+
+The proposed semantic codebase structure for Booster Framework aims to address current challenges in codebase management while aligning with the principles of modularity and scalability. This reorganization, centered around the concept of "Agents", offers numerous benefits, including improved code separation, easier collaboration, and the potential for scalable codebase management.