chore: bump module versions (minor)

Co-authored-by: DevelopmentCats <176868952+DevelopmentCats@users.noreply.github.com>

.github/PULL_REQUEST_TEMPLATE.md

@@ -0,0 +1,39 @@
+## Description
+
+<!-- Briefly describe what this PR does and why -->
+
+---
+
+## Type of Change
+
+- [ ] New module
+- [ ] Bug fix
+- [ ] Feature/enhancement
+- [ ] Documentation
+- [ ] Other
+
+---
+
+## Module Information
+
+<!-- Delete this section if not applicable -->
+
+**Path:** `registry/[namespace]/modules/[module-name]`  
+**New version:** `v1.0.0`  
+**Breaking change:** [ ] Yes [ ] No
+
+---
+
+## Testing & Validation
+
+- [ ] Tests pass (`bun test`)
+- [ ] Code formatted (`bun run fmt`)
+- [ ] Changes tested locally
+
+---
+
+## Related Issues
+
+<!-- Link related issues or write "None" if not applicable -->
+
+Closes #

.github/scripts/version-bump.sh

@@ -0,0 +1,229 @@
+#!/bin/bash
+
+# Version Bump Script
+# Usage: ./version-bump.sh <bump_type> [base_ref]
+#   bump_type: patch, minor, or major
+#   base_ref: base reference for diff (default: origin/main)
+
+set -euo pipefail
+
+usage() {
+  echo "Usage: $0 <bump_type> [base_ref]"
+  echo "  bump_type: patch, minor, or major"
+  echo "  base_ref: base reference for diff (default: origin/main)"
+  echo ""
+  echo "Examples:"
+  echo "  $0 patch                    # Update versions with patch bump"
+  echo "  $0 minor                    # Update versions with minor bump"
+  echo "  $0 major                    # Update versions with major bump"
+  exit 1
+}
+
+validate_version() {
+  local version="$1"
+  if ! [[ "$version" =~ ^[0-9]+\.[0-9]+\.[0-9]+$ ]]; then
+    echo "❌ Invalid version format: '$version'. Expected X.Y.Z format." >&2
+    return 1
+  fi
+  return 0
+}
+
+bump_version() {
+  local current_version="$1"
+  local bump_type="$2"
+
+  IFS='.' read -r major minor patch <<< "$current_version"
+
+  if ! [[ "$major" =~ ^[0-9]+$ ]] || ! [[ "$minor" =~ ^[0-9]+$ ]] || ! [[ "$patch" =~ ^[0-9]+$ ]]; then
+    echo "❌ Version components must be numeric: major='$major' minor='$minor' patch='$patch'" >&2
+    return 1
+  fi
+
+  case "$bump_type" in
+    "patch")
+      echo "$major.$minor.$((patch + 1))"
+      ;;
+    "minor")
+      echo "$major.$((minor + 1)).0"
+      ;;
+    "major")
+      echo "$((major + 1)).0.0"
+      ;;
+    *)
+      echo "❌ Invalid bump type: '$bump_type'. Expected patch, minor, or major." >&2
+      return 1
+      ;;
+  esac
+}
+
+update_readme_version() {
+  local readme_path="$1"
+  local namespace="$2"
+  local module_name="$3"
+  local new_version="$4"
+
+  if [ ! -f "$readme_path" ]; then
+    return 1
+  fi
+
+  local module_source="registry.coder.com/${namespace}/${module_name}/coder"
+  if grep -q "source.*${module_source}" "$readme_path"; then
+    echo "Updating version references for $namespace/$module_name in $readme_path"
+    awk -v module_source="$module_source" -v new_version="$new_version" '
+        /source.*=.*/ {
+          if ($0 ~ module_source) {
+            in_target_module = 1
+          } else {
+            in_target_module = 0
+          }
+        }
+        /version.*=.*"/ {
+          if (in_target_module) {
+            gsub(/version[[:space:]]*=[[:space:]]*"[^"]*"/, "version = \"" new_version "\"")
+            in_target_module = 0
+          }
+        }
+        { print }
+        ' "$readme_path" > "${readme_path}.tmp" && mv "${readme_path}.tmp" "$readme_path"
+    return 0
+  elif grep -q 'version\s*=\s*"' "$readme_path"; then
+    echo "⚠️  Found version references but no module source match for $namespace/$module_name"
+    return 1
+  fi
+
+  return 1
+}
+
+main() {
+  if [ $# -lt 1 ] || [ $# -gt 2 ]; then
+    usage
+  fi
+
+  local bump_type="$1"
+  local base_ref="${2:-origin/main}"
+
+  case "$bump_type" in
+    "patch" | "minor" | "major") ;;
+
+    *)
+      echo "❌ Invalid bump type: '$bump_type'. Expected patch, minor, or major." >&2
+      exit 1
+      ;;
+  esac
+
+  echo "🔍 Detecting modified modules..."
+
+  local changed_files
+  changed_files=$(git diff --name-only "${base_ref}"...HEAD)
+  local modules
+  modules=$(echo "$changed_files" | grep -E '^registry/[^/]+/modules/[^/]+/' | cut -d'/' -f1-4 | sort -u)
+
+  if [ -z "$modules" ]; then
+    echo "❌ No modules detected in changes"
+    exit 1
+  fi
+
+  echo "Found modules:"
+  echo "$modules"
+  echo ""
+
+  local bumped_modules=""
+  local updated_readmes=""
+  local untagged_modules=""
+  local has_changes=false
+
+  while IFS= read -r module_path; do
+    if [ -z "$module_path" ]; then continue; fi
+
+    local namespace
+    namespace=$(echo "$module_path" | cut -d'/' -f2)
+    local module_name
+    module_name=$(echo "$module_path" | cut -d'/' -f4)
+
+    echo "📦 Processing: $namespace/$module_name"
+
+    local latest_tag
+    latest_tag=$(git tag -l "release/${namespace}/${module_name}/v*" | sort -V | tail -1)
+    local readme_path="$module_path/README.md"
+    local current_version
+
+    if [ -z "$latest_tag" ]; then
+      if [ -f "$readme_path" ] && grep -q 'version\s*=\s*"' "$readme_path"; then
+        local readme_version
+        readme_version=$(grep 'version\s*=\s*"' "$readme_path" | head -1 | sed 's/.*version\s*=\s*"\([^"]*\)".*/\1/')
+        echo "No git tag found, but README shows version: $readme_version"
+
+        if ! validate_version "$readme_version"; then
+          echo "Starting from v1.0.0 instead"
+          current_version="1.0.0"
+        else
+          current_version="$readme_version"
+          untagged_modules="$untagged_modules\n- $namespace/$module_name (README: v$readme_version)"
+        fi
+      else
+        echo "No existing tags or version references found for $namespace/$module_name, starting from v1.0.0"
+        current_version="1.0.0"
+      fi
+    else
+      current_version=$(echo "$latest_tag" | sed 's/.*\/v//')
+      echo "Found git tag: $latest_tag (v$current_version)"
+    fi
+
+    echo "Current version: $current_version"
+
+    if ! validate_version "$current_version"; then
+      exit 1
+    fi
+
+    local new_version
+    new_version=$(bump_version "$current_version" "$bump_type")
+
+    echo "New version: $new_version"
+
+    if update_readme_version "$readme_path" "$namespace" "$module_name" "$new_version"; then
+      updated_readmes="$updated_readmes\n- $namespace/$module_name"
+      has_changes=true
+    fi
+
+    bumped_modules="$bumped_modules\n- $namespace/$module_name: v$current_version → v$new_version"
+    echo ""
+
+  done <<< "$modules"
+
+  echo "📋 Summary:"
+  echo "Bump Type: $bump_type"
+  echo ""
+  echo "Modules Updated:"
+  echo -e "$bumped_modules"
+  echo ""
+
+  if [ -n "$updated_readmes" ]; then
+    echo "READMEs Updated:"
+    echo -e "$updated_readmes"
+    echo ""
+  fi
+
+  if [ -n "$untagged_modules" ]; then
+    echo "⚠️  Modules Without Git Tags:"
+    echo -e "$untagged_modules"
+    echo "These modules were versioned based on README content. Consider creating proper release tags after merging."
+    echo ""
+  fi
+
+  if [ "$has_changes" = true ]; then
+    echo "✅ Version bump completed successfully!"
+    echo "📝 README files have been updated with new versions."
+    echo ""
+    echo "Next steps:"
+    echo "1. Review the changes: git diff"
+    echo "2. Commit the changes: git add . && git commit -m 'chore: bump module versions ($bump_type)'"
+    echo "3. Push the changes: git push"
+    exit 0
+  else
+    echo "ℹ️  No README files were updated (no version references found matching module sources)."
+    echo "Version calculations completed, but no files were modified."
+    exit 0
+  fi
+}
+
+main "$@"

.github/workflows/ci.yaml

@@ -48,7 +48,7 @@ jobs:
       - name: Validate formatting
         run: bun fmt:ci
       - name: Check for typos
-        uses: crate-ci/typos@v1.32.0
+        uses: crate-ci/typos@v1.33.1
         with:
           config: .github/typos.toml
   validate-readme-files:

.github/workflows/deploy-registry.yaml

@@ -2,8 +2,6 @@ name: deploy-registry
 
 on:
   push:
-    branches:
-      - main
     tags:
       # Matches release/<namespace>/<resource_name>/<semantic_version>
       # (e.g., "release/whizus/exoscale-zone/v1.0.13")

.github/workflows/version-bump.yaml

@@ -0,0 +1,107 @@
+name: Version Bump
+
+on:
+  pull_request:
+    types: [labeled]
+    paths:
+      - "registry/**/modules/**"
+
+concurrency:
+  group: ${{ github.workflow }}-${{ github.ref }}
+  cancel-in-progress: true
+
+jobs:
+  version-bump:
+    if: github.event.label.name == 'version:patch' || github.event.label.name == 'version:minor' || github.event.label.name == 'version:major'
+    runs-on: ubuntu-latest
+    permissions:
+      contents: read
+      pull-requests: write
+    steps:
+      - name: Checkout code
+        uses: actions/checkout@v4
+        with:
+          fetch-depth: 0
+          token: ${{ secrets.GITHUB_TOKEN }}
+
+      - name: Extract bump type from label
+        id: bump-type
+        run: |
+          case "${{ github.event.label.name }}" in
+            "version:patch")
+              echo "type=patch" >> $GITHUB_OUTPUT
+              ;;
+            "version:minor")
+              echo "type=minor" >> $GITHUB_OUTPUT
+              ;;
+            "version:major")
+              echo "type=major" >> $GITHUB_OUTPUT
+              ;;
+            *)
+              echo "Invalid version label: ${{ github.event.label.name }}"
+              exit 1
+              ;;
+          esac
+
+      - name: Check version bump requirements
+        id: version-check
+        run: |
+          # Run the script to check what versions should be
+          output_file=$(mktemp)
+          if ./.github/scripts/version-bump.sh "${{ steps.bump-type.outputs.type }}" origin/main > "$output_file" 2>&1; then
+            echo "Script completed successfully"
+          else
+            echo "Script failed"
+            cat "$output_file"
+            exit 1
+          fi
+
+          # Store output for PR comment
+          {
+            echo "output<<EOF"
+            cat "$output_file"
+            echo "EOF"
+          } >> $GITHUB_OUTPUT
+
+          # Show output
+          cat "$output_file"
+
+          # Check if any files would be modified by the script
+          if git diff --quiet; then
+            echo "versions_up_to_date=true" >> $GITHUB_OUTPUT
+            echo "✅ All module versions are already up to date"
+          else
+            echo "versions_up_to_date=false" >> $GITHUB_OUTPUT
+            echo "❌ Module versions need to be updated"
+            echo "Files that would be changed:"
+            git diff --name-only
+            echo ""
+            echo "Diff preview:"
+            git diff
+            exit 1
+          fi
+
+      - name: Comment on PR - Failure
+        if: failure() && steps.version-check.outputs.versions_up_to_date == 'false'
+        uses: actions/github-script@v7
+        with:
+          script: |
+            const output = `${{ steps.version-check.outputs.output }}`;
+            const bumpType = `${{ steps.bump-type.outputs.type }}`;
+
+            let comment = `## ❌ Version Bump Validation Failed\n\n`;
+            comment += `**Bump Type:** \`${bumpType}\`\n\n`;
+            comment += `Module versions need to be updated but haven't been bumped yet.\n\n`;
+            comment += `**Required Actions:**\n`;
+            comment += `1. Run the version bump script locally: \`./.github/scripts/version-bump.sh ${bumpType}\`\n`;
+            comment += `2. Commit the changes: \`git add . && git commit -m "chore: bump module versions (${bumpType})"\`\n`;
+            comment += `3. Push the changes: \`git push\`\n\n`;
+            comment += `### Script Output:\n\`\`\`\n${output}\n\`\`\`\n\n`;
+            comment += `> Please update the module versions and push the changes to continue.`;
+
+            github.rest.issues.createComment({
+              issue_number: context.issue.number,
+              owner: context.repo.owner,
+              repo: context.repo.repo,
+              body: comment
+            });

CONTRIBUTING.md

@@ -1,294 +1,319 @@
-# Contributing
+# Contributing to the Coder Registry
 
-## Getting started
+Welcome! This guide covers how to contribute to the Coder Registry, whether you're creating a new module or improving an existing one.
 
-This repo uses two main runtimes to verify the correctness of a module/template before it is published:
+## What is the Coder Registry?
 
-- [Bun](https://bun.sh/) – Used to run tests for each module/template to validate overall functionality and correctness of Terraform output
-- [Go](https://go.dev/) – Used to validate all README files in the directory. The README content is used to populate [the Registry website](https://registry.coder.com).
+The Coder Registry is a collection of Terraform modules that extend Coder workspaces with development tools like VS Code, Cursor, JetBrains IDEs, and more.
 
-### Installing Bun
+## Types of Contributions
 
-To install Bun, you can run this command on Linux/MacOS:
+- **[New Modules](#creating-a-new-module)** - Add support for a new tool or functionality
+- **[Existing Modules](#contributing-to-existing-modules)** - Fix bugs, add features, or improve documentation
+- **[Bug Reports](#reporting-issues)** - Report problems or request features
 
-```shell
+## Setup
+
+### Prerequisites
+
+- Basic Terraform knowledge (for module development)
+- Terraform installed ([installation guide](https://developer.hashicorp.com/terraform/install))
+- Docker (for running tests)
+
+### Install Dependencies
+
+Install Bun:
+
+```bash
 curl -fsSL https://bun.sh/install | bash
 ```
 
-Or this command on Windows:
+Install project dependencies:
 
-```shell
-powershell -c "irm bun.sh/install.ps1 | iex"
+```bash
+bun install
 ```
 
-Follow the instructions to ensure that Bun is available globally. Once Bun is installed, install all necessary dependencies from the root of the repo:
+### Understanding Namespaces
 
-Via NPM:
+All modules are organized under `/registry/[namespace]/modules/`. Each contributor gets their own namespace (e.g., `/registry/your-username/modules/`). If a namespace is taken, choose a different unique namespace, but you can still use any display name on the Registry website.
 
-```shell
-npm i
+### Images and Icons
+
+- **Namespace avatars**: Must be named `avatar.png` or `avatar.svg` in `/registry/[namespace]/.images/`
+- **Module screenshots/demos**: Use `/registry/[namespace]/.images/` for module-specific images
+- **Module icons**: Use the shared `/.icons/` directory at the root for module icons
+
+---
+
+## Creating a New Module
+
+### 1. Create Your Namespace (First Time Only)
+
+If you're a new contributor, create your namespace:
+
+```bash
+mkdir -p registry/[your-username]
+mkdir -p registry/[your-username]/.images
 ```
 
-Via PNPM:
+#### Add Your Avatar
 
-```shell
-pnpm i
+Every namespace must have an avatar. We recommend using your GitHub avatar:
+
+1. Download your GitHub avatar from `https://github.com/[your-username].png`
+2. Save it as `avatar.png` in `registry/[your-username]/.images/`
+3. This gives you a properly sized, square image that's already familiar to the community
+
+The avatar must be:
+
+- Named exactly `avatar.png` or `avatar.svg`
+- Square image (recommended: 400x400px minimum)
+- Supported formats: `.png` or `.svg` only
+
+#### Create Your Namespace README
+
+Create `registry/[your-username]/README.md`:
+
+```markdown
+---
+display_name: "Your Name"
+bio: "Brief description of who you are and what you do"
+avatar_url: "./.images/avatar.png"
+github: "your-username"
+linkedin: "https://www.linkedin.com/in/your-username" # Optional
+website: "https://yourwebsite.com" # Optional
+support_email: "you@example.com" # Optional
+status: "community"
+---
+
+# Your Name
+
+Brief description of who you are and what you do.
 ```
 
-This repo does not support Yarn.
+> **Note**: The `avatar_url` must point to `./.images/avatar.png` or `./.images/avatar.svg`.
 
-### Installing Go (optional)
+### 2. Generate Module Files
 
-This step can be skipped if you are not working on any of the README validation logic. The validation will still run as part of CI.
-
-[Navigate to the official Go Installation page](https://go.dev/doc/install), and install the correct version for your operating system.
-
-Once Go has been installed, verify the installation via:
-
-```shell
-go version
+```bash
+./scripts/new_module.sh [your-username]/[module-name]
+cd registry/[your-username]/modules/[module-name]
 ```
 
-## Namespaces
+This script generates:
 
-All Coder resources are scoped to namespaces placed at the top level of the `/registry` directory. Any modules or templates must be placed inside a namespace to be accepted as a contribution. For example, all modules created by CoderEmployeeBob would be placed under `/registry/coderemployeebob/modules`, with a subdirectory for each individual module the user has published.
+- `main.tf` - Terraform configuration template
+- `README.md` - Documentation template with frontmatter
+- `run.sh` - Script for module execution (can be deleted if not required)
 
-If a namespace is already taken, you will need to create a different, unique namespace, but will still be able to choose any display name. (The display name is shown in the Registry website. More info below.)
+### 3. Build Your Module
 
-### Namespace (contributor profile) README files
+1. **Edit `main.tf`** to implement your module's functionality
+2. **Update `README.md`** with:
+   - Accurate description and usage examples
+   - Correct icon path (usually `../../../../.icons/your-icon.svg`)
+   - Proper tags that describe your module
+3. **Create `main.test.ts`** to test your module
+4. **Add any scripts** or additional files your module needs
 
-More information about contributor profile README files can be found below.
+### 4. Test and Submit
 
-### Images
+```bash
+# Test your module
+bun test -t 'module-name'
 
-Any images needed for either the main namespace directory or a module/template can be placed in a relative `/images` directory at the top of the namespace directory. (e.g., CoderEmployeeBob can have a `/registry/coderemployeebob/images` directory, that can be referenced by the main README file, as well as a README file in `/registry/coderemployeebob/modules/custom_module/README.md`.) This is to minimize the risk of file name conflicts between different users as they add images to help illustrate parts of their README files.
+# Format code
+bun fmt
 
-## Coder modules
-
-### Adding a new module
-
-> [!WARNING]
-> These instructions cannot be followed just yet; the script referenced will be made available shortly. Contributors looking to add modules early will need to create all directories manually.
-
-Once Bun (and possibly Go) have been installed, clone the Coder Registry repository. From there, you can run this script to make it easier to start contributing a new module or template:
-
-```shell
-./new.sh USER_NAMESPACE/NAME_OF_NEW_MODULE
+# Commit and create PR
+git add .
+git commit -m "Add [module-name] module"
+git push origin your-branch
 ```
 
-You can also create a module file manually by creating the necessary files and directories.
+> **Important**: It is your responsibility to implement tests for every new module. Test your module locally before opening a PR. The testing suite requires Docker containers with the `--network=host` flag, which typically requires running tests on Linux (this flag doesn't work with Docker Desktop on macOS/Windows). macOS users can use [Colima](https://github.com/abiosoft/colima) or [OrbStack](https://orbstack.dev/) instead of Docker Desktop.
 
-### The composition of a Coder module
+---
 
-Each Coder Module must contain the following files:
+## Contributing to Existing Modules
 
-- A `main.tf` file that defines the main Terraform-based functionality
-- A `main.test.ts` file that is used to validate that the module works as expected
-- A `README.md` file containing required information (listed below)
+### 1. Find the Module
 
-You are free to include any additional files in the module, as needed by the module. For example, the [Windows RDP module](https://github.com/coder/registry/tree/main/registry/coder/modules/windows-rdp) contains additional files for injecting specific functionality into a Coder Workspace.
-
-> [!NOTE]
-> Some legacy modules do not have test files defined just yet. This will be addressed soon.
-
-### The `main.tf` file
-
-This file defines all core Terraform functionality, to be mixed into your Coder workspaces. More information about [Coder's use of Terraform can be found here](https://coder.com/docs/admin/templates/extending-templates/modules), and [general information about the Terraform language can be found in the official documentation](https://developer.hashicorp.com/terraform/docs).
-
-### The structure of a module README
-
-Validation criteria for module README files is listed below.
-
-### Testing a Module
-
-> [!IMPORTANT]
-> It is the responsibility of the module author to implement tests for every new module they wish to contribute. It is expected the author has tested the module locally before opening a PR. Feel free to reference existing test files to get an idea for how to set them up.
-
-All general-purpose test helpers for validating Terraform can be found in the top-level `/testing` directory. The helpers run `terraform apply` on modules that use variables, testing the script output against containers.
-
-When writing a test file, you can import the test utilities via the `~test` import alias:
-
-```ts
-// This works regardless of how deeply-nested your test file is in the file
-// structure
-import {
-  runTerraformApply,
-  runTerraformInit,
-  testRequiredVariables,
-} from "~test";
+```bash
+find registry -name "*[module-name]*" -type d
 ```
 
-> [!NOTE]
-> The testing suite must be able to run docker containers with the `--network=host` flag. This typically requires running the tests on Linux as this flag does not apply to Docker Desktop for MacOS or Windows. MacOS users can work around this by using something like [colima](https://github.com/abiosoft/colima) or [Orbstack](https://orbstack.dev/) instead of Docker Desktop.
+### 2. Make Your Changes
 
-#### Running tests
+**For bug fixes:**
 
-You can run all tests by running this command from the root of the Registry directory:
+- Reproduce the issue
+- Fix the code in `main.tf`
+- Add/update tests
+- Update documentation if needed
 
-```shell
+**For new features:**
+
+- Add new variables with sensible defaults
+- Implement the feature
+- Add tests for new functionality
+- Update README with new variables
+
+**For documentation:**
+
+- Fix typos and unclear explanations
+- Add missing variable documentation
+- Improve usage examples
+
+### 3. Test Your Changes
+
+```bash
+# Test a specific module
+bun test -t 'module-name'
+
+# Test all modules
 bun test
 ```
 
-Note that running _all_ tests can take some time, so you likely don't want to be running this command as part of your core development loop.
+### 4. Maintain Backward Compatibility
 
-To run specific tests, you can use the `-t` flag, which accepts a filepath regex:
+- New variables should have default values
+- Don't break existing functionality
+- Test that minimal configurations still work
 
-```shell
-bun test -t '<regex_pattern>'
+---
+
+## Submitting Changes
+
+1. **Fork and branch:**
+
+   ```bash
+   git checkout -b fix/module-name-issue
+   ```
+
+2. **Commit with clear messages:**
+
+   ```bash
+   git commit -m "Fix version parsing in module-name"
+   ```
+
+3. **Open PR with:**
+   - Clear title describing the change
+   - What you changed and why
+   - Any breaking changes
+
+### Using PR Templates
+
+We have different PR templates for different types of contributions. GitHub will show you options to choose from, or you can manually select:
+
+- **New Module**: Use `?template=new_module.md`
+- **Bug Fix**: Use `?template=bug_fix.md`
+- **Feature**: Use `?template=feature.md`
+- **Documentation**: Use `?template=documentation.md`
+
+Example: `https://github.com/coder/registry/compare/main...your-branch?template=new_module.md`
+
+---
+
+## Requirements
+
+### Every Module Must Have
+
+- `main.tf` - Terraform code
+- `main.test.ts` - Working tests
+- `README.md` - Documentation with frontmatter
+
+### README Frontmatter
+
+Module README frontmatter must include:
+
+```yaml
+---
+display_name: "Module Name" # Required - Name shown on Registry website
+description: "What it does" # Required - Short description
+icon: "../../../../.icons/tool.svg" # Required - Path to icon file
+verified: false # Optional - Set by maintainers only
+tags: ["tag1", "tag2"] # Required - Array of descriptive tags
+---
 ```
 
-To ensure that the module runs predictably in local development, you can update the Terraform source as follows:
+### README Requirements
 
-```tf
-module "example" {
-  # You may need to remove the 'version' field, it is incompatible with some sources.
-  source = "git::https://github.com/<USERNAME>/<REPO>.git//<MODULE-NAME>?ref=<BRANCH-NAME>"
-}
+All README files must follow these rules:
+
+- Must have frontmatter section with proper YAML
+- Exactly one h1 header directly below frontmatter
+- When increasing header levels, increment by one each time
+- Use `tf` instead of `hcl` for code blocks
+
+### Best Practices
+
+- Use descriptive variable names and descriptions
+- Include helpful comments
+- Test all functionality
+- Follow existing code patterns in the module
+
+---
+
+## Versioning Guidelines
+
+When you modify a module, you need to update its version number in the README. Understanding version numbers helps you describe the impact of your changes:
+
+- **Patch** (1.2.3 → 1.2.4): Bug fixes
+- **Minor** (1.2.3 → 1.3.0): New features, adding inputs
+- **Major** (1.2.3 → 2.0.0): Breaking changes (removing inputs, changing types)
+
+### Updating Module Versions
+
+If your changes require a version bump, use the version bump script:
+
+```bash
+# For bug fixes
+./.github/scripts/version-bump.sh patch
+
+# For new features
+./.github/scripts/version-bump.sh minor
+
+# For breaking changes
+./.github/scripts/version-bump.sh major
 ```
 
-## Updating README files
+The script will:
 
-This repo uses Go to validate each README file. If you are working with the README files at all (i.e., creating them, modifying them), it is strongly recommended that you install Go (installation instructions mentioned above), so that the files can be validated locally.
+1. Detect which modules you've modified
+2. Calculate the new version number
+3. Update all version references in the module's README
+4. Show you a summary of changes
 
-### Validating all README files
+**Important**: Only run the version bump script if your changes require a new release. Documentation-only changes don't need version updates.
 
-To validate all README files throughout the entire repo, you can run the following:
+---
 
-```shell
-go build ./cmd/readmevalidation && ./readmevalidation
-```
+## Reporting Issues
 
-The resulting binary is already part of the `.gitignore` file, but you can remove it with:
+When reporting bugs, include:
 
-```shell
-rm ./readmevalidation
-```
+- Module name and version
+- Expected vs actual behavior
+- Minimal reproduction case
+- Error messages
+- Environment details (OS, Terraform version)
 
-### README validation criteria
+---
 
-The following criteria exists for two reasons:
+## Getting Help
 
-1. Content accessibility
-2. Having content be designed in a way that's easy for the Registry site build step to use
+- **Examples**: Check `/registry/coder/modules/` for well-structured modules
+- **Issues**: Open an issue for technical problems
+- **Community**: Reach out to the Coder community for questions
 
-#### General README requirements
+## Common Pitfalls
 
-- There must be a frontmatter section.
-- There must be exactly one h1 header, and it must be at the very top, directly below the frontmatter.
-- The README body (if it exists) must start with an h1 header. No other content (including GitHub-Flavored Markdown alerts) is allowed to be placed above it.
-- When increasing the level of a header, the header's level must be incremented by one each time.
-- Any `.hcl` code snippets must be labeled as `.tf` snippets instead
+1. **Missing frontmatter** in README
+2. **No tests** or broken tests
+3. **Hardcoded values** instead of variables
+4. **Breaking changes** without defaults
+5. **Not running** `bun fmt` before submitting
 
-  ````txt
-  ```tf
-  Content
-  ```
-  ````
-
-#### Namespace (contributor profile) criteria
-
-In addition to the general criteria, all README files must have the following:
-
-- Frontmatter metadata with support for the following fields:
-
-  - `display_name` (required string) – The name to use when displaying your user profile in the Coder Registry site.
-  - `bio` (optional string) – A short description of who you are.
-  - `github` (optional string) – Your GitHub handle.
-  - `avatar_url` (optional string) – A relative/absolute URL pointing to your avatar for the Registry site. It is strongly recommended that you commit avatar images to this repo and reference them via a relative URL.
-  - `linkedin` (optional string) – A URL pointing to your LinkedIn page.
-  - `support_email` (optional string) – An email for users to reach you at if they need help with a published module/template.
-  - `status` (string union) – If defined, this must be one of `"community"`, `"partner"`, or `"official"`. `"community"` should be used for the majority of external contributions. `"partner"` is for companies who have a formal business partnership with Coder. `"official"` should be used only by Coder employees.
-
-- The README body (the content that goes directly below the frontmatter) is allowed to be empty, but if it isn't, it must follow all the rules above.
-
-You are free to customize the body of a contributor profile however you like, adding any number of images or information. Its content will never be rendered in the Registry website.
-
-Additional information can be placed in the README file below the content listed above, using any number of headers.
-
-Additional image/video assets can be placed in the same user namespace directory where that user's main content lives.
-
-#### Module criteria
-
-In addition to the general criteria, all README files must have the following:
-
-- Frontmatter that describes metadata for the module:
-  - `display_name` (required string) – This is the name displayed on the Coder Registry website
-  - `description` (required string) – A short description of the module, which is displayed on the Registry website
-  - `icon` (required string) – A relative/absolute URL pointing to the icon to display for the module in the Coder Registry website.
-  - `verified` (optional boolean) – Indicates whether the module has been officially verified by Coder. Please do not set this without approval from a Coder employee.
-  - `tags` (required string array) – A list of metadata tags to describe the module. Used in the Registry site for search and navigation functionality.
-  - `maintainer_github` (deprecated string) – The name of the creator of the module. This field exists for backwards compatibility with previous versions of the Registry, but going forward, the value will be inferred from the namespace directory.
-  - `partner_github` (deprecated string) - The name of any additional creators for a module. This field exists for backwards compatibility with previous versions of the Registry, but should not ever be used going forward.
-- The following content directly under the h1 header (without another header between them):
-
-  - A description of what the module does
-  - A Terraform snippet for letting other users import the functionality
-
-    ```tf
-    module "cursor" {
-      count    = data.coder_workspace.me.start_count
-      source   = "registry.coder.com/coder/cursor/coder"
-      version  = "1.0.19"
-      agent_id = coder_agent.example.id
-    }
-    ```
-
-Additional information can be placed in the README file below the content listed above, using any number of headers.
-
-Additional image/video assets can be placed in one of two places:
-
-1. In the same user namespace directory where that user's main content lives
-2. If the image is an icon, it can be placed in the top-level `.icons` directory (this is done because a lot of modules will be based off the same products)
-
-## Releases
-
-The release process involves the following steps:
-
-### 1. Create and merge a new PR
-
-- Create a PR with your module changes
-- Get your PR reviewed, approved, and merged into the `main` branch
-
-### 2. Prepare Release (Maintainer Task)
-
-After merging to `main`, a maintainer will:
-
-- Check out the merge commit:
-
-  ```shell
-  git checkout MERGE_COMMIT_ID
-  ```
-
-- Create annotated tags for each module that was changed:
-
-  ```shell
-  git tag -a "release/$namespace/$module/v$version" -m "Release $namespace/$module v$version"
-  ```
-
-- Push the tags to origin:
-
-  ```shell
-  git push origin release/$namespace/$module/v$version
-  ```
-
-For example, to release version 1.0.14 of the coder/aider module:
-
-```shell
-git tag -a "release/coder/aider/v1.0.14" -m "Release coder/aider v1.0.14"
-git push origin release/coder/aider/v1.0.14
-```
-
-### Version Numbers
-
-Version numbers should follow semantic versioning:
-
-- **Patch version** (1.2.3 → 1.2.4): Bug fixes
-- **Minor version** (1.2.3 → 1.3.0): New features, adding inputs, deprecating inputs
-- **Major version** (1.2.3 → 2.0.0): Breaking changes (removing inputs, changing input types)
-
-### 3. Publishing to Coder Registry
-
-After tags are pushed, the changes will be published to [registry.coder.com](https://registry.coder.com).
-
-> [!NOTE]
-> Some data in registry.coder.com is fetched on demand from this repository's `main` branch. This data should update almost immediately after a release, while other changes will take some time to propagate.
+Happy contributing! 🚀

MAINTAINER.md

@@ -0,0 +1,103 @@
+# Maintainer Guide
+
+Quick reference for maintaining the Coder Registry repository.
+
+## Setup
+
+Install Go for README validation:
+
+```bash
+# macOS
+brew install go
+
+# Linux
+sudo apt install golang-go
+```
+
+## Daily Tasks
+
+### Review PRs
+
+Check that PRs have:
+
+- [ ] All required files (`main.tf`, `main.test.ts`, `README.md`)
+- [ ] Proper frontmatter in README
+- [ ] Working tests (`bun test`)
+- [ ] Formatted code (`bun run fmt`)
+- [ ] Avatar image for new namespaces (`avatar.png` or `avatar.svg` in `.images/`)
+
+#### Version Guidelines
+
+When reviewing PRs, ensure the version change follows semantic versioning:
+
+- **Patch** (1.2.3 → 1.2.4): Bug fixes
+- **Minor** (1.2.3 → 1.3.0): New features, adding inputs
+- **Major** (1.2.3 → 2.0.0): Breaking changes (removing inputs, changing types)
+
+PRs should clearly indicate the version change (e.g., `v1.2.3 → v1.2.4`).
+
+### Validate READMEs
+
+```bash
+go build ./cmd/readmevalidation && ./readmevalidation
+```
+
+## Releases
+
+### Create Release Tags
+
+After merging a PR:
+
+1. Get the new version from the PR (shown as `old → new`)
+2. Checkout the merge commit and create the tag:
+
+```bash
+# Checkout the merge commit
+git checkout MERGE_COMMIT_ID
+
+# Create and push the release tag using the version from the PR
+git tag -a "release/$namespace/$module/v$version" -m "Release $namespace/$module v$version"
+git push origin release/$namespace/$module/v$version
+```
+
+Example: If PR shows `v1.2.3 → v1.2.4`, use `v1.2.4` in the tag.
+
+### Publishing
+
+Changes are automatically published to [registry.coder.com](https://registry.coder.com) after tags are pushed.
+
+## README Requirements
+
+### Module Frontmatter (Required)
+
+```yaml
+display_name: "Module Name"
+description: "What it does"
+icon: "../../../../.icons/tool.svg"
+maintainer_github: "username"
+partner_github: "partner-name" # Optional - For official partner modules
+verified: false # Optional - Set by maintainers only
+tags: ["tag1", "tag2"]
+```
+
+### Namespace Frontmatter (Required)
+
+```yaml
+display_name: "Your Name"
+bio: "Brief description of who you are and what you do"
+avatar_url: "./.images/avatar.png"
+github: "username"
+linkedin: "https://www.linkedin.com/in/username" # Optional
+website: "https://yourwebsite.com" # Optional
+support_email: "you@example.com" # Optional
+status: "community" # or "partner", "official"
+```
+
+## Common Issues
+
+- **README validation fails**: Check YAML syntax, ensure h1 header after frontmatter
+- **Tests fail**: Ensure Docker with `--network=host`, check Terraform syntax
+- **Wrong file structure**: Use `./scripts/new_module.sh` for new modules
+- **Missing namespace avatar**: Must be `avatar.png` or `avatar.svg` in `.images/` directory
+
+That's it. Keep it simple.

registry/coder/modules/claude-code/README.md

@@ -14,7 +14,7 @@ Run the [Claude Code](https://docs.anthropic.com/en/docs/agents-and-tools/claude
 ```tf
 module "claude-code" {
   source              = "registry.coder.com/coder/claude-code/coder"
-  version             = "1.3.1"
+  version = "1.4.0"
   agent_id            = coder_agent.example.id
   folder              = "/home/coder"
   install_claude_code = true
@@ -88,7 +88,7 @@ resource "coder_agent" "main" {
 module "claude-code" {
   count               = data.coder_workspace.me.start_count
   source              = "registry.coder.com/coder/claude-code/coder"
-  version             = "1.3.1"
+  version = "1.4.0"
   agent_id            = coder_agent.example.id
   folder              = "/home/coder"
   install_claude_code = true
@@ -107,7 +107,7 @@ Run Claude Code as a standalone app in your workspace. This will install Claude
 ```tf
 module "claude-code" {
   source              = "registry.coder.com/coder/claude-code/coder"
-  version             = "1.3.1"
+  version = "1.4.0"
   agent_id            = coder_agent.example.id
   folder              = "/home/coder"
   install_claude_code = true
@@ -117,3 +117,41 @@ module "claude-code" {
   icon = "https://registry.npmmirror.com/@lobehub/icons-static-png/1.24.0/files/dark/claude-color.png"
 }
 ```
+
+## Enable user memory
+
+Claude Code supports [user memory](https://docs.anthropic.com/en/docs/claude-code/memory-management) that persists across all projects. This memory is stored in `~/.claude/CLAUDE.md` and contains personal preferences, coding standards, and instructions that apply to all your work.
+
+```tf
+module "claude-code" {
+  source              = "registry.coder.com/coder/claude-code/coder"
+  version = "1.4.0"
+  agent_id            = coder_agent.example.id
+  folder              = "/home/coder"
+  install_claude_code = true
+  claude_code_version = "latest"
+
+  # Enable user memory
+  enable_user_memory = true
+  user_memory_content = <<-EOT
+    # My Claude Code Preferences
+    
+    ## Coding Style
+    - Always use descriptive variable names
+    - Prefer explicit over implicit code
+    - Add comments for complex logic
+    
+    ## Preferred Technologies
+    - Use TypeScript for JavaScript projects
+    - Prefer functional programming patterns
+    - Use modern ES6+ syntax
+    
+    ## Testing
+    - Write unit tests for all functions
+    - Use descriptive test names
+    - Aim for high test coverage
+  EOT
+}
+```
+
+The `user_memory_content` is only used to create the initial `~/.claude/CLAUDE.md` file if it doesn't already exist. Once created, you can edit this file directly to update your preferences, and they will persist across workspace rebuilds since the file lives in the user's home directory outside the workspace.

registry/coder/modules/claude-code/main.tf

@@ -84,9 +84,22 @@ variable "experiment_post_install_script" {
   default     = null
 }
 
+variable "enable_user_memory" {
+  type        = bool
+  description = "Whether to enable user memory for Claude Code. This creates ~/.claude/CLAUDE.md for persistent user preferences."
+  default     = false
+}
+
+variable "user_memory_content" {
+  type        = string
+  description = "Initial content for the user memory file (~/.claude/CLAUDE.md). Only used if the file doesn't already exist."
+  default     = null
+}
+
 locals {
   encoded_pre_install_script  = var.experiment_pre_install_script != null ? base64encode(var.experiment_pre_install_script) : ""
   encoded_post_install_script = var.experiment_post_install_script != null ? base64encode(var.experiment_post_install_script) : ""
+  encoded_user_memory_content = var.user_memory_content != null ? base64encode(var.user_memory_content) : ""
 }
 
 # Install and Initialize Claude Code
@@ -113,6 +126,28 @@ resource "coder_script" "claude_code" {
       echo "Folder created successfully."
     fi
 
+    # Set up user memory if enabled
+    if [ "${var.enable_user_memory}" = "true" ]; then
+      echo "Setting up Claude Code user memory..."
+      
+      # Create the .claude directory if it doesn't exist
+      if [ ! -d "$HOME/.claude" ]; then
+        echo "Creating ~/.claude directory..."
+        mkdir -p "$HOME/.claude"
+      fi
+      
+      # Create the user memory file if it doesn't exist and content is provided
+      if [ ! -f "$HOME/.claude/CLAUDE.md" ] && [ -n "${local.encoded_user_memory_content}" ]; then
+        echo "Creating user memory file ~/.claude/CLAUDE.md..."
+        echo "${local.encoded_user_memory_content}" | base64 -d > "$HOME/.claude/CLAUDE.md"
+        echo "User memory file created successfully."
+      elif [ -f "$HOME/.claude/CLAUDE.md" ]; then
+        echo "User memory file ~/.claude/CLAUDE.md already exists, skipping creation."
+      else
+        echo "User memory enabled but no initial content provided. You can manually create ~/.claude/CLAUDE.md later."
+      fi
+    fi
+
     # Run pre-install script if provided
     if [ -n "${local.encoded_pre_install_script}" ]; then
       echo "Running pre-install script..."

registry/coder/modules/windows-rdp/README.md

@@ -16,7 +16,7 @@ Enable Remote Desktop + a web based client on Windows workspaces, powered by [de
 module "windows_rdp" {
   count       = data.coder_workspace.me.start_count
   source      = "registry.coder.com/coder/windows-rdp/coder"
-  version     = "1.0.18"
+  version     = "1.2.0"
   agent_id    = resource.coder_agent.main.id
   resource_id = resource.aws_instance.dev.id
 }
@@ -34,7 +34,7 @@ module "windows_rdp" {
 module "windows_rdp" {
   count       = data.coder_workspace.me.start_count
   source      = "registry.coder.com/coder/windows-rdp/coder"
-  version     = "1.0.18"
+  version     = "1.2.0"
   agent_id    = resource.coder_agent.main.id
   resource_id = resource.aws_instance.dev.id
 }
@@ -46,12 +46,25 @@ module "windows_rdp" {
 module "windows_rdp" {
   count       = data.coder_workspace.me.start_count
   source      = "registry.coder.com/coder/windows-rdp/coder"
-  version     = "1.0.18"
+  version     = "1.2.0"
   agent_id    = resource.coder_agent.main.id
   resource_id = resource.google_compute_instance.dev[0].id
 }
 ```
 
+### With Custom Devolutions Gateway Version
+
+```tf
+module "windows_rdp" {
+  count                       = data.coder_workspace.me.start_count
+  source                      = "registry.coder.com/coder/windows-rdp/coder"
+  version                     = "1.2.0"
+  agent_id                    = resource.coder_agent.main.id
+  resource_id                 = resource.aws_instance.dev.id
+  devolutions_gateway_version = "2025.1.6" # Specify a specific version
+}
+```
+
 ## Roadmap
 
 - [ ] Test on Microsoft Azure.

registry/coder/modules/windows-rdp/main.tf

@@ -9,6 +9,18 @@ terraform {
   }
 }
 
+variable "order" {
+  type        = number
+  description = "The order determines the position of app in the UI presentation. The lowest order is shown first and apps with equal order are sorted by name (ascending order)."
+  default     = null
+}
+
+variable "group" {
+  type        = string
+  description = "The name of a group that this app belongs to."
+  default     = null
+}
+
 variable "share" {
   type    = string
   default = "owner"
@@ -39,14 +51,21 @@ variable "admin_password" {
   sensitive = true
 }
 
+variable "devolutions_gateway_version" {
+  type        = string
+  default     = "2025.2.1"
+  description = "Version of Devolutions Gateway to install. Defaults to the latest available version."
+}
+
 resource "coder_script" "windows-rdp" {
   agent_id     = var.agent_id
   display_name = "windows-rdp"
   icon         = "/icon/desktop.svg"
 
   script = templatefile("${path.module}/powershell-installation-script.tftpl", {
-    admin_username = var.admin_username
-    admin_password = var.admin_password
+    admin_username              = var.admin_username
+    admin_password              = var.admin_password
+    devolutions_gateway_version = var.devolutions_gateway_version
 
     # Wanted to have this be in the powershell template file, but Terraform
     # doesn't allow recursive calls to the templatefile function. Have to feed
@@ -68,6 +87,8 @@ resource "coder_app" "windows-rdp" {
   url          = "http://localhost:7171"
   icon         = "/icon/desktop.svg"
   subdomain    = true
+  order        = var.order
+  group        = var.group
 
   healthcheck {
     url       = "http://localhost:7171"
@@ -78,7 +99,7 @@ resource "coder_app" "windows-rdp" {
 
 resource "coder_app" "rdp-docs" {
   agent_id     = var.agent_id
-  display_name = "Local RDP"
+  display_name = "Local RDP Docs"
   slug         = "rdp-docs"
   icon         = "https://raw.githubusercontent.com/matifali/logos/main/windows.svg"
   url          = "https://coder.com/docs/ides/remote-desktops#rdp-desktop"

registry/coder/modules/windows-rdp/powershell-installation-script.tftpl

@@ -21,7 +21,7 @@ function Configure-RDP {
 function Install-DevolutionsGateway {
 # Define the module name and version
 $moduleName = "DevolutionsGateway"
-$moduleVersion = "2024.1.5"
+$moduleVersion = "${devolutions_gateway_version}"
 
 # Install the module with the specified version for all users
 # This requires administrator privileges