Chore/bisect

.eslintrc.json

@@ -0,0 +1,36 @@
+{
+  "root": true,
+  "parser": "@typescript-eslint/parser",
+  "parserOptions": {
+    "ecmaVersion": "latest",
+    "sourceType": "module",
+    "project": "./tsconfig.json"
+  },
+  "plugins": ["@typescript-eslint"],
+  "extends": [
+    "eslint:recommended",
+    "plugin:@typescript-eslint/recommended",
+    "plugin:@typescript-eslint/recommended-requiring-type-checking"
+  ],
+  "env": {
+    "es2022": true,
+    "node": true
+  },
+  "rules": {
+    "no-console": "off",
+    "import/extensions": "off",
+    "@typescript-eslint/explicit-module-boundary-types": "off",
+    "@typescript-eslint/no-explicit-any": "warn",
+    "@typescript-eslint/no-unused-vars": ["error", {
+      "argsIgnorePattern": "^_",
+      "varsIgnorePattern": "^_"
+    }],
+    "@typescript-eslint/consistent-type-imports": ["error", {
+      "prefer": "type-imports"
+    }],
+    "no-unused-vars": "off",
+    "quotes": ["error", "single", { "avoidEscape": true }],
+    "semi": ["error", "always"]
+  },
+  "ignorePatterns": ["dist", "node_modules", "*.js", "api-docs"]
+}

.gitignore

@@ -1,19 +1,76 @@
-# Generated by Cargo
-/target/
+# Rust / Cargo
+# Remove Cargo.lock from gitignore if creating an executable, leave it for libraries
+# More information here https://doc.rust-lang.org/cargo/guide/cargo-toml-vs-cargo-lock.html
+debug/
+target/
+**/*.rs.bk
+*.pdb
 
-# Remove Cargo.lock from gitignore if creating an executable
-# Cargo.lock
+# Bun & Node.js
+node_modules/
+.bun/
+bun.lockb
+package-lock.json
+yarn.lock
+npm-debug.log*
+yarn-debug.log*
+yarn-error.log*
+pnpm-debug.log*
 
-# These are backup files generated by rustfmt
-**/*.rs.bk
+# Build output
+dist/
+build/
+out/
+.output/
+*.tsbuildinfo
 
-# MSVC Windows builds of rustc generate these
-*.pdb
+# API documentation
+api-docs/
+
+# TypeScript cache
+.temp/
+.cache/
+
+# IDE and editors
+.idea/
+.vscode/
+*.swp
+*.swo
+*~
+.project
+.classpath
+.settings/
+*.sublime-workspace
+*.sublime-project
+
+# OS specific files
+.DS_Store
+Thumbs.db
+ehthumbs.db
+Desktop.ini
+$RECYCLE.BIN/
+
+# Environment variables
+.env
+.env.local
+.env.development.local
+.env.test.local
+.env.production.local
+
+# Debug files
+.debug/
+debug.log
+
+# Testing
+coverage/
+.nyc_output/
 
-# flyctl reference directory
-/flyctl/
+# Logs
+logs/
+*.log
 
-# Test containers
-tests/containers/*
-!tests/containers/Dockerfile
-!tests/containers/mkosi.default
+# Miscellaneous
+.tmp/
+.turbo/
+.vercel/
+.next/

CLAUDE.md

@@ -1,6 +1,7 @@
 # bbctl Development Guidelines
 
 ## Build & Run Commands
+
 ```bash
 # Build
 cargo build
@@ -25,6 +26,7 @@ cargo clippy
 ```
 
 ## CLI Examples
+
 ```bash
 # List instances
 cargo run -- instances list
@@ -37,25 +39,58 @@ cargo run -- volumes create my-volume --size 10 --region nyc
 
 # Create network
 cargo run -- networks create my-network --cidr 192.168.1.0/24
+
+# Build optimized release version
+cargo build --release
+
+# Check for compilation errors without building
+cargo check
+
+# Run tests
+cargo test
+
+# Run specific test
+cargo test test_name
+
+# Run specific test with output
+cargo test test_name -- --nocapture
 ```
 
 ## Code Style Guidelines
-- **Formatting**: Use `cargo fmt` to format code according to Rust standard style
-- **Linting**: Run `cargo clippy` for static analysis
-- **Naming**: 
-  - Use snake_case for variables, functions, and modules
-  - Use PascalCase for structs, enums, and traits
-- **Error Handling**: Use `AppResult<T>` for functions that can fail
-- **State Management**: Follow the App/AppMode pattern for managing application state
-- **UI Components**: Use Ratatui components (List, Table, Paragraph) with consistent styling
-- **Provider APIs**: VyOS and Proxmox providers should implement common traits
+
+-   **Formatting**: Use `cargo fmt` to format code according to Rust standard style
+
+-   **Linting**: Run `cargo clippy` for static analysis
+
+-   **Naming**:
+
+-   Use snake_case for variables, functions, and modules
+
+-   Use PascalCase for structs, enums, and traits
+
+-   **Error Handling**: Use `AppResult<T>` for functions that can fail
+
+-   **State Management**: Follow the App/AppMode pattern for managing application state
+
+-   **UI Components**: Use Ratatui components (List, Table, Paragraph) with consistent styling
+
+-   **Provider APIs**: VyOS and Proxmox providers should implement common traits
 
 ## Project Structure
-- **src/app.rs**: Core application state and data models
-- **src/event.rs**: Event handling for TUI (keyboard, mouse, resize)
-- **src/handler.rs**: Keyboard event processing
-- **src/tui.rs**: Terminal setup and management
-- **src/ui.rs**: UI rendering and layout components
-- **src/main.rs**: CLI command processing using Clap
-
-Future work includes integrating with actual VyOS and Proxmox APIs and adding E2E encryption for public cloud integration.
+
+-   **src/app.rs**: Core application state and data models
+-   **src/event.rs**: Event handling for TUI (keyboard, mouse, resize)
+-   **src/handler.rs**: Keyboard event processing
+-   **src/tui.rs**: Terminal setup and management
+-   **src/ui.rs**: UI rendering and layout components
+-   **src/main.rs**: CLI command processing using Clap
+
+Future work includes integrating with actual VyOS and Proxmox APIs and adding E2E encryption for public cloud integration.
+
+-   **Imports**: Group imports by crate, with std first, then external, then internal
+-   **Document**: Use three slashes (`///`) for public API documentation
+-   **Async**: Use tokio runtime with futures for async operations
+
+## Project Structure
+
+The app is organized following a typical TUI pattern with app state, event handling, and UI rendering modules. Follow existing patterns when adding new functionality.

Cargo.toml

@@ -30,6 +30,10 @@ env_logger = "0.10"
 indicatif = "0.17"
 openssl = { version = "0.10", features = ["vendored"] }
 
+# API & RPC will be added later
+
+# Networking & Security
+uuid = { version = "1.4", features = ["v4", "serde"] }
 [dev-dependencies]
 assert_cmd = "2.0"
 predicates = "3.0"

PLAN.md

@@ -0,0 +1,105 @@
+# BitBuilder Cloud CLI (bbctl) Implementation Plan
+
+## Overview
+bbctl is a CLI tool for provisioning and managing multi-tenant infrastructure on bare metal servers running VyOS v1.5 or Proxmox. Similar to fly.io's flyctl, bbctl provides a seamless experience for deploying, scaling, and managing applications across distributed infrastructure.
+
+## Architecture
+The architecture consists of multiple components:
+
+1. **Command-line interface (CLI)** - The user-facing interface with subcommands for resource management
+2. **Terminal User Interface (TUI)** - Interactive dashboard for visualizing and managing resources
+3. **API Client** - For communicating with infrastructure providers (VyOS, Proxmox)
+4. **Configuration** - Local config files for storing settings, credentials, and state
+5. **Resource Controllers** - For managing instances, volumes, networks, etc.
+
+## Implementation Phases
+
+### Phase 1: Base Infrastructure Setup
+- Create directory structure for core components
+- Implement VyOS and Proxmox provider interfaces
+- Setup test environment with containers
+- Implement SSH connectivity to provider hosts
+- Basic authentication mechanism
+
+### Phase 2: Resource Management Implementation
+- Complete API for VM/instance management
+- Storage (volume) provisioning and attachment
+- Network creation and configuration
+- IP address management
+
+### Phase 3: TUI Enhancement
+- Improve dashboard with real-time status updates
+- Resource creation wizards
+- Detailed views for resources
+- Settings management
+
+### Phase 4: Multi-Tenancy & Security
+- User and organization management
+- Role-based access control
+- Secure credential management
+- Encryption for data in transit
+
+### Phase 5: CI/CD Integration
+- Deployment workflows
+- Integration with external CI/CD systems
+- Scaling and update policies
+
+## Phase 1 Implementation Details
+
+### 1. Provider Interfaces
+
+#### VyOS Provider
+Create interfaces for managing VyOS routers:
+- SSH-based configuration management using VyOS operational mode
+- HTTP API integration for automated provisioning
+- Configuration templating for standard network setups
+
+#### Proxmox Provider
+Create interfaces for managing Proxmox clusters:
+- REST API integration for VM management
+- Resource allocation and monitoring
+- Template management for quick deployments
+
+### 2. Test Environment
+- Create containerized test environments for local development
+- Mock API responses for testing without actual infrastructure
+- Integration tests with real infrastructure in CI environment
+
+### 3. Authentication
+- Implement authentication mechanisms for VyOS and Proxmox
+- Secure credential storage in local configuration
+- Token-based authentication for API calls
+
+### 4. Basic Commands
+Initial implementation will focus on:
+- `bbctl init` - Initialize a new project
+- `bbctl instances` - List/create/manage VMs
+- `bbctl volumes` - Manage storage
+- `bbctl networks` - Configure virtual networks
+
+## Directory Structure
+```
+bbctl/
+├── src/
+│   ├── api/
+│   │   ├── vyos.rs      # VyOS API client
+│   │   └── proxmox.rs   # Proxmox API client
+│   ├── commands/        # CLI command handlers
+│   ├── models/          # Data models for resources
+│   ├── tui/             # Terminal UI components
+│   ├── main.rs          # Main entry point
+│   └── config.rs        # Configuration management
+├── tests/
+│   ├── integration/     # Integration tests
+│   ├── fixtures/        # Test data
+│   └── containers/      # Test containers
+├── docs/                # Documentation
+└── examples/            # Example configurations
+```
+
+## Next Steps
+1. Implement the VyOS API client with basic authentication
+2. Create test containers for local development
+3. Implement the core resource models and commands
+4. Develop mock backends for testing without real infrastructure
+5. Create initial TUI dashboard components