@atlashub/smartstack-cli 4.35.0 → 4.36.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/dist/index.js +28 -32
- package/dist/index.js.map +1 -1
- package/dist/mcp-entry.mjs +29 -10
- package/dist/mcp-entry.mjs.map +1 -1
- package/package.json +1 -1
- package/templates/skills/apex/references/checks/seed-checks.sh +1 -1
- package/templates/skills/apex/references/core-seed-data.md +39 -21
- package/templates/skills/application/references/application-roles-template.md +14 -8
- package/templates/skills/application/references/provider-template.md +32 -20
- package/templates/skills/application/templates-frontend.md +294 -2
- package/templates/skills/application/templates-seed.md +23 -11
- package/templates/skills/audit-route/SKILL.md +107 -0
- package/templates/skills/audit-route/references/routing-pattern.md +129 -0
- package/templates/skills/audit-route/steps/step-00-init.md +128 -0
- package/templates/skills/audit-route/steps/step-01-inventory.md +157 -0
- package/templates/skills/audit-route/steps/step-02-conformity.md +193 -0
- package/templates/skills/audit-route/steps/step-03-report.md +201 -0
- package/templates/skills/dev-start/SKILL.md +12 -2
- package/templates/skills/efcore/SKILL.md +219 -67
- package/templates/agents/efcore/conflicts.md +0 -114
- package/templates/agents/efcore/db-deploy.md +0 -86
- package/templates/agents/efcore/db-reset.md +0 -98
- package/templates/agents/efcore/db-seed.md +0 -73
- package/templates/agents/efcore/db-status.md +0 -97
- package/templates/agents/efcore/scan.md +0 -124
- package/templates/skills/efcore/references/both-contexts.md +0 -32
- package/templates/skills/efcore/references/destructive-operations.md +0 -38
- package/templates/skills/efcore/steps/db/step-deploy.md +0 -217
- package/templates/skills/efcore/steps/db/step-reset.md +0 -186
- package/templates/skills/efcore/steps/db/step-seed.md +0 -166
- package/templates/skills/efcore/steps/db/step-status.md +0 -173
- package/templates/skills/efcore/steps/migration/step-00-init.md +0 -102
- package/templates/skills/efcore/steps/migration/step-01-check.md +0 -164
- package/templates/skills/efcore/steps/migration/step-02-create.md +0 -160
- package/templates/skills/efcore/steps/migration/step-03-validate.md +0 -168
- package/templates/skills/efcore/steps/rebase-snapshot/step-00-init.md +0 -173
- package/templates/skills/efcore/steps/rebase-snapshot/step-01-backup.md +0 -100
- package/templates/skills/efcore/steps/rebase-snapshot/step-02-fetch.md +0 -115
- package/templates/skills/efcore/steps/rebase-snapshot/step-03-create.md +0 -112
- package/templates/skills/efcore/steps/rebase-snapshot/step-04-validate.md +0 -157
- package/templates/skills/efcore/steps/shared/step-00-init.md +0 -131
- package/templates/skills/efcore/steps/squash/step-00-init.md +0 -141
- package/templates/skills/efcore/steps/squash/step-01-backup.md +0 -120
- package/templates/skills/efcore/steps/squash/step-02-fetch.md +0 -168
- package/templates/skills/efcore/steps/squash/step-03-create.md +0 -184
- package/templates/skills/efcore/steps/squash/step-04-validate.md +0 -174
|
@@ -0,0 +1,193 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: step-02-conformity
|
|
3
|
+
description: Evaluate conformity of each element and scan for anti-patterns
|
|
4
|
+
next_step: steps/step-03-report.md
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Step 2: Conformity Analysis
|
|
8
|
+
|
|
9
|
+
## MANDATORY EXECUTION RULES:
|
|
10
|
+
- Load `references/routing-pattern.md` FIRST for the reference pattern
|
|
11
|
+
- Read each element's FULL source code before evaluating
|
|
12
|
+
- NEVER judge developers — analyze code objectively
|
|
13
|
+
- Distinguish errors from conscious architectural choices
|
|
14
|
+
- If a deviation has a valid technical justification, say so explicitly
|
|
15
|
+
- Cross-reference manual findings with MCP results from `{mcp_results}` (step-00)
|
|
16
|
+
|
|
17
|
+
## YOUR TASK:
|
|
18
|
+
For each of the 5 elements found in Step 1, evaluate conformity against the reference pattern. Then scan the entire codebase for anti-patterns.
|
|
19
|
+
|
|
20
|
+
---
|
|
21
|
+
|
|
22
|
+
## EXECUTION SEQUENCE:
|
|
23
|
+
|
|
24
|
+
### Phase A: Conformity Evaluation (per element)
|
|
25
|
+
|
|
26
|
+
For each of the 5 elements, read the full source file and evaluate:
|
|
27
|
+
|
|
28
|
+
#### Rating Scale:
|
|
29
|
+
| Rating | Symbol | Meaning |
|
|
30
|
+
|--------|--------|---------|
|
|
31
|
+
| Conforme | ✅ | Implementation matches the pattern |
|
|
32
|
+
| Partiellement conforme | ⚠️ | Intent is correct but execution deviates |
|
|
33
|
+
| Non conforme | ❌ | Implementation contradicts the pattern |
|
|
34
|
+
| Absent | 🔴 | Element does not exist |
|
|
35
|
+
|
|
36
|
+
#### For each element, record:
|
|
37
|
+
|
|
38
|
+
**If ✅ Conforme:**
|
|
39
|
+
- Brief confirmation of what makes it compliant
|
|
40
|
+
- Any notable strengths or best practices observed
|
|
41
|
+
|
|
42
|
+
**If ⚠️ Partiellement conforme, ❌ Non conforme, or 🔴 Absent — answer ALL 5 questions:**
|
|
43
|
+
|
|
44
|
+
**a) Qu'est-ce qui a ete fait a la place ?**
|
|
45
|
+
Describe precisely the alternative implementation found in the code.
|
|
46
|
+
Include specific file paths and line numbers.
|
|
47
|
+
|
|
48
|
+
**b) Pourquoi est-ce que ca ne respecte pas le pattern ?**
|
|
49
|
+
Technical explanation of the deviation:
|
|
50
|
+
- Tight coupling (front depends on route structure)
|
|
51
|
+
- Static routes (hardcoded in JSX instead of API-driven)
|
|
52
|
+
- Missing guard (no permission check at route level)
|
|
53
|
+
- Non-lazy imports (eager loading bloats bundle)
|
|
54
|
+
- Incomplete implementation (partial API usage)
|
|
55
|
+
|
|
56
|
+
**c) Pourquoi le developpeur a probablement fait ca ?**
|
|
57
|
+
Formulate a benevolent hypothesis:
|
|
58
|
+
- Pattern unknown at development time?
|
|
59
|
+
- Technical constraint (bundler, framework limitation)?
|
|
60
|
+
- Deliberate MVP simplification?
|
|
61
|
+
- Misunderstanding of front/back responsibility separation?
|
|
62
|
+
- Legacy architecture inheritance?
|
|
63
|
+
- Confusion between static protected routes and dynamic routes?
|
|
64
|
+
- Migration in progress (intentional intermediate state)?
|
|
65
|
+
|
|
66
|
+
**d) Quelle est la consequence concrete de cette deviation ?**
|
|
67
|
+
Concrete impact:
|
|
68
|
+
- DB/front coupling (routes changes require front deploy)
|
|
69
|
+
- Potential security flaw (permission bypass)
|
|
70
|
+
- Rigidity (adding a route requires code change + deploy)
|
|
71
|
+
- Technical debt (maintenance burden)
|
|
72
|
+
- Bundle size impact (non-lazy loading)
|
|
73
|
+
- User experience (flash of wrong page, etc.)
|
|
74
|
+
|
|
75
|
+
**e) Comment migrer vers le pattern cible ?**
|
|
76
|
+
Concrete migration steps considering existing code:
|
|
77
|
+
- DO NOT propose a complete rewrite if a targeted refactor suffices
|
|
78
|
+
- Number the steps in priority order
|
|
79
|
+
- Estimate scope: small (1-2 files), medium (3-5 files), large (6+ files)
|
|
80
|
+
- Note any prerequisites or dependencies between migration steps
|
|
81
|
+
|
|
82
|
+
---
|
|
83
|
+
|
|
84
|
+
### Phase B: Anti-Pattern Scan
|
|
85
|
+
|
|
86
|
+
Scan the ENTIRE codebase (not just routing files) for these anti-patterns:
|
|
87
|
+
|
|
88
|
+
#### B1. Hardcoded Routes in JSX
|
|
89
|
+
```
|
|
90
|
+
Grep patterns (in {web_root}):
|
|
91
|
+
- <Route\s+path= (outside DynamicRouter)
|
|
92
|
+
- path:\s*['"/] (in non-config files)
|
|
93
|
+
- navigate\(['"]\/ (hardcoded navigation targets)
|
|
94
|
+
- to=['"]\/ (Link/NavLink with hardcoded paths)
|
|
95
|
+
- href=['"]\/(?!http) (internal links with hardcoded paths)
|
|
96
|
+
```
|
|
97
|
+
|
|
98
|
+
**IMPORTANT**: Exclude legitimate cases:
|
|
99
|
+
- DynamicRouter.tsx itself (it generates routes dynamically)
|
|
100
|
+
- Test files
|
|
101
|
+
- Constants files that define route patterns for DynamicRouter consumption
|
|
102
|
+
- Documentation files
|
|
103
|
+
|
|
104
|
+
#### B2. Hardcoded Permissions in Components
|
|
105
|
+
```
|
|
106
|
+
Grep patterns (in {web_root}):
|
|
107
|
+
- hasPermission\(['"] (string literal permission checks)
|
|
108
|
+
- permission.*=== (direct comparison)
|
|
109
|
+
- role.*===.*['"]admin (role-based instead of permission-based)
|
|
110
|
+
- canAccess\(['"] (string literal access checks)
|
|
111
|
+
```
|
|
112
|
+
|
|
113
|
+
**Distinguish**: Permission checks using API-provided data (OK) vs hardcoded permission strings (anti-pattern).
|
|
114
|
+
|
|
115
|
+
**NOTE**: Components checking `permissionPath` from the menu API or from `useRouteConfig` data are CONFORMING — this is defense in depth, not hardcoding.
|
|
116
|
+
|
|
117
|
+
#### B2bis. MCP-detected Hardcoded Paths (cross-reference)
|
|
118
|
+
```
|
|
119
|
+
If {mcp_results.frontend_routes} is available:
|
|
120
|
+
- Merge MCP apiClients.issues (type: 'invalid-path') with manual B1 findings
|
|
121
|
+
- Add any MCP-detected hardcoded navigate()/Link paths not found by manual grep
|
|
122
|
+
- Deduplicate: same file:line from both sources counts as ONE finding
|
|
123
|
+
- Mark source: [MANUAL], [MCP], or [BOTH] for each finding
|
|
124
|
+
```
|
|
125
|
+
|
|
126
|
+
#### B3. Non-Lazy Imports in Registry
|
|
127
|
+
```
|
|
128
|
+
Grep patterns (in componentRegistry files):
|
|
129
|
+
- ^import .* from (eager imports of page components)
|
|
130
|
+
- require\( (CommonJS require of pages)
|
|
131
|
+
```
|
|
132
|
+
|
|
133
|
+
**Expected pattern**: `lazy(() => import(...))`
|
|
134
|
+
|
|
135
|
+
#### B4. Missing Suspense Boundaries
|
|
136
|
+
```
|
|
137
|
+
Grep patterns (in {web_root}):
|
|
138
|
+
- Check DynamicRouter and App.tsx for <Suspense> wrapping
|
|
139
|
+
- Check if lazy components are rendered without Suspense parent
|
|
140
|
+
```
|
|
141
|
+
|
|
142
|
+
#### B5. Route/Permission Path Misalignment
|
|
143
|
+
```
|
|
144
|
+
Cross-reference:
|
|
145
|
+
- Backend: permission paths in navigation seed data
|
|
146
|
+
- Frontend: permission checks in components
|
|
147
|
+
- Look for mismatches between API-provided paths and frontend expectations
|
|
148
|
+
```
|
|
149
|
+
|
|
150
|
+
#### B6. Duplicate Route Definitions
|
|
151
|
+
```
|
|
152
|
+
Check for routes defined in multiple places:
|
|
153
|
+
- DynamicRouter + another router file
|
|
154
|
+
- Static route config + dynamic route config
|
|
155
|
+
- Multiple files registering the same path
|
|
156
|
+
```
|
|
157
|
+
|
|
158
|
+
---
|
|
159
|
+
|
|
160
|
+
### Phase C: Compile Conformity Summary
|
|
161
|
+
|
|
162
|
+
```
|
|
163
|
+
## Conformity Results
|
|
164
|
+
|
|
165
|
+
| # | Element | Rating | Key Finding |
|
|
166
|
+
|---|---------|--------|-------------|
|
|
167
|
+
| 1 | componentRegistry | ✅/⚠️/❌/🔴 | {one-line summary} |
|
|
168
|
+
| 2 | ProtectedRoute | ✅/⚠️/❌/🔴 | {one-line summary} |
|
|
169
|
+
| 3 | DynamicRouter | ✅/⚠️/❌/🔴 | {one-line summary} |
|
|
170
|
+
| 4 | useRouteConfig | ✅/⚠️/❌/🔴 | {one-line summary} |
|
|
171
|
+
| 5 | Navigation API | ✅/⚠️/❌/🔴 | {one-line summary} |
|
|
172
|
+
|
|
173
|
+
## Anti-Patterns Detected: {count}
|
|
174
|
+
|
|
175
|
+
| # | Anti-Pattern | File:Line | Severity | Description |
|
|
176
|
+
|---|-------------|-----------|----------|-------------|
|
|
177
|
+
| 1 | {type} | {file}:{line} | HIGH/MED/LOW | {description} |
|
|
178
|
+
| ... | | | | |
|
|
179
|
+
|
|
180
|
+
-> Proceeding to final report...
|
|
181
|
+
```
|
|
182
|
+
|
|
183
|
+
---
|
|
184
|
+
|
|
185
|
+
## SUCCESS METRICS:
|
|
186
|
+
- Each element rated with justification
|
|
187
|
+
- All 5 causal questions answered for every deviation
|
|
188
|
+
- Anti-pattern scan covers entire web_root (not just routing files)
|
|
189
|
+
- False positives excluded (legitimate uses identified)
|
|
190
|
+
- Conformity summary table complete
|
|
191
|
+
|
|
192
|
+
## NEXT STEP:
|
|
193
|
+
After displaying conformity results, proceed directly to `./step-03-report.md`
|
|
@@ -0,0 +1,201 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: step-03-report
|
|
3
|
+
description: Generate the final structured audit report with migration plan
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Step 3: Final Report
|
|
7
|
+
|
|
8
|
+
## MANDATORY EXECUTION RULES:
|
|
9
|
+
- Use ALL data collected from steps 0-2
|
|
10
|
+
- Follow the EXACT output structure below
|
|
11
|
+
- Prioritize migration steps by impact (critical > important > nice-to-have)
|
|
12
|
+
- Include file:line references for every finding
|
|
13
|
+
- Keep executive summary to 3 lines maximum
|
|
14
|
+
|
|
15
|
+
## YOUR TASK:
|
|
16
|
+
Generate the complete structured audit report.
|
|
17
|
+
|
|
18
|
+
---
|
|
19
|
+
|
|
20
|
+
## OUTPUT STRUCTURE:
|
|
21
|
+
|
|
22
|
+
Generate the following report EXACTLY in this format:
|
|
23
|
+
|
|
24
|
+
```markdown
|
|
25
|
+
---
|
|
26
|
+
|
|
27
|
+
# Audit Dynamic Routing — {project_name}
|
|
28
|
+
|
|
29
|
+
**Date**: {current_date}
|
|
30
|
+
**Branch**: {current_branch}
|
|
31
|
+
**Scope**: {scope}
|
|
32
|
+
**Strict mode**: {strict}
|
|
33
|
+
|
|
34
|
+
---
|
|
35
|
+
|
|
36
|
+
## Resume executif
|
|
37
|
+
|
|
38
|
+
**Score global : {X}/5 elements conformes — Statut : {OK / A corriger / Critique}**
|
|
39
|
+
|
|
40
|
+
{Line 1: Overall architecture state in one sentence}
|
|
41
|
+
{Line 2: Most critical finding or strength}
|
|
42
|
+
{Line 3: Recommended immediate action (if any)}
|
|
43
|
+
|
|
44
|
+
---
|
|
45
|
+
|
|
46
|
+
## 1. componentRegistry
|
|
47
|
+
**Statut** : {✅ / ⚠️ / ❌ / 🔴}
|
|
48
|
+
**Fichier** : {path:line or ABSENT}
|
|
49
|
+
|
|
50
|
+
{If deviation: full 5-question causal analysis (a through e)}
|
|
51
|
+
{If conforme: brief confirmation with notable strengths}
|
|
52
|
+
|
|
53
|
+
---
|
|
54
|
+
|
|
55
|
+
## 2. ProtectedRoute
|
|
56
|
+
**Statut** : {✅ / ⚠️ / ❌ / 🔴}
|
|
57
|
+
**Fichier** : {path:line or ABSENT}
|
|
58
|
+
|
|
59
|
+
{If deviation: full 5-question causal analysis}
|
|
60
|
+
{If conforme: brief confirmation}
|
|
61
|
+
|
|
62
|
+
---
|
|
63
|
+
|
|
64
|
+
## 3. DynamicRouter
|
|
65
|
+
**Statut** : {✅ / ⚠️ / ❌ / 🔴}
|
|
66
|
+
**Fichier** : {path:line or ABSENT}
|
|
67
|
+
|
|
68
|
+
{If deviation: full 5-question causal analysis}
|
|
69
|
+
{If conforme: brief confirmation}
|
|
70
|
+
|
|
71
|
+
---
|
|
72
|
+
|
|
73
|
+
## 4. useRouteConfig (hook de fetch)
|
|
74
|
+
**Statut** : {✅ / ⚠️ / ❌ / 🔴}
|
|
75
|
+
**Fichier** : {path:line or ABSENT}
|
|
76
|
+
|
|
77
|
+
{If deviation: full 5-question causal analysis}
|
|
78
|
+
{If conforme: brief confirmation}
|
|
79
|
+
|
|
80
|
+
---
|
|
81
|
+
|
|
82
|
+
## 5. API Navigation
|
|
83
|
+
**Statut** : {✅ / ⚠️ / ❌ / 🔴}
|
|
84
|
+
**Endpoint** : {method path or ABSENT}
|
|
85
|
+
|
|
86
|
+
{If deviation: full 5-question causal analysis}
|
|
87
|
+
{If conforme: brief confirmation}
|
|
88
|
+
|
|
89
|
+
---
|
|
90
|
+
|
|
91
|
+
## Validation MCP (baseline automatique)
|
|
92
|
+
|
|
93
|
+
{If MCP unavailable: "MCP non disponible — audit base sur l'analyse manuelle uniquement."}
|
|
94
|
+
|
|
95
|
+
{If MCP available:}
|
|
96
|
+
|
|
97
|
+
### validate_frontend_routes
|
|
98
|
+
| Metrique | Valeur |
|
|
99
|
+
|----------|--------|
|
|
100
|
+
| Valid | {yes/no} |
|
|
101
|
+
| Registry exists | {yes/no} |
|
|
102
|
+
| Registered keys | {N} |
|
|
103
|
+
| Missing keys | {N} |
|
|
104
|
+
| API client issues | {N} |
|
|
105
|
+
| Recommendations | {list} |
|
|
106
|
+
|
|
107
|
+
### validate_conventions (frontend-routes)
|
|
108
|
+
| Metrique | Valeur |
|
|
109
|
+
|----------|--------|
|
|
110
|
+
| Errors | {N} |
|
|
111
|
+
| Warnings | {N} |
|
|
112
|
+
| Seed data routes checked | {N} |
|
|
113
|
+
|
|
114
|
+
### Divergences MCP vs analyse manuelle
|
|
115
|
+
{List any differences between MCP automated results and manual analysis.
|
|
116
|
+
If both agree, state: "Aucune divergence — MCP et analyse manuelle sont alignes."}
|
|
117
|
+
|
|
118
|
+
---
|
|
119
|
+
|
|
120
|
+
## Anti-patterns detectes
|
|
121
|
+
|
|
122
|
+
{If none: "Aucun anti-pattern detecte."}
|
|
123
|
+
|
|
124
|
+
{If found, list ALL with file:line references:}
|
|
125
|
+
|
|
126
|
+
| # | Type | Fichier:Ligne | Severite | Description |
|
|
127
|
+
|---|------|--------------|----------|-------------|
|
|
128
|
+
| 1 | {type} | {file}:{line} | {CRITIQUE/IMPORTANT/MINEUR} | {description} |
|
|
129
|
+
|
|
130
|
+
### Detail par anti-pattern
|
|
131
|
+
|
|
132
|
+
#### AP-{n}: {title}
|
|
133
|
+
- **Localisation** : {file}:{line}
|
|
134
|
+
- **Code concerne** :
|
|
135
|
+
```tsx
|
|
136
|
+
{relevant code snippet, max 5 lines}
|
|
137
|
+
```
|
|
138
|
+
- **Probleme** : {why this is an anti-pattern}
|
|
139
|
+
- **Impact** : {concrete consequence}
|
|
140
|
+
- **Correction** : {specific fix}
|
|
141
|
+
|
|
142
|
+
---
|
|
143
|
+
|
|
144
|
+
## Plan de migration priorise
|
|
145
|
+
|
|
146
|
+
{If no migration needed: "Aucune migration necessaire — l'architecture est conforme au pattern cible."}
|
|
147
|
+
|
|
148
|
+
{If migration needed:}
|
|
149
|
+
|
|
150
|
+
### Critique (bloquer toute PR)
|
|
151
|
+
{numbered list of critical fixes with file references and estimated scope}
|
|
152
|
+
|
|
153
|
+
### Important (a planifier dans le sprint)
|
|
154
|
+
{numbered list of important fixes}
|
|
155
|
+
|
|
156
|
+
### Nice-to-have (backlog)
|
|
157
|
+
{numbered list of improvements}
|
|
158
|
+
|
|
159
|
+
### Ordre de migration recommande
|
|
160
|
+
{If multiple fixes, specify dependency order:}
|
|
161
|
+
1. {First fix — prerequisite for others}
|
|
162
|
+
2. {Second fix — depends on #1}
|
|
163
|
+
3. ...
|
|
164
|
+
|
|
165
|
+
---
|
|
166
|
+
|
|
167
|
+
## Metriques
|
|
168
|
+
|
|
169
|
+
| Metrique | Valeur |
|
|
170
|
+
|----------|--------|
|
|
171
|
+
| Elements conformes | {X}/5 |
|
|
172
|
+
| Elements partiellement conformes | {Y}/5 |
|
|
173
|
+
| Elements non conformes | {Z}/5 |
|
|
174
|
+
| Elements absents | {W}/5 |
|
|
175
|
+
| Anti-patterns detectes | {count} |
|
|
176
|
+
| Anti-patterns critiques | {count} |
|
|
177
|
+
| Fichiers a modifier | {count} |
|
|
178
|
+
| Estimation effort migration | {Faible/Moyen/Eleve} |
|
|
179
|
+
| MCP baseline disponible | {Oui/Non} |
|
|
180
|
+
| Divergences MCP vs manuel | {count} |
|
|
181
|
+
|
|
182
|
+
---
|
|
183
|
+
```
|
|
184
|
+
|
|
185
|
+
---
|
|
186
|
+
|
|
187
|
+
## REPORT QUALITY RULES:
|
|
188
|
+
|
|
189
|
+
1. **Every finding has evidence** — file:line or code snippet
|
|
190
|
+
2. **No vague statements** — "some routes are hardcoded" -> "3 routes hardcoded in TicketListView.tsx:42, UserPage.tsx:18, AdminDashboard.tsx:7"
|
|
191
|
+
3. **Migration steps are actionable** — not "refactor the routing" but "Move Route definition from App.tsx:34-56 to DynamicRouter, add componentKey 'admin.dashboard' to PageRegistry"
|
|
192
|
+
4. **Distinguish SmartStack-specific patterns** — Some deviations from the generic pattern may be correct for SmartStack SDK architecture. Flag these as "SmartStack-specific: conforming to SDK pattern" rather than as deviations
|
|
193
|
+
5. **Be honest about ambiguity** — If you cannot determine whether a deviation is intentional, say "Intention ambigue" and present both interpretations
|
|
194
|
+
|
|
195
|
+
## SUCCESS METRICS:
|
|
196
|
+
- Report follows exact structure above
|
|
197
|
+
- All sections populated with data from steps 0-2
|
|
198
|
+
- Executive summary is exactly 3 lines
|
|
199
|
+
- Migration plan is prioritized and actionable
|
|
200
|
+
- Metrics table is complete and accurate
|
|
201
|
+
- Every finding has a file:line reference
|
|
@@ -180,12 +180,22 @@ Use `Bash(run_in_background=true)` so it runs in background.
|
|
|
180
180
|
2. If `--reset` OR no stored password:
|
|
181
181
|
a. If backend was just launched, wait for it to be UP first:
|
|
182
182
|
```bash
|
|
183
|
-
#
|
|
183
|
+
# Phase 1: Wait for port to be bound (up to 30s)
|
|
184
184
|
for i in $(seq 1 10); do
|
|
185
185
|
netstat.exe -ano | grep ":${API_PORT} .*LISTENING" && break
|
|
186
186
|
sleep 3
|
|
187
187
|
done
|
|
188
188
|
```
|
|
189
|
+
```bash
|
|
190
|
+
# Phase 2: Wait for API to actually respond to HTTP requests (up to 30s)
|
|
191
|
+
# Kestrel binds the port BEFORE the app is fully initialized.
|
|
192
|
+
# We must confirm the API actually responds before resetting the password.
|
|
193
|
+
for i in $(seq 1 10); do
|
|
194
|
+
curl -s -o /dev/null -w "%{http_code}" "http://localhost:${API_PORT}/scalar" 2>/dev/null | grep -q "200" && break
|
|
195
|
+
sleep 3
|
|
196
|
+
done
|
|
197
|
+
```
|
|
198
|
+
If `/scalar` does not return 200 after 30s, warn the user and attempt the reset anyway.
|
|
189
199
|
b. Run: `smartstack admin reset --force --json`
|
|
190
200
|
c. Parse JSON output to extract email and password
|
|
191
201
|
d. Write `.claude/dev-session.json`:
|
|
@@ -224,7 +234,7 @@ Use `Bash(run_in_background=true)` so it runs in background.
|
|
|
224
234
|
|
|
225
235
|
<important_notes>
|
|
226
236
|
|
|
227
|
-
1. **Backend must be
|
|
237
|
+
1. **Backend must be READY before admin reset** - First poll the port (netstat), then poll the `/health` endpoint (HTTP 200) to confirm the API is fully initialized. Kestrel binds the port before the app finishes starting, so port-only checks are insufficient.
|
|
228
238
|
2. **Cross-worktree support** - Detect the correct API directory regardless of which worktree we're in
|
|
229
239
|
3. **No MCP required** - This skill only uses bash commands and the `smartstack` CLI
|
|
230
240
|
4. **Config coherence is critical** - Mismatched ports between backend/frontend is the #1 cause of "it doesn't work" issues
|