feat(CC-0003): add minimal GitHub Actions CI workflow

[berendt]

• Add .github/workflows/ci.yaml with three parallel jobs
  (lint, test, test-integration) triggered on push to main
  and pull_request events
• Use golangci-lint-action v9 (v2.10) for lint job, delegating
  Go setup to the action internally
• Run make test and make test-integration in separate jobs
  using actions/setup-go with go-version-file: go.work for
  version management and automatic module caching
• Pin all GitHub Actions to full 40-character commit SHAs with
  version comments for supply-chain hardening
• Set least-privilege permissions (contents: read) and add
  concurrency group with cancel-in-progress to avoid redundant
  runs on superseded pushes
• Add reference documentation at docs/ci-workflow.md covering
  trigger events, job descriptions, Go setup conventions,
  concurrency behavior, and project dependencies

[sourcery-ai]

Reviewer's Guide

Introduces a minimal GitHub Actions CI pipeline with three SHA-pinned parallel jobs (lint, unit tests, integration tests) plus reference documentation and planwerk metadata updates, using least-privilege permissions, concurrency controls, and go.work-based Go setup.

Sequence diagram for CI workflow concurrency cancellation behavior

sequenceDiagram
  actor Developer
  participant Repo as GitHubRepository
  participant Actions as GitHubActions
  participant RunOld as WorkflowRun_old
  participant RunNew as WorkflowRun_new

  Developer->>Repo: push commit A to main
  Repo->>Actions: emit push event (main)
  Actions->>RunOld: start CI workflow (group=ref-workflow)

  RunOld->>RunOld: execute jobs lint, test, test-integration

  Developer->>Repo: push commit B to main
  Repo->>Actions: emit push event (main)
  Actions->>RunNew: start CI workflow (same group)
  Actions->>RunOld: cancel in-progress (concurrency cancel-in-progress=true)

  RunNew->>RunNew: execute jobs lint, test, test-integration

Loading

File-Level Changes

Change	Details	Files
Add a minimal CI GitHub Actions workflow with three parallel jobs for linting, unit tests, and integration tests, using secure defaults.	Define CI workflow triggering on pushes to main and all pull_request events Configure top-level least-privilege permissions with contents: read Add concurrency group scoped by ref and workflow name with cancel-in-progress enabled Create lint job using golangci-lint-action v9 which manages Go installation internally Create test job that checks out the repo, sets up Go from go.work via actions/setup-go, and runs make test Create test-integration job mirroring the test job but running make test-integration Pin all GitHub Actions to full 40-character commit SHAs with human-readable version comments	.github/workflows/ci.yaml
Document the CI workflow behavior, conventions, and dependencies for maintainers.	Describe workflow location, trigger events, and branch behavior Explain each job (lint, test, test-integration) including steps and action versions Document Go setup conventions using go.work and automatic module caching Describe concurrency configuration and its per-branch cancellation semantics Outline permissions model and least-privilege rationale List dependencies on go.work, Makefile, and .golangci.yml from prior changes Capture conventions such as SPDX headers, YAML style, quoted on, and SHA-pinned actions	docs/ci-workflow.md
Update planwerk tracking metadata to reflect implementation and review state for this feature slice.	Move feature tracking JSON from features to progress to mark implementation progress Add a new review JSON entry to record the first review for this feature slice	.planwerk/features/CC-0003-a003-add-minimal-github-actions-ci-workflow.json .planwerk/progress/CC-0003-a003-add-minimal-github-actions-ci-workflow.json .planwerk/reviews/CC-0003-a003-add-minimal-github-actions-ci-workflow-review-1.json

---

Tips and commands

Interacting with Sourcery

• Trigger a new review: Comment @sourcery-ai review on the pull request.
• Continue discussions: Reply directly to Sourcery's review comments.
• Generate a GitHub issue from a review comment: Ask Sourcery to create an
  issue from a review comment by replying to it. You can also reply to a
  review comment with @sourcery-ai issue to create an issue from it.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull
  request title to generate a title at any time. You can also comment
  @sourcery-ai title on the pull request to (re-)generate the title at any time.
• Generate a pull request summary: Write @sourcery-ai summary anywhere in
  the pull request body to generate a PR summary at any time exactly where you
  want it. You can also comment @sourcery-ai summary on the pull request to
  (re-)generate the summary at any time.
• Generate reviewer's guide: Comment @sourcery-ai guide on the pull
  request to (re-)generate the reviewer's guide at any time.
• Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
  pull request to resolve all Sourcery comments. Useful if you've already
  addressed all the comments and don't want to see them anymore.
• Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
  request to dismiss all existing Sourcery reviews. Especially useful if you
  want to start fresh with a new review - don't forget to comment
  @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

• Enable or disable review features such as the Sourcery-generated pull request
  summary, the reviewer's guide, and others.
• Change the review language.
• Add, remove or edit custom review instructions.
• Adjust other review settings.

Getting Help

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

[sourcery-ai]

Hey - I've found 1 issue, and left some high level feedback:

• Consider adding paths / paths-ignore filters to the workflow triggers so that docs-only or non-Go changes don’t unnecessarily run the full CI pipeline.
• It may be useful to set explicit timeout-minutes values on each job (lint, test, test-integration) to avoid hanging runs consuming runners indefinitely if something stalls.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- Consider adding `paths` / `paths-ignore` filters to the workflow triggers so that docs-only or non-Go changes don’t unnecessarily run the full CI pipeline.
- It may be useful to set explicit `timeout-minutes` values on each job (lint, test, test-integration) to avoid hanging runs consuming runners indefinitely if something stalls.

## Individual Comments

### Comment 1
<location path=".github/workflows/ci.yaml" line_range="38-39" />
<code_context>
+      - name: Run unit tests
+        run: make test
+
+  test-integration:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@34e114876b0b11c390a56381ad16ebd13914f8d5 # v4
+      - uses: actions/setup-go@40f1582b2485089dde7abd97c1529aa768e1baff # v5
+        with:
+          go-version-file: go.work
+      - name: Run integration tests
+        run: make test-integration
</code_context>
<issue_to_address>
**suggestion (testing):** Adding explicit timeouts for long-running integration tests can prevent stuck workflows.

Since `make test-integration` may depend on external services and could hang, please configure `timeout-minutes` on this job (or the test step) so a stuck run doesn’t block runners indefinitely.

```suggestion
  test-integration:
    runs-on: ubuntu-latest
    timeout-minutes: 30
```
</issue_to_address>

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[sourcery-ai]

suggestion (testing): Adding explicit timeouts for long-running integration tests can prevent stuck workflows.

Since make test-integration may depend on external services and could hang, please configure timeout-minutes on this job (or the test step) so a stuck run doesn’t block runners indefinitely.

Suggested change

	test-integration:
	runs-on: ubuntu-latest
	test-integration:
	runs-on: ubuntu-latest
	timeout-minutes: 30