feat: add dual-mode support to test-fix-gen workflow

Enable test generation for existing codebases without requiring prior
workflow session. Supports both session-based (WFS-xxx) and prompt-based
(text description or file path) inputs with automatic mode detection.

Key improvements:
- Prompt mode: Generate tests from feature description or requirements file
- Backward compatible: Existing session-based usage unchanged
- Flexible input: Accepts session ID, text description, or file path
- Use case: Testing existing APIs without workflow history

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>
This commit is contained in:
catlog22
2025-10-17 22:20:01 +08:00
parent c27e7f9cfb
commit b65cd49444
5 changed files with 158 additions and 17 deletions

View File

@@ -284,10 +284,22 @@ codex exec "CONTINUE TO NEXT SUBTASK: ..." resume --last --skip-git-repo-check -
1. Mark subtask as blocked in TodoWrite 1. Mark subtask as blocked in TodoWrite
2. Report error details to user 2. Report error details to user
3. Pause execution for manual intervention 3. Pause execution for manual intervention
4. User can choose to: 4. Use AskUserQuestion for recovery decision:
- Retry current subtask
- Continue to next subtask ```typescript
- Abort entire task AskUserQuestion({
questions: [{
question: "Codex execution failed for the subtask. How should the workflow proceed?",
header: "Recovery",
options: [
{ label: "Retry Subtask", description: "Attempt to execute the same subtask again." },
{ label: "Skip Subtask", description: "Continue to the next subtask in the plan." },
{ label: "Abort Workflow", description: "Stop the entire execution." }
],
multiSelect: false
}]
})
```
**Git Verification Failure** (if --verify-git): **Git Verification Failure** (if --verify-git):
1. Show unexpected changes 1. Show unexpected changes

View File

@@ -121,9 +121,22 @@ Claude (orchestrating AI) synthesizes both outputs:
### Phase 3: User Review and Iteration ### Phase 3: User Review and Iteration
1. **Present Synthesis**: Show synthesized plan and key discussion points 1. **Present Synthesis**: Show synthesized plan and key discussion points
2. **Continue or Conclude**: Prompt user: 2. **Continue or Conclude**: Use AskUserQuestion to prompt user:
- **(1)** Start another round of discussion
- **(2)** Conclude and finalize the plan ```typescript
AskUserQuestion({
questions: [{
question: "Round of discussion complete. What is the next step?",
header: "Next Round",
options: [
{ label: "Start another round", description: "Continue the discussion to refine the plan further." },
{ label: "Conclude and finalize", description: "End the discussion and save the final plan." }
],
multiSelect: false
}]
})
```
3. **Loop or Finalize**: 3. **Loop or Finalize**:
- Continue → New round with Gemini analyzing latest synthesis - Continue → New round with Gemini analyzing latest synthesis
- Conclude → Save final synthesized document - Conclude → Save final synthesized document

View File

@@ -68,7 +68,21 @@ Define subtasks manually (remaining capacity: 4 tasks):
- "User authentication" and "OAuth integration" both handle auth - "User authentication" and "OAuth integration" both handle auth
- Consider combining into single task - Consider combining into single task
Proceed with breakdown? (y/n): y # Use AskUserQuestion for confirmation
AskUserQuestion({
questions: [{
question: "File conflicts and/or similar functionality detected. How do you want to proceed?",
header: "Confirm",
options: [
{ label: "Proceed with breakdown", description: "Accept the risks and create the subtasks as defined." },
{ label: "Restart breakdown", description: "Discard current subtasks and start over." },
{ label: "Cancel breakdown", description: "Abort the operation and leave the parent task as is." }
],
multiSelect: false
}]
})
User selected: "Proceed with breakdown"
✅ Task IMPL-1 broken down: ✅ Task IMPL-1 broken down:
▸ IMPL-1: Build authentication module (container) ▸ IMPL-1: Build authentication module (container)

View File

@@ -174,7 +174,20 @@ Rollback to version 1.1:
- Remove new subtasks if any - Remove new subtasks if any
- Update session stats - Update session stats
Confirm rollback? (y/n): y # Use AskUserQuestion for confirmation
AskUserQuestion({
questions: [{
question: "Are you sure you want to roll back this task to a previous version?",
header: "Confirm",
options: [
{ label: "Yes, rollback", description: "Restore the task from the selected backup." },
{ label: "No, cancel", description: "Keep the current version of the task." }
],
multiSelect: false
}]
})
User selected: "Yes, rollback"
✅ Task rolled back to version 1.1 ✅ Task rolled back to version 1.1
``` ```
@@ -227,7 +240,20 @@ Proposed updates:
+ Add OAuth2 integration + Add OAuth2 integration
+ Update authentication flow + Update authentication flow
Apply changes? (y/n): y # Use AskUserQuestion for confirmation
AskUserQuestion({
questions: [{
question: "Do you want to apply these changes to the task?",
header: "Apply",
options: [
{ label: "Yes, apply", description: "Create new version with these changes." },
{ label: "No, cancel", description: "Discard changes and keep current version." }
],
multiSelect: false
}]
})
User selected: "Yes, apply"
✓ Version 1.2 created ✓ Version 1.2 created
✓ Context updated ✓ Context updated

View File

@@ -1,7 +1,7 @@
--- ---
name: test-fix-gen name: test-fix-gen
description: Create independent test-fix workflow session by analyzing completed implementation description: Create independent test-fix workflow session from existing implementation (session or prompt-based)
argument-hint: "[--use-codex] [--cli-execute] source-session-id" argument-hint: "[--use-codex] [--cli-execute] (source-session-id | \"feature description\" | /path/to/file.md)"
allowed-tools: SlashCommand(*), TodoWrite(*), Read(*), Bash(*) allowed-tools: SlashCommand(*), TodoWrite(*), Read(*), Bash(*)
--- ---
@@ -9,13 +9,16 @@ allowed-tools: SlashCommand(*), TodoWrite(*), Read(*), Bash(*)
## Coordinator Role ## Coordinator Role
**This command is a pure orchestrator**: Creates an independent test-fix workflow session for validating a completed implementation. It reuses the standard planning toolchain with automatic cross-session context gathering. **This command is a pure orchestrator**: Creates an independent test-fix workflow session for existing code. Supports two input modes:
- **Session Mode**: Analyze completed workflow session (cross-session context gathering)
- **Prompt Mode**: Analyze existing codebase via description or file (prompt-based context gathering)
**Core Principles**: **Core Principles**:
- **Session Isolation**: Creates new `WFS-test-[source]` session to keep verification separate from implementation - **Dual Input Support**: Accepts either session ID (WFS-xxx) or feature description/file path
- **Context-First**: Prioritizes gathering code changes and summaries from source session - **Session Isolation**: Creates new `WFS-test-[slug]` session to keep test workflow independent
- **Format Reuse**: Creates standard `IMPL-*.json` task, using `meta.type: "test-fix"` for agent assignment - **Context-First**: Gathers implementation context via appropriate method (session or prompt-based)
- **Parameter Simplification**: Tools auto-detect test session type via metadata, no manual cross-session parameters needed - **Format Reuse**: Creates standard `IMPL-*.json` tasks, using `meta.type: "test-fix"` for agent assignment
- **Automatic Mode Detection**: Input pattern determines execution mode (no manual flags)
- **Manual First**: Default to manual fixes, use `--use-codex` flag for automated Codex fix application - **Manual First**: Default to manual fixes, use `--use-codex` flag for automated Codex fix application
**Execution Flow**: **Execution Flow**:
@@ -339,3 +342,76 @@ See `/workflow:tools:test-task-generate` for detailed specifications.
- `/workflow:test-cycle-execute` - Execute test-fix workflow with dynamic iteration - `/workflow:test-cycle-execute` - Execute test-fix workflow with dynamic iteration
- `/workflow:execute` - Execute standard workflow tasks - `/workflow:execute` - Execute standard workflow tasks
- `/workflow:status` - Check progress - `/workflow:status` - Check progress
## Dual-Mode Support (Enhanced)
### Input Mode Detection
**Automatic mode detection based on argument pattern**:
```bash
# Detection Logic
if [[ "$input" == WFS-* ]]; then
MODE="session" # Session Mode
elif [ -f "$input" ]; then
MODE="prompt" # Prompt Mode (file)
else
MODE="prompt" # Prompt Mode (text)
fi
```
### Mode Comparison
| Aspect | Session Mode | Prompt Mode |
|--------|-------------|-------------|
| **Input** | `WFS-xxx` pattern | Description or file path |
| **Phase 1** | Create `WFS-test-[source]` with `source_session_id` | Create `WFS-test-[slug]` without `source_session_id` |
| **Phase 2** | `/workflow:tools:test-context-gather` | `/workflow:tools:context-gather` |
| **Phase 3-5** | Identical | Identical |
| **Context Source** | Source session summaries | Direct codebase analysis |
### Usage Examples
#### Session Mode (Existing Behavior)
```bash
# Test validation for completed implementation session
/workflow:test-fix-gen WFS-user-auth-v2
```
#### Prompt Mode - Text Description
```bash
# Generate tests from feature description
/workflow:test-fix-gen "Test the user authentication API endpoints in src/auth/api.ts"
```
#### Prompt Mode - File Reference
```bash
# Generate tests from requirements file
/workflow:test-fix-gen ./docs/api-requirements.md
```
#### With Codex Automation
```bash
# Session mode with automated fixes
/workflow:test-fix-gen --use-codex WFS-user-auth
# Prompt mode with automated fixes
/workflow:test-fix-gen --use-codex "Test user registration flow"
```
### Implementation Notes
**Core Rules Addition**:
- Rule 0: **Detect Input Mode** - First analyze input argument to determine session vs prompt mode
**Phase 1 Variation**:
- Session: `"Test validation for [sourceSessionId]"`
- Prompt: `"Test generation for: [prompt-description]"`
**Phase 2 Variation**:
- Session: `test-context-gather` (reads `source_session_id` from metadata)
- Prompt: `context-gather --session [sessionId] "[task_description]"`
### Backward Compatibility
**Fully backward compatible**: Existing session-based usage remains unchanged. All `WFS-*` arguments automatically use session mode.