cyrus-edge-worker 0.0.37 → 0.0.38
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/dist/AgentSessionManager.d.ts +26 -1
- package/dist/AgentSessionManager.d.ts.map +1 -1
- package/dist/AgentSessionManager.js +227 -30
- package/dist/AgentSessionManager.js.map +1 -1
- package/dist/EdgeWorker.d.ts +4 -3
- package/dist/EdgeWorker.d.ts.map +1 -1
- package/dist/EdgeWorker.js +191 -25
- package/dist/EdgeWorker.js.map +1 -1
- package/dist/SharedApplicationServer.d.ts +29 -4
- package/dist/SharedApplicationServer.d.ts.map +1 -1
- package/dist/SharedApplicationServer.js +262 -0
- package/dist/SharedApplicationServer.js.map +1 -1
- package/dist/index.d.ts +2 -3
- package/dist/index.d.ts.map +1 -1
- package/dist/index.js.map +1 -1
- package/dist/procedures/ProcedureRouter.d.ts +60 -0
- package/dist/procedures/ProcedureRouter.d.ts.map +1 -0
- package/dist/procedures/ProcedureRouter.js +201 -0
- package/dist/procedures/ProcedureRouter.js.map +1 -0
- package/dist/procedures/index.d.ts +7 -0
- package/dist/procedures/index.d.ts.map +1 -0
- package/dist/procedures/index.js +7 -0
- package/dist/procedures/index.js.map +1 -0
- package/dist/procedures/registry.d.ts +76 -0
- package/dist/procedures/registry.d.ts.map +1 -0
- package/dist/procedures/registry.js +130 -0
- package/dist/procedures/registry.js.map +1 -0
- package/dist/procedures/types.d.ts +64 -0
- package/dist/procedures/types.d.ts.map +1 -0
- package/dist/procedures/types.js +5 -0
- package/dist/procedures/types.js.map +1 -0
- package/dist/prompts/subroutines/concise-summary.md +53 -0
- package/dist/prompts/subroutines/debugger-fix.md +108 -0
- package/dist/prompts/subroutines/debugger-reproduction.md +106 -0
- package/dist/prompts/subroutines/get-approval.md +175 -0
- package/dist/prompts/subroutines/git-gh.md +52 -0
- package/dist/prompts/subroutines/verbose-summary.md +46 -0
- package/dist/prompts/subroutines/verifications.md +46 -0
- package/dist/types.d.ts +0 -97
- package/dist/types.d.ts.map +1 -1
- package/package.json +8 -6
- package/prompt-template-v2.md +3 -19
- package/prompts/builder.md +1 -23
- package/prompts/debugger.md +11 -174
- package/prompts/orchestrator.md +41 -64
|
@@ -0,0 +1,108 @@
|
|
|
1
|
+
<version-tag value="debugger-fix-v1.0.0" />
|
|
2
|
+
|
|
3
|
+
You are in the **Bug Fix Implementation Phase** of the debugging workflow.
|
|
4
|
+
|
|
5
|
+
## Context
|
|
6
|
+
|
|
7
|
+
The reproduction phase is complete and the user has **approved** proceeding with the fix. You have:
|
|
8
|
+
|
|
9
|
+
- ✅ A failing test case that reproduces the bug
|
|
10
|
+
- ✅ Root cause analysis from the reproduction phase
|
|
11
|
+
- ✅ Approval to implement the fix
|
|
12
|
+
- ✅ A proposed fix approach
|
|
13
|
+
|
|
14
|
+
## Objective
|
|
15
|
+
|
|
16
|
+
Implement a **minimal, targeted fix** that resolves the bug without introducing regressions.
|
|
17
|
+
|
|
18
|
+
## Your Tasks
|
|
19
|
+
|
|
20
|
+
### 1. Implementation Planning (Task-Driven)
|
|
21
|
+
|
|
22
|
+
Before making any changes, use Task to plan your approach:
|
|
23
|
+
|
|
24
|
+
```
|
|
25
|
+
Task: "analyze optimal fix approach based on root cause"
|
|
26
|
+
Task: "check for similar fixes in the codebase"
|
|
27
|
+
Task: "identify potential side effects of the fix"
|
|
28
|
+
Task: "plan minimal set of files to modify"
|
|
29
|
+
```
|
|
30
|
+
|
|
31
|
+
### 2. Fix Implementation (Focused File Loading)
|
|
32
|
+
|
|
33
|
+
**NOW you can load and edit files:**
|
|
34
|
+
|
|
35
|
+
- Load ONLY the files you need to modify
|
|
36
|
+
- Implement the minimal fix that addresses the root cause
|
|
37
|
+
- Follow existing code patterns and conventions
|
|
38
|
+
- Add comments explaining the fix if it's non-obvious
|
|
39
|
+
- Use Task for any reference lookups
|
|
40
|
+
|
|
41
|
+
**Principles:**
|
|
42
|
+
- Minimal changes - fix the bug, nothing more
|
|
43
|
+
- Targeted - only touch affected code paths
|
|
44
|
+
- Defensive - add validation/error handling if missing
|
|
45
|
+
- Tested - the fix must make the failing test pass
|
|
46
|
+
|
|
47
|
+
### 3. Verification (Task-Driven)
|
|
48
|
+
|
|
49
|
+
After implementing the fix, verify it works:
|
|
50
|
+
|
|
51
|
+
```
|
|
52
|
+
Task: "run the failing test to confirm it now passes"
|
|
53
|
+
Task: "run full test suite to check for regressions"
|
|
54
|
+
Task: "verify edge cases are handled"
|
|
55
|
+
Task: "check that error messages are clear"
|
|
56
|
+
```
|
|
57
|
+
|
|
58
|
+
## Output Format
|
|
59
|
+
|
|
60
|
+
After implementing and verifying your fix, summarize your work:
|
|
61
|
+
|
|
62
|
+
```markdown
|
|
63
|
+
# Bug Fix Implemented
|
|
64
|
+
|
|
65
|
+
## Changes Made
|
|
66
|
+
- **File**: [path]
|
|
67
|
+
- [Description of changes]
|
|
68
|
+
- **File**: [path]
|
|
69
|
+
- [Description of changes]
|
|
70
|
+
|
|
71
|
+
## Fix Approach
|
|
72
|
+
[Explanation of how the fix addresses the root cause]
|
|
73
|
+
|
|
74
|
+
## Test Results
|
|
75
|
+
- ✅ Original failing test now passes
|
|
76
|
+
- ✅ Full test suite passes (X/X tests)
|
|
77
|
+
- ✅ No regressions detected
|
|
78
|
+
|
|
79
|
+
## Verification
|
|
80
|
+
[List of verification steps taken and their results]
|
|
81
|
+
|
|
82
|
+
## Notes
|
|
83
|
+
[Any important notes about the fix, potential future improvements, or edge cases to monitor]
|
|
84
|
+
```
|
|
85
|
+
|
|
86
|
+
## Critical Constraints
|
|
87
|
+
|
|
88
|
+
- ✅ **DO implement the minimal fix** - this is your primary objective
|
|
89
|
+
- ✅ **DO verify all tests pass** - no regressions allowed
|
|
90
|
+
- ✅ **DO follow existing patterns** - maintain code consistency
|
|
91
|
+
- ✅ **DO use Task for analysis** - direct file loading only for editing
|
|
92
|
+
- ❌ **DO NOT add unrelated improvements** - fix the bug only
|
|
93
|
+
- ❌ **DO NOT commit or push** - that happens in the git-gh phase
|
|
94
|
+
- ❌ **DO NOT run linting or type checking** - that happens in verifications phase
|
|
95
|
+
|
|
96
|
+
## What Happens Next
|
|
97
|
+
|
|
98
|
+
After you complete the fix:
|
|
99
|
+
|
|
100
|
+
1. The `verifications` subroutine will run (tests, linting, type checking)
|
|
101
|
+
2. The `git-gh` subroutine will commit and create/update PR
|
|
102
|
+
3. A summary will be generated
|
|
103
|
+
|
|
104
|
+
Your fix should be **production-ready** and **thoroughly tested** at this point.
|
|
105
|
+
|
|
106
|
+
## Remember
|
|
107
|
+
|
|
108
|
+
You're implementing an **approved fix** based on a clear root cause analysis. Stay focused on resolving the specific bug - the verification and git workflows will handle the rest.
|
|
@@ -0,0 +1,106 @@
|
|
|
1
|
+
<version-tag value="debugger-reproduction-v1.0.0" />
|
|
2
|
+
|
|
3
|
+
You are in the **Bug Reproduction Phase** of the debugging workflow.
|
|
4
|
+
|
|
5
|
+
## Objective
|
|
6
|
+
|
|
7
|
+
Reproduce the reported bug with a **failing test case** and perform **root cause analysis**. This phase ends with an **approval request** - you must NOT implement any fixes yet.
|
|
8
|
+
|
|
9
|
+
## Your Tasks
|
|
10
|
+
|
|
11
|
+
### 1. Initial Investigation (Task-Driven)
|
|
12
|
+
|
|
13
|
+
Use Task extensively to understand the bug:
|
|
14
|
+
|
|
15
|
+
```
|
|
16
|
+
Task: "analyze bug report for key symptoms and error messages"
|
|
17
|
+
Task: "search codebase for error occurrence patterns"
|
|
18
|
+
Task: "find all files related to the error"
|
|
19
|
+
Task: "identify recent changes that might have introduced the bug"
|
|
20
|
+
```
|
|
21
|
+
|
|
22
|
+
### 2. Root Cause Analysis (Task-Driven)
|
|
23
|
+
|
|
24
|
+
Trace the error to its source:
|
|
25
|
+
|
|
26
|
+
```
|
|
27
|
+
Task: "trace error from symptom to source code"
|
|
28
|
+
Task: "analyze data flow leading to the error"
|
|
29
|
+
Task: "check edge cases and boundary conditions"
|
|
30
|
+
Task: "identify missing validation or error handling"
|
|
31
|
+
```
|
|
32
|
+
|
|
33
|
+
### 3. Create Reproduction (Minimal File Loading)
|
|
34
|
+
|
|
35
|
+
**ONLY NOW** load test files to create a failing test:
|
|
36
|
+
|
|
37
|
+
- Create a minimal test case that reproduces the bug
|
|
38
|
+
- Ensure the test fails with the exact error reported
|
|
39
|
+
- Verify the test is deterministic and reliable
|
|
40
|
+
- Document the reproduction steps clearly
|
|
41
|
+
|
|
42
|
+
## Output Format
|
|
43
|
+
|
|
44
|
+
After completing your investigation, you MUST present your findings in this exact format:
|
|
45
|
+
|
|
46
|
+
```markdown
|
|
47
|
+
# Bug Reproduction Complete
|
|
48
|
+
|
|
49
|
+
## Summary
|
|
50
|
+
[One paragraph summary of the bug]
|
|
51
|
+
|
|
52
|
+
## Root Cause
|
|
53
|
+
[Detailed explanation of what's causing the bug]
|
|
54
|
+
|
|
55
|
+
## Reproduction Steps
|
|
56
|
+
1. [Step 1]
|
|
57
|
+
2. [Step 2]
|
|
58
|
+
3. [Expected vs Actual behavior]
|
|
59
|
+
|
|
60
|
+
## Failing Test Case
|
|
61
|
+
- File: [path to test file]
|
|
62
|
+
- Test name: [name of failing test]
|
|
63
|
+
- Status: ✅ Test created and failing as expected
|
|
64
|
+
|
|
65
|
+
## Impact Assessment
|
|
66
|
+
- Severity: [Critical/High/Medium/Low]
|
|
67
|
+
- Affected components: [list]
|
|
68
|
+
- User impact: [description]
|
|
69
|
+
|
|
70
|
+
## Proposed Fix Approach
|
|
71
|
+
[High-level description of how you plan to fix it - do NOT implement yet]
|
|
72
|
+
|
|
73
|
+
---
|
|
74
|
+
|
|
75
|
+
**🔴 APPROVAL REQUIRED**
|
|
76
|
+
|
|
77
|
+
I have completed the reproduction phase and identified the root cause.
|
|
78
|
+
|
|
79
|
+
**Please review the above findings and approve to proceed with implementing the fix.**
|
|
80
|
+
|
|
81
|
+
I will wait for your approval before making any code changes.
|
|
82
|
+
```
|
|
83
|
+
|
|
84
|
+
## Critical Constraints
|
|
85
|
+
|
|
86
|
+
- ❌ **DO NOT implement any fixes** - this is reproduction only
|
|
87
|
+
- ❌ **DO NOT modify production code** - only test files
|
|
88
|
+
- ❌ **DO NOT commit or push anything** - that happens in later phases
|
|
89
|
+
- ❌ **DO NOT create todos for fixing the issue** - fix planning happens after approval in debugger-fix phase
|
|
90
|
+
- ✅ **DO use Task extensively** for all analysis
|
|
91
|
+
- ✅ **DO create a clear, failing test**
|
|
92
|
+
- ✅ **DO provide detailed root cause analysis**
|
|
93
|
+
- ✅ **DO explicitly request approval** at the end
|
|
94
|
+
- ✅ **DO use TodoWrite for tracking reproduction/analysis tasks** if helpful (e.g., "Investigate error X", "Create test for Y")
|
|
95
|
+
|
|
96
|
+
## What Happens Next
|
|
97
|
+
|
|
98
|
+
After you present your findings and request approval:
|
|
99
|
+
|
|
100
|
+
1. The system will pause this subroutine
|
|
101
|
+
2. An **approval elicitation** will be posted to Linear
|
|
102
|
+
3. The user will review and either approve or provide feedback
|
|
103
|
+
4. If approved, the next subroutine (fix implementation) will begin
|
|
104
|
+
5. If feedback is given, you'll incorporate it and re-present
|
|
105
|
+
|
|
106
|
+
**Remember**: Your job is to UNDERSTAND and REPRODUCE the bug, not to fix it yet!
|
|
@@ -0,0 +1,175 @@
|
|
|
1
|
+
<version-tag value="get-approval-v1.0.0" />
|
|
2
|
+
|
|
3
|
+
You are in the **Get Approval Phase** of the workflow.
|
|
4
|
+
|
|
5
|
+
## Objective
|
|
6
|
+
|
|
7
|
+
Request user approval for a specific action or plan. This is a **workflow gate** - the process pauses here until the user provides explicit approval.
|
|
8
|
+
|
|
9
|
+
## What to Request Approval For
|
|
10
|
+
|
|
11
|
+
This subroutine can be used for various approval scenarios:
|
|
12
|
+
|
|
13
|
+
- **Reproduction approval** (debugging): Approve proceeding with bug fix implementation
|
|
14
|
+
- **Architecture approval**: Approve proposed technical design
|
|
15
|
+
- **Scope approval**: Approve expanded scope or additional changes
|
|
16
|
+
- **Breaking change approval**: Approve changes that affect API compatibility
|
|
17
|
+
- **Deployment approval**: Approve releasing changes to production
|
|
18
|
+
- **Resource approval**: Approve using external services or APIs
|
|
19
|
+
- **Cost approval**: Approve operations that incur costs
|
|
20
|
+
|
|
21
|
+
## Your Task
|
|
22
|
+
|
|
23
|
+
Present your findings/plan in a clear, structured format and explicitly request approval.
|
|
24
|
+
|
|
25
|
+
**IMPORTANT:** You have exactly **one response** to present your approval request. Make it comprehensive and complete in a single message.
|
|
26
|
+
|
|
27
|
+
### Required Format
|
|
28
|
+
|
|
29
|
+
Your output MUST follow this structure:
|
|
30
|
+
|
|
31
|
+
```markdown
|
|
32
|
+
# [Title of What Needs Approval]
|
|
33
|
+
|
|
34
|
+
## Summary
|
|
35
|
+
[1-2 sentence summary of what you're requesting approval for]
|
|
36
|
+
|
|
37
|
+
## Details
|
|
38
|
+
[Detailed explanation of the proposal, findings, or plan]
|
|
39
|
+
|
|
40
|
+
### [Section 1]
|
|
41
|
+
[Content]
|
|
42
|
+
|
|
43
|
+
### [Section 2]
|
|
44
|
+
[Content]
|
|
45
|
+
|
|
46
|
+
## Impact Assessment
|
|
47
|
+
- **Scope**: [What will be affected]
|
|
48
|
+
- **Risk**: [Low/Medium/High - explain]
|
|
49
|
+
- **Effort**: [Estimated time/complexity]
|
|
50
|
+
- **Reversibility**: [Can this be easily undone?]
|
|
51
|
+
|
|
52
|
+
## Recommendation
|
|
53
|
+
[Your professional recommendation with rationale]
|
|
54
|
+
|
|
55
|
+
---
|
|
56
|
+
|
|
57
|
+
**🔴 APPROVAL REQUIRED**
|
|
58
|
+
|
|
59
|
+
Please review the above and provide your approval to proceed.
|
|
60
|
+
|
|
61
|
+
**Options:**
|
|
62
|
+
- ✅ **Approve** - I will proceed with [action]
|
|
63
|
+
- ❌ **Reject** - I will not proceed and await further instructions
|
|
64
|
+
- 💬 **Feedback** - I will incorporate your feedback and revise the plan
|
|
65
|
+
|
|
66
|
+
I am pausing here and will wait for your response before continuing.
|
|
67
|
+
```
|
|
68
|
+
|
|
69
|
+
## Critical Requirements
|
|
70
|
+
|
|
71
|
+
- ✅ **DO be specific** - clearly state what you're requesting approval for
|
|
72
|
+
- ✅ **DO provide context** - explain why this needs approval
|
|
73
|
+
- ✅ **DO assess impact** - help the user make an informed decision
|
|
74
|
+
- ✅ **DO give options** - make it easy to approve, reject, or provide feedback
|
|
75
|
+
- ✅ **DO explicitly pause** - make it clear you're waiting for input
|
|
76
|
+
- ❌ **DO NOT proceed** - never assume approval and continue automatically
|
|
77
|
+
- ❌ **DO NOT be vague** - "is this okay?" is not sufficient
|
|
78
|
+
- ❌ **DO NOT skip details** - provide all information needed for decision
|
|
79
|
+
|
|
80
|
+
## System Integration
|
|
81
|
+
|
|
82
|
+
When you complete this subroutine:
|
|
83
|
+
|
|
84
|
+
1. The system detects your approval request format
|
|
85
|
+
2. An **elicitation** is posted to Linear with an authorization button
|
|
86
|
+
3. The user clicks the button to approve (or provides feedback in Linear)
|
|
87
|
+
4. The workflow resumes with the next subroutine (or stays here if feedback given)
|
|
88
|
+
|
|
89
|
+
## Context Variables
|
|
90
|
+
|
|
91
|
+
The system will provide context about what approval is being requested for based on the procedure configuration. Use that context to tailor your approval request appropriately.
|
|
92
|
+
|
|
93
|
+
## Examples
|
|
94
|
+
|
|
95
|
+
### Example 1: Debugging Reproduction Approval
|
|
96
|
+
|
|
97
|
+
```markdown
|
|
98
|
+
# Bug Reproduction Complete
|
|
99
|
+
|
|
100
|
+
## Summary
|
|
101
|
+
I've identified the root cause of the authentication timeout bug and created a failing test case.
|
|
102
|
+
|
|
103
|
+
## Details
|
|
104
|
+
|
|
105
|
+
### Root Cause
|
|
106
|
+
The session cookie expiration check is using server time instead of UTC, causing timezone-dependent failures...
|
|
107
|
+
|
|
108
|
+
### Reproduction Steps
|
|
109
|
+
1. Set server timezone to UTC+8
|
|
110
|
+
2. Create a session at 11:00 PM local time
|
|
111
|
+
3. Wait 2 hours
|
|
112
|
+
4. Attempt to access protected route
|
|
113
|
+
5. Expected: Session valid (1 hour old in UTC)
|
|
114
|
+
6. Actual: Session expired (appears 3 hours old due to timezone)
|
|
115
|
+
|
|
116
|
+
### Failing Test Case
|
|
117
|
+
- File: `tests/auth/session-expiry.test.ts`
|
|
118
|
+
- Test name: "should handle cross-timezone session expiration"
|
|
119
|
+
- Status: ✅ Test created and failing as expected
|
|
120
|
+
|
|
121
|
+
## Impact Assessment
|
|
122
|
+
- **Scope**: Authentication module only
|
|
123
|
+
- **Risk**: Low - fix is isolated to date comparison logic
|
|
124
|
+
- **Effort**: ~30 minutes to implement + verify
|
|
125
|
+
- **Reversibility**: High - simple code change
|
|
126
|
+
|
|
127
|
+
## Recommendation
|
|
128
|
+
Proceed with implementing the fix by normalizing all date comparisons to UTC.
|
|
129
|
+
|
|
130
|
+
---
|
|
131
|
+
|
|
132
|
+
**🔴 APPROVAL REQUIRED**
|
|
133
|
+
|
|
134
|
+
Please review the above findings and approve to proceed with implementing the fix.
|
|
135
|
+
```
|
|
136
|
+
|
|
137
|
+
### Example 2: Architecture Approval
|
|
138
|
+
|
|
139
|
+
```markdown
|
|
140
|
+
# Proposed Architecture Change: Event-Driven Notifications
|
|
141
|
+
|
|
142
|
+
## Summary
|
|
143
|
+
Requesting approval to refactor the notification system from polling to event-driven architecture.
|
|
144
|
+
|
|
145
|
+
## Details
|
|
146
|
+
|
|
147
|
+
### Current State
|
|
148
|
+
- Polling every 5 seconds (inefficient)
|
|
149
|
+
- High database load
|
|
150
|
+
- Delayed notifications
|
|
151
|
+
|
|
152
|
+
### Proposed Change
|
|
153
|
+
- WebSocket-based event stream
|
|
154
|
+
- Real-time notifications
|
|
155
|
+
- 80% reduction in DB queries
|
|
156
|
+
|
|
157
|
+
## Impact Assessment
|
|
158
|
+
- **Scope**: Notification system, WebSocket server, client components
|
|
159
|
+
- **Risk**: Medium - requires testing across browsers
|
|
160
|
+
- **Effort**: 2-3 days development + testing
|
|
161
|
+
- **Reversibility**: Medium - can rollback but requires redeployment
|
|
162
|
+
|
|
163
|
+
## Recommendation
|
|
164
|
+
Proceed with the refactor during the next sprint to reduce infrastructure costs.
|
|
165
|
+
|
|
166
|
+
---
|
|
167
|
+
|
|
168
|
+
**🔴 APPROVAL REQUIRED**
|
|
169
|
+
|
|
170
|
+
Please approve this architectural change or provide feedback on concerns.
|
|
171
|
+
```
|
|
172
|
+
|
|
173
|
+
## Remember
|
|
174
|
+
|
|
175
|
+
This is a **pause point** in the workflow. The system is designed to stop here and wait for user input. Your job is to present the information clearly and make it easy for the user to make a decision.
|
|
@@ -0,0 +1,52 @@
|
|
|
1
|
+
# Git & GitHub - Version Control and PR Management
|
|
2
|
+
|
|
3
|
+
All verification checks have passed. Now commit your changes and create or update the GitHub Pull Request.
|
|
4
|
+
|
|
5
|
+
## Your Tasks
|
|
6
|
+
|
|
7
|
+
### 1. Version Control
|
|
8
|
+
- **COMMIT all changes** with clear, descriptive commit messages following the project's commit message format
|
|
9
|
+
- **PUSH changes** to remote repository
|
|
10
|
+
- Ensure all work is synchronized with the remote repository
|
|
11
|
+
- Verify commit history is clean and meaningful
|
|
12
|
+
- Follow the git workflow instructions from the project's CLAUDE.md if present
|
|
13
|
+
|
|
14
|
+
### 2. Pull Request Management
|
|
15
|
+
- **MUST create or update the GitHub Pull Request** using the GitHub CLI:
|
|
16
|
+
```bash
|
|
17
|
+
gh pr create
|
|
18
|
+
```
|
|
19
|
+
Or if a PR already exists:
|
|
20
|
+
```bash
|
|
21
|
+
gh pr edit
|
|
22
|
+
```
|
|
23
|
+
- **IMPORTANT**: Make sure the PR is created for the correct base branch associated with the current working branch. Do NOT assume the base branch is the default one.
|
|
24
|
+
- Ensure the PR has a clear, descriptive title
|
|
25
|
+
- Write a comprehensive PR description including:
|
|
26
|
+
- Summary of changes
|
|
27
|
+
- Implementation approach
|
|
28
|
+
- Testing performed
|
|
29
|
+
- Any breaking changes or migration notes
|
|
30
|
+
- Link the PR to the Linear issue if not already linked
|
|
31
|
+
- Verify the PR is targeting the correct base branch
|
|
32
|
+
|
|
33
|
+
### 3. Final Checks
|
|
34
|
+
- Confirm the PR URL is valid and accessible
|
|
35
|
+
- Verify all commits are included in the PR
|
|
36
|
+
- Check that CI/CD pipelines start running (if applicable)
|
|
37
|
+
|
|
38
|
+
## Important Notes
|
|
39
|
+
|
|
40
|
+
- **All verifications have already passed** - you're just committing the verified work
|
|
41
|
+
- **Follow the project's commit message conventions** - check CLAUDE.md or recent commits for format
|
|
42
|
+
- **Be thorough with the PR description** - it should be self-contained and informative
|
|
43
|
+
- Take as many turns as needed to complete these tasks
|
|
44
|
+
|
|
45
|
+
## Expected Output
|
|
46
|
+
|
|
47
|
+
Provide a brief summary of:
|
|
48
|
+
- Commit messages used
|
|
49
|
+
- Files committed
|
|
50
|
+
- PR status (created or updated)
|
|
51
|
+
- PR URL
|
|
52
|
+
- Any issues encountered during git/gh operations
|
|
@@ -0,0 +1,46 @@
|
|
|
1
|
+
# Summary Phase - Final Response Generation
|
|
2
|
+
|
|
3
|
+
You have completed both the primary work and closure review. Now generate a comprehensive summary of everything accomplished.
|
|
4
|
+
|
|
5
|
+
## Your Task
|
|
6
|
+
|
|
7
|
+
Create a clear, concise summary for Linear that covers:
|
|
8
|
+
|
|
9
|
+
### 1. Work Completed
|
|
10
|
+
- What features were implemented or bugs were fixed
|
|
11
|
+
- Key technical decisions made
|
|
12
|
+
- Any changes to the original scope or approach
|
|
13
|
+
|
|
14
|
+
### 2. Implementation Details
|
|
15
|
+
- High-level overview of the implementation approach
|
|
16
|
+
- Key files modified or created
|
|
17
|
+
- Any new dependencies, tools, or patterns introduced
|
|
18
|
+
|
|
19
|
+
### 3. Testing & Quality Assurance
|
|
20
|
+
- What testing was performed
|
|
21
|
+
- Test results and coverage
|
|
22
|
+
- Any known limitations or edge cases
|
|
23
|
+
|
|
24
|
+
### 4. Pull Request Information
|
|
25
|
+
- Link to the GitHub PR
|
|
26
|
+
- Status of the PR (ready for review, needs attention, etc.)
|
|
27
|
+
- Any special review notes or areas that need extra attention
|
|
28
|
+
|
|
29
|
+
### 5. Next Steps (if applicable)
|
|
30
|
+
- Any follow-up tasks or future improvements identified
|
|
31
|
+
- Configuration or deployment steps required
|
|
32
|
+
- Notes for reviewers
|
|
33
|
+
|
|
34
|
+
## Format Requirements
|
|
35
|
+
|
|
36
|
+
- Use clear, professional language suitable for Linear
|
|
37
|
+
- Be concise but comprehensive
|
|
38
|
+
- Use markdown formatting for readability
|
|
39
|
+
- Focus on what matters to stakeholders and reviewers
|
|
40
|
+
- **To mention someone**: Use `https://linear.app/linear/profiles/username` syntax where `username` is the Linear username (e.g., `https://linear.app/linear/profiles/alice` to mention @alice)
|
|
41
|
+
|
|
42
|
+
## Constraints
|
|
43
|
+
|
|
44
|
+
- **You have exactly 1 turn** - generate the summary in a single response
|
|
45
|
+
- This is the final output that will be posted to Linear
|
|
46
|
+
- Make it informative and actionable
|
|
@@ -0,0 +1,46 @@
|
|
|
1
|
+
# Verifications - Testing and Quality Checks
|
|
2
|
+
|
|
3
|
+
You have completed the primary work on this issue. Now perform thorough verification to ensure everything works correctly and meets quality standards.
|
|
4
|
+
|
|
5
|
+
## Your Tasks
|
|
6
|
+
|
|
7
|
+
### 1. Code Quality Review
|
|
8
|
+
- Review all code changes for quality, consistency, and best practices
|
|
9
|
+
- Ensure proper error handling and edge cases are covered
|
|
10
|
+
- Verify code follows project conventions and patterns
|
|
11
|
+
- Check for any code smells or areas that need refactoring
|
|
12
|
+
|
|
13
|
+
### 2. Testing & Verification
|
|
14
|
+
- Run all relevant tests and ensure they pass
|
|
15
|
+
- Fix any failing tests
|
|
16
|
+
- Add any missing test coverage for new functionality
|
|
17
|
+
- Verify the implementation meets all requirements from the issue description
|
|
18
|
+
- Check that existing functionality wasn't broken by the changes
|
|
19
|
+
|
|
20
|
+
### 3. Linting & Type Checking
|
|
21
|
+
- Run linting tools and fix any issues
|
|
22
|
+
- Run TypeScript type checking (if applicable) and fix any errors
|
|
23
|
+
- Ensure code meets all quality standards
|
|
24
|
+
- Fix any auto-fixable issues
|
|
25
|
+
|
|
26
|
+
### 4. Documentation Review
|
|
27
|
+
- Update relevant documentation (README, API docs, etc.)
|
|
28
|
+
- Remove any debug code, console.logs, or commented-out sections
|
|
29
|
+
- Ensure code comments are clear and up-to-date
|
|
30
|
+
- Update CHANGELOG.md if applicable
|
|
31
|
+
|
|
32
|
+
## Important Notes
|
|
33
|
+
|
|
34
|
+
- **Do NOT commit or push changes** - that happens in the next subroutine
|
|
35
|
+
- **Do NOT create or update PRs** - that also happens in the next subroutine
|
|
36
|
+
- **Focus on verification only** - this is the quality gate
|
|
37
|
+
- Be thorough but efficient
|
|
38
|
+
|
|
39
|
+
## Expected Output
|
|
40
|
+
|
|
41
|
+
Provide a brief summary of:
|
|
42
|
+
- What quality checks you performed
|
|
43
|
+
- Test results and coverage
|
|
44
|
+
- Any issues found and fixed
|
|
45
|
+
- Linting and type checking results
|
|
46
|
+
- Confirmation that all verifications passed
|
package/dist/types.d.ts
CHANGED
|
@@ -1,103 +1,6 @@
|
|
|
1
1
|
import type { Issue as LinearIssue } from "@linear/sdk";
|
|
2
2
|
import type { SDKMessage } from "cyrus-claude-runner";
|
|
3
3
|
import type { CyrusAgentSession, Workspace } from "cyrus-core";
|
|
4
|
-
import type { OAuthCallbackHandler } from "./SharedApplicationServer.js";
|
|
5
|
-
/**
|
|
6
|
-
* Configuration for a single repository/workspace pair
|
|
7
|
-
*/
|
|
8
|
-
export interface RepositoryConfig {
|
|
9
|
-
id: string;
|
|
10
|
-
name: string;
|
|
11
|
-
repositoryPath: string;
|
|
12
|
-
baseBranch: string;
|
|
13
|
-
linearWorkspaceId: string;
|
|
14
|
-
linearWorkspaceName?: string;
|
|
15
|
-
linearToken: string;
|
|
16
|
-
teamKeys?: string[];
|
|
17
|
-
routingLabels?: string[];
|
|
18
|
-
projectKeys?: string[];
|
|
19
|
-
workspaceBaseDir: string;
|
|
20
|
-
isActive?: boolean;
|
|
21
|
-
promptTemplatePath?: string;
|
|
22
|
-
allowedTools?: string[];
|
|
23
|
-
disallowedTools?: string[];
|
|
24
|
-
mcpConfigPath?: string | string[];
|
|
25
|
-
appendInstruction?: string;
|
|
26
|
-
model?: string;
|
|
27
|
-
fallbackModel?: string;
|
|
28
|
-
labelPrompts?: {
|
|
29
|
-
debugger?: {
|
|
30
|
-
labels: string[];
|
|
31
|
-
allowedTools?: string[] | "readOnly" | "safe" | "all" | "coordinator";
|
|
32
|
-
disallowedTools?: string[];
|
|
33
|
-
};
|
|
34
|
-
builder?: {
|
|
35
|
-
labels: string[];
|
|
36
|
-
allowedTools?: string[] | "readOnly" | "safe" | "all" | "coordinator";
|
|
37
|
-
disallowedTools?: string[];
|
|
38
|
-
};
|
|
39
|
-
scoper?: {
|
|
40
|
-
labels: string[];
|
|
41
|
-
allowedTools?: string[] | "readOnly" | "safe" | "all" | "coordinator";
|
|
42
|
-
disallowedTools?: string[];
|
|
43
|
-
};
|
|
44
|
-
orchestrator?: {
|
|
45
|
-
labels: string[];
|
|
46
|
-
allowedTools?: string[] | "readOnly" | "safe" | "all" | "coordinator";
|
|
47
|
-
disallowedTools?: string[];
|
|
48
|
-
};
|
|
49
|
-
};
|
|
50
|
-
}
|
|
51
|
-
/**
|
|
52
|
-
* Configuration for the EdgeWorker supporting multiple repositories
|
|
53
|
-
*/
|
|
54
|
-
export interface EdgeWorkerConfig {
|
|
55
|
-
proxyUrl: string;
|
|
56
|
-
baseUrl?: string;
|
|
57
|
-
webhookBaseUrl?: string;
|
|
58
|
-
webhookPort?: number;
|
|
59
|
-
serverPort?: number;
|
|
60
|
-
serverHost?: string;
|
|
61
|
-
ngrokAuthToken?: string;
|
|
62
|
-
defaultAllowedTools?: string[];
|
|
63
|
-
defaultDisallowedTools?: string[];
|
|
64
|
-
defaultModel?: string;
|
|
65
|
-
defaultFallbackModel?: string;
|
|
66
|
-
promptDefaults?: {
|
|
67
|
-
debugger?: {
|
|
68
|
-
allowedTools?: string[] | "readOnly" | "safe" | "all" | "coordinator";
|
|
69
|
-
disallowedTools?: string[];
|
|
70
|
-
};
|
|
71
|
-
builder?: {
|
|
72
|
-
allowedTools?: string[] | "readOnly" | "safe" | "all" | "coordinator";
|
|
73
|
-
disallowedTools?: string[];
|
|
74
|
-
};
|
|
75
|
-
scoper?: {
|
|
76
|
-
allowedTools?: string[] | "readOnly" | "safe" | "all" | "coordinator";
|
|
77
|
-
disallowedTools?: string[];
|
|
78
|
-
};
|
|
79
|
-
orchestrator?: {
|
|
80
|
-
allowedTools?: string[] | "readOnly" | "safe" | "all" | "coordinator";
|
|
81
|
-
disallowedTools?: string[];
|
|
82
|
-
};
|
|
83
|
-
};
|
|
84
|
-
repositories: RepositoryConfig[];
|
|
85
|
-
cyrusHome: string;
|
|
86
|
-
handlers?: {
|
|
87
|
-
createWorkspace?: (issue: LinearIssue, repository: RepositoryConfig) => Promise<Workspace>;
|
|
88
|
-
onClaudeMessage?: (issueId: string, message: SDKMessage, repositoryId: string) => void;
|
|
89
|
-
onSessionStart?: (issueId: string, issue: LinearIssue, repositoryId: string) => void;
|
|
90
|
-
onSessionEnd?: (issueId: string, exitCode: number | null, repositoryId: string) => void;
|
|
91
|
-
onError?: (error: Error, context?: any) => void;
|
|
92
|
-
onOAuthCallback?: OAuthCallbackHandler;
|
|
93
|
-
};
|
|
94
|
-
features?: {
|
|
95
|
-
enableContinuation?: boolean;
|
|
96
|
-
enableTokenLimitHandling?: boolean;
|
|
97
|
-
enableAttachmentDownload?: boolean;
|
|
98
|
-
promptTemplatePath?: string;
|
|
99
|
-
};
|
|
100
|
-
}
|
|
101
4
|
/**
|
|
102
5
|
* Events emitted by EdgeWorker
|
|
103
6
|
*/
|
package/dist/types.d.ts.map
CHANGED
|
@@ -1 +1 @@
|
|
|
1
|
-
{"version":3,"file":"types.d.ts","sourceRoot":"","sources":["../src/types.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,EAAE,KAAK,IAAI,WAAW,EAAE,MAAM,aAAa,CAAC;AACxD,OAAO,KAAK,EAAE,UAAU,EAAE,MAAM,qBAAqB,CAAC;AACtD,OAAO,KAAK,EAAE,iBAAiB,EAAE,SAAS,EAAE,MAAM,YAAY,CAAC;
|
|
1
|
+
{"version":3,"file":"types.d.ts","sourceRoot":"","sources":["../src/types.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,EAAE,KAAK,IAAI,WAAW,EAAE,MAAM,aAAa,CAAC;AACxD,OAAO,KAAK,EAAE,UAAU,EAAE,MAAM,qBAAqB,CAAC;AACtD,OAAO,KAAK,EAAE,iBAAiB,EAAE,SAAS,EAAE,MAAM,YAAY,CAAC;AAE/D;;GAEG;AACH,MAAM,WAAW,gBAAgB;IAEhC,SAAS,EAAE,CAAC,KAAK,EAAE,MAAM,KAAK,IAAI,CAAC;IACnC,YAAY,EAAE,CAAC,KAAK,EAAE,MAAM,EAAE,MAAM,CAAC,EAAE,MAAM,KAAK,IAAI,CAAC;IAGvD,iBAAiB,EAAE,CAClB,OAAO,EAAE,MAAM,EACf,KAAK,EAAE,WAAW,EAClB,YAAY,EAAE,MAAM,KAChB,IAAI,CAAC;IACV,eAAe,EAAE,CAChB,OAAO,EAAE,MAAM,EACf,QAAQ,EAAE,MAAM,GAAG,IAAI,EACvB,YAAY,EAAE,MAAM,KAChB,IAAI,CAAC;IAGV,gBAAgB,EAAE,CACjB,OAAO,EAAE,MAAM,EACf,OAAO,EAAE,UAAU,EACnB,YAAY,EAAE,MAAM,KAChB,IAAI,CAAC;IACV,iBAAiB,EAAE,CAClB,OAAO,EAAE,MAAM,EACf,IAAI,EAAE,MAAM,EACZ,YAAY,EAAE,MAAM,KAChB,IAAI,CAAC;IACV,iBAAiB,EAAE,CAClB,OAAO,EAAE,MAAM,EACf,IAAI,EAAE,MAAM,EACZ,KAAK,EAAE,GAAG,EACV,YAAY,EAAE,MAAM,KAChB,IAAI,CAAC;IAGV,KAAK,EAAE,CAAC,KAAK,EAAE,KAAK,EAAE,OAAO,CAAC,EAAE,GAAG,KAAK,IAAI,CAAC;CAC7C;AAED;;GAEG;AACH,MAAM,WAAW,sBAAsB;IACtC,OAAO,EAAE,iBAAiB,CAAC;IAC3B,SAAS,EAAE,WAAW,CAAC;IACvB,SAAS,EAAE,SAAS,CAAC;IACrB,gBAAgB,EAAE;QAAE,QAAQ,EAAE,MAAM,CAAC;QAAC,cAAc,EAAE,MAAM,GAAG,IAAI,CAAA;KAAE,CAAC;IACtE,cAAc,EAAE,MAAM,CAAC;IACvB,kBAAkB,EAAE,MAAM,EAAE,CAAC;IAC7B,YAAY,EAAE,MAAM,EAAE,CAAC;IACvB,eAAe,EAAE,MAAM,EAAE,CAAC;CAC1B"}
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "cyrus-edge-worker",
|
|
3
|
-
"version": "0.0.
|
|
3
|
+
"version": "0.0.38",
|
|
4
4
|
"description": "Unified edge worker for processing Linear issues with Claude",
|
|
5
5
|
"type": "module",
|
|
6
6
|
"main": "dist/index.js",
|
|
@@ -17,10 +17,11 @@
|
|
|
17
17
|
"@ngrok/ngrok": "^1.5.1",
|
|
18
18
|
"chokidar": "^4.0.3",
|
|
19
19
|
"file-type": "^18.7.0",
|
|
20
|
-
"cyrus-claude-runner": "0.0.
|
|
21
|
-
"cyrus-
|
|
22
|
-
"cyrus-
|
|
23
|
-
"cyrus-
|
|
20
|
+
"cyrus-claude-runner": "0.0.31",
|
|
21
|
+
"cyrus-core": "0.0.19",
|
|
22
|
+
"cyrus-linear-webhook-client": "0.0.3",
|
|
23
|
+
"cyrus-simple-agent-runner": "0.0.1",
|
|
24
|
+
"cyrus-ndjson-client": "0.0.24"
|
|
24
25
|
},
|
|
25
26
|
"devDependencies": {
|
|
26
27
|
"@types/node": "^20.0.0",
|
|
@@ -34,7 +35,8 @@
|
|
|
34
35
|
"access": "public"
|
|
35
36
|
},
|
|
36
37
|
"scripts": {
|
|
37
|
-
"build": "tsc",
|
|
38
|
+
"build": "tsc && npm run copy-prompts",
|
|
39
|
+
"copy-prompts": "mkdir -p dist/prompts/subroutines && cp -r src/prompts/subroutines/*.md dist/prompts/subroutines/",
|
|
38
40
|
"dev": "tsc --watch",
|
|
39
41
|
"test": "vitest",
|
|
40
42
|
"test:run": "vitest run",
|