@goplausible/algorand-mcp 3.0.7

package/dist/resources/knowledge/taxonomy/algokit:cli:architecture-decisions:2023-07-19_advanced_generate_command.md

@@ -0,0 +1,203 @@
+# Advanced `algokit generate` command
+
+- **Status**: Approved
+- **Owner:** Altynbek Orumbayev, Inaie Ignacio
+- **Deciders**: Rob Moore, Daniel McGregor, Alessandro Cappellato
+- **Date created**: 2023-07-19
+- **Date decided:** 2023-07-24
+- **Date updated**: 2023-07-24
+
+## Context
+
+The [Frontend Templates ADR](./2023-06-06_frontend-templates.md) introduced and expanded on AlgoKit's principles of Modularity and Maintainability by introducing a new set of official templates for quickly bootstrapping standalone `react` and `fullstack` projects showcasing best practices and patterns for building frontend and fullstack applications with Algorand. As a logical next step, we want to enable developers to extend existing projects instantiated from official templates with new files and features.
+
+## Requirements
+
+### 1. AlgoKit user should be able to use generate command to extend existing algokit compliant projects with new `files` of any kind
+
+This implies scenarios like:
+
+- Adding new contracts into existing algokit compliant projects.
+  > Algokit compliant projects are projects that were instantiated from official or community templates and follow the same structure and conventions.
+- Overriding existing files with new ones.
+- Adding new files into existing projects.
+
+Overall, we want to introduce a notion of `generators` which can be viewed as a modular self-sufficient template units that are hosted within template repositories and describe how to create or update files within projects instantiated from AlgoKit templates.
+
+Ruby on Rails has a similar concept of [generators](https://guides.rubyonrails.org/generators.html) which are used to create or update files within Rails projects. This can be used as a reference for inspiration.
+
+### 2. Template builder should be able to access a clear guideline and refer to official templates for examples on how to create `generators`
+
+This implies extension of existing starter guidelines available for template builders on [AlgoKit Docs](https://github.com/algorandfoundation/algokit-cli/blob/main/docs/tutorials/algokit-template.md) and using one or several official templates as a reference point.
+
+## Principles
+
+- **Modularity**: Artifacts dependant on `advanced algokit generate` command capabilities embedded into templates should follow guiding AlgoKit principles and expand on approaches already utilized in `react`, `fullstack` and `beaker` templates. This implies that giving developers flexibility to define any extra templating logic, allowing to create or update any files within projects instantiated from algokit templates.
+- **Maintainability**: The `advanced algokit generate` capabilities on `algokit-cli` and related artifacts on respective official templates should be easy to maintain and extend.
+- **Seamless onramp**: Great developer experience for template builders to create their own `generators` and user experience to use them via `advanced algokit generate` command should be a priority.
+
+All of the aforementioned requirements should be met in a way that is consistent with the guiding principles of AlgoKit or attempt to find a balanced trade of between the principles that satisfies the requirements. Refer to [AlgoKit Guiding Principles](../../docs/algokit.md#Guiding-Principles) for detailed reference on the principles.
+
+## Considered Options
+
+Based on preliminary research, all of the options below assume that:
+A `generator` is a self contained copier/jinja template that is hosted within a template repository and describes how to create or update files within projects instantiated from algokit templates. Hosting it along with the template is a necessity given that community based templates can follow different conventions, patterns and structure making it hard to attempt to generalize the logic of `generators` and make them work for all templates.
+
+### Option 1: Wrapping generators into self contained copier templates hidden within algokit templates
+
+This option implies that `generators` are self contained copier templates that are hidden within algokit templates and are not exposed to the end user. This option is inspired by [Ruby on Rails generators](https://guides.rubyonrails.org/generators.html) and [Yeoman generators](https://yeoman.io/authoring/).
+
+The main idea is to rely on `_templates_suffix` in copier.yamls to define 2 separate types of suffixes for `templates` and for `generators`:
+
+- Existing templates under all official algokit templates are already prefixed with `.jinja` hence we just need to explicitly prefix it with `.jinja` on root copier
+- The new generators jinja templates can be prefixed (for example) with alternative file extension for jinja files such as `.j2`. Which is also a common convention for jinja templates.
+- - This only works for files though for regular folders and cases like `{% if %}folder_name{% endif %}.j2` we need to wrap them into {% raw %} to that first pass when template initially initialized unwraps the content allowing second pass via generator to then use them as jinja templates. The only downside here is slightly longer file names for folders, but I think it's a reasonable tradeoff considering simplicity of the solution.
+
+Overview of the proposal can be summarized via the following diagram:
+
+```mermaid
+graph TB
+  T["Template Folder"]
+  T --> C["copier.yaml"]
+  T --> C1["..."]
+  T --> G[".algokit/generators"]
+
+  G --> G1["Generator 1"]
+  G1 --> E1["copier.yaml"]
+  G1 --> E2["..."]
+
+  G --> G2["..."]
+  G2 --> E3["..."]
+
+  G --> G3["Generator N"]
+  G3 --> E["copier.yaml"]
+  G3 --> E4["..."]
+```
+
+#### Pros
+
+- Generators are hidden within algokit templates and are not exposed to the end user. When user runs `algokit generate` command, cli presents a list of available generators to choose from. This makes it easier for user to understand what generators are available and what they do.
+- Generators are self contained copier templates giving template builders flexibility to do any kind of templating logic similar to what they can already do with regular templates.
+- Majority of implementation complexity is reduced by relying on copier as a backbone for generators feature.
+
+#### Cons
+
+- Generators are somewhat tightly coupled with individual algokit templates, which implies its not necessarily a matter of copy pasting generators from one template to another. This can be a problem for community template builders who want to reuse generators from official templates. However, this can be mitigated by providing clear guidelines on how to create generators and referring to official templates as a reference point. Additionally, it seems like a reasonable tradeoff given that templates can vastly differ in type, structure, conventions and patterns and it's significantly harder to generalize the logic of generators to make them work for all templates.
+
+#### Implementation details
+
+**1. Adjusting templates structure**
+
+For instance, if we assume existing `beaker` template, the new file/folder structure can look as follows:
+
+```
+template_content/.algokit # alternatively could be just `.algokit-generators`
+└── generators
+    └── {generator_name} # generator name can be anything
+        ├── copier.yaml # copier config for generator
+        └── smart_contracts # logic for adding new contracts to beaker template
+            └── {% raw %}{{ contract_name }}{% endraw %}
+                ├── contract.py.j2
+                ├── {% raw %}{% if language == 'python' %}deploy_config.py{% endif %}{% endraw %}.j2
+                └── {% raw %}{% if language == 'typescript' %}deploy-config.ts{% endif %}{% endraw %}.j2
+...rest of the template is left as is
+copier.yml
+```
+
+The `index.ts` and `config.py` files on beaker template need to be updated to auto import all contracts from sub folders at `smart_contracts` to eliminate the need for developers to manually import them after running the smart contract generator.
+
+> Please note, above is just an example that assumes the generator for adding new contracts, but the proposal is generic enough to support any kind of jinja-based templating logic.
+
+**2. Adjusting `.algokit.toml`**
+
+The proposal for new structure for defining generators in root algokit toml is as follows:
+
+```toml
+[generators.create_contract] # [generators.<generator_name>]
+description = "Adds new smart contract to existing project" # description of the generator, can appear in cli for extra info
+path = ".algokit/generators/create_contract"  # path that cli should grab to forward to copier copy
+```
+
+**3. Adjusting `algokit generate` command on cli**
+
+Next step in implementation part of the proposal is adjusting the `generator` command on `algokit-cli` to make sure it knows how to look for generators. The available generators can be provided to user via list picker (a.k.a ruby on rails style) by letting algokit scan contents of `algokit.toml` and look for `.generators` folder.
+
+a) Has no generators
+If algokit-cli can't find any generator configured then nothing change from current implementation.
+
+b) Has generators and user runs `algokit generate` command to see the list of available generators
+A new `click` command per each generator in `.algokit.toml` is added to the list of generate commands, that will list all available generators for the user to choose from.
+
+```bash
+algokit-cli generate
+
+---
+
+Usage: algokit generate [OPTIONS] COMMAND [ARGS]...
+
+  Generate code for an Algorand project.
+
+Options:
+  -h, --help  Show this message and exit.
+
+Commands:
+  client  Create a typed ApplicationClient from an ARC-32 application.json
+  smart-contract  Adds new smart contract to existing project
+```
+
+Then, to invoke the interactive flow via copier user runs:
+
+```bash
+algokit-cli generate smart-contract `name of the contract`
+```
+
+c) Has generators, user knows what to pick and wants to run it non interactively
+Using the generator configuration the `generator` will automatically add new `click` commands to the existing list of generate commands allowing the user to run them in the command line.
+
+```bash
+algokit-cli generate smart-contract -a contract_name=`name of the contract` -a language=python # passing extra arguments to generator similar to algokit init
+```
+
+**4. Testing and documentation**
+
+Lastly we need to make sure that the new feature is properly tested and documented. This includes:
+
+- Testing the new feature works as expected on all official templates that will host generators. This will imply adding a separate test suite that picks some default template state and run generators on top of them confirming that created artifacts are placed in expected locations and have expected content. Tests should be easy to follow and expand on existing tests suite on templates without introducing extra complexity.
+- Introduce new tutorial sections on [AlgoKit Docs](https://github.com/algorandfoundation/algokit-cli/blob/main/docs/tutorials/algokit-template.md) on how to create generators and refer to official templates as a reference point.
+
+### Option 2: Wrapping generators into self contained copier templates hosted on separate repositories
+
+This option proposes to host `generators` on separate set of repositories and use them as a dependency for algokit templates.
+`algokit.toml` can be extended on template repositories to list generators they depend on.
+
+The only distinction between this option and option 1 is that generators are hosted on separate repositories and are not hidden within algokit templates. Implying that they are not tightly coupled with algokit templates and can be reused/forked by community template builders to build their own generators.
+
+#### Pros
+
+- Generators are not tightly coupled with algokit templates and can be reused/forked by community template builders to build their own generators.
+- Generators can be versioned and updated independently from algokit templates.
+
+#### Cons
+
+- Developing and maintaining generators is significantly more complex due to the need to maintain separate repositories and versioning.
+- Official maintainers and community template builders need to be put extra effort at keeping generators generic enough to be reused by other templates. Given that templates can vastly differ in type, structure, conventions and patterns, this can be a challenge.
+- Given that copier is being considered as a backbone for generators feature, drawbacks outlined for hosting templates on monorepos in the [previous adr](2023-06-06_frontend-templates.md#option-1-monolithic-template) apply here as well.
+
+## Open questions for reviewers
+
+1. What kinds of generators other than `add new contract` do we want to support on initial release (if any)?
+2. Are there any other template repositories that we want to integrate with generators other than `beaker` (`fullstack` will contain those as well as it uses `beaker` as a dependency)?
+
+> Please note an MVP PoC is already implemented and available to play around on algokit-cli and beaker template repo under `advanced-generate-command` and `generators` branches respectively.
+> To test it out checkout the branche on cli do `pipx install . --force`, navigate to beaker template repo and checkout the branch as well, then navigate to any of the sub folders in `tests_generated`. Lastly do `algokit bootstrap all`, build the contract and execute `algokit generate` from root of that folder to play around with the feature based on the implementation proposal from Option 1.
+
+## Final Decision
+
+The team approved the proposal for Option 1: Wrapping generators into self contained copier templates hidden within algokit templates.
+
+## Next steps
+
+1. Polishing the PoC on algokit-cli and adding tests
+2. Polishing the PoC on beaker template and adding tests
+3. Adding documentation for new capabilities of the generate command
+4. Adding documentation for template builders on how to create generators

package/dist/resources/knowledge/taxonomy/algokit:cli:architecture-decisions:2024-01-13_native_binaries.md

@@ -0,0 +1,163 @@
+# AlgoKit CLI native binaries
+
+- **Status**: Approved
+- **Owner:** Altynbek Orumbayev (MakerX), Negar Abbasi (MakerX)
+- **Deciders**: Alessandro (Algorand Foundation), MakerX
+- **Date created**: 2024-01-13
+- **Date decided:** 2024-01-25
+- **Date updated**: 2024-01-16
+
+## Context
+
+The primary motivation for this decision is to streamline the installation process of AlgoKit CLI and reduce the friction associated with installing it on various operating systems. Currently, users often encounter minor environment-specific bugs during installation, which can be a significant deterrent. By providing native binaries, we aim to speed up the installation time and eliminate these bugs by **removing requirements to install python by the user**, thereby improving the overall user experience.
+
+The north star for this decision is to provide a distribution model that can be described as:
+
+```mermaid
+graph TD
+    A[GitHub Runners] -->|Windows| B[Packaging tool]
+    A -->|Mac| C[Packaging tool]
+    A -->|Linux| D[Packaging tool]
+    B --> E[Windows Binary]
+    C --> F[Mac Binary]
+    D --> G[Linux Binary]
+    E -->|Winget| H[Windows Users]
+    F -->|Brew| I[Mac Users]
+    G -->|Snap| J[Linux Users]
+    A -->|Wheel Build| K[Poetry]
+    K --> L[PyPi]
+    L -->|pipx| M[Python Users]
+```
+
+> ⚠️⚠️⚠️ Please note diagram above is a draft and is to be separately discussed in a follow up ADR that will focus on distribution of the binaries.
+
+The scope of this ADR only concerns the packaging for the CLI. The distribution via `snap`, `winget` and etc will be handled separately/in-parallel after decision and implementation of this ADR is in place.
+
+## Requirements
+
+- The native binaries should be easy to maintain and understand from a CI/CD deployment perspective.
+- The solution should support a wide variety of Linux distributions, macOS (both Apple Silicon and Intel architectures), and Windows.
+- The solution should integrate seamlessly with existing installation options, including Homebrew, or provide an easier alternative.
+- The solution should be designed with future scalability in mind, allowing for the addition of support for other variations of architectures or else as needed.
+- The solution should not significantly increase the complexity of the build process.
+- The solution should provide clear error messages and debugging information to assist in troubleshooting any issues that may arise.
+- You don't need to install Python on your system to use AlgoKit if you aren't creating a Python project.
+
+## Options
+
+### Option 1 - PyInstaller
+
+**Pros**
+
+- Easy to use and configure
+- Supports multiple platforms and architectures
+- Can handle complex packages and dependencies
+- Generates a single file executable
+- Active development and community support
+- Fairly fast build time via ci - ~3-4 minutes
+- Fairly small executable size (see benchmarking results below)
+- Marginally equal executable load time in `onedir` mode compared to `onefile` mode
+
+**Cons**
+
+- Occasionally requires manual configuration for more complex packages
+- Requires complex build packaging matrix to support multiple platforms and architectures
+- Requires minor tweaks in algokit cli to account for the fact that features relying on `sys.executable` will point to algokit cli executable instead of python interpreter. This is a minor change and can be done in a backwards compatible way however still a con to consider.
+- Requires minor tweaks in algokit cli to introduce `multiprocessing.freeze_support()` to avoid issues with `vanity-address` task when executing via binary.
+
+#### PoC
+
+The PoC is available [here](https://github.com/algorandfoundation/algokit-cli/pull/382). It outlines a simple github action with extra setup that compiles algokit cli as a single file executable on latest versions of Windows, Mac and Linux github runners.
+
+### Option 2 - Nuitka
+
+**Pros**
+
+- Nuitka translates Python code into C and then compiles it, which can result in performance improvements.
+- Cross-Platform: Supports multiple platforms including Windows, macOS, and Linux.
+- More cross compilations options than PyInstaller
+- Official github action simplifies the process of building executables for different platforms.
+
+**Cons**
+
+- Compilation Time: The process of converting Python to C and then compiling can be time-consuming. Up to ~30 minutes on github with 3 parallel jobs.
+- Size of Executable: The resulting executables can be larger due to the inclusion of the Python interpreter and the compiled C code (see benchmarking results below).
+- Does not support Python 3.12.
+- Requires minor tweaks in algokit cli to account for the fact that features relying on `sys.executable` will point to algokit cli executable instead of python interpreter. This is a minor change and can be done in a backwards compatible way however still a con to consider.
+- Requires minor tweaks in algokit cli to introduce `multiprocessing.freeze_support()` to avoid issues with `vanity-address` task when executing via binary.
+
+#### PoC
+
+The PoC is available [here](https://github.com/algorandfoundation/algokit-cli/pull/393). It outlines a simple github action with extra setup that compiles algokit cli as a single file executable on latest versions of Windows, Mac and Linux github runners.
+
+### Benchmarking `pyinstaller` vs `nuitka` vs pipx installed `algokit`
+
+#### Methodology
+
+`hyperfine` was used to benchmark 5 different executables:
+
+- Nuitka Onefile - Nuitka compiled executable with `--onefile` flag, which produces a single file executable.
+- Nuitka Onedir - Nuitka compiled executable with `--onedir` flag, which produces a directory with the executable and other dependencies unzipped.
+- PyInstaller Onedir - PyInstaller compiled executable with `--standalone` flag, which produces a directory with the executable and other dependencies unzipped.
+- PyInstaller Onefile - PyInstaller compiled executable with `--onefile` flag, which produces a single file executable.
+- AlgoKit from `pipx` - AlgoKit CLI installed via `pipx` with all dependencies frozen (current latest stable release).
+
+The benchmarking was performed on a MacBook M2 running macOS 14.2.1 and an ARM based Ubuntu 20.04.3 LTS running on a Parallels Desktop on the same machine.
+
+#### Results
+
+| Method              | macOS M2 | Ubuntu 20 ARM Linux VM | Windows 11 ARM |
+| ------------------- | -------- | ---------------------- | -------------- |
+| nuitka_onefile      | 3.634    | 1.465                  | 3.874          |
+| nuitka_onedir       | 0.2515   | 0.6200                 | 0.5136         |
+| pyinstaller_onedir  | 0.3228   | 0.7927                 | 0.6668         |
+| pyinstaller_onefile | 3.031    | 1.466                  | 1.875          |
+| algokit             | 0.3126   | 0.6111                 | 0.7579         |
+
+![Benchmarking Results](./assets/2024-01-13_native_binaries/image_1.png)
+_Figure: Benchmarking results comparing the performance of Nuitka (onefile, onedir modes), PyInstaller (onefile, onedir modes), and pipx installed Algokit CLI on macOS M2, Windows 11 ARM VM, Ubuntu 20 ARM VM._
+
+| Method              | Windows (MB) | Ubuntu (MB) | macOS (MB) |
+| ------------------- | ------------ | ----------- | ---------- |
+| nuitka_onedir       | 92.10        | 106         | 166        |
+| nuitka_onefile      | 22.48        | 23          | 41         |
+| pyinstaller_onedir  | 46.07        | 52          | 113        |
+| pyinstaller_onefile | 26.47        | 25          | 45         |
+
+![Bundle sizes](./assets/2024-01-13_native_binaries/image_2.png)
+_Figure: Bundle sizes of folders with executables build with Nuitka (onefile, onedir modes), PyInstaller (onefile, onedir modes)._
+
+#### Preliminary Observations
+
+- Nuitka's warmed up execution time is **fast**
+- Nuitka produces largest executables in `onedir` mode
+- Nuitka is the slowest to build (no charts for build benchmarks, this is observations based on CI build time from PoC, see links above)
+- PyInstaller produces smallest executables in `onedir` mode
+- PyInstaller is the fastest to build (no charts for build benchmarks, this is observations based on CI build time from PoC, see links above)
+
+### Honorable Mentions
+
+#### cx_Freeze
+
+cx_Freeze is a set of scripts and modules for freezing Python scripts into executables. It is similar to PyInstaller in many ways, but PyInstaller is preferred due to its more mature and comprehensive documentation.
+
+#### PyOxidizer
+
+PyOxidizer is a utility for producing binaries that embed Python. However, it is no longer actively maintained, which makes it a less desirable option for our needs.
+
+## Preferred option
+
+Based on observations so far we are leaning towards an Option 1. Where we would use PyInstaller to build native binaries for Windows, Mac and Linux.
+
+While `nuitka` in `onedir` mode is even faster than pip installed algokit, it generates larger executables, and is the slowest option in terms of build time. Pyinstaller is only marginally slower than `nuitka` or pip installed algokit in terms of execution time, has mature documentation, and is the fastest option to build (in `onedir` mode) and produces smaller executables than `nuitka`. Given that and the fact that `nuitka` does not support Python 3.12 yet and has a lot of `magical` optimizations hidden under the hood, we are leaning towards PyInstaller as the preferred option for building native binaries given its maturity and straightforwardness despite marginally slower execution time (which is not a big deal given that we are talking of deviations of 5-10 milliseconds).
+
+## Selected option
+
+The team has formally pre-discussed this ADR and has agreed to proceed with Option 1 - PyInstaller.
+
+## Next Steps
+
+- [ ] Finalize the decision on the preferred option.
+- [ ] Expand PoC and polish the github action to build native binaries for Windows, Mac and Linux for x86, x86-64 and ARM architectures.
+- [ ] Implement portability snapshot tests, expanding existing algokit cli snapshot tests by running against real executable covering main functionality to test and ensure that the native binaries are portable and behave the same way as pip installed algokit cli.
+- [ ] Submit follow up ADR to discuss strategies on how to distribute the binaries in most accessible, user friendly and secure way.

package/dist/resources/knowledge/taxonomy/algokit:cli:architecture-decisions:2024-01-23_init-wizard-v2.md

@@ -0,0 +1,211 @@
+# AlgoKit Init Wizard Version 2 and Template Enhancements
+
+- **Status:** Proposed (Revision 2)
+- **Owner:** Altynbek Orumbayev
+- **Deciders:** Alessandro (Algorand Foundation), Rob Moore (MakerX), MakerX team
+- **Creation Date:** 2024-01-23
+- **Decision Date:** 2024-02-13
+- **Update Date:** 2024-02-12
+
+## Revisions
+
+- **Revision 1:** Initial discussions with Alessandro, Michael, Joe, Georgio, and Chris identified key issues with the existing wizards and explored ways to improve templating capabilities. These discussions led to the consideration of a unified 'monorepo' structure to consolidate template repositories into more focused, smaller generators under a single repository. The revision also sought to refine the wizard and enhance command orchestration capabilities, incorporating tools like `npm workspaces`.
+- **Revision 2:** Engaged in multiple brainstorming sessions with Algorand Foundation/DevRel members and MakerX engineers to develop a pragmatic, time-bound, and prerequisite-neutral strategy. This approach resulted in splitting the ADR into two segments: one focusing on the `init` wizard enhancements and the other on template improvements and command orchestration upgrades in algokit-cli.
+
+## Background
+
+This ADR emerges from various discussions aimed at enhancing the `init` wizard version 2 user experience and aligning it with emerging smart contract languages/frameworks to make it more user-friendly and accessible to beginners. It builds upon prior decisions from the [Advanced algokit generate command](./2023-07-19_advanced_generate_command.md) and [Frontend Templates](./2023-06-06_frontend-templates.md) ADRs, integrating feedback from the Algorand Foundation and DevRel team.
+
+### Main Areas for Improvement
+
+1. **Enhancements to the `Init` Wizard:**
+
+   - Improve user experience by making the wizard more intuitive and less reliant on Algorand-specific jargon.
+   - Streamline the `presets` concept to minimize user inputs and simplify the process.
+
+2. **Template Refinements:**
+
+   - Address potential complexities in maintaining the `fullstack` template with new `smart-contract` template combinations, including future `.NET` integration alongside `puya` compiler-compatible stacks.
+   - Implement `codespaces` configurations for simplified project setup in GitHub Codespaces.
+   - Consider unifying `add smart contract` generators in the `puya` and `beaker` templates into a single, generic generator managed by the CLI itself (suggestion added as part of revision 2 based on DevRel feedback). This helps solving the problem of simplifying template building experience (removing duplication of generators that are essentially generic) while still giving an option for template builders to have custom generators within templates.
+
+3. **CLI Enhancements:**
+
+   - Enhance user experience by standardizing the use of `bootstrap`, `algokit.toml`, `.algokit` folder, and `.env` conventions, presenting a unified and intuitive CLI interface.
+
+## Detailed Proposals
+
+### 1. Improved `Init` Wizard Flow
+
+Shift from a detailed, template-specific question format to a more streamlined, interactive process that focuses on the user's intent rather than specific technologies within the Algorand ecosystem.
+
+**Current Init Wizard V1:**
+
+```mermaid
+graph TD
+    A[Start] --> Z[Pick an official template Puya, TealScript, React, Beaker]
+    Z --> B[Name for this project.]
+    B --> C[Package author name]
+    C --> D[Package author email]
+    D --> E[Do you want to add VSCode configuration?]
+    E -->|yes| F[Do you want to use ESLint and Prettier for code linting and formatting?]
+    E -->|no| G[Do you want to add JetBrains configuration - primarily optimized for WebStorm?]
+    F --> H[Do you want to use Tailwind CSS? A utility-first CSS framework for rapidly building custom designs.]
+    G --> H
+    H -->|yes| I[Do you want to use a daisyUI? Framework agnostic CSS component library for building modern websites and web applications fast.]
+    H -->|no| J[Do you want to include unit tests via Jest?]
+    I --> J
+    J --> K[Do you want to include end to end tests via Playwright?]
+    K --> L[Do you want to include Github Actions workflows for build validation?]
+    L -->|yes| M[Pick your website hosting provider for continuous delivery]
+    L -->|no| N[End]
+    M --> N
+```
+
+**Proposed Init Wizard V2:**
+
+```mermaid
+graph TB
+    A[Would you like to build a smart contract or a dapp frontend?]
+    B[If smart contract, which language would you like to use?]
+    C[If frontend, which framework would you like to use?]
+    D[Python, implies puya]
+    E[Typescript, implies TealScript]
+    F[React]
+    G[`production`/`starter`/`custom`]
+    I[`production`/`starter`/`custom`]
+    J[Would you like to include a frontend component?]
+    A --> B
+    A --> C
+    B --> D
+    D --> J
+    E --> J
+    J --> G
+    J --> F
+    B --> E
+    C --> F
+    F --> I
+```
+
+The proposal aims to simplify the question process and reduce the overall number of questions, focusing on identifying **what** the user intends to build without the additional complexity of selecting specific Algorand ecosystem tools or languages.
+
+As illustrated in the proposed flow diagram, the initiative seeks to:
+
+- Simplify the init wizard's questions, avoiding technical jargon and aligning with popular programming languages and frameworks, leveraging direct mappings like `python`, `typescript`, and `.net`.
+- Introduce clear preset options: `starter` for a comprehensive preselection based on the Algorand Foundation's recommendations, `production` for setups aligned with production standards, and `custom` for developers seeking detailed customization through template questions.
+
+This proposal presents no significant drawbacks, as it refines the question flow of the algokit init process without altering the command's fundamental behavior, thereby not impacting current users and enhancing the overall `init wizard` experience.
+
+### 2. Fullstack Template and CLI Command Orchestration Enhancements
+
+This dual-step approach suggests offloading business logic related to linking smart contracts and frontends within fullstack to a self-contained generator within the `react` template. It also introduces the concept of command orchestration in algokit-cli to manage project lifecycles more effectively.
+
+#### 2.1 Autonomy of Frontend Template
+
+**Fullstack Template Structure**:
+
+| Before                                                                                                                                                                                                                                                     | After                                                                                                                                                                                                                                                                         |
+| ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| The current fullstack is tightly coupled with the frontend template, handling the connection between frontend and backend. This coupling necessitates additional safety checks whenever there are changes in the expected structure of the React template. | The frontend now invokes the `import-contract` generator within the React template, which autonomously manages the linkage with a smart contract project. This adjustment makes the fullstack less reliant on template-specific changes that it should not be concerned with. |
+
+The proposal includes changes to the fullstack template's structure, enabling the frontend to autonomously manage its linkage with smart contract projects, thereby simplifying integration and enhancing maintainability.
+
+**Benefits:**
+
+- Simplifies integration of templates by allowing the frontend template to manage smart contract linkages independently.
+- Generalizes the fullstack template, offering flexibility in choosing backend components.
+
+**Suggested Enhancements:**
+
+- Further generalize the `AppCalls.tsx` component, removing assumptions on default `hello world` contracts and using `resolveBy: 'id'` by default.
+- Incorporate suggestions from discussions during revision 2, including the potential bundling of `add smart contract` generators directly into `algokit-cli` for reduced redundancy and enhanced template support.
+
+#### 2.2 CLI Command Orchestration
+
+Aims to utilize `algokit.toml` for organizing project-specific commands, enhancing project management and command execution through a more structured approach.
+
+Example workspace root `.algokit.toml`:
+
+```toml
+[algokit]
+min_version = "v1.8.0"
+
+[project]
+type = 'workspace' # informs algokit-cli that this is a workspace root that hosts multiple projects
+name = 'myworkspace' # included for reference but unique identifier for the workspace can be actually be excluded as it is not required for orchestration to work
+projects = ['src'] # a list of relative/absolute paths directly to folders with independent components of the project that are part of the workspace or roots of folders hosting multiple independent components
+```
+
+Example workspace of a smart contract project `.algokit.toml`:
+
+```toml
+[algokit]
+min_version = "v1.8.0"
+
+[generate.smart_contract]
+description = "Adds new smart contract to existing project"
+path = ".algokit/generators/create_contract"
+
+[project]
+type = 'backend'
+name = '{ component_name }'
+
+# The `deploy` command is categorized separately due to its static nature. Category names align with their root command group, hence `generate` is under [generate], while `deploy` is categorized under [project].
+[project.deploy]
+command = "poetry run python -m smart_contracts deploy"
+environment_secrets = [
+  "DEPLOYER_MNEMONIC",
+]
+
+[project.deploy.localnet]
+environment_secrets = []
+
+# New category for project specific commands that can be defined arbitrarily by the user
+[project.commands]
+test = { command = "poetry run pytest", description = "Run unit tests for the smart contracts" }
+build = { command = "poetry run python -m smart_contracts build", description = "Transpile puya smart contracts into TEAL and ABI specs" }
+# Description is used as `help` text as content gets presented to user via `algokit cli` interface.
+```
+
+**Enhancements to `.algokit.toml` enable the cli to:**
+
+- Navigate and interpret any project structure compliant with `.algokit.toml`.
+- Simplify interactions with project-specific commands.
+- Dynamically orchestrate command execution based on `.algokit.toml` configurations.
+  - For `algokit project {command_name}` executed at the workspace root, it aggregates and executes `{command_name}` from all child components either `sequentially` or `concurrently`, allowing users to choose the execution order per matching command identifier.
+  - When executed at a component's root, it runs the component-specific command from its `.algokit.toml`, also integrating it into the `algokit project` command group for visibility.
+
+**Suggested Improvements:**
+
+- Consider introducing command dependencies to ensure execution order for any command (in addition to current proposal to allow handling execution order for commands with matching 'names/identifiers'), enhancing the orchestration capabilities of the CLI.
+
+## Reference: Alternatives Considered
+
+### Consolidating AlgoKit Templates into a Monorepo
+
+**Overview:** Explores the possibility of merging AlgoKit templates into a single repository, focusing on streamlined project management and orchestration within js-centric environments.
+
+**Pros:**
+
+- Simplifies monorepo project management and orchestration in npm-based projects.
+
+**Cons:**
+
+- Increases complexity and potential conflicts with existing CLI capabilities and Copier's recommendations, suggesting that a better alternative might be to consider a shift to where we have a more CLI-centric approach that handles orchestration without introducing extra dependant pre-requisites.
+
+## Decision
+
+A phased implementation of both proposals, starting with user-facing enhancements to the `init` wizard followed by template and CLI command orchestration improvements. This strategy allows for immediate impact and addresses urgent needs first, with potential for further simplification through subsequent enhancements.
+
+## Next Steps
+
+1. Break down the selected options into detailed work items.
+2. Implement the proposed changes in the AlgoKit CLI and templates.
+3. Update documentation and onboarding materials to reflect the new changes.
+4. Announce the updates to the community and DevRel, soliciting feedback for future enhancements.
+5. Tackle minor improvements that become feasible following the main proposal implementations.
+
+### Open Questions
+
+1. Should we implement a bidirectional query mechanism where selecting a smart contract prompts the option to add a frontend, and similarly, choosing a frontend first triggers a query about integrating a smart contract? This approach necessitates a minor modification in the wording of the initial query. In the current workflow, we don't prompt adding smart contracts part since this question is prominently positioned as the initial query in the wizard's sequence.
+2. Alternative suggestions for 'type' categorization for `.algokit.toml` files? Or we are clear to proceed with `workspace` to highlight roots of full-stack/monorepo projects, `backend` to represent anything non webapp related and `frontend` to represent anything related?