chore: fix fences errors

config/README.md

@@ -1 +1,109 @@
-# Platform Service Configuration Files\n\nThis directory contains **16 production-ready TOML configuration files** generated from Nickel schemas\nfor all platform services across all deployment modes.\n\n## Generated Files\n\n**4 Services × 4 Deployment Modes = 16 Configuration Files**\n\n```{$detected_lang}\norchestrator.{solo,multiuser,cicd,enterprise}.toml       (2.2 kB each)\ncontrol-center.{solo,multiuser,cicd,enterprise}.toml     (3.4 kB each)\nmcp-server.{solo,multiuser,cicd,enterprise}.toml         (2.7 kB each)\ninstaller.{solo,multiuser,cicd,enterprise}.toml          (2.5 kB each)\n```\n\n**Total**: ~45 KB, all validated and ready for deployment\n\n## Deployment Modes\n\n| Mode | Resources | Database | Use Case | Load |\n| ------ | ----------- | ---------- | ---------- | ------ |\n| **solo** | 2 CPU, 4 GB | Embedded | Development | `ORCHESTRATOR_MODE=solo` |\n| **multiuser** | 4 CPU, 8 GB | PostgreSQL/SurrealDB | Team Staging | `ORCHESTRATOR_MODE=multiuser` |\n| **cicd** | 8 CPU, 16 GB | Ephemeral | CI/CD Pipelines | `ORCHESTRATOR_MODE=cicd` |\n| **enterprise** | 16+ CPU, 32+ GB | SurrealDB HA | Production | `ORCHESTRATOR_MODE=enterprise` |\n\n## Quick Start\n\n### Load a configuration mode\n\n```{$detected_lang}\n# Solo mode (single developer)\nexport ORCHESTRATOR_MODE=solo\nexport CONTROL_CENTER_MODE=solo\n\n# Multiuser mode (team development)\nexport ORCHESTRATOR_MODE=multiuser\nexport CONTROL_CENTER_MODE=multiuser\n\n# Enterprise mode (production HA)\nexport ORCHESTRATOR_MODE=enterprise\nexport CONTROL_CENTER_MODE=enterprise\n```\n\n### Override individual fields\n\n```{$detected_lang}\nexport ORCHESTRATOR_SERVER_WORKERS=8\nexport ORCHESTRATOR_SERVER_PORT=9090\nexport CONTROL_CENTER_REQUIRE_MFA=true\n```\n\n## Configuration Loading Hierarchy\n\nEach service loads configuration with this priority:\n\n1. **Explicit path** — `{SERVICE}_CONFIG` environment variable\n2. **Mode-specific** — `{SERVICE}_MODE` → `provisioning/platform/config/{service}.{mode}.toml`\n3. **Legacy** — `config.user.toml` (backward compatibility)\n4. **Defaults** — `config.defaults.toml` or built-in\n5. **Field overrides** — `{SERVICE}_*` environment variables\n\n## Docker Compose Integration\n\n```{$detected_lang}\nexport DEPLOYMENT_MODE=multiuser\ndocker-compose -f provisioning/platform/infrastructure/docker/docker-compose.yml up\n```\n\n## Kubernetes Integration\n\n```{$detected_lang}\n# Load enterprise mode configs into K8s\nkubectl create configmap orchestrator-config \\n  --from-file=provisioning/platform/config/orchestrator.enterprise.toml\n```\n\n## Validation\n\nVerify all configs parse correctly:\n\n```{$detected_lang}\nfor file in *.toml; do\n    nu -c "open '$file'" && echo "✅ $file" || echo "❌ $file"\ndone\n```\n\n## Structure\n\n- **orchestrator.*.toml** — Workflow engine configuration\n- **control-center.*.toml** — Policy/RBAC backend configuration\n- **mcp-server.*.toml** — MCP server configuration\n- **installer.*.toml** — Installation/bootstrap configuration\n\nEach file contains service-specific settings for networking, storage, security, logging, and monitoring.\n\n## Related Documentation\n\n- **Configuration workflow**: `provisioning/.typedialog/provisioning/platform/configuration-workflow.md`\n- **Usage guide**: `provisioning/.typedialog/provisioning/platform/usage-guide.md`\n- **Schema definitions**: `provisioning/.typedialog/provisioning/platform/schemas/`\n- **Default values**: `provisioning/.typedialog/provisioning/platform/defaults/`\n\n## Generated By\n\n**Framework**: TypeDialog + Nickel Configuration System\n**Date**: 2026-01-05\n**Status**: ✅ Production Ready
+# Platform Service Configuration Files
+
+This directory contains **16 production-ready TOML configuration files** generated from Nickel schemas
+for all platform services across all deployment modes.
+
+## Generated Files
+
+**4 Services × 4 Deployment Modes = 16 Configuration Files**
+
+```toml
+orchestrator.{solo,multiuser,cicd,enterprise}.toml       (2.2 kB each)
+control-center.{solo,multiuser,cicd,enterprise}.toml     (3.4 kB each)
+mcp-server.{solo,multiuser,cicd,enterprise}.toml         (2.7 kB each)
+installer.{solo,multiuser,cicd,enterprise}.toml          (2.5 kB each)
+```
+
+**Total**: ~45 KB, all validated and ready for deployment
+
+## Deployment Modes
+
+| Mode | Resources | Database | Use Case | Load |
+| ------ | ----------- | ---------- | ---------- | ------ |
+| **solo** | 2 CPU, 4 GB | Embedded | Development | `ORCHESTRATOR_MODE=solo` |
+| **multiuser** | 4 CPU, 8 GB | PostgreSQL/SurrealDB | Team Staging | `ORCHESTRATOR_MODE=multiuser` |
+| **cicd** | 8 CPU, 16 GB | Ephemeral | CI/CD Pipelines | `ORCHESTRATOR_MODE=cicd` |
+| **enterprise** | 16+ CPU, 32+ GB | SurrealDB HA | Production | `ORCHESTRATOR_MODE=enterprise` |
+
+## Quick Start
+
+### Load a configuration mode
+
+```toml
+# Solo mode (single developer)
+export ORCHESTRATOR_MODE=solo
+export CONTROL_CENTER_MODE=solo
+
+# Multiuser mode (team development)
+export ORCHESTRATOR_MODE=multiuser
+export CONTROL_CENTER_MODE=multiuser
+
+# Enterprise mode (production HA)
+export ORCHESTRATOR_MODE=enterprise
+export CONTROL_CENTER_MODE=enterprise
+```
+
+### Override individual fields
+
+```javascript
+export ORCHESTRATOR_SERVER_WORKERS=8
+export ORCHESTRATOR_SERVER_PORT=9090
+export CONTROL_CENTER_REQUIRE_MFA=true
+```
+
+## Configuration Loading Hierarchy
+
+Each service loads configuration with this priority:
+
+1. **Explicit path** — `{SERVICE}_CONFIG` environment variable
+2. **Mode-specific** — `{SERVICE}_MODE` → `provisioning/platform/config/{service}.{mode}.toml`
+3. **Legacy** — `config.user.toml` (backward compatibility)
+4. **Defaults** — `config.defaults.toml` or built-in
+5. **Field overrides** — `{SERVICE}_*` environment variables
+
+## Docker Compose Integration
+
+```javascript
+export DEPLOYMENT_MODE=multiuser
+docker-compose -f provisioning/platform/infrastructure/docker/docker-compose.yml up
+```
+
+## Kubernetes Integration
+
+```yaml
+# Load enterprise mode configs into K8s
+kubectl create configmap orchestrator-config 
+  --from-file=provisioning/platform/config/orchestrator.enterprise.toml
+```
+
+## Validation
+
+Verify all configs parse correctly:
+
+```toml
+for file in *.toml; do
+    nu -c "open '$file'" && echo "✅ $file" || echo "❌ $file"
+done
+```
+
+## Structure
+
+- **orchestrator.*.toml** — Workflow engine configuration
+- **control-center.*.toml** — Policy/RBAC backend configuration
+- **mcp-server.*.toml** — MCP server configuration
+- **installer.*.toml** — Installation/bootstrap configuration
+
+Each file contains service-specific settings for networking, storage, security, logging, and monitoring.
+
+## Related Documentation
+
+- **Configuration workflow**: `provisioning/.typedialog/provisioning/platform/configuration-workflow.md`
+- **Usage guide**: `provisioning/.typedialog/provisioning/platform/usage-guide.md`
+- **Schema definitions**: `provisioning/.typedialog/provisioning/platform/schemas/`
+- **Default values**: `provisioning/.typedialog/provisioning/platform/defaults/`
+
+## Generated By
+
+**Framework**: TypeDialog + Nickel Configuration System
+**Date**: 2026-01-05
+**Status**: ✅ Production Ready

crates/control-center-ui/REFERENCE.md

@@ -1 +1,33 @@
-# Control Center UI Reference\n\nThis directory will reference the existing control center UI implementation.\n\n## Current Implementation Location\n\n`/Users/Akasha/repo-cnz/src/control-center-ui/`\n\n## Implementation Details\n\n- **Language**: Web frontend (likely React/Vue/Leptos)\n- **Purpose**: Web interface for system management\n- **Features**:\n  - Dashboard and monitoring UI\n  - Configuration management interface\n  - System administration controls\n\n## Integration Status\n\n- **Current**: Fully functional in original location\n- **New Structure**: Reference established\n- **Migration**: Planned for future phase\n\n## Usage\n\nThe control center UI remains fully functional at its original location.\n\n```{$detected_lang}\ncd /Users/Akasha/repo-cnz/src/control-center-ui\n# Use existing UI development commands\n```\n\nSee original implementation for development setup and usage instructions.
+# Control Center UI Reference
+
+This directory will reference the existing control center UI implementation.
+
+## Current Implementation Location
+
+`/Users/Akasha/repo-cnz/src/control-center-ui/`
+
+## Implementation Details
+
+- **Language**: Web frontend (likely React/Vue/Leptos)
+- **Purpose**: Web interface for system management
+- **Features**:
+  - Dashboard and monitoring UI
+  - Configuration management interface
+  - System administration controls
+
+## Integration Status
+
+- **Current**: Fully functional in original location
+- **New Structure**: Reference established
+- **Migration**: Planned for future phase
+
+## Usage
+
+The control center UI remains fully functional at its original location.
+
+```bash
+cd /Users/Akasha/repo-cnz/src/control-center-ui
+# Use existing UI development commands
+```
+
+See original implementation for development setup and usage instructions.

crates/control-center-ui/upstream-dependency-issue.md

@@ -1 +1,145 @@
-# Upstream Dependency Issue: num-bigint-dig v0.8.4\n\n## Issue Summary\n\n**Status**: ⚠️ **UPSTREAM ISSUE - NON-BLOCKING**\n\nThe control-center-ui build produces a future incompatibility warning from the transitive dependency `num-bigint-dig v0.8.4`:\n\n```{$detected_lang}\nwarning: the following packages contain code that will be rejected by a future version of Rust: num-bigint-dig v0.8.4\nnote: to see what the problems were, use the option `--future-incompat-report`, or run `cargo report future-incompatibilities --id 1`\n```\n\n## Root Cause\n\nThe `num-bigint-dig v0.8.4` crate uses a **private `vec!` macro** in multiple locations (Rust issue #120192).\nThis pattern will become a hard error in a future Rust release.\n\n**Affected files in num-bigint-dig v0.8.4:**\n\n- `src/biguint.rs` (lines 490, 2005, 2027, 2313)\n- `src/prime.rs` (line 138)\n- `src/bigrand.rs` (line 319)\n\n## Dependency Chain\n\n```{$detected_lang}\ncontrol-center-ui (control-center-ui v0.1.0)\n    ↓\nnum-bigint-dig v0.8.4\n    ↑ (pulled in by)\n├── rsa v0.9.9\n│   ├── control-center\n│   ├── jsonwebtoken v10.2.0\n│   └── provisioning-orchestrator\n└── ssh-key v0.6.7\n    ├── russh v0.44.1\n    └── russh-keys v0.44.0\n```\n\n## Why We Can't Fix It\n\n**Option 1: Direct Patch**\n\n- ✗ Cannot patch transitive crates.io dependencies to different crates.io versions\n- Cargo only allows patches to point to different sources (git repos, local paths)\n\n**Option 2: Upgrade rsa**\n\n- Available: `rsa v0.10.0-rc.10` (release candidate only, not stable)\n- Status: Not production-ready until stable release\n- Current: `rsa v0.9.9` (stable, production)\n\n**Option 3: Upgrade ssh-key**\n\n- Current: `ssh-key v0.6.7`\n- Still depends on `num-bigint-dig v0.8.4` (not upgraded yet)\n\n**Option 4: Local Fork**\n\n- ✗ Not practical for transitive dependencies\n\n## Resolution Timeline\n\n**For num-bigint-dig:**\n\n- Available versions: 0.8.5, 0.8.6, 0.9.0, 0.9.1\n- Latest: v0.9.1\n- Status: Fixed in 0.8.6 and later\n- When it gets picked up: Depends on upstream crate releases\n\n**Upstream Action Items:**\n\n1. **rsa crate** needs to upgrade to use newer num-bigint-dig when available\n2. **ssh-key crate** needs to upgrade to use newer num-bigint-dig when available\n3. Once upstream crates update their dependencies, our Cargo.lock will automatically use the fixed version\n\n## Current Impact\n\n✅ **NO IMPACT ON FUNCTIONALITY**\n\n- Code compiles cleanly\n- All tests pass\n- All features work correctly\n- Only a forward-compatibility warning, not an error\n\n✅ **NOT A BLOCKER FOR:**\n\n- Deployment\n- Production use\n- Any functionality\n- WASM compilation\n- Release builds\n\n## Timeline for Resolution\n\n| Status | Item | Estimated |\n| -------- | ------ | ----------- |\n| ✓ Available | num-bigint-dig 0.8.6 | Already released |\n| ⏳ Waiting | rsa v0.10 stable release | 2024-Q4 to 2025-Q1 |\n| ⏳ Waiting | Downstream crate updates | After upstream releases |\n| ✓ Automatic | Our build updates | Once dependencies are updated |\n\n## Monitoring\n\nTo check for updates:\n\n```{$detected_lang}\n# Check for future incompatibilities\ncargo report future-incompatibilities\n\n# Check available versions\ncargo outdated\n\n# Check dependency tree\ncargo tree | grep num-bigint-dig\n```\n\n## Workaround (if needed)\n\nIf the warning becomes an error before upstream fixes are released, you can:\n\n1. **Use an older Rust version** (current stable still allows this as warning)\n2. **Wait for upstream updates** (recommended)\n3. **Create a fork** of rsa/ssh-key with newer num-bigint-dig (not recommended)\n\n## Recommended Action\n\n**No immediate action needed.** This is a normal part of the Rust ecosystem evolution:\n\n- Upstream packages will update their dependencies\n- Our Cargo.lock will automatically resolve to fixed versions\n- Continue monitoring with `cargo report future-incompatibilities`\n\n## References\n\n- Rust Issue #120192: <https://github.com/rust-lang/rust/issues/120192>\n- num-bigint-dig Repository: <https://github.com/dignifiedquire/num-bigint>\n- num-bigint-dig Releases: <https://github.com/dignifiedquire/num-bigint/releases>\n\n---\n\n**Last Updated**: December 12, 2025\n**Status**: Monitored, Non-Blocking\n**Action**: Awaiting Upstream Fixes
+# Upstream Dependency Issue: num-bigint-dig v0.8.4
+
+## Issue Summary
+
+**Status**: ⚠️ **UPSTREAM ISSUE - NON-BLOCKING**
+
+The control-center-ui build produces a future incompatibility warning from the transitive dependency `num-bigint-dig v0.8.4`:
+
+```bash
+warning: the following packages contain code that will be rejected by a future version of Rust: num-bigint-dig v0.8.4
+note: to see what the problems were, use the option `--future-incompat-report`, or run `cargo report future-incompatibilities --id 1`
+```
+
+## Root Cause
+
+The `num-bigint-dig v0.8.4` crate uses a **private `vec!` macro** in multiple locations (Rust issue #120192).
+This pattern will become a hard error in a future Rust release.
+
+**Affected files in num-bigint-dig v0.8.4:**
+
+- `src/biguint.rs` (lines 490, 2005, 2027, 2313)
+- `src/prime.rs` (line 138)
+- `src/bigrand.rs` (line 319)
+
+## Dependency Chain
+
+```bash
+control-center-ui (control-center-ui v0.1.0)
+    ↓
+num-bigint-dig v0.8.4
+    ↑ (pulled in by)
+├── rsa v0.9.9
+│   ├── control-center
+│   ├── jsonwebtoken v10.2.0
+│   └── provisioning-orchestrator
+└── ssh-key v0.6.7
+    ├── russh v0.44.1
+    └── russh-keys v0.44.0
+```
+
+## Why We Can't Fix It
+
+**Option 1: Direct Patch**
+
+- ✗ Cannot patch transitive crates.io dependencies to different crates.io versions
+- Cargo only allows patches to point to different sources (git repos, local paths)
+
+**Option 2: Upgrade rsa**
+
+- Available: `rsa v0.10.0-rc.10` (release candidate only, not stable)
+- Status: Not production-ready until stable release
+- Current: `rsa v0.9.9` (stable, production)
+
+**Option 3: Upgrade ssh-key**
+
+- Current: `ssh-key v0.6.7`
+- Still depends on `num-bigint-dig v0.8.4` (not upgraded yet)
+
+**Option 4: Local Fork**
+
+- ✗ Not practical for transitive dependencies
+
+## Resolution Timeline
+
+**For num-bigint-dig:**
+
+- Available versions: 0.8.5, 0.8.6, 0.9.0, 0.9.1
+- Latest: v0.9.1
+- Status: Fixed in 0.8.6 and later
+- When it gets picked up: Depends on upstream crate releases
+
+**Upstream Action Items:**
+
+1. **rsa crate** needs to upgrade to use newer num-bigint-dig when available
+2. **ssh-key crate** needs to upgrade to use newer num-bigint-dig when available
+3. Once upstream crates update their dependencies, our Cargo.lock will automatically use the fixed version
+
+## Current Impact
+
+✅ **NO IMPACT ON FUNCTIONALITY**
+
+- Code compiles cleanly
+- All tests pass
+- All features work correctly
+- Only a forward-compatibility warning, not an error
+
+✅ **NOT A BLOCKER FOR:**
+
+- Deployment
+- Production use
+- Any functionality
+- WASM compilation
+- Release builds
+
+## Timeline for Resolution
+
+| Status | Item | Estimated |
+| -------- | ------ | ----------- |
+| ✓ Available | num-bigint-dig 0.8.6 | Already released |
+| ⏳ Waiting | rsa v0.10 stable release | 2024-Q4 to 2025-Q1 |
+| ⏳ Waiting | Downstream crate updates | After upstream releases |
+| ✓ Automatic | Our build updates | Once dependencies are updated |
+
+## Monitoring
+
+To check for updates:
+
+```bash
+# Check for future incompatibilities
+cargo report future-incompatibilities
+
+# Check available versions
+cargo outdated
+
+# Check dependency tree
+cargo tree | grep num-bigint-dig
+```
+
+## Workaround (if needed)
+
+If the warning becomes an error before upstream fixes are released, you can:
+
+1. **Use an older Rust version** (current stable still allows this as warning)
+2. **Wait for upstream updates** (recommended)
+3. **Create a fork** of rsa/ssh-key with newer num-bigint-dig (not recommended)
+
+## Recommended Action
+
+**No immediate action needed.** This is a normal part of the Rust ecosystem evolution:
+
+- Upstream packages will update their dependencies
+- Our Cargo.lock will automatically resolve to fixed versions
+- Continue monitoring with `cargo report future-incompatibilities`
+
+## References
+
+- Rust Issue #120192: <https://github.com/rust-lang/rust/issues/120192>
+- num-bigint-dig Repository: <https://github.com/dignifiedquire/num-bigint>
+- num-bigint-dig Releases: <https://github.com/dignifiedquire/num-bigint/releases>
+
+---
+
+**Last Updated**: December 12, 2025
+**Status**: Monitored, Non-Blocking
+**Action**: Awaiting Upstream Fixes

crates/control-center/web/README.md

@@ -1 +1,180 @@
-# Control Center Web UI\n\nReact/TypeScript frontend for the Control Center vault secrets management.\n\n## Features\n\n- **Secrets List**: Browse and filter vault secrets\n- **Secret View**: View secret details with show/hide value toggle\n- **Secret Create/Edit**: Create new secrets or update existing ones\n- **Secret History**: View version history and restore previous versions\n- **Copy to Clipboard**: Easy copy functionality for secret values\n- **Responsive Design**: Works on desktop and mobile devices\n\n## Components\n\n### Core Components\n\n- **SecretsManager**: Main orchestrator component\n- **SecretsList**: List view with pagination and filtering\n- **SecretView**: Detailed secret view with metadata\n- **SecretCreate**: Create/edit form for secrets\n- **SecretHistory**: Version history with restore functionality\n\n### API Client\n\n- **secretsApi**: HTTP client for vault secrets endpoints\n- Type-safe request/response handling\n- Error handling with custom error types\n\n## Prerequisites\n\n- Node.js 18+\n- npm or yarn\n- Control Center backend running on <http://localhost:8080>\n\n## Installation\n\n```{$detected_lang}\ncd provisioning/platform/control-center/web\nnpm install\n```\n\n## Development\n\n```{$detected_lang}\n# Start development server\nnpm start\n\n# Build for production\nnpm build\n\n# Run tests\nnpm test\n\n# Lint code\nnpm run lint\n\n# Format code\nnpm run format\n```\n\n## Environment Variables\n\nCreate a `.env` file in the web directory:\n\n```{$detected_lang}\nREACT_APP_API_URL=http://localhost:8080\n```\n\n## Usage\n\n### Import and Use\n\n```{$detected_lang}\nimport { SecretsManager } from './components/secrets';\n\nfunction App() {\n  return (\n    <div className="app">\n      <SecretsManager />\n    </div>\n  );\n}\n```\n\n### API Client\n\n```{$detected_lang}\nimport { secretsApi } from './api/secrets';\n\n// Create a secret\nconst secret = await secretsApi.createSecret({\n  path: 'database/prod/password',\n  value: 'my-secret-value',\n  context: 'production',\n  metadata: { description: 'Production DB password' },\n});\n\n// Get a secret\nconst secretData = await secretsApi.getSecret('database/prod/password');\n\n// List secrets\nconst { secrets, total } = await secretsApi.listSecrets({\n  prefix: 'database/',\n  limit: 50,\n  offset: 0,\n});\n\n// Update secret\nawait secretsApi.updateSecret('database/prod/password', {\n  value: 'new-secret-value',\n});\n\n// Delete secret\nawait secretsApi.deleteSecret('database/prod/password');\n\n// Get history\nconst history = await secretsApi.getSecretHistory('database/prod/password');\n\n// Restore version\nawait secretsApi.restoreSecretVersion('database/prod/password', 2);\n```\n\n## Architecture\n\n```{$detected_lang}\nSecretsManager (Orchestrator)\n  ├── SecretsList (Browse)\n  ├── SecretView (Detail)\n  ├── SecretCreate (Create/Edit)\n  └── SecretHistory (Versions)\n       ↓\n  secretsApi (HTTP Client)\n       ↓\n  Control Center Backend API\n       ↓\n  KMS Service (Encryption)\n       ↓\n  RustyVault (Storage)\n```\n\n## Security\n\n- **MFA Required**: All secret operations require MFA verification\n- **RBAC**: Role-based access control enforced by backend\n- **Encrypted Storage**: Values encrypted via KMS Service before storage\n- **Audit Trail**: All operations logged for compliance\n- **No Plaintext**: Values never stored unencrypted\n- **Context Encryption**: Optional AAD for additional security\n\n## TypeScript Types\n\nAll components are fully typed. See `src/types/secrets.ts` for type definitions:\n\n- `Secret`: Secret metadata\n- `SecretWithValue`: Secret with decrypted value\n- `SecretVersion`: Version information\n- `SecretHistory`: Complete version history\n- `CreateSecretRequest`: Create request payload\n- `UpdateSecretRequest`: Update request payload\n- `ListSecretsQuery`: List query parameters\n- `ApiError`: Error response type\n\n## Styling\n\nCustom CSS in `src/components/secrets/secrets.css`. Modify to match your design system.\n\n## Browser Support\n\n- Chrome/Edge 90+\n- Firefox 88+\n- Safari 14+\n\n## License\n\nSee project root LICENSE file.\n\n## Contributing\n\nSee project root CONTRIBUTING.md for contribution guidelines.
+# Control Center Web UI
+
+React/TypeScript frontend for the Control Center vault secrets management.
+
+## Features
+
+- **Secrets List**: Browse and filter vault secrets
+- **Secret View**: View secret details with show/hide value toggle
+- **Secret Create/Edit**: Create new secrets or update existing ones
+- **Secret History**: View version history and restore previous versions
+- **Copy to Clipboard**: Easy copy functionality for secret values
+- **Responsive Design**: Works on desktop and mobile devices
+
+## Components
+
+### Core Components
+
+- **SecretsManager**: Main orchestrator component
+- **SecretsList**: List view with pagination and filtering
+- **SecretView**: Detailed secret view with metadata
+- **SecretCreate**: Create/edit form for secrets
+- **SecretHistory**: Version history with restore functionality
+
+### API Client
+
+- **secretsApi**: HTTP client for vault secrets endpoints
+- Type-safe request/response handling
+- Error handling with custom error types
+
+## Prerequisites
+
+- Node.js 18+
+- npm or yarn
+- Control Center backend running on <http://localhost:8080>
+
+## Installation
+
+```bash
+cd provisioning/platform/control-center/web
+npm install
+```
+
+## Development
+
+```bash
+# Start development server
+npm start
+
+# Build for production
+npm build
+
+# Run tests
+npm test
+
+# Lint code
+npm run lint
+
+# Format code
+npm run format
+```
+
+## Environment Variables
+
+Create a `.env` file in the web directory:
+
+```bash
+REACT_APP_API_URL=http://localhost:8080
+```
+
+## Usage
+
+### Import and Use
+
+```bash
+import { SecretsManager } from './components/secrets';
+
+function App() {
+  return (
+    <div className="app">
+      <SecretsManager />
+    </div>
+  );
+}
+```
+
+### API Client
+
+```bash
+import { secretsApi } from './api/secrets';
+
+// Create a secret
+const secret = await secretsApi.createSecret({
+  path: 'database/prod/password',
+  value: 'my-secret-value',
+  context: 'production',
+  metadata: { description: 'Production DB password' },
+});
+
+// Get a secret
+const secretData = await secretsApi.getSecret('database/prod/password');
+
+// List secrets
+const { secrets, total } = await secretsApi.listSecrets({
+  prefix: 'database/',
+  limit: 50,
+  offset: 0,
+});
+
+// Update secret
+await secretsApi.updateSecret('database/prod/password', {
+  value: 'new-secret-value',
+});
+
+// Delete secret
+await secretsApi.deleteSecret('database/prod/password');
+
+// Get history
+const history = await secretsApi.getSecretHistory('database/prod/password');
+
+// Restore version
+await secretsApi.restoreSecretVersion('database/prod/password', 2);
+```
+
+## Architecture
+
+```bash
+SecretsManager (Orchestrator)
+  ├── SecretsList (Browse)
+  ├── SecretView (Detail)
+  ├── SecretCreate (Create/Edit)
+  └── SecretHistory (Versions)
+       ↓
+  secretsApi (HTTP Client)
+       ↓
+  Control Center Backend API
+       ↓
+  KMS Service (Encryption)
+       ↓
+  RustyVault (Storage)
+```
+
+## Security
+
+- **MFA Required**: All secret operations require MFA verification
+- **RBAC**: Role-based access control enforced by backend
+- **Encrypted Storage**: Values encrypted via KMS Service before storage
+- **Audit Trail**: All operations logged for compliance
+- **No Plaintext**: Values never stored unencrypted
+- **Context Encryption**: Optional AAD for additional security
+
+## TypeScript Types
+
+All components are fully typed. See `src/types/secrets.ts` for type definitions:
+
+- `Secret`: Secret metadata
+- `SecretWithValue`: Secret with decrypted value
+- `SecretVersion`: Version information
+- `SecretHistory`: Complete version history
+- `CreateSecretRequest`: Create request payload
+- `UpdateSecretRequest`: Update request payload
+- `ListSecretsQuery`: List query parameters
+- `ApiError`: Error response type
+
+## Styling
+
+Custom CSS in `src/components/secrets/secrets.css`. Modify to match your design system.
+
+## Browser Support
+
+- Chrome/Edge 90+
+- Firefox 88+
+- Safari 14+
+
+## License
+
+See project root LICENSE file.
+
+## Contributing
+
+See project root CONTRIBUTING.md for contribution guidelines.

crates/mcp-server/README.md

@@ -1 +1,135 @@
-# Rust MCP Server for Infrastructure Automation\n\n## Overview\n\nA **Rust-native Model Context Protocol (MCP) server** for infrastructure automation and AI-assisted DevOps operations.\nThis replaces the Python implementation, providing significant performance improvements and maintaining philosophical consistency\nwith the Rust ecosystem approach.\n\n## ✅ Project Status: **PROOF OF CONCEPT COMPLETE**\n\n### 🎯 Achieved Goals\n\n- ✅ **Feasibility Analysis**: Rust MCP server is fully viable\n- ✅ **Functional Prototype**: All core features working\n- ✅ **Performance Benchmarks**: Microsecond-level latency achieved\n- ✅ **Integration**: Successfully integrates with existing provisioning system\n\n### 🚀 Performance Results\n\n```{$detected_lang}\n🚀 Rust MCP Server Performance Analysis\n==================================================\n\n📋 Server Parsing Performance:\n  • 31 chars: 0μs avg\n  • 67 chars: 0μs avg  \n  • 65 chars: 0μs avg\n  • 58 chars: 0μs avg\n\n🤖 AI Status Performance:\n  • AI Status: 0μs avg (10000 iterations)\n\n💾 Memory Footprint:\n  • ServerConfig size: 80 bytes\n  • Config size: 272 bytes\n\n✅ Performance Summary:\n  • Server parsing: Sub-millisecond latency\n  • Configuration access: Microsecond latency\n  • Memory efficient: Small struct footprint\n  • Zero-copy string operations where possible\n```\n\n### 🏗️ Architecture\n\n```{$detected_lang}\nsrc/\n├── simple_main.rs      # Lightweight MCP server entry point\n├── main.rs            # Full MCP server (with SDK integration)\n├── lib.rs             # Library interface\n├── config.rs          # Configuration management\n├── provisioning.rs    # Core provisioning engine\n├── tools.rs           # AI-powered parsing tools\n├── errors.rs          # Error handling\n└── performance_test.rs # Performance benchmarking\n```\n\n### 🎲 Key Features\n\n1. **AI-Powered Server Parsing**: Natural language to infrastructure config\n2. **Multi-Provider Support**: AWS, UpCloud, Local\n3. **Configuration Management**: TOML-based with environment overrides  \n4. **Error Handling**: Comprehensive error types with recovery hints\n5. **Performance Monitoring**: Built-in benchmarking capabilities\n\n### 📊 Rust vs Python Comparison\n\n| Metric | Python MCP Server | Rust MCP Server | Improvement |\n| -------- | ------------------ | ----------------- | ------------- |\n| **Startup Time** | ~500ms | ~50ms | **10x faster** |\n| **Memory Usage** | ~50MB | ~5MB | **10x less** |\n| **Parsing Latency** | ~1ms | ~0.001ms | **1000x faster** |\n| **Binary Size** | Python + deps | ~15MB static | **Portable** |\n| **Type Safety** | Runtime errors | Compile-time | **Zero runtime errors** |\n\n### 🛠️ Usage\n\n```{$detected_lang}\n# Build and run\ncargo run --bin provisioning-mcp-server --release\n\n# Run with custom config\nPROVISIONING_PATH=/path/to/provisioning cargo run --bin provisioning-mcp-server -- --debug\n\n# Run tests\ncargo test\n\n# Run benchmarks  \ncargo run --bin provisioning-mcp-server --release\n```\n\n### 🔧 Configuration\n\nSet via environment variables:\n\n```{$detected_lang}\nexport PROVISIONING_PATH=/path/to/provisioning\nexport PROVISIONING_AI_PROVIDER=openai\nexport OPENAI_API_KEY=your-key\nexport PROVISIONING_DEBUG=true\n```\n\n### 📈 Integration Benefits\n\n1. **Philosophical Consistency**: Rust throughout the stack\n2. **Performance**: Sub-millisecond response times\n3. **Memory Safety**: No segfaults, no memory leaks\n4. **Concurrency**: Native async/await support\n5. **Distribution**: Single static binary\n6. **Cross-compilation**: ARM64/x86_64 support\n\n### 🎪 Demo Integration\n\nThis Rust MCP server is ready to be showcased at the **Rust Meetup 2025** as proof that:\n\n> **"A Rust-first approach to infrastructure automation delivers both performance and safety without compromising functionality."**\n\n### 🚧 Next Steps\n\n1. Full MCP SDK integration (schema definitions)\n2. WebSocket/TCP transport layer\n3. Plugin system for extensibility\n4. Metrics collection and monitoring\n5. Documentation and examples\n\n### 📝 Conclusion\n\n**The Rust MCP Server successfully demonstrates that replacing Python components with Rust provides:**\n\n- ⚡ **1000x performance improvement** in parsing operations\n- 🧠 **10x memory efficiency**\n- 🔒 **Compile-time safety** guarantees\n- 🎯 **Philosophical consistency** with the ecosystem approach\n\nThis validates the **"Rust-first infrastructure automation"** approach for the meetup presentation.
+# Rust MCP Server for Infrastructure Automation
+
+## Overview
+
+A **Rust-native Model Context Protocol (MCP) server** for infrastructure automation and AI-assisted DevOps operations.
+This replaces the Python implementation, providing significant performance improvements and maintaining philosophical consistency
+with the Rust ecosystem approach.
+
+## ✅ Project Status: **PROOF OF CONCEPT COMPLETE**
+
+### 🎯 Achieved Goals
+
+- ✅ **Feasibility Analysis**: Rust MCP server is fully viable
+- ✅ **Functional Prototype**: All core features working
+- ✅ **Performance Benchmarks**: Microsecond-level latency achieved
+- ✅ **Integration**: Successfully integrates with existing provisioning system
+
+### 🚀 Performance Results
+
+```bash
+🚀 Rust MCP Server Performance Analysis
+==================================================
+
+📋 Server Parsing Performance:
+  • 31 chars: 0μs avg
+  • 67 chars: 0μs avg  
+  • 65 chars: 0μs avg
+  • 58 chars: 0μs avg
+
+🤖 AI Status Performance:
+  • AI Status: 0μs avg (10000 iterations)
+
+💾 Memory Footprint:
+  • ServerConfig size: 80 bytes
+  • Config size: 272 bytes
+
+✅ Performance Summary:
+  • Server parsing: Sub-millisecond latency
+  • Configuration access: Microsecond latency
+  • Memory efficient: Small struct footprint
+  • Zero-copy string operations where possible
+```
+
+### 🏗️ Architecture
+
+```bash
+src/
+├── simple_main.rs      # Lightweight MCP server entry point
+├── main.rs            # Full MCP server (with SDK integration)
+├── lib.rs             # Library interface
+├── config.rs          # Configuration management
+├── provisioning.rs    # Core provisioning engine
+├── tools.rs           # AI-powered parsing tools
+├── errors.rs          # Error handling
+└── performance_test.rs # Performance benchmarking
+```
+
+### 🎲 Key Features
+
+1. **AI-Powered Server Parsing**: Natural language to infrastructure config
+2. **Multi-Provider Support**: AWS, UpCloud, Local
+3. **Configuration Management**: TOML-based with environment overrides  
+4. **Error Handling**: Comprehensive error types with recovery hints
+5. **Performance Monitoring**: Built-in benchmarking capabilities
+
+### 📊 Rust vs Python Comparison
+
+| Metric | Python MCP Server | Rust MCP Server | Improvement |
+| -------- | ------------------ | ----------------- | ------------- |
+| **Startup Time** | ~500ms | ~50ms | **10x faster** |
+| **Memory Usage** | ~50MB | ~5MB | **10x less** |
+| **Parsing Latency** | ~1ms | ~0.001ms | **1000x faster** |
+| **Binary Size** | Python + deps | ~15MB static | **Portable** |
+| **Type Safety** | Runtime errors | Compile-time | **Zero runtime errors** |
+
+### 🛠️ Usage
+
+```bash
+# Build and run
+cargo run --bin provisioning-mcp-server --release
+
+# Run with custom config
+PROVISIONING_PATH=/path/to/provisioning cargo run --bin provisioning-mcp-server -- --debug
+
+# Run tests
+cargo test
+
+# Run benchmarks  
+cargo run --bin provisioning-mcp-server --release
+```
+
+### 🔧 Configuration
+
+Set via environment variables:
+
+```javascript
+export PROVISIONING_PATH=/path/to/provisioning
+export PROVISIONING_AI_PROVIDER=openai
+export OPENAI_API_KEY=your-key
+export PROVISIONING_DEBUG=true
+```
+
+### 📈 Integration Benefits
+
+1. **Philosophical Consistency**: Rust throughout the stack
+2. **Performance**: Sub-millisecond response times
+3. **Memory Safety**: No segfaults, no memory leaks
+4. **Concurrency**: Native async/await support
+5. **Distribution**: Single static binary
+6. **Cross-compilation**: ARM64/x86_64 support
+
+### 🎪 Demo Integration
+
+This Rust MCP server is ready to be showcased at the **Rust Meetup 2025** as proof that:
+
+> **"A Rust-first approach to infrastructure automation delivers both performance and safety without compromising functionality."**
+
+### 🚧 Next Steps
+
+1. Full MCP SDK integration (schema definitions)
+2. WebSocket/TCP transport layer
+3. Plugin system for extensibility
+4. Metrics collection and monitoring
+5. Documentation and examples
+
+### 📝 Conclusion
+
+**The Rust MCP Server successfully demonstrates that replacing Python components with Rust provides:**
+
+- ⚡ **1000x performance improvement** in parsing operations
+- 🧠 **10x memory efficiency**
+- 🔒 **Compile-time safety** guarantees
+- 🎯 **Philosophical consistency** with the ecosystem approach
+
+This validates the **"Rust-first infrastructure automation"** approach for the meetup presentation.

docs/deployment/known-issues.md

@@ -1 +1,97 @@
-# Known Issues - Provisioning Platform\n\n## Control-Center Requires Rust Nightly (Edition 2024 Dependency)\n\n**Status**: Resolved (using nightly)\n**Severity**: Low\n**Affects**: Docker deployment only\n**Date Reported**: 2025-10-07\n**Date Resolved**: 2025-10-07\n\n### Issue\n\nControl-center Docker builds fail with the following error:\n\n```{$detected_lang}\nfeature 'edition2024' is required\nthis Cargo does not support nightly features, but if you\nswitch to nightly channel you can add\n`cargo-features = ["edition2024"]` to enable this feature\n```\n\n### Root Cause\n\nDependency chain:\n\n```{$detected_lang}\ncontrol-center → surrealdb 2.3.10 → surrealdb-core 2.3.10 → async-graphql 7.0.17\n```\n\nThe `async-graphql-value` crate v7.0.17 requires Rust edition 2024, which is not yet stable in Rust 1.82.\nEdition 2024 is currently only available in Rust nightly builds.\n\n### Resolution\n\n**Updated Dockerfiles to use Rust nightly** (2025-10-07):\n\nBoth `orchestrator/Dockerfile` and `control-center/Dockerfile` now use:\n\n```{$detected_lang}\nFROM rustlang/rust:nightly-bookworm AS builder\n```\n\nThis provides edition2024 support required by the surrealdb dependency chain.\n\n### Production Considerations\n\n**Rust Nightly Stability**:\n\n- Nightly builds are generally stable for compilation\n- The compiled binaries are production-ready\n- Runtime behavior is not affected by nightly vs stable compilation\n- Consider pinning to a specific nightly date for reproducible builds\n\n**Alternative**: Use native deployment with stable Rust if nightly is a concern:\n\n```{$detected_lang}\ncd provisioning/platform/scripts\nnu run-native.nu build\nnu run-native.nu start-all --background\n```\n\n### Timeline\n\n- **Rust 1.85** (estimated Feb 2025): Expected to stabilize edition 2024\n- **SurrealDB 3.x**: May drop async-graphql dependency\n\n### Tracking\n\n- Rust Edition 2024 RFC: <https://github.com/rust-lang/rfcs/pull/3501>\n- SurrealDB Issue: <https://github.com/surrealdb/surrealdb/issues>\n- async-graphql Issue: <https://github.com/async-graphql/async-graphql/issues>\n\n### Related Files\n\n- `provisioning/platform/control-center/Dockerfile`\n- `provisioning/platform/Cargo.toml` (workspace dependencies)\n- `provisioning/platform/control-center/Cargo.toml`\n\n---\n\n## RocksDB Build Takes Long Time\n\n**Status**: Known Limitation\n**Severity**: Low\n**Affects**: All builds\n\n### Issue\n\nRocksDB compilation takes 30-60 seconds during builds.\n\n### Workaround\n\nUse cached Docker layers or native builds with incremental compilation.\n\n---\n\n**Last Updated**: 2025-10-07
+# Known Issues - Provisioning Platform
+
+## Control-Center Requires Rust Nightly (Edition 2024 Dependency)
+
+**Status**: Resolved (using nightly)
+**Severity**: Low
+**Affects**: Docker deployment only
+**Date Reported**: 2025-10-07
+**Date Resolved**: 2025-10-07
+
+### Issue
+
+Control-center Docker builds fail with the following error:
+
+```bash
+feature 'edition2024' is required
+this Cargo does not support nightly features, but if you
+switch to nightly channel you can add
+`cargo-features = ["edition2024"]` to enable this feature
+```
+
+### Root Cause
+
+Dependency chain:
+
+```bash
+control-center → surrealdb 2.3.10 → surrealdb-core 2.3.10 → async-graphql 7.0.17
+```
+
+The `async-graphql-value` crate v7.0.17 requires Rust edition 2024, which is not yet stable in Rust 1.82.
+Edition 2024 is currently only available in Rust nightly builds.
+
+### Resolution
+
+**Updated Dockerfiles to use Rust nightly** (2025-10-07):
+
+Both `orchestrator/Dockerfile` and `control-center/Dockerfile` now use:
+
+```bash
+FROM rustlang/rust:nightly-bookworm AS builder
+```
+
+This provides edition2024 support required by the surrealdb dependency chain.
+
+### Production Considerations
+
+**Rust Nightly Stability**:
+
+- Nightly builds are generally stable for compilation
+- The compiled binaries are production-ready
+- Runtime behavior is not affected by nightly vs stable compilation
+- Consider pinning to a specific nightly date for reproducible builds
+
+**Alternative**: Use native deployment with stable Rust if nightly is a concern:
+
+```rust
+cd provisioning/platform/scripts
+nu run-native.nu build
+nu run-native.nu start-all --background
+```
+
+### Timeline
+
+- **Rust 1.85** (estimated Feb 2025): Expected to stabilize edition 2024
+- **SurrealDB 3.x**: May drop async-graphql dependency
+
+### Tracking
+
+- Rust Edition 2024 RFC: <https://github.com/rust-lang/rfcs/pull/3501>
+- SurrealDB Issue: <https://github.com/surrealdb/surrealdb/issues>
+- async-graphql Issue: <https://github.com/async-graphql/async-graphql/issues>
+
+### Related Files
+
+- `provisioning/platform/control-center/Dockerfile`
+- `provisioning/platform/Cargo.toml` (workspace dependencies)
+- `provisioning/platform/control-center/Cargo.toml`
+
+---
+
+## RocksDB Build Takes Long Time
+
+**Status**: Known Limitation
+**Severity**: Low
+**Affects**: All builds
+
+### Issue
+
+RocksDB compilation takes 30-60 seconds during builds.
+
+### Workaround
+
+Use cached Docker layers or native builds with incremental compilation.
+
+---
+
+**Last Updated**: 2025-10-07