fix(changelog): use tag range for release notes

.gitea/workflows/auto-tag.yml

@@ -134,11 +134,12 @@ jobs:
             exit 1
           fi
 
-          # Generate changelog for current tag only
+          # Generate changelog for current tag only (range: PREV_TAG..CURRENT_TAG)
           PREV_TAG=$(git tag --sort=-version:refname | grep -E '^v[0-9]+\.[0-9]+\.[0-9]+$' \
             | grep -v "^${CURRENT_TAG}$" | head -1 || echo "")
           if [ -n "$PREV_TAG" ]; then
-            git-cliff --config cliff.toml --tag "$CURRENT_TAG" --strip all > /tmp/release_body.md || true
+            # Generate changelog for current tag only using tag range
+            git-cliff --config cliff.toml --tag "${PREV_TAG}..${CURRENT_TAG}" > /tmp/release_body.md || true
             # Generate full CHANGELOG.md from all tags
             git-cliff --config cliff.toml --output CHANGELOG.md
           else

CHANGELOG.md

@@ -33,7 +33,6 @@ CI, chore, and build changes are excluded.
 - Pin plugin-stronghold npm version to match Rust crate (2.3.1)
 
 ### Features
-- Full copy from apollo_nxt-trcaa with complete sanitization
 - **kube**: Add Kubernetes management support
 
 ## [0.3.12] — 2026-06-05

KUBERNETES_V1.1.0_ASSESSMENT.md

@@ -0,0 +1,321 @@
+# Kubernetes Management Implementation Assessment
+## v1.1.0 Plan Status Report
+
+**Date**: 2026-06-06  
+**Project**: tftsr-devops_investigation  
+**Current Version**: 1.1.0
+
+---
+
+## Executive Summary
+
+The Kubernetes management feature is **partially implemented** with a solid foundation but missing critical runtime functionality. The backend architecture and frontend UI components are in place, but the actual kubectl command execution integration remains incomplete. The feature is **not production-ready** for v1.1.0 release without addressing the critical path items.
+
+---
+
+## Current Implementation Status
+
+### ✅ Implemented Components
+
+#### Backend (Rust)
+| Component | Status | Details |
+|-----------|--------|---------|
+| **ClusterClient struct** | ✅ Complete | Basic cluster metadata storage (id, name, context, server_url, kubeconfig_content) |
+| **PortForwardSession struct** | ✅ Complete | Session tracking with status, pod info, ports, and child process management |
+| **RefreshRegistry** | ✅ Complete | Domain-based data caching infrastructure (not yet utilized) |
+| **6 IPC Commands** | ✅ Complete | `add_cluster`, `remove_cluster`, `list_clusters`, `start_port_forward`, `stop_port_forward`, `list_port_forwards`, `delete_port_forward` |
+| **AppState Extension** | ✅ Complete | Added `clusters`, `port_forwards`, `refresh_registry` to state |
+| **Kubeconfig Parsing** | ✅ Complete | Basic YAML parsing in `shell/kubeconfig.rs` |
+| **kubectl Binary Detection** | ✅ Complete | Locates kubectl in PATH, bundled sidecar, or common paths |
+
+#### Frontend (React)
+| Component | Status | Details |
+|-----------|--------|---------|
+| **KubernetesPage** | ✅ Complete | Main navigation page with tabs for clusters and port forwards |
+| **ClusterList** | ✅ Complete | Displays cluster list with add/remove functionality |
+| **PortForwardList** | ✅ Complete | Shows active port forwards with stop/delete controls |
+| **AddClusterModal** | ✅ Complete | Form for adding clusters via kubeconfig YAML |
+| **PortForwardForm** | ✅ Complete | Form for starting port forwards with cluster/pod/port selection |
+| **TypeScript Types** | ✅ Complete | `ClusterInfo`, `PortForwardRequest`, `PortForwardResponse` in `tauriCommands.ts` |
+
+#### Tests
+| Test Type | Status | Details |
+|-----------|--------|---------|
+| **Rust Tests** | ⚠️ Partial | 308 total tests; kube module has no unit tests |
+| **Frontend Tests** | ⚠️ Partial | 98 total tests; `kubernetesCommands.test.ts` exists (141 lines) |
+
+---
+
+## Critical Missing Features for v1.1.0
+
+### 🚨 Must-Have (Blocker)
+
+#### 1. Port Forward Runtime Execution (CRITICAL)
+**Priority**: BLOCKER  
+**Impact**: Feature is non-functional without this
+
+**Current State**: 
+- `start_port_forward` IPC command creates session metadata but **does not execute kubectl port-forward**
+- Local port is hardcoded to `0` and never assigned
+- No actual kubectl subprocess is spawned
+
+**Required Implementation**:
+```rust
+// In commands/kube.rs: start_port_forward()
+// Current: Creates session but doesn't run kubectl
+// Required:
+let kubectl_path = locate_kubectl()?; // from shell/kubectl.rs
+let kubeconfig_path = get_kubeconfig_path(cluster_id, state)?; // from shell/executor.rs
+
+// Build kubectl command: kubectl port-forward pod -n namespace local_port:container_port
+let args = vec![
+    "port-forward".to_string(),
+    format!("{}/{}", request.namespace, request.pod),
+    format!("{}:{}", local_port, container_port),
+];
+
+// Start subprocess and store child handle in PortForwardSession
+let child = Command::new(kubectl_path)
+    .args(&args)
+    .env("KUBECONFIG", kubeconfig_path)
+    .spawn()?;
+
+session.kubectl_child = Some(Arc::new(Mutex::new(child)));
+```
+
+**Estimate**: 3-4 days
+
+---
+
+#### 2. Kubeconfig Integration (CRITICAL)
+**Priority**: BLOCKER  
+**Impact**: Cannot connect to clusters without this
+
+**Current State**:
+- Clusters are stored in memory with kubeconfig content
+- No integration with database-backed kubeconfig management
+- No way to reference stored kubeconfigs by ID
+
+**Required Implementation**:
+- Store clusters in database with encrypted kubeconfig content
+- Add `kubeconfig_id` field to cluster metadata
+- Link port forwards to stored kubeconfigs
+- Implement kubeconfig rotation and validation
+
+**Estimate**: 2-3 days
+
+---
+
+#### 3. Error Handling & Session Recovery (CRITICAL)
+**Priority**: BLOCKER  
+**Impact**: Poor UX, potential resource leaks
+
+**Current State**:
+- No error reporting from kubectl subprocess
+- Sessions not recovered on app restart
+- No cleanup of orphaned kubectl processes
+
+**Required Implementation**:
+- Capture kubectl stderr/stdout and propagate errors
+- Persist port forward sessions to database
+- Implement session recovery on startup
+- Add cleanup logic in `Drop` implementations
+
+**Estimate**: 2 days
+
+---
+
+### ⚠️ Should-Have (High Priority)
+
+#### 4. Pod Discovery UI (HIGH)
+**Priority**: HIGH  
+**Impact**: Users cannot discover available pods
+
+**Required Implementation**:
+- Add "Discover Pods" button to PortForwardForm
+- Call `kubectl get pods -n <namespace>` to populate pod dropdown
+- Filter pods by status (Running, Pending, etc.)
+
+**Estimate**: 1-2 days
+
+---
+
+#### 5. Multiple Port Support (HIGH)
+**Priority**: HIGH  
+**Impact**: Limited functionality for multi-port pods
+
+**Current State**:
+- Only supports single port forward
+- `local_ports` and `ports` vectors are unused
+
+**Required Implementation**:
+- Support multiple port mappings in UI
+- Allow users to specify multiple container ports
+- Execute multiple kubectl port-forward commands
+
+**Estimate**: 1-2 days
+
+---
+
+#### 6. Cluster Health Monitoring (MEDIUM-HIGH)
+**Priority**: MEDIUM-HIGH  
+**Impact**: No visibility into cluster connectivity
+
+**Required Implementation**:
+- Add "Test Connection" button to cluster list
+- Call `kubectl cluster-info` to verify connectivity
+- Display cluster status (Connected/Disconnected)
+
+**Estimate**: 1 day
+
+---
+
+### 📋 Nice-to-Have (Deferred to v1.2.0+)
+
+#### 7. Advanced Port Forward Features
+- **Port Reuse**: Allow same local port for different clusters
+- **Background Mode**: Keep port forwards running after app close
+- **Port Range**: Support port ranges (e.g., 8080-8090)
+- **Reverse Port Forward**: Support `--reverse` flag
+
+#### 8. Cluster Management Enhancements
+- **Cluster Groups**: Organize clusters by environment (prod/staging/dev)
+- **Cluster Labels**: Add custom labels to clusters
+- **Export/Import**: Export cluster configurations
+
+#### 9. Logging & Diagnostics
+- **kubectl Output Logging**: Show kubectl stdout/stderr in UI
+- **Connection Diagnostics**: Diagnose common kubectl issues
+- **Session History**: Track port forward history
+
+#### 10. Integration with Existing Features
+- **Triage Integration**: Link port forwards to issues
+- **AI Context**: Inject port forward sessions into AI analysis
+- **Audit Logging**: Track all port forward operations
+
+---
+
+## Architectural Concerns
+
+### 1. State Management
+**Issue**: Clusters and port forwards stored in memory only  
+**Risk**: Data loss on app crash/restart  
+**Recommendation**: 
+- Add database persistence layer
+- Implement periodic snapshots
+- Add migration for `clusters` and `port_forwards` tables
+
+### 2. Error Propagation
+**Issue**: kubectl errors not propagated to UI  
+**Risk**: Silent failures, debugging difficulty  
+**Recommendation**:
+- Implement structured error types
+- Add retry logic with exponential backoff
+- Log kubectl output to file for debugging
+
+### 3. Concurrency
+**Issue**: No rate limiting for kubectl commands  
+**Risk**: Resource exhaustion with many port forwards  
+**Recommendation**:
+- Implement concurrent port forward limit
+- Add resource usage monitoring
+- Queue system for command execution
+
+### 4. Security
+**Issue**: Kubeconfig content stored in memory  
+**Risk**: Potential credential exposure  
+**Recommendation**:
+- Use secure memory allocation
+- Clear secrets immediately after use
+- Implement kubeconfig encryption at rest
+
+---
+
+## Implementation Roadmap
+
+### Phase 1: Critical Fixes (5-7 days) - **BLOCKS v1.1.0**
+1. ✅ Implement port forward runtime execution
+2. ✅ Add database persistence for clusters
+3. ✅ Implement error handling and session recovery
+4. ✅ Add cluster health check
+
+### Phase 2: High Priority Enhancements (3-4 days)
+5. ✅ Pod discovery UI
+6. ✅ Multiple port support
+7. ✅ Connection testing
+
+### Phase 3: Polish & Testing (3-4 days)
+8. Unit test coverage for kube module
+9. Integration tests for port forwarding
+10. UI/UX improvements
+11. Documentation
+
+### Phase 4: Future Enhancements (v1.2.0+)
+12. Advanced features (groups, labels, export/import)
+13. Logging and diagnostics
+14. Triage/AI integration
+
+---
+
+## Testing Requirements
+
+### Unit Tests Needed
+- [ ] `kube::client::tests` - ClusterClient serialization
+- [ ] `kube::portforward::tests` - Session lifecycle
+- [ ] `commands::kube::tests` - IPC command handlers
+- [ ] `shell::kubeconfig::tests` - YAML parsing
+
+### Integration Tests Needed
+- [ ] End-to-end port forwarding flow
+- [ ] Multi-cluster management
+- [ ] Error recovery scenarios
+- [ ] Concurrent port forwards
+
+### Frontend Tests Needed
+- [ ] ClusterList integration
+- [ ] PortForwardForm validation
+- [ ] Modal state management
+
+---
+
+## Risk Assessment
+
+| Risk | Probability | Impact | Mitigation |
+|------|-------------|--------|------------|
+| **Port forwards don't work** | 100% | Critical | Implement Phase 1 immediately |
+| **Data loss on restart** | 80% | High | Add database persistence |
+| **kubectl errors silent** | 90% | High | Implement error propagation |
+| **Resource leaks** | 60% | Medium | Add Drop cleanup + tests |
+| **Poor UX** | 70% | Medium | Add pod discovery, health checks |
+
+---
+
+## Recommendation
+
+**DO NOT RELEASE v1.1.0 with current state.**
+
+The Kubernetes management feature is **functionally incomplete**. Users can add clusters and see UI elements, but port forwarding will not work without kubectl execution.
+
+### Path to v1.1.0:
+1. **Implement Phase 1 (Critical)** - 5-7 days
+2. **Add integration tests** - 2 days
+3. **User acceptance testing** - 2 days
+
+**Total additional effort**: ~10 days
+
+### Alternative: Release with Feature Flag
+If timeline is tight:
+- Release v1.1.0 with Kubernetes feature **disabled by default**
+- Add feature flag in settings: `experimental.kubernetes.enabled`
+- Document as "Preview: Requires manual kubectl setup"
+- Enable by default after Phase 1 completion
+
+---
+
+## Conclusion
+
+The Kubernetes management feature has a **solid architectural foundation** but requires critical runtime implementation to be functional. The frontend UI and data models are complete, but the backend execution layer (kubectl subprocess management) is missing.
+
+**Priority Action**: Implement port forward runtime execution with proper error handling and session persistence.
+
+**Estimated v1.1.0 Readiness**: 10-12 days from now with focused development.