speccrew 0.5.19 → 0.6.0

package/.speccrew/skills/speccrew-deploy-smoke-test/SKILL.md

@@ -0,0 +1,243 @@
+---
+name: speccrew-deploy-smoke-test
+description: Performs lightweight smoke testing against running application. Verifies core API endpoint reachability based on API Contract documents. Does NOT test business logic — only HTTP status code verification.
+tools: Read, Bash, Glob
+---
+
+# Trigger Scenarios
+
+- User requests to verify application is running correctly
+- Deploy Agent needs to validate deployment success
+- Post-deployment verification required
+
+# Input Parameters
+
+| Parameter | Required | Type | Description |
+|-----------|----------|------|-------------|
+| `platform_id` | Yes | string | Platform identifier |
+| `base_url` | No | string | Application base URL (e.g., `http://localhost:8080`). Required for `http` mode. |
+| `api_contract_paths` | No | string | Comma-separated paths to API Contract documents. Required for `http` mode. |
+| `iteration_path` | Yes | string | Current iteration directory path |
+| `test_mode` | No | string | Test method: `http` (default, for server apps), `process` (for client apps - verify process runs and exits cleanly), `log` (verify expected log output). Default: `http` |
+| `expected_exit_code` | No | string | Expected process exit code for `process` mode (default: `0`) |
+| `log_file` | No | string | Log file path for `log` mode verification |
+| `expected_log_patterns` | No | string | Comma-separated regex patterns expected in log for `log` mode (e.g., `"DB initialized,UI loaded"`) |
+| `process_name` | No | string | Process name or pattern to check (for `process` mode, e.g., `myapp.exe` or `MyApp`) |
+
+# Workflow
+
+### Test Strategy
+
+Based on `test_mode` parameter:
+
+**Mode: `http`** (default — for server/web applications)
+- Parse API Contract documents
+- curl each endpoint and verify HTTP status codes
+- Pass criteria: GET returns 200; POST/PUT/DELETE returns non-404
+
+**Mode: `process`** (for client/desktop applications)
+- Verify the application process is still running (not crashed)
+- If the app supports a CLI health check command, run it
+- Pass criteria: Process alive AND exit code matches `expected_exit_code` (if process has exited)
+- For GUI apps: Check process exists and has been running for at least 10 seconds without crash
+
+**Mode: `log`** (for log-based verification)
+- Read `log_file` content
+- Check for each pattern in `expected_log_patterns`
+- Pass criteria: ALL expected patterns found in log
+- Fail: Any pattern missing → report which patterns were not found
+- Example patterns for client with local DB:
+  - "Database migration completed" (DB initialized)
+  - "Application ready" (app started)
+  - "UI rendered" (UI loaded, for GUI apps)
+
+## Step 1: Parse API Contracts (HTTP Mode)
+
+Extract endpoints from API Contract documents:
+
+1. **Read each API Contract document**
+   - Split `api_contract_paths` by comma
+   - Read each document using Read tool
+
+2. **Extract endpoint list**
+   - Parse endpoints from contract:
+     - Method: GET, POST, PUT, DELETE, etc.
+     - Path: endpoint path (e.g., `/api/users`)
+     - Expected status code: from contract definition
+
+3. **Filter for core endpoints**
+   - Focus on core endpoints only
+   - For GET endpoints: test directly with full validation
+   - For POST/PUT/DELETE: only verify endpoint exists (expect 400/401/405 is acceptable, NOT 404)
+
+## Step 2: Execute Smoke Tests (HTTP Mode)
+
+Test each endpoint:
+
+1. **For each endpoint, execute curl command**
+   ```bash
+   curl -s -o /dev/null -w "%{http_code}" -X {METHOD} {base_url}{path}
+   ```
+
+2. **Record test results**
+   - Endpoint path
+   - HTTP method
+   - Expected status (or status range)
+   - Actual status code
+   - Pass/fail status
+
+3. **Handle connection errors**
+   - If curl fails to connect → mark as FAILED
+   - Report: "Cannot connect to {base_url}"
+
+## Step 2 (Alternative): Process Mode Verification
+
+For client/desktop applications:
+
+1. **Check process is still running**
+   - **Windows**:
+     ```powershell
+     tasklist /FI "IMAGENAME eq {process_name}" | findstr /I "{process_name}"
+     ```
+   - **Unix/Mac**:
+     ```bash
+     pgrep -f "{process_name}"
+     ```
+
+2. **Verify process stability**
+   - Record process start time
+   - Wait 10 seconds
+   - Check if process is still running (not crashed)
+   - If process has exited:
+     - Get exit code
+     - Compare with `expected_exit_code` (default: 0)
+
+3. **Record test results**
+   - Process name
+   - Status: RUNNING / EXITED
+   - Exit code (if exited)
+   - Uptime (if running)
+   - Pass/fail status
+
+## Step 2 (Alternative): Log Mode Verification
+
+For log-based smoke testing:
+
+1. **Read log file content**
+   - Use Read tool to read `log_file`
+   - If file not found → FAILED
+
+2. **Parse expected patterns**
+   - Split `expected_log_patterns` by comma
+   - Trim whitespace from each pattern
+
+3. **Check each pattern**
+   - For each pattern in expected patterns:
+     - **Windows**:
+       ```powershell
+       Select-String -Path "{log_file}" -Pattern "{pattern}"
+       ```
+     - **Unix/Mac**:
+       ```bash
+       grep -E "{pattern}" "{log_file}"
+       ```
+   - Record whether pattern was found
+
+4. **Record test results**
+   - Pattern name
+   - Found: YES/NO
+   - Pass/fail status
+
+5. **Report missing patterns**
+   - List all patterns not found
+   - Include context from log if available
+
+## Step 3: Evaluate Results
+
+Apply pass criteria:
+
+1. **GET endpoints**
+   - Pass: HTTP 200 or 301/302 (redirect)
+   - Fail: 404 or connection error
+
+2. **POST/PUT/DELETE endpoints**
+   - Pass: NOT 404 (any other status is acceptable for smoke test)
+   - Acceptable: 400 (bad request), 401 (unauthorized), 405 (method not allowed)
+   - Fail: 404 (not found)
+
+3. **Health endpoint**
+   - Pass: HTTP 200
+   - Fail: Any other status
+
+4. **Calculate pass rate**
+   - pass_rate = (passed_count / total_count) * 100
+
+## Step 4: Report Smoke Test Results
+
+Compile test results table:
+
+| Endpoint | Method | Expected | Actual | Status |
+|----------|--------|----------|--------|--------|
+| /api/users | GET | 200 | 200 | PASS |
+| /api/auth/login | POST | !404 | 401 | PASS |
+| /api/orders | GET | 200 | 404 | FAIL |
+
+# Task Completion Report
+
+## Success Report
+
+```
+## Task Completion Report
+- **Status**: SUCCESS
+- **Platform**: {platform_id}
+- **Base URL**: {base_url}
+- **Endpoints Tested**: {total_count}
+- **Pass Rate**: {pass_rate}%
+- **Passed**: {passed_count}
+- **Failed**: {failed_count}
+- **Test Results**:
+
+| Endpoint | Method | Expected | Actual | Status |
+|----------|--------|----------|--------|--------|
+| {endpoint_1} | {method} | {expected} | {actual} | PASS |
+| {endpoint_2} | {method} | {expected} | {actual} | PASS |
+| {endpoint_3} | {method} | {expected} | {actual} | FAIL |
+
+- **Summary**: Smoke test passed with {pass_rate}% success rate
+```
+
+## Failure Report
+
+```
+## Task Completion Report
+- **Status**: FAILED
+- **Platform**: {platform_id}
+- **Base URL**: {base_url}
+- **Endpoints Tested**: {total_count}
+- **Pass Rate**: {pass_rate}%
+- **Failed Endpoints**:
+  - {endpoint_1}: expected {expected}, got {actual}
+  - {endpoint_2}: expected {expected}, got {actual}
+- **Error Category**: {VALIDATION_ERROR | RUNTIME_ERROR}
+- **Error**: {detailed error description}
+- **Recovery Hint**: Verify application is running and API contracts are up to date
+```
+
+# Important Notes
+
+- **Smoke test is NOT integration testing** — it only verifies service availability and endpoint reachability
+- **Pass rate threshold** — If pass rate < 80% → FAILED
+- **Critical GET endpoints** — If any critical GET endpoint returns 404 → FAILED
+- **No business logic testing** — Smoke test does not validate request/response bodies or business rules
+- **Lightweight verification** — Designed for quick post-deployment validation
+
+# Key Rules
+
+| Rule | Description |
+|------|-------------|
+| **HTTP Status Only** | Only verify HTTP status codes, not response bodies |
+| **GET Endpoints** | Must return 200 or redirect (301/302) |
+| **Write Endpoints** | Any status except 404 is acceptable |
+| **80% Pass Rate** | Overall pass rate must be >= 80% |
+| **Critical GET 404** | Any critical GET endpoint returning 404 causes failure |
+| **Contract-Based** | Extract endpoints from API Contract documents |

package/.speccrew/skills/speccrew-deploy-startup/SKILL.md

@@ -0,0 +1,218 @@
+---
+name: speccrew-deploy-startup
+description: Starts the application in local/development environment and performs health check verification. Reports service URL and health status.
+tools: Read, Bash
+---
+
+# Trigger Scenarios
+
+- User requests to start the application for testing
+- Deploy Agent needs to verify application startup
+- Smoke test requires a running application instance
+
+# Input Parameters
+
+| Parameter | Required | Type | Description |
+|-----------|----------|------|-------------|
+| `platform_id` | Yes | string | Platform identifier |
+| `start_cmd` | Yes | string | Application start command from conventions-data (e.g., `java -jar target/app.jar`) |
+| `health_url` | No | string | Health check URL (e.g., `http://localhost:8080/actuator/health`). Required for `http` mode. |
+| `health_timeout` | No | string | Health check timeout, default 60s |
+| `project_root` | Yes | string | Absolute path to the project root directory |
+| `iteration_path` | Yes | string | Current iteration directory path |
+| `verification_mode` | No | string | Verification method: `http` (default, for server apps), `process` (for client/desktop apps), `log` (for apps with log output). Default: `http` |
+| `process_name` | No | string | Process name or pattern to check (for `process` mode, e.g., `myapp.exe` or `MyApp`) |
+| `log_file` | No | string | Path to application log file (for `log` mode) |
+| `success_pattern` | No | string | Regex pattern in log that indicates successful startup (for `log` mode, e.g., `"Application started"` or `"Ready"`) |
+
+# Workflow
+
+## Step 1: Start Application
+
+Launch the application in background:
+
+1. **Execute start_cmd in background via Bash**
+   - Working directory: `project_root`
+   - Command: `start_cmd`
+   - Use background execution (e.g., `nohup {start_cmd} > app.log 2>&1 &` on Unix)
+   - Capture the process PID
+
+2. **Record PID for cleanup**
+   - Store PID for later reference
+   - Log: "Application started with PID {pid}"
+
+3. **Wait for initial startup**
+   - Wait 5 seconds for application initialization
+   - Log: "Waiting for application to initialize..."
+
+## Step 2: Verification (Based on Mode)
+
+### Verification Strategy
+
+Based on `verification_mode` parameter:
+
+**Mode: `http`** (default — for server/web applications)
+- Poll `health_url` every 5 seconds using curl
+- Success: HTTP 200 response
+- Timeout: `health_timeout` seconds
+
+**Mode: `process`** (for desktop/mobile/client applications)
+- Check if process `process_name` is running
+- On Windows: `tasklist /FI "IMAGENAME eq {process_name}" | findstr /I "{process_name}"`
+- On Unix/Mac: `pgrep -f "{process_name}"`
+- Success: Process found and running
+- Timeout: `health_timeout` seconds (default 30s)
+
+**Mode: `log`** (for applications with log-based startup confirmation)
+- Monitor `log_file` for `success_pattern`
+- On Windows: `Select-String -Path "{log_file}" -Pattern "{success_pattern}"`
+- On Unix/Mac: `grep -m 1 "{success_pattern}" "{log_file}"`
+- Poll every 3 seconds
+- Success: Pattern found in log
+- Timeout: `health_timeout` seconds (default 60s)
+
+### Execution by Mode
+
+#### HTTP Mode (default)
+
+Poll health endpoint until success or timeout:
+
+1. **Calculate max attempts**
+   - timeout_seconds = parseInt(health_timeout) || 60
+   - max_attempts = timeout_seconds / 5
+   - attempt = 0
+
+2. **Poll health_url**
+   ```bash
+   curl -s -o /dev/null -w "%{http_code}" {health_url}
+   ```
+
+3. **Check response**
+   - HTTP 200 → Health check passed, continue to Step 3
+   - Other codes → Increment attempt, wait 5 seconds, retry
+
+4. **Timeout handling**
+   - If attempt >= max_attempts → FAILED with Error Category: RUNTIME_ERROR
+   - Report: "Health check timed out after {timeout_seconds}s"
+
+#### Process Mode (for client apps)
+
+Verify process is running:
+
+1. **Calculate max attempts**
+   - timeout_seconds = parseInt(health_timeout) || 30
+   - max_attempts = timeout_seconds / 3
+   - attempt = 0
+
+2. **Check process existence**
+   - **Windows**:
+     ```powershell
+     tasklist /FI "IMAGENAME eq {process_name}" | findstr /I "{process_name}"
+     ```
+   - **Unix/Mac**:
+     ```bash
+     pgrep -f "{process_name}"
+     ```
+
+3. **Check result**
+   - Process found → Verification passed, continue to Step 3
+   - Process not found → Increment attempt, wait 3 seconds, retry
+
+4. **Timeout handling**
+   - If attempt >= max_attempts → FAILED with Error Category: RUNTIME_ERROR
+   - Report: "Process verification timed out after {timeout_seconds}s - process {process_name} not found"
+
+#### Log Mode (for log-based verification)
+
+Monitor log file for success pattern:
+
+1. **Calculate max attempts**
+   - timeout_seconds = parseInt(health_timeout) || 60
+   - max_attempts = timeout_seconds / 3
+   - attempt = 0
+
+2. **Check log file for success_pattern**
+   - **Windows**:
+     ```powershell
+     Select-String -Path "{log_file}" -Pattern "{success_pattern}"
+     ```
+   - **Unix/Mac**:
+     ```bash
+     grep -m 1 "{success_pattern}" "{log_file}"
+     ```
+
+3. **Check result**
+   - Pattern found → Verification passed, continue to Step 3
+   - Pattern not found → Increment attempt, wait 3 seconds, retry
+
+4. **Timeout handling**
+   - If attempt >= max_attempts → FAILED with Error Category: RUNTIME_ERROR
+   - Report: "Log verification timed out after {timeout_seconds}s - pattern '{success_pattern}' not found in {log_file}"
+
+## Step 3: Report Startup Status
+
+Compile and report startup results:
+
+1. **Record service information**
+   - Service URL: derived from `health_url` (remove `/actuator/health` if present)
+   - Health status: UP / DOWN
+   - Startup duration: time from start to health success
+   - PID: process ID for cleanup
+
+2. **Verify application is still running**
+   - Check if process with recorded PID exists
+   - If not running → FAILED with Error Category: RUNTIME_ERROR
+
+# Task Completion Report
+
+## Success Report
+
+```
+## Task Completion Report
+- **Status**: SUCCESS
+- **Platform**: {platform_id}
+- **Project Root**: {project_root}
+- **Service URL**: {service_url}
+- **Health URL**: {health_url}
+- **Health Status**: UP
+- **Startup Duration**: {duration_seconds}s
+- **Process ID (PID)**: {pid}
+- **Start Command**: {start_cmd}
+- **Summary**: Application started successfully and passed health check
+```
+
+## Failure Report
+
+```
+## Task Completion Report
+- **Status**: FAILED
+- **Platform**: {platform_id}
+- **Project Root**: {project_root}
+- **Start Command**: {start_cmd}
+- **Health URL**: {health_url}
+- **Error Category**: {DEPENDENCY_MISSING | RUNTIME_ERROR}
+- **Error**: {detailed error description}
+- **Startup Log** (last 30 lines):
+```
+{last_30_lines_of_application_log}
+```
+- **Recovery Hint**: {suggestion for resolving the issue}
+```
+
+# Important Notes
+
+- **Application runs in BACKGROUND** — it must remain running for subsequent smoke test
+- **PID must be reported** — the Deploy Agent uses this for cleanup later
+- **Health check uses curl** — cross-platform availability may vary; ensure curl is available
+- **Default timeout is 60s** — adjust health_timeout parameter for slower-starting applications
+- **Process monitoring** — verify the application process is still running after health check
+
+# Key Rules
+
+| Rule | Description |
+|------|-------------|
+| **Background Execution** | Application must start in background and continue running |
+| **PID Recording** | Always record and report the process PID |
+| **Health Polling** | Poll health endpoint every 5 seconds until success or timeout |
+| **Timeout Configurable** | health_timeout parameter controls maximum wait time |
+| **Process Verification** | Verify application process is still running after health check |

package/.speccrew/skills/speccrew-dev-backend/SKILL.md

@@ -117,7 +117,7 @@ Execute tasks in dependency order.
 
 1. **Mark task as 🔄 In Progress**
 2. **Implement the code** following design specification
-3. **Run local checks** (Step 5)
+3. **Run local checks** (Step 6)
 4. **Update status to ✅ Complete** if checks pass
 5. **Record deviations** if implementation differs from design
 
@@ -127,7 +127,33 @@ Execute tasks in dependency order.
 - Describe issue clearly to user
 - Wait for user decision: return to design phase OR proceed with documented deviation
 
-## Step 5: Local Checks
+## Step 5: Database Migration Verification
+
+> This step applies ONLY when the task checklist contains Database Migration tasks.
+> If no migration tasks exist, skip to Step 6.
+
+### 5.1 Verify Migration Scripts
+
+After all migration-related tasks in Step 4 are complete:
+
+1. **Check script existence**: Verify all migration scripts listed in the design document's "Migration Requirements" table have been created at the specified paths
+2. **Check naming convention**: Verify script names follow the pattern defined in conventions-data.md Migration Configuration
+3. **Check script content**: Each script must contain valid SQL/DDL (or tool-specific syntax) that matches the Table Schema defined in the design document
+
+### 5.2 Verify Migration Order
+
+1. **Dependency check**: Migration scripts with table dependencies must be ordered correctly (e.g., referenced table created before foreign key table)
+2. **Version sequence**: Migration version numbers must be sequential with no gaps
+
+### 5.3 Report Migration Summary
+
+Add to the task record:
+
+| Script Name | Path | Type | Tables Affected | Status |
+|-------------|------|------|----------------|--------|
+| {name} | {path} | CREATE/ALTER | {tables} | Created/Verified |
+
+## Step 6: Local Checks
 
 After completing each task, run quality checks:
 
@@ -155,7 +181,7 @@ When task is blocked (compile fail, test fail, env issue):
 3. **Check environment**: `.env` variables, database connectivity
 4. **Record diagnosis**: symptom → investigation steps → root cause → resolution
 
-## Step 6: Record Deviations
+## Step 7: Record Deviations
 
 If implementation differs from design, record in task file "Deviation Log" section:
 
@@ -167,7 +193,7 @@ If implementation differs from design, record in task file "Deviation Log" secti
 | BE-003 | Use JWT library A | Used JWT library B | Library A has security vulnerability |
 ```
 
-## Step 7: Handle Technical Debt
+## Step 8: Handle Technical Debt
 
 If accepting suboptimal solutions, write to tech-debt directory:
 
@@ -175,7 +201,7 @@ If accepting suboptimal solutions, write to tech-debt directory:
 
 Use the unified tech_debt document template defined in the workspace document templates configuration.
 
-## Step 8: Completion Notification
+## Step 9: Completion Notification
 
 When all tasks complete, update task record and notify user:
 
@@ -205,7 +231,7 @@ Ready for testing phase.
 
 ## Task Completion Report
 
-At the end of Step 8 (or if the skill fails at any point), output a structured Task Completion Report:
+At the end of Step 9 (or if the skill fails at any point), output a structured Task Completion Report:
 
 ### Success Report
 
@@ -219,6 +245,9 @@ At the end of Step 8 (or if the skill fails at any point), output a structured T
   - {file_path_1}
   - {file_path_2}
   - ...
+- **Migration Scripts**: {count} scripts at {migration_dir}
+  - {script_1_name}: {type} ({tables})
+  - {script_2_name}: {type} ({tables})
 - **Summary**: Backend module {module_name} implemented with {X} tasks completed
 ```
 

package/.speccrew/skills/speccrew-knowledge-techs-generate/templates/CONVENTIONS-DATA-TEMPLATE.md

@@ -111,6 +111,24 @@ erDiagram
 
 ### Migration Patterns
 
+#### Migration Configuration
+
+<!-- AI-TAG: MIGRATION_CONFIG -->
+<!-- Backend only. Extract from project's actual migration setup. -->
+
+| Config Item | Value |
+|-------------|-------|
+| Migration Tool | migration_tool (e.g., Flyway / Liquibase / Alembic / Prisma Migrate / TypeORM migrations / Knex migrations) |
+| Script Language | script_language (e.g., SQL / XML / YAML / TypeScript / Python) |
+| Script Directory | migration_script_dir (e.g., `src/main/resources/db/migration/`) |
+| Naming Convention | migration_naming (e.g., `V{version}__{description}.sql` for Flyway) |
+| Seed Data Directory | seed_data_dir (e.g., `src/main/resources/db/seed/`, or "N/A" if not used) |
+| Seed Data Format | seed_data_format (e.g., SQL INSERT / JSON fixtures / CSV) |
+| Execution Command | migration_run_cmd (e.g., `mvn flyway:migrate` / `npx prisma migrate dev`) |
+| Validation Command | migration_validate_cmd (e.g., `mvn flyway:validate` / `npx prisma migrate diff`) |
+
+#### Migration Workflow
+
 <!-- AI-TAG: MIGRATION_PATTERNS -->
 <!-- Backend only. If this platform is frontend or mobile, write 'Not applicable - database operations are handled at the backend layer.' -->
 
@@ -128,6 +146,23 @@ TestMigration --> ApplyMigration["Apply to Production"]
 - [{{name}}](file://{{path}}#L{{start}}-L{{end}})
 {{/each}}
 
+#### Deployment Configuration
+
+<!-- AI-TAG: DEPLOYMENT_CONFIG -->
+<!-- Backend only. Extract from project's actual deployment/startup setup. -->
+
+| Config Item | Value |
+|-------------|-------|
+| Build Command | build_cmd (e.g., `mvn package -DskipTests` / `npm run build`) |
+| Start Command | start_cmd (e.g., `java -jar target/app.jar` / `npm start`) |
+| Health Check URL | health_url (e.g., `http://localhost:8080/actuator/health`) |
+| Health Check Timeout | health_timeout (e.g., 30s) |
+| Stop Command | stop_cmd (e.g., `kill $PID` / Ctrl+C) |
+| Verification Mode | verification_mode (e.g., `http` for server, `process` for desktop/mobile, `log` for log-based) |
+| Process Name | process_name (e.g., `MyApp.exe` / `com.example.myapp`, for process mode. "N/A" for server) |
+| Log File Path | log_file_path (e.g., `logs/app.log` / `~/Library/Logs/MyApp.log`, for log mode. "N/A" if not applicable) |
+| Success Log Pattern | success_log_pattern (e.g., `"Application started"` / `"Ready"`, for log mode. "N/A" if not applicable) |
+
 ### Query Optimization
 
 <!-- AI-TAG: QUERY_OPTIMIZATION -->

package/.speccrew/skills/speccrew-sd-backend/templates/SD-BACKEND-TEMPLATE.md

@@ -132,9 +132,12 @@ flowchart TD
 
 ### 4.4 Migration Requirements
 
-| Migration | Type | Description |
-|-----------|------|-------------|
-| {migration-name} | CREATE TABLE/ALTER TABLE/ADD INDEX | {what changes} |
+<!-- AI-NOTE: File Path and Script Name MUST follow the migration naming convention 
+     and script directory defined in conventions-data.md Migration Configuration -->
+
+| Migration | Type | Script Name | File Path | Description |
+|-----------|------|-------------|-----------|-------------|
+| {migration-name} | CREATE TABLE/ALTER TABLE/ADD INDEX | {e.g., V001__create_user.sql} | {e.g., src/main/resources/db/migration/} | {what changes} |
 
 ## 5. Transaction Design
 

package/.speccrew/skills/speccrew-test-case-design/SKILL.md

@@ -260,7 +260,7 @@ For any uncovered acceptance criteria:
 
 **Test Case Design Document:**
 ```
-speccrew-workspace/iterations/{number}-{type}-{name}/05.tests/cases/[feature-name]-test-case-design.md
+speccrew-workspace/iterations/{number}-{type}-{name}/06.system-test/cases/[feature-name]-test-case-design.md
 ```
 
 ### 7.2 Read Template
@@ -334,7 +334,7 @@ Upon completion (success or failure), output the following report format:
 - **Platform**: <platform_id, e.g., "web-vue">
 - **Phase**: test_case_design
 - **Output Files**:
-  - `speccrew-workspace/iterations/{iteration}/05.system-test/cases/{platform_id}/[feature]-test-cases.md`
+  - `speccrew-workspace/iterations/{iteration}/06.system-test/cases/{platform_id}/[feature]-test-cases.md`
 - **Summary**: Test case design completed with {count} test cases covering {dimensions} dimensions
 ```
 

package/.speccrew/skills/speccrew-test-code-gen/SKILL.md

@@ -307,7 +307,7 @@ Output the code plan document for traceability:
 1. **Read the template**: `templates/TEST-CODE-PLAN-TEMPLATE.md`
 2. **Replace top-level placeholders** (feature name, platform, date, etc.)
 3. **Create the document** using `create_file`:
-   - Target path: `speccrew-workspace/iterations/{number}-{type}-{name}/05.system-test/code/{platform_id}/[feature]-test-code-plan.md`
+   - Target path: `speccrew-workspace/iterations/{number}-{type}-{name}/06.system-test/code/{platform_id}/[feature]-test-code-plan.md`
    - Content: Template with top-level placeholders replaced
 4. **Verify**: Document has complete section structure
 
@@ -376,7 +376,7 @@ Upon completion (success or failure), output the following report format:
 - **Platform**: <platform_id, e.g., "web-vue">
 - **Phase**: test_code_gen
 - **Output Files**:
-  - `speccrew-workspace/iterations/{iteration}/05.system-test/code/{platform_id}/[feature]-test-code-plan.md`
+  - `speccrew-workspace/iterations/{iteration}/06.system-test/code/{platform_id}/[feature]-test-code-plan.md`
   - <list of generated test source files>
 - **Summary**: Test code generation completed with {file_count} files covering {case_count} test cases
 ```

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "speccrew",
-  "version": "0.5.19",
+  "version": "0.6.0",
   "description": "Spec-Driven Development toolkit for AI-powered IDEs",
   "author": "charlesmu99",
   "repository": {

package/workspace-template/docs/solutions/agent-knowledge-map.md

@@ -180,8 +180,8 @@ Backend Designer Agent:
 
 | Deliverable | Path | Format | Description |
 |-------------|------|--------|-------------|
-| Test Case Document | `iterations/iXXX/05.tests/cases/[feature-name]-test-cases.md` | Per template | Includes acceptance and unit tests |
-| Test Report | `iterations/iXXX/05.tests/reports/[feature-name]-test-report.md` | Structured report | Includes pass rate, failure details |
+| Test Case Document | `iterations/iXXX/06.system-test/cases/[feature-name]-test-cases.md` | Per template | Includes acceptance and unit tests |
+| Test Report | `iterations/iXXX/06.system-test/reports/[feature-name]-test-report.md` | Structured report | Includes pass rate, failure details |
 
 ---
 
@@ -204,7 +204,8 @@ knowledge/                          iterations/iXXX/
 │                                         ├── 04.development/
 │                                         │ ├── {platform_id}/ ←── Dev Agent output (frontend/backend/mobile/desktop)
 │                Dev Agent                              │
-│                                         └── 05.tests/
+│                                         ├── 05.deployment/
+│                                         └── 06.system-test/
 └── techs/conventions/testing.md        ├── cases/    ←── Test Agent output
                    Test Agent ────────────────── └── reports/
 ```