V0.11.0rc

.github/ISSUE_TEMPLATE/feature_request.yml

@@ -0,0 +1,108 @@
+name: Feature Request
+description: Suggest a new feature or enhancement for Automaker
+title: '[Feature]: '
+labels: ['enhancement']
+body:
+  - type: markdown
+    attributes:
+      value: |
+        Thanks for taking the time to suggest a feature! Please fill out the form below to help us understand your request.
+
+  - type: dropdown
+    id: feature-area
+    attributes:
+      label: Feature Area
+      description: Which area of Automaker does this feature relate to?
+      options:
+        - UI/UX (User Interface)
+        - Agent/AI
+        - Kanban Board
+        - Git/Worktree Management
+        - Project Management
+        - Settings/Configuration
+        - Documentation
+        - Performance
+        - Other
+      default: 0
+    validations:
+      required: true
+
+  - type: dropdown
+    id: priority
+    attributes:
+      label: Priority
+      description: How important is this feature to your workflow?
+      options:
+        - Nice to have
+        - Would improve my workflow
+        - Critical for my use case
+      default: 0
+    validations:
+      required: true
+
+  - type: textarea
+    id: problem-statement
+    attributes:
+      label: Problem Statement
+      description: Is your feature request related to a problem? Please describe the problem you're trying to solve.
+      placeholder: A clear and concise description of what the problem is. Ex. I'm always frustrated when...
+    validations:
+      required: true
+
+  - type: textarea
+    id: proposed-solution
+    attributes:
+      label: Proposed Solution
+      description: Describe the solution you'd like to see implemented.
+      placeholder: A clear and concise description of what you want to happen.
+    validations:
+      required: true
+
+  - type: textarea
+    id: alternatives-considered
+    attributes:
+      label: Alternatives Considered
+      description: Describe any alternative solutions or workarounds you've considered.
+      placeholder: A clear and concise description of any alternative solutions or features you've considered.
+    validations:
+      required: false
+
+  - type: textarea
+    id: use-cases
+    attributes:
+      label: Use Cases
+      description: Describe specific scenarios where this feature would be useful.
+      placeholder: |
+        1. When working on...
+        2. As a user who needs to...
+        3. In situations where...
+    validations:
+      required: false
+
+  - type: textarea
+    id: mockups
+    attributes:
+      label: Mockups/Screenshots
+      description: If applicable, add mockups, wireframes, or screenshots to help illustrate your feature request.
+      placeholder: Drag and drop images here or paste image URLs
+    validations:
+      required: false
+
+  - type: textarea
+    id: additional-context
+    attributes:
+      label: Additional Context
+      description: Add any other context, references, or examples about the feature request here.
+      placeholder: Any additional information that might be helpful...
+    validations:
+      required: false
+
+  - type: checkboxes
+    id: terms
+    attributes:
+      label: Checklist
+      options:
+        - label: I have searched existing issues to ensure this feature hasn't been requested already
+          required: true
+        - label: I have provided a clear description of the problem and proposed solution
+          required: true

.gitignore

@@ -90,9 +90,8 @@ pnpm-lock.yaml
 yarn.lock
 
 # Fork-specific workflow files (should never be committed)
-DEVELOPMENT_WORKFLOW.md
-check-sync.sh
 # API key files
 data/.api-key
 data/credentials.json
 data/
+.codex/

.husky/pre-commit

@@ -31,7 +31,12 @@ fi
 
 # Ensure common system paths are in PATH (for systems without nvm)
 # This helps find node/npm installed via Homebrew, system packages, etc.
-export PATH="$PATH:/usr/local/bin:/opt/homebrew/bin:/usr/bin"
+if [ -n "$WINDIR" ]; then
+  export PATH="$PATH:/c/Program Files/nodejs:/c/Program Files (x86)/nodejs"
+  export PATH="$PATH:$APPDATA/npm:$LOCALAPPDATA/Programs/nodejs"
+else 
+  export PATH="$PATH:/usr/local/bin:/opt/homebrew/bin:/usr/bin"
+fi
 
 # Run lint-staged - works with or without nvm
 # Prefer npx, fallback to npm exec, both work with system-installed Node.js

CONTRIBUTING.md

@@ -24,6 +24,7 @@ For complete details on contribution terms and rights assignment, please review
     - [Development Setup](#development-setup)
     - [Project Structure](#project-structure)
   - [Pull Request Process](#pull-request-process)
+    - [Branching Strategy (RC Branches)](#branching-strategy-rc-branches)
     - [Branch Naming Convention](#branch-naming-convention)
     - [Commit Message Format](#commit-message-format)
     - [Submitting a Pull Request](#submitting-a-pull-request)
@@ -186,6 +187,59 @@ automaker/
 
 This section covers everything you need to know about contributing changes through pull requests, from creating your branch to getting your code merged.
 
+### Branching Strategy (RC Branches)
+
+Automaker uses **Release Candidate (RC) branches** for all development work. Understanding this workflow is essential before contributing.
+
+**How it works:**
+
+1. **All development happens on RC branches** - We maintain version-specific RC branches (e.g., `v0.10.0rc`, `v0.11.0rc`) where all active development occurs
+2. **RC branches are eventually merged to main** - Once an RC branch is stable and ready for release, it gets merged into `main`
+3. **Main branch is for releases only** - The `main` branch contains only released, stable code
+
+**Before creating a PR:**
+
+1. **Check for the latest RC branch** - Before starting work, check the repository for the current RC branch:
+
+   ```bash
+   git fetch upstream
+   git branch -r | grep rc
+   ```
+
+2. **Base your work on the RC branch** - Create your feature branch from the latest RC branch, not from `main`:
+
+   ```bash
+   # Find the latest RC branch (e.g., v0.11.0rc)
+   git checkout upstream/v0.11.0rc
+   git checkout -b feature/your-feature-name
+   ```
+
+3. **Target the RC branch in your PR** - When opening your pull request, set the base branch to the current RC branch, not `main`
+
+**Example workflow:**
+
+```bash
+# 1. Fetch latest changes
+git fetch upstream
+
+# 2. Check for RC branches
+git branch -r | grep rc
+# Output: upstream/v0.11.0rc
+
+# 3. Create your branch from the RC
+git checkout -b feature/add-dark-mode upstream/v0.11.0rc
+
+# 4. Make your changes and commit
+git commit -m "feat: Add dark mode support"
+
+# 5. Push to your fork
+git push origin feature/add-dark-mode
+
+# 6. Open PR targeting the RC branch (v0.11.0rc), NOT main
+```
+
+**Important:** PRs opened directly against `main` will be asked to retarget to the current RC branch.
+
 ### Branch Naming Convention
 
 We use a consistent branch naming pattern to keep our repository organized:
@@ -275,14 +329,14 @@ Follow these steps to submit your contribution:
 
 #### 1. Prepare Your Changes
 
-Ensure you've synced with the latest upstream changes:
+Ensure you've synced with the latest upstream changes from the RC branch:
 
 ```bash
 # Fetch latest changes from upstream
 git fetch upstream
 
-# Rebase your branch on main (if needed)
-git rebase upstream/main
+# Rebase your branch on the current RC branch (if needed)
+git rebase upstream/v0.11.0rc  # Use the current RC branch name
 ```
 
 #### 2. Run Pre-submission Checks
@@ -314,18 +368,19 @@ git push origin feature/your-feature-name
 
 1. Go to your fork on GitHub
 2. Click "Compare & pull request" for your branch
-3. Ensure the base repository is `AutoMaker-Org/automaker` and base branch is `main`
+3. **Important:** Set the base repository to `AutoMaker-Org/automaker` and the base branch to the **current RC branch** (e.g., `v0.11.0rc`), not `main`
 4. Fill out the PR template completely
 
 #### PR Requirements Checklist
 
 Your PR should include:
 
+- [ ] **Targets the current RC branch** (not `main`) - see [Branching Strategy](#branching-strategy-rc-branches)
 - [ ] **Clear title** describing the change (use conventional commit format)
 - [ ] **Description** explaining what changed and why
 - [ ] **Link to related issue** (if applicable): `Closes #123` or `Fixes #456`
 - [ ] **All CI checks passing** (format, lint, build, tests)
-- [ ] **No merge conflicts** with main branch
+- [ ] **No merge conflicts** with the RC branch
 - [ ] **Tests included** for new functionality
 - [ ] **Documentation updated** if adding/changing public APIs