Run issue-worm on this repo

[leonarduk]

Adds .github/workflows/issue-worm.yml, so labelling an issue issue-worm starts a build here.

Opened from the issue-worm-pro dashboard's Issues tab.

Add the WORM_PAT secret

.github/workflows/issue-worm.yml authenticates as a WORM_PAT repository secret, which does
not exist yet. Until it does, every issue labelled issue-worm fails on the
action's first step.

secrets.GITHUB_TOKEN cannot stand in for it: a push made with the built-in
token deliberately does not trigger other workflows, so the pull request
issue-worm opens would never get a CI run, a review, or a required check.

A fine-grained token (recommended)

1. Open https://github.com/settings/personal-access-tokens/new.

2. Token name: anything you will recognise later, e.g. issue-worm leonarduk/local-github-runner.
   Expiration: your call -- issue-worm starts failing with a 401 the day
   it expires, so calendar the rotation.

3. Resource owner: leonarduk. If that is an organisation rather than your
   own account, an org owner has to approve the token before it works.

4. Repository access: Only select repositories, then leonarduk/local-github-runner.

5. Repository permissions -- these, and nothing else is needed:

   Permission	Level	What it buys
   Contents	Read and write	pushing issue-worm's branch
   Pull requests	Read and write	opening the pull request
   Issues	Read and write	reading the issue body (read), plus posting the live progress comment and saving a self-heal draft back onto the issue (write)
   Workflows	Read and write	only if issue-worm should be allowed to edit files under .github/workflows/; leave it off otherwise

   Read-only Metadata is added for you and is required. Issues: read is
   the one people miss -- only the issue-body fetch needs it, and that runs,
   and fails, before the push and pull request steps ever do.

6. Generate token, then copy it. GitHub shows it exactly once.

7. Paste it in at https://github.com/leonarduk/local-github-runner/settings/secrets/actions/new
   -- that is Settings -> Secrets and variables -> Actions, then
   New repository secret. Name it WORM_PAT, paste the token in as the
   secret, and Add secret.

Or a classic token

https://github.com/settings/tokens/new with the single repo scope covers
all three permissions above (tick workflow too for the same workflow-file
caveat). It is much coarser -- a classic token reaches every repo its owner
can -- so prefer the fine-grained one where you have the choice.

Then apply the issue-worm label to an issue here to try it.

Closes #168

[coderabbitai]

Important

• 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Advanced

Run ID: 2e8059b8-42c9-4038-b638-f0d1569d2200

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[github-actions]

GPT AI Code Review

Skipped: API key not configured

The OPENAI_API_KEY repository secret is not set.

To enable GPT reviews, add OPENAI_API_KEY as a repository secret:

1. Go to Settings > Secrets and variables > Actions in this repo.
2. Click New repository secret.
3. Name: OPENAI_API_KEY
4. Value: your GPT API key.

Once the secret is configured, re-run this workflow or push a new commit to trigger a fresh review.

REVIEW SKIPPED - API KEY NOT CONFIGURED

---

Reviewed by GPT via gpt-pr-review.yml. Advisory only.

[github-actions]

DeepSeek AI Code Review

1. Acceptance criteria

The PR adds .github/workflows/issue-worm.yml on the branch, which satisfies the first AC once merged to the default branch. The second AC (WORM_PAT secret) is explicitly out of scope for automation and is documented in the issue body — the workflow file correctly references secrets.WORM_PAT and the header comment documents the required secrets. No gap here.

2. Bugs and logic errors

• run-name will render literally on non-issue events. run-name: "issue #${{ github.event.issue.number }}: ${{ github.event.issue.title }}" is fine for issues: labeled, which is the only trigger, so this is not actually a bug — but note the comment claims the dashboard's actions_runs.py parses this prefix; if the workflow is ever extended to workflow_dispatch or push, the run-name will be issue #: and the dashboard link will break silently. Worth a guard or a comment.
• concurrency.cancel-in-progress: false combined with the self-retrigger gate. The if: github.event.label.name == 'issue-worm' gate stops the workflow from retriggering itself when issue-worm applies in-progress/pr-opened labels. That is correct. But note: if a user removes and re-adds the issue-worm label while a run is in flight, the second run queues behind the first (good) and then runs against a branch the first run may have already pushed. The action itself is responsible for idempotency here; the workflow cannot enforce it. Not blocking, but the comment "a second label event waits rather than racing the first for the same branch" overstates the guarantee — it serialises, it does not deduplicate.
• permissions: contents: read on the job. This is the workflow's GITHUB_TOKEN scope, not WORM_PAT. It is correct and minimal — the action uses WORM_PAT for writes. No issue, but worth confirming the action does not fall back to GITHUB_TOKEN anywhere; if it does, the push will silently fail to trigger downstream workflows, which is exactly the failure mode the issue warns about.

3. CLI and API safety

• DEEPSEEK_API_KEY is passed via env: unconditionally. On a self-hosted runner with local Ollama, the secret is still injected into the step environment. If the action or any subprocess it spawns logs its environment (e.g. on a crash traceback, or a set -x shell), the key leaks into the run log. Prefer gating the env var on the runner, or at minimum confirm the action never echoes env. This is the kind of thing that is fine until it isn't.
• github-token: ${{ secrets.WORM_PAT }} is passed as an action input, not an env var. GitHub masks secrets in logs, so this is acceptable, but action inputs are visible in the run's "Set up job" step metadata in some UI views. Standard practice, not blocking.
• No timeout-minutes on the job. A hung action (network stall against DeepSeek, or a stuck git push) will occupy a runner for the default 6 hours. For a workflow that runs on every issue-worm label, this is a real cost/availability risk. Recommend timeout-minutes: 30 or similar.
• @v1 floating tag. The comment justifies it, but a floating major tag on an action that receives WORM_PAT (a repo-write PAT) means a compromised or force-pushed v1 ref executes with full write access to this repo. Pinning to a SHA is the safer default for a token-bearing action; if you keep @v1, ensure the action repo has branch protection on the v1 tag and 2FA on the owner account.

4. Test coverage

No tests are added, which is expected for a workflow-only PR. The acceptance criteria are validated by the manual step in the issue ("apply the issue-worm label to an issue here to try it"). That is adequate for this change, but there is no automated check that the workflow YAML is valid — a typo in run-name or concurrency would only surface on the first labelled issue. Consider a actionlint step in a separate CI workflow (not this one) as a follow-up.

5. Suggested follow-up issues

• Add timeout-minutes to the build job in .github/workflows/issue-worm.yml
• Pin leonarduk/issue-worm to a commit SHA instead of the floating @v1 tag
• Gate DEEPSEEK_API_KEY injection on the runner type so it is not present on self-hosted Ollama runners
• Add an actionlint CI check for .github/workflows/*.yml
• Document the run-name prefix contract in a comment near actions_runs.py so future workflow edits do not silently break the dashboard link

APPROVE — the workflow satisfies the in-scope AC, the token-scope and self-retrigger reasoning is sound, and the remaining items are hardening rather than correctness blockers.

---

Reviewed by DeepSeek via deepseek-pr-review.yml. Advisory only.