Replace v1.0|1.0.0 with v0.1.0

- reorganize kiro specs into folders
- move old documents into docs history folder

Author: mdstaff

.claude/agents/technical-writing-agent.md

@@ -19,7 +19,7 @@ You are an expert Technical Writing specialist with deep knowledge of:
 
 ## Project Context
 
-**Ashfolio** is a production-ready (v1.0) Phoenix LiveView portfolio management application built with the Ash Framework. Key characteristics:
+**Ashfolio** is a production-ready (v0.1.0) Phoenix LiveView portfolio management application built with the Ash Framework. Key characteristics:
 
 - **Single-user local application** with SQLite database
 - **Comprehensive test suite** (383/383 tests passing)

.kiro/specs/README.md

@@ -0,0 +1,78 @@
+# Ashfolio Feature Specifications
+
+This directory contains focused, manageable specifications for Ashfolio features. Each spec can be worked on independently without conflicts.
+
+## Current Specifications
+
+### 🗺️ Development Roadmap
+
+- **[User Experience Enhancements](user-experience-enhancements/)** - Comprehensive UX roadmap (reference for focused specs - to be removed later)
+
+### 📋 Focused Feature Specs (Ready for Development)
+
+#### Core UX Improvements
+
+- **[Symbol Autocomplete](symbol-autocomplete/)** - Intelligent symbol search in transaction forms
+- **[Real-Time Price Lookup](real-time-price-lookup/)** - Automatic price fetching during transaction entry
+- **[Interactive Dashboard Charts](interactive-dashboard-charts/)** - Portfolio performance and allocation visualization
+- **[Advanced Holdings Table](advanced-holdings-table/)** - Enhanced table with sorting, filtering, and bulk operations
+- **[Mobile Optimization](mobile-optimization/)** - Touch-optimized interface for mobile devices
+
+#### Documentation & Quality
+
+- **[Documentation Quality Improvements](documentation-quality-improvements/)** - Technical writing and organization enhancements
+
+### 📚 Reference Specifications
+
+- **[V1.0 Foundation](requirements.md)** - Original v1.0 requirements (completed)
+- **[V1.0 Design](design.md)** - Original v1.0 technical design (completed)
+- **[V1.0 Tasks](tasks.md)** - Original v1.0 implementation plan (97% complete)
+
+## Specification Structure
+
+Each feature spec follows this structure:
+
+```
+feature-name/
+├── requirements.md    # User stories and acceptance criteria
+├── design.md         # Technical architecture and implementation
+└── tasks.md          # Implementation plan with specific tasks
+```
+
+## Development Workflow
+
+1. **Choose a Feature**: Select a focused spec that aligns with project priorities
+2. **Review Requirements**: Ensure requirements are clear and complete
+3. **Create Design**: Develop technical design if not already present
+4. **Plan Tasks**: Break down implementation into manageable tasks
+5. **Implement**: Execute tasks while maintaining test coverage
+6. **Integrate**: Ensure feature works with existing v1.0 foundation
+
+## Foundation Status
+
+**Ashfolio v1.0**: Production-ready foundation with 383 passing tests
+
+- ✅ Complete Ash Framework architecture
+- ✅ Phoenix LiveView interface
+- ✅ Portfolio calculations and market data
+- ✅ Account and transaction management
+- ✅ Comprehensive test coverage
+
+All new features build upon this solid foundation without breaking existing functionality.
+
+## Prioritization Guidelines
+
+**High Priority** (Immediate User Value):
+
+1. Symbol Autocomplete - Reduces transaction entry friction
+2. Real-Time Price Lookup - Improves data accuracy
+3. Mobile Optimization - Expands accessibility
+
+**Medium Priority** (Enhanced Experience):
+
+1. Interactive Dashboard Charts - Better data visualization
+2. Advanced Holdings Table - Power user features
+
+**Ongoing** (Quality & Maintenance):
+
+1. Documentation Quality Improvements - Developer experience

.kiro/specs/advanced-holdings-table/requirements.md

@@ -0,0 +1,73 @@
+# Advanced Holdings Table Requirements
+
+## Introduction
+
+This feature enhances the existing holdings table with sorting, filtering, and bulk operations to help users manage larger portfolios more efficiently.
+
+**Foundation**: Built on v1.0's existing holdings table and HoldingsCalculator with proven performance.
+
+## Requirements
+
+### Requirement 1: Table Sorting and Persistence
+
+**User Story:** As a portfolio manager with many holdings, I want to sort my holdings by different criteria so that I can analyze my positions effectively.
+
+#### Acceptance Criteria
+
+1. WHEN viewing the holdings table THEN users SHALL be able to click column headers to sort by that column
+2. WHEN sorting is applied THEN the system SHALL show visual indicators (arrows) for sort direction
+3. WHEN clicking the same column header THEN sorting SHALL toggle between ascending and descending
+4. WHEN sorting is applied THEN the sort state SHALL persist across page refreshes
+5. WHEN the table is sorted THEN all data SHALL remain accurate and properly formatted
+
+### Requirement 2: Holdings Filtering
+
+**User Story:** As an investor with a diverse portfolio, I want to filter my holdings so that I can focus on specific types of investments.
+
+#### Acceptance Criteria
+
+1. WHEN viewing the holdings table THEN users SHALL have access to filter controls above the table
+2. WHEN filtering by asset class THEN only holdings matching the selected class SHALL be displayed
+3. WHEN filtering by performance THEN users SHALL be able to show only gains, losses, or both
+4. WHEN filters are applied THEN the system SHALL show active filter indicators with clear options
+5. WHEN filters are cleared THEN the table SHALL return to showing all holdings
+
+### Requirement 3: Bulk Operations
+
+**User Story:** As a power user, I want to perform actions on multiple holdings at once so that I can manage my portfolio efficiently.
+
+#### Acceptance Criteria
+
+1. WHEN viewing holdings THEN users SHALL be able to select multiple rows using checkboxes
+2. WHEN rows are selected THEN bulk action buttons SHALL appear (Refresh Prices, Export Data)
+3. WHEN bulk refresh is triggered THEN selected holdings SHALL have their prices updated simultaneously
+4. WHEN bulk export is triggered THEN selected holdings data SHALL be exported to CSV format
+5. WHEN bulk operations complete THEN users SHALL receive confirmation and the selection SHALL clear
+
+### Requirement 4: Pagination for Large Portfolios
+
+**User Story:** As an investor with many holdings, I want the table to load quickly so that I can access my data without performance issues.
+
+#### Acceptance Criteria
+
+1. WHEN the portfolio has more than 25 holdings THEN the table SHALL implement pagination
+2. WHEN navigating pages THEN sort and filter settings SHALL be maintained
+3. WHEN on any page THEN users SHALL see current page info (showing X-Y of Z holdings)
+4. WHEN changing pages THEN the transition SHALL be smooth without full page reloads
+5. WHEN bulk operations are used THEN they SHALL work across all pages, not just the current page
+
+## Technical Requirements
+
+### Integration Points
+
+- **Existing Holdings Table**: Enhance current table component
+- **HoldingsCalculator**: Use existing calculation engine
+- **Phoenix LiveView**: Leverage existing real-time capabilities
+- **User Preferences**: Store sort/filter preferences (new feature)
+
+### Performance Targets
+
+- Table rendering: < 500ms for 100+ holdings
+- Sort operations: < 200ms response time
+- Filter operations: < 300ms response time
+- Bulk operations: < 5s for 50 selected holdings

.kiro/specs/documentation-quality-improvements/requirements.md

@@ -4,7 +4,7 @@
 
 This document outlines the requirements for addressing critical documentation gaps, quality issues, and alignment discrepancies identified in the Ashfolio project during the Phase 10 review. These improvements are essential for achieving production readiness and maintaining long-term project sustainability.
 
-The scope includes fixing compilation issues, aligning documentation with implementation reality, creating missing documentation, and establishing comprehensive testing procedures to ensure the project meets professional standards for a v1.0 release.
+The scope includes fixing compilation issues, aligning documentation with implementation reality, creating missing documentation, and establishing comprehensive testing procedures to ensure the project meets professional standards for a v0.1.0 release.
 
 ## Requirements
 

.kiro/specs/interactive-dashboard-charts/requirements.md

@@ -0,0 +1,65 @@
+# Interactive Dashboard Charts Requirements
+
+## Introduction
+
+This feature adds interactive charts to the dashboard for portfolio performance visualization and asset allocation analysis, enhancing the existing dashboard with professional data visualization.
+
+**Foundation**: Built on v1.0's dashboard with existing portfolio calculations and Phoenix LiveView architecture.
+
+## Requirements
+
+### Requirement 1: Portfolio Performance Chart
+
+**User Story:** As a portfolio manager, I want to see my portfolio performance over time so that I can track my investment progress visually.
+
+#### Acceptance Criteria
+
+1. WHEN viewing the dashboard THEN the system SHALL display a line chart showing portfolio value over the last 30 days
+2. WHEN hovering over chart points THEN tooltips SHALL show exact date, portfolio value, and daily change
+3. WHEN insufficient historical data exists THEN the system SHALL show a helpful message explaining data requirements
+4. WHEN the chart loads THEN it SHALL use skeleton loading states during data fetching
+5. WHEN portfolio data updates THEN the chart SHALL refresh automatically via LiveView
+
+### Requirement 2: Asset Allocation Pie Chart
+
+**User Story:** As an investor, I want to see how my portfolio is allocated across different assets so that I can understand my diversification.
+
+#### Acceptance Criteria
+
+1. WHEN viewing the dashboard THEN the system SHALL display a pie chart showing allocation by asset class
+2. WHEN clicking on pie segments THEN they SHALL highlight and show detailed allocation information
+3. WHEN hovering over segments THEN tooltips SHALL show asset class, value, and percentage
+4. WHEN portfolio has no holdings THEN the system SHALL show an empty state with guidance
+5. WHEN allocation changes THEN the chart SHALL update in real-time
+
+### Requirement 3: Responsive Chart Design
+
+**User Story:** As a mobile user, I want charts to work well on my device so that I can view my portfolio data anywhere.
+
+#### Acceptance Criteria
+
+1. WHEN viewing charts on mobile THEN they SHALL be touch-interactive with appropriate sizing
+2. WHEN screen size changes THEN charts SHALL resize responsively without losing functionality
+3. WHEN on small screens THEN chart legends SHALL adapt to available space
+4. WHEN charts are displayed THEN they SHALL maintain readability across all device sizes
+5. WHEN touch interactions occur THEN they SHALL provide appropriate feedback
+
+## Technical Requirements
+
+### New Dependencies
+
+- **Chart.js**: Lightweight charting library compatible with Phoenix LiveView
+- **Historical Data Storage**: New PortfolioSnapshot resource for time-series data
+
+### Integration Points
+
+- **Existing Dashboard**: Enhance current DashboardLive module
+- **Portfolio Calculators**: Use existing calculation engines
+- **Phoenix LiveView**: Leverage existing real-time capabilities
+
+### Performance Targets
+
+- Chart rendering: < 1s for 30 days of data
+- Interactive response: < 100ms for hover/click events
+- Data loading: Progressive loading with skeleton states
+- Memory usage: < 10MB for chart data and rendering

.kiro/specs/mobile-optimization/requirements.md

@@ -0,0 +1,72 @@
+# Mobile Optimization Requirements
+
+## Introduction
+
+This feature optimizes Ashfolio's interface for mobile devices, ensuring all functionality works seamlessly on phones and tablets while maintaining the desktop experience quality.
+
+**Foundation**: Built on v1.0's existing responsive design with Tailwind CSS and Phoenix LiveView.
+
+## Requirements
+
+### Requirement 1: Touch-Optimized Forms
+
+**User Story:** As a mobile user, I want forms that work well with touch input so that I can easily enter transactions on my phone.
+
+#### Acceptance Criteria
+
+1. WHEN accessing forms on mobile THEN all input fields SHALL be appropriately sized for touch (minimum 44px height)
+2. WHEN entering numeric data THEN the system SHALL show numeric keyboards for amount and price fields
+3. WHEN selecting dates THEN the system SHALL use native date pickers optimized for mobile
+4. WHEN using dropdowns THEN they SHALL be touch-friendly with adequate spacing between options
+5. WHEN forms have validation errors THEN error messages SHALL be clearly visible on small screens
+
+### Requirement 2: Mobile Navigation
+
+**User Story:** As a mobile user, I want easy navigation between sections so that I can access all portfolio features on my device.
+
+#### Acceptance Criteria
+
+1. WHEN accessing on mobile THEN the navigation SHALL use a collapsible hamburger menu
+2. WHEN the menu is open THEN it SHALL provide easy access to all main sections (Dashboard, Accounts, Transactions)
+3. WHEN navigating between pages THEN transitions SHALL be smooth and responsive
+4. WHEN using the back button THEN it SHALL work correctly with the single-page application
+5. WHEN the menu is closed THEN it SHALL not interfere with page content
+
+### Requirement 3: Responsive Data Tables
+
+**User Story:** As a mobile user, I want to view my portfolio data clearly so that I can monitor my investments on any device.
+
+#### Acceptance Criteria
+
+1. WHEN viewing tables on mobile THEN they SHALL use horizontal scrolling or card-based layouts as appropriate
+2. WHEN scrolling tables horizontally THEN important columns (symbol, value) SHALL remain visible
+3. WHEN viewing holdings on mobile THEN the most critical information SHALL be prioritized in the layout
+4. WHEN tables are too wide THEN they SHALL provide smooth horizontal scrolling with momentum
+5. WHEN switching between portrait and landscape THEN tables SHALL adapt their layout appropriately
+
+### Requirement 4: Mobile Performance
+
+**User Story:** As a mobile user, I want the app to load quickly and respond smoothly so that I can efficiently manage my portfolio.
+
+#### Acceptance Criteria
+
+1. WHEN loading pages on mobile THEN initial render SHALL complete within 3 seconds on 3G connections
+2. WHEN interacting with the interface THEN touch responses SHALL feel immediate (< 100ms)
+3. WHEN charts are displayed THEN they SHALL be optimized for mobile rendering performance
+4. WHEN using the app offline THEN core functionality SHALL remain available with appropriate indicators
+5. WHEN data updates occur THEN they SHALL not cause jarring layout shifts on mobile
+
+## Technical Requirements
+
+### Integration Points
+
+- **Existing Tailwind CSS**: Enhance mobile-first responsive design
+- **Phoenix LiveView**: Optimize for mobile touch events
+- **Current Components**: Adapt existing components for mobile use
+
+### Performance Targets
+
+- First contentful paint: < 2s on 3G
+- Touch response time: < 100ms
+- Smooth scrolling: 60fps on modern mobile devices
+- Offline functionality: Core features available without network

.kiro/specs/real-time-price-lookup/requirements.md

@@ -0,0 +1,61 @@
+# Real-Time Price Lookup Requirements
+
+## Introduction
+
+This feature adds automatic price lookup when users select symbols in transaction forms, providing current market data to assist with accurate transaction entry.
+
+**Foundation**: Built on v1.0's existing PriceManager GenServer and Yahoo Finance integration.
+
+## Requirements
+
+### Requirement 1: Automatic Price Fetching
+
+**User Story:** As an investor entering transactions, I want to see current market prices when I select a symbol so that I can enter accurate transaction data.
+
+#### Acceptance Criteria
+
+1. WHEN a user selects a symbol in the transaction form THEN the system SHALL automatically fetch the current market price
+2. WHEN price lookup is in progress THEN the system SHALL show a loading indicator next to the price field
+3. WHEN current price is retrieved THEN it SHALL display prominently with timestamp
+4. WHEN a price is auto-populated THEN the user SHALL be able to override it with manual entry
+5. WHEN the form is submitted THEN it SHALL use the user-entered price, not the auto-fetched price
+
+### Requirement 2: Fallback and Error Handling
+
+**User Story:** As a user, I want the form to work even when price lookup fails so that I can still enter transactions manually.
+
+#### Acceptance Criteria
+
+1. WHEN price lookup fails THEN the system SHALL show the last known cached price with staleness indicator
+2. WHEN no price data is available THEN the system SHALL allow manual price entry with appropriate validation
+3. WHEN API rate limits are hit THEN the system SHALL show cached price and explain the limitation
+4. WHEN network is unavailable THEN the system SHALL gracefully degrade to manual entry mode
+5. WHEN errors occur THEN they SHALL not prevent form submission with manual prices
+
+### Requirement 3: Market Context Information
+
+**User Story:** As an investor, I want to understand the context of price data so that I can make informed decisions about my transaction entries.
+
+#### Acceptance Criteria
+
+1. WHEN price data is displayed THEN it SHALL include market status (open/closed/pre-market/after-hours)
+2. WHEN showing cached prices THEN the system SHALL display last update timestamp
+3. WHEN markets are closed THEN the system SHALL show the last closing price with appropriate label
+4. WHEN price data is stale (>1 hour) THEN it SHALL be clearly marked as outdated
+5. WHEN displaying prices THEN they SHALL use consistent currency formatting ($X,XXX.XX)
+
+## Technical Requirements
+
+### Integration Points
+
+- **Existing PriceManager**: Extend for individual symbol lookup
+- **Yahoo Finance API**: Reuse existing integration
+- **Transaction Forms**: Integrate with FormComponent
+- **ETS Cache**: Utilize existing price caching
+
+### Performance Targets
+
+- Price lookup: < 2s response time
+- Cache utilization: > 90% for recently viewed symbols
+- Form responsiveness: No blocking of user input during lookup
+- Error recovery: < 1s fallback to cached/manual entry