feat(tier1): Initialize Global Sentinel Tier 1 HA Architecture

- Formalized the QuanuX Physical Laws of High Availability in `.agent/skills/tier1_ha_skill.md`.
- Documented the Active-Passive NATS Supercluster architecture and global routing realities in `docs/architecture/high_availability.md`, accounting for BGP Anycast propagation ("The Long-Dark").
- Established the STONITH Apoptosis security protocols in `docs/security/failover_protocols.md`, mandating Out-Of-Band (OOB) hardware fencing over primary network channels.
- Drafted the HA implementation roadmap in `docs/planning/HA_IMPLEMENTATION_PLAN.md`, explicitly anchoring the GlobalSentinelLoop into the FastAPI lifespan and enforcing Typer CLI standards for `quanuxctl`.
- Enforced strict state segregation between NATS (Control State) and Hybrid Analytical Memory (DuckDB/HDF5/NAS choice).

Author: quantDIY

.agent/skills/tier1_ha_skill.md

@@ -0,0 +1,41 @@
+---
+description: The Physical Laws of Global High Availability (HA) for QuanuX Tier 1 Leader Nodes and the Active-Passive NATS Supercluster.
+---
+
+# QuanuX Tier 1 High Availability (HA) Skill File
+
+> [!IMPORTANT]
+> **IMMORTAL GUIDANCE:** This document establishes the absolute physical and cryptographic laws of the QuanuX Tier 1 Global Supercluster. Any code, architecture, or CLI tools you write concerning Tier 1 routing, orchestration, or node control MUST strictly adhere to this protocol.
+
+## 1. The NATS JetStream KV Lock (Leader Election)
+The Tier 1 Leader is determined *strictly* by who holds the `quanux.tier1.leader` key via Raft consensus. 
+- There is no ambiguous state. A node is either the Leader or a Follower.
+- Holding the KV lock grants the Tier 1 server total god-mode over the Global Sentinel network.
+- When the Leader's TTL (Time-To-Live) on the lock expires without a heartbeat, the Raft consensus automatically allows a hot-standby Follower to acquire the lock and promote itself.
+
+## 2. Active-Passive Global Nodes
+Only **ONE** Tier 1 Server acts as the active orchestrator.
+- **The Leader:** Actively commands the Nests, deploys risk updates, and emits orchestration directives.
+- **The Followers:** Maintain absolute silence. They are hot-standby replicas observing the NATS JetStream state, passively syncing to the exact nanosecond of the Leader's event log without taking any authoritative action.
+
+## 3. The STONITH Fencing Law (Preventing Split-Brain)
+This is the most critical axiom of QuanuX high availability. If a Follower promotes itself to Leader, its *very first cryptographic act* MUST be to execute a precise Fencing operation.
+- **The OOB Network Mandate:** Fencing must be executed via IPMI/PDU over a strictly separate Out-Of-Band (OOB) Ethernet network. Network partitions mean cryptographic tokens or SSH will fail; hard-power cycling is the only absolute proof of death.
+- **No Infinite Blocking:** The STONITH sequence MUST have a severe hard-timeout (e.g., 2000ms). If it fails to reach the BMC/PDU, it must abort and transition to `CRITICAL_PENDING` with alarms sent to the Architect. It cannot block the event loop infinitely.
+- We cannot permit a Split-Brain reality where two Tier 1 nodes believe they are the Leader and issue conflicting logic to the Tier 4 Fiber Nests. 
+
+## 4. BGP Convergence & The "Long-Dark"
+- Do not assume immediate route convergence. Global BGP shifts take 3 seconds to 3 minutes.
+- Tier 4 Nests must be programmed to survive the "Long-Dark," halting *new* entries and executing *existing* exit logic blindly until routes converge.
+
+## 5. State Segregation (NATS vs. Analytical Storage)
+- **NATS JetStream** holds ONLY the Control State (active deployments, risk updates).
+- **Analytical Storage (Hybrid Choice)** holds historic/analytic Memory (tick data, deep backtest results). The end-user configures whether this is DuckDB, HDF5, or another NAS. HA failover only guarantees NATS orchestration.
+
+## 6. The CLI Authority (`quanuxctl`)
+Automated Raft consensus governs normal operation, but the Architect commands the system via `quanuxctl`.
+- `quanuxctl` is the ONLY manual interface authorized to override the Raft election.
+- Use `quanuxctl` to force failovers, demote a struggling Leader, or permanently fence a rogue node from the cluster.
+- When generating strategy deployment or node orchestration logic, remember that `quanuxctl` can seamlessly interrupt or redirect the system flow through these administrative paths.
+
+**When analyzing or extending QuanuX HA features, you must always verify that your solution complies with OOB STONITH limits, BGP delay realities, Analytical State Segregation, and the singular authority of the CLI.**

docs/architecture/high_availability.md

@@ -0,0 +1,44 @@
+# QuanuX Global High Availability Architecture
+
+This document dictates the design and structural reality of the QuanuX Active-Passive NATS Supercluster—a globally distributed Control Plane orchestrating decentralized Tier 4 Nests in multiple financial hubs (e.g., Aurora, Carteret, Frankfurt).
+
+## 1. The Global Sentinel Vision
+QuanuX operates under the paradigm that the Data Plane is ruthless and hyper-localized (C++ execution loops over bare-metal Linux sockets), while the Control Plane is globally distributed, highly available, and impervious to catastrophic localized failure. 
+
+To achieve this, QuanuX leverages an **Active-Passive Global Tier 1** mechanism backed by a NATS JetStream Supercluster. 
+
+### The Split
+*   **Data Plane (Tick-to-Trade):** 59ns lock-free Dual-Thread execution in Tier 4 Fiber Nests. This layer operates out-of-band of the central node.
+*   **Control Plane (Orchestration & Risk):** Synchronous, deterministic, Raft-driven governance managed by the Tier 1 Global Leader Server.
+
+## 2. Infrastructure Anatomy
+The Tier 1 Control Plane is structured via **Leader Election**:
+*   **Tier 1 Leader:** The sole commander holding the JetStream KV lock (`quanux.tier1.leader`). Responsible for emitting immutable orchestration logs, adjusting risk metrics, and managing the Biological Lore (e.g., triggering Apoptosis).
+*   **Regional Followers:** Live in datacenters worldwide. They are silent hot-standbys that persist the JetStream event log.
+
+---
+
+## 3. Failover Sequence: The Millisecond Anatomy of a Crash
+
+When a Tier 1 Leader experiences physical destruction, network segmentation, or fatal OS panic, the QuanuX cluster executes a mathematically deterministic failover protocol.
+
+### Step 1: Leader TTL Expiration
+The Tier 1 Leader sends a high-frequency heartbeat holding the JetStream lock. If the cluster goes `N` milliseconds without a heartbeat, the lock's TTL expires.
+
+### Step 2: Follower Promotion
+Raft consensus awakens the Followers. The fastest Follower (usually the geographically closest with the best ping to the quorum) instantly seizes the `quanux.tier1.leader` KV lock. At this point, it is logically the Leader.
+
+### Step 3: STONITH Apoptosis (Fencing)
+Before issuing a single command to the edge nodes, the new Leader issues a mathematically guaranteed kill-pill—a `STATE_HALT` command (Apoptosis)—directed at the physical ID of the fallen Leader. 
+*   *Why?* It prevents a "Split-Brain." If the old Leader was severed by a **Network Partition**, it cannot be reached via normal SSH or software protocols. Fencing MUST occur over a strictly separate **Out-Of-Band (OOB) Hardware Management Network** (IPMI/iLO/PDU) to physically cut its power. Otherwise, the old Leader will resurrect locally when the partition heals, creating chaotic dual-command horizons.
+
+### Step 4: Event Sourcing & Deterministic Replay
+The new Leader replays the last uncommitted NATS JetStream log. By traversing the deterministic event sequence of the entire cluster, the new Leader rebuilds the exact working memory and risk state that the old Leader possessed micro-seconds before crashing. No configurations or deployments are dropped.
+
+### Step 5: Global Anycast IP & The "Long-Dark" Reconnection
+*   **Control Plane Routing:** Tier 1 IPs are configured as Virtual IPs (VIPs) using BGP Anycast. When the failover occurs, the new Leader triggers a BGP route update to shift traffic globally. 
+*   **The "Long-Dark" Survival Mode:** The execution edge Nests detect a ping timeout. BGP route convergence across the global internet requires anywhere from 3 seconds to 3 minutes. The Nests do **NOT** panic, but they understand the reality of the propagation delay.
+*   **Ritchie FSM (Finite State Machine):** During the blackout, Nests throttle or completely halt *new* strategy entries locally. They rely on their FSM to blindly execute *existing* exit logic via raw sockets. When the BGP routes finally converge, the physical internet seamlessly routes them to the new Leader node. Connection restored. State synchronized.
+
+## 4. Summary
+The QuanuX High Availability Architecture bridges biological resilience with institutional-grade networking. By coupling Raft election to STONITH fencing and separating the Control Plane from the localized Execution Plane, the cluster can dynamically survive the loss of master operational nodes worldwide.

docs/planning/HA_IMPLEMENTATION_PLAN.md

@@ -0,0 +1,50 @@
+# HA Implementation Roadmap & CLI Expansion Plan
+
+This document serves as the exact engineering blueprint for migrating the QuanuX Tier 1 Server from a single-node Python orchestrator into a fully distributed Global Supercluster.
+
+## Phase 1: NATS JetStream vs Analytical Boundary
+**Objective:** Replace local state management with a globally distributed KV lock while enforcing the boundary between Execution State and Analytical Memory.
+
+1. **Initialize Global Bucket:** Create a NATS JetStream Key-Value bucket named `quanux_cluster_state` replicated across $N$ geographic regions.
+2. **Lock Definition:** Define the primary lock `quanux.tier1.leader`.
+3. **State Reflection (The Dichotomy):** 
+   - **Control State (NATS JetStream):** Risk profiles, Supervisor limits, active deployments, and real-time orchestration events are strictly appended to the JetStream Event Log for immediate HA replay.
+   - **Analytical State (Hybrid):** Historic tick data, heavy backtesting memory, and massive order-flow archives must NEVER be stored in NATS. They are safely offloaded to a user-configured storage engine (DuckDB, HDF5, NAS). HA Failover strictly guarantees the Control State, not the analytics volume.
+
+## Phase 2: Python Background Leader Election Loop
+**Objective:** Implement the Active-Passive heartbeat and Raft observer within the FastAPI backend with defensive STONITH timeouts.
+
+1. **The Observer Task (FastAPI Lifespan):** The Tier 1 Server is driven by FastAPI. The background `asyncio` task (`GlobalSentinelLoop`) does not exist in a vacuum; it is spun up and managed by the FastAPI lifespan context manager (or startup/shutdown events). Furthermore, the FastAPI routing logic must be Raft-aware: if the node is a Follower, specific orchestration endpoints must automatically reject or redirect traffic until the node is promoted to Leader.
+2. **Heartbeat Maintenance:** If the server is Leader, it writes the current timestamp to `quanux.tier1.leader` every `50ms`. 
+3. **The Watcher:** If the server is a Follower, it establishes a JetStream Watcher on the lock. If the lock's TTL is exceeded (e.g., no update for `250ms`), the server attempts a targeted `Update` with its own `Node_ID` to seize the lock.
+4. **Apoptosis Hook (Defended):** Upon acquiring the lock, the backend triggers `execute_stonith(old_leader_id)`. **CRITICAL:** This call must have a strict hard-timeout (e.g., `2000ms`). If the IPMI interface of the dead datacenter is offline, it cannot block infinitely. If the script hits the timeout, it abandons the lock, enters a `CRITICAL_PENDING` state, and fires a severe alarm via `quanuxctl`/SMS/PagerDuty to the Architect.
+5. **State Rehydration:** Once Fencing is verified, the server replays the NATS Event Log to rehydrate the application state and begins accepting `quanuxctl` and Nest connections.
+
+## Phase 3: The `quanuxctl` CLI Expansion
+**Objective:** Grant the Architect "God-Mode" over the Raft cluster and manual failover hierarchy. Any automated clustering protocol must have deterministic manual overrides.
+
+The `quanuxctl` CLI will be expanded to include the `cluster` command group.
+
+### `quanuxctl cluster status`
+*   **Action:** Queries NATS for the telemetry of the global supercluster.
+*   **Output:** 
+    *   Identifies the current **Leader** (Node ID, Region, Uptime).
+    *   Lists all **Followers** (Node IDs, Ping to Leader, Replay Lag).
+    *   Displays the health and state of the `quanux.tier1.leader` lock.
+
+### `quanuxctl cluster promote <node_id>`
+*   **Action:** Forces a manual Raft election override.
+*   **Execution:** Administratively commands the current Leader to drop the lock and artificially boosts the priority/election-timer of the specified `<node_id>` so it is guaranteed to become the new Leader.
+*   **Use Case:** Pre-emptive maintenance of a datacenter or shifting latency footprints before major economic releases.
+
+### `quanuxctl cluster demote`
+*   **Action:** Forces the current Leader to step down gracefully without explicitly assigning a successor.
+*   **Execution:** The Leader deletes its lock on `quanux.tier1.leader` and enters a 5-second backoff period where it refuses to vote OR run for election, allowing the remaining Followers to elect a new Leader.
+
+### `quanuxctl cluster fence <node_id>`
+*   **Action:** Manually triggers STONITH (Apoptosis) against a rogue or "zombie" node.
+*   **Execution:** Bypasses Raft consensus entirely and immediately fires the deepest available Fencing mechanism (Cryptographic -> OS -> Hardware) against a specific Node ID. 
+*   **Use Case:** Resolving complex network splits or permanently blinding a node that has been compromised or is behaving erratically outside of normal cluster logic.
+
+---
+**Execution Mandate:** Development must proceed linearly from Phase 1 to Phase 3. The foundational AI context (tier1_ha_skill.md) provides the parameters. Code generation algorithms are to strictly reference this plan when structuring the `quanuxctl` Typer framework extensions.

docs/security/failover_protocols.md

@@ -0,0 +1,39 @@
+# QuanuX Security & Failover Protocols
+
+## 1. Overview
+The security of the QuanuX Tier 1 Global Supercluster relies equally on cryptography and brutal pragmatism. When a failover event is triggered, the cluster cannot assume the old Leader is "dead" simply because it vanished from the network quorum; it must be **proven** dead. This document formalizes the STONITH (Shoot The Other Node In The Head) protocol, also known as the Apoptosis Directive.
+
+## 2. The STONITH Protocol (Apoptosis)
+A "Split-Brain" scenario—where two Tier 1 Orchestrators believe they are the Leader and stream conflicting commands to Execution Nests—is an unrecoverable, catastrophic event.
+
+### 2.1 The Prime Directive of Promotion
+When a Follower successfully acquires the `quanux.tier1.leader` NATS JetStream KV lock via Raft consensus, **it is strictly prohibited from emitting orchestration commands** until it has fully terminated the previous Leader.
+
+### 2.2 Fencing Mechanisms
+The new Leader will execute a `STATE_HALT` kill-pill against the fallen Leader's `Node_ID`. The stark reality of distributed systems is that **Network Partitions** render software fencing useless. If the old Leader is unreachable because its primary switch failed, it is still alive locally. Sending a cryptographic token or trying to SSH into it will fail. Thus, QuanuX prioritizes physical infrastructure segregation:
+
+1. **Hardware Fencing (IPMI / iLO / PDU) via Out-Of-Band (OOB) Network:**
+   **[PRIMARY MANDATE]** Hardware physical power fencing is the ONLY valid STONITH in a network split. The new Leader sends a kill-pill over a physically separate OOB ethernet network wired to a distinct management switch. It connects directly to the Baseboard Management Controller (BMC) or the Power Distribution Rack to physically kill power to the old Leader.
+2. **OS-Level Fencing (SSH / API Kill):**
+   *(Secondary)* If the OOB network is unavailable but the OS is reachable, the new Leader issues a kernel-level `sysrq-trigger` or tears down the supervisor.
+3. **Cryptographic Fencing (The Ritchie Protocol Extension):** 
+   *(Tertiary/Fallback)* The new Leader broadcasts a signed global banishment token across JetStream. NATS will brutally reject any further connections originating from the old Leader's TLS identity, acting as a final logical fence if power cannot be cut.
+
+*If all fencing attempts fail or block, the new Leader must ABORT its lock acquisition via a hard-timeout to prevent the "Infinite Blocking Trap" and log a `CRITICAL_PENDING` alarm to the Architect.*
+
+## 3. The Millisecond Timeline of Failover Execution
+The life-cycle of a high-availability failover across continents happens far faster than a human operator can react—up until the grim reality of global BGP propagation.
+
+*   `T+0ms`: The active Tier 1 Leader (e.g., Aurora) physically crashes or drops its network connection to the Quorum.
+*   `T+Nms`: The `quanux.tier1.leader` JetStream lock's TTL (Time-To-Live) heartbeat expires.
+*   `T+N+10ms`: Raft election begins. Followers in Carteret and Frankfurt detect the missing leader.
+*   `T+N+25ms`: The Frankfurt node, having a faster consensus ping with the remaining Quorum, acquires the `quanux.tier1.leader` lock.
+*   `T+N+30ms`: **Apoptosis Initiated.** Frankfurt fires a hardware kill-pill (STONITH) to Aurora's physical IPMI over the OOB network.
+*   `T+N+45ms`: **Event Sourcing Replay.** Frankfurt replays the JetStream log in deterministic order to rebuild its risk and orchestration state, adopting the precise memory footprint of Aurora right before the crash.
+*   `T+N+50ms`: **BGP Route Advertisement.** The VIP routing shifts. Frankfurt broadcasts it is now the origin of the Control Plane IP via BGP Anycast (or GARP for intra-DC local failovers).
+*   `T+N+55ms`: **The Long-Dark Blackout Begins.** While GARP works instantly locally, BGP convergence across the global internet takes anywhere from 3 to 180 seconds. The Edge Nests enter the "Long-Dark".
+*   `T+2000ms - T+120s`: **Edge Nest Survival (The Ritchie FSM).** The Tier 4 Fiber Nests know the Control Plane is dark. They throttle or halt new strategy entries locally, blindly executing their existing exit logic and risk liquidation checks via raw sockets until global routing converges.
+*   `T+Route_Converged`: **Reconnection.** The global physical network finally routes the VIP to Frankfurt. Nests seamlessly reconnect. Standard Operation Resumes.
+
+## 4. Unattended Operations
+Tier 3 and Tier 4 Nests are biologically resilient. If the entire Control Plane is briefly severed, Nests will freeze non-essential risk updates but **will continue deterministic order execution and local liquidation checks** via raw sockets. They are designed never to panic in the dark.