docs: sync from docs/wiki/ at commit cd703e2d

AI-Providers.md

@@ -1,6 +1,6 @@
 # AI Providers
 
-TFTSR supports 6+ AI providers, including custom providers with flexible authentication and API formats. API keys are stored encrypted with AES-256-GCM.
+TRCAA supports 6+ AI providers, including custom providers with flexible authentication and API formats. API keys are stored encrypted with AES-256-GCM.
 
 ## Provider Factory
 
@@ -154,11 +154,11 @@ The domain prompt is injected as the first `system` role message in every new co
 
 ---
 
-## 6. Custom Provider (Custom REST & Others)
+## 6. Custom Provider (Multiple API Formats)
 
 **Status:** ✅ **Implemented** (v0.2.6)
 
-Custom providers allow integration with non-OpenAI-compatible APIs. The application supports two API formats:
+Custom providers allow integration with non-OpenAI-compatible APIs. The application supports multiple API formats:
 
 ### Format: OpenAI Compatible (Default)
 
@@ -178,9 +178,42 @@ Standard OpenAI `/chat/completions` endpoint with Bearer authentication.
 
 ---
 
-### Format: Custom REST
+### Format: TFTSR GenAI
 
-**Enterprise AI Gateway** — For AI platforms that use a non-OpenAI request/response format with centralized cost tracking and model access.
+**TFTSR GenAI Gateway** — Enterprise AI gateway with model proxying and cost tracking.
+
+| Field | Value |
+|-------|-------|
+| `config.provider_type` | `"custom"` |
+| `config.api_format` | `"generic-genai"` |
+| Status | ⚠️ **Limited compatibility** |
+
+**Known Limitations:**
+- ❌ **Tool calling not supported**: Gateway returns `503 Service Unavailable` with error `"Gemini Filter Triggered: UNEXPECTED_TOOL_CALL"`
+- ❌ **Shell execution unavailable**: Cannot use `execute_shell_command` or other function calling features
+- ✅ **Basic chat works**: Text-only conversations function correctly
+- ✅ **Workaround parser included**: Attempts to extract tool calls from malformed responses (ChatGPT JSON in `msg` field, Claude XML wrapper)
+
+**Recommendation**: Use **LiteLLM + AWS Bedrock** (see [LiteLLM Setup Guide](LiteLLM-Bedrock-Setup)) or **Ollama** for full tool calling support.
+
+**Root Cause**: TFTSR GenAI gateway applies content filtering that blocks structured tool call responses before they reach the client. This is a gateway-level restriction that cannot be worked around from the client side.
+
+**Configuration (if needed for text-only use):**
+```
+Name:             TFTSR GenAI
+Type:             Custom
+API Format:       TFTSR GenAI
+API URL:          https://your-gateway/api/v2/chat
+Model:            your-model-name
+API Key:          (your API key)
+User ID:          user@example.com (optional, for cost tracking)
+```
+
+---
+
+### Format: Custom REST (Generic)
+
+**Generic Enterprise AI Gateway** — For AI platforms that use a non-OpenAI request/response format with centralized cost tracking and model access.
 
 | Field | Value |
 |-------|-------|
@@ -259,12 +292,67 @@ All providers support the following optional configuration fields (v0.2.6+):
 | `api_format` | `Option<String>` | API format (`openai` or `custom_rest`) | `openai` |
 | `session_id` | `Option<String>` | Session ID for stateful APIs | None |
 | `user_id` | `Option<String>` | User ID for cost tracking (Custom REST gateways) | None |
+| `supports_tool_calling` | `Option<bool>` | Enable function/tool calling | `true` for built-in providers, `false` for custom |
 
 **Backward Compatibility:**
 All fields are optional and default to OpenAI-compatible behavior. Existing provider configurations are unaffected.
 
 ---
 
+## Tool Calling Auto-Detection
+
+**Status:** ✅ **Implemented** (v1.0.9+)
+
+TRCAA can automatically detect whether a custom AI provider supports tool calling (function calling) by sending a test tool call and analyzing the response.
+
+### How It Works
+
+1. Navigate to **Settings → AI Providers** → Add/Edit Custom Provider
+2. Configure your provider (API URL, key, model)
+3. Click **"Auto-Detect Tool Calling Support"** button
+4. System sends a simple test tool call to the provider
+5. Checkbox automatically enabled/disabled based on result
+6. Success/warning message displayed
+
+### Detection Criteria
+
+| Scenario | Result | Explanation |
+|----------|--------|-------------|
+| Provider returns `tool_calls` array with test tool | ✅ Tool calling supported | Checkbox enabled automatically |
+| Provider responds without tool_calls | ⚠️ Not supported | Checkbox disabled automatically |
+| Gateway returns 503 / "tool" error | ⚠️ Blocked at gateway level | Checkbox disabled (e.g., TFTSR GenAI) |
+| Connection/auth/timeout error | ❌ Error displayed | User must fix connection issue |
+
+### Test Tool
+
+The auto-detection sends this minimal tool:
+
+```rust
+{
+  "name": "test_tool",
+  "description": "A test tool that returns 'success'. Call this tool with no arguments.",
+  "parameters": {
+    "type": "object",
+    "properties": {},
+    "required": []
+  }
+}
+```
+
+### Known Limitations
+
+- **TFTSR GenAI**: Gateway blocks tool calls with `503 UNEXPECTED_TOOL_CALL` before they reach the model. Auto-detect correctly identifies this as "not supported."
+- **Small Models**: Models <3B parameters (e.g., `llama3.2:1b`) may respond but describe tools instead of calling them. Auto-detect may return `true` (model capability) but runtime behavior will fail.
+- **Timeout**: Detection uses same timeout as regular chat (60-180s depending on provider). Slow providers may timeout during detection.
+
+### Manual Override
+
+You can always manually toggle the `supports_tool_calling` checkbox:
+- ✅ Enable: For providers you know support tool calling
+- ❌ Disable: For text-only chat without shell execution or integrations
+
+---
+
 ## Adding a New Provider
 
 1. Create `src-tauri/src/ai/{name}.rs` implementing the `Provider` trait

Architecture.md

@@ -2,7 +2,7 @@
 
 ## Overview
 
-TFTSR uses a Tauri 2.x architecture: a Rust backend runs natively, and a React/TypeScript frontend runs in an embedded WebView. Communication between them happens exclusively via typed IPC (`invoke()`).
+TRCAA uses a Tauri 2.x architecture: a Rust backend runs natively, and a React/TypeScript frontend runs in an embedded WebView. Communication between them happens exclusively via typed IPC (`invoke()`).
 
 ```
 ┌─────────────────────────────────────────┐
@@ -229,7 +229,7 @@ Timeline events are stored in the `timeline_events` table (indexed by issue_id a
 
 ```
 1. Initialize tracing (RUST_LOG controls level)
-2. Determine data directory (~/.local/share/tftsr or TFTSR_DATA_DIR)
+2. Determine data directory (~/.local/share/tftsr or TRCAA_DATA_DIR)
 3. Open / create SQLite database (run migrations)
 4. Create AppState (db + settings + app_data_dir)
 5. Register Tauri plugins (stronghold, dialog, fs, shell, http, cli, updater)

CICD-Pipeline.md

@@ -5,17 +5,16 @@
 | Component | URL | Notes |
 |-----------|-----|-------|
 | Gitea | `https://gogs.tftsr.com` / `http://172.0.0.29:3000` | Git server (migrated from Gogs 0.14) |
-| Gitea Actions | Built into Gitea | Native GitHub Actions-compatible CI/CD |
+| Gitea Actions (direct) | `http://gitea.tftsr.com:8084` | v2.x |
+| Gitea Actions (proxy) | `http://gitea.tftsr.com:8085` | nginx reverse proxy |
 | PostgreSQL (Gitea DB) | Container: `gogs_postgres_db` | DB: `gogsdb`, User: `gogs` |
 
-**CI/CD System:** Gitea Actions (v1.22+) with native GitHub Actions API compatibility. Uses `.gitea/workflows/*.yml` for workflow definitions.
-
 ### CI Agents
 
 | Agent | Platform | Host | Purpose |
 |-------|----------|------|---------|
-| `gitea_act_runner_amd64` (Docker) | `linux-amd64` | 172.0.0.29 | Native x86_64 — test builds + amd64/windows release |
+| `gitea_act_runner_amd64` (Docker) | `linux-amd64` | gitea.tftsr.com | Native x86_64 — test builds + amd64/windows release |
-| `act_runner` (systemd) | `linux-arm64` | 172.0.0.29 | Native aarch64 — arm64 release builds |
+| `act_runner` (systemd) | `linux-arm64` | gitea.tftsr.com | Native aarch64 — arm64 release builds |
 | `act_runner` (launchd) | `macos-arm64` | sarman's local Mac | Native Apple Silicon — macOS `.dmg` release builds |
 
 Agent labels configured in `~/.config/act_runner/config.yaml`:
@@ -47,7 +46,7 @@ Rust toolchain, cross-compilers) so that CI jobs skip package installation entir
 2. Confirm all 3 images appear in the Gitea package/container registry at `172.0.0.29:3000`
 3. Only then merge workflow changes that depend on the new image contents
 
-**Server prerequisite — insecure registry** (one-time, on 172.0.0.29):
+**Server prerequisite — insecure registry** (one-time, on gitea.tftsr.com):
 ```sh
 echo '{"insecure-registries":["172.0.0.29:3000"]}' | sudo tee /etc/docker/daemon.json
 sudo systemctl restart docker
@@ -60,7 +59,7 @@ daemon to pull from the local HTTP registry.
 ## Cargo and npm Caching
 
 All Rust and build jobs use `actions/cache@v3` to cache downloaded package artifacts.
-Gitea 1.22 implements the GitHub Actions cache API natively.
+Gitea 1.22 implements the Gitea Actions cache API natively.
 
 **Cargo cache** (Rust jobs):
 ```yaml
@@ -136,7 +135,7 @@ Jobs (run in parallel after autotag):
   build-macos-arm64   → cargo tauri build (aarch64-apple-darwin) — runs on local Mac
                          → {.dmg} uploaded to Gitea release
                          → existing same-name assets are deleted before upload (rerun-safe)
-                         → unsigned; after install run: xattr -cr /Applications/TFTSR.app
+                         → unsigned; after install run: xattr -cr /Applications/TRCAA.app
 ```
 
 **Per-step agent routing (Woodpecker 2.x labels):**
@@ -145,7 +144,7 @@ Jobs (run in parallel after autotag):
 steps:
   - name: build-linux-amd64
     labels:
-      platform: linux/amd64   # → woodpecker_agent on 172.0.0.29
+      platform: linux/amd64   # → woodpecker_agent on gitea.tftsr.com
 
   - name: build-linux-arm64
     labels:
@@ -235,7 +234,7 @@ No DB config path switching needed (unlike Woodpecker 0.15.4).
 After migration, Woodpecker 2.x registers webhooks automatically when a repo is
 activated via the UI. No manual JWT-signed webhook setup required.
 
-1. Log in at `http://172.0.0.29:8085` via Gitea OAuth2
+1. Log in at `http://gitea.tftsr.com:8085` via Gitea OAuth2
 2. Add repo `sarman/tftsr-devops_investigation`
 3. Woodpecker creates webhook in Gitea automatically
 

Database.md

@@ -2,7 +2,7 @@
 
 ## Overview
 
-TFTSR uses **SQLite** via `rusqlite` with the `bundled-sqlcipher` feature for AES-256 encryption in production. 22 versioned migrations are tracked in the `_migrations` table.
+TRCAA uses **SQLite** via `rusqlite` with the `bundled-sqlcipher` feature for AES-256 encryption in production. 22 versioned migrations are tracked in the `_migrations` table.
 
 **DB file location:** `{app_data_dir}/tftsr.db`
 
@@ -13,7 +13,7 @@ TFTSR uses **SQLite** via `rusqlite` with the `bundled-sqlcipher` feature for AE
 | Build type | Encryption | Key |
 |-----------|-----------|-----|
 | Debug (`debug_assertions`) | None (plain SQLite) | — |
-| Release | SQLCipher AES-256 | `TFTSR_DB_KEY` env var |
+| Release | SQLCipher AES-256 | `TRCAA_DB_KEY` (or legacy `TRCAA_DB_KEY`) env var |
 
 **SQLCipher settings (production):**
 - Cipher: AES-256-CBC
@@ -24,7 +24,7 @@ TFTSR uses **SQLite** via `rusqlite` with the `bundled-sqlcipher` feature for AE
 ```rust
 // Simplified init logic
 pub fn init_db(data_dir: &Path) -> anyhow::Result<Connection> {
-    let key = env::var("TFTSR_DB_KEY")
+    let key = env::var("TRCAA_DB_KEY")
         .unwrap_or_else(|_| "dev-key-change-in-prod".to_string());
     let conn = if cfg!(debug_assertions) {
         Connection::open(db_path)?           // plain SQLite
@@ -236,7 +236,7 @@ CREATE TABLE image_attachments (
 
 **Encryption:**
 - OAuth2 tokens encrypted with AES-256-GCM
-- Key derived from `TFTSR_DB_KEY` environment variable
+- Key derived from `TRCAA_DB_KEY` (or legacy `TRCAA_DB_KEY`) environment variable
 - Random 96-bit nonce per encryption
 - Format: `base64(nonce || ciphertext || tag)`
 
@@ -389,96 +389,6 @@ CREATE VIEW IF NOT EXISTS v_image_attachments_with_issue AS
 
 Used by `list_all_log_files` and `list_all_image_attachments` to power the cross-incident Attachments tab in the History page. Explicitly selects named columns (not `SELECT *`) to avoid including the BLOB data in list queries.
 
-### 023 — MCP Resources table (MCP Integration v0.3.0+)
-
-```sql
-CREATE TABLE IF NOT EXISTS mcp_resources (
-    id TEXT PRIMARY KEY,
-    server_id TEXT NOT NULL,
-    uri TEXT NOT NULL,
-    name TEXT NOT NULL,
-    description TEXT,
-    mime_type TEXT,
-    discovered_at TEXT NOT NULL DEFAULT (datetime('now')),
-    FOREIGN KEY(server_id) REFERENCES mcp_servers(id) ON DELETE CASCADE
-);
-CREATE INDEX idx_mcp_resources_server ON mcp_resources(server_id);
-```
-
-Stores resources (files, data sources) exposed by MCP servers for AI agent access.
-
-### 024 — shell_commands table (Shell Execution v1.0.0+)
-
-```sql
-CREATE TABLE IF NOT EXISTS shell_commands (
-    id TEXT PRIMARY KEY,
-    command_template TEXT NOT NULL,
-    tier INTEGER NOT NULL CHECK(tier IN (1, 2, 3)),
-    description TEXT,
-    category TEXT NOT NULL,  -- 'kubectl', 'proxmox', 'general'
-    created_at TEXT NOT NULL DEFAULT (datetime('now'))
-);
-```
-
-Pre-defined command templates with tier classification for the three-tier safety system. See [[Shell-Execution]] for details.
-
-### 025 — kubeconfig_files table (Shell Execution v1.0.0+)
-
-```sql
-CREATE TABLE IF NOT EXISTS kubeconfig_files (
-    id TEXT PRIMARY KEY,
-    name TEXT NOT NULL,
-    encrypted_content TEXT NOT NULL,
-    context TEXT NOT NULL,
-    cluster_url TEXT,
-    is_active INTEGER NOT NULL DEFAULT 0,
-    uploaded_at TEXT NOT NULL DEFAULT (datetime('now'))
-);
-CREATE INDEX idx_kubeconfig_active ON kubeconfig_files(is_active);
-```
-
-Encrypted storage for kubectl configuration files. Content encrypted with AES-256-GCM. Only one config can be active at a time.
-
-### 026 — command_executions table (Shell Execution v1.0.0+)
-
-```sql
-CREATE TABLE IF NOT EXISTS command_executions (
-    id TEXT PRIMARY KEY,
-    issue_id TEXT,
-    command TEXT NOT NULL,
-    tier INTEGER NOT NULL,
-    approval_status TEXT NOT NULL,  -- 'auto', 'approved', 'denied'
-    kubeconfig_id TEXT,
-    exit_code INTEGER,
-    stdout TEXT,
-    stderr TEXT,
-    execution_time_ms INTEGER,
-    executed_at TEXT NOT NULL DEFAULT (datetime('now')),
-    FOREIGN KEY (issue_id) REFERENCES issues(id) ON DELETE CASCADE,
-    FOREIGN KEY (kubeconfig_id) REFERENCES kubeconfig_files(id) ON DELETE SET NULL
-);
-CREATE INDEX idx_command_executions_issue ON command_executions(issue_id);
-CREATE INDEX idx_command_executions_executed ON command_executions(executed_at);
-```
-
-Complete audit trail of all shell command executions with exit codes, stdout/stderr capture, and execution timing.
-
-### 027 — approval_decisions table (Shell Execution v1.0.0+)
-
-```sql
-CREATE TABLE IF NOT EXISTS approval_decisions (
-    id TEXT PRIMARY KEY,
-    command_pattern TEXT NOT NULL,
-    decision TEXT NOT NULL CHECK(decision IN ('allow_once', 'allow_session', 'deny')),
-    session_id TEXT,
-    decided_at TEXT NOT NULL DEFAULT (datetime('now')),
-    expires_at TEXT
-);
-CREATE INDEX idx_approval_decisions_session ON approval_decisions(session_id);
-```
-
-Session-based approval preferences for Tier 2 commands. Allows users to approve similar commands for the duration of a session.
-
 ---
 
 ## Key Design Notes

Development-Setup.md

@@ -28,29 +28,15 @@ Node **v22** required. Install via nvm or system package manager.
 npm install --legacy-peer-deps
 ```
 
-### kubectl Binary (for Shell Execution)
-
-kubectl v1.30.0 is bundled with the application. To download binaries for development:
-
-```bash
-./scripts/download-kubectl.sh linux amd64
-./scripts/download-kubectl.sh linux arm64
-./scripts/download-kubectl.sh darwin arm64
-./scripts/download-kubectl.sh darwin amd64
-./scripts/download-kubectl.sh windows amd64
-```
-
-Binaries are placed in `binaries/kubectl-{os}-{arch}` and bundled via `tauri.conf.json` resources. See [[Shell-Execution]] for runtime usage details.
-
 ---
 
 ## Environment Variables
 
 | Variable | Default | Purpose |
 |----------|---------|---------|
-| `TFTSR_DATA_DIR` | Platform data dir | Override DB location |
+| `TRCAA_DATA_DIR` (or legacy `TRCAA_DATA_DIR`) | Platform data dir | Override DB location |
-| `TFTSR_DB_KEY` | _(none)_ | DB encryption key (required in release builds) |
+| `TRCAA_DB_KEY` (or legacy `TRCAA_DB_KEY`) | _(none)_ | DB encryption key (required in release builds) |
-| `TFTSR_ENCRYPTION_KEY` | _(none)_ | Credential encryption key (required in release builds) |
+| `TRCAA_ENCRYPTION_KEY` (or legacy `TRCAA_ENCRYPTION_KEY`) | _(none)_ | Credential encryption key (required in release builds) |
 | `RUST_LOG` | `info` | Tracing verbosity: `debug`, `info`, `warn`, `error` |
 
 Application data is stored at:
@@ -135,7 +121,7 @@ cargo tauri build
 # Outputs: .deb, .rpm, .AppImage (Linux)
 ```
 
-Release builds enforce secure key configuration. Set both `TFTSR_DB_KEY` and `TFTSR_ENCRYPTION_KEY` before building.
+Release builds enforce secure key configuration. Set both `TRCAA_DB_KEY` (or legacy `TRCAA_DB_KEY`) and `TRCAA_ENCRYPTION_KEY` (or legacy `TRCAA_ENCRYPTION_KEY`) before building.
 
 ---
 

IPC-Commands.md

@@ -603,86 +603,6 @@ interface TicketResult {
 
 ---
 
-## Shell Execution Commands
-
-> **Status:** Fully Implemented (v1.0.0+)
-> 
-> See [[Shell-Execution]] for complete documentation of the three-tier safety system.
-
-### `upload_kubeconfig`
-```typescript
-uploadKubeconfigCmd(name: string, content: string) → string
-```
-Upload and encrypt a kubeconfig file. Returns the kubeconfig ID.
-
-### `list_kubeconfigs`
-```typescript
-listKubeconfigsCmd() → KubeconfigInfo[]
-```
-List all uploaded kubeconfig files with metadata.
-```typescript
-interface KubeconfigInfo {
-    id: string;
-    name: string;
-    context: string;
-    cluster_url?: string;
-    is_active: boolean;
-}
-```
-
-### `activate_kubeconfig`
-```typescript
-activateKubeconfigCmd(id: string) → void
-```
-Set a kubeconfig as active for kubectl commands.
-
-### `delete_kubeconfig`
-```typescript
-deleteKubeconfigCmd(id: string) → void
-```
-Delete a kubeconfig file permanently.
-
-### `respond_to_shell_approval`
-```typescript
-respondToShellApprovalCmd(approvalId: string, decision: string) → void
-```
-Respond to a Tier 2 command approval request.
-- `decision`: `"deny"`, `"allow_once"`, or `"allow_session"`
-
-### `list_command_executions`
-```typescript
-listCommandExecutionsCmd(issueId?: string) → CommandExecution[]
-```
-List recent command executions, optionally filtered by issue ID.
-```typescript
-interface CommandExecution {
-    id: string;
-    command: string;
-    tier: number;  // 1, 2, or 3
-    approval_status: string;  // 'auto', 'approved', 'denied'
-    exit_code?: number;
-    stdout?: string;
-    stderr?: string;
-    execution_time_ms?: number;
-    executed_at: string;
-}
-```
-
-### `check_kubectl_installed`
-```typescript
-checkKubectlInstalledCmd() → KubectlStatus
-```
-Check if kubectl is installed and return version info.
-```typescript
-interface KubectlStatus {
-    installed: boolean;
-    path?: string;
-    version?: string;
-}
-```
-
----
-
 ## Authentication Storage
 
 All integration credentials are stored in the `credentials` table:
@@ -700,7 +620,7 @@ CREATE TABLE credentials (
 
 **Encryption:**
 - Algorithm: AES-256-GCM
-- Key derivation: From `TFTSR_DB_KEY` environment variable
+- Key derivation: From `TRCAA_DB_KEY` (or legacy `TRCAA_DB_KEY`) environment variable
 - Nonce: Random 96-bit per encryption
 - Format: `base64(nonce || ciphertext || tag)`
 

Integrations.md

@@ -83,7 +83,7 @@ Password:         (encrypted with AES-256-GCM)
 ### Implementation Details
 - **API**: ServiceNow Table API (`/api/now/table/incident`)
 - **Auth**: HTTP Basic authentication
-- **Severity mapping**: TFTSR P1-P4 → ServiceNow urgency/impact (1-3)
+- **Severity mapping**: TRCAA P1-P4 → ServiceNow urgency/impact (1-3)
 - **Incident lookup**: Supports both sys_id (UUID) and incident number (INC0010001)
 - **TDD Tests**: 7 tests with mockito HTTP mocking
 
@@ -152,7 +152,7 @@ All integrations using OAuth2 (Confluence, Azure DevOps) follow the same flow:
 
 **Security:**
 - Tokens encrypted at rest with AES-256-GCM (256-bit key)
-- Key derived from environment variable `TFTSR_DB_KEY`
+- Key derived from environment variable `TRCAA_DB_KEY` (or legacy `TRCAA_DB_KEY`)
 - PKCE prevents authorization code interception
 - Callback server only accepts from `localhost`
 

LiteLLM-Bedrock-Setup.md

@@ -1,6 +1,6 @@
 # LiteLLM + AWS Bedrock Setup
 
-This guide covers how to use **Claude via AWS Bedrock** with TFTSR through the LiteLLM proxy, providing an OpenAI-compatible API gateway.
+This guide covers how to use **Claude via AWS Bedrock** with TRCAA through the LiteLLM proxy, providing an OpenAI-compatible API gateway.
 
 ## Why LiteLLM + Bedrock?
 
@@ -89,7 +89,7 @@ Expected response:
 }
 ```
 
-### 4. Configure TFTSR
+### 4. Configure TRCAA
 
 In **Settings → AI Providers → Add Provider**:
 
@@ -182,7 +182,7 @@ curl -s http://localhost:8000/v1/chat/completions \
   -d '{"model": "bedrock-business", "messages": [{"role": "user", "content": "test"}]}'
 ```
 
-### 5. Configure in TFTSR
+### 5. Configure in TRCAA
 
 Add both models as separate providers:
 
@@ -232,7 +232,7 @@ model_list:
       aws_profile_name: ClaudeCodeLP  # Same as Claude Code
 ```
 
-Now both Claude Code and TFTSR use the same Bedrock account without duplicate credential management.
+Now both Claude Code and TRCAA use the same Bedrock account without duplicate credential management.
 
 ---
 
@@ -263,7 +263,7 @@ lsof -i :8000
 litellm --config ~/.litellm/config.yaml --port 8080
 ```
 
-Update the Base URL in TFTSR to match: `http://localhost:8080/v1`
+Update the Base URL in TRCAA to match: `http://localhost:8080/v1`
 
 ### AWS Credentials Not Found
 
@@ -385,7 +385,7 @@ Pricing is identical, but Bedrock provides:
 1. **Master Key** — The `master_key` in config is required but doesn't need to be complex since LiteLLM runs locally
 2. **AWS Credentials** — Never commit `.aws/credentials` or credential process scripts to git
 3. **Local Only** — LiteLLM proxy should only bind to `127.0.0.1` (localhost) — never expose to network
-4. **Audit Logs** — TFTSR logs all AI requests with SHA-256 hashes in the audit table
+4. **Audit Logs** — TRCAA logs all AI requests with SHA-256 hashes in the audit table
 
 ---
 

MCP-Servers.md

@@ -2,7 +2,7 @@
 
 ## Overview
 
-**Model Context Protocol (MCP)** is an open standard that allows AI models to invoke external tools and access external resources through a standardised JSON-RPC interface. TFTSR integrates MCP as a first-class feature, enabling the AI triage assistant to call tools exposed by any compliant MCP server — file search, database queries, monitoring APIs, runbook automation, and more.
+**Model Context Protocol (MCP)** is an open standard that allows AI models to invoke external tools and access external resources through a standardised JSON-RPC interface. TRCAA integrates MCP as a first-class feature, enabling the AI triage assistant to call tools exposed by any compliant MCP server — file search, database queries, monitoring APIs, runbook automation, and more.
 
 MCP support extends the AI's capabilities beyond conversation: during incident triage, the model can autonomously invoke registered tools to gather diagnostic data, check system status, or execute remediation steps — all within the app's security and audit framework.
 
@@ -12,7 +12,7 @@ MCP support extends the AI's capabilities beyond conversation: during incident t
 
 ```
 ┌──────────────────────────────────────────────┐
-│  TFTSR App                                   │
+│  TRCAA App                                   │
 │                                              │
 │  ┌────────┐   ┌──────────┐   ┌───────────┐  │
 │  │Frontend│──▶│ Commands │──▶│  Store    │  │
@@ -127,7 +127,7 @@ The process is spawned via Tokio and wrapped with `rmcp::transport::TokioChildPr
 
 #### Important: PATH for npx/node-based servers
 
-When TFTSR spawns a stdio process from a macOS `.app` bundle, it runs in a **stripped environment** — the system `PATH` is not inherited. Any server that relies on `node`, `npx`, `python`, or other tools found via `PATH` must have it explicitly set.
+When TRCAA spawns a stdio process from a macOS `.app` bundle, it runs in a **stripped environment** — the system `PATH` is not inherited. Any server that relies on `node`, `npx`, `python`, or other tools found via `PATH` must have it explicitly set.
 
 In the **Environment Variables (Plaintext)** field, add:
 
@@ -208,7 +208,7 @@ Navigate to **Settings > MCP Servers** (`/settings/mcp`) to manage servers.
    - **Auth Value** — The token/key (will be encrypted on save). Leave blank for `none`.
    - **Environment Variables (Plaintext)** (stdio only) — Space-separated `KEY=value` pairs for non-sensitive values. **Always include `PATH=...` for `npx`/node/python-based servers** — the app bundle does not inherit the system PATH.
    - **Secure Environment Variables (Encrypted)** (stdio only) — Space-separated `KEY=value` pairs for sensitive values (API keys, tokens). Stored AES-256-GCM encrypted. Leave blank when editing to preserve existing values.
-   - **Custom Headers** (HTTP only) — Space-separated `KEY:value` pairs for custom HTTP headers.
+   - **Custom Headers** (HTTP only) — Not yet supported by the backend transport (currently ignored); do not use for secrets yet.
    - **Enabled** — Toggle on/off.
 3. Click **Save**. The server record is persisted.
 4. Click **Discover** to connect and enumerate available tools and resources.
@@ -293,7 +293,7 @@ See [IPC Commands](IPC-Commands#mcp-servers) for full type signatures.
 
 ## Security
 
-- **Encrypted auth values** — AES-256-GCM, same key derivation as integration credentials (`TFTSR_ENCRYPTION_KEY`)
+- **Encrypted auth values** — AES-256-GCM, same key derivation as integration credentials (`TRCAA_ENCRYPTION_KEY` (or legacy `TRCAA_ENCRYPTION_KEY`))
 - **Server-side scrubbing** — `auth_value` set to `None` before any response to the frontend
 - **Audit logging** — `write_audit_event` called before every MCP tool execution
 - **PII scan** — Tool call arguments are scanned for PII patterns (non-blocking warning to user)

PII-Detection.md

@@ -2,7 +2,7 @@
 
 ## Overview
 
-Before any text is sent to an AI provider, TFTSR scans it for personally identifiable information (PII). Users must review and approve each detected span before the redacted text is transmitted.
+Before any text is sent to an AI provider, TRCAA scans it for personally identifiable information (PII). Users must review and approve each detected span before the redacted text is transmitted.
 
 ## Detection Flow
 

Security-Model.md

@@ -2,7 +2,7 @@
 
 ## Threat Model Summary
 
-TFTSR handles sensitive IT incident data including log files that may contain credentials, PII, and internal infrastructure details. The security model addresses:
+TRCAA handles sensitive IT incident data including log files that may contain credentials, PII, and internal infrastructure details. The security model addresses:
 
 1. **Data at rest** — Database encryption
 2. **Data in transit** — PII redaction before AI send, TLS for all outbound requests
@@ -19,22 +19,22 @@ Production builds use SQLCipher:
 - **KDF:** PBKDF2-HMAC-SHA512, 256,000 iterations
 - **HMAC:** HMAC-SHA512
 - **Page size:** 16384 bytes
-- **Key source:** `TFTSR_DB_KEY` environment variable
+- **Key source:** `TRCAA_DB_KEY` (or legacy `TRCAA_DB_KEY`) environment variable
 
 Debug builds use plain SQLite (no encryption) for developer convenience.
 
-Release builds now fail startup if `TFTSR_DB_KEY` is missing or empty.
+Release builds now fail startup if `TRCAA_DB_KEY` (or legacy `TRCAA_DB_KEY`) is missing or empty.
 
 ---
 
 ## Credential Encryption
 
 Integration tokens are encrypted with AES-256-GCM before persistence:
-- **Key source:** `TFTSR_ENCRYPTION_KEY` (required in release builds)
+- **Key source:** `TRCAA_ENCRYPTION_KEY` (or legacy `TRCAA_ENCRYPTION_KEY`) (required in release builds)
 - **Key derivation:** SHA-256 hash of key material to a fixed 32-byte AES key
 - **Nonce:** Cryptographically secure random nonce per encryption
 
-Release builds fail secure operations if `TFTSR_ENCRYPTION_KEY` is unset or empty.
+Release builds fail secure operations if `TRCAA_ENCRYPTION_KEY` (or legacy `TRCAA_ENCRYPTION_KEY`) is unset or empty.
 
 The Stronghold plugin remains enabled and now uses a per-installation salt derived from the app data directory path hash instead of a fixed static salt.
 
@@ -136,7 +136,7 @@ MCP server support introduces external tool execution capabilities. The followin
 ### Auth Value Storage
 
 - Auth tokens (API keys, bearer tokens, OAuth2 access tokens) are encrypted with **AES-256-GCM** before persistence in `mcp_servers.auth_value`.
-- Encryption uses the same key derivation as integration credentials (`TFTSR_ENCRYPTION_KEY` → SHA-256 → 32-byte AES key).
+- Encryption uses the same key derivation as integration credentials (`TRCAA_ENCRYPTION_KEY` (or legacy `TRCAA_ENCRYPTION_KEY`) → SHA-256 → 32-byte AES key).
 - Random 96-bit nonce per encryption operation.
 - Format: `base64(nonce || ciphertext || tag)`.
 

Shell-Execution.md

@@ -277,7 +277,7 @@ Navigate to **Settings → Shell Execution** to view recent command executions:
 
 ### Encryption
 - **Kubeconfig Files**: AES-256-GCM encryption at rest
-- **Encryption Key**: Derived from `TFTSR_ENCRYPTION_KEY` environment variable
+- **Encryption Key**: Derived from `TRCAA_ENCRYPTION_KEY` (or legacy `TRCAA_ENCRYPTION_KEY`) environment variable
 - **Nonce**: Random 12-byte nonce per encryption operation
 - **Authentication Tag**: 16-byte tag for integrity verification
 

Troubleshooting.md

@@ -175,7 +175,7 @@ sudo apt-get install -y libwebkit2gtk-4.1-dev libssl-dev libgtk-3-dev \
 
 **Symptom:** App fails to start with SQLCipher error.
 
-1. `TFTSR_DB_KEY` env var is set
+1. `TRCAA_DB_KEY` (or legacy `TRCAA_DB_KEY`) env var is set
 2. Key matches what was used when DB was created
 3. File isn't corrupted: `file tftsr.db` should say `SQLite 3.x database`