claude-statusline 2.1.2

package/docs/research-01-sandbox-detection.md

@@ -0,0 +1,169 @@
+# Sandbox Detection Research
+
+## Overview
+
+This document documents research into detecting sandbox environments for statusline indicators, specifically for Claude Code statusline implementations.
+
+## Problem Statement
+
+Claude Code statusline scripts run in a sanitized environment that doesn't receive the actual sandbox environment variables (like `SANDBOX_RUNTIME=1`). This makes automatic sandbox detection challenging.
+
+## Key Findings
+
+### 1. Environment Variable Limitations
+
+**Claude Code Statusline Environment (from debug logs):**
+```
+FEATURE=notset (CLAUDE_CODE_STATUSLINE_SHOW_SANDBOX not available)
+TMPDIR=/var/folders/.../T/ (not /tmp/claude)
+SANDBOX_RUNTIME=notset
+CLAUDE_CODE_ENTRYPOINT=cli
+```
+
+**Available Environment Variables:**
+- `CLAUDE_CODE_ENTRYPOINT=cli` - Entry point indicator
+- `CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1` - **NOT a sandbox indicator** (only disables telemetry)
+
+### 2. Existing Statusline Projects Research
+
+#### Container Detection Approaches (from Starship)
+
+**File-based Detection Methods (Priority Order):**
+1. **/.dockerenv** - Docker container indicator
+2. **/proc/vz** + **/proc/bc** - OpenVZ detection
+3. **/dev/incus/sock** - Incus container socket
+4. **/run/.containerenv** - Podman/Others (parse for name/image)
+5. **/run/systemd/container** - SystemD containers
+6. **/run/host/container-manager** - OCI container manager
+
+**Cross-platform Considerations:**
+- Disabled on non-Linux systems entirely
+- Special handling for WSL with systemd
+
+#### Claude Code Statusline Projects
+
+**Projects Examined:**
+- rz1989s/claude-code-statusline
+- dwillitzer/claude-statusline
+- Owloops/claude-powerline
+- sirmalloc/ccstatusline
+- Ido-Levi/claude-code-tamagotchi
+
+**Key Finding: No existing projects have solved sandbox detection.**
+
+All projects focus on:
+- Configuration detection
+- Git repository detection
+- MCP server monitoring
+- Security (safe file handling, input validation)
+
+None attempt to detect Claude Code's sandbox/restricted mode.
+
+### 3. Container Detection Methods for Adaptation
+
+**Most Reliable Methods:**
+```bash
+# File-based checks (most reliable in restricted environments)
+if [[ -f "/.dockerenv" ]]; then echo "Docker"; fi
+if [[ -d "/proc/vz" ]] && ! [[ -d "/proc/bc" ]]; then echo "OpenVZ"; fi
+if [[ -S "/dev/incus/sock" ]]; then echo "Incus"; fi
+
+# System-based detection
+systemd-detect-virt --container 2>/dev/null
+virt-what 2>/dev/null
+
+# Process namespace analysis
+cat /proc/1/cmdline | tr '\0' ' '
+```
+
+**Environment-based Detection (Less Reliable):**
+```bash
+# Container environment variables
+grep -q "container=" /proc/1/environ
+grep -q docker /proc/1/cgroup
+
+# Kubernetes/OpenShift indicators
+[[ -n "${KUBERNETES_PORT:-}" ]]
+```
+
+### 4. Potential Sandbox Detection Approaches
+
+#### File-based Detection
+- Look for Claude Code-specific files in `/tmp/claude*`
+- Check for restricted filesystem access
+- Test system file readability (`/proc/version`, `/etc/passwd`)
+
+#### Command Availability Testing
+- Sandboxes often restrict system commands
+- Test for `uname`, `ps`, `systemctl` availability
+
+#### Process Namespace Analysis
+- Compare current PID namespace with init process
+- Check if init process looks like system init
+
+#### Resource Limitations
+- Check memory/CPU limits typical of sandboxes
+- Test network access restrictions
+
+## Implementation Challenges
+
+### 1. Environment Isolation
+Claude Code sanitizes the environment passed to statusline scripts, removing sandbox-specific variables.
+
+### 2. False Positives
+Container detection methods might trigger in non-sandbox development environments (Docker development containers, etc.).
+
+### 3. Cross-platform Complexity
+Different methods work on Linux vs macOS vs Windows.
+
+### 4. Performance Impact
+Detection methods must be fast enough for frequent statusline updates.
+
+## Current Implementation Status
+
+### What Works:
+- ✅ Feature toggle via `CLAUDE_CODE_STATUSLINE_SHOW_SANDBOX=1`
+- ✅ Manual sandbox indicator control
+- ✅ Proper icon selection (Nerd Font vs fallback)
+- ✅ Statusline integration
+
+### What Doesn't Work:
+- ❌ Automatic sandbox detection
+- ❌ Environment variable detection (sanitized)
+- ❌ Reliable file-based detection (no Claude Code-specific files found)
+
+### Known Limitations:
+- Claude Code doesn't pass sandbox state to statusline scripts
+- No reliable Claude Code-specific sandbox indicators available
+- Container detection methods designed for containers, not application sandboxing
+
+## Recommendations
+
+### Short-term:
+- Use manual toggle approach with `CLAUDE_CODE_STATUSLINE_SHOW_SANDBOX=1`
+- Document limitation for users
+- Request feature from Claude Code team to pass sandbox state
+
+### Long-term:
+- Implement multiple detection methods with confidence scoring
+- Add configuration for custom detection rules
+- Consider file-based monitoring for Claude Code-specific patterns
+
+## Future Research Directions
+
+1. **Claude Code Internal APIs**: Check if Claude Code exposes sandbox state through other means
+2. **Process Monitoring**: Monitor Claude Code process characteristics
+3. **Filesystem Analysis**: Look for Claude Code sandbox artifacts
+4. **Network Behavior**: Analyze network patterns in sandboxed vs non-sandboxed modes
+5. **Resource Usage**: Monitor memory/CPU patterns unique to sandboxed execution
+
+## References
+
+- [Starship Container Module](https://github.com/starship/starship)
+- [Claude Code Documentation](https://code.claude.com/docs)
+- [Container Detection Methods](https://github.com/moby/moby/issues/18390)
+- [SystemD Detection](https://www.freedesktop.org/software/systemd/man/systemd-detect-virt.html)
+
+---
+
+**Note:** This represents current research as of the investigation date. Sandbox detection methods may evolve with Claude Code updates.

package/docs/research-02-competitive-analysis.md

@@ -0,0 +1,226 @@
+# Competitive Analysis Research
+
+## Overview
+
+This document provides a comprehensive competitive analysis of existing Claude Code statusline projects to identify feature gaps, market positioning, and strategic opportunities for our statusline implementation.
+
+## Methodology
+
+**Projects Analyzed:**
+- rz1989s/claude-code-statusline
+- dwillitzer/claude-statusline
+- Owloops/claude-powerline
+- sirmalloc/ccstatusline
+- Ido-Levi/claude-code-tamagotchi
+
+**Analysis Criteria:**
+Feature comparison across 15 dimensions including performance, customization, environment support, and unique capabilities.
+
+**Research Date:** November 2025
+
+## Competitive Landscape Matrix
+
+### Complete Feature Comparison
+
+| **Criteria** | **rz1989s** | **dwillitzer** | **Owloops** | **sirmalloc** | **Ido-Levi** | **Our Project** |
+|--------------|------------|---------------|-------------|---------------|--------------|-----------------|
+| **Enhanced Environment Support** | Extensive (8+ envs) | Basic | Good | Good | Basic | Node.js, Python, Docker + sandbox detection |
+| **Color Theme Support** | Excellent (18+ themes) | Good | Excellent (5+ themes) | Excellent | Basic | ASCII/Nerd Font modes |
+| **Custom Format Strings** | Outstanding (227+ TOML) | Excellent (templates) | Very Good | Excellent | Basic | Environment variables only |
+| **Performance Optimization** | Exceptional (<50ms) | Good (<50ms) | Good (~80ms) | Good (~80ms) | Fair (AI overhead) | ~99ms (36ms optimized) |
+| **Parallel Processing** | Advanced (concurrent) | Basic | Good | Good | Basic | Sequential |
+| **Automated Testing** | Comprehensive (77+ tests) | Limited | Good | Good | Basic | Manual testing |
+| **Installation Scripts** | Outstanding (3-tier system) | Good | Excellent (npx) | Excellent (npx) | Good | Manual setup |
+| **Documentation Quality** | Outstanding | Good | Very Good | Excellent | Very Good | Comprehensive docs |
+| **Plugin Architecture** | Advanced (18 components) | Limited | Good | Excellent | Basic | Monolithic |
+| **Configuration Files** | Outstanding (TOML) | Good | Very Good | Excellent | Good | Environment variables |
+| **Sandbox Detection** | Good (restricted env) | Basic | Basic | Good | Basic | **Unique research area** |
+| **Git Integration Depth** | Exceptional (advanced) | Basic | Very Good | Excellent | Basic | Comprehensive indicators |
+| **Terminal Compatibility** | Outstanding | Good | Very Good | Excellent | Good | Cross-platform optimized |
+| **Cross-platform Support** | Excellent | Good | Very Good | Outstanding | Good | macOS/Linux |
+| **Error Handling** | Exceptional | Good | Good | Very Good | Good | Robust validation |
+
+## Market Segmentation Analysis
+
+### **Category 1: Enterprise-Grade Solutions**
+**rz1989s/claude-code-statusline**
+- **Strengths:** 227+ configuration options, enterprise caching, comprehensive testing
+- **Target:** Enterprise users, complex workflows
+- **Codebase:** 1000+ lines, TypeScript planned
+- **Performance:** Sub-50ms with universal caching
+
+### **Category 2: Specialized Solutions**
+
+**sirmalloc/ccstatusline**
+- **Strengths:** TUI interface, Windows support, powerline features
+- **Target:** Interactive configuration users, Windows developers
+- **Codebase:** React-based, widget system
+- **Performance:** ~80ms with async operations
+
+**Ido-Levi/claude-code-tamagotchi**
+- **Strengths:** AI-powered behavioral enforcement, virtual pet concept
+- **Target:** Gamification enthusiasts, productivity hackers
+- **Codebase:** AI integration with Groq API
+- **Performance:** Variable (AI processing overhead)
+
+**dwillitzer/claude-statusline**
+- **Strengths:** Multi-provider AI support, intelligent token counting
+- **Target:** Multi-AI platform users
+- **Codebase:** Provider-agnostic design
+- **Performance:** <50ms optimized
+
+### **Category 3: Balanced Solutions**
+
+**Owloops/claude-powerline**
+- **Strengths:** Powerline aesthetics, good customization
+- **Target:** Visual customization enthusiasts
+- **Codebase:** Modular widget system
+- **Performance:** ~80ms with caching
+
+## Feature Saturation Analysis
+
+### 🔴 **TABLE STAKES - Universal Features**
+These features are implemented by all major projects and are considered baseline expectations:
+
+- **Performance <100ms:** All projects achieve sub-100ms response times
+- **Cross-platform Support:** Universal macOS/Linux compatibility
+- **Basic Git Integration:** Git repository status detection is standard
+- **Environment Variables:** All projects support environment variable configuration
+- **Terminal Compatibility:** Basic emoji/ASCII fallback support
+
+### 🟡 **COMPETITIVE DIFFERENTIATORS - High Adoption**
+These features are implemented by 60-80% of advanced projects:
+
+- **Color Theme Support (80%):** 4/5 projects offer multiple themes
+  - rz1989s: 18+ themes including Catppuccin variants
+  - Owloops: 5 built-in themes (dark, light, nord, tokyo-night, rose-pine)
+  - sirmalloc: Multiple themes with ANSI/256/truecolor
+  - dwillitzer: Provider-aware color coding
+
+- **Custom Format Strings (80%):** 4/5 advanced projects offer user-defined formats
+  - rz1989s: 227+ TOML settings with template variables
+  - sirmalloc: Interactive TUI with custom widgets
+  - dwillitzer: Template system with %model%, %context%, %project%
+  - Owloops: CLI flags and config file templates
+
+- **Enhanced Environment Support (60%):** 3/5 projects detect multiple runtimes
+  - rz1989s: Node.js, Python, Docker, Ruby, Go, Rust, Java
+  - Owloops: Multiple development environments
+  - sirmalloc: Node.js, Bun, Python, Git environments
+
+### 🟢 **BLUE OCEAN OPPORTUNITIES - Unique Differentiators**
+These features represent unique market positioning opportunities:
+
+- **Sandbox Detection:** **Only our project is actively researching this**
+- **AI Integration:** Only Ido-Levi offers AI-powered statusline analysis
+- **Enterprise Caching:** Only rz1989s provides enterprise-grade universal caching
+- **Powerline Support:** Only sirmalloc and Owloops implement powerline aesthetics
+- **Multi-provider Support:** Only dwillitzer supports multiple AI providers
+
+## Strategic Positioning Analysis
+
+### **Our Competitive Advantages**
+
+1. **Unique Research Focus:** Sandbox detection is an unsolved problem
+2. **Academic Documentation:** Research-driven approach differentiates from feature-focused competitors
+3. **Focused Simplicity:** 284 lines vs competitors' 1000+ lines maintainability
+4. **Security-First Design:** Robust input validation and command injection protection
+5. **Performance Clarity:** Transparent performance metrics and optimization strategies
+
+### **Market Position**
+**"The Security-Focused Research-Driven Statusline"**
+
+- Differentiates through academic approach to unsolved problems
+- Targets security-conscious developers and enterprise environments
+- Positions as the most thoroughly documented and analyzed solution
+
+## Implementation Gap Analysis
+
+### **HIGH PRIORITY - Competitive Necessity**
+Missing features that create competitive disadvantage:
+
+1. **Color Theme Support**
+   - **Competitive Gap:** 4/5 major projects implement this
+   - **Implementation Effort:** Medium - requires color system architecture
+   - **User Impact:** High - visual customization is highly valued
+   - **Timeline:** 2-3 weeks for basic implementation
+
+2. **Custom Format Strings**
+   - **Competitive Gap:** 4/5 advanced projects offer this
+   - **Implementation Effort:** High - requires configuration system redesign
+   - **User Impact:** High - customization flexibility expected by power users
+   - **Timeline:** 4-6 weeks for comprehensive implementation
+
+### **MEDIUM PRIORITY - Market Differentiation**
+Features that strengthen competitive position:
+
+3. **Enhanced Environment Support**
+   - **Competitive Gap:** Behind rz1989s, ahead of dwillitzer/Ido-Levi
+   - **Implementation Effort:** Low-Medium - leverage existing detection patterns
+   - **User Impact:** Medium - valuable for polyglot environments
+   - **Timeline:** 1-2 weeks for Ruby/Go/Rust support
+
+4. **Parallel Processing**
+   - **Competitive Gap:** Only rz1989s has advanced concurrent operations
+   - **Implementation Effort:** High - requires architecture redesign
+   - **User Impact:** Medium-High - performance improvement
+   - **Timeline:** 3-4 weeks for full concurrent implementation
+
+### **LOW PRIORITY - Strategic Innovation**
+Unique differentiator investments:
+
+5. **Sandbox Detection Completion**
+   - **Competitive Gap:** **Blue Ocean - no competitors**
+   - **Implementation Effort:** Medium - research foundation exists
+   - **User Impact:** High - solves unique Claude Code problem
+   - **Timeline:** 2-3 weeks for production implementation
+
+## Development Roadmap Recommendations
+
+### **Phase 1: Competitive Parity (Weeks 1-4)**
+1. **Week 1-2:** Implement basic color theme system
+2. **Week 3-4:** Add custom format string support
+3. **Outcome:** Feature parity with 80% of competitors
+
+### **Phase 2: Strategic Differentiation (Weeks 5-8)**
+1. **Week 5-6:** Complete sandbox detection implementation
+2. **Week 7-8:** Enhanced environment support (Ruby, Go, Rust)
+3. **Outcome:** Unique market position with competitive feature set
+
+### **Phase 3: Performance Optimization (Weeks 9-12)**
+1. **Week 9-10:** Parallel processing architecture
+2. **Week 11-12:** Advanced performance optimizations
+3. **Outcome:** Performance leadership alongside feature completeness
+
+## Success Metrics
+
+### **Adoption Metrics**
+- GitHub stars growth rate vs competitors
+- Issue resolution time and community engagement
+- Documentation quality assessments
+
+### **Technical Metrics**
+- Performance benchmarks (target: <50ms full feature set)
+- Code maintainability (lines of code vs feature complexity)
+- Test coverage (target: 80%+ for new features)
+
+### **Market Position Metrics**
+- Feature completeness score vs competitors
+- Unique differentiator recognition (sandbox detection)
+- Security and documentation standards leadership
+
+## Conclusion
+
+The competitive analysis reveals a crowded but fragmented market with clear opportunities for differentiation. Our project's unique research-driven approach and focus on unsolved problems (sandbox detection) provides a strong foundation for market positioning.
+
+**Key Strategic Insights:**
+1. **Immediate Need:** Color themes and custom formats for competitive parity
+2. **Unique Opportunity:** Sandbox detection as blue ocean differentiator
+3. **Market Position:** Security-focused, research-driven statusline solution
+4. **Competitive Advantage:** Academic documentation and problem-solving approach
+
+The recommended implementation roadmap prioritizes competitive necessity while building toward unique market differentiation through innovative research and security-focused design.
+
+---
+
+**Note:** This analysis represents the competitive landscape as of November 2025. The statusline ecosystem evolves rapidly, and competitive positions may shift with new releases and feature additions.

package/docs/research-03-platform-analysis.md

@@ -0,0 +1,142 @@
+# Platform Distribution Analysis and Windows Support Decision
+
+## Executive Summary
+
+This document analyzes the platform distribution of CLI tool users and provides justification for focusing on Unix-like systems (macOS, Linux, WSL) rather than providing native Windows support for the TypeScript rewrite of claude-statusline.
+
+## Research Findings
+
+### 1. Official Claude Code CLI Platform Support
+- **macOS 10.15+**
+- **Linux (Ubuntu 20.04+/Debian 10+)**
+- **Windows 10+** via WSL 1/2 or Git for Windows
+
+### 2. Developer Platform Statistics (2024-2025)
+
+#### Operating System Distribution
+- **Windows**: 59.2% (personal), 47.8% (professional)
+- **macOS**: 31.8% (personal), 31.8% (professional)
+- **Linux distributions**: ~27-28% (Ubuntu being the most popular)
+- **WSL specifically**: 17.1% (personal), 16.8% (professional)
+
+#### Node.js/npm Platform Distribution
+- **Linux**: 78% of downloads
+- **Windows**: 17% of downloads
+- **macOS**: 5% of downloads
+
+### 3. Windows Developer Behavior Patterns
+
+#### WSL Adoption Trends
+- Rapid growth between 2021-2023
+- WSL is now open source (Microsoft Build 2025)
+- 17% of developers use WSL as their primary development environment
+
+#### Terminal Tool Preferences on Windows
+1. **WSL**: Provides authentic Linux environment at kernel level
+   - Preferred by professional developers for CLI tools
+   - Full Linux integration, not just emulation
+   - Seamlessly runs Unix-like tools
+
+2. **Git Bash**: Simple but limited
+   - "Painfully slow" for complex operations
+   - Basic Unix command support
+   - Not a true Linux environment
+
+3. **PowerShell**: Powerful but different paradigm
+   - Windows-native, object-oriented pipeline
+   - Incompatible with Unix-like tool conventions
+   - Requires Windows-specific adaptations
+
+### 4. CLI Tool Usage Patterns
+
+#### Evidence from Community
+- Multiple third-party guides for running Claude Code on Windows via WSL
+- Reddit threads show confusion about native Windows support
+- General consensus: "Claude Code requires macOS or Linux to run properly"
+- Windows users actively seek WSL solutions for CLI tools
+
+#### Node.js Ecosystem Insight
+- 78% Linux downloads suggest serious CLI development happens on Unix-like systems
+- Professional developers prefer Unix-like environments for Node.js development
+- CLI tool ecosystem primarily targets Unix-like systems
+
+## Decision: Target Unix-Like Systems Only
+
+### Rationale
+
+1. **WSL Covers Windows Developers**
+   - Most Windows developers using CLI tools already use WSL
+   - WSL provides a genuine Linux environment where Unix tools work natively
+   - No loss of functionality for Windows users willing to use WSL
+
+2. **Complexity vs Benefit**
+   - Native Windows support requires significant complexity
+   - Cross-platform abstractions (like simple-git) add overhead
+   - Minimal user base for native Windows CLI tools
+
+3. **Performance Optimization**
+   - Eliminating Windows-specific code improves performance
+   - Simpler code base is easier to optimize and maintain
+   - Unix-only implementation is more efficient
+
+4. **Development Velocity**
+   - Focus on primary use case (95% of users)
+   - Reduced testing surface
+   - Faster iteration and improvements
+
+### Implementation Strategy
+
+#### Phase 1: Remove Windows-Specific Code
+1. Replace simple-git with native git commands using `child_process.spawn`
+2. Remove Windows-specific path handling
+3. Simplify git operations for Unix-like systems only
+4. Add proper error messages for native Windows users directing to WSL
+
+#### Phase 2: Update Documentation
+1. Document WSL as the recommended Windows approach
+2. Update system requirements to clarify Unix-like focus
+3. Add installation guide for WSL setup
+4. Remove references to Git Bash/PowerShell support
+
+#### Phase 3: Communication (Future Release)
+1. Frame as performance optimization, not dropping support
+2. Emphasize that existing WSL users are unaffected
+3. Provide clear migration path for any Windows users
+
+## Impact Analysis
+
+### Benefits
+- **Performance**: 5ms improvement from simple-git removal (per performance optimization plan)
+- **Simplicity**: Reduced code complexity and maintenance burden
+- **Testing**: Fewer platform combinations to test
+- **Development**: Faster feature development and bug fixes
+
+### Risks
+- **Minimal**: Windows CLI developers already use WSL
+- **Mitigation**: Clear documentation and helpful error messages
+- **Fallback**: Can reconsider if significant demand emerges
+
+## Sources
+- Stack Overflow Developer Survey 2024-2025
+- Node.js Statistics 2024-2025
+- Microsoft Build 2025 announcements
+- WSL adoption trend analysis
+- Claude Code GitHub issues and community discussions
+- Terminal tool usage patterns research
+
+## Conclusion
+
+The data strongly supports focusing on Unix-like systems for the TypeScript rewrite. WSL provides adequate coverage for Windows developers who need CLI tools, while eliminating native Windows support significantly simplifies the code base and improves performance.
+
+This decision aligns with the broader trend in the developer ecosystem where professional Windows developers increasingly use WSL for Unix-like tooling, and the Node.js ecosystem's strong Linux preference (78% of downloads).
+
+## Next Steps for simple-git Replacement
+
+Based on this analysis and the performance optimization plan in `docs/prd-01-typescript-perf-optimization.md`:
+
+1. **Replace simple-git** with native `child_process.spawn` commands (5ms improvement)
+2. **Remove Windows-specific code** and path handling complexity
+3. **Update documentation** to clarify WSL as the recommended Windows approach
+4. **Keep existing parsing logic** - only the command execution needs to change
+
+The implementation is already outlined in Phase 1, Task 1.1 of the performance optimization plan, indicating it's a straightforward change.

package/package.json

@@ -0,0 +1,89 @@
+{
+  "name": "claude-statusline",
+  "version": "2.1.2",
+  "description": "Simple statusline for Claude Code with git indicators. TypeScript rewrite for performance and npm distribution.",
+  "main": "dist/index.bundle.js",
+  "bin": {
+    "claude-statusline": "bin/claude-statusline"
+  },
+  "type": "module",
+  "scripts": {
+    "build": "tsc",
+    "build:bundle": "node esbuild.config.js",
+    "build:prod": "node esbuild.prod.config.js && npm run build:types",
+    "build:types": "tsc --emitDeclarationOnly",
+    "dev": "tsc --watch",
+    "dev:bundle": "node esbuild.config.js --watch",
+    "start": "node dist/index.js",
+    "start:bundle": "node dist/index.js",
+    "test": "node --test --experimental-strip-types tests/**/*.test.ts",
+    "test:bundle": "npm run build:bundle && npm test",
+    "lint": "eslint src/**/*.ts",
+    "format": "prettier --write src/**/*.ts",
+    "benchmark": "node scripts/benchmark.js",
+    "benchmark:bundle": "npm run build:bundle && npm run benchmark",
+    "prepublishOnly": "npm run build:prod && npm test",
+    "bun:build": "bun build src/index.ts --outdir dist --target node",
+    "bun:build:bundle": "node esbuild.config.js",
+    "bun:dev": "bun --watch src/index.ts",
+    "bun:start": "bun src/index.ts",
+    "bun:start:bundle": "bun dist/index.js",
+    "bun:test": "bun test tests/**/*.test.ts",
+    "bun:benchmark": "bun scripts/benchmark.js",
+    "bun:benchmark:bundle": "npm run build:bundle && bun scripts/benchmark.js"
+  },
+  "keywords": [
+    "claude-code",
+    "statusline",
+    "git",
+    "cli",
+    "terminal",
+    "productivity"
+  ],
+  "author": "shrwnsan",
+  "license": "Apache-2.0",
+  "repository": {
+    "type": "git",
+    "url": "https://github.com/shrwnsan/claude-statusline.git"
+  },
+  "bugs": {
+    "url": "https://github.com/shrwnsan/claude-statusline/issues"
+  },
+  "homepage": "https://github.com/shrwnsan/claude-statusline#readme",
+  "engines": {
+    "node": ">=22.6.0",
+    "bun": ">=1.0.0"
+  },
+  "dependencies": {
+    "yaml": "^2.6.1",
+    "zod": "^3.23.8"
+  },
+  "devDependencies": {
+    "@types/node": "^22.10.1",
+    "@typescript-eslint/eslint-plugin": "^8.18.0",
+    "@typescript-eslint/parser": "^8.18.0",
+    "esbuild": "^0.27.1",
+    "eslint": "^9.17.0",
+    "eslint-config-prettier": "^9.1.0",
+    "eslint-plugin-prettier": "^5.2.1",
+    "prettier": "^3.4.2",
+    "typescript": "^5.7.2"
+  },
+  "files": [
+    "dist/",
+    "bin/",
+    "README.md",
+    "LICENSE",
+    "docs/"
+  ],
+  "exports": {
+    ".": {
+      "import": "./dist/index.bundle.js",
+      "types": "./dist/index.d.ts"
+    },
+    "./config": {
+      "import": "./dist/core/config.js",
+      "types": "./dist/core/config.d.ts"
+    }
+  }
+}