feat: add template selection to app create

[solimander]

Adds template selection to eigenx app create now that we have multiple templates (minimal, attested-api).

Changes

• New third parameter: eigenx app create [name] [language] [template-name]
• Interactive prompt shows available templates when not specified
• Templates fetched from templates.json in eigenx-templates repo (language → category structure)
• Renamed --template → --template-repo for custom Git URLs

Usage

eigenx app create                           # fully interactive
eigenx app create my-app typescript         # prompts for template
eigenx app create my-app typescript attested-api # full specification

Template catalog is cached for 15 minutes. Fetch failures fail fast with clear errors.

[claude]

Claude finished @solimander's task —— View job

---

Code Review Complete ✅

I've thoroughly analyzed this PR that adds template selection to eigenx app create. Here's my comprehensive review:

Todo List:

• Read and analyze all changed files
• Review main implementation in create.go
• Examine new catalog.go for template management
• Check interactive utilities and flag changes
• Assess security implications of external template fetching
• Check for performance considerations and caching
• Look for test coverage
• Provide comprehensive review feedback

---

Overall Assessment: Strong Implementation ⭐⭐⭐⭐

This is a well-designed feature that significantly improves the template selection experience. The implementation follows good practices and maintains backward compatibility.

🟢 Strengths

Architecture & Design

• Clean separation: New catalog.go properly separates template catalog logic from the main create command
• Extensible structure: Language → category structure supports future template additions easily
• Interactive UX: Excellent progressive disclosure - prompts only when parameters are missing
• Backward compatibility: Existing workflows continue to work unchanged

Code Quality

• Error handling: Comprehensive error messages with clear context (pkg/template/catalog.go:75-84)
• Input validation: Proper project name validation prevents common issues (pkg/commands/app/create.go:304-312)
• Code organization: Well-structured configuration gathering in gatherProjectConfig()

Caching Strategy

• Smart caching: 15-minute cache duration balances freshness vs performance
• Thread-safe: Proper use of sync.RWMutex for concurrent access (pkg/template/catalog.go:116-119)
• Local development: Excellent support via EIGENX_USE_LOCAL_TEMPLATES environment variable

🟡 Areas for Improvement

Security Considerations

1. HTTP timeout: ✅ Good - 10-second timeout prevents hanging requests (pkg/template/catalog.go:155-157)
2. TLS validation: ⚠️ Consider adding explicit TLS verification for the GitHub raw URL
3. Input sanitization: The template path concatenation looks safe but could benefit from explicit path traversal protection

Error Handling & UX

// pkg/template/catalog.go:161-167
if resp.StatusCode != http.StatusOK {
    return nil, fmt.Errorf("failed to fetch template catalog: HTTP %d", resp.StatusCode)
}

Suggestion: Provide more helpful error messages for common HTTP status codes (404, 403, etc.)

Performance & Reliability

1. Network resilience: Consider adding retry logic for transient network failures
2. Fallback mechanism: Could gracefully degrade to a built-in template list if network fetch fails
3. Memory usage: JSON unmarshaling creates intermediate objects - fine for current scale but worth monitoring

🔴 Critical Issues

Missing Test Coverage

This is the most significant concern:

• No unit tests for the new catalog.go functionality
• No tests for SelectTemplateInteractive() in utils/interactive.go
• Integration test exists (.github/workflows/create.yml:70) but limited to happy path

Recommended test additions:

// Suggested tests to add:
func TestFetchTemplateCatalog_Success(t *testing.T) // HTTP mocking
func TestFetchTemplateCatalog_NetworkError(t *testing.T) // Error scenarios  
func TestTemplateCatalog_GetTemplate(t *testing.T) // Template lookup
func TestSelectTemplateInteractive(t *testing.T) // Interactive selection

Configuration Change Impact

• Deletion of config/templates.yaml may affect existing workflows
• Consider adding migration notes or backward compatibility support

📋 Detailed Code Review

pkg/commands/app/create.go

• Line 125-133: Template selection logic is clean and follows the interactive pattern well
• Line 141-144: Good error propagation from catalog lookup
• Refactoring: The large gatherProjectConfig() function could be broken down further for better testability

pkg/template/catalog.go

• Lines 47-72: Custom JSON unmarshaling is necessary but adds complexity - well implemented
• Lines 124-151: Cache management is thread-safe and efficient
• Line 194: Good fallback directory detection for local development

pkg/commands/utils/interactive.go

• Lines 45-46: slices.Sorted(maps.Keys(...)) ensures consistent template ordering ✅
• Lines 65-67: Clean category extraction from display string

pkg/common/flags.go

• Line 47-50: Renamed flag from --template to --template-repo makes the distinction clear

🎯 Recommendations

High Priority

1. Add comprehensive tests for the new catalog functionality
2. Add error handling tests for network failures and malformed JSON

Medium Priority

3. Enhanced error messages for common HTTP failures
4. Retry logic for network requests
5. Path traversal protection in template path handling

Low Priority

6. Consider adding telemetry for template selection patterns
7. Add template validation (ensure paths exist in repo before returning)

🛡️ Security Assessment: Acceptable Risk

• No obvious security vulnerabilities
• External network requests are reasonable for this use case
• Consider adding explicit TLS verification as defense-in-depth

🚀 Performance: Good

• Caching prevents excessive network requests
• Reasonable timeout values
• Memory usage is appropriate for expected JSON sizes

---

Final Verdict: This is a solid implementation that significantly improves the user experience. The main concern is the lack of test coverage, which should be addressed before merging to production.