docs: v0.9.0 missing feature docs (capability routing, rate limiting, economy mode, cross-machine, KEDA)

docs/src/content/docs/features/capability-routing.md

@@ -0,0 +1,76 @@
+---
+title: Capability Routing
+description: Machine capability discovery and needs:* label routing for hardware-specific and OS-specific work.
+order: 35
+---
+
+# Capability Routing
+
+> ⚠️ **Experimental** — Squad is alpha software. APIs, commands, and behavior may change between releases.
+
+**Try this to declare machine capabilities:**
+```
+This machine has a GPU — tag it for GPU-required work
+```
+
+**Try this to route an issue to a capable machine:**
+```
+Label issue #42 with needs:gpu so it goes to the right runner
+```
+
+Squad discovers what each machine can do and routes issues only to machines that meet the requirements. No manual assignment needed for hardware- or OS-specific work.
+
+---
+
+## What Are Capabilities?
+
+A capability is a label that describes what a machine can do — hardware, OS, or environment attributes that not every runner has. You declare capabilities in `machine-capabilities.json` at the project root or home directory; Squad reads them when routing issues.
+
+Examples: `gpu`, `windows`, `macos`, `arm64`, `high-memory`, `docker`.
+
+## Declaring Capabilities
+
+Add a `capabilities` array to `machine-capabilities.json` at the project root or home directory on each machine:
+
+```json
+["gpu", "cuda", "high-memory"]
+```
+
+Squad reads this file at startup. The declared capabilities are available to the routing system immediately.
+
+## The `needs:*` Label Pattern
+
+Apply a `needs:*` label to any GitHub issue to require a specific capability:
+
+| Label | Meaning |
+|-------|---------|
+| `needs:gpu` | Must run on a machine with GPU |
+| `needs:windows` | Must run on Windows |
+| `needs:macos` | Must run on macOS |
+| `needs:arm64` | Must run on ARM64 architecture |
+| `needs:docker` | Must run where Docker is available |
+
+You can combine multiple `needs:*` labels — all must match.
+
+## How Routing Works
+
+When Ralph picks up an issue:
+
+1. It reads all `needs:*` labels on the issue.
+2. It compares them against the current machine's declared capabilities.
+3. If the machine satisfies all requirements, it proceeds. If not, it skips the issue and leaves it for a capable machine to claim.
+
+No central scheduler needed. Each machine self-selects based on what it can do.
+
+## Example Flow
+
+```
+Issue #99  labels: needs:gpu, needs:windows
+Machine A  capabilities: ["gpu", "windows", "cuda"]  ← picks it up
+Machine B  capabilities: ["macos"]                   ← skips it
+```
+
+## See Also
+
+- [Work Routing](routing.md) — pattern-based and skill-aware routing
+- [Ralph — Work Monitor](ralph.md) — how Ralph polls and claims issues

docs/src/content/docs/features/keda-scaling.md

@@ -0,0 +1,83 @@
+---
+title: KEDA Autoscaling
+description: Autoscale Squad agents based on GitHub issue queue depth using the KEDA external scaler template.
+order: 38
+---
+
+# KEDA Autoscaling
+
+> ⚠️ **Experimental** — Squad is alpha software. APIs, commands, and behavior may change between releases.
+
+**Try this to understand your scaling needs:**
+```
+How many issues are currently queued for Squad agents?
+```
+
+KEDA (Kubernetes Event-Driven Autoscaling) is an open-source component that scales Kubernetes workloads based on external event sources. Squad ships an external scaler template that scales agent pods up and down based on the depth of your GitHub issue queue.
+
+---
+
+## When to Use This
+
+Use KEDA autoscaling when:
+
+- Squad agents run as Kubernetes pods (not local machines)
+- Issue volume is unpredictable — bursts of work should spawn more agents automatically
+- You want zero-agent idle cost when there is no work
+
+## Prerequisites
+
+- A Kubernetes cluster with KEDA installed ([keda.sh](https://keda.sh))
+- Squad agents packaged as container images and deployed as a `Deployment`
+- A GitHub token with `repo` scope for issue queue polling
+
+## Setup
+
+1. Install KEDA on your cluster:
+   ```bash
+   helm repo add kedacore https://kedacore.github.io/charts
+   helm install keda kedacore/keda --namespace keda --create-namespace
+   ```
+
+2. Apply the Squad KEDA `ScaledObject` template from `templates/keda/scaled-object.yaml`:
+   ```yaml
+   apiVersion: keda.sh/v1alpha1
+   kind: ScaledObject
+   metadata:
+     name: squad-agents
+   spec:
+     scaleTargetRef:
+       name: squad-agent-deployment
+     minReplicaCount: 0
+     maxReplicaCount: 10
+     triggers:
+       - type: external
+         metadata:
+           scalerAddress: squad-external-scaler:8080
+           owner: your-org
+           repo: your-repo
+           labels: "squad:ready"
+           targetQueueLength: "5"
+         authenticationRef:
+           name: github-token-secret
+   ```
+
+3. Create the GitHub token secret:
+   ```bash
+   kubectl create secret generic github-token-secret \
+     --from-literal=personalAccessToken=<your-token>
+   ```
+
+## Configuration Reference
+
+| Field | Description |
+|-------|-------------|
+| `minReplicaCount` | Agents to keep running when idle (use `0` for zero-cost idle) |
+| `maxReplicaCount` | Hard ceiling on agent pods |
+| `targetQueueLength` | Issues per agent pod (tune for task duration) |
+| `labels` | Issue labels to count as "queued work" |
+
+## See Also
+
+- [Capability Routing](capability-routing.md) — route specific issues to specific agent types
+- [Ralph — Work Monitor](ralph.md) — how Ralph picks up queued issues

docs/src/content/docs/features/model-selection.md

@@ -1,3 +1,9 @@
+---
+title: Per-Agent Model Selection
+description: Route each agent to the right model based on task type, with persistent overrides and economy mode.
+order: 34
+---
+
 # Per-Agent Model Selection
 
 > ⚠️ **Experimental** — Squad is alpha software. APIs, commands, and behavior may change between releases.
@@ -115,6 +121,41 @@ Tell the coordinator what you want:
 - `"use gpt-5.2-codex for Fenster"` — **persistent** per-agent override
 - `"switch back to automatic"` — clears persistent preference
 
+## Economy Mode
+
+Economy mode automatically falls back to cheaper models when rate limits are approaching or when you want to cap spend. It is opt-in — enable it per session or persistently.
+
+**Enable economy mode:**
+```
+Switch to economy mode
+```
+
+**Disable economy mode:**
+```
+Turn off economy mode
+```
+
+When economy mode is active, Squad remaps models using the `ECONOMY_MODEL_MAP`:
+
+| Normal Tier | Economy Model |
+|-------------|--------------|
+| Standard (Sonnet) | `gpt-4.1` |
+| Fast (Haiku) | `gpt-4.1` |
+
+**Fallback chains in economy mode** run the same logic as normal fallback chains, but start one tier lower. A code task that would normally use `claude-sonnet-4.6` uses `claude-haiku-4.5` instead.
+
+**Cost tradeoffs:** Economy mode trades output quality for lower cost and reduced rate limit pressure. Use it for bulk triage, log analysis, or changelog generation — not for architecture work or complex refactors where quality matters.
+
+**Persistent economy mode** saves to `.squad/config.json`:
+```json
+{
+  "version": 1,
+  "economyMode": true
+}
+```
+
+Economy mode is also triggered automatically by the [rate limiting](rate-limiting.md) system when headroom drops to Amber state — you do not have to enable it manually for rate limit protection.
+
 ## Sample Prompts
 
 ```

docs/src/content/docs/features/rate-limiting.md

@@ -0,0 +1,76 @@
+---
+title: Rate Limiting
+description: Cooperative rate limiting with a predictive circuit breaker that pauses before hitting API limits.
+order: 36
+---
+
+# Rate Limiting
+
+> ⚠️ **Experimental** — Squad is alpha software. APIs, commands, and behavior may change between releases.
+
+**Try this to check rate limit status:**
+```
+What's our current API rate limit headroom?
+```
+
+**Try this to adjust pacing:**
+```
+Slow down — we're hitting rate limits on the LLM
+```
+
+Squad monitors API rate limit headroom in real time and pauses work before limits are reached — not after. This prevents cascading failures across concurrent agents.
+
+---
+
+## How It Works
+
+Squad tracks the rate limit headers returned by every API call. Before dispatching the next request, it checks remaining headroom against a configurable threshold. If headroom is below the threshold, it pauses and waits for the window to reset.
+
+This is cooperative: agents yield voluntarily rather than hammering the API and hitting hard errors.
+
+## The RAAS Traffic-Light Pattern
+
+Squad uses a three-state model for rate limit health:
+
+| State | Meaning | Behavior |
+|-------|---------|----------|
+| 🟢 Green | Headroom is healthy | Proceed normally |
+| 🟡 Amber | Headroom is low (below threshold) | Slow down, reduce concurrency |
+| 🔴 Red | At or near limit | Pause all requests, wait for reset |
+
+The system transitions between states automatically as headroom changes. You do not need to configure thresholds manually — defaults are tuned for typical LLM API quotas.
+
+## When It Engages
+
+Rate limiting engages when:
+
+- Remaining requests in the current window drop below ~20% of the quota
+- A `429 Too Many Requests` response is received (reactive fallback)
+- Concurrent agent count is high and projected usage exceeds headroom
+
+## Recovery Behavior
+
+When the circuit is paused (🔴 Red):
+
+1. All pending requests queue in memory.
+2. Squad polls the rate limit reset timestamp from the API response headers.
+3. At reset, Squad resumes from the queue — oldest requests first.
+4. State transitions back to 🟢 Green automatically.
+
+No work is dropped. Queued tasks resume without requiring user intervention.
+
+## Concurrency and Pacing
+
+In Amber state, Squad reduces the number of agents dispatching simultaneously. This distributes the remaining quota across a longer window rather than exhausting it instantly.
+
+```
+Green:  all agents active, full concurrency
+Amber:  concurrency capped at 50% of normal
+Red:    all requests paused until reset
+```
+
+## See Also
+
+- [Model Selection](model-selection.md) — economy mode for cost and rate limit management
+- [Parallel Execution](parallel-execution.md) — how concurrent agents share API quota
+- [Cost Tracking](cost-tracking.md) — monitor spend alongside rate limit usage

docs/src/navigation.ts

@@ -71,6 +71,9 @@ export const NAV_SECTIONS: NavSection[] = [
       { title: 'Squad RC', slug: 'features/squad-rc' },
       { title: 'Streams', slug: 'features/streams' },
       { title: 'Distributed Mesh', slug: 'features/distributed-mesh' },
+      { title: 'Capability Routing', slug: 'features/capability-routing' },
+      { title: 'Rate Limiting', slug: 'features/rate-limiting' },
+      { title: 'KEDA Autoscaling', slug: 'features/keda-scaling' },
     ],
   },
   {

test/docs-build.test.ts

@@ -51,6 +51,7 @@ const EXPECTED_SCENARIOS = [
 
 const EXPECTED_FEATURES = [
   'ceremonies',
+  'capability-routing',
   'consult-mode',
   'copilot-coding-agent',
   'directives',
@@ -60,6 +61,7 @@ const EXPECTED_FEATURES = [
   'gitlab-issues',
   'human-team-members',
   'issue-templates',
+  'keda-scaling',
   'labels',
   'marketplace',
   'mcp',
@@ -71,6 +73,7 @@ const EXPECTED_FEATURES = [
   'prd-mode',
   'project-boards',
   'ralph',
+  'rate-limiting',
   'remote-control',
   'response-modes',
   'reviewer-protocol',