# Feature Extraction Validation Checklist

Use this checklist to verify the extracted features are complete and accurate.

## Completeness Checks

### Module Coverage
- [ ] All modules identified and explored
- [ ] Each module's `module.json` or config file read
- [ ] Each module's renderer file checked
- [ ] All module settings documented
- [ ] Module-specific features assigned to correct module

### Feature Type Coverage
- [ ] All filter types documented
- [ ] All display types documented
- [ ] All template options listed
- [ ] All UI helpers included
- [ ] All server-side features documented
- [ ] All settings categorized

### Integration Coverage
- [ ] WooCommerce features (if applicable)
- [ ] ACF features (if applicable)
- [ ] WPML features (if applicable)
- [ ] Gutenberg block features (if applicable)
- [ ] Other third-party integrations

### File Coverage
- [ ] Main plugin file read
- [ ] Changelog reviewed
- [ ] All module directories explored
- [ ] Settings/admin files checked
- [ ] Frontend JavaScript files reviewed
- [ ] Integration files checked

## Metadata Accuracy

### Required Fields
- [ ] Every feature has `module` assigned
- [ ] Every feature has `component_type`
- [ ] Every feature has `layer`
- [ ] Every feature has `platform`
- [ ] Every feature has `category`
- [ ] Every feature has `use_case`
- [ ] `requires` field included when applicable

### Field Values
- [ ] `module` values are consistent (match actual module names)
- [ ] `component_type` values are appropriate
- [ ] `layer` values correctly identify where feature operates
- [ ] `platform` values match actual platform support
- [ ] `category` values are logical
- [ ] `requires` dependencies are accurate

## Use Case Accuracy

### External Features (Marketing-Worthy)
- [ ] Query/filtering capabilities marked as external
- [ ] Display/rendering features marked as external
- [ ] Major customization options marked as external
- [ ] User-facing functionality marked as external
- [ ] Integration features marked as external
- [ ] Performance features (user-configurable) marked as external

### Internal Features (Support-Only)
- [ ] Granular styling details marked as internal
- [ ] Technical implementation details marked as internal
- [ ] Fine-tuning options marked as internal
- [ ] Support-only settings marked as internal

### Common Mistakes to Avoid
- [ ] Not marking query settings as external (they're user-facing!)
- [ ] Not marking design customization as external (it's marketing-worthy!)
- [ ] Marking too many features as internal (be less conservative)
- [ ] Confusing "granular" with "internal" (granular can still be external)

## Duplicate Detection

### Check These Common Duplicate Areas
- [ ] Settings section vs module-specific sections
- [ ] UI helpers section vs module settings
- [ ] General features vs specific implementations
- [ ] Different names for same feature
- [ ] Features appearing in multiple logical sections

### Specific Duplicates to Look For
- [ ] Same feature with different wording
- [ ] Module-level vs item-level settings (may be different scopes)
- [ ] General capability vs specific implementation
- [ ] Features split across sections incorrectly

## Organization

### Section Structure
- [ ] Logical section headers
- [ ] Features grouped appropriately
- [ ] Related features near each other
- [ ] Clear hierarchy (modules → features)

### Naming Consistency
- [ ] Feature names are clear and descriptive
- [ ] Similar features use consistent naming
- [ ] No ambiguous names
- [ ] Names match what users would recognize

## Content Quality

### Feature Descriptions
- [ ] Each feature has a clear description
- [ ] Descriptions explain what the feature does
- [ ] Descriptions are user-focused (not technical)
- [ ] No vague or unclear descriptions

### User-Facing Focus
- [ ] Only user-facing features included
- [ ] No internal implementation details
- [ ] No API endpoints or handlers
- [ ] No developer-only technical details

## Final Validation

### Before Finalizing
- [ ] Read through entire document
- [ ] Verify no obvious features missing
- [ ] Check changelog for any missed features
- [ ] Verify all metadata is complete
- [ ] Confirm use_case assignments are accurate
- [ ] Ensure no duplicates exist
- [ ] Verify organization is logical

### Quality Metrics
- [ ] Total feature count seems reasonable for plugin scope
- [ ] All major capabilities represented
- [ ] Balance between external and internal seems appropriate
- [ ] Features cover all user interaction points
- [ ] Integration features properly documented

## Common Issues to Watch For

### Missing Features
- Settings that appear in admin but not documented
- UI elements visible to users but not listed
- Configuration options in module settings
- Filter types that exist but aren't documented
- Display options that aren't listed

### Incorrect Metadata
- Wrong module assignment
- Incorrect platform support
- Missing dependencies
- Wrong category assignment
- Incorrect use_case (too conservative)

### Organizational Issues
- Features in wrong sections
- Duplicates across sections
- Unclear section headers
- Poor grouping of related features

## Quick Validation Commands

If working with markdown file, use these checks:

```bash
# Count total features
grep -c "^\*\*" plugin-features.md

# Check for missing use_case
grep "Metadata:" plugin-features.md | grep -v "use_case"

# Check for duplicates (example)
grep "Feature Name" plugin-features.md | sort | uniq -d

# Count external vs internal
grep -c "use_case: external" plugin-features.md
grep -c "use_case: internal" plugin-features.md
```

## Success Criteria

The extraction is successful when:
- ✅ All user-facing features are documented
- ✅ All metadata is complete and accurate
- ✅ use_case assignments are appropriate (not too conservative)
- ✅ No duplicates exist
- ✅ Features are logically organized
- ✅ Only user-facing features included (no internal details)
- ✅ Integration features properly documented
- ✅ Document is ready for RAG import