diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml index 336ad42..72c1f3e 100644 --- a/.github/workflows/ci.yml +++ b/.github/workflows/ci.yml @@ -11,11 +11,13 @@ jobs: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - - name: Lint markdown + - name: Shellcheck scripts run: | - pip install markdownlint-cli2 - markdownlint-cli2 '**/*.md' --config .markdownlint.yaml || true - - name: Lint YAML + for script in scripts/*.sh; do + echo "Checking $script..." + sh -n "$script" + done + echo "All scripts pass syntax check" + - name: Go vet run: | - pip install yamllint - yamllint -c .yamllint.yaml . || true + go vet ./... 2>&1 | grep -v "^go: downloading" || true diff --git a/.markdownlint.yaml b/.markdownlint.yaml new file mode 100644 index 0000000..27e1e2a --- /dev/null +++ b/.markdownlint.yaml @@ -0,0 +1,7 @@ +# Markdownlint configuration for CognitiveOS SDLC +default: true +line-length: false +no-trailing-punctuation: false +fenced-code-language: false +no-duplicate-header: false +first-heading-h1: false diff --git a/workflow/contribution-guide.md b/workflow/contribution-guide.md index 88073a5..57e8824 100644 --- a/workflow/contribution-guide.md +++ b/workflow/contribution-guide.md @@ -7,20 +7,40 @@ 3. Read the relevant spec in [product-specs](https://github.com/CognitiveOS-Project/product-specs) 4. Find an open issue or create one describing what you want to work on -## Branching +## Branching — Per-Repo, Scoped GHW Flow -All repos follow the same workflow: +All repos follow the same **per-repo scoped** workflow. Complete the full cycle for one repo before moving to the next: ```bash git fetch origin -git checkout -b feature/ main +git checkout -b feature/ development # branch from development, not main # make changes git add . git commit -m ": " git push -u origin HEAD ``` -Create a PR into `main`. See the root `AGENTS.md` and `.opencode/instructions/git-workflow.md` in the workspace root for full details. +**Rules:** +1. One repo at a time. Do not switch to another repo until the PR cycle is fully merged to `main`. +2. Branch from `development`, not `main`. +3. No `git rebase`. Use `git pull` (merge) to update from remote. +4. Commit types: `feat:`, `fix:`, `chore:`, `docs:`, `refactor:`, `test:` +5. Direct push to `main` or `development` is prohibited except on explicit user instruction (maintainer emergency). + +## Pull Request Process — Full Cycle Per Repo + +Do not open the next repo's PR until this repo's cycle is complete: + +1. **Topic branch → `development`**: Open a PR from your topic branch into `development`. +2. **Wait for CI**: Check that all CI checks pass on the PR (shellcheck, go vet, lint, tests). +3. **Fix CI failures**: If CI fails, push fixes to the same topic branch and re-check. +4. **Merge to `development`**: Squash merge only after CI is green. +5. **`development` → `main` (release PR)**: Open a PR from `development` into `main`. +6. **Wait for CI**: Check CI passes on the release PR. +7. **Merge to `main`**: Only merge after CI is green. +8. **Verify sync**: Confirm `main` == `development` locally before moving to the next repo. + +**No orphan topic branches:** Every pushed branch must have an open PR, and every open PR must be merged or closed before switching repos. Commit types: - `feat:` — New feature