@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
|
@@ -805,7 +805,7 @@ public class {AppPascalName}SeedDataProvider : IClientSeedDataProvider
|
|
|
805
805
|
else
|
|
806
806
|
{
|
|
807
807
|
app = NavigationApplication.Create(
|
|
808
|
-
"{app_code}", "{app_label_en}",
|
|
808
|
+
ApplicationZone.Business, "{app_code}", "{app_label_en}",
|
|
809
809
|
"{app_desc_en}", "{app_icon}", IconType.Lucide,
|
|
810
810
|
"/{app_code}", {display_order});
|
|
811
811
|
context.NavigationApplications.Add(app);
|
|
@@ -822,17 +822,23 @@ public class {AppPascalName}SeedDataProvider : IClientSeedDataProvider
|
|
|
822
822
|
|
|
823
823
|
// Module translations — IDEMPOTENT (unique index IX_nav_Translations_EntityType_EntityId_LanguageCode)
|
|
824
824
|
// CRITICAL: Always check before inserting to avoid duplicate key errors on re-runs
|
|
825
|
+
// CRITICAL: Use modEntity.Id (actual DB ID), NOT seed-time GUID from SeedData class.
|
|
825
826
|
// if (!await context.NavigationTranslations.AnyAsync(
|
|
826
|
-
// t => t.EntityId ==
|
|
827
|
-
// { foreach (var t in {Module}NavigationSeedData.GetTranslationEntries())
|
|
827
|
+
// t => t.EntityId == mod1Entity.Id && t.EntityType == NavigationEntityType.Module, ct))
|
|
828
|
+
// { foreach (var t in {Module}NavigationSeedData.GetTranslationEntries())
|
|
829
|
+
// { context.NavigationTranslations.Add(
|
|
830
|
+
// NavigationTranslation.Create(t.EntityType, mod1Entity.Id, t.LanguageCode, t.Label, t.Description)); } }
|
|
828
831
|
|
|
829
832
|
// Sections (idempotent per-section — check each before inserting)
|
|
830
833
|
// var secExists = await context.NavigationSections.AnyAsync(s => s.Code == secEntry.Code && s.ModuleId == ..., ct);
|
|
831
834
|
// Use NavigationSection.Create(moduleId, code, label, description, icon, iconType, route, displayOrder)
|
|
832
835
|
|
|
833
836
|
// Section translations — IDEMPOTENT (same guard pattern as module translations)
|
|
837
|
+
// CRITICAL: Resolve actual section from DB (secEntry.Id is seed-time GUID ≠ DB ID):
|
|
838
|
+
// var actualSection = await context.NavigationSections
|
|
839
|
+
// .FirstAsync(s => s.Code == secEntry.Code && s.ModuleId == modEntity.Id, ct);
|
|
834
840
|
// if (!await context.NavigationTranslations.AnyAsync(
|
|
835
|
-
// t => t.EntityId ==
|
|
841
|
+
// t => t.EntityId == actualSection.Id && t.EntityType == NavigationEntityType.Section, ct))
|
|
836
842
|
|
|
837
843
|
// Resources (idempotent per-resource — check each before inserting)
|
|
838
844
|
// var resExists = await context.NavigationResources.AnyAsync(r => r.Code == resEntry.Code && r.SectionId == ..., ct);
|
|
@@ -841,20 +847,26 @@ public class {AppPascalName}SeedDataProvider : IClientSeedDataProvider
|
|
|
841
847
|
|
|
842
848
|
public async Task SeedRolesAsync(ICoreDbContext context, CancellationToken ct)
|
|
843
849
|
{
|
|
844
|
-
//
|
|
850
|
+
// Resolve application from DB by Code — NOT seed-time GUID
|
|
851
|
+
var app = await context.NavigationApplications
|
|
852
|
+
.FirstAsync(a => a.Code == "{app_code}", ct);
|
|
853
|
+
|
|
854
|
+
// Check idempotence — scoped by actual DB ApplicationId
|
|
845
855
|
var exists = await context.Roles
|
|
846
|
-
.AnyAsync(r => r.ApplicationId ==
|
|
856
|
+
.AnyAsync(r => r.ApplicationId == app.Id, ct);
|
|
847
857
|
if (exists) return;
|
|
848
858
|
|
|
849
859
|
// Create application-scoped roles (Admin, Manager, Contributor, Viewer)
|
|
850
860
|
foreach (var entry in ApplicationRolesSeedData.GetRoleEntries())
|
|
851
861
|
{
|
|
852
862
|
var role = Role.Create(
|
|
853
|
-
entry.
|
|
854
|
-
entry.
|
|
855
|
-
|
|
856
|
-
entry.
|
|
857
|
-
entry.IsSystem
|
|
863
|
+
name: entry.Name,
|
|
864
|
+
shortName: entry.Code,
|
|
865
|
+
category: RoleCategory.Application,
|
|
866
|
+
description: entry.Description,
|
|
867
|
+
isSystem: entry.IsSystem,
|
|
868
|
+
applicationId: app.Id,
|
|
869
|
+
code: entry.Code);
|
|
858
870
|
context.Roles.Add(role);
|
|
859
871
|
}
|
|
860
872
|
await ((DbContext)context).SaveChangesAsync(ct);
|
|
@@ -0,0 +1,107 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: audit-route
|
|
3
|
+
description: |
|
|
4
|
+
Audit dynamic routing architecture against the DB-driven pattern.
|
|
5
|
+
Use this skill when:
|
|
6
|
+
- Verifying routing is fully database-driven (no hardcoded routes)
|
|
7
|
+
- Checking the 5 mandatory elements (componentRegistry, ProtectedRoute, DynamicRouter, useRouteConfig, API)
|
|
8
|
+
- Validating route/permission alignment
|
|
9
|
+
- Detecting anti-patterns (static routes, hardcoded permissions, non-lazy imports)
|
|
10
|
+
argument-hint: "[--strict] [--scope=frontend|backend|all]"
|
|
11
|
+
model: sonnet
|
|
12
|
+
allowed-tools: "Read, Grep, Glob, Bash, Agent, ToolSearch"
|
|
13
|
+
entry_point: steps/step-00-init.md
|
|
14
|
+
---
|
|
15
|
+
|
|
16
|
+
<objective>
|
|
17
|
+
Audit the dynamic routing implementation against the SmartStack DB-driven routing pattern. The architecture requires that navigation and permissions are **entirely driven by the database** — the React frontend must contain **zero hardcoded routes**.
|
|
18
|
+
|
|
19
|
+
The audit validates 5 mandatory elements:
|
|
20
|
+
1. **componentRegistry** — static mapping `string -> lazy(component)`, only allowed static file
|
|
21
|
+
2. **ProtectedRoute** — front-end guard that validates permissions from the API (defense in depth)
|
|
22
|
+
3. **DynamicRouter** — rendering engine that generates `<Route>` from API config
|
|
23
|
+
4. **useRouteConfig** — hook that fetches route config + permissions from the API at mount
|
|
24
|
+
5. **Navigation API** — endpoint returning routes **already filtered** by JWT/session
|
|
25
|
+
|
|
26
|
+
For each element: inventory, conformity check, causal analysis of deviations, and migration plan.
|
|
27
|
+
</objective>
|
|
28
|
+
|
|
29
|
+
<quick_start>
|
|
30
|
+
|
|
31
|
+
```bash
|
|
32
|
+
/audit-route # Full audit (frontend + backend)
|
|
33
|
+
/audit-route --scope=frontend # Frontend only (React routing)
|
|
34
|
+
/audit-route --scope=backend # Backend only (API + navigation)
|
|
35
|
+
/audit-route --strict # Fail on any partial conformity (treat warnings as errors)
|
|
36
|
+
```
|
|
37
|
+
|
|
38
|
+
</quick_start>
|
|
39
|
+
|
|
40
|
+
<parameters>
|
|
41
|
+
|
|
42
|
+
<flags>
|
|
43
|
+
| Flag | Description |
|
|
44
|
+
|------|-------------|
|
|
45
|
+
| `--scope=all` | Audit both frontend and backend (default) |
|
|
46
|
+
| `--scope=frontend` | Audit React routing only (elements 1-4) |
|
|
47
|
+
| `--scope=backend` | Audit API navigation only (element 5) |
|
|
48
|
+
| `--strict` | Treat partial conformity (warning) as non-conformity (error) |
|
|
49
|
+
</flags>
|
|
50
|
+
|
|
51
|
+
</parameters>
|
|
52
|
+
|
|
53
|
+
<workflow>
|
|
54
|
+
1. **Initialize** — Detect project structure, resolve paths, parse flags
|
|
55
|
+
2. **MCP Pre-scan** — Call `validate_frontend_routes` and `validate_conventions` for automated baseline
|
|
56
|
+
3. **Inventory** — Locate each of the 5 mandatory elements in the codebase
|
|
57
|
+
4. **Conformity** — Evaluate each element against the reference pattern, cross-reference with MCP findings
|
|
58
|
+
5. **Anti-patterns** — Scan for hardcoded routes, static permissions, non-lazy imports
|
|
59
|
+
6. **Report** — Generate structured audit report with causal analysis and migration plan
|
|
60
|
+
</workflow>
|
|
61
|
+
|
|
62
|
+
<state_variables>
|
|
63
|
+
| Variable | Type | Description |
|
|
64
|
+
|----------|------|-------------|
|
|
65
|
+
| `{scope}` | string | frontend, backend, or all |
|
|
66
|
+
| `{strict}` | boolean | Treat warnings as errors |
|
|
67
|
+
| `{web_root}` | string | Path to web/smartstack-web/src/ |
|
|
68
|
+
| `{api_root}` | string | Path to src/SmartStack.Api/ |
|
|
69
|
+
| `{elements}` | object[] | Inventory of the 5 mandatory elements |
|
|
70
|
+
| `{conformity}` | object[] | Conformity status per element |
|
|
71
|
+
| `{anti_patterns}` | object[] | Detected anti-patterns with file:line |
|
|
72
|
+
| `{mcp_results}` | object | Results from MCP validate_frontend_routes + validate_conventions |
|
|
73
|
+
| `{score}` | string | X/5 conformity score |
|
|
74
|
+
</state_variables>
|
|
75
|
+
|
|
76
|
+
<entry_point>
|
|
77
|
+
|
|
78
|
+
**FIRST ACTION:** Load `steps/step-00-init.md`
|
|
79
|
+
|
|
80
|
+
</entry_point>
|
|
81
|
+
|
|
82
|
+
<step_files>
|
|
83
|
+
| Step | File | Purpose |
|
|
84
|
+
|------|------|---------|
|
|
85
|
+
| 00 | `steps/step-00-init.md` | Parse flags, detect project structure, resolve paths |
|
|
86
|
+
| 01 | `steps/step-01-inventory.md` | Locate all 5 mandatory elements in the codebase |
|
|
87
|
+
| 02 | `steps/step-02-conformity.md` | Evaluate conformity, causal analysis, anti-pattern scan |
|
|
88
|
+
| 03 | `steps/step-03-report.md` | Generate structured audit report with migration plan |
|
|
89
|
+
</step_files>
|
|
90
|
+
|
|
91
|
+
<execution_rules>
|
|
92
|
+
- **Read-only** — This skill NEVER modifies code
|
|
93
|
+
- **Non-judgmental** — Analyze code, not developers. Distinguish errors from conscious choices
|
|
94
|
+
- **Comprehensive** — Check ALL files, not a sample. Grep entire codebase for anti-patterns
|
|
95
|
+
- **Evidence-based** — Every finding must reference a specific file:line
|
|
96
|
+
- **Causal** — Every deviation must include: what was done instead, why it deviates, probable reason, consequence, and migration path
|
|
97
|
+
- **SmartStack-aware** — Respect SmartStack SDK architecture (PageRegistry, DynamicRouter, menu API)
|
|
98
|
+
</execution_rules>
|
|
99
|
+
|
|
100
|
+
<success_criteria>
|
|
101
|
+
- All 5 elements inventoried with exact file paths and line numbers
|
|
102
|
+
- Each element rated: Conforme / Partiellement conforme / Non conforme / Absent
|
|
103
|
+
- Anti-patterns detected across entire codebase (not just routing files)
|
|
104
|
+
- Causal analysis for every deviation (5 questions answered)
|
|
105
|
+
- Prioritized migration plan (critical > important > nice-to-have)
|
|
106
|
+
- Executive summary with X/5 score and 3-line architecture status
|
|
107
|
+
</success_criteria>
|
|
@@ -0,0 +1,129 @@
|
|
|
1
|
+
# Dynamic Routing Reference Pattern
|
|
2
|
+
|
|
3
|
+
## Architecture Principle
|
|
4
|
+
|
|
5
|
+
Navigation and permissions are **entirely driven by the database**. The React frontend contains **zero hardcoded routes**. The backend API returns routes already filtered by the user's JWT/session.
|
|
6
|
+
|
|
7
|
+
## 5 Mandatory Elements
|
|
8
|
+
|
|
9
|
+
### 1. componentRegistry
|
|
10
|
+
|
|
11
|
+
**Role**: Static mapping `string -> lazy(component)`. The ONLY allowed static file.
|
|
12
|
+
|
|
13
|
+
**Requirements**:
|
|
14
|
+
- All page imports MUST be lazy (`React.lazy(() => import(...))`)
|
|
15
|
+
- Keys are string identifiers (dot-separated hierarchical recommended)
|
|
16
|
+
- No business logic in the registry — pure mapping only
|
|
17
|
+
- Must be loaded at app startup (imported in main.tsx or App.tsx)
|
|
18
|
+
- New pages are registered here and ONLY here
|
|
19
|
+
|
|
20
|
+
**SmartStack specifics**:
|
|
21
|
+
- File: `componentRegistry.generated.ts`
|
|
22
|
+
- Registration via `PageRegistry.register()` (v3.7+)
|
|
23
|
+
- `PAGE_KEYS` constant for type-safe key references
|
|
24
|
+
- Generated by MCP `scaffold_routes` tool
|
|
25
|
+
|
|
26
|
+
### 2. ProtectedRoute
|
|
27
|
+
|
|
28
|
+
**Role**: Front-end guard that validates permissions received from the API (defense in depth).
|
|
29
|
+
|
|
30
|
+
**Requirements**:
|
|
31
|
+
- Receives permission requirements from route config (NOT hardcoded)
|
|
32
|
+
- Checks user permissions against route requirements
|
|
33
|
+
- Redirects unauthorized users (to login or forbidden page)
|
|
34
|
+
- Does NOT contain a list of routes or paths
|
|
35
|
+
- Permissions come from the API, not from static constants
|
|
36
|
+
|
|
37
|
+
**SmartStack specifics**:
|
|
38
|
+
- File: `ProtectedRoute.tsx`
|
|
39
|
+
- Replaced the old `RouteGuard.tsx` (which had hardcoded lists)
|
|
40
|
+
- Uses `permissionPath` from menu API DTOs
|
|
41
|
+
|
|
42
|
+
### 3. DynamicRouter
|
|
43
|
+
|
|
44
|
+
**Role**: Rendering engine that generates `<Route>` elements from the API configuration.
|
|
45
|
+
|
|
46
|
+
**Requirements**:
|
|
47
|
+
- Iterates over API route config to create React Router `<Route>` elements
|
|
48
|
+
- Resolves components from componentRegistry by key
|
|
49
|
+
- Wraps routes with ProtectedRoute for permission checking
|
|
50
|
+
- Handles nested routes (outlets, tabs)
|
|
51
|
+
- Supports loading states (shows loader while config is being fetched)
|
|
52
|
+
- No hardcoded route paths in the router itself
|
|
53
|
+
|
|
54
|
+
**SmartStack specifics**:
|
|
55
|
+
- File: `DynamicRouter.tsx`
|
|
56
|
+
- Sole routing engine — App.tsx reduced to providers + DynamicRouter
|
|
57
|
+
- Handles: dynamic app routes, feature gating, auto-redirects, outlet tab routes, doc routes
|
|
58
|
+
- `OUTLET_SECTIONS` config for tab-based pages
|
|
59
|
+
- `getStaticAppRoutes()` for per-app legacy redirects (migration period only)
|
|
60
|
+
|
|
61
|
+
### 4. useRouteConfig
|
|
62
|
+
|
|
63
|
+
**Role**: Hook that fetches route configuration + permissions from the API at mount.
|
|
64
|
+
|
|
65
|
+
**Requirements**:
|
|
66
|
+
- Calls navigation API on mount (or auth change)
|
|
67
|
+
- Returns structured route config with components, paths, and permissions
|
|
68
|
+
- Provides loading/error states
|
|
69
|
+
- Caches appropriately (invalidates on auth change)
|
|
70
|
+
- Flattens hierarchical menu into usable route entries
|
|
71
|
+
|
|
72
|
+
**SmartStack specifics**:
|
|
73
|
+
- File: `useRouteConfig.ts`
|
|
74
|
+
- Flattens menu API response into `RouteConfigEntry[]`
|
|
75
|
+
- Provides `byKey` and `byApplication` maps
|
|
76
|
+
- Used by DynamicRouter to build routes
|
|
77
|
+
|
|
78
|
+
### 5. Navigation API
|
|
79
|
+
|
|
80
|
+
**Role**: Endpoint returning routes already filtered by JWT/session.
|
|
81
|
+
|
|
82
|
+
**Requirements**:
|
|
83
|
+
- Returns routes with: path, componentKey, permissions, children
|
|
84
|
+
- Filters routes based on authenticated user's permissions
|
|
85
|
+
- Hierarchical structure (Application > Module > Section > Resource)
|
|
86
|
+
- Includes permission paths for front-end guard
|
|
87
|
+
- Supports feature gating (license-based)
|
|
88
|
+
|
|
89
|
+
**SmartStack specifics**:
|
|
90
|
+
- Endpoint: `GET /api/navigation/menu`
|
|
91
|
+
- Returns enriched DTOs at 4 levels (Application, Module, Section, Resource)
|
|
92
|
+
- `ComponentKey` and `PermissionPath` on all 4 DTO levels
|
|
93
|
+
- `RequiredFeature` for license-based feature gating
|
|
94
|
+
- Built by `NavigationService.BuildApplicationMenu/BuildModuleMenu/BuildSectionMenu/BuildResourceMenu`
|
|
95
|
+
|
|
96
|
+
## Expected API Response Structure
|
|
97
|
+
|
|
98
|
+
```json
|
|
99
|
+
{
|
|
100
|
+
"routes": [
|
|
101
|
+
{
|
|
102
|
+
"path": "/administration/users",
|
|
103
|
+
"componentKey": "administration.users.list",
|
|
104
|
+
"permissionPath": "administration.users",
|
|
105
|
+
"permissions": ["administration.users.access", "administration.users.read"],
|
|
106
|
+
"children": [
|
|
107
|
+
{
|
|
108
|
+
"path": ":id",
|
|
109
|
+
"componentKey": "administration.users.detail",
|
|
110
|
+
"permissions": ["administration.users.read"]
|
|
111
|
+
}
|
|
112
|
+
]
|
|
113
|
+
}
|
|
114
|
+
]
|
|
115
|
+
}
|
|
116
|
+
```
|
|
117
|
+
|
|
118
|
+
## Common Anti-Patterns
|
|
119
|
+
|
|
120
|
+
| Anti-Pattern | Description | Risk |
|
|
121
|
+
|-------------|-------------|------|
|
|
122
|
+
| Hardcoded routes in JSX | `<Route path="/admin" ...>` outside DynamicRouter | Routes drift from DB, permissions bypassed |
|
|
123
|
+
| Static permission lists | `const ADMIN_PERMS = [...]` in components | Permissions out of sync with API |
|
|
124
|
+
| Non-lazy imports in registry | `import Page from './Page'` (eager) | Bundle bloat, slow initial load |
|
|
125
|
+
| Missing Suspense boundary | No `<Suspense>` around lazy components | Crashes on slow loads |
|
|
126
|
+
| Route paths in components | `navigate('/admin/users')` with hardcoded paths | Tight coupling, breaks if DB paths change |
|
|
127
|
+
| Permission checks without API | `if (user.role === 'admin')` | Bypasses permission system |
|
|
128
|
+
| Duplicate route definitions | Routes in both DynamicRouter and static config | Conflicts, unpredictable behavior |
|
|
129
|
+
| Missing loading state | No loader while route config is fetching | Flash of "not found" page |
|
|
@@ -0,0 +1,128 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: step-00-init
|
|
3
|
+
description: Parse flags, detect project structure, resolve paths for routing audit
|
|
4
|
+
next_step: steps/step-01-inventory.md
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Step 0: Initialization
|
|
8
|
+
|
|
9
|
+
## MANDATORY EXECUTION RULES:
|
|
10
|
+
- NEVER skip project detection
|
|
11
|
+
- ALWAYS resolve actual filesystem paths before proceeding
|
|
12
|
+
- YOU ARE AN INITIALIZER, not a scanner
|
|
13
|
+
|
|
14
|
+
## YOUR TASK:
|
|
15
|
+
Parse the flags, detect the SmartStack project structure, and resolve which directories to scan.
|
|
16
|
+
|
|
17
|
+
---
|
|
18
|
+
|
|
19
|
+
## EXECUTION SEQUENCE:
|
|
20
|
+
|
|
21
|
+
### 1. Parse Input
|
|
22
|
+
|
|
23
|
+
```
|
|
24
|
+
Arguments from $ARGUMENTS:
|
|
25
|
+
--scope=frontend -> {scope} = "frontend" (elements 1-4 only)
|
|
26
|
+
--scope=backend -> {scope} = "backend" (element 5 only)
|
|
27
|
+
--scope=all -> {scope} = "all" (default)
|
|
28
|
+
--strict -> {strict} = true (default: false)
|
|
29
|
+
|
|
30
|
+
No arguments -> {scope} = "all", {strict} = false
|
|
31
|
+
```
|
|
32
|
+
|
|
33
|
+
### 2. Detect Project Structure
|
|
34
|
+
|
|
35
|
+
Use Glob and Bash to locate:
|
|
36
|
+
|
|
37
|
+
```
|
|
38
|
+
Frontend paths:
|
|
39
|
+
{web_root} = web/smartstack-web/src/
|
|
40
|
+
Verify: package.json exists in web/smartstack-web/
|
|
41
|
+
Verify: src/ directory exists
|
|
42
|
+
|
|
43
|
+
Backend paths:
|
|
44
|
+
{api_root} = src/SmartStack.Api/
|
|
45
|
+
{app_root} = src/SmartStack.Application/
|
|
46
|
+
{infra_root} = src/SmartStack.Infrastructure/
|
|
47
|
+
Verify: SmartStack.sln exists at project root
|
|
48
|
+
|
|
49
|
+
Key files to pre-locate (existence check only):
|
|
50
|
+
- componentRegistry: Glob for "**/componentRegistry*" in {web_root}
|
|
51
|
+
- ProtectedRoute: Glob for "**/ProtectedRoute*" in {web_root}
|
|
52
|
+
- DynamicRouter: Glob for "**/DynamicRouter*" in {web_root}
|
|
53
|
+
- useRouteConfig: Glob for "**/useRouteConfig*" in {web_root}
|
|
54
|
+
- Navigation controller: Glob for "**/Navigation*Controller*" in {api_root}
|
|
55
|
+
```
|
|
56
|
+
|
|
57
|
+
### 3. Validate Paths
|
|
58
|
+
|
|
59
|
+
For each required path:
|
|
60
|
+
- If missing: record as CRITICAL warning
|
|
61
|
+
- If found: record path for next steps
|
|
62
|
+
|
|
63
|
+
### 4. MCP Pre-scan (automated baseline)
|
|
64
|
+
|
|
65
|
+
Use `ToolSearch` to fetch MCP tools, then call them to get an automated baseline:
|
|
66
|
+
|
|
67
|
+
```
|
|
68
|
+
Step 4a: Fetch MCP tools
|
|
69
|
+
ToolSearch query="select:mcp__smartstack__validate_frontend_routes,mcp__smartstack__validate_conventions"
|
|
70
|
+
|
|
71
|
+
Step 4b: Call validate_frontend_routes (if available)
|
|
72
|
+
mcp__smartstack__validate_frontend_routes scope="all"
|
|
73
|
+
-> Store full result as {mcp_results.frontend_routes}
|
|
74
|
+
-> This gives: registry status, API client issues, component registry keys, missing keys, recommendations
|
|
75
|
+
|
|
76
|
+
Step 4c: Call validate_conventions (if available)
|
|
77
|
+
mcp__smartstack__validate_conventions checks=["frontend-routes"]
|
|
78
|
+
-> Store result as {mcp_results.conventions}
|
|
79
|
+
-> This gives: seed data cross-reference, missing PageRegistry entries
|
|
80
|
+
|
|
81
|
+
If MCP is unavailable: record as WARNING and continue without MCP baseline.
|
|
82
|
+
The manual audit in steps 1-2 will still produce a complete report.
|
|
83
|
+
```
|
|
84
|
+
|
|
85
|
+
### 5. Show Summary and Proceed
|
|
86
|
+
|
|
87
|
+
Display:
|
|
88
|
+
|
|
89
|
+
```
|
|
90
|
+
Routing Audit Configuration:
|
|
91
|
+
|
|
92
|
+
| Setting | Value |
|
|
93
|
+
|---------|-------|
|
|
94
|
+
| Scope | {scope} |
|
|
95
|
+
| Strict mode | {strict} |
|
|
96
|
+
| Web root | {web_root} |
|
|
97
|
+
| API root | {api_root} |
|
|
98
|
+
| MCP available | {yes/no} |
|
|
99
|
+
|
|
100
|
+
Pre-scan results:
|
|
101
|
+
| Element | File Found |
|
|
102
|
+
|---------|-----------|
|
|
103
|
+
| componentRegistry | {path or MISSING} |
|
|
104
|
+
| ProtectedRoute | {path or MISSING} |
|
|
105
|
+
| DynamicRouter | {path or MISSING} |
|
|
106
|
+
| useRouteConfig | {path or MISSING} |
|
|
107
|
+
| Navigation API | {path or MISSING} |
|
|
108
|
+
|
|
109
|
+
MCP baseline (if available):
|
|
110
|
+
| Check | Result |
|
|
111
|
+
|-------|--------|
|
|
112
|
+
| validate_frontend_routes | {valid: true/false, issues: N} |
|
|
113
|
+
| validate_conventions | {errors: N, warnings: N} |
|
|
114
|
+
|
|
115
|
+
-> Proceeding to inventory...
|
|
116
|
+
```
|
|
117
|
+
|
|
118
|
+
---
|
|
119
|
+
|
|
120
|
+
## SUCCESS METRICS:
|
|
121
|
+
- Scope and flags correctly parsed
|
|
122
|
+
- All filesystem paths resolved and validated
|
|
123
|
+
- MCP pre-scan executed (or gracefully skipped if unavailable)
|
|
124
|
+
- Pre-scan summary displayed with file existence status
|
|
125
|
+
- Ready for detailed inventory in next step
|
|
126
|
+
|
|
127
|
+
## NEXT STEP:
|
|
128
|
+
After showing initialization summary, proceed directly to `./step-01-inventory.md`
|
|
@@ -0,0 +1,157 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: step-01-inventory
|
|
3
|
+
description: Locate and inventory all 5 mandatory routing elements in the codebase
|
|
4
|
+
next_step: steps/step-02-conformity.md
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Step 1: Inventory
|
|
8
|
+
|
|
9
|
+
## MANDATORY EXECUTION RULES:
|
|
10
|
+
- Read EVERY file identified — do NOT guess from file names alone
|
|
11
|
+
- Record exact file paths AND line numbers for each finding
|
|
12
|
+
- If an element is ABSENT, search for alternative implementations before declaring missing
|
|
13
|
+
- Use parallel tool calls where possible for speed
|
|
14
|
+
|
|
15
|
+
## YOUR TASK:
|
|
16
|
+
For each of the 5 mandatory elements, locate the implementation, read it, and record key characteristics.
|
|
17
|
+
|
|
18
|
+
---
|
|
19
|
+
|
|
20
|
+
## EXECUTION SEQUENCE:
|
|
21
|
+
|
|
22
|
+
### 1. componentRegistry
|
|
23
|
+
|
|
24
|
+
**Search strategy:**
|
|
25
|
+
1. Glob: `**/componentRegistry*`, `**/pageRegistry*`, `**/PageRegistry*` in {web_root}
|
|
26
|
+
2. If not found: Grep for `React.lazy` or `lazy(` across all `.ts`/`.tsx` files
|
|
27
|
+
3. If not found: Grep for `import.*Page` to find eager imports pattern
|
|
28
|
+
|
|
29
|
+
**Record:**
|
|
30
|
+
- File path and total lines
|
|
31
|
+
- Registration mechanism (PageRegistry.register, object literal, Map, etc.)
|
|
32
|
+
- Import style: lazy (`React.lazy(() => import(...))`) vs eager (`import X from`)
|
|
33
|
+
- Number of registered components
|
|
34
|
+
- Key naming convention (dot-separated, slash-separated, flat)
|
|
35
|
+
- Where it's imported/loaded (main.tsx, App.tsx, etc.)
|
|
36
|
+
|
|
37
|
+
### 2. ProtectedRoute
|
|
38
|
+
|
|
39
|
+
**Search strategy:**
|
|
40
|
+
1. Glob: `**/ProtectedRoute*`, `**/RouteGuard*`, `**/AuthRoute*` in {web_root}
|
|
41
|
+
2. If not found: Grep for `permissions.*check\|requiredPermission\|canAccess` in routing files
|
|
42
|
+
3. If not found: Grep for `Navigate.*login\|redirect.*unauthorized` in route wrappers
|
|
43
|
+
|
|
44
|
+
**Record:**
|
|
45
|
+
- File path and total lines
|
|
46
|
+
- How permissions are received (props, context, hook)
|
|
47
|
+
- Where permission data comes from (API via hook, static constants, hardcoded)
|
|
48
|
+
- What happens on unauthorized (redirect, 403 page, null render)
|
|
49
|
+
- Whether it contains any hardcoded route or permission lists
|
|
50
|
+
|
|
51
|
+
### 3. DynamicRouter
|
|
52
|
+
|
|
53
|
+
**Search strategy:**
|
|
54
|
+
1. Glob: `**/DynamicRouter*`, `**/AppRouter*`, `**/RouterConfig*` in {web_root}
|
|
55
|
+
2. If not found: Grep for `<Route.*path=` to find where routes are defined
|
|
56
|
+
3. Also check: `App.tsx` for inline route definitions
|
|
57
|
+
|
|
58
|
+
**Record:**
|
|
59
|
+
- File path and total lines
|
|
60
|
+
- Route generation method (iterates API data, static JSX, hybrid)
|
|
61
|
+
- How components are resolved (from registry, inline import, direct reference)
|
|
62
|
+
- Whether ProtectedRoute wrapping is applied
|
|
63
|
+
- Handling of nested routes / outlets
|
|
64
|
+
- Loading state handling (Suspense, loader, etc.)
|
|
65
|
+
- Any hardcoded routes within the file (count and list them)
|
|
66
|
+
|
|
67
|
+
### 4. useRouteConfig
|
|
68
|
+
|
|
69
|
+
**Search strategy:**
|
|
70
|
+
1. Glob: `**/useRouteConfig*`, `**/useRoutes*`, `**/useNavigation*` in {web_root}
|
|
71
|
+
2. If not found: Grep for `fetch.*navigation\|fetch.*routes\|fetch.*menu` in hooks
|
|
72
|
+
3. If not found: Grep for `/api/navigation` or `/api/routes` in service files
|
|
73
|
+
|
|
74
|
+
**Record:**
|
|
75
|
+
- File path and total lines
|
|
76
|
+
- API endpoint called
|
|
77
|
+
- Data transformation (flat list, tree, maps)
|
|
78
|
+
- Return shape (routes, permissions, loading, error)
|
|
79
|
+
- Caching strategy (React Query, SWR, useState, context)
|
|
80
|
+
- When it re-fetches (auth change, mount only, interval)
|
|
81
|
+
|
|
82
|
+
### 5. Navigation API
|
|
83
|
+
|
|
84
|
+
**Search strategy (backend):**
|
|
85
|
+
1. Glob: `**/Navigation*Controller*` in {api_root}
|
|
86
|
+
2. Grep for `[HttpGet].*menu\|[HttpGet].*route\|[HttpGet].*navigation` in controllers
|
|
87
|
+
3. Also check: service files with Glob `**/NavigationService*` in {infra_root}
|
|
88
|
+
|
|
89
|
+
**Search strategy (frontend, as consumer):**
|
|
90
|
+
1. Grep for `/api/navigation` or `navigation/menu` in {web_root}/services/
|
|
91
|
+
|
|
92
|
+
**Record:**
|
|
93
|
+
- Controller file path, endpoint path, HTTP method
|
|
94
|
+
- Service file path (business logic)
|
|
95
|
+
- Response DTO structure (what fields are returned)
|
|
96
|
+
- Whether response is filtered by user permissions/JWT
|
|
97
|
+
- Whether ComponentKey is included in response
|
|
98
|
+
- Whether PermissionPath is included in response
|
|
99
|
+
- Feature gating support (RequiredFeature field)
|
|
100
|
+
|
|
101
|
+
---
|
|
102
|
+
|
|
103
|
+
### 6. Cross-reference with MCP Results
|
|
104
|
+
|
|
105
|
+
If `{mcp_results}` is available from step-00:
|
|
106
|
+
|
|
107
|
+
```
|
|
108
|
+
For componentRegistry:
|
|
109
|
+
- Compare manual key count with MCP componentRegistry.registeredKeys.length
|
|
110
|
+
- Note any missingKeys reported by MCP
|
|
111
|
+
- Flag if MCP found issues not visible from manual inspection
|
|
112
|
+
|
|
113
|
+
For Navigation API:
|
|
114
|
+
- Compare seed data routes (from MCP validate_conventions) with manual API analysis
|
|
115
|
+
- Note any backend routes with no frontend counterpart
|
|
116
|
+
|
|
117
|
+
For API clients:
|
|
118
|
+
- Use MCP apiClients.issues to enrich anti-pattern detection later (step-02)
|
|
119
|
+
- Record hardcoded paths found by MCP
|
|
120
|
+
```
|
|
121
|
+
|
|
122
|
+
### 7. Compile Inventory Table
|
|
123
|
+
|
|
124
|
+
After all 5 elements are investigated, compile:
|
|
125
|
+
|
|
126
|
+
```
|
|
127
|
+
## Element Inventory
|
|
128
|
+
|
|
129
|
+
| # | Element | Status | File | Lines | Key Characteristics |
|
|
130
|
+
|---|---------|--------|------|-------|-------------------|
|
|
131
|
+
| 1 | componentRegistry | FOUND/ABSENT | {path} | {n} | {summary} |
|
|
132
|
+
| 2 | ProtectedRoute | FOUND/ABSENT | {path} | {n} | {summary} |
|
|
133
|
+
| 3 | DynamicRouter | FOUND/ABSENT | {path} | {n} | {summary} |
|
|
134
|
+
| 4 | useRouteConfig | FOUND/ABSENT | {path} | {n} | {summary} |
|
|
135
|
+
| 5 | Navigation API | FOUND/ABSENT | {path} | {n} | {summary} |
|
|
136
|
+
|
|
137
|
+
MCP Cross-reference (if available):
|
|
138
|
+
| MCP Check | Issues Found | Aligned with Manual |
|
|
139
|
+
|-----------|-------------|-------------------|
|
|
140
|
+
| componentRegistry keys | {N missing} | {yes/no + detail} |
|
|
141
|
+
| API client paths | {N hardcoded} | {yes/no + detail} |
|
|
142
|
+
| Seed data sync | {N missing} | {yes/no + detail} |
|
|
143
|
+
|
|
144
|
+
-> Proceeding to conformity analysis...
|
|
145
|
+
```
|
|
146
|
+
|
|
147
|
+
---
|
|
148
|
+
|
|
149
|
+
## SUCCESS METRICS:
|
|
150
|
+
- All 5 elements searched with at least 2 search strategies each
|
|
151
|
+
- Exact file paths and line numbers recorded
|
|
152
|
+
- Key characteristics noted for each found element
|
|
153
|
+
- ABSENT elements confirmed after exhaustive search
|
|
154
|
+
- Inventory table displayed
|
|
155
|
+
|
|
156
|
+
## NEXT STEP:
|
|
157
|
+
After displaying inventory, proceed directly to `./step-02-conformity.md`
|