|
|
|
@@ -87,6 +87,31 @@ Do not claim completion without verification evidence.
|
|
|
|
|
|
|
|
|
|
## Git workflow
|
|
|
|
|
|
|
|
|
|
### Branching strategy
|
|
|
|
|
|
|
|
|
|
For every spec change or new functionality:
|
|
|
|
|
|
|
|
|
|
1. Create a new branch from `dev` with a proper prefix:
|
|
|
|
|
- `feat/` for new features (e.g., `feat/tool-workshop`)
|
|
|
|
|
- `fix/` for bug fixes (e.g., `fix/terminal-tty`)
|
|
|
|
|
- `refactor/` for refactors (e.g., `refactor/api-cleanup`)
|
|
|
|
|
- `docs/` for documentation (e.g., `docs/api-guide`)
|
|
|
|
|
- `chore/` for maintenance (e.g., `chore/update-deps`)
|
|
|
|
|
2. Branch name should reference the OpenSpec change name when applicable.
|
|
|
|
|
3. Do not commit directly to `main` or `dev`.
|
|
|
|
|
|
|
|
|
|
### Completion and merge
|
|
|
|
|
|
|
|
|
|
When implementation is complete and verified:
|
|
|
|
|
|
|
|
|
|
1. Ensure all tests pass and quality gates are met.
|
|
|
|
|
2. Stage all changes with `git add -A`.
|
|
|
|
|
3. Create a commit with a proper conventional commit message (see below).
|
|
|
|
|
4. Switch to `dev`: `git checkout dev`.
|
|
|
|
|
5. Merge the feature branch: `git merge --no-ff <branch-name>`.
|
|
|
|
|
6. Push to remote: `git push origin dev`.
|
|
|
|
|
7. Delete the local feature branch if desired: `git branch -d <branch-name>`.
|
|
|
|
|
|
|
|
|
|
### Auto-commit on spec completion
|
|
|
|
|
|
|
|
|
|
When an OpenSpec change is fully implemented and all tasks are complete:
|
|
|
|
|