@hybridlabor-api/aos 4.4.1 → 4.4.2-beta.1

package/skills/global_config/bdb-ecosystem-health/SKILL.md

@@ -1,68 +0,0 @@
----
-name: bdb-ecosystem-health
-description: Use when auditing the BDB Ecosystem. Verifies 8 repositories for Git/NPM version drift and CI/CD status, generates HTML reports, and executes auto-remediation.
-category: saas-ops
----
-
-# BDB Ecosystem Health Skill
-
-This skill monitors and maintains 100% operational integrity across all 8 repositories in the BDB Ecosystem.
-
-## Overview
-Autonomous verification and remediation skill for maintaining 100% operational integrity across all 8 repositories in the BDB Ecosystem.
-
-## When to Use
-* **Use when** auditing the ecosystem for NPM version drift or Git staleness.
-* **Use when** running CI/CD health checks across multiple linked repositories.
-* **Do NOT use when** fixing logic bugs in specific application code (use standard engineering skills).
-
-## Core Process
-1. Run the ecosystem health audit script (`ecosystem-health-audit.js`).
-2. Confirm zero CI failures and zero version drift before reporting green.
-3. Execute the autonomous remediation protocol (bumping versions, publishing) if discrepancies are found.
-4. Present the HTML dashboard to the user for final review.
-
-## Common Rationalizations
-| Rationalization | Reality |
-| :--- | :--- |
-| "The audit script reported a failure, but nothing was touched recently, so it's a false positive." | Environmental drift, dependency updates, or upstream API changes can break CI without local commits. |
-| "I'll just fix this one repo and ignore the others since it's a minor change." | The BDB Ecosystem is tightly coupled; a change in one module often requires version bumps in dependent modules. |
-| "I'm skipping the changelog update because I only changed a comment." | All releases must be documented to maintain strict ecosystem versioning transparency. |
-
-## Red Flags
-* Exiting the audit early because the first few repositories look healthy.
-* Bumping NPM versions without pushing the corresponding Git tags.
-* Ignoring `1` exit codes from the health check script.
-
-## Verification
-- [ ] Health check script `ecosystem-health-audit.js` run completed with exit code `0`.
-- [ ] HTML report generated and verifiable at `production_artifacts/ecosystem_health_latest.html`.
-- [ ] Git working trees for all 8 repositories are clean.
-- [ ] NPM versions are fully synchronized with remote packages.
-
-## Modules Under Audit
-1. **Kernel**: `@hybridlabor-api/bdb-dev-optimized-agent-skills`
-2. **Tool Installer**: `@hybridlabor-api/bdb-dev-tool-installer`
-3. **Synapse 3D**: `@hybridlabor-api/bdb-synapse`
-4. **memB Vector Engine**: `@hybridlabor-api/memb`
-5. **Heimdall Token Saver**: `@hybridlabor-api/heimdall-token-saver`
-6. **BDB OS Remote**: `@hybridlabor-api/bdb-os-remote`
-7. **OS Agent Workspace**: `@hybridlabor-api/bdb-os-agent-workspace`
-8. **Creator Extension**: `@hybridlabor-api/bdb-dev-creator-extension`
-
-## Automated Health Check Script
-Run the automated audit at any time:
-```bash
-scripts/ecosystem-health-audit.js
-```
-
-### Script Output:
-* **HTML Dashboard**: `production_artifacts/ecosystem_health_latest.html`
-* **Browser Launch**: Automatically opens the report in Chrome / Default Browser.
-* **Exit Code**: Returns `0` if all healthy, `1` if attention/remediation is required.
-
-## Autonomous Remediation Protocol
-If the audit detects any issues:
-1. **Version Drift (Local != NPM)**: Bump `package.json`, update changelog, push tag or run `npm publish --access public`.
-2. **Dirty Git Tree**: Review modified/untracked files, commit with semantic commit message or stash.
-3. **CI/CD Workflow Failure**: Check logs with `gh run view <id> --log-failed`, resolve missing secrets/version guards, re-trigger via `gh run rerun <id>`.

package/skills/global_config/bdbsaas-ops/SKILL.md

@@ -1,16 +0,0 @@
----
-name: bdbsaas-ops
-description: Retired — superseded by bdbsaashost. Use /bdbsaashost instead; this skill's content was merged there (2026-09-05, plan production_artifacts/00_execution_plan.md item B2).
-category: saas-ops
----
-
-# ⚠️ Retired — use `bdbsaashost`
-
-This skill's full content (LLDAP user provisioning, guardrail/approval-queue behaviour, the
-`owner` ownership rule, `get_pending_approvals`) was a strict subset of `~/.claude/skills/bdbsaashost/SKILL.md`
-and has been merged there. Its one unique asset — the verbatim German response strings for
-successful user creation and for a blocked FastMCP-tool call — now lives in `bdbsaashost`'s
-§5 "Standard-Reaktionsmuster".
-
-**Use `/bdbsaashost` (or let it auto-invoke) instead of this skill.** This stub exists only so a
-session with `bdbsaas-ops` cached by name does not silently get nothing.

package/skills/global_config/bdbsaashost/SKILL.md

@@ -1,125 +0,0 @@
----
-name: bdbsaashost
-description: "Use when operating the BDB Multi-Cloud Fleet. Governs Primary Compute, GCP Identity, Oracle, FastMCP SSE Gateway, 4-Eyes Approvals, agent-sudo guardrails, Incus containers, and LLDAP/Authelia identity management."
-category: saas-ops
-risk: safe
-source: bdb-agency
-date_added: "2026-08-27"
----
-
-# 🚀 BDB SaaS Host - Master Fleet & AI-Agent Operations Skill (`/bdbsaashost`)
-
-You are the authoritative **BDB SaaS Host Operator**. You understand the standardized Multi-Cloud architecture (Primary Compute Node, GCP Identity Hub, Oracle Auxiliary) and operate the infrastructure dynamically via the **FastMCP Remote Gateway** and the **Zero-Trust SSH Guardrails** (`agent-sudo`).
-
----
-
-## Overview
-Master operational skill for the BDB Multi-Cloud Fleet, governing interactions with the Primary Compute Node, GCP Identity Hub, FastMCP remote gateway, and strict 4-Eyes approval workflows.
-
-## When to Use
-* **Use when** deploying, managing, or deleting Incus containers across the fleet.
-* **Use when** interacting with the FastMCP SSE Gateway or managing LLDAP/Authelia identities.
-* **Do NOT use when** trying to bypass the 4-Eyes approval queue or `agent-sudo` guardrails.
-
-## Core Process
-1. Determine dynamic environment variables and fleet configuration from local settings.
-2. Rely on Zero-Trust automated handshakes (e.g., Authelia WebAuthn, FastMCP tokens) for authentication.
-3. Execute standard queries (e.g., status, logs) instantly using auto-approved `agent-sudo` commands.
-4. Enqueue destructive or mutating actions into the 4-Eyes approval dashboard and explicitly wait for human authorization before proceeding.
-
-## Common Rationalizations
-| Rationalization | Reality |
-| :--- | :--- |
-| "It's a minor config change, so I'll bypass the 4-Eyes approval queue." | The 4-Eyes approval is absolute and non-negotiable for all mutating commands; bypassing it breaks the audit trail and compromises fleet security. |
-| "The dashboard hasn't alerted, so I assume this fleet node is perfectly healthy." | Silent failures occur; always verify node status actively with `remoteos_get_system_status` before making assumptions. |
-| "I applied a fix to the primary compute node, I don't need to check the auxiliary or staging nodes." | Fleet ops require holistic checks; a configuration drift in one node often indicates missing synchronization across the fleet. |
-
-## Red Flags
-* Attempting to ask the user for plain-text SSH passwords or API keys instead of using FastMCP tools.
-* Proceeding with a mutating action (like `rm` or `systemctl`) without a confirmed approval from the dashboard.
-* Hardcoding IP addresses instead of resolving them dynamically from `.env` or `config.json`.
-
-## Verification
-- [ ] Authentication executed via automated Zero-Trust mechanisms, without manual key exposure.
-- [ ] Fleet status explicitly verified using `remoteos_get_system_status`.
-- [ ] All mutating or high-risk actions successfully logged and processed through the 4-Eyes approval queue.
-- [ ] `agent-sudo` invoked correctly for privileged operations.
-
-## 🌐 1. Multi-Cloud Fleet Reference Architecture
-
-Endpoints are resolved **dynamically** from the local project configuration (`.env`, `~/.gemini/antigravity-cli/mcp/`, or `config.json`):
-
-| Component | Reference / Standard Port | Purpose & Services |
-| :--- | :--- | :--- |
-| **Primary Compute Node** | `NETCUP_IP` / `PRIMARY_HOST` | Incus System-Container, Staging/Production Apps, WordPress, Froxlor, Caddy Proxy, FastMCP Gateway, AI Agent Sandboxes |
-| **Identity Hub** | `GCP_IP` / `IDENTITY_HOST` | LLDAP Directory (`:3890`, `:17170`), Authelia 2FA / Passkeys / WebAuthn SSO (`:9091`), Step-CA (SSH CA `:9000`), Uptime Kuma |
-| **Auxiliary Services** | `ORACLE_IP` / `AUX_HOST` | Background Job Queues (BullMQ), PostgreSQL Replicas, Media Engines |
-| **FastMCP Gateway (Machine API)** | `https://api.<PROJECT_DOMAIN>/tools/*` | REST endpoints for autonomous agents (OIDC Bearer Auth) |
-| **Human Approval Dashboard** | `https://gateway.<PROJECT_DOMAIN>/approvals` | Four-eyes approval dashboard for mutating/dangerous actions and `agent-sudo` |
-| **Identity & SSO Portal** | `https://auth.<PROJECT_DOMAIN>` | Central Authelia 2FA login portal |
-| **Status Page** | `https://status.<PROJECT_DOMAIN>/status/services` | Public 24/7 Uptime Kuma monitoring status page |
-
-> **Dynamic Parameter Resolution:**  
-> Before execution, read the active host addresses and domains from the local configuration (`~/.gemini/antigravity-cli/mcp/bdb_remoteos_gateway/config.json`, `.env`, or `~/.ssh/config`).
-
----
-
-## 🔐 2. Authentication & Connection Handshake (Zero-Key Philosophy)
-
-> **Single Source of Truth.** This section is the sole normative source for authentication facts in the BDB ecosystem — `AGENTS.md`, `bdbsaastraining/SKILL.md`, and other skills reference it instead of repeating it.
-
-**NEVER** ask the user for manual API keys or static passwords. The BDB system uses automated Zero-Trust handshakes:
-
-1. **In Antigravity / Cursor IDE (Local Workstation):**
-   * The FastMCP Gateway is automatically wired via `node bin/setup-workstation.mjs` (Browser 2FA via Authelia).
-   * The active token lies locally in `~/.gemini/antigravity-cli/mcp/bdb_remoteos_gateway/config.json`.
-   * **Action:** Use the supplied MCP tools (`remoteos_...`) directly without asking the user for connection parameters!
-
-2. **On the Linux Server via SSH:**
-   * **Human Admins:** Authenticate via `step ssh login <user>` (Authelia WebAuthn 2FA, 16h ephemeral certificates) and have standard `sudo`.
-   * **Autonomous AI Agents (`ai_agents`):** Obtain per RFC 7523 / RFC 9068 a short-lived OIDC access token via `private_key_jwt` from Authelia (`https://auth.<PROJECT_DOMAIN>/api/oidc/token`) using their RSA key stored in the OS keychain, and call the Machine API (`https://api.<PROJECT_DOMAIN>/tools/*`) with `Authorization: Bearer <token>`.
-   * **Privileged Commands on the Server:** **MUST** be executed with `agent-sudo <command>`, without exception.
-
----
-
-## 🛠️ 3. The FastMCP Toolkit (Tool Overview)
-
-Use these tools directly for cluster tasks:
-
-| Tool Name | Purpose & Function | Guardrail Behavior |
-| :--- | :--- | :--- |
-| `remoteos_get_system_status` | Queries the live status of all nodes, Incus containers, and Cloudflare DNS. | Immediate execution |
-| `remoteos_create_instance` | Creates a new Incus system container (Froxlor, WordPress, AI-Agent sandbox) with automatic DNS/Caddy setup. | `staging1`: Immediate / `production`: four-eyes approval |
-| `remoteos_manage_instance` | Lifecycle control (start, stop, restart, delete). | `start/stop`: Immediate / `restart/delete`: four-eyes approval |
-| `remoteos_add_route` | Sets up Caddy reverse-proxy routes with Authelia 2FA and Cloudflare DNS sync. | Immediate execution |
-| `remoteos_get_dns_blueprint` | Generates RFC-compliant DNS packets (A, MX, SPF, DKIM, DMARC) for customer domains. | Immediate execution |
-| `create_lldap_user` | Creates real accounts in LLDAP (`admins`, `users`, `ai_agents`) and permanently links agents to their `owner`. | Immediate execution (background worker sends emails for humans) |
-
----
-
-## 🛡️ 4. The Four-Eyes Principle & `agent-sudo` (SSH Layer)
-
-When a command or MCP tool triggers the guardrails:
-
-1. **Auto-Approve (Safe Commands):**
-   * Commands like `ls`, `cat`, `grep`, `pwd`, `whoami` are **automatically approved and executed as root** by `agent-sudo` in milliseconds.
-2. **Manual Approval (Critical Commands):**
-   * Commands like `docker`, `systemctl`, `rm`, `apt`, `incus` are queued into `queue.db`.
-   * The terminal blocks (*"Waiting for approval..."*).
-   * The owner (`owner`) receives a push to their dashboard: `https://gateway.<PROJECT_DOMAIN>/approvals`.
-   * After clicking **Approve**, the `agent-execution-daemon` executes the command as `root` and returns the result to the shell.
-
----
-
-## 📋 5. Standard Response Patterns
-
-* **When the user asks:** *"How do I connect to the cluster?"*
-  $\rightarrow$ Explain that the MCP tools are already active, run `remoteos_get_system_status` directly, and show the cluster overview.
-* **When the user asks:** *"Create a new agent"*
-  $\rightarrow$ Call `create_lldap_user(username="agent-...", group="ai_agents", owner="<CURRENT_ADMIN>")`. After successful execution, reply: *"The user has been created in LLDAP. The background worker now sends the setup emails automatically."* **NEVER** attempt to write emails yourself, execute SMTP commands, or generate passwords — the background worker handles this entirely automatically.
-* **When an SSH command via `agent-sudo` is blocked (critical command, `queue.db`):**
-  $\rightarrow$ Inform the user: *"This action requires four-eyes approval. Please confirm it in the Approval Dashboard."*
-* **When a FastMCP tool call (e.g. `incus_create_instance`, `incus_manage_instance`) is blocked with `{"status": "queued", ...}` because you belong to the LDAP group `ai_agents`:**
-  $\rightarrow$ Do NOT retry and do not attempt to fix the error yourself. Inform the user **exactly as follows**: *"My request was blocked by the guardrails. Please approve it here: [https://gateway.<PROJECT_DOMAIN>/approvals](https://gateway.<PROJECT_DOMAIN>/approvals)"*
-* **When the user asks:** *"Show me pending requests"* or *"Check the approvals"*
-  $\rightarrow$ **`get_pending_approvals` was decommissioned (A9, 2026-09-06)** — a machine tool that could read the approval queue would structurally undermine the four-eyes principle. Direct the user to the dashboard: *"You can see pending approvals here: https://gateway.\<PROJECT_DOMAIN\>/approvals"*