# Questions & Answers

## Q1: For F2: The new format includes 'steps' as verification steps. Should these be auto-generated from the feature description, or should the LLM provide them explicitly when calling save_features?
**Category:** clarification
**Answer:** LLM provides steps explicitly when calling save_features. This gives more control and better quality verification steps.

## Q2: For F2: What are the valid values for 'category'? The example shows 'functional' - should there be a predefined set (e.g., functional, ui, api, performance) or free-form text?
**Category:** clarification
**Answer:** Free-form text, no predefined set of categories.

## Q3: For F1/F2: Should the existing fields (priority, complexity, dependencies) be preserved in the new JSON format, or completely replaced by the new structure?
**Category:** other
**Answer:** Priority should come from the order in the array (first = highest priority). Complexity and dependencies should be optional but encouraged fields.

## Q4: For F4: Should we support reading existing feature-list.md files (backwards compatibility), or just provide a one-time migration tool? What happens to tasks that already have feature-list.md?
**Category:** other
**Answer:** No backwards compatibility needed - assume this is the first time running, no need to handle old feature-list.md files.

## Q5: For F3: The 'passes' field suggests this is for test verification. Should mark_feature_complete just set passes=true, or should there be additional validation (e.g., all steps verified)?
**Category:** other
**Answer:** Validate that steps are verified before marking complete. This is marked as a <promise> - super important requirement.
