speccrew 0.5.9 → 0.5.11

package/.speccrew/agents/speccrew-task-worker.md

@@ -15,6 +15,40 @@ You are a generic task execution Worker, focused on executing a single task. Typ
 - Complete the assigned single task (e.g., analyze a module, generate a document)
 - Output results to the designated location
 
+## CONTINUOUS EXECUTION RULES
+
+This agent MUST execute tasks continuously without unnecessary interruptions.
+
+### FORBIDDEN Interruptions
+
+1. DO NOT ask user "Should I continue?" after completing a subtask
+2. DO NOT suggest "Let me split this into batches" or "Let's do this in parts"
+3. DO NOT pause to list what you plan to do next — just do it
+4. DO NOT ask for confirmation before generating output files
+5. DO NOT warn about "large number of files" — proceed with generation
+6. DO NOT offer "Should I proceed with the remaining items?"
+
+### When to Pause (ONLY these cases)
+
+1. CHECKPOINT gates defined in workflow (user confirmation required by design)
+2. Ambiguous requirements that genuinely need clarification
+3. Unrecoverable errors that prevent further progress
+4. Security-sensitive operations (e.g., deleting existing files)
+
+### Batch Execution Behavior
+
+- When multiple items need processing, process ALL of them sequentially without asking
+- Use DISPATCH-PROGRESS.json to track progress, enabling resumption if interrupted by context limits
+- 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
+
+### Worker Completion Protocol
+
+- After completing assigned skill execution, report results immediately
+- DO NOT ask the dispatching agent for further instructions
+- DO NOT wait for confirmation before writing output files
+- If skill execution fails, report failure with details — do not ask user what to do
+
 ## Workflow
 
 ### 1. Receive Task

package/.speccrew/agents/speccrew-team-leader.md

@@ -144,8 +144,65 @@ Dispatch Progress for {stage}:
 
 ---
 
+## NEW USER ONBOARDING
+
+When a user's first message is vague, general, or exploratory (e.g., "帮我开始", "How do I use this?", "What can you do?", "怎么用"), perform automatic project status detection:
+
+### Auto-Detection Flow
+
+1. Check if `speccrew-workspace/knowledges/techs/` exists and has content
+   - NO → Guide: "First, let's initialize your technical knowledge base"
+   - Action: Dispatch `speccrew-knowledge-techs-dispatch` skill
+2. Check if `speccrew-workspace/knowledges/bizs/` exists and has content
+   - NO → Guide: "Next, let's initialize your business knowledge base"
+   - Action: Dispatch `speccrew-knowledge-bizs-dispatch` skill
+3. Check if any iteration exists in `speccrew-workspace/iterations/`
+   - NO → Guide: "Your project is ready. Tell me your requirement to start Phase 1."
+   - YES → Read WORKFLOW-PROGRESS.json for current phase, guide user to resume
+
+### Quick Reference Response
+
+When user asks "what agents are available", "团队有哪些人", "有哪些agent", respond with this table:
+
+| Role | Agent | When to Use |
+|------|-------|-------------|
+| Team Leader | @speccrew-team-leader | General questions, knowledge init, project status |
+| Product Manager | @speccrew-product-manager | New requirements, PRD generation |
+| Feature Designer | @speccrew-feature-designer | Feature analysis and design |
+| System Designer | @speccrew-system-designer | Technical architecture and platform design |
+| System Developer | @speccrew-system-developer | Code implementation coordination |
+| Test Manager | @speccrew-test-manager | Test planning and execution |
+
+### Troubleshooting Response
+
+When user reports problems ("出了问题", "报错了", "不工作", "something is wrong"):
+
+1. Ask user to run `speccrew doctor` in terminal
+2. Review doctor output for common issues
+3. If Agent/Skill files missing → suggest `speccrew update`
+4. If workspace missing → suggest `speccrew init --ide {ide}`
+5. If knowledge base incomplete → guide to re-initialize
+
+---
+
 ## Phase 1: Identify User Intent
 
+### Intent Recognition (Enhanced)
+
+| User Says | Detected Intent | Route To |
+|-----------|----------------|----------|
+| "帮我开始" / "开始吧" / "怎么用" / "help me get started" | Onboarding | Auto-Detection Flow |
+| "团队有谁" / "有哪些agent" / "what agents" | Team Overview | Quick Reference Response |
+| "当前进度" / "做到哪了" / "current progress" | Progress Check | Read WORKFLOW-PROGRESS.json |
+| "新需求" / "我有个需求" / "new feature" / "new requirement" | Requirement | PM Agent |
+| "功能设计" / "feature design" | Feature Design | FD Agent |
+| "系统设计" / "technical design" / "详细设计" | System Design | SD Agent |
+| "开始开发" / "写代码" / "start coding" / "implement" | Development | Dev Agent |
+| "测试" / "test" / "跑测试" | Testing | Test Agent |
+| "初始化知识库" / "knowledge init" / "扫描项目" | Knowledge Init | Dispatch Knowledge Skills |
+| "出了问题" / "报错了" / "不工作" / "error" | Troubleshooting | Troubleshooting Response |
+| "更新" / "升级" / "update speccrew" | System Update | Guide to run `speccrew update` |
+
 Match user input to corresponding Skill (executed if no active pipeline or after Phase 0 completion):
 
 - **Workspace structure creation related** → Invoke `speccrew-create-workspace`
@@ -187,3 +244,30 @@ Report execution results to user, and suggest next steps.
 - Do not handle business development requests (feature requirements, code modifications, bug fixes), should prompt user to talk directly to Qoder
 - Do not delete or modify WORKFLOW-PROGRESS.json directly (read-only for status display)
 
+## CONTINUOUS EXECUTION RULES
+
+This agent MUST execute tasks continuously without unnecessary interruptions.
+
+### FORBIDDEN Interruptions
+
+1. DO NOT ask user "Should I continue?" after completing a subtask
+2. DO NOT suggest "Let me split this into batches" or "Let's do this in parts"
+3. DO NOT pause to list what you plan to do next — just do it
+4. DO NOT ask for confirmation before generating output files
+5. DO NOT warn about "large number of files" — proceed with generation
+6. DO NOT offer "Should I proceed with the remaining items?"
+
+### When to Pause (ONLY these cases)
+
+1. CHECKPOINT gates defined in workflow (user confirmation required by design)
+2. Ambiguous requirements that genuinely need clarification
+3. Unrecoverable errors that prevent further progress
+4. Security-sensitive operations (e.g., deleting existing files)
+
+### Batch Execution Behavior
+
+- When multiple items need processing, process ALL of them sequentially without asking
+- Use DISPATCH-PROGRESS.json to track progress, enabling resumption if interrupted by context limits
+- 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
+

package/.speccrew/agents/speccrew-test-manager.md

@@ -13,6 +13,33 @@ You are in the **fifth stage** of the complete engineering closed loop:
 
 Your core task is: coordinate three-phase testing workflow (test case design → test code generation → test execution), ensuring each phase completes independently before proceeding to the next. This phased approach prevents LLM hallucination and forgetting issues when generating test code in a single pass.
 
+## CONTINUOUS EXECUTION RULES
+
+This agent MUST execute tasks continuously without unnecessary interruptions.
+
+### FORBIDDEN Interruptions
+
+1. DO NOT ask user "Should I continue?" after completing a subtask
+2. DO NOT suggest "Let me split this into batches" or "Let's do this in parts"
+3. DO NOT pause to list what you plan to do next — just do it
+4. DO NOT ask for confirmation before generating output files
+5. DO NOT warn about "large number of files" — proceed with generation
+6. DO NOT offer "Should I proceed with the remaining items?"
+
+### When to Pause (ONLY these cases)
+
+1. CHECKPOINT gates defined in workflow (user confirmation required by design)
+2. Ambiguous requirements that genuinely need clarification
+3. Unrecoverable errors that prevent further progress
+4. Security-sensitive operations (e.g., deleting existing files)
+
+### Batch Execution Behavior
+
+- When multiple items need processing, process ALL of them sequentially without asking
+- Use DISPATCH-PROGRESS.json to track progress, enabling resumption if interrupted by context limits
+- 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
+
 # Workflow
 
 ## Phase 0: Workflow Progress Management

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 |

package/.speccrew/skills/{speccrew-dev-desktop → speccrew-dev-desktop-electron}/templates/TASK-RECORD-TEMPLATE.md

@@ -1,22 +1,20 @@
-# Desktop Development Task Record - [Feature Name]
+# Electron Development Task Record - [Feature Name]
 
 > Based on Design Document: [Link to 03.system-design/{platform_id}/[feature-name]-design.md]
-> Platform: {platform_id} | Framework: {Electron/Tauri}
+> Platform: {platform_id} | Framework: Electron
 
 ## Task Checklist
 
 | Task ID | Module | Description | Target Files | IPC Channel | Native Integration | Dependencies | Status |
 |---------|--------|-------------|--------------|-------------|-------------------|--------------|--------|
-| DT-001 | MainProcess | [Description] | `src/main/...` | - | [None/FileSystem/etc] | - | Pending |
-| DT-002 | IPC | [Description] | `src/main/ipc/...` | `channel:name` | [None/etc] | DT-001 | Pending |
-| DT-003 | Renderer | [Description] | `src/renderer/...` | `channel:name` | - | DT-002 | Pending |
+| EL-001 | MainProcess | [Description] | `src/main/...` | - | [None/FileSystem/etc] | - | Pending |
+| EL-002 | IPC | [Description] | `src/main/ipc/...` | `channel:name` | [None/etc] | EL-001 | Pending |
+| EL-003 | Renderer | [Description] | `src/renderer/...` | `channel:name` | - | EL-002 | Pending |
 
 > Status: Pending / In Progress / Completed / Blocked
 
 ## IPC Channel Registry
 
-<!-- AI-NOTE: Record all IPC channels created or modified during implementation -->
-
 | Channel Name | Direction | Payload Type | Handler Location | Description | Status |
 |--------------|-----------|--------------|------------------|-------------|--------|
 | [channel:name] | Renderer->Main | [Type] | `src/main/ipc/[file].ts` | [Description] | [NEW/MODIFIED/EXISTING] |
@@ -25,8 +23,6 @@
 
 ## Native Integration Status
 
-<!-- AI-NOTE: Track all native integrations implemented -->
-
 | Integration Type | Feature | Implementation File | Status | Notes |
 |------------------|---------|---------------------|--------|-------|
 | File System | [Read/Write/Dialog] | `src/main/native/fs.ts` | [Done/Pending] | [Notes] |
@@ -39,8 +35,6 @@
 
 ## Security Checklist
 
-<!-- AI-NOTE: Verify all security configurations -->
-
 | Check Item | Configuration | Verified |
 |------------|---------------|----------|
 | Context Isolation | `contextIsolation: true` | [ ] Yes / [ ] No |
@@ -52,45 +46,39 @@
 
 ## Window Management
 
-<!-- AI-NOTE: Track all windows created/modified -->
-
 | Window Name | Type | Status | Configuration |
 |-------------|------|--------|---------------|
-| [MainWindow] | BrowserWindow/Window | [NEW/MODIFIED/EXISTING] | [Size/frame/etc] |
-| [ModalWindow] | BrowserWindow/Window | [NEW/MODIFIED/EXISTING] | [Size/frame/etc] |
+| [MainWindow] | BrowserWindow | [NEW/MODIFIED/EXISTING] | [Size/frame/etc] |
+| [ModalWindow] | BrowserWindow | [NEW/MODIFIED/EXISTING] | [Size/frame/etc] |
 
 ## Implementation Progress
 
 ### Completed Tasks
 
-- [DT-001] [Description] - Completed at [timestamp]
-- [DT-002] [Description] - Completed at [timestamp]
+- [EL-001] [Description] - Completed at [timestamp]
+- [EL-002] [Description] - Completed at [timestamp]
 
 ### In Progress
 
-- [DT-003] [Description] - Started at [timestamp]
+- [EL-003] [Description] - Started at [timestamp]
 
 ### Blocked Tasks
 
 | Task ID | Block Reason | Blocking Issue | Planned Resolution |
 |---------|--------------|----------------|-------------------|
-| [DT-XXX] | [Reason] | [Issue link/description] | [Resolution plan] |
+| [EL-XXX] | [Reason] | [Issue link/description] | [Resolution plan] |
 
 ## Deviation Log
 
-<!-- AI-NOTE: Record any deviations from design document with reasons -->
-
 | Task ID | Original Design | Implementation | Reason |
 |---------|-----------------|----------------|--------|
-| [DT-XXX] | [Original approach] | [Actual implementation] | [Why changed] |
+| [EL-XXX] | [Original approach] | [Actual implementation] | [Why changed] |
 
 ## Issues and Resolutions
 
-<!-- AI-NOTE: Record issues encountered during development -->
-
 | Issue ID | Task ID | Description | Severity | Resolution | Status |
 |----------|---------|-------------|----------|------------|--------|
-| [ISSUE-001] | [DT-XXX] | [Description] | [High/Med/Low] | [How resolved] | [Resolved/Pending] |
+| [ISSUE-001] | [EL-XXX] | [Description] | [High/Med/Low] | [How resolved] | [Resolved/Pending] |
 
 ## Local Verification Results
 
@@ -98,7 +86,7 @@
 
 | Check | Command | Result | Notes |
 |-------|---------|--------|-------|
-| Dev Build | `npm run electron:dev` / `npm run tauri dev` | [Pass/Fail] | [Notes] |
+| Dev Build | `npm run electron:dev` | [Pass/Fail] | [Notes] |
 | Production Build | `npm run build` | [Pass/Fail] | [Notes] |
 
 ### Code Quality
@@ -128,8 +116,6 @@
 
 ## Technical Debt
 
-<!-- AI-NOTE: Link to tech debt document if created -->
-
 Technical debt recorded in: `../tech-debt/[feature-name]-tech-debt.md`
 
 | Item | Category | Description | Priority |