cyrus-edge-worker 0.2.37 → 0.2.39

package/dist/prompts/subroutines/changelog-update-gitlab.md

@@ -0,0 +1,79 @@
+# Changelog Update (GitLab) - Document Changes
+
+All verification checks have passed. Now update the changelog if the project uses one.
+
+## Your Tasks
+
+### 1. Push Current Branch and Create Draft MR
+First, push the current branch (even if there are no new commits) and create a draft MR to get an MR number:
+
+```bash
+# Push the branch to remote
+git push -u origin HEAD
+
+# Check if MR already exists, if not create a draft MR
+# IMPORTANT: The --target-branch flag MUST match the base_branch from the issue context
+glab mr view --output json 2>/dev/null || glab mr create --draft --target-branch [base_branch from context] --title "WIP: [brief description]" --description "Work in progress for [ISSUE-ID]. Full description to follow."
+```
+
+Record the MR URL and number for use in the changelog entry.
+
+### 2. Check for Changelog Files
+Check if the project has changelog files:
+```bash
+ls -la CHANGELOG.md CHANGELOG.internal.md 2>/dev/null || echo "NO_CHANGELOG"
+```
+
+**If no changelog files exist, complete with:** `Draft MR created at [MR URL]. No changelog files found.`
+
+### 3. Check for Existing Changelog Entry
+If changelog files exist, check if there's already a changelog entry for this issue:
+- Look in the `## [Unreleased]` section for entries mentioning the current Linear issue identifier
+- If an entry already exists for this issue, you may update it to add the MR link, but do NOT add duplicate entries
+
+### 4. Update Changelog with MR Link
+If changelog files exist and no entry exists (or entry needs MR link):
+
+**For user-facing changes (CHANGELOG.md):**
+- Add entry under `## [Unreleased]` in the appropriate subsection (`### Added`, `### Changed`, `### Fixed`, `### Removed`)
+- Focus on end-user impact from the perspective of users running the CLI
+- Be concise but descriptive about what users will experience differently
+- Include both the Linear issue identifier AND the MR link
+- Format: `- **Feature name** - Description. ([ISSUE-ID](https://linear.app/...), [!NUMBER](MR_URL))`
+
+**For internal/technical changes (CHANGELOG.internal.md):**
+- Add entry if the changes are internal development, refactors, or tooling updates
+- Follow the same format as CHANGELOG.md
+
+## Important Notes
+
+- **Create draft MR first** - this gives you the MR number to include in the changelog
+- **Always specify `--target-branch`** - use the target branch from the `<base_branch>` tag in the issue context. Do NOT rely on the repository's default branch setting.
+- **Only update changelogs if they exist** - not all projects use changelogs
+- **Avoid duplicate entries** - check if an entry already exists for this issue before adding
+- **Follow Keep a Changelog format** - https://keepachangelog.com/
+- **Group related changes** - consolidate multiple commits into a single meaningful entry
+- **Do NOT commit or push the changelog changes** - that happens in the next subroutine
+- Take as many turns as needed to complete these tasks
+
+## Expected Output
+
+**IMPORTANT: Do NOT post Linear comments.** Your output is for internal workflow only.
+
+Provide a brief completion message (1 sentence max):
+
+```
+Draft MR created at [MR URL]. Changelog updated for [ISSUE-ID].
+```
+
+Or if no changelog exists:
+
+```
+Draft MR created at [MR URL]. No changelog files found.
+```
+
+Or if entry already existed:
+
+```
+Draft MR created at [MR URL]. Changelog entry already exists for this issue.
+```

package/dist/prompts/subroutines/glab-mr.md

@@ -0,0 +1,106 @@
+# GitLab MR - Merge Request Management
+
+A draft MR exists and all changes have been committed and pushed. Now update the MR with a full description and optionally mark it as ready.
+
+## Your Tasks
+
+### 1. Get MR Information
+First, get the current MR URL and verify the target branch:
+```bash
+glab mr view --output json | jq -r '"\(.web_url) targeting \(.target_branch)"'
+```
+
+**IMPORTANT**: Verify that the MR targets the correct target branch (from `<base_branch>` in the issue context). If it doesn't, update it:
+```bash
+glab mr update --target-branch [correct target branch]
+```
+
+### 2. Update MR with Full Description
+Update the MR with a comprehensive description:
+```bash
+glab mr update --title "[descriptive title]" --description "[full description]"
+```
+
+**IMPORTANT: Assignee attribution**
+Check the `<assignee>` section from the issue context and add assignee information at the **very top** of the MR description, before the summary:
+
+- If a `<gitlab_username>` or `<github_username>` is available, format as: `Assignee: @username ([Display Name](linear_profile_url))`
+- If only a `<linear_profile_url>` is available (no username), format as: `Assignee: [Display Name](linear_profile_url)` using the `<linear_display_name>` and `<linear_profile_url>` values
+
+Follow this with a blank line, then the rest of the description. If no assignee information is available at all, skip this step.
+
+**IMPORTANT: Cyrus attribution marker**
+You MUST include the following hidden HTML comment somewhere in the MR description (e.g. at the very end). This marker is used to identify Cyrus-authored MRs for tracking purposes:
+```
+<!-- generated-by-cyrus -->
+```
+This marker is invisible when rendered on GitLab but allows the webhook to detect that this MR was authored by Cyrus, even when the MR is created under a human user's GitLab account.
+
+The MR description should include:
+- Summary of changes
+- Implementation approach
+- Testing performed
+- Any breaking changes or migration notes
+- Link to the Linear issue
+
+**IMPORTANT: Cyrus interaction tip**
+At the end of the MR description (before the `<!-- generated-by-cyrus -->` marker), include a tip section using the following exact format:
+
+```
+---
+
+> **Tip:** I will respond to comments that @ mention @{{gitlab_bot_username}} on this MR. You can also leave review comments, and I will automatically wake up to address each comment.
+```
+
+This helps reviewers know how to interact with Cyrus directly on the MR.
+
+Ensure the MR has a clear, descriptive title (remove "WIP:" or "Draft:" prefix if present).
+
+### 3. Mark MR as Ready (CONDITIONAL)
+
+**CRITICAL**: Before marking the MR as ready, you MUST check the `<agent_guidance>` section in your context.
+
+**DO NOT mark the MR as ready if ANY of the following conditions are true:**
+- The agent guidance specifies `--draft` in MR creation commands
+- The agent guidance mentions keeping MRs as drafts
+- The user has explicitly requested the MR remain as a draft
+- The project instructions specify draft MRs
+
+**Only if none of the above conditions apply**, convert the draft MR to ready for review:
+```bash
+glab mr update --ready
+```
+
+### 4. Final Checks
+- Confirm the MR URL is valid and accessible
+- Verify all commits are included in the MR
+- Verify the MR targets the correct target branch (from `<base_branch>` in context)
+- Check that CI/CD pipelines start running (if applicable)
+
+## Important Notes
+
+- **A draft MR already exists** - you're updating it and optionally marking it ready
+- **All commits are pushed** - the changelog already includes the MR link
+- **Be thorough with the MR description** - it should be self-contained and informative
+- **RESPECT AGENT GUIDANCE** - if guidance specifies draft MRs, do NOT mark as ready
+- **Verify the correct target branch** - ensure MR targets the `<base_branch>` from context
+- Take as many turns as needed to complete these tasks
+
+## Expected Output
+
+**IMPORTANT: Do NOT post Linear comments.** Your output is for internal workflow only.
+
+Provide a brief completion message (1 sentence max) that includes the MR URL and status:
+
+If marked as ready:
+```
+MR ready at [MR URL].
+```
+
+If kept as draft (due to agent guidance or user request):
+```
+Draft MR updated at [MR URL] (kept as draft per guidance).
+```
+
+Example: "MR ready at https://gitlab.com/org/repo/-/merge_requests/123."
+Example: "Draft MR updated at https://gitlab.com/org/repo/-/merge_requests/123 (kept as draft per guidance)."

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "cyrus-edge-worker",
-  "version": "0.2.37",
+  "version": "0.2.39",
   "description": "Unified edge worker for processing Linear issues with Claude",
   "type": "module",
   "main": "dist/index.js",
@@ -16,23 +16,24 @@
     "@linear/sdk": "^64.0.0",
     "@ngrok/ngrok": "^1.5.1",
     "chokidar": "^4.0.3",
-    "fastify": "^5.8.1",
+    "fastify": "^5.8.3",
     "fastify-mcp": "^2.1.0",
     "file-type": "^21.3.2",
     "ignore": "^7.0.5",
     "zod": "4.3.6",
-    "cyrus-claude-runner": "0.2.37",
-    "cyrus-cloudflare-tunnel-client": "0.2.37",
-    "cyrus-core": "0.2.37",
-    "cyrus-config-updater": "0.2.37",
-    "cyrus-cursor-runner": "0.2.37",
-    "cyrus-github-event-transport": "0.2.37",
-    "cyrus-codex-runner": "0.2.37",
-    "cyrus-gemini-runner": "0.2.37",
-    "cyrus-slack-event-transport": "0.2.37",
-    "cyrus-linear-event-transport": "0.2.37",
-    "cyrus-mcp-tools": "0.2.37",
-    "cyrus-simple-agent-runner": "0.2.37"
+    "cyrus-claude-runner": "0.2.39",
+    "cyrus-config-updater": "0.2.39",
+    "cyrus-core": "0.2.39",
+    "cyrus-codex-runner": "0.2.39",
+    "cyrus-cloudflare-tunnel-client": "0.2.39",
+    "cyrus-cursor-runner": "0.2.39",
+    "cyrus-gemini-runner": "0.2.39",
+    "cyrus-github-event-transport": "0.2.39",
+    "cyrus-gitlab-event-transport": "0.2.39",
+    "cyrus-mcp-tools": "0.2.39",
+    "cyrus-linear-event-transport": "0.2.39",
+    "cyrus-slack-event-transport": "0.2.39",
+    "cyrus-simple-agent-runner": "0.2.39"
   },
   "devDependencies": {
     "@types/node": "^20.0.0",