x-ipe 1.0.24__py3-none-any.whl → 1.0.25__py3-none-any.whl

x_ipe/resources/skills/task-type-feature-breakdown/references/breakdown-guidelines.md

@@ -0,0 +1,330 @@
+# Feature Breakdown Guidelines Reference
+
+This document contains detailed guidelines, examples, and rules for feature breakdown. Referenced from SKILL.md.
+
+---
+
+## Feature Sizing Guidelines
+
+### Too Large (Split)
+
+Examples of features that need splitting:
+- "Complete E-Commerce System" → Split into Cart, Payment, Shipping, etc.
+- "User Management" → Split into Registration, Profile, Settings, etc.
+- "Full Admin Dashboard" → Split into User Admin, Content Admin, Analytics, etc.
+
+### Good Size
+
+Features appropriately scoped:
+- "Shopping Cart Management"
+- "Payment Processing with Stripe"
+- "Email Notification System"
+- "User Profile Management"
+- "JWT Authentication"
+
+### Too Small (Combine)
+
+Features that should be combined:
+- "Add to Cart Button" → Part of Shopping Cart feature
+- "Validate Email Format" → Part of User Registration feature
+- "Display Error Message" → Part of Form Validation feature
+
+---
+
+## Feature ID Assignment Rules
+
+### ID Format
+
+```
+FEATURE-{NNN}
+```
+
+Where NNN is a zero-padded 3-digit number (001, 002, etc.)
+
+### Assignment Rules
+
+1. **Sequential Assignment** - IDs assigned in order of creation
+2. **No Gaps** - Do not skip numbers
+3. **No Reuse** - Deleted features keep their IDs
+4. **Part-Specific Ranges** - When using parts, each part covers a range:
+   - Part 1: FEATURE-001 to FEATURE-011
+   - Part 2: FEATURE-012 to FEATURE-017
+   - etc.
+
+### Continuation Numbering
+
+When adding features to an existing set:
+```
+1. Query feature board for highest existing FEATURE-XXX
+2. Start new features at next number
+3. Example: If FEATURE-011 exists, next is FEATURE-012
+```
+
+---
+
+## Priority Matrix
+
+### Priority Levels
+
+| Priority | Description | Typical Features |
+|----------|-------------|------------------|
+| P0 (Critical) | MVP must-have | Core loop, auth, primary workflow |
+| P1 (High) | Important for launch | Secondary workflows, error handling |
+| P2 (Medium) | Nice to have | Convenience features, polish |
+| P3 (Low) | Future consideration | Advanced features, optimizations |
+
+### Priority Assignment Criteria
+
+1. **User Impact** - How many users affected? How severely?
+2. **Business Value** - Revenue, retention, or growth impact
+3. **Technical Risk** - Complex features may need early start
+4. **Dependencies** - Features blocking others get higher priority
+
+---
+
+## Feature Naming Conventions
+
+### Good Names
+
+- **Specific:** "JWT Authentication" not "Login"
+- **Action-oriented:** "User Profile Management" not "User Profile"
+- **Technology-agnostic (usually):** "Payment Processing" not "Stripe Integration"
+- **Clear scope:** "Order History Display" not "Orders"
+
+### Bad Names
+
+- **Too vague:** "User Stuff", "Main Feature"
+- **Too technical:** "REST API Controller Layer"
+- **Too broad:** "Everything Users Need"
+- **Ambiguous:** "Processing", "Handler", "Manager"
+
+---
+
+## Version Numbering
+
+| Version | When to Use |
+|---------|-------------|
+| v1.0 | Initial feature implementation |
+| v1.1, v1.2 | Minor enhancements, bug fixes |
+| v2.0 | Major redesign or rewrite |
+
+**Note:** Most breakdown features will be v1.0.
+
+---
+
+## Feature Dependency Patterns
+
+### Sequential Dependencies
+
+```
+FEATURE-001: User Authentication (no deps)
+    └── FEATURE-002: User Profile (depends on FEATURE-001)
+            └── FEATURE-003: User Settings (depends on FEATURE-002)
+```
+
+### Parallel with Shared Dependency
+
+```
+                    ┌── FEATURE-002: User Service (depends on FEATURE-001)
+FEATURE-001: Database Layer ──┤
+                    └── FEATURE-003: Product Service (depends on FEATURE-001)
+```
+
+### Multiple Dependencies
+
+```
+FEATURE-001: Authentication (no deps) ──┐
+                                        ├── FEATURE-003: Admin Panel
+FEATURE-002: Authorization (no deps) ───┘
+```
+
+### Dependency Rules
+
+1. **No Circular Dependencies** - A cannot depend on B if B depends on A
+2. **Foundation First** - Core/shared features have no dependencies
+3. **Clear Reason** - Document why dependency exists
+4. **Minimal Dependencies** - Only list direct dependencies, not transitive
+5. **DAG Structure** - Dependency graph must be a Directed Acyclic Graph
+
+---
+
+## Mockup Processing Details
+
+### Auto-Detection Procedure
+
+```
+1. IF mockup_list is NOT provided or empty:
+   a. Check if requirement came from an Idea (look for idea folder reference)
+   b. IF idea folder exists:
+      - Scan: x-ipe-docs/ideas/{idea-folder}/mockups/
+      - IF mockups found → Auto-populate mockup_list from found files
+      - Notify: "Found {N} mockups in idea folder, processing..."
+   
+2. IF mockup_list is STILL empty after auto-detection:
+   - Log: "No mockups found - skipping mockup processing"
+   - Proceed to Step 3
+```
+
+### File Operations Example
+
+```yaml
+# Input mockup_list
+mockup_list:
+  - mockup_name: "main-dashboard"
+    mockup_list: "x-ipe-docs/ideas/Draft Idea - 01232026/mockup.html"
+  - mockup_name: "settings-panel"
+    mockup_list: "x-ipe-docs/ideas/Draft Idea - 01232026/mockups/settings.html"
+
+# Result: Files created
+x-ipe-docs/requirements/FEATURE-001/mockups/main-dashboard.html
+x-ipe-docs/requirements/FEATURE-001/mockups/settings-panel.html
+```
+
+### Linking Mockups in Documents
+
+**Location 1:** `x-ipe-docs/requirements/requirement-details.md`
+
+**Location 2:** `x-ipe-docs/requirements/{FEATURE-ID}/specification.md`
+
+**Format:**
+```markdown
+## Linked Mockups
+
+| Mockup Function Name | Mockup List |
+|---------------------|-------------|
+| main-dashboard | [main-dashboard.html](FEATURE-001/mockups/main-dashboard.html) |
+| settings-panel | [settings-panel.html](FEATURE-001/mockups/settings-panel.html) |
+```
+
+### Mockup Rules
+
+- If mockup_list is N/A or empty, skip mockup processing
+- Use relative paths from the document location
+- Preserve original file extension when copying
+- Create mockups folder only if mockup_list has items
+
+---
+
+## Part File Management
+
+### When Parts Exist
+
+| Action | Target |
+|--------|--------|
+| Read requirements | Current active part (highest number) |
+| Write Feature List | Current active part |
+| Update Index | requirement-details-index.md |
+
+### Part File Structure
+
+```markdown
+# Requirement Details - Part {X}
+
+> Continued from: [requirement-details-part-{X-1}.md](requirement-details-part-{X-1}.md)  
+> Created: MM-DD-YYYY
+
+---
+
+## Feature List
+
+| Feature ID | Feature Title | Version | Brief Description | Feature Dependency |
+|------------|---------------|---------|-------------------|-------------------|
+| FEATURE-012 | Design Themes | v1.0 | Theme folder structure | FEATURE-011 |
+
+---
+
+## Linked Mockups
+
+| Mockup Function Name | Feature | Mockup List |
+|---------------------|---------|-------------|
+| themes-toolbox | FEATURE-012 | [themes-toolbox.html](FEATURE-012/mockups/themes-toolbox.html) |
+
+---
+
+## Feature Details (Continued)
+
+### FEATURE-012: Design Themes
+[Feature details...]
+```
+
+### Index File Structure
+
+```markdown
+# Requirement Details Index
+
+> Last Updated: MM-DD-YYYY
+
+## Parts Overview
+
+| Part | File | Features Covered | Lines |
+|------|------|------------------|-------|
+| 1 | [Part 1](requirement-details-part-1.md) | FEATURE-001 to FEATURE-011 | ~420 |
+| 2 | [Part 2](requirement-details-part-2.md) | FEATURE-012 to FEATURE-017 | ~415 |
+```
+
+**⚠️ IMPORTANT:** Index file contains ONLY Parts Overview table. NO Feature List in index - each part has its own.
+
+---
+
+## Feature Details Template
+
+```markdown
+### {FEATURE-ID}: {Feature Title}
+
+**Version:** v{X.Y}  
+**Brief Description:** [1-2 sentence description]
+
+**Acceptance Criteria:**
+- [ ] Criterion 1
+- [ ] Criterion 2
+- [ ] Criterion 3
+
+**Dependencies:**
+- {FEATURE-ID}: [Why needed]
+- None (if no dependencies)
+
+**Technical Considerations:**
+- [Key technical decisions or constraints]
+- [Performance requirements]
+- [Security considerations]
+```
+
+### Template Rules
+
+- Keep brief description under 50 words
+- List 3-7 acceptance criteria per feature
+- Note dependencies using Feature IDs
+- Technical considerations are hints for design
+
+---
+
+## Integration with Feature Board Management
+
+This skill **MUST** call the feature-board-management skill to create features on the board.
+
+### Why Integration Matters
+
+1. **Creates centralized tracking** - Single source of truth at x-ipe-docs/requirements/features.md
+2. **Initializes status** - All features start with status "Planned"
+3. **Enables queries** - Other skills can query feature board for Feature Data Model
+4. **Supports lifecycle** - Board tracks features through all phases
+
+### Call Format
+
+```
+CALL feature-stage+feature-board-management skill:
+  operation: create_or_update_features
+  features:
+    - feature_id: FEATURE-001
+      title: User Authentication
+      version: v1.0
+      description: JWT-based user authentication
+      dependencies: []
+    - feature_id: FEATURE-002
+      title: User Profile  
+      version: v1.0
+      description: User profile management
+      dependencies: [FEATURE-001]
+```
+
+**See:** `skills/feature-stage+feature-board-management/SKILL.md` for full operation details

x_ipe/resources/skills/task-type-feature-refinement/SKILL.md

@@ -181,50 +181,15 @@ RECEIVE Feature Data Model:
 ```
 
 **🌐 Web Search (Recommended):**
-Use web search capability to research:
-- Domain-specific business rules and edge cases
-- Industry compliance requirements (GDPR, PCI-DSS, HIPAA, etc.)
-- User experience best practices for similar features
-- Common pitfalls and edge cases in similar implementations
-- Accessibility requirements and standards (WCAG)
+Use web search for: domain rules, compliance (GDPR, PCI-DSS, HIPAA), UX best practices, common pitfalls, accessibility (WCAG).
 
 **🎨 Mockup Analysis (When Mockup List Provided):**
-```
-IF Mockup List != N/A:
-  1. OPEN and analyze the Mockup List file(s)
-  2. EXTRACT UI/UX requirements from mockup:
-     - Layout structure and component hierarchy
-     - User interaction patterns (clicks, hovers, inputs)
-     - Visual design elements (colors, spacing, typography)
-     - Form fields, validation rules, error states
-     - Navigation flows and page transitions
-     - Responsive behavior hints
-  3. DOCUMENT extracted requirements:
-     - Add to "UI/UX Requirements" section in specification
-     - Create acceptance criteria for UI elements
-     - Note any UI-specific edge cases
-  4. IDENTIFY gaps between mockup and requirements:
-     - Missing interactions not shown in mockup
-     - Backend data requirements for UI elements
-     - Loading states, empty states, error states
-  5. ASK human about mockup ambiguities if needed
-
-ELSE IF Mockup List == N/A:
-  - Check if idea-summary has mockup references
-  - If frontend feature, note that mockup may be needed
-  - Focus on functional requirements
-```
+- Analyze mockup file(s) and extract UI/UX requirements
+- Document in "UI/UX Requirements" section with acceptance criteria
+- Identify gaps: missing interactions, loading/empty/error states
+- Ask human about ambiguities if needed
 
-**Mockup-to-Specification Mapping:**
-
-| Mockup Element | Specification Section |
-|----------------|----------------------|
-| Layout/Components | UI/UX Requirements → UI Elements |
-| Forms/Inputs | Functional Requirements + Validation Rules |
-| Buttons/Actions | User Stories + Acceptance Criteria |
-| Navigation | User Flows |
-| Error States | Edge Cases & Constraints |
-| Data Display | Functional Requirements → Output |
+> See [references/specification-writing-guide.md](references/specification-writing-guide.md) for mockup-to-specification mapping.
 
 ---
 
@@ -295,30 +260,10 @@ Target: x-ipe-docs/requirements/FEATURE-012/mockups/home-page-v1.html
 
 **Rule:** Maintain ONE specification file per feature with version history inside.
 
-**DO NOT create versioned files like:**
-- ❌ `specification-v2.md`
-- ❌ `specification-v1.md`
+- ✅ Keep single `specification.md` file with Version History table
+- ❌ Do NOT create versioned files like `specification-v2.md`
 
-**Instead:**
-- ✅ Keep single `specification.md` file
-- ✅ Add/update Version History table after the header
-- ✅ Update content in place with new version
-
-**Version History Format (add after document header):**
-```markdown
-## Version History
-
-| Version | Date | Description |
-|---------|------|-------------|
-| v2.0 | 01-22-2026 | Major upgrade: xterm.js, session persistence, split-pane |
-| v1.0 | 01-18-2026 | Initial specification |
-```
-
-**When updating existing specification:**
-1. Increment version in document header (v1.0 → v2.0)
-2. Add new row to Version History table
-3. Update specification content in place
-4. Keep the same filename: `specification.md`
+> See [references/specification-writing-guide.md](references/specification-writing-guide.md) for version history format.
 
 ---
 
@@ -331,149 +276,51 @@ Target: x-ipe-docs/requirements/FEATURE-012/mockups/home-page-v1.html
 > Status: Refined  
 > Last Updated: MM-DD-YYYY
 
-## Linked Mockups
-
-| Mockup | Type | Path | Description |
-|--------|------|------|-------------|
-| {Mockup Name} | HTML | [path/to/mockup.html](path/to/mockup.html) | {Brief description} |
+## Version History
+[Version table - see guide]
 
-> **Note:** UI/UX requirements below are derived from these mockups.
+## Linked Mockups
+[Mockup table if applicable - see guide]
 
 ## Overview
-
-[2-3 paragraph detailed description of what this feature does, why it's needed, and who will use it]
+[2-3 paragraph description: what, why, who]
 
 ## User Stories
-
-As a [user type], I want to [action/goal], so that [benefit/value].
-
-**Examples:**
-- As a **customer**, I want to **save items to my cart**, so that **I can purchase them later**.
-- As an **admin**, I want to **view all user orders**, so that **I can track sales and resolve issues**.
+[As a [user], I want to [action], so that [benefit]]
 
 ## Acceptance Criteria
-
-- [ ] Criterion 1: [Specific, measurable condition]
-- [ ] Criterion 2: [Specific, measurable condition]
-- [ ] Criterion 3: [Specific, measurable condition]
-- [ ] Criterion 4: [Specific, measurable condition]
-- [ ] Criterion 5: [Specific, measurable condition]
+[Testable, measurable conditions]
 
 ## Functional Requirements
-
-### FR-1: [Requirement Name]
-
-**Description:** [What the system must do]
-
-**Details:**
-- Input: [What data is provided]
-- Process: [What happens]
-- Output: [What result is produced]
-
-### FR-2: [Requirement Name]
-[Repeat for each functional requirement]
+[FR-N: Requirement with Input/Process/Output]
 
 ## Non-Functional Requirements
-
-### NFR-1: Performance
-
-- Response time: [X seconds/milliseconds]
-- Throughput: [X requests per second]
-- Concurrent users: [X users]
-
-### NFR-2: Security
-
-- Authentication required: [Yes/No]
-- Authorization level: [Role/permission required]
-- Data encryption: [What data, how encrypted]
-
-### NFR-3: Scalability
-
-- Expected growth: [User/data growth projections]
-- Scaling strategy: [Horizontal/vertical]
+[Performance, Security, Scalability]
 
 ## UI/UX Requirements
-
-[If applicable]
-
-**Wireframes/Mockups:** [Link or embed]
-
-**User Flows:**
-1. User navigates to [page/screen]
-2. User performs [action]
-3. System displays [result]
-
-**UI Elements:**
-- Button: [Label, action]
-- Form fields: [List with validation rules]
-- Error messages: [List with conditions]
+[Wireframes, User Flows, UI Elements]
 
 ## Dependencies
-
-### Internal Dependencies
-
-- **FEATURE-XXX:** [Why this feature is needed, what it provides]
-- **FEATURE-YYY:** [Why this feature is needed, what it provides]
-
-### External Dependencies
-
-- **Library/Service Name:** [Purpose, version if known]
-- **Third-party API:** [What functionality it provides]
+[Internal and External]
 
 ## Business Rules
-
-### BR-1: [Rule Name]
-
-**Rule:** [Clear statement of business rule]
-
-**Example:** 
-- Only authenticated users can add items to cart
-- Prices must be positive numbers
-- Discounts cannot exceed 90%
-
-### BR-2: [Rule Name]
-[Repeat for each business rule]
+[BR-N: Clear rule statements]
 
 ## Edge Cases & Constraints
-
-### Edge Case 1: [Scenario]
-
-**Scenario:** [Describe unusual or boundary condition]  
-**Expected Behavior:** [How system should respond]
-
-**Examples:**
-- User session expires during checkout → Redirect to login, preserve cart
-- Database connection lost → Show error, queue for retry
-- Invalid input format → Return validation error with details
+[Scenarios with expected behavior]
 
 ## Out of Scope
-
-- [Explicitly list what this feature does NOT include]
-- [Helps prevent scope creep]
-
-**Examples:**
-- Social media login (only email/password for v1.0)
-- Multi-factor authentication (planned for v2.0)
-- Mobile app support (web only for v1.0)
+[What is NOT included]
 
 ## Technical Considerations
-
-[Hints for technical design - not detailed design, just considerations]
-
-- Suggested technology/framework
-- Known performance requirements
-- Security considerations
-- Integration points
+[Hints for technical design - WHAT not HOW]
 
 ## Open Questions
-
-- [ ] Question 1: [What needs clarification]
-- [ ] Question 2: [What needs decision]
-- [ ] Question 3: [What needs stakeholder input]
-
----
+[What needs clarification]
 ```
 
+> **Full templates and examples:** See [references/specification-writing-guide.md](references/specification-writing-guide.md)
+
 **Specification Quality Checklist:**
 - [ ] All acceptance criteria are testable
 - [ ] User stories provide clear value