hashan-77 commited on
Commit
37c95c8
·
verified ·
1 Parent(s): af38ab6

Deploy repair agent from GitHub Actions

Browse files
Files changed (1) hide show
  1. README.md +137 -3
README.md CHANGED
@@ -1,5 +1,5 @@
1
  ---
2
- title: Stitch QA Repair Agent
3
  emoji: 🛠️
4
  colorFrom: purple
5
  colorTo: blue
@@ -7,6 +7,140 @@ sdk: docker
7
  app_port: 7860
8
  ---
9
 
10
- # Stitch QA Repair Agent
11
 
12
- Generates repair suggestions from execution logs.
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1
  ---
2
+ title: Stitch QA Defect Resolution Intelligence Analyst
3
  emoji: 🛠️
4
  colorFrom: purple
5
  colorTo: blue
 
7
  app_port: 7860
8
  ---
9
 
10
+ # Stitch QA Defect Resolution Intelligence Analyst - Repair Agent
11
 
12
+ **Defect Resolution Intelligence Analyst** is Agent 2 in the Stitch QA workflow.
13
+ It is also known by its original service name: **Repair Agent**.
14
+
15
+ Agent 2 converts confirmed Stitch QA findings into prioritized, evidence-linked repair contracts. It does not modify project source code. Its responsibility is to define what should be repaired, why it matters, what must stay protected, and how the repair should be verified.
16
+
17
+ ---
18
+
19
+ ## Role in Stitch QA
20
+
21
+ ```text
22
+ Source findings + runtime findings
23
+ ↓
24
+ Defect Resolution Intelligence Analyst - Repair Agent
25
+ ↓
26
+ Prioritized Stitch Repair Contracts
27
+ ```
28
+
29
+ Agent 2 receives validated evidence from source review and runtime analysis. It then creates repair contracts that are safe, bounded, and traceable back to the findings that justified them.
30
+
31
+ ---
32
+
33
+ ## Responsibilities
34
+
35
+ - Convert confirmed findings into repair contracts.
36
+ - Prioritize repairs using validated QA impact.
37
+ - Correlate related source and runtime findings when they describe the same affected behavior.
38
+ - Keep environment blockers separate from application defects.
39
+ - Define repair objectives, strategies, change boundaries, and protected behavior.
40
+ - Provide verification guidance and done conditions.
41
+ - Preserve `Auto Apply: False`.
42
+ - Avoid broad refactors or unsupported repair recommendations.
43
+
44
+ ---
45
+
46
+ ## Inputs
47
+
48
+ Agent 2 may receive:
49
+
50
+ - Source Quality Intelligence findings.
51
+ - Runtime Quality Intelligence root-cause groups.
52
+ - Test execution evidence.
53
+ - Failure origin and release gate.
54
+ - Project metadata.
55
+ - Evidence completeness information.
56
+
57
+ ---
58
+
59
+ ## Outputs
60
+
61
+ Agent 2 produces:
62
+
63
+ - Overall repair priority.
64
+ - Planning confidence.
65
+ - Repair side-effect risk.
66
+ - Stitch Repair Contracts.
67
+ - Next action.
68
+ - Verification guidance.
69
+ - Current knowledge requirement flag.
70
+ - Limitations.
71
+
72
+ ---
73
+
74
+ ## Repair Contract Structure
75
+
76
+ A Stitch Repair Contract typically includes:
77
+
78
+ - Contract ID.
79
+ - Linked finding references.
80
+ - Priority.
81
+ - Repair objective.
82
+ - Repair strategy.
83
+ - Change boundary.
84
+ - Protected behavior.
85
+ - Side-effect risk.
86
+ - Verification plan.
87
+ - Done condition.
88
+ - Contract status.
89
+
90
+ ---
91
+
92
+ ## Evidence-Linked Planning
93
+
94
+ Agent 2 must not create repair work from unsupported assumptions.
95
+
96
+ For example:
97
+
98
+ - If runtime evidence shows two failing tests caused by the same missing validation behavior, Agent 2 should group those findings into a focused repair contract.
99
+ - If Maven is unavailable, Agent 2 should recommend resolving the environment or build-tool problem, not editing application source code.
100
+ - If no tests exist in a Python source-only project, Agent 2 may recommend adding focused tests without changing production behavior solely to satisfy missing-test evidence.
101
+
102
+ ---
103
+
104
+ ## AI Usage
105
+
106
+ Agent 2 may use a local model reasoning layer to draft or refine repair contracts. However, every contract must remain grounded in supplied Stitch QA evidence and must pass validation.
107
+
108
+ If AI generation is unavailable, invalid, incomplete, or ungrounded, Agent 2 returns deterministic fallback repair planning.
109
+
110
+ ---
111
+
112
+ ## Safety Rules
113
+
114
+ - Do not automatically apply fixes.
115
+ - Do not generate unrelated refactors.
116
+ - Do not mix environment blockers with application defects.
117
+ - Do not recommend application source changes for toolchain availability problems.
118
+ - Do not invent current external facts.
119
+ - Do not expand repair scope beyond supplied evidence.
120
+ - Keep `auto_apply` false in all outputs.
121
+
122
+ ---
123
+
124
+ ## Typical Outcomes
125
+
126
+ | Scenario | Expected Agent 2 outcome |
127
+ | --- | --- |
128
+ | Confirmed application failures | One or more prioritized repair contracts |
129
+ | Correlated runtime and source findings | One focused contract where evidence supports correlation |
130
+ | Maven unavailable | Environment-only repair contract |
131
+ | All tests pass and no source findings exist | `NO_REPAIR_REQUIRED` |
132
+ | Unsupported project clean exit | Agent 2 is not run |
133
+
134
+ ---
135
+
136
+ ## Service Summary
137
+
138
+ | Field | Value |
139
+ | --- | --- |
140
+ | Agent number | Agent 2 |
141
+ | Special name | Defect Resolution Intelligence Analyst |
142
+ | Original service name | Repair Agent |
143
+ | Primary responsibility | Evidence-linked repair planning |
144
+ | Source-code modification | Not allowed |
145
+ | Main output | Stitch Repair Contracts |
146
+ | Auto Apply | Always false |