@atlashub/smartstack-cli 3.43.0 → 3.45.0

package/templates/skills/apex/references/execution-layer1-rules.md

@@ -1,96 +0,0 @@
-# Layer 1: Execution Rules — Application + API + Seed Data
-
-> **Loaded by:** step-03-execute.md (section: Layer 1)
-> **Purpose:** Critical rules for Layer 1 execution — NavRoute, permissions, validators, code generation, frontend patterns.
-
----
-
-## NavRoute and Permission Kebab-Case (CRITICAL)
-
-**ALL NavRoute segments and permission codes MUST use kebab-case for multi-word identifiers.**
-
-Root cause (test-apex-007): Controllers had `[NavRoute("humanresources.employees")]` instead of `[NavRoute("human-resources.employees")]`. This mismatched seed data routes and permission codes, causing 404s and permission denials at runtime.
-
-**Rules:**
-- NavRoute: `human-resources.employees` (NEVER `humanresources.employees`)
-- Permissions: `human-resources.employees.read` (segments MATCH NavRoute exactly)
-- Seed data codes: `human-resources` (NEVER `humanresources`)
-- C# class names stay PascalCase (`HumanResourcesController`) — only route/permission strings use kebab-case
-- POST-CHECKs 41 + 48 validate this. Fix BEFORE committing.
-
----
-
-## Controller Route Attribute (BLOCKING)
-
-**Controllers with `[NavRoute]` must NOT have `[Route]` attribute.**
-
-Root cause (test-apex-007): ALL 7 controllers had BOTH `[Route("api/...")]` AND `[NavRoute("...")]`. In SmartStack, `[NavRoute]` resolves routes dynamically from Navigation entities in the database at startup. Having `[Route]` alongside causes route conflicts → all endpoints return 404.
-
-**Rules:**
-- `[NavRoute("app.module")]` is the ONLY route attribute needed on controllers
-- **FORBIDDEN:** `[Route("api/human-resources/employees")]` alongside `[NavRoute]`
-- **FORBIDDEN:** `[Route("api/[controller]")]` alongside `[NavRoute]`
-- If generating via MCP `scaffold_extension` with `navRoute` option → output is correct (NavRoute only)
-- If generating via `/controller` skill → verify NO `[Route]` is added
-- POST-CHECK 50 validates this. Fix BEFORE committing.
-
----
-
-## Validators DI Registration (CRITICAL)
-
-After creating validators, they MUST be registered in DI. Without registration, `[FromBody]` DTOs are never validated.
-
-```csharp
-In DependencyInjection.cs (or ServiceCollectionExtensions.cs):
-  services.AddValidatorsFromAssemblyContaining<Create{Entity}DtoValidator>();
-```
-
-POST-CHECK 46 validates this. If validators exist but no DI registration → BLOCKING.
-
----
-
-## Date Fields — Use DateOnly (CRITICAL)
-
-**ALL date-only fields in DTOs MUST use `DateOnly`, NEVER `string`.**
-
-Root cause (test-apex-007): WorkLog DTO had `string Date` instead of `DateOnly Date`. This causes: no date validation, inconsistent date formats, parsing errors.
-
-**Type mapping for DTOs:**
-
-| Domain type | DTO type | Example |
-|-------------|----------|---------|
-| `DateTime` | `DateTime` | `CreatedAt`, `UpdatedAt` |
-| Date-only field | `DateOnly` | `Date`, `StartDate`, `EndDate`, `BirthDate` |
-| `string` for date | **FORBIDDEN** | Never use `string` for dates |
-| `DateTime` for date-only | **Avoid** | Use `DateOnly` when no time component needed |
-
-POST-CHECK 47 validates this. If a DTO has `string` type for a property named `*Date*` → BLOCKING.
-
----
-
-## Code Generation (if entities have codePattern != "manual")
-
-For each entity with auto-generated code pattern (from feature.json or step-02 decisions):
-
-```
-1. Create CodePatternConfig for the entity (strategy, prefix, digits from codePattern)
-2. Register ICodeGenerator<TEntity> in DependencyInjection.cs (Infrastructure layer)
-   → See references/code-generation.md for DI registration pattern
-3. Update CreateDto: REMOVE Code property (auto-generated, not user-provided)
-4. Update CreateDtoValidator: REMOVE Code regex rule (not in DTO anymore)
-5. Update service CreateAsync: inject ICodeGenerator<TEntity>, call NextCodeAsync()
-   → Code is auto-generated BEFORE entity creation
-   → See references/code-generation.md for service integration pattern
-6. Keep Code in ResponseDto (returned to frontend after creation)
-7. Keep Code in UpdateDto ONLY if code is mutable (rare — discuss with user)
-```
-
-**CRITICAL:** If `codePattern.strategy == "manual"` (or no codePattern), keep the current behavior: Code stays in CreateDto, user provides it, validator has regex rule.
-
----
-
-## Sequential vs Parallel Execution
-
-**If economy_mode:** Execute each item from the plan sequentially using skills and MCP.
-
-**If NOT economy_mode:** See `references/agent-teams-protocol.md` for parallel team-based execution with exec-backend and exec-frontend teammates.

package/templates/skills/apex/references/initialization-challenge-flow.md

@@ -1,110 +0,0 @@
-# Initialization — Challenge Flow & Hierarchy Definition
-
-> **Loaded by:** step-00-init.md (sections 4-5)
-> **Purpose:** Detailed flow for challenging user hierarchy assumptions and defining the 4-level navigation structure.
-
----
-
-## Challenge Questions Reference
-
-> **Complete question templates with validation:**
-> Load `references/challenge-questions.md` for the actual YAML question blocks and validation logic.
-
----
-
-## 4-Level Navigation Hierarchy (BLOCKING RULE)
-
-SmartStack uses a **4-level navigation hierarchy:**
-- **Level 1: Application** — e.g., "HumanResources", "ProjectManagement"
-- **Level 2: Module** — e.g., "Employees", "Timesheet"
-- **Level 3: Section** — e.g., "List", "Dashboard", "Approval"
-- **Level 4: Resource** — e.g., "Export", "Settings" (optional)
-
-**BLOCKING RULE:** Every module MUST have at least one section. A module without sections produces an incomplete navigation tree, broken seed data, and missing frontend routes.
-
----
-
-## Step 4: Validate Application Level (4a)
-
-Load application question from `references/challenge-questions.md` section 4a.
-
-**If `{app_name}` was clearly inferred from the task description:**
-- Skip question, use inferred value
-
-**If unclear:**
-- Present question with best guess as recommended option
-- Options:
-  1. "Inferred app name (Recommended)" + description
-  2. "New application" + option to create
-  3. "Existing application" + option to select from scanned projects
-- If "New application": collect `{app_name}`, `{app_code}`, `{app_icon}`, `{app_labels}` (4 langs)
-- If "Existing application": scan `**/Seeding/Data/**/NavigationApplicationSeedData.cs` and present discovered apps
-
----
-
-## Step 4b: Validate Module Level
-
-Load module question from `references/challenge-questions.md` section 4b.
-
-**If `{module_code}` was clearly inferred:**
-- Skip question
-
-**If unclear:**
-- Present question with best guess(es) as options
-- Options:
-  1. "Inferred module code (Recommended)" + from task description
-  2. "Alternative suggestions" + based on keywords
-- User selects or enters custom value
-- Store as `{module_code}` (kebab-case)
-
----
-
-## Step 4c: Define Sections (MANDATORY — at least one)
-
-Load section questions from `references/challenge-questions.md` section 4c.
-
-**BLOCKING VALIDATION:** Sections list MUST contain at least one entry before proceeding.
-
-Infer section suggestions from:
-1. Task description (extract nouns/concepts that suggest functional sub-areas)
-2. PRD/feature.json if available (module.sections)
-3. Common patterns: "list" (default for simple CRUD), "dashboard", "settings", "reports"
-
-**Question format:**
-```yaml
-question: "What sections should the module '{module_code}' contain?
-           (Select at least one — use 'Other' to add custom sections)"
-options:
-  - label: "<inferred section 1>"
-    description: "Primary functional area based on module purpose"
-  - label: "<inferred section 2>"
-    description: "Secondary functional area"
-  - label: "<inferred section 3>"
-    description: "Additional area inferred from context"
-multiSelect: true
-```
-
-**Validation (BLOCKING):**
-```
-IF {sections}.length == 0:
-  DISPLAY: "Every module must have at least one section."
-  → Re-ask the sections question
-  → DO NOT proceed to next step
-```
-
-**Store for each section:**
-```yaml
-sections:
-  - code: "section-kebab"
-    labels: { fr: "...", en: "...", it: "...", de: "..." }
-    icon: "LucideIconName"
-    displayOrder: 10
-```
-
----
-
-## Delegate Mode Skip (if -d)
-
-When `/ralph-loop` invokes `/apex -d {prd_path}`, ALL hierarchy is extracted from the PRD file:
-- Skip sections 2-4 (no interactive questions)
-- Jump directly to section 3 (MCP verify)

package/templates/skills/apex/references/planning-layer-mapping.md

@@ -1,151 +0,0 @@
-# Planning — Layer Mapping, Skill Assignment, Parallelization Strategy
-
-> **Loaded by:** step-02-plan.md (sections 1-4)
-> **Purpose:** Map analyzed elements to layers, assign skills/MCP tools, and identify parallelization opportunities.
-
----
-
-## Map Changes to Layers
-
-For each element identified in step-01, assign to a SmartStack layer:
-
-| Layer | Category | Order |
-|-------|----------|-------|
-| 0 | Domain (entities, enums, exceptions) | Sequential |
-| 0 | Infrastructure - EF Configs | Sequential |
-| 0 | Infrastructure - Migration (BLOCKING) | Sequential |
-| 1 | Application (services, DTOs, validators) | Parallel |
-| 1 | API (controllers) | Parallel |
-| 1 | Infrastructure - Seed Data | Parallel |
-| 2 | Frontend (pages, components) | Parallel |
-| 2 | I18n (translations) | Parallel |
-| 3 | Tests | Sequential |
-
----
-
-## Entity Definition Template
-
-Each entity in the plan MUST include:
-
-```yaml
-Entity: {EntityName}
-  - tenantMode: strict | optional | scoped | none
-  - codePattern: auto-generated strategy (if applicable)
-  - fkFields: [{field, targetEntity}] (if applicable)
-  - acceptance criteria: [AC1, AC2, ...]
-```
-
-The `tenantMode` decision (from step-01) drives:
-- EF query filters
-- Seed data approach
-- API authorization
-
-See `smartstack-layers.md` for tenant mode seed data strategies.
-
----
-
-## Assign Skill/MCP per File
-
-For EACH file in the plan, specify HOW it will be created/modified.
-
-**Format:**
-
-```markdown
-| # | File | Action | Tool |
-|---|------|--------|------|
-| 1 | Domain/Entities/.../MyEntity.cs | create | MCP scaffold_extension |
-| 2 | Infrastructure/.../MyEntityConfiguration.cs | create | MCP scaffold_extension |
-| 3 | Migration | create | MCP suggest_migration + dotnet ef |
-```
-
----
-
-## Layer 0 — Domain + Infrastructure (sequential)
-
-| # | File | Action | Tool |
-|---|------|--------|------|
-| 1 | Domain/Entities/.../Entity.cs | create | MCP scaffold_extension |
-| 2 | Infrastructure/.../EntityConfiguration.cs | create | MCP scaffold_extension |
-| 3 | Infrastructure/Migrations/ | create | MCP suggest_migration + dotnet ef |
-
----
-
-## Layer 1 — Application + API + Seed Data (parallel)
-
-**Backend:** Application/API/Seed Data
-
-| # | File | Action | Tool |
-|---|------|--------|------|
-| 4 | Application/Services/.../Service.cs | create | MCP scaffold_extension |
-| 5 | Application/DTOs/.../Dto.cs | create | MCP scaffold_extension |
-| 6 | Api/Controllers/.../Controller.cs | create | /controller skill or MCP scaffold_extension |
-| 7 | Seeding/Data/NavigationApplicationSeedData.cs | create | Reference smartstack-layers.md (once per app) |
-| 7b | Seeding/Data/ApplicationRolesSeedData.cs | create | Reference smartstack-layers.md (once per app) |
-| 7c | Infrastructure/Services/CodeGeneration/ | create | Reference code-generation.md (per entity with codePattern != manual) |
-| 8 | Seeding/Data/.../NavigationModuleSeedData.cs | create | Reference core-seed-data.md (4 langs: fr, en, it, de) |
-| 8c | ↳ (same file) Section methods | add | Reference core-seed-data.md §2b (if sections exist) |
-| 8d | ↳ (same file) Resource methods | add | Reference core-seed-data.md §2b (if resources exist) |
-| 8b | Application/Authorization/Permissions.cs | create | MCP generate_permissions |
-| 9 | Seeding/Data/.../PermissionsSeedData.cs | create | MCP generate_permissions |
-| 10 | Seeding/Data/.../RolesSeedData.cs | create | Reference smartstack-layers.md |
-| 10b | Seeding/{App}SeedDataProvider.cs | create | Reference core-seed-data.md (IClientSeedDataProvider + DI) |
-
-**Frontend:** API Client, Routes, Pages, I18n
-
-| # | File | Action | Tool |
-|---|------|--------|------|
-| 11 | src/pages/{App}/{Mod}/ListPage.tsx | create | /ui-components skill |
-| 11b | src/pages/{App}/{Mod}/CreatePage.tsx | create | /ui-components skill (FK: EntityLookup) |
-| 11c | src/pages/{App}/{Mod}/EditPage.tsx | create | /ui-components skill (FK: EntityLookup) |
-| 11d | src/pages/{App}/{Mod}/{Section}Page.tsx | create | /ui-components skill (per section in `{sections}`) |
-| 11e | src/pages/{App}/{Mod}/{Section}DetailPage.tsx | create | /ui-components skill (per section) |
-| 12 | src/services/api/{module}Api.ts | create | MCP scaffold_api_client |
-| 13 | src/routes/{module}.tsx | create | MCP scaffold_routes |
-| 14 | src/i18n/locales/{lang}/{module}.json | create | Reference smartstack-frontend.md (4 languages) |
-
-**FK Field Guidance:** If step-01 identified `fkFields[]`, every Create/Edit page MUST use `EntityLookup` for those fields (see `smartstack-frontend.md` section 6). The corresponding backend GetAll endpoints (Layer 1) MUST support `?search=` parameter.
-
----
-
-## Layer 2b — Documentation (after frontend pages exist)
-
-| # | File | Action | Tool |
-|---|------|--------|------|
-| 14b | src/pages/docs/business/{app}/{module}/doc-data.ts | create | /documentation skill |
-| 14c | src/pages/docs/business/{app}/{module}/index.tsx | create | /documentation skill |
-
----
-
-## Layer 3 — Tests (sequential)
-
-| # | File | Action | Tool |
-|---|------|--------|------|
-| 15 | tests/.../EntityTests.cs | create | MCP scaffold_tests |
-| 16 | tests/.../ServiceTests.cs | create | MCP scaffold_tests |
-
----
-
-## Identify Parallelization (Agent Teams)
-
-If NOT economy_mode AND Layer 1 has both backend and frontend work:
-
-**Create agent teams to execute Layer 1 backend and frontend in parallel.**
-
-See `references/agent-teams-protocol.md` for team creation, teammate spawning, task coordination, and shutdown procedures.
-
----
-
-## Delegate Mode Fast Path
-
-When `/ralph-loop` invokes `/apex -d {prd_path}`, PRD tasks already define the scope:
-
-Map each PRD task to a layer based on `task.category`:
-- `domain` → Layer 0
-- `infrastructure` → Layer 0
-- `application` → Layer 1
-- `api` → Layer 1
-- `seedData` → Layer 1
-- `frontend` → Layer 2
-- `test` → Layer 3
-
-For each task: infer file_path, action, and tool from category. SKIP user checkpoint. Jump to "Estimated Commits" section.