docs: update documentation for today's changes (#70)

Author: CalvinAllen

CONTRIBUTING.md

@@ -32,9 +32,11 @@ Enhancement suggestions are tracked as GitHub issues. When creating an enhanceme
 1. Fork the repo and create your branch from `main`
 2. If you've added code that should be tested, add tests
 3. Ensure your code follows the existing style
-4. Write a clear commit message describing your changes
+4. **Use a conventional commit format for your PR title** (e.g., `feat(node): add version caching`)
 5. Submit your pull request!
 
+**Note:** We use squash merges, so your PR title becomes the commit message on main. Make sure it follows the [commit convention](docs/COMMIT_CONVENTION.md).
+
 ## Development Setup
 
 ### Prerequisites
@@ -196,7 +198,7 @@ test(migrate): add tests for package preservation
 
 For detailed guidelines and examples, see [Commit Convention Guide](docs/COMMIT_CONVENTION.md).
 
-**Note:** Pull requests are automatically checked for commit message compliance. Non-conforming commits will fail CI checks.
+**Note:** PR titles are automatically validated for conventional commit compliance. Non-conforming titles will fail CI checks. Since we use squash merges, your PR title becomes the final commit message.
 
 ## Adding a New Runtime Provider
 

README.md

@@ -134,13 +134,19 @@ dtvem freeze
 dtvem install          # Prompts for confirmation
 dtvem install --yes    # Skip confirmation
 
-# Check currently active versions
+# Check currently active versions (all runtimes)
 dtvem current
 
-# List installed versions
+# Check active version for specific runtime
+dtvem current python
+
+# List all installed versions (all runtimes)
+dtvem list
+
+# List installed versions for specific runtime
 dtvem list python
 
-# List all available versions
+# List all available versions for download
 dtvem list-all python
 
 # List with filtering
@@ -297,7 +303,7 @@ This scans all installed versions and creates shims for every executable found,
 | `init` | Initialize dtvem (setup directories and PATH) | ✅ Complete |
 | `install [runtime] [version]` | Install a specific runtime version, or all from `.dtvem/runtimes.json` | ✅ Complete |
 | `uninstall <runtime> <version>` | Remove an installed version | ✅ Complete |
-| `list <runtime>` | List installed versions | ✅ Complete |
+| `list [runtime]` | List installed versions (all runtimes or specific) | ✅ Complete |
 | `list-all <runtime>` | List all available versions (with filtering) | ✅ Complete |
 
 ### Version Management

docs/COMMIT_CONVENTION.md

@@ -70,18 +70,20 @@ The scope should be the name of the affected module or component:
 The subject contains a succinct description of the change:
 
 - Use the imperative, present tense: "add" not "added" nor "adds"
-- Don't capitalize the first letter
+- Start with lowercase (but uppercase abbreviations like PR, API, CLI, URL are allowed)
 - No period (.) at the end
 - Maximum 72 characters
 
 **Good examples:**
 - `fix(python): handle missing pip.exe on Windows`
 - `feat(cli): add --yes flag to install command`
 - `docs: add troubleshooting section to README`
+- `chore(ci): remove PR coverage comments`
+- `feat: add API endpoint for version lookup`
 
 **Bad examples:**
-- `Fixed bug` (missing scope, not descriptive)
-- `feat(node): Added support for nvm.` (wrong tense, capitalized, period)
+- `Fixed bug` (missing type, not descriptive)
+- `feat(node): Added support for nvm.` (wrong tense, period at end)
 - `Update code` (missing type, not descriptive)
 
 ### Body (Optional)
@@ -156,9 +158,29 @@ Reverting due to Windows compatibility issues that need more investigation.
 Relates to #234
 ```
 
+## Pull Requests and Squash Merges
+
+This project uses **squash merges** for all pull requests. This means:
+
+- All commits in your PR are combined into a single commit on merge
+- **The PR title becomes the commit message** on the main branch
+- Your PR title must follow the conventional commit format
+
+When creating a PR, ensure your title follows the format:
+```
+<type>(<scope>): <subject>
+```
+
+For example:
+- `feat(node): add support for Node.js 22.x`
+- `fix(shim): handle API errors on Windows`
+- `chore(ci): update PR linting workflow`
+
+The PR title is validated automatically - if it doesn't follow the convention, the CI check will fail.
+
 ## Validation
 
-All commits in pull requests are automatically validated using [commitlint](https://commitlint.js.org/). If your commits don't follow this convention, the CI check will fail.
+Both PR titles and individual commits are automatically validated using [commitlint](https://commitlint.js.org/). If they don't follow this convention, the CI check will fail.
 
 ### Tips for Success