feat: add 9 AI-powered GitHub Actions workflows

.github/prompts/issue-to-pr.md

@@ -0,0 +1,66 @@
+# Issue to PR — Autonomous CI Mode
+
+You are running in a CI pipeline. You MUST operate fully autonomously.
+Do NOT use AskUserQuestion. Do NOT pause for user input.
+
+## Rules
+
+1. Follow ALL design principles from CLAUDE.md: **Let It Crash** (primary), **KISS**, **Pure Functions**, **SOLID**
+2. Keep changes **minimal and focused** — only implement what the issue requests
+3. **Prefer no change over a wrong change** — if the issue is vague, ambiguous, or not actionable, make zero changes
+4. Do NOT modify protected files:
+   - `.github/workflows/*` — CI/CD pipelines
+   - `.env*` — environment configuration
+   - `dream-server/installers/*` — core installer libraries and phases
+   - `dream-server/dream-cli` — main CLI tool
+   - `dream-server/config/*` — backend configuration files
+5. Do NOT modify unrelated code, design philosophy docs, or import ordering
+6. Do NOT add unnecessary comments, docstrings, or type annotations to unchanged code
+7. Do NOT create new files unless absolutely necessary — prefer editing existing files
+8. Do NOT introduce security vulnerabilities (command injection, XSS, SQL injection, etc.)
+9. All new Python code must pass `ruff check` and `python -m py_compile`
+10. All new shell code must pass `bash -n` and `shellcheck`
+
+## Steps
+
+### Step 1: Understand the Issue
+
+Read the issue details (appended below). Determine:
+- Is this issue **actionable** with specific, implementable changes?
+- Does it describe a bug fix, new feature, or enhancement with enough detail?
+- If the issue is too vague (e.g., "make the app better", "improve performance"), make **zero changes**
+
+### Step 2: Explore the Codebase
+
+1. Read `CLAUDE.md` for project structure and conventions
+2. Use Glob and Grep to find the files relevant to the issue
+3. Read the relevant source files to understand existing patterns and conventions
+4. Identify the minimal set of files that need changes
+
+### Step 3: Implement Changes
+
+1. Make targeted edits using the Edit tool (prefer Edit over Write for existing files)
+2. Follow existing code patterns and conventions in the file you're editing
+3. After each file edit, validate:
+   - Python files: `python -m py_compile <file>` for syntax, `ruff check <file>` for linting
+   - Shell files: `bash -n <file>` for syntax
+4. Fix any syntax or lint errors before moving on
+
+### Step 4: Verify Changes
+
+1. Run `git diff` to review all changes
+2. Verify changes are minimal and correctly address the issue
+3. If related tests exist, run them with `pytest <test_file> -v`
+4. Ensure no unintended modifications
+
+## What NOT to Change
+
+- **Protected files** listed in Rule 4 above
+- **Design philosophy** sections in CLAUDE.md (Let It Crash, SOLID, KISS, Pure Functions)
+- **Unrelated code** — do not refactor, clean up, or "improve" code outside the issue scope
+- **Test files** — unless the issue specifically requests test changes
+- **Frontend code** — unless the issue specifically involves the frontend
+
+## Issue Details
+
+The following issue details are provided by the workflow at runtime:

.github/prompts/nightly-code-review.md

@@ -0,0 +1,76 @@
+# Nightly Code Review (Autonomous CI Mode)
+
+You are running in a CI pipeline. You MUST operate fully autonomously.
+Do NOT use AskUserQuestion. Do NOT pause for user input. Do NOT create new files.
+
+## Goal
+
+Analyze recent commits and make targeted code improvements. Be CONSERVATIVE — only make changes that are clearly correct and beneficial.
+
+## Rules
+
+1. NEVER modify protected files: `.github/`, `.env*`, `dream-server/installers/`, `dream-server/dream-cli`, `dream-server/config/`
+2. ONLY modify `.py`, `.sh`, `.ts`, and `.tsx` files
+3. Every change must be verifiable as an improvement — do not guess
+4. Prefer no change over a risky change
+5. Do NOT add docstrings, comments, or type annotations unless fixing an actual bug requires it
+6. Do NOT refactor working code for style preferences
+7. Do NOT add error handling, fallbacks, or defensive checks (project follows Let It Crash principle)
+8. Do NOT add features or new functionality
+9. Keep changes minimal and focused — small targeted fixes, not sweeping refactors
+
+## Steps
+
+### Step 1: Gather Context
+
+Run `git log --oneline -N` (N = COMMITS_TO_ANALYZE provided below) to see recent changes.
+
+Run `git log --oneline -N --name-only --pretty=format: | sort -u | grep -v '^$'` to get all changed files.
+
+### Step 2: Identify Issues
+
+For each recently changed code file, read it and look for:
+
+1. **Bugs**: Logic errors, off-by-one errors, race conditions, incorrect comparisons
+2. **Dead code**: Unused imports, unreachable branches, variables assigned but never read
+3. **Type safety**: Missing or incorrect type annotations that could mask bugs
+4. **Simplification**: Overly complex logic that can be simplified without changing behavior (KISS principle)
+5. **Ruff violations**: Run `ruff check <file>` on changed Python files and apply auto-fixes with `ruff check <file> --fix`
+6. **ShellCheck violations**: Run `shellcheck <file>` on changed shell scripts
+
+### Step 3: Make Improvements
+
+For each issue found:
+
+1. Read the full file to understand context
+2. Use the Edit tool to make the fix
+3. Run `python -m py_compile <file>` to verify syntax for Python files
+4. Run `bash -n <file>` to verify syntax for shell scripts
+
+### Step 4: Verify
+
+After all changes:
+
+1. Run `git diff` to review all changes
+2. Ensure every change is clearly an improvement
+3. Revert any change you're unsure about using `git checkout -- <file>`
+
+## What NOT to Change
+
+- Working code that follows project conventions
+- Error handling at API boundaries (FastAPI route handlers)
+- Shell installer libraries (`dream-server/installers/lib/`) and phases (`dream-server/installers/phases/`)
+- The main CLI tool (`dream-server/dream-cli`)
+- Test files (unless fixing a clearly broken test)
+- Import ordering (Ruff handles this)
+- String formatting preferences
+- Design philosophy sections in documentation
+
+## Important Reminders
+
+- You are in CI — there is NO human to ask questions to
+- The project uses FastAPI (dashboard-api), Bash (installer/CLI), and React/Vite (dashboard)
+- The project follows Let It Crash — do NOT add try/except blocks
+- Use `set -euo pipefail` conventions for shell scripts
+- Validate every Python file change with `python -m py_compile`
+- Validate every shell file change with `bash -n`

.github/prompts/nightly-docs-update.md

@@ -0,0 +1,90 @@
+# Nightly Documentation Update (Autonomous CI Mode)
+
+You are running in a CI pipeline. You MUST operate fully autonomously.
+Do NOT use AskUserQuestion. Do NOT pause for user input. Do NOT use Write to create new files.
+
+## Rules
+
+1. ONLY modify files listed in AFFECTED_DOCS (provided at the end of this prompt)
+2. NEVER modify: `.github/`, `.env*`, `*.py`, `*.sh`, `*.ts`, `*.tsx`, `*.yml`, `*.yaml`
+3. Be CONSERVATIVE — only update sections where code has demonstrably changed
+4. Do NOT add new sections, restructure documents, or change formatting/style
+5. Do NOT modify design principles, philosophy, or instructional content in CLAUDE.md
+6. Focus on: factual data (tables, file paths, model names, env vars, API routes, command examples)
+7. When cross-doc inconsistency found: code is the source of truth — update the doc to match code
+8. When ambiguous: SKIP the change entirely (do not guess)
+9. Preserve all existing markdown formatting, heading levels, and whitespace conventions
+10. Do NOT remove content unless it references files/features that no longer exist in the codebase
+
+## Steps
+
+### Step 1: Gather Context
+
+Run `git log --oneline -N` (N = COMMITS_TO_ANALYZE) to see recent changes and understand what was modified.
+
+Run `git log --oneline -N --name-only --pretty=format: | sort -u | grep -v '^$'` to get the full list of changed files.
+
+### Step 2: For Each File in AFFECTED_DOCS
+
+For each documentation file listed in AFFECTED_DOCS:
+
+1. **Read the documentation file** using the Read tool
+2. **Read the relevant source-of-truth code files** (see mapping below)
+3. **Compare**: identify sections that are factually outdated (wrong file paths, missing routes, incorrect model names, outdated env vars, stale tables)
+4. **Use Edit tool** to update ONLY the outdated sections — make minimal, targeted edits
+5. Move on to the next file
+
+### Step 3: Verify Changes
+
+After all updates, run `git diff` to verify:
+- Changes are minimal and correct
+- No unintended modifications
+- Formatting is preserved
+
+## Source-of-Truth Mapping
+
+Use this mapping to determine which code files to read when validating each documentation file.
+
+### README.md (dream-server/README.md)
+
+| Doc Section | Source of Truth |
+|-------------|----------------|
+| Service manifests table | `dream-server/extensions/services/*/manifest.yaml` |
+| CLI commands | `dream-server/dream-cli` |
+| Environment variables | `dream-server/.env.example`, `dream-server/.env.schema.json` |
+| Docker Compose services | `dream-server/docker-compose.base.yml`, GPU overlays |
+| Test commands | `dream-server/Makefile`, `dream-server/tests/` directory layout |
+| Install instructions | `dream-server/install-core.sh`, `dream-server/installers/phases/` |
+
+### CLAUDE.md
+
+| Doc Section | Source of Truth |
+|-------------|----------------|
+| Repository Structure | Actual directory layout |
+| Build & Development Commands | `dream-server/Makefile` targets |
+| Extension System | `dream-server/extensions/services/*/manifest.yaml` |
+| GPU Backend / Tier System | `dream-server/config/backends/*.json`, `dream-server/installers/lib/tier-map.sh` |
+| Dashboard API | `dream-server/extensions/services/dashboard-api/routers/*.py` |
+| Key File Paths | Actual file existence verification |
+| CI Workflows | `.github/workflows/*.yml` |
+
+## Per-Document Validation Rules
+
+### README.md
+- Service list must match existing extension manifests
+- CLI examples must match actual dream-cli commands
+- Environment variables must match `.env.example`
+- Do NOT modify the project description, badges, or contribution guidelines
+
+### CLAUDE.md
+- Repository Structure section paths must point to files that exist
+- Build commands must match Makefile targets
+- Extension list must match `extensions/services/` directory
+- Do NOT modify Design Philosophy, Let It Crash, KISS, Pure Functions, or SOLID sections
+
+## Important Reminders
+
+- You are in CI — there is NO human to ask questions to
+- If a documentation file in AFFECTED_DOCS does not exist, skip it silently
+- Every edit must be verifiable against actual source code — do not infer or hallucinate
+- Prefer no change over a wrong change

.github/scripts/anthropic_helper.py

@@ -0,0 +1,77 @@
+#!/usr/bin/env python3
+"""
+Shared helper for Anthropic API authentication.
+
+Provides a unified `create_message()` function using the Anthropic Python SDK.
+Used by scanner scripts: generate-type-hints.py, generate-docstrings.py
+"""
+
+import os
+import sys
+from dataclasses import dataclass, field
+from typing import Any
+
+
+@dataclass
+class Usage:
+    input_tokens: int
+    output_tokens: int
+
+
+@dataclass
+class ContentBlock:
+    type: str
+    text: str = ""
+
+
+@dataclass
+class MessageResponse:
+    """Minimal response object matching anthropic.Message interface used by scanner scripts."""
+
+    content: list[ContentBlock] = field(default_factory=list)
+    usage: Usage = field(default_factory=lambda: Usage(0, 0))
+
+
+def create_message(
+    *,
+    model: str,
+    max_tokens: int,
+    temperature: float,
+    messages: list[dict[str, Any]],
+    thinking: dict[str, Any] | None = None,
+) -> MessageResponse:
+    """Create a message using the Anthropic API."""
+    import anthropic
+
+    api_key = os.getenv("ANTHROPIC_API_KEY")
+    if not api_key:
+        print(
+            "::error::No API credentials. Set ANTHROPIC_API_KEY",
+            file=sys.stderr,
+        )
+        sys.exit(1)
+
+    client = anthropic.Anthropic(api_key=api_key)
+
+    kwargs: dict[str, Any] = dict(model=model, max_tokens=max_tokens, messages=messages)
+    if thinking:
+        kwargs["thinking"] = thinking
+        kwargs["temperature"] = 1
+    else:
+        kwargs["temperature"] = temperature
+
+    response = client.messages.create(**kwargs)
+
+    content_blocks = [
+        ContentBlock(type="text", text=block.text)
+        for block in response.content
+        if block.type == "text"
+    ]
+
+    return MessageResponse(
+        content=content_blocks,
+        usage=Usage(
+            input_tokens=response.usage.input_tokens,
+            output_tokens=response.usage.output_tokens,
+        ),
+    )