synarcx 0.3.1 → 0.3.2

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.
@@ -71,7 +71,7 @@ export function getSynDebugCommandTemplate() {
71
71
  name: 'syn:debug',
72
72
  description: 'Investigate a known error — root cause analysis through hypothesis, explicitly prompts /syn:propose',
73
73
  tags: ['workflow', 'debug', 'fix'],
74
- content: `Investigate a known error or failure systematically in 3 phases. Produces a diagnosis and suggests \`/syn:propose\` for creating the fix change.
74
+ content: `Investigate a known error or failure systematically in 3 phases. Produces a diagnosis and explicitly prompts the user to run \`/syn:propose\` does NOT auto-create artifacts or auto-hand off.
75
75
 
76
76
  **Input**: Error message, symptom, or failure description. The argument after \`/syn:debug\` is what went wrong.
77
77
 
@@ -79,7 +79,12 @@ export function getSynDebugCommandTemplate() {
79
79
 
80
80
  ## Initial Context
81
81
 
82
- If a change is active, read its artifacts first to understand what was intended vs. what went wrong.
82
+ If a change is active, read its artifacts first:
83
+ - \`synspec/changes/<name>/proposal.md\`
84
+ - \`synspec/changes/<name>/design.md\`
85
+ - \`synspec/changes/<name>/tasks.md\`
86
+
87
+ Use that context to understand what was intended vs. what went wrong.
83
88
 
84
89
  ---
85
90
 
@@ -111,7 +116,19 @@ If a change is active, read its artifacts first to understand what was intended
111
116
 
112
117
  ## Output
113
118
 
114
- After completing, present the diagnosis and explicitly prompt the user to run \`/syn:propose\` to formalize the fix. Do NOT auto-create artifacts.`
119
+ After completing the 3-phase investigation, present findings and prompt explicitly:
120
+
121
+ \`\`\`
122
+ ### Diagnosis
123
+
124
+ **Root Cause**: <what was found>
125
+ **Pattern**: <similar issues or novel>
126
+ **Hypothesis**: <proposed fix approach>
127
+
128
+ **Ready to formalize?** Run \`/syn:propose\` to create a change with these findings.
129
+ \`\`\`
130
+
131
+ Do NOT create any artifacts, do NOT start the pipeline automatically. The user must explicitly run \`/syn:propose\` to formalize.`
115
132
  });
116
133
  }
117
134
  //# sourceMappingURL=debug.js.map
@@ -103,12 +103,52 @@ export function getSynRefactorCommandTemplate() {
103
103
 
104
104
  ---
105
105
 
106
+ ## Initial Context
107
+
108
+ Check for existing context:
109
+ \`\`\`bash
110
+ synarcx list --json
111
+ \`\`\`
112
+
113
+ If a relevant change exists, read its artifacts. Otherwise, start fresh.
114
+
115
+ ---
116
+
117
+ ## Reframing the Problem
118
+
119
+ This is a structural-change investigation. The goal is to improve code organization, reduce duplication, increase cohesion, or decrease coupling — without changing what the system does.
120
+
121
+ ### Opening Question
122
+
123
+ Start by asking (use AskUserQuestion tool, open-ended):
124
+ > "What part of the codebase feels like it needs restructuring?"
125
+
126
+ Let the user describe the pain point before diving in.
127
+
128
+ ---
129
+
106
130
  ## Investigation
107
131
 
108
- 1. **Map the current shape** — read relevant source files, identify module boundaries, dependencies, duplication.
109
- 2. **Identify the target shape** — define what the ideal structure looks like.
110
- 3. **Surface risks** — flag implicit dependencies, testing hazards, areas that could get worse.
111
- 4. **Visualize** use ASCII diagrams to show current vs. target structure.
132
+ 1. **Map the current shape** — read relevant source files, identify:
133
+ - Module boundaries and responsibilities
134
+ - Dependency direction
135
+ - Code duplication or overlapping concerns
136
+ - Testing patterns
137
+
138
+ 2. **Identify the target shape** — work with the user to define:
139
+ - What the ideal structure would look like
140
+ - Which modules or files move where
141
+ - How dependencies should flow
142
+
143
+ 3. **Surface risks** — flag areas of concern:
144
+ - Implicit dependencies that aren't visible in imports
145
+ - Areas where refactoring could make things worse
146
+ - Testing hazards (brittle tests, high coupling to internals)
147
+
148
+ 4. **Visualize** — use ASCII diagrams to show:
149
+ - Current vs. target module structure
150
+ - Dependency direction changes
151
+ - File/move relationships
112
152
 
113
153
  ---
114
154
 
@@ -120,7 +160,20 @@ When artifacts are created, the analyze phase MUST check for behavior contract v
120
160
 
121
161
  ## Hand-Off
122
162
 
123
- Present a summary with Current Shape, Target Shape, Key Changes, and Risks. Then explicitly prompt: "Ready to formalize? Run \`/syn:propose\` to create a change with these findings."`
163
+ When the investigation reaches a clear conclusion, present findings and explicitly prompt:
164
+
165
+ \`\`\`
166
+ ### Refactoring Plan
167
+
168
+ **Current Shape**: <summary of current structure>
169
+ **Target Shape**: <proposed structure>
170
+ **Key Changes**: <list of structural moves>
171
+ **Risks**: <potential issues>
172
+
173
+ **Ready to formalize?** Run \`/syn:propose\` to create a change with these findings.
174
+ \`\`\`
175
+
176
+ Do NOT create any artifacts or start the pipeline. The user must explicitly run \`/syn:propose\`.`
124
177
  });
125
178
  }
126
179
  //# sourceMappingURL=refactor.js.map