Fix typos and file permissions

.config/docs/contributing/dev-environment.md

@@ -10,7 +10,7 @@ Before contributing to this project, you will have to make sure you have the too
 - **[Node.js](https://github.com/ProfessorManhattan/ansible-nodejs)** >=12 which is used for the development environment which includes a pre-commit hook
 - **[VirtualBox](https://github.com/ProfessorManhattan/ansible-virtualbox)** which is used for running Molecule tests
 
-Docker and VirtualBox must be installed with root priviledges. If they are missing from your system, running `bash .start.sh` will prompt you for your password and automatically install them. Otherwise, you can follow the official [directions for installing Docker](https://docs.docker.com/get-docker/) and [directions for installing VirtualBox](https://www.virtualbox.org/manual/ch02.html).
+Docker and VirtualBox must be installed with root privileges. If they are missing from your system, running `bash .start.sh` will prompt you for your password and automatically install them. Otherwise, you can follow the official [directions for installing Docker](https://docs.docker.com/get-docker/) and [directions for installing VirtualBox](https://www.virtualbox.org/manual/ch02.html).
 
 ### Getting Started
 

.config/docs/readme-playbook/managing-environments.md

@@ -1,6 +1,6 @@
 ## Managing Environments
 
-We accomplish managing different environments by symlinking all the folders that should be unique to each network environment (e.g. `host_vars/`, `group_vars/`, `inventories/`, `files/vpn/`, and `files/ssh/`). In the `environments/` folder, you will see multiple folders. In our case, `environments/dev/` contains sensible configurations for testing the playbook and its' roles. The production environment is a seperate git submodule that links to a private git repository that contains our Ansible-vaulted API keys and passwords. When you are ready to set up your production configurations, you can use this method of storing your environment-specific folders in the `environments/` folder as well. But if you are just starting off, you do not have to worry about this since, by default, this playbook is configured to run with the settings included in the `/environments/dev/` folder.
+We accomplish managing different environments by symlinking all the folders that should be unique to each network environment (e.g. `host_vars/`, `group_vars/`, `inventories/`, `files/vpn/`, and `files/ssh/`). In the `environments/` folder, you will see multiple folders. In our case, `environments/dev/` contains sensible configurations for testing the playbook and its' roles. The production environment is a separate git submodule that links to a private git repository that contains our Ansible-vaulted API keys and passwords. When you are ready to set up your production configurations, you can use this method of storing your environment-specific folders in the `environments/` folder as well. But if you are just starting off, you do not have to worry about this since, by default, this playbook is configured to run with the settings included in the `/environments/dev/` folder.
 
 ### Switching Between Environments
 

.github/workflows/openhands-resolver.yml

@@ -0,0 +1,34 @@
+name: Resolve Issue with OpenHands
+
+on:
+  issues:
+    types: [labeled]
+  pull_request:
+    types: [labeled]
+  issue_comment:
+    types: [created]
+  pull_request_review_comment:
+    types: [created]
+  pull_request_review:
+    types: [submitted]
+
+permissions:
+  contents: write
+  pull-requests: write
+  issues: write
+
+jobs:
+  call-openhands-resolver:
+    uses: All-Hands-AI/OpenHands/.github/workflows/openhands-resolver.yml@main
+    with:
+      macro: ${{ vars.OPENHANDS_MACRO || '@openhands-agent' }}
+      max_iterations: ${{ fromJson(vars.OPENHANDS_MAX_ITER || 50) }}
+      base_container_image: ${{ vars.OPENHANDS_BASE_CONTAINER_IMAGE || '' }}
+      LLM_MODEL: ${{ vars.LLM_MODEL || 'anthropic/claude-sonnet-4-20250514' }}
+      target_branch: ${{ vars.TARGET_BRANCH || 'main' }}
+      runner: ${{ vars.TARGET_RUNNER }}
+    secrets:
+      PAT_TOKEN: ${{ secrets.PAT_TOKEN }}
+      PAT_USERNAME: ${{ secrets.PAT_USERNAME }}
+      LLM_API_KEY: ${{ secrets.LLM_API_KEY }}
+      LLM_BASE_URL: ${{ secrets.LLM_BASE_URL }}

docs/CONTRIBUTING.md

@@ -100,7 +100,7 @@ For the most part, when working on one of our NPM packages, all of the code shou
 
 We adhere to strict design-patterns across all of our NPM packages. In order for you to get a feel for what we are looking for, you should browse through our [`Buildr`](repository.project.buildr) project's files. After browsing through the Buildr project's source code, you will notice that we include other files/folders in the `src/` folder:
 
-- `constants/` - This folder houses all the constant variables used in the project. The constants are generally seperated out into different files based on where they are being used in the application.
+- `constants/` - This folder houses all the constant variables used in the project. The constants are generally separated out into different files based on where they are being used in the application.
 - `lib/` - This folder contains all the pieces of the app that would generally be utilized by the `app.ts` file.
 - `models/` - This folder contains all of the data models that are used. Data models are important to use especially in larger projects because they provide type definitions and also open the door to data validation which is touched on in the [Preferred Libraries](#preferred-libraries) section.
 - `tsconfig.json` - This file is included to address a Visual Studio Code bug that occurs if you open the `src/` directory and not the root folder
@@ -158,7 +158,7 @@ validate(post).then(errors => {
 });
 ```
 
-Using the library above can provide real value to our users. By validating the data before running any business logic, we can save the user time by taking out the guess work required for debugging. Please note that in practice, the `Post` model/class would be seperated into a file stored in `src/models/post.model.ts`.
+Using the library above can provide real value to our users. By validating the data before running any business logic, we can save the user time by taking out the guess work required for debugging. Please note that in practice, the `Post` model/class would be separated into a file stored in `src/models/post.model.ts`.
 
 **All data inputs should utilize this form of validation.** If the `class-validator` project does not provide a decorator that can properly validate the input data then you can extend the library by creating a custom validation decorator. There is an [example of how to create a custom validator in the Buildr project](https://gitlab.com/megabyte-labs/npm/buildr/-/blob/master/src/lib/validators/is-true.validator.ts).
 

docs/customization/index.md

@@ -11,11 +11,11 @@ There are many ways you can customize Install Doctor so that your device is prov
 
 The Install Doctor project leverages dozens of technologies but, at its core, it is ultimately a Chezmoi project. This allows us to leverage Chezmoi's script execution abilities, encryption handlers, and diff feature (which allows you to display the changes that will be made before applying them).
 
-If you decide that our built-in prompt system does not accomodate your needs, we highly recommend you sift through [Chezmoi's documentation](https://www.chezmoi.io/). By reading the documentation, you will learn why some files and folders start with `dot_`, how files ending with `.tmpl` are rendered, and additional features you can leverage.
+If you decide that our built-in prompt system does not accommodate your needs, we highly recommend you sift through [Chezmoi's documentation](https://www.chezmoi.io/). By reading the documentation, you will learn why some files and folders start with `dot_`, how files ending with `.tmpl` are rendered, and additional features you can leverage.
 
 That said, if you do not feel like taking a deep dive and learning a new technology, then you can leverage our built-in prompt system. Better yet, if you want to customize Install Doctor, you can customize the repository to your liking without having to learn the inner workings and features of Chezmoi.
 
-Our project is the most ellaborate and full-featured implementation of Chezmoi we have come across. If you come across another project that parallels the full-featuredness of ours then please let our team and community know about it by posting in one of our social media sites / chat rooms which are all linked to on the [Community page](https://install.doctor/community).
+Our project is the most elaborate and full-featured implementation of Chezmoi we have come across. If you come across another project that parallels the full-featuredness of ours then please let our team and community know about it by posting in one of our social media sites / chat rooms which are all linked to on the [Community page](https://install.doctor/community).
 
 ## Prompts
 

docs/customization/scripts.md

@@ -5,7 +5,7 @@ sidebar_label: Scripts
 slug: /customization/scripts
 ---
 
-Install Doctor leverages shell scripting for many of the complex tasks that cannot easily be accomodated by the Install Doctor [ZX-based installer](https://github.com/megabyte-labs/install.doctor/blob/master/home/dot_local/bin/executable_install-program). On macOS / Linux / *nix variants Bash is used and, on Windows, PowerShell is also leveraged. Since Install Doctor is a [Chezmoi](https://www.chezmoi.io/)-based installer, all of the Chezmoi features and syntaxes are used by the scripts housed in the Install Doctor repository. After parsing script templates and filtering files with the `.chezmoiignore` file, all the scripts with file names that begin with `run_` are executed at different phases during the provisioning process.
+Install Doctor leverages shell scripting for many of the complex tasks that cannot easily be accommodated by the Install Doctor [ZX-based installer](https://github.com/megabyte-labs/install.doctor/blob/master/home/dot_local/bin/executable_install-program). On macOS / Linux / *nix variants Bash is used and, on Windows, PowerShell is also leveraged. Since Install Doctor is a [Chezmoi](https://www.chezmoi.io/)-based installer, all of the Chezmoi features and syntaxes are used by the scripts housed in the Install Doctor repository. After parsing script templates and filtering files with the `.chezmoiignore` file, all the scripts with file names that begin with `run_` are executed at different phases during the provisioning process.
 
 ## Script Phases
 

docs/features/index.md

@@ -128,4 +128,4 @@ By default, our pre-defined software templates include dozens (or hundreds, depe
 
 ## More Features
 
-There are many, many more features that have not been listed in this high-level overview. We encourage you to browse through the [Install Doctor repository](https://github.com/megabyte-labs/install.doctor) codebase to browse through additional features not listed here. If you cannot find a feature that you are looking for, then please engage with our [Community](https://install.doctor/community) and let us know how to make Install Doctor accomodate your needs.
+There are many, many more features that have not been listed in this high-level overview. We encourage you to browse through the [Install Doctor repository](https://github.com/megabyte-labs/install.doctor) codebase to browse through additional features not listed here. If you cannot find a feature that you are looking for, then please engage with our [Community](https://install.doctor/community) and let us know how to make Install Doctor accommodate your needs.

docs/index.md

@@ -18,7 +18,7 @@ Install Doctor makes it as easy as possible to:
 
 ## Multi-OS Provisioning
 
-Part of what seperates Install Doctor from other provisioning systems is that it includes features that make it easy to apply your same configurations across multiple operating systems. It includes its own software installation program that can be configured to, for instance, prefer to install software with the system package manager but leverage [Homebrew](https://brew.sh/) if the package is not available via the system package manager.
+Part of what separates Install Doctor from other provisioning systems is that it includes features that make it easy to apply your same configurations across multiple operating systems. It includes its own software installation program that can be configured to, for instance, prefer to install software with the system package manager but leverage [Homebrew](https://brew.sh/) if the package is not available via the system package manager.
 
 Apart from installing a configurable set of software packages, it also leverages Chezmoi's built-in feature that allows you to delegate specific scripts to run on certain operating systems. This is how, at provisioning time, the system runs PowerShell scripts on Windows and Bash scripts on other targets.
 

docs/scripts/overview/profile.md

@@ -5,7 +5,7 @@ sidebar_label: Profile Scripts
 slug: /scripts/profile
 ---
 
-Install Doctor's expertly configured and optimized system configuration collection includes masterfully created Bash / ZSH profile scripts. These scripts are seperated into a handful of files that are only imported when necessary.
+Install Doctor's expertly configured and optimized system configuration collection includes masterfully created Bash / ZSH profile scripts. These scripts are separated into a handful of files that are only imported when necessary.
 
 The default configuration ensures ZSH is the default shell. When combined with the [Oh-My-ZSH](https://ohmyz.sh/) framework, this gives the user access to advanced auto-completion, type ahead, and predictive features.
 

home/.chezmoiscripts/universal/run_after_01-pre-install.sh.tmpl

@@ -889,7 +889,7 @@ loadCronjobs() {
 #     as well as improve security. Some of the tweaks include modifying default settings for various applications.
 macOSSettings() {
   if [ -d /System ] && [ -d /Applications ] && [ -f "${XDG_CONFIG_HOME:-$HOME/.config}/shell/macos.sh" ]; then
-    bash "${XDG_CONFIG_HOME:-$HOME/.config}/shell/macos.sh"
+    APPLY_MACOS_SETTINGS=true bash "${XDG_CONFIG_HOME:-$HOME/.config}/shell/macos.sh"
   fi
 }
 

home/dot_config/shell/macos.sh.tmpl

@@ -6,6 +6,11 @@
 #     This script houses a wide range of macOS system tweaks that are intended to improve the developer experience on macOS,
 #     as well as improve security. Some of the tweaks include modifying default settings for various applications.
 
+# Exit early if not explicitly requested to run system configuration
+if [ "$APPLY_MACOS_SETTINGS" != "true" ]; then
+  exit 0
+fi
+
 gum log -sl info 'Applying optimized macOS settings'
 
 # Ask for the administrator password upfront