Files
Bewerbungszauberer/openspec/changes/archive/2025-11-03-add-application-validation/tasks.md
T

193 lines
7.7 KiB
Markdown
Raw Normal View History

2025-11-02 21:00:05 +01:00
# Implementation Tasks
## 1. Design Validation Logic
- [x] 1.1 Study `/validate-profile` command structure and pattern
- [x] 1.2 Define required vs optional sections for application.md
- [x] 1.3 Design placeholder detection regex patterns
- [x] 1.4 Define validation pass/fail criteria
- [x] 1.5 Design error message format and structure
## 2. Implement Location Detection
- [x] 2.1 Implement current directory detection logic
- Check if cwd ends with pattern: `applications/pending/[folder-name]/`
- Verify `application.md` exists in current directory
- [x] 2.2 Implement parameter parsing logic
- Accept folder name (e.g., `2025-11-02-TechCorp-Developer`)
- Accept relative path (e.g., `applications/pending/2025-11-02-TechCorp-Developer`)
- Accept absolute path
- [x] 2.3 Implement application discovery
- List available applications in `applications/pending/`
- Handle empty applications directory gracefully
## 3. Implement Error Handling for Location
- [x] 3.1 Handle running from wrong directory without parameter
- Show error message
- List available applications
- Provide usage examples
- [x] 3.2 Handle non-existent application with parameter
- Show error: "Application not found: [name]"
- List available applications
- [x] 3.3 Handle missing application.md
- Show error: "No application.md found in [path]"
- Suggest this may not be a valid application folder
## 4. Implement File Reading & Parsing
- [x] 4.1 Read application.md file content
- [x] 4.2 Parse markdown sections by headings
- Identify section boundaries
- Extract content for each section
- [x] 4.3 Handle corrupted or unreadable files
- Catch read errors
- Provide helpful error message
- [x] 4.4 Implement case-insensitive section matching
- Match "Organization Information", "organization information", etc.
## 5. Implement Placeholder Detection
- [x] 5.1 Create regex for square bracket placeholders: `\[([^\]]+)\]`
- [x] 5.2 Create patterns for common placeholders:
- `[To be filled]`
- `[Organization name]`
- `[Job Title]`
- `[...]`
- [x] 5.3 Detect generic template text
- "Add information here"
- "To be filled"
- Other unchanged template phrases
- [x] 5.4 Implement context-aware detection
- Don't flag legitimate brackets like `[PhD]`, `[Acquired]`
- Check surrounding context for meaningful use
- [x] 5.5 Handle very long placeholder text (truncate to 100 chars)
## 6. Implement Required Section Validation
- [x] 6.1 Validate Organization Information section
- Check for Organization Name field
- Detect placeholders in name field
- [x] 6.2 Validate Job Information section
- Check for Job Title field
- Detect placeholders in title field
- [x] 6.3 Validate Job Description Summary section
- Check if section has any content
- Verify at least one subsection (Responsibilities/Required Skills/etc.) has real content
- Detect if all subsections only have placeholders
- [x] 6.4 Implement empty section detection
- Check if required sections exist but have no content
- Report missing required sections
## 7. Implement Optional Section Handling
- [x] 7.1 Identify optional sections (don't validate):
- Match Strategy
- Key Messages
- Tone of Voice
- Research Notes
- Document Checklist
- Application Strategy Notes
- Timeline
- [x] 7.2 Ensure optional sections don't cause validation failure
- [x] 7.3 Allow these sections to contain placeholders without error
## 8. Implement Population Awareness
- [x] 8.1 Check if `input/` folder exists
- [x] 8.2 Check if `input/` folder contains files
- [x] 8.3 Implement warning logic:
- If `input/` is empty AND most sections have placeholders → suggest adding documents and running `/populate-application`
- If `input/` has files AND most sections still have placeholders → suggest running `/populate-application`
- If required sections are filled → don't warn (manually populated is fine)
- [x] 8.4 Add population warning to failure output
## 9. Implement Pass/Fail Reporting
- [x] 9.1 Design success output format:
- ✅ emoji and "Application Validation: PASSED" title
- Summary section with key information extracted from application.md
- Encouraging message
- Clear next step
- [x] 9.2 Design failure output format:
- ❌ emoji and "Application Validation: FAILED" title
- Explanation paragraph
- "Issues found:" heading
- Structured error list organized by section
- Actionable guidance
- [x] 9.3 Implement structured error grouping
- Group errors by section (## Organization Information, ## Job Description Summary, etc.)
- Use checkbox format: `- [ ] Field Name: Issue description`
- [x] 9.4 Quote specific placeholder text in errors
- Extract and quote the actual placeholder found
- Truncate if longer than 100 characters
## 10. Create Slash Command File
- [x] 10.1 Create `src/.claude/commands/validate-application.md`
- [x] 10.2 Write comprehensive instructions covering:
- Location detection logic (current directory vs parameter)
- Error handling for wrong location
- File reading and parsing
- Placeholder detection patterns
- Required vs optional section validation
- Population awareness checks
- Success/failure output formatting
- Edge case handling
- [x] 10.3 Add examples of success and failure outputs
- [x] 10.4 Include edge case handling instructions
## 11. Update Framework Documentation
- [x] 11.1 Update `src/CLAUDE.md` - Add `/validate-application` to command reference
- [x] 11.2 Update workflow section to include validation step
- Add between "Populate application" and "Generate documents" (future)
- [x] 11.3 Add best practices note about validating before generation
- [x] 11.4 Add usage examples:
- Running from inside application folder
- Running with explicit path
- [x] 11.5 Update `/populate-application` documentation to mention validation as next step
## 12. Integration Points
- [x] 12.1 Ensure consistency with `/validate-profile` pattern
- Match output format
- Match tone and language
- Match error structure
- [x] 12.2 Verify workflow integration:
- Profile validation → Application init → Add documents → Populate → **Validate** → Generate
- [x] 12.3 Consider future document generation integration
- Validation will be prerequisite for generation commands
## 13. Testing & Validation
- [x] 13.1 Test from inside application folder (no parameter)
- [x] 13.2 Test with folder name parameter
- [x] 13.3 Test with path parameter
- [x] 13.4 Test from wrong location (should show error + list)
- [x] 13.5 Test with non-existent application
- [x] 13.6 Test with complete application (should pass)
- [x] 13.7 Test with incomplete application (should fail with specific errors)
- [x] 13.8 Test with empty input/ folder (should warn)
- [x] 13.9 Test with populated input/ but empty sections (should suggest /populate-application)
- [x] 13.10 Test with manually populated application (should pass even if input/ empty)
- [x] 13.11 Test placeholder detection accuracy (catch placeholders, allow legitimate brackets)
- [x] 13.12 Test missing application.md file
- [x] 13.13 Test missing required sections
- [x] 13.14 Validate proposal: `openspec validate add-application-validation --strict`
## 14. Update Test Environment
- [x] 14.1 Copy new `/validate-application` command to test directory
- [x] 14.2 Update `CLAUDE.md` in test directory
- [x] 14.3 Preserve test directory's `profile.md` and `applications/` folder
- [x] 14.4 Test in actual test environment
## 15. Git Workflow
- [x] 15.1 Verify all changes are on feature branch `feature/application-validation`
- [x] 15.2 Stage all files (OpenSpec proposal, slash command, documentation updates)
- [x] 15.3 Create descriptive commit message following conventional commits format
- [x] 15.4 Merge feature branch into main
- [x] 15.5 Verify final state