edsger 0.43.0 → 0.44.0
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/.claude/settings.local.json +23 -3
- package/.env.local +12 -0
- package/dist/api/release-test-cases.d.ts +7 -0
- package/dist/api/release-test-cases.js +21 -0
- package/dist/api/releases.d.ts +41 -0
- package/dist/api/releases.js +31 -0
- package/dist/commands/release-sync/index.d.ts +5 -0
- package/dist/commands/release-sync/index.js +38 -0
- package/dist/commands/smoke-test/index.d.ts +5 -0
- package/dist/commands/smoke-test/index.js +40 -0
- package/dist/index.js +40 -0
- package/dist/phases/release-sync/__tests__/github.test.d.ts +9 -0
- package/dist/phases/release-sync/__tests__/github.test.js +123 -0
- package/dist/phases/release-sync/__tests__/snapshot.test.d.ts +8 -0
- package/dist/phases/release-sync/__tests__/snapshot.test.js +93 -0
- package/dist/phases/release-sync/github.d.ts +54 -0
- package/dist/phases/release-sync/github.js +101 -0
- package/dist/phases/release-sync/index.d.ts +24 -0
- package/dist/phases/release-sync/index.js +147 -0
- package/dist/phases/release-sync/snapshot.d.ts +27 -0
- package/dist/phases/release-sync/snapshot.js +159 -0
- package/dist/phases/smoke-test/__tests__/agent.test.d.ts +4 -0
- package/dist/phases/smoke-test/__tests__/agent.test.js +85 -0
- package/dist/phases/smoke-test/agent.d.ts +12 -0
- package/dist/phases/smoke-test/agent.js +94 -0
- package/dist/phases/smoke-test/index.d.ts +22 -0
- package/dist/phases/smoke-test/index.js +233 -0
- package/dist/phases/smoke-test/prompts.d.ts +15 -0
- package/dist/phases/smoke-test/prompts.js +35 -0
- package/dist/skills/phase/smoke-test/SKILL.md +80 -0
- package/dist/utils/json-extract.d.ts +6 -0
- package/dist/utils/json-extract.js +44 -0
- package/dist/workspace/__tests__/workspace-manager.test.d.ts +7 -0
- package/dist/workspace/__tests__/workspace-manager.test.js +52 -0
- package/dist/workspace/workspace-manager.d.ts +31 -0
- package/dist/workspace/workspace-manager.js +96 -10
- package/package.json +1 -1
- package/dist/services/lifecycle-agent/__tests__/phase-criteria.test.d.ts +0 -4
- package/dist/services/lifecycle-agent/__tests__/phase-criteria.test.js +0 -133
- package/dist/services/lifecycle-agent/__tests__/transition-rules.test.d.ts +0 -4
- package/dist/services/lifecycle-agent/__tests__/transition-rules.test.js +0 -336
- package/dist/services/lifecycle-agent/index.d.ts +0 -24
- package/dist/services/lifecycle-agent/index.js +0 -25
- package/dist/services/lifecycle-agent/phase-criteria.d.ts +0 -57
- package/dist/services/lifecycle-agent/phase-criteria.js +0 -335
- package/dist/services/lifecycle-agent/transition-rules.d.ts +0 -60
- package/dist/services/lifecycle-agent/transition-rules.js +0 -184
- package/dist/services/lifecycle-agent/types.d.ts +0 -190
- package/dist/services/lifecycle-agent/types.js +0 -12
|
@@ -1,335 +0,0 @@
|
|
|
1
|
-
/**
|
|
2
|
-
* Phase Quality Criteria Definitions
|
|
3
|
-
*
|
|
4
|
-
* Defines the quality criteria the lifecycle agent uses to evaluate
|
|
5
|
-
* each phase's outputs. These criteria determine whether a phase
|
|
6
|
-
* should advance, be re-run, or be escalated to a human.
|
|
7
|
-
*
|
|
8
|
-
* Each phase has:
|
|
9
|
-
* - An advance threshold: minimum score to auto-advance
|
|
10
|
-
* - An escalate threshold: score below which to escalate to human
|
|
11
|
-
* - A set of weighted criteria for evaluation
|
|
12
|
-
* - A max retry count before escalation
|
|
13
|
-
*/
|
|
14
|
-
/**
|
|
15
|
-
* User Stories Analysis quality criteria
|
|
16
|
-
* Evaluates whether generated user stories adequately capture the feature requirements
|
|
17
|
-
*/
|
|
18
|
-
export const USER_STORIES_ANALYSIS_CRITERIA = {
|
|
19
|
-
phase: 'user_stories_analysis',
|
|
20
|
-
advanceThreshold: 75,
|
|
21
|
-
escalateThreshold: 40,
|
|
22
|
-
maxAutoRetries: 2,
|
|
23
|
-
criteria: [
|
|
24
|
-
{
|
|
25
|
-
id: 'us_completeness',
|
|
26
|
-
name: 'Feature Coverage',
|
|
27
|
-
description: 'All significant aspects of the feature are captured in user stories',
|
|
28
|
-
weight: 0.3,
|
|
29
|
-
minimumScore: 60,
|
|
30
|
-
evaluationGuidance: 'Check that the user stories collectively cover all major aspects of the feature description. Look for gaps where important functionality is not represented by any user story. Consider edge cases and error scenarios.',
|
|
31
|
-
},
|
|
32
|
-
{
|
|
33
|
-
id: 'us_clarity',
|
|
34
|
-
name: 'Story Clarity',
|
|
35
|
-
description: 'User stories follow standard format and are clear, specific, and actionable',
|
|
36
|
-
weight: 0.25,
|
|
37
|
-
minimumScore: 60,
|
|
38
|
-
evaluationGuidance: 'Verify each user story follows the "As a [role], I want [goal], so that [benefit]" format or equivalent clear structure. Stories should be specific enough to implement without ambiguity. Check for vague terms like "improve", "enhance", or "better" without quantifiable criteria.',
|
|
39
|
-
},
|
|
40
|
-
{
|
|
41
|
-
id: 'us_testability',
|
|
42
|
-
name: 'Testability',
|
|
43
|
-
description: 'Each user story has implicit or explicit acceptance criteria',
|
|
44
|
-
weight: 0.2,
|
|
45
|
-
minimumScore: 50,
|
|
46
|
-
evaluationGuidance: 'Assess whether each user story can be tested. The story should describe behavior that is observable and verifiable. Stories like "the system should be fast" without measurable criteria score low.',
|
|
47
|
-
},
|
|
48
|
-
{
|
|
49
|
-
id: 'us_independence',
|
|
50
|
-
name: 'Story Independence',
|
|
51
|
-
description: 'User stories are reasonably independent and avoid unnecessary coupling',
|
|
52
|
-
weight: 0.15,
|
|
53
|
-
minimumScore: 40,
|
|
54
|
-
evaluationGuidance: 'Check that stories can be developed and delivered somewhat independently. High coupling between stories (where one cannot be started without completing another) reduces flexibility. Some dependencies are natural, but excessive chaining scores low.',
|
|
55
|
-
},
|
|
56
|
-
{
|
|
57
|
-
id: 'us_sizing',
|
|
58
|
-
name: 'Appropriate Sizing',
|
|
59
|
-
description: 'Stories are neither too large (epics) nor too small (tasks)',
|
|
60
|
-
weight: 0.1,
|
|
61
|
-
minimumScore: 40,
|
|
62
|
-
evaluationGuidance: 'Stories should represent a meaningful unit of user-visible functionality. Stories that are too large (spanning multiple features) or too small (implementation details disguised as stories) score low.',
|
|
63
|
-
},
|
|
64
|
-
],
|
|
65
|
-
};
|
|
66
|
-
/**
|
|
67
|
-
* Test Cases Analysis quality criteria
|
|
68
|
-
* Evaluates whether generated test cases provide adequate coverage
|
|
69
|
-
*/
|
|
70
|
-
export const TEST_CASES_ANALYSIS_CRITERIA = {
|
|
71
|
-
phase: 'test_cases_analysis',
|
|
72
|
-
advanceThreshold: 75,
|
|
73
|
-
escalateThreshold: 40,
|
|
74
|
-
maxAutoRetries: 2,
|
|
75
|
-
criteria: [
|
|
76
|
-
{
|
|
77
|
-
id: 'tc_coverage',
|
|
78
|
-
name: 'Story Coverage',
|
|
79
|
-
description: 'Test cases cover the critical paths for all user stories',
|
|
80
|
-
weight: 0.3,
|
|
81
|
-
minimumScore: 60,
|
|
82
|
-
evaluationGuidance: 'Verify that each user story has at least one corresponding test case for its happy path. Critical stories should have multiple test cases covering edge cases. Calculate the ratio of stories with tests to total stories.',
|
|
83
|
-
},
|
|
84
|
-
{
|
|
85
|
-
id: 'tc_critical_paths',
|
|
86
|
-
name: 'Critical Path Coverage',
|
|
87
|
-
description: 'Critical and high-risk scenarios are tested',
|
|
88
|
-
weight: 0.25,
|
|
89
|
-
minimumScore: 60,
|
|
90
|
-
evaluationGuidance: 'Check that error handling, boundary conditions, and security-sensitive paths have test cases. Look for tests that cover authentication, authorization, data validation, and failure recovery scenarios where applicable.',
|
|
91
|
-
},
|
|
92
|
-
{
|
|
93
|
-
id: 'tc_specificity',
|
|
94
|
-
name: 'Test Specificity',
|
|
95
|
-
description: 'Test cases have clear steps, inputs, and expected outcomes',
|
|
96
|
-
weight: 0.25,
|
|
97
|
-
minimumScore: 50,
|
|
98
|
-
evaluationGuidance: 'Each test case should specify: preconditions, steps to execute, test data/inputs, and expected outcomes. Vague test cases like "verify the feature works" without specific steps score low.',
|
|
99
|
-
},
|
|
100
|
-
{
|
|
101
|
-
id: 'tc_priority',
|
|
102
|
-
name: 'Priority Assignment',
|
|
103
|
-
description: 'Critical tests are properly identified and prioritized',
|
|
104
|
-
weight: 0.2,
|
|
105
|
-
minimumScore: 40,
|
|
106
|
-
evaluationGuidance: 'Verify that is_critical flags are assigned appropriately. Core functionality and data integrity tests should be marked critical. Cosmetic or nice-to-have tests should not be critical.',
|
|
107
|
-
},
|
|
108
|
-
],
|
|
109
|
-
};
|
|
110
|
-
/**
|
|
111
|
-
* Technical Design quality criteria
|
|
112
|
-
* Evaluates the technical design document quality
|
|
113
|
-
*/
|
|
114
|
-
export const TECHNICAL_DESIGN_CRITERIA = {
|
|
115
|
-
phase: 'technical_design',
|
|
116
|
-
advanceThreshold: 70,
|
|
117
|
-
escalateThreshold: 35,
|
|
118
|
-
maxAutoRetries: 2,
|
|
119
|
-
criteria: [
|
|
120
|
-
{
|
|
121
|
-
id: 'td_feasibility',
|
|
122
|
-
name: 'Implementation Feasibility',
|
|
123
|
-
description: 'Design is technically feasible and can be implemented with the available technology stack',
|
|
124
|
-
weight: 0.3,
|
|
125
|
-
minimumScore: 60,
|
|
126
|
-
evaluationGuidance: 'Check that the design uses technologies and patterns consistent with the existing codebase. The design should not require major infrastructure changes or introduce incompatible dependencies. Implementation steps should be realistic.',
|
|
127
|
-
},
|
|
128
|
-
{
|
|
129
|
-
id: 'td_completeness',
|
|
130
|
-
name: 'Design Completeness',
|
|
131
|
-
description: 'Design addresses all user stories and specifies key implementation details',
|
|
132
|
-
weight: 0.25,
|
|
133
|
-
minimumScore: 60,
|
|
134
|
-
evaluationGuidance: 'Verify the design covers database schema changes, API endpoints, UI components, and business logic for all user stories. Check for missing details that would block implementation: undefined data models, unclear API contracts, or missing error handling strategies.',
|
|
135
|
-
},
|
|
136
|
-
{
|
|
137
|
-
id: 'td_architecture',
|
|
138
|
-
name: 'Architectural Quality',
|
|
139
|
-
description: 'Design follows good architectural practices and is consistent with the existing system',
|
|
140
|
-
weight: 0.25,
|
|
141
|
-
minimumScore: 50,
|
|
142
|
-
evaluationGuidance: 'Assess separation of concerns, appropriate abstraction levels, and consistency with existing architectural patterns. Check for anti-patterns like tight coupling, god objects, or bypassing established data flows.',
|
|
143
|
-
},
|
|
144
|
-
{
|
|
145
|
-
id: 'td_risks',
|
|
146
|
-
name: 'Risk Identification',
|
|
147
|
-
description: 'Key risks, assumptions, and trade-offs are identified',
|
|
148
|
-
weight: 0.2,
|
|
149
|
-
minimumScore: 40,
|
|
150
|
-
evaluationGuidance: 'Check that the design acknowledges technical risks, performance implications, and security considerations. A design that claims no risks or trade-offs is likely incomplete.',
|
|
151
|
-
},
|
|
152
|
-
],
|
|
153
|
-
};
|
|
154
|
-
/**
|
|
155
|
-
* Branch Planning quality criteria
|
|
156
|
-
* Evaluates whether the feature is well-split into branches
|
|
157
|
-
*/
|
|
158
|
-
export const BRANCH_PLANNING_CRITERIA = {
|
|
159
|
-
phase: 'branch_planning',
|
|
160
|
-
advanceThreshold: 70,
|
|
161
|
-
escalateThreshold: 35,
|
|
162
|
-
maxAutoRetries: 1,
|
|
163
|
-
criteria: [
|
|
164
|
-
{
|
|
165
|
-
id: 'bp_coverage',
|
|
166
|
-
name: 'Feature Coverage',
|
|
167
|
-
description: 'All user stories are assigned to branches',
|
|
168
|
-
weight: 0.35,
|
|
169
|
-
minimumScore: 60,
|
|
170
|
-
evaluationGuidance: 'Verify every user story is covered by at least one planned branch. No functionality should be left unassigned.',
|
|
171
|
-
},
|
|
172
|
-
{
|
|
173
|
-
id: 'bp_ordering',
|
|
174
|
-
name: 'Dependency Ordering',
|
|
175
|
-
description: 'Branches are ordered logically with proper dependency tracking',
|
|
176
|
-
weight: 0.35,
|
|
177
|
-
minimumScore: 50,
|
|
178
|
-
evaluationGuidance: 'Check that branches with dependencies on other branches correctly specify base_branch_id relationships. Foundation work (data models, APIs) should come before UI or integration branches.',
|
|
179
|
-
},
|
|
180
|
-
{
|
|
181
|
-
id: 'bp_sizing',
|
|
182
|
-
name: 'Branch Sizing',
|
|
183
|
-
description: 'Branches represent reviewable, incremental units of work',
|
|
184
|
-
weight: 0.3,
|
|
185
|
-
minimumScore: 50,
|
|
186
|
-
evaluationGuidance: 'Branches should be small enough for meaningful code review (not too many files changed) but large enough to represent a coherent unit of functionality. A single branch containing the entire feature scores low.',
|
|
187
|
-
},
|
|
188
|
-
],
|
|
189
|
-
};
|
|
190
|
-
/**
|
|
191
|
-
* Code Implementation quality criteria
|
|
192
|
-
* Evaluates the code output after implementation
|
|
193
|
-
*/
|
|
194
|
-
export const CODE_IMPLEMENTATION_CRITERIA = {
|
|
195
|
-
phase: 'code_implementation',
|
|
196
|
-
advanceThreshold: 70,
|
|
197
|
-
escalateThreshold: 30,
|
|
198
|
-
maxAutoRetries: 2,
|
|
199
|
-
criteria: [
|
|
200
|
-
{
|
|
201
|
-
id: 'ci_functionality',
|
|
202
|
-
name: 'Core Functionality',
|
|
203
|
-
description: 'Code implements the specified user stories and design',
|
|
204
|
-
weight: 0.35,
|
|
205
|
-
minimumScore: 60,
|
|
206
|
-
evaluationGuidance: 'Verify the code addresses the user stories and follows the technical design. Check that key API endpoints, database operations, and UI components are implemented.',
|
|
207
|
-
},
|
|
208
|
-
{
|
|
209
|
-
id: 'ci_compilability',
|
|
210
|
-
name: 'Build Success',
|
|
211
|
-
description: 'Code compiles/builds without errors',
|
|
212
|
-
weight: 0.3,
|
|
213
|
-
minimumScore: 70,
|
|
214
|
-
evaluationGuidance: 'Check for compilation errors, type errors, or missing imports. Code that does not build gets a very low score. Warnings are acceptable but should be minimal.',
|
|
215
|
-
},
|
|
216
|
-
{
|
|
217
|
-
id: 'ci_patterns',
|
|
218
|
-
name: 'Code Quality',
|
|
219
|
-
description: 'Code follows established patterns and conventions in the codebase',
|
|
220
|
-
weight: 0.2,
|
|
221
|
-
minimumScore: 50,
|
|
222
|
-
evaluationGuidance: 'Check that the code follows the project\'s existing patterns: naming conventions, file organization, error handling patterns, and architectural layers. New patterns introduced without justification score low.',
|
|
223
|
-
},
|
|
224
|
-
{
|
|
225
|
-
id: 'ci_pr_quality',
|
|
226
|
-
name: 'PR Quality',
|
|
227
|
-
description: 'Pull request is well-formed with clear description',
|
|
228
|
-
weight: 0.15,
|
|
229
|
-
minimumScore: 40,
|
|
230
|
-
evaluationGuidance: 'Verify the PR has a clear title, description referencing the feature, and reasonable diff size. PRs with thousands of changed lines or no description score low.',
|
|
231
|
-
},
|
|
232
|
-
],
|
|
233
|
-
};
|
|
234
|
-
/**
|
|
235
|
-
* Functional Testing quality criteria
|
|
236
|
-
* Evaluates test execution results
|
|
237
|
-
*/
|
|
238
|
-
export const FUNCTIONAL_TESTING_CRITERIA = {
|
|
239
|
-
phase: 'functional_testing',
|
|
240
|
-
advanceThreshold: 80,
|
|
241
|
-
escalateThreshold: 40,
|
|
242
|
-
maxAutoRetries: 3,
|
|
243
|
-
criteria: [
|
|
244
|
-
{
|
|
245
|
-
id: 'ft_pass_rate',
|
|
246
|
-
name: 'Test Pass Rate',
|
|
247
|
-
description: 'Percentage of tests that pass',
|
|
248
|
-
weight: 0.5,
|
|
249
|
-
minimumScore: 70,
|
|
250
|
-
evaluationGuidance: 'Calculate the pass rate: (passing tests / total tests) * 100. All critical tests must pass for a high score. Non-critical test failures reduce the score proportionally.',
|
|
251
|
-
},
|
|
252
|
-
{
|
|
253
|
-
id: 'ft_critical_pass',
|
|
254
|
-
name: 'Critical Test Pass Rate',
|
|
255
|
-
description: 'All tests marked as critical must pass',
|
|
256
|
-
weight: 0.35,
|
|
257
|
-
minimumScore: 80,
|
|
258
|
-
evaluationGuidance: 'Check specifically that all tests marked is_critical=true pass. Any critical test failure is a significant quality concern. Score 0 if any critical test fails, 100 if all pass.',
|
|
259
|
-
},
|
|
260
|
-
{
|
|
261
|
-
id: 'ft_coverage',
|
|
262
|
-
name: 'Test Execution Coverage',
|
|
263
|
-
description: 'Tests actually execute meaningful scenarios',
|
|
264
|
-
weight: 0.15,
|
|
265
|
-
minimumScore: 50,
|
|
266
|
-
evaluationGuidance: 'Verify tests are not trivially passing (e.g., empty test bodies, always-true assertions). Tests should exercise real functionality and verify meaningful outcomes.',
|
|
267
|
-
},
|
|
268
|
-
],
|
|
269
|
-
};
|
|
270
|
-
/**
|
|
271
|
-
* Code Review quality criteria
|
|
272
|
-
* Evaluates the AI code review output
|
|
273
|
-
*/
|
|
274
|
-
export const CODE_REVIEW_CRITERIA = {
|
|
275
|
-
phase: 'code_review',
|
|
276
|
-
advanceThreshold: 75,
|
|
277
|
-
escalateThreshold: 35,
|
|
278
|
-
maxAutoRetries: 1,
|
|
279
|
-
criteria: [
|
|
280
|
-
{
|
|
281
|
-
id: 'cr_thoroughness',
|
|
282
|
-
name: 'Review Thoroughness',
|
|
283
|
-
description: 'Review covers all significant changes in the PR',
|
|
284
|
-
weight: 0.35,
|
|
285
|
-
minimumScore: 50,
|
|
286
|
-
evaluationGuidance: 'Check that the review addresses the main files and logic changes in the PR. Reviews that only comment on superficial issues (formatting, naming) while missing logic errors score low.',
|
|
287
|
-
},
|
|
288
|
-
{
|
|
289
|
-
id: 'cr_actionability',
|
|
290
|
-
name: 'Actionable Feedback',
|
|
291
|
-
description: 'Review comments are specific and actionable',
|
|
292
|
-
weight: 0.35,
|
|
293
|
-
minimumScore: 50,
|
|
294
|
-
evaluationGuidance: 'Verify review comments suggest specific improvements rather than vague observations. Comments like "this could be better" without explanation score low. Comments with code suggestions or specific alternatives score high.',
|
|
295
|
-
},
|
|
296
|
-
{
|
|
297
|
-
id: 'cr_severity',
|
|
298
|
-
name: 'Issue Severity Accuracy',
|
|
299
|
-
description: 'Issues are appropriately categorized by severity',
|
|
300
|
-
weight: 0.3,
|
|
301
|
-
minimumScore: 40,
|
|
302
|
-
evaluationGuidance: 'Check that blocking issues (bugs, security) are flagged appropriately and not buried among style nits. Conversely, check that cosmetic issues are not marked as blocking.',
|
|
303
|
-
},
|
|
304
|
-
],
|
|
305
|
-
};
|
|
306
|
-
/**
|
|
307
|
-
* All default phase criteria indexed by phase name
|
|
308
|
-
*/
|
|
309
|
-
export const DEFAULT_PHASE_CRITERIA = {
|
|
310
|
-
user_stories_analysis: USER_STORIES_ANALYSIS_CRITERIA,
|
|
311
|
-
test_cases_analysis: TEST_CASES_ANALYSIS_CRITERIA,
|
|
312
|
-
technical_design: TECHNICAL_DESIGN_CRITERIA,
|
|
313
|
-
branch_planning: BRANCH_PLANNING_CRITERIA,
|
|
314
|
-
code_implementation: CODE_IMPLEMENTATION_CRITERIA,
|
|
315
|
-
functional_testing: FUNCTIONAL_TESTING_CRITERIA,
|
|
316
|
-
code_review: CODE_REVIEW_CRITERIA,
|
|
317
|
-
};
|
|
318
|
-
/**
|
|
319
|
-
* Get quality criteria for a phase, with optional overrides from config
|
|
320
|
-
*/
|
|
321
|
-
export function getPhaseQualityCriteria(phase, overrides) {
|
|
322
|
-
const defaults = DEFAULT_PHASE_CRITERIA[phase];
|
|
323
|
-
if (!defaults) {
|
|
324
|
-
return null;
|
|
325
|
-
}
|
|
326
|
-
const phaseOverrides = overrides?.[phase];
|
|
327
|
-
if (!phaseOverrides) {
|
|
328
|
-
return defaults;
|
|
329
|
-
}
|
|
330
|
-
return {
|
|
331
|
-
...defaults,
|
|
332
|
-
...phaseOverrides,
|
|
333
|
-
criteria: phaseOverrides.criteria ?? defaults.criteria,
|
|
334
|
-
};
|
|
335
|
-
}
|
|
@@ -1,60 +0,0 @@
|
|
|
1
|
-
/**
|
|
2
|
-
* Transition Rules Engine
|
|
3
|
-
*
|
|
4
|
-
* Defines the rules for transitioning between phases and provides
|
|
5
|
-
* the core decision-making logic for the lifecycle agent.
|
|
6
|
-
*
|
|
7
|
-
* The engine uses phase evaluation results combined with configurable
|
|
8
|
-
* thresholds to determine the appropriate action:
|
|
9
|
-
* - advance: Move to the next phase
|
|
10
|
-
* - rerun: Re-execute the current phase with feedback
|
|
11
|
-
* - escalate: Request human intervention
|
|
12
|
-
*/
|
|
13
|
-
import type { FeatureStatus } from '../../types/index.js';
|
|
14
|
-
import type { ExecutionMode } from '../../types/pipeline.js';
|
|
15
|
-
import type { TransitionRule, PhaseEvaluationResult, LifecycleAgentConfig, LifecycleDecision, LifecycleDecisionResult, CriterionEvaluation, PhaseQualityCriteria } from './types.js';
|
|
16
|
-
/**
|
|
17
|
-
* Default transition rules mapping each phase to its successor
|
|
18
|
-
* These mirror the existing getNextExecutionMode() logic but are structured
|
|
19
|
-
* as data rather than code, making them configurable and testable
|
|
20
|
-
*/
|
|
21
|
-
export declare const DEFAULT_TRANSITION_RULES: readonly TransitionRule[];
|
|
22
|
-
/**
|
|
23
|
-
* Get the transition rule for advancing from a given phase
|
|
24
|
-
*/
|
|
25
|
-
export declare function getTransitionRule(fromPhase: string): TransitionRule | undefined;
|
|
26
|
-
/**
|
|
27
|
-
* Get the execution mode for re-running a phase
|
|
28
|
-
* Maps phase names to their "only_*" execution mode
|
|
29
|
-
*/
|
|
30
|
-
export declare function getRerunExecutionMode(phase: string): ExecutionMode;
|
|
31
|
-
/**
|
|
32
|
-
* Get the verification status for a phase
|
|
33
|
-
* This is the status set after a phase completes while awaiting review
|
|
34
|
-
*/
|
|
35
|
-
export declare function getVerificationStatus(phase: string): FeatureStatus | undefined;
|
|
36
|
-
/**
|
|
37
|
-
* Calculate the weighted quality score from individual criterion evaluations
|
|
38
|
-
*/
|
|
39
|
-
export declare function calculateQualityScore(evaluations: readonly CriterionEvaluation[], criteria: PhaseQualityCriteria): number;
|
|
40
|
-
/**
|
|
41
|
-
* Determine the lifecycle decision based on evaluation results
|
|
42
|
-
*
|
|
43
|
-
* Decision logic:
|
|
44
|
-
* 1. If quality score >= advanceThreshold AND confidence >= confidenceThreshold → advance
|
|
45
|
-
* 2. If quality score < escalateThreshold → escalate (quality too low for auto-fix)
|
|
46
|
-
* 3. If rerun count >= maxAutoRetries → escalate (exhausted retries)
|
|
47
|
-
* 4. If confidence < confidenceThreshold → escalate (agent uncertain)
|
|
48
|
-
* 5. Otherwise → rerun (quality between escalate and advance thresholds)
|
|
49
|
-
*/
|
|
50
|
-
export declare function determineDecision(qualityScore: number, confidence: number, rerunCount: number, phaseCriteria: PhaseQualityCriteria, config: LifecycleAgentConfig): LifecycleDecision;
|
|
51
|
-
/**
|
|
52
|
-
* Build the complete decision result from an evaluation
|
|
53
|
-
* Combines the evaluation with transition rules to produce an actionable result
|
|
54
|
-
*/
|
|
55
|
-
export declare function buildDecisionResult(evaluation: PhaseEvaluationResult): LifecycleDecisionResult;
|
|
56
|
-
/**
|
|
57
|
-
* Default lifecycle agent configuration
|
|
58
|
-
* Conservative defaults that prioritize safety over automation speed
|
|
59
|
-
*/
|
|
60
|
-
export declare const DEFAULT_LIFECYCLE_AGENT_CONFIG: LifecycleAgentConfig;
|
|
@@ -1,184 +0,0 @@
|
|
|
1
|
-
/**
|
|
2
|
-
* Transition Rules Engine
|
|
3
|
-
*
|
|
4
|
-
* Defines the rules for transitioning between phases and provides
|
|
5
|
-
* the core decision-making logic for the lifecycle agent.
|
|
6
|
-
*
|
|
7
|
-
* The engine uses phase evaluation results combined with configurable
|
|
8
|
-
* thresholds to determine the appropriate action:
|
|
9
|
-
* - advance: Move to the next phase
|
|
10
|
-
* - rerun: Re-execute the current phase with feedback
|
|
11
|
-
* - escalate: Request human intervention
|
|
12
|
-
*/
|
|
13
|
-
/**
|
|
14
|
-
* Default transition rules mapping each phase to its successor
|
|
15
|
-
* These mirror the existing getNextExecutionMode() logic but are structured
|
|
16
|
-
* as data rather than code, making them configurable and testable
|
|
17
|
-
*/
|
|
18
|
-
export const DEFAULT_TRANSITION_RULES = [
|
|
19
|
-
{
|
|
20
|
-
fromPhase: 'user_stories_analysis',
|
|
21
|
-
toPhase: 'test_cases_analysis',
|
|
22
|
-
executionMode: 'only_test_cases_analysis',
|
|
23
|
-
targetStatus: 'test_cases_analysis',
|
|
24
|
-
},
|
|
25
|
-
{
|
|
26
|
-
fromPhase: 'test_cases_analysis',
|
|
27
|
-
toPhase: 'technical_design',
|
|
28
|
-
executionMode: 'only_technical_design',
|
|
29
|
-
targetStatus: 'technical_design',
|
|
30
|
-
},
|
|
31
|
-
{
|
|
32
|
-
fromPhase: 'technical_design',
|
|
33
|
-
toPhase: 'branch_planning',
|
|
34
|
-
executionMode: 'only_branch_planning',
|
|
35
|
-
targetStatus: 'branch_planning',
|
|
36
|
-
},
|
|
37
|
-
{
|
|
38
|
-
fromPhase: 'branch_planning',
|
|
39
|
-
toPhase: 'code_implementation',
|
|
40
|
-
executionMode: 'from_code_implementation',
|
|
41
|
-
targetStatus: 'code_implementation',
|
|
42
|
-
},
|
|
43
|
-
{
|
|
44
|
-
fromPhase: 'code_implementation',
|
|
45
|
-
toPhase: 'functional_testing',
|
|
46
|
-
executionMode: 'from_functional_testing',
|
|
47
|
-
targetStatus: 'functional_testing',
|
|
48
|
-
},
|
|
49
|
-
{
|
|
50
|
-
fromPhase: 'functional_testing',
|
|
51
|
-
toPhase: 'code_review',
|
|
52
|
-
executionMode: 'from_code_review',
|
|
53
|
-
targetStatus: 'code_review',
|
|
54
|
-
},
|
|
55
|
-
{
|
|
56
|
-
fromPhase: 'code_review',
|
|
57
|
-
toPhase: 'code_refine',
|
|
58
|
-
executionMode: 'only_code_refine',
|
|
59
|
-
targetStatus: 'code_refine',
|
|
60
|
-
},
|
|
61
|
-
];
|
|
62
|
-
/**
|
|
63
|
-
* Get the transition rule for advancing from a given phase
|
|
64
|
-
*/
|
|
65
|
-
export function getTransitionRule(fromPhase) {
|
|
66
|
-
return DEFAULT_TRANSITION_RULES.find((rule) => rule.fromPhase === fromPhase);
|
|
67
|
-
}
|
|
68
|
-
/**
|
|
69
|
-
* Get the execution mode for re-running a phase
|
|
70
|
-
* Maps phase names to their "only_*" execution mode
|
|
71
|
-
*/
|
|
72
|
-
export function getRerunExecutionMode(phase) {
|
|
73
|
-
const rerunModes = {
|
|
74
|
-
user_stories_analysis: 'only_user_stories_analysis',
|
|
75
|
-
test_cases_analysis: 'only_test_cases_analysis',
|
|
76
|
-
technical_design: 'only_technical_design',
|
|
77
|
-
branch_planning: 'only_branch_planning',
|
|
78
|
-
code_implementation: 'only_code_implementation',
|
|
79
|
-
functional_testing: 'only_functional_testing',
|
|
80
|
-
code_review: 'only_code_review',
|
|
81
|
-
code_refine: 'only_code_refine',
|
|
82
|
-
};
|
|
83
|
-
return rerunModes[phase] || 'full_pipeline';
|
|
84
|
-
}
|
|
85
|
-
/**
|
|
86
|
-
* Get the verification status for a phase
|
|
87
|
-
* This is the status set after a phase completes while awaiting review
|
|
88
|
-
*/
|
|
89
|
-
export function getVerificationStatus(phase) {
|
|
90
|
-
const verificationStatuses = {
|
|
91
|
-
user_stories_analysis: 'user_stories_analysis_verification',
|
|
92
|
-
test_cases_analysis: 'test_cases_analysis_verification',
|
|
93
|
-
technical_design: 'technical_design_verification',
|
|
94
|
-
branch_planning: 'branch_planning_verification',
|
|
95
|
-
code_implementation: 'code_implementation_verification',
|
|
96
|
-
code_refine: 'code_refine_verification',
|
|
97
|
-
};
|
|
98
|
-
return verificationStatuses[phase];
|
|
99
|
-
}
|
|
100
|
-
/**
|
|
101
|
-
* Calculate the weighted quality score from individual criterion evaluations
|
|
102
|
-
*/
|
|
103
|
-
export function calculateQualityScore(evaluations, criteria) {
|
|
104
|
-
if (evaluations.length === 0)
|
|
105
|
-
return 0;
|
|
106
|
-
const criteriaMap = new Map(criteria.criteria.map((c) => [c.id, c]));
|
|
107
|
-
let weightedSum = 0;
|
|
108
|
-
let totalWeight = 0;
|
|
109
|
-
for (const evaluation of evaluations) {
|
|
110
|
-
const definition = criteriaMap.get(evaluation.criterionId);
|
|
111
|
-
if (definition) {
|
|
112
|
-
weightedSum += evaluation.score * definition.weight;
|
|
113
|
-
totalWeight += definition.weight;
|
|
114
|
-
}
|
|
115
|
-
}
|
|
116
|
-
if (totalWeight === 0)
|
|
117
|
-
return 0;
|
|
118
|
-
return Math.round(weightedSum / totalWeight);
|
|
119
|
-
}
|
|
120
|
-
/**
|
|
121
|
-
* Determine the lifecycle decision based on evaluation results
|
|
122
|
-
*
|
|
123
|
-
* Decision logic:
|
|
124
|
-
* 1. If quality score >= advanceThreshold AND confidence >= confidenceThreshold → advance
|
|
125
|
-
* 2. If quality score < escalateThreshold → escalate (quality too low for auto-fix)
|
|
126
|
-
* 3. If rerun count >= maxAutoRetries → escalate (exhausted retries)
|
|
127
|
-
* 4. If confidence < confidenceThreshold → escalate (agent uncertain)
|
|
128
|
-
* 5. Otherwise → rerun (quality between escalate and advance thresholds)
|
|
129
|
-
*/
|
|
130
|
-
export function determineDecision(qualityScore, confidence, rerunCount, phaseCriteria, config) {
|
|
131
|
-
const maxRetries = Math.min(phaseCriteria.maxAutoRetries, config.maxAutoRetries);
|
|
132
|
-
// Check confidence first - if agent is uncertain, escalate
|
|
133
|
-
if (confidence < config.confidenceThreshold) {
|
|
134
|
-
return 'escalate';
|
|
135
|
-
}
|
|
136
|
-
// Quality meets the advance threshold - auto-advance
|
|
137
|
-
if (qualityScore >= phaseCriteria.advanceThreshold) {
|
|
138
|
-
return 'advance';
|
|
139
|
-
}
|
|
140
|
-
// Quality below escalation threshold - needs human help
|
|
141
|
-
if (qualityScore < phaseCriteria.escalateThreshold) {
|
|
142
|
-
return 'escalate';
|
|
143
|
-
}
|
|
144
|
-
// Quality is between thresholds - could improve with a re-run
|
|
145
|
-
// But check if we've exhausted retries
|
|
146
|
-
if (rerunCount >= maxRetries) {
|
|
147
|
-
return 'escalate';
|
|
148
|
-
}
|
|
149
|
-
return 'rerun';
|
|
150
|
-
}
|
|
151
|
-
/**
|
|
152
|
-
* Build the complete decision result from an evaluation
|
|
153
|
-
* Combines the evaluation with transition rules to produce an actionable result
|
|
154
|
-
*/
|
|
155
|
-
export function buildDecisionResult(evaluation) {
|
|
156
|
-
if (evaluation.decision === 'advance') {
|
|
157
|
-
const transition = getTransitionRule(evaluation.phase);
|
|
158
|
-
return {
|
|
159
|
-
evaluation,
|
|
160
|
-
transition,
|
|
161
|
-
executionMode: transition?.executionMode,
|
|
162
|
-
targetStatus: transition?.targetStatus,
|
|
163
|
-
};
|
|
164
|
-
}
|
|
165
|
-
if (evaluation.decision === 'rerun') {
|
|
166
|
-
return {
|
|
167
|
-
evaluation,
|
|
168
|
-
executionMode: getRerunExecutionMode(evaluation.phase),
|
|
169
|
-
};
|
|
170
|
-
}
|
|
171
|
-
// escalate - no automatic action, just return the evaluation
|
|
172
|
-
return { evaluation };
|
|
173
|
-
}
|
|
174
|
-
/**
|
|
175
|
-
* Default lifecycle agent configuration
|
|
176
|
-
* Conservative defaults that prioritize safety over automation speed
|
|
177
|
-
*/
|
|
178
|
-
export const DEFAULT_LIFECYCLE_AGENT_CONFIG = {
|
|
179
|
-
enabled: false,
|
|
180
|
-
autoAdvanceEnabled: false,
|
|
181
|
-
autoRerunEnabled: true,
|
|
182
|
-
maxAutoRetries: 3,
|
|
183
|
-
confidenceThreshold: 60,
|
|
184
|
-
};
|