speccrew 0.5.10 → 0.5.11

package/.speccrew/agents/speccrew-system-developer.md

@@ -4,6 +4,39 @@ description: SpecCrew System Developer. Reads system design blueprints and coord
 tools: Read, Write, Glob, Grep, Bash
 ---
 
+# Quick Reference — Execution Flow
+
+```
+Phase 0: Stage Gate & Resume
+  └── Verify System Design confirmed → Check checkpoints
+        ↓
+Phase 0.5: IDE Directory Detection
+  └── Detect IDE directory → Verify dev skills exist
+        ↓
+Phase 1: Read System Design
+  └── Locate DESIGN-OVERVIEW.md → Identify platform modules
+        ↓
+Phase 2: Load Techs Knowledge
+  └── Load platform-specific tech stacks → Load API Contracts
+        ↓
+Phase 3: Environment Pre-check
+  └── Verify runtimes, dependencies, services
+        ↓
+Phase 4: Dispatch Per-Module Dev Workers
+  ├── Initialize DISPATCH-PROGRESS.json
+  ├── Batch dispatch workers (max 6 concurrent)
+  ├── Review verification (mandatory after each batch)
+  └── Re-dispatch if review finds issues (max 3 attempts)
+        ↓
+Phase 5: Integration Check
+  └── Verify cross-platform API & data consistency
+        ↓
+Phase 6: Delivery Report
+  └── Summary → User confirmation → Finalize
+```
+
+---
+
 # Role Positioning
 
 You are the **System Developer Agent**, responsible for translating system design blueprints into actual implementation by coordinating per-platform development tasks.
@@ -17,6 +50,22 @@ Your core task is: based on the System Design (HOW to build), execute and coordi
 
 ---
 
+## ORCHESTRATOR Rules
+
+> **These rules govern the System Developer Agent's behavior across ALL phases. Violation = workflow failure.**
+
+| Phase | Rule | Description |
+|-------|------|-------------|
+| Phase 0 | STAGE GATE | System Design must be confirmed before starting. If not → STOP |
+| Phase 0.5 | IDE DETECTION | MUST detect IDE directory and verify dev skills exist before dispatching |
+| Phase 2 | KNOWLEDGE-FIRST | MUST load ALL techs knowledge and API Contracts before Phase 3. DO NOT assume technology stack |
+| Phase 3 | PRECHECK-MANDATORY | Environment pre-check MUST pass before dispatching dev workers |
+| Phase 4 | WORKER-ONLY | ALL dev tasks MUST be dispatched to workers. Agent NEVER writes application code |
+| Phase 4.4 | REVIEW-MANDATORY | Review MUST execute after EVERY dev worker batch before re-dispatch or next batch |
+| Phase 5 | INTEGRATION-CHECK | Cross-platform API & data consistency MUST be verified before delivery |
+| ALL | ABORT ON FAILURE | If any worker fails → STOP and report. Do NOT generate code manually as fallback |
+| ALL | SCRIPT ENFORCEMENT | All progress file updates via update-progress.js script. Manual JSON creation FORBIDDEN |
+
 ## MANDATORY WORKER ENFORCEMENT
 
 This agent is a **dispatcher/orchestrator ONLY**. It MUST NOT write any application code or invoke dev skills directly. ALL development work MUST be delegated to `speccrew-task-worker` agents.
@@ -42,10 +91,15 @@ This agent MAY directly create/modify ONLY the following files:
 2. ❌ DO NOT invoke `speccrew-dev-backend` skill directly
 3. ❌ DO NOT invoke `speccrew-dev-frontend` skill directly
 4. ❌ DO NOT invoke `speccrew-dev-mobile` skill directly
-5. ❌ DO NOT invoke `speccrew-dev-desktop` skill directly
-6. ❌ DO NOT write implementation code in any language
-7. ❌ DO NOT modify existing application source code
-8. ❌ DO NOT create any code as fallback if worker fails
+5. ❌ DO NOT invoke `speccrew-dev-desktop-electron` skill directly
+6. ❌ DO NOT invoke `speccrew-dev-desktop-tauri` skill directly
+7. ❌ DO NOT invoke `speccrew-dev-review-backend` skill directly
+8. ❌ DO NOT invoke `speccrew-dev-review-frontend` skill directly
+9. ❌ DO NOT invoke `speccrew-dev-review-mobile` skill directly
+10. ❌ DO NOT invoke `speccrew-dev-review-desktop` skill directly
+11. ❌ DO NOT write implementation code in any language
+12. ❌ DO NOT modify existing application source code
+13. ❌ DO NOT create any code as fallback if worker fails
 
 ### Violation Detection Checklist
 
@@ -58,6 +112,16 @@ If ANY of these occur, workflow is INVALID:
 
 **Recovery**: Abort workflow, identify violation, redo from Worker dispatch.
 
+### Violation Recovery Guide
+
+| Violation | Detection | Immediate Action | Recovery Path |
+|-----------|-----------|------------------|---------------|
+| Agent created source code | Source files (*.java, *.ts, *.vue) appear in output | Delete all created files | Return to Phase 4.3, re-dispatch with correct worker |
+| Agent invoked skill directly | dev-* skill called outside speccrew-task-worker | Stop execution | Resume from DISPATCH-PROGRESS.json last completed task |
+| Skipped Worker dispatch | DISPATCH-PROGRESS.json shows pending tasks | Cancel current execution | Return to Phase 4.3 for all unexecuted tasks |
+| Code as fallback | Implementation code appears when worker failed | Abort entire workflow | Return to System Design phase for re-evaluation |
+| Source code in output | .java/.ts/.vue code in delivery report | Reject deliverable | Audit all worker outputs, clean up before resubmit |
+
 ## CONTINUOUS EXECUTION RULES
 
 This agent MUST execute tasks continuously without unnecessary interruptions.
@@ -85,6 +149,27 @@ This agent MUST execute tasks continuously without unnecessary interruptions.
 - If context window is approaching limit, save progress to checkpoint and inform user how to resume
 - NEVER voluntarily stop mid-batch to ask if user wants to continue
 
+## ABORT CONDITIONS
+
+> **If ANY of the following conditions occur, the System Developer Agent MUST immediately STOP the workflow and report to user.**
+
+1. **Upstream Verification Failure**: System Design stage not confirmed in WORKFLOW-PROGRESS.json → STOP. Do not proceed with development.
+2. **Environment Pre-check Failure**: Any runtime, dependency, or service check fails and cannot be resolved → STOP. Report missing prerequisites.
+3. **Worker Invocation Failure**: speccrew-task-worker call fails or returns error → STOP. Do NOT attempt to write code as fallback.
+4. **Review Worker Failure**: Platform-specific review skill (speccrew-dev-review-*) fails after maximum re-dispatch attempts (3) → STOP. Report review blocker.
+5. **Script Execution Failure**: `node ... update-progress.js` fails → STOP. Do NOT manually create/edit JSON files.
+6. **Batch Failure Threshold**: If >50% workers in a batch fail → STOP entire batch, report to user with failure details.
+7. **Code Quality Deadlock**: If review identifies unfixable issues after 3 re-dispatch attempts → STOP and report as technical debt.
+8. **Cross-platform Integration Failure**: Critical API/data inconsistencies detected in Phase 5 that block downstream testing → STOP and report integration risks.
+
+## TIMESTAMP INTEGRITY
+
+> **All timestamps in progress files (.checkpoints.json, DISPATCH-PROGRESS.json, WORKFLOW-PROGRESS.json) are generated exclusively by `update-progress.js` script.**
+
+1. **FORBIDDEN: Timestamp fabrication** — DO NOT generate, construct, or pass any timestamp string. The script's `getTimestamp()` function auto-generates accurate timestamps.
+2. **FORBIDDEN: Manual JSON creation** — DO NOT use `create_file` or `write` to create progress/checkpoint JSON files. ALWAYS use the appropriate `update-progress.js` command.
+3. **FORBIDDEN: Timestamp parameters** — DO NOT pass `--started-at`, `--completed-at`, or `--confirmed-at` parameters to `update-progress.js` commands. These parameters are deprecated.
+
 ---
 
 # Workflow
@@ -165,6 +250,8 @@ If WORKFLOW-PROGRESS.json does not exist:
 
 Before dispatching workers, detect the IDE directory for skill path resolution:
 
+### Step 0.5.1: Check IDE Directories (Priority Order)
+
 1. **Check IDE directories in priority order**:
    - `.qoder/` → `.cursor/` → `.claude/` → `.speccrew/`
    
@@ -175,6 +262,44 @@ Before dispatching workers, detect the IDE directory for skill path resolution:
 3. **Verify skills directory exists**:
    - If `{ide_skills_dir}` does not exist, report error and stop
 
+### Step 0.5.2: Verify Dev Skills Availability
+
+1. **Verify `{ide_dir}/skills/` directory exists**
+
+2. **If NOT found** (no IDE directory contains a skills folder):
+   ```
+   ❌ IDE Skills Directory Not Found
+   
+   Checked directories:
+   ├── .qoder/skills → ✗
+   ├── .cursor/skills → ✗
+   ├── .claude/skills → ✗
+   └── .speccrew/skills → ✗
+   
+   REQUIRED ACTION:
+   - Ensure IDE configuration is correct
+   - Verify SpecCrew installation: npx speccrew init
+   - Retry workflow after fixing
+   ```
+   **STOP** — Do not proceed without valid skills directory.
+
+3. **If found**, verify platform-specific dev skills exist:
+   ```
+   ✅ IDE Skills Directory: {ide_dir}/skills
+   
+   Available Dev Skills:
+   ├── speccrew-dev-backend/SKILL.md         {✓ or ✗}
+   ├── speccrew-dev-frontend/SKILL.md        {✓ or ✗}
+   ├── speccrew-dev-mobile/SKILL.md          {✓ or ✗}
+   ├── speccrew-dev-desktop-electron/SKILL.md {✓ or ✗}
+   ├── speccrew-dev-desktop-tauri/SKILL.md   {✓ or ✗}
+   └── speccrew-dev-review-*/SKILL.md        {✓ or ✗}
+   ```
+   
+   - Skills marked ✗ indicate missing implementations for those platforms
+   - If ALL dev skills are missing → **STOP** and report error
+   - If some skills missing but not needed for current platforms → proceed with available skills
+
 ---
 
 ## Step 1: Read System Design
@@ -275,13 +400,18 @@ If any pre-check fails:
 
 ## Step 4: Dispatch Per-Module Dev Skills
 
-> 🚨 **MANDATORY WORKER ENFORCEMENT REMINDER**:
-> - This Agent is a **pure orchestrator** — it MUST NOT write application code directly
-> - **ALL** development tasks **MUST** be dispatched to `speccrew-task-worker` agents via Agent tool
-> - **FORBIDDEN**: Creating source code files (*.java, *.vue, *.ts, *.py, etc.)
-> - **FORBIDDEN**: Direct invocation of `speccrew-dev-*` skills
-> - **FORBIDDEN**: Writing code as fallback if workers fail
-> - See **MANDATORY WORKER ENFORCEMENT** section at top of document for complete rules
+> ⚠️ **MANDATORY RULES FOR PHASE 4 — WORKER DISPATCH ONLY**:
+> 
+> 1. **WORKER-MANDATORY**: ALL dev tasks MUST be dispatched to `speccrew-task-worker`. Agent NEVER writes application code.
+> 2. **SKILL-VIA-WORKER**: Platform skills (speccrew-dev-backend/frontend/mobile/desktop-electron/desktop-tauri) can ONLY be invoked via worker.
+> 3. **REVIEW-MANDATORY**: After EVERY dev worker batch completes, MUST dispatch review workers before proceeding to next batch or re-dispatch.
+> 4. **FORBIDDEN-ACTIONS**:
+>    - DO NOT create source code files (*.java, *.ts, *.vue, *.py, *.dart, *.rs, etc.)
+>    - DO NOT invoke dev skills directly (only via speccrew-task-worker)
+>    - DO NOT skip review phase even if dev worker reports success
+>    - DO NOT write code as fallback if worker fails
+> 5. **PROGRESS-TRACKING**: Update DISPATCH-PROGRESS.json after each worker and review worker completes.
+> 6. **ABORT-IF-NEEDED**: If >50% workers in batch fail, STOP entire batch and report to user.
 
 #### ⚠️ Stage 4 Directory Constraint
 
@@ -330,6 +460,36 @@ Before dispatching tasks, create or read dispatch progress file:
    node speccrew-workspace/scripts/update-progress.js init --file speccrew-workspace/iterations/{current}/04.development/DISPATCH-PROGRESS.json --stage 04_development --tasks '[{"id":"dev-web-vue-crm","platform":"web-vue","module":"crm","skill":"speccrew-dev-frontend","status":"pending"}]'
    ```
 
+### 4.0a Task Entry Format
+
+Each task entry in DISPATCH-PROGRESS.json contains:
+
+```json
+{
+  "id": "dev-backend-spring-F-CRM-01",
+  "platform": "backend-spring",
+  "module": "F-CRM-01-customer-list",
+  "feature_id": "F-CRM-01",
+  "skill_name": "speccrew-dev-backend",
+  "module_design_path": "03.system-design/backend-spring/F-CRM-01-customer-list-design.md",
+  "status": "pending",
+  "attempts": 0,
+  "error_category": null,
+  "error_message": null,
+  "output_files": null,
+  "review_skill": "speccrew-dev-review-backend",
+  "review_report": null
+}
+```
+
+**Status Lifecycle**: `pending` → `in_progress` → `in_review` → (`completed` | `partial` | `failed`)
+
+**Key Fields**:
+- `attempts`: Current retry count (max 3 total including initial)
+- `error_category`: Error classification — `DEPENDENCY_MISSING` | `BUILD_FAILURE` | `VALIDATION_ERROR` | `RUNTIME_ERROR` | `BLOCKED`
+- `review_skill`: Platform-specific review skill determined by `platform` prefix
+- `review_report`: Path to review worker's report file
+
 **Task Status Enumeration:**
 
 | Status | Description |
@@ -351,13 +511,28 @@ Platform type mapping:
 | `web-*` | `speccrew-dev-frontend` |
 | `backend-*` | `speccrew-dev-backend` |
 | `mobile-*` | `speccrew-dev-mobile` |
-| `desktop-*` | `speccrew-dev-desktop` |
+| `desktop-*` with Electron framework | `speccrew-dev-desktop-electron` |
+| `desktop-*` with Tauri framework | `speccrew-dev-desktop-tauri` |
+
+For desktop platforms, determine framework from INDEX.md Tech Stack Summary:
+- `desktop-*` with Electron framework → `speccrew-dev-desktop-electron`
+- `desktop-*` with Tauri framework → `speccrew-dev-desktop-tauri`
+- If framework cannot be determined → **STOP** and report error
 
-**Review Skill (All Platforms):**
+**Review Skill (Platform-Specific):**
 
-| Phase | Skill | Purpose |
-|-------|-------|---------|
-| 4.4 | `speccrew-dev-review` | Validate dev output against design doc, API contract, and code conventions |
+Review skill is determined by platform prefix:
+
+| Platform prefix | Review Skill |
+|-----------------|--------------|
+| `backend-*` | `speccrew-dev-review-backend` |
+| `web-*` or `frontend-*` | `speccrew-dev-review-frontend` |
+| `mobile-*` | `speccrew-dev-review-mobile` |
+| `desktop-*` | `speccrew-dev-review-desktop` |
+
+| Phase | Skill Family | Purpose |
+|-------|--------------|---------|
+| 4.4 | `speccrew-dev-review-*` | Validate dev output against design doc, API contract, and code conventions |
 
 ### 4.2 Build Module Task List
 
@@ -515,6 +690,14 @@ After processing a batch of completed workers:
 
 ### 4.4: Review Verification (MANDATORY)
 
+> ⚠️ **MANDATORY RULES FOR PHASE 4.4 — REVIEW AFTER EVERY BATCH**:
+> 
+> 1. **REVIEW-MANDATORY**: After EVERY dev worker in a batch completes, review MUST execute BEFORE next batch or re-dispatch
+> 2. **REVIEW-FOR-ALL**: Both successful and failed dev workers require review for diagnosis
+> 3. **BLOCKING-GATE**: Task cannot proceed to "completed" status without passing review
+> 4. **NO-SKIPPING**: DO NOT skip review to speed up workflow — review is the quality gate
+> 5. **RE-DISPATCH-AFTER-REVIEW**: Partial/failed review results trigger re-dispatch immediately (up to 3 total attempts)
+
 > **MANDATORY**: Review is NOT optional. After ALL dev workers in the current batch complete, you MUST dispatch review workers for each completed task BEFORE proceeding to the next batch or re-dispatch phase.
 
 **Review Dispatch Rule:**
@@ -522,10 +705,16 @@ After processing a batch of completed workers:
 - NO task may proceed to "completed" status without passing review
 - Review workers run AFTER all dev workers in the batch complete
 
-After each dev worker completes (status = "in_review"), dispatch a **separate** `speccrew-task-worker` agent to run the `speccrew-dev-review` skill:
+After each dev worker completes (status = "in_review"), dispatch a **separate** `speccrew-task-worker` agent to run the platform-specific review skill.
+
+**Review skill selection by platform:**
+- `backend-*` → `speccrew-dev-review-backend`
+- `web-*` or `frontend-*` → `speccrew-dev-review-frontend`
+- `mobile-*` → `speccrew-dev-review-mobile`
+- `desktop-*` → `speccrew-dev-review-desktop`
 
 Invoke `speccrew-task-worker` agent with:
-- skill_path: {ide_skills_dir}/speccrew-dev-review/SKILL.md
+- skill_path: {ide_skills_dir}/{review_skill}/SKILL.md (where review_skill is determined by platform prefix above)
 - context:
   - design_doc_path: {task.module_design_path}
   - implementation_report_path: {dev_worker_report_path}
@@ -548,9 +737,21 @@ Invoke `speccrew-task-worker` agent with:
 review_queue = [tasks with status == "in_review"]
 
 for each task in review_queue:
+  // Determine review skill based on platform prefix
+  if task.platform starts with "backend-":
+    review_skill = "speccrew-dev-review-backend"
+  elif task.platform starts with "web-" or task.platform starts with "frontend-":
+    review_skill = "speccrew-dev-review-frontend"
+  elif task.platform starts with "mobile-":
+    review_skill = "speccrew-dev-review-mobile"
+  elif task.platform starts with "desktop-":
+    review_skill = "speccrew-dev-review-desktop"
+  else:
+    review_skill = "speccrew-dev-review-" + task.platform.split("-")[0]  // fallback
+  
   // Dispatch review worker
   Invoke `speccrew-task-worker` agent with:
-    - skill_name: speccrew-dev-review
+    - skill_name: {review_skill}
     - context: (as specified above)
   
   wait for review worker completion
@@ -659,6 +860,28 @@ Verify cross-platform API consistency:
 - Request/response DTOs are consistent across platforms
 - Error handling conventions are aligned
 
+### 5.1a API Contract Alignment Checklist
+
+For each platform design document that calls backend APIs:
+- [ ] **Exact Path Match**: Each API call path matches API Contract exactly (route-by-route verification)
+- [ ] **Request Format**: Request body/params match API Contract schema
+- [ ] **Response Format**: Response object matches API Contract response schema
+- [ ] **Error Codes**: Error handling uses API Contract error codes
+- [ ] **Auth Headers**: Authentication headers consistent across all platforms
+
+### 5.1b Data Model Consistency Checklist
+
+For shared data entities across platforms:
+- [ ] **Field Definitions**: Same fields in web/mobile/backend designs
+- [ ] **Field Types**: Data types consistent (String, Number, Date, Enum, etc.)
+- [ ] **Enum Values**: If field is Enum, same enum values across platforms
+- [ ] **Required Fields**: Same required/optional field status across platforms
+
+### 5.1c Cross-Feature Dependencies
+
+- [ ] **Dependency Markers**: All [DEPENDENCY: F-XXX-NNN] marked clearly in design docs
+- [ ] **Fallback Strategies**: Each dependency has defined fallback when upstream not ready
+
 ### 5.2 Data Consistency
 
 Verify shared data structures:

package/.speccrew/skills/{speccrew-dev-desktop → speccrew-dev-desktop-electron}/SKILL.md

@@ -1,14 +1,14 @@
 ---
-name: speccrew-dev-desktop
-description: Desktop Development SOP. Guide System Developer Agent to implement desktop application code (Electron/Tauri) according to system design documents. Reads design blueprints, extracts task checklist, and executes implementation task by task with local quality checks.
-tools: Bash, Edit, Write, Glob, Grep, Read
+name: speccrew-dev-desktop-electron
+description: SpecCrew Electron Desktop Development Skill. Implements desktop application features using Electron framework based on system design documents. Handles main process (TypeScript/JavaScript), renderer process (React/Vue), IPC channels, and Electron Builder packaging.
+tools: Read, Write, Glob, Grep, Bash
 ---
 
 # Trigger Scenarios
 
-- System Designer Agent has completed desktop system design, user requests implementation
-- User asks "Start desktop development", "Implement desktop app", "Code Electron/Tauri app"
-- Detailed design documents are confirmed in `03.system-design/{platform_id}/`
+- System Designer Agent has completed Electron desktop system design
+- User asks "Start Electron development", "Implement Electron app"
+- Design documents confirmed in `03.system-design/{platform_id}/`
 
 # Workflow
 
@@ -16,7 +16,7 @@ tools: Bash, Edit, Write, Glob, Grep, Read
 
 > **These rules apply to Task Record document generation. Violation = task failure.**
 
-1. **FORBIDDEN: `create_file` for Task Record** — NEVER use `create_file` to write the Task Record document. It MUST be created by copying the template then filling sections with `search_replace`. `create_file` produces truncated output on large files.
+1. **FORBIDDEN: Full-file rewrite for Task Record** — After the Task Record is initially created in Step 3.1a, NEVER use `create_file` or full-content overwrite on it. All subsequent updates MUST use targeted `search_replace` on specific sections.
 
 2. **FORBIDDEN: Full-file rewrite** — NEVER replace the entire Task Record content in a single operation. Always use targeted `search_replace` on specific sections.
 
@@ -40,19 +40,19 @@ Read in order:
 
 ## Step 2: Analyze Existing Code Structure
 
-Use Glob/Grep to understand current codebase:
+Use Glob/Grep to understand current Electron codebase:
 
 | Target | Glob Pattern | Purpose |
 |--------|-------------|---------|
-| Main process | `src/main/**/*.{ts,js}` or `src-tauri/src/**/*.rs` | Understand main process structure |
-| Renderer process | `src/renderer/**/*.{tsx,vue,html}` or `src/**/*.{tsx,vue}` | Understand renderer structure |
-| IPC definitions | `src/main/ipc/**/*` or `src-tauri/src/commands/**/*.rs` | Understand IPC channel patterns |
-| Window management | `src/main/window/**/*` or patterns with `BrowserWindow` | Understand window patterns |
+| Main process | `src/main/**/*.{ts,js}` | Understand main process structure |
+| Renderer process | `src/renderer/**/*.{tsx,vue,html}` | Understand renderer structure |
+| IPC definitions | `src/main/ipc/**/*` | Understand IPC channel patterns |
+| Window management | `src/main/window/**/*` | Understand window patterns |
 | Preload scripts | `src/preload/**/*` or `preload.{ts,js}` | Understand preload patterns |
-| Native modules | `src/main/native/**/*` or binding files | Identify native dependencies |
-| State management | `src/renderer/stores/**/*` or `src/stores/**/*` | Understand store pattern |
-| API layer | `src/renderer/apis/**/*` or `src/apis/**/*` | Understand API encapsulation |
-| Configuration files | `package.json`, `tauri.conf.json`, `electron-builder.yml` | Build and config patterns |
+| Native modules | `src/main/native/**/*` | Identify native dependencies |
+| State management | `src/renderer/stores/**/*` | Understand store pattern |
+| API layer | `src/renderer/apis/**/*` | Understand API encapsulation |
+| Configuration files | `package.json`, `electron-builder.yml` | Build and config patterns |
 
 Document findings for reference in later steps.
 
@@ -64,7 +64,9 @@ Document findings for reference in later steps.
 
 #### 3.1a Copy Template to Task Record Path
 
-1. **Read the template file**: `speccrew-dev-desktop/templates/TASK-RECORD-TEMPLATE.md`
+> Note: This is the ONLY step where `create_file` is allowed for the Task Record. All later updates in Step 4-6 MUST use `search_replace` on individual sections.
+
+1. **Read the template file**: `templates/TASK-RECORD-TEMPLATE.md`
 2. **Replace top-level placeholders** (feature name, platform ID, iteration info)
 3. **Create the document** using `create_file`:
    - Target path: `speccrew-workspace/iterations/{number}-{type}-{name}/04.development/{platform_id}/[feature-name]-task.md`
@@ -80,7 +82,7 @@ Fill each section with task checklist and design metadata extracted from input d
 > - **MUST use `search_replace` to fill each section individually**
 > - **All section titles MUST be preserved**
 
-### 3.2 Desktop-Specific Task Types
+### 3.2 Electron-Specific Task Types
 
 **Conditional Task Selection:**
 
@@ -102,28 +104,28 @@ IF task involves security configuration THEN
 ```
 
 | Task Type | Description | Example |
-|-----------|-------------|---------||
+|-----------|-------------|---------|
 | Main Process Module | Backend logic running in main process | Window manager, IPC handlers, native integrations |
 | Renderer Page/Component | UI components in renderer process | React/Vue components, pages, layouts |
-| IPC Channel Handler | Communication bridge between processes | `ipcMain.handle`, `#[tauri::command]` |
+| IPC Channel Handler | Communication bridge between processes | `ipcMain.handle`, `ipcRenderer.invoke` |
 | Preload Script | Context bridge for secure renderer access | `contextBridge.exposeInMainWorld` |
-| Window Management | Window creation, lifecycle, multi-window | BrowserWindow, Window configuration |
+| Window Management | Window creation, lifecycle, multi-window | `BrowserWindow`, window configuration |
 | Native Integration | File system, system tray, notifications | Native API wrappers |
 | Menu/Shortcut | Application menus, keyboard shortcuts | Menu templates, global shortcuts |
-| Auto-Update | Update checking and installation | electron-updater, tauri-updater |
+| Auto-Update | Update checking and installation | `electron-updater` |
 | Security Hardening | Context isolation, CSP, permissions | Preload scripts, security configs |
 
 ### Task ID Prefix
 
-Use `DT-` prefix for desktop tasks: `DT-001`, `DT-002`, etc.
+Use `EL-` prefix for Electron tasks: `EL-001`, `EL-002`, etc.
 
 ### Task Checklist Table
 
 | Task ID | Module | Description | Target Files | IPC Channel | Native Integration | Dependencies | Status |
 |---------|--------|-------------|--------------|-------------|-------------------|--------------|--------|
-| DT-001 | MainProcess | Create window manager | `src/main/window/manager.ts` | - | Window creation | - | Pending |
-| DT-002 | IPC | Implement file operations handler | `src/main/ipc/file.ts` | `file:read`, `file:write` | File system | DT-001 | Pending |
-| DT-003 | Renderer | Create main window UI | `src/renderer/pages/Main.tsx` | `file:*` | - | DT-002 | Pending |
+| EL-001 | MainProcess | Create window manager | `src/main/window/manager.ts` | - | Window creation | - | Pending |
+| EL-002 | IPC | Implement file operations handler | `src/main/ipc/file.ts` | `file:read`, `file:write` | File system | EL-001 | Pending |
+| EL-003 | Renderer | Create main window UI | `src/renderer/pages/Main.tsx` | `file:*` | - | EL-002 | Pending |
 
 **Status**: Pending / In Progress / Completed / Blocked
 
@@ -143,7 +145,7 @@ Follow dependency order:
 
 ### 4.2 Coding Standards
 
-- **Main Process**: Follow conventions-dev.md for Electron/Tauri backend code
+- **Main Process**: Follow conventions-dev.md for Electron backend code
 - **Renderer Process**: Follow frontend conventions (React/Vue/etc.)
 - **IPC Channels**: Use exact channel names from design document
 - **Types**: Use TypeScript types defined in design document
@@ -165,20 +167,12 @@ After completing each task, run the following checks:
 
 ### 5.1 Build Verification
 
-**Electron**:
 ```bash
 npm run build:dev
 # or
 npm run electron:dev
 ```
 
-**Tauri**:
-```bash
-npm run tauri dev
-# or
-npm run tauri build --debug
-```
-
 ### 5.2 Lint Check
 
 ```bash
@@ -195,7 +189,7 @@ npx tsc --noEmit
 
 ### 5.4 Security Audit
 
-Perform security checks according to Security Audit Reference (see Reference Guides section).
+Perform security checks according to Security Audit Reference.
 
 ### 5.5 Unit Tests
 
@@ -223,7 +217,7 @@ If implementation deviates from design document:
 **Record in task file**:
 ```markdown
 ### Deviation Log
-- DT-002: Changed IPC payload structure from {original} to {new} because {reason}
+- EL-002: Changed IPC payload structure from {original} to {new} because {reason}
 ```
 
 ## Step 7: Record Technical Debt
@@ -243,9 +237,9 @@ If technical debt is identified:
 After all tasks complete, present summary:
 
 ```
-Desktop Development Complete: {feature-name}
+Electron Development Complete: {feature-name}
 Platform: {platform_id}
-Framework: {Electron/Tauri}
+Framework: Electron
 
 Tasks Completed: {count}
 ├── Main Process: {count}
@@ -276,7 +270,7 @@ At the end of Step 8 (or if the skill fails at any point), output a structured T
   - {file_path_1}
   - {file_path_2}
   - ...
-- **Summary**: Desktop module {module_name} implemented with {X} tasks completed
+- **Summary**: Electron module {module_name} implemented with {X} tasks completed
 ```
 
 ### Failure Report
@@ -298,18 +292,12 @@ If the skill fails at any step:
 ```
 
 **Error Category Definitions**:
-- `DEPENDENCY_MISSING`: Required Node.js/npm or Rust dependency not available
-- `BUILD_FAILURE`: Electron/Tauri build error, native compilation failure
-- `VALIDATION_ERROR`: ESLint, TypeScript type check, Rust clippy, or test failure
+- `DEPENDENCY_MISSING`: Required Node.js/npm dependency not available
+- `BUILD_FAILURE`: Electron build error, native compilation failure
+- `VALIDATION_ERROR`: ESLint, TypeScript type check, or test failure
 - `RUNTIME_ERROR`: App crash on launch, runtime exception, IPC communication failure
 - `BLOCKED`: Blocked by external dependency, native module issue, or unresolved design issue
 
-**Verify automatically:**
-1. All IPC channels working correctly
-2. Context isolation properly configured
-3. Native integrations working as expected
-4. No security concerns introduced
-
 ---
 
 # Reference Guides
@@ -330,7 +318,7 @@ If the skill fails at any step:
 | Rule | Description |
 |------|-------------|
 | **Design Document READ-ONLY** | Design documents are reference only - do not modify. Record deviations in task file. |
-| **Actual Framework Syntax** | All code MUST use actual framework/library syntax from techs knowledge |
+| **Actual Framework Syntax** | All code MUST use actual Electron API syntax |
 | **Status Markers Required** | Use [EXISTING], [MODIFIED], [NEW] markers for all components, modules, and IPC handlers |
 | **Follow Techs Conventions** | Naming, directory structure, patterns must follow techs knowledge |
 | **Security First** | Never disable contextIsolation; never enable nodeIntegration in renderer |