@legioncodeinc/rflectr 0.1.0

package/library/knowledge/private/security/credential-storage.md

@@ -0,0 +1,129 @@
+# Credential Storage & Environment Isolation
+
+> Category: Security | Version: 1.0 | Date: June 2026 | Status: Active
+
+Where secrets live, how they're resolved at launch, and the exact environment contract handed to each child process. This is the security-critical surface of `rflectr`. Read [`../architecture/system-overview.md`](../architecture/system-overview.md) first.
+
+**Related:**
+- [`../auth/oauth-device-flows.md`](../auth/oauth-device-flows.md)
+- [`../data/provider-registry.md`](../data/provider-registry.md)
+- [`../architecture/launch-flow-claude.md`](../architecture/launch-flow-claude.md)
+- Source: `src/env.ts`, `src/key-setup.ts`, `src/constants.ts`
+
+---
+
+## Where secrets live
+
+Secrets are **never** written to `providers.json` or `config.json`. Those files hold only an `authRef` pointer. The actual secret lives in one of three places, resolved in priority order by `resolveProviderCredential(providerId, authRef)` (`src/env.ts`):
+
+1. **Env var** — `RFLECTR_KEY_<PROVIDER_ID_UPPER>` (highest priority), or whatever `env:VAR_NAME` the `authRef` names (e.g. `env:OPENCODE_API_KEY`).
+2. **OS keyring** — via `@napi-rs/keyring`, service `rflectr`. Accounts:
+   - `provider:<id>` — an API key.
+   - `oauth:provider:<id>` — a JSON `StoredOAuthCredential` (see [`../auth/oauth-device-flows.md`](../auth/oauth-device-flows.md)).
+   - `global:opencode` — the shared OpenCode Zen/Go key.
+3. **Legacy keyring entries** — `rflectr` / `opencode-starter` accounts, auto-migrated on first successful read.
+
+`@napi-rs/keyring` is an `optionalDependency` loaded via dynamic `import()`, so a missing native binary degrades gracefully rather than crashing. `classifyKeyringError(err)` turns native failures into human messages ("Secret Service daemon is not running", "keychain access was denied or the keychain is locked", "native keyring module not available", …).
+
+```mermaid
+flowchart TD
+    need["launch needs a key for provider X"] --> env{"RFLECTR_KEY_X or env:VAR set?"}
+    env -->|yes| use["use it"]
+    env -->|no| ref{"authRef kind"}
+    ref -->|keyring:provider:X| kr["read keyring account"]
+    ref -->|keyring:oauth:provider:X| oauth["read + refresh OAuth credential"]
+    ref -->|keyring:global:opencode| zen["readGlobalOpencodeCredential() chain"]
+    kr --> use
+    oauth --> use
+    zen --> use
+```
+
+### The OpenCode Zen/Go fallback chain
+
+`readGlobalOpencodeCredential()` tries, in order: `OPENCODE_API_KEY` env var → keyring `global:opencode` → legacy keyring `rflectr` → oldest legacy service `opencode-starter`. On a successful legacy read, `migrateGlobalOpencodeCredential()` rewrites it to `global:opencode` using a **read → write → verify → delete** protocol (the old entry is only deleted after the new one verifies).
+
+---
+
+## Child process environment
+
+`buildChildEnv(baseUrl, model, apiKey, proxyPort?, contextWindow?, enableGatewayDiscovery?)` (`src/env.ts`) builds the env for the launched host. It is the security boundary: the parent shell is never mutated (except `OPENCODE_API_KEY` during interactive key setup).
+
+**Removed** — every var in `CONFLICTING_ENV_VARS` (`src/constants.ts`), so stale cloud config can't leak into the child:
+
+```
+CLAUDE_CODE_USE_VERTEX, ANTHROPIC_VERTEX_PROJECT_ID, ANTHROPIC_VERTEX_BASE_URL,
+CLOUD_ML_REGION, ANTHROPIC_BEDROCK_BASE_URL, ANTHROPIC_AWS_BASE_URL,
+ANTHROPIC_AWS_API_KEY, ANTHROPIC_AWS_WORKSPACE_ID, ANTHROPIC_FOUNDRY_API_KEY,
+ANTHROPIC_FOUNDRY_BASE_URL, ANTHROPIC_AUTH_TOKEN, ANTHROPIC_API_KEY,
+ANTHROPIC_BASE_URL, ANTHROPIC_MODEL, ANTHROPIC_DEFAULT_OPUS_MODEL,
+ANTHROPIC_DEFAULT_SONNET_MODEL, ANTHROPIC_DEFAULT_HAIKU_MODEL
+```
+
+**Set:**
+
+| Var | Value |
+|---|---|
+| `ANTHROPIC_BASE_URL` | `http://127.0.0.1:<proxyPort>` when a proxy is used, else `baseUrl` (which must **not** end in `/v1`) |
+| `ANTHROPIC_API_KEY` | the provider key, or the proxy token when proxying |
+| `ANTHROPIC_MODEL` | `claudeCodeClientModelId(stripOneMContextSuffix(model), contextWindow)` |
+| `CLAUDE_CODE_MAX_CONTEXT_TOKENS` | `resolveContextWindow(bareModel, contextWindow)` |
+| `CLAUDE_CODE_ENABLE_GATEWAY_MODEL_DISCOVERY` | `1` when `enableGatewayDiscovery` (switch-menu mode) |
+| `ENABLE_TOOL_SEARCH` | `true` — defer MCP tools like native Claude Code (`applyClaudeCodeThirdPartyCompat`) |
+| `CLAUDE_CODE_SIMPLE_SYSTEM_PROMPT` | `0` — keep the full system prompt on proxy routes |
+
+On the **anthropic direct-passthrough** path, the single-model launch additionally sets `CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS=1` to strip beta headers on the direct hop. On proxy routes the betas stay enabled so tool search works through the local proxy.
+
+`detectConflicts()` reports which of these vars were present (shown in `--dry-run` and warnings) so a user can see what was scrubbed.
+
+---
+
+## Interactive key setup
+
+`resolveOrCollectApiKey(simulate?, trace?)` (`src/key-setup.ts`) is called for the OpenCode Zen/Go key. On startup it silently calls the credential-store read first — if a key is found, no prompt appears. Otherwise it prompts for paste and offers platform-specific save options. In every case `process.env['OPENCODE_API_KEY']` is set immediately so the key is live for the current session regardless of save choice.
+
+| Platform | Options |
+|---|---|
+| **macOS** | Keychain only · Keychain + `~/.zshrc` autoload · shell profile (plaintext) · session only |
+| **Windows** | Credential Manager · `setx` user env var (plaintext) · session only |
+| **Linux desktop** | Secret Service (GNOME Keyring / KWallet) · shell profile (plaintext) · session only |
+| **Linux headless** | shell profile · session only (with a note explaining why secure storage is unavailable) |
+
+Notes:
+
+- The macOS autoload line uses the `security` CLI directly so the shell can source it: `export OPENCODE_API_KEY="$(security find-generic-password -s rflectr -a rflectr -w 2>/dev/null)"`.
+- `setx` is invoked with piped stdio to suppress its "SUCCESS" stdout.
+- Secret Service availability is probed with a test `getPassword()` (`isSecretServiceAvailable()`); if the daemon isn't running the option is hidden.
+- `detectShellProfile()` chooses the right profile file per platform/shell (`~/.zshrc`, `~/.bash_profile`, `~/.bashrc`, `~/.profile`).
+
+---
+
+## Trust boundaries
+
+```mermaid
+flowchart TD
+    subgraph trusted["Trusted — rflectr process"]
+        keyring["OS keyring"]
+        registry["providers.json (no secrets)"]
+        env["buildChildEnv()"]
+    end
+    subgraph child["Child host (Claude Code / Codex / Gemini)"]
+        proc["host process"]
+    end
+    subgraph net["Network"]
+        prov["upstream provider"]
+    end
+    keyring -->|resolved at launch| env
+    env -->|"scrubbed env + proxy token"| proc
+    proc -->|"127.0.0.1 only"| localproxy["local proxy"]
+    localproxy -->|"provider key (never to child)"| prov
+```
+
+Key properties:
+
+- The **provider's real key never reaches the child** when proxying — the child gets a random proxy token; the proxy holds the real key and calls upstream.
+- The proxy binds `127.0.0.1` only, on a random port, and validates the token, so other local processes can't use it.
+- Secrets are keyring-backed by default; plaintext options (`setx`, shell profile) are opt-in and clearly labelled.
+
+### Server-mode caveat
+
+The `server` command can bind in network mode and asks for a server password (`isAuthorized`, `sanitizeCredential` in `src/server/auth.ts`). When exposed beyond localhost, that password is the only gate — see [`../infrastructure/server-gateway.md`](../infrastructure/server-gateway.md).

package/library/knowledge/private/standards/documentation-framework.md

@@ -0,0 +1,154 @@
+# Documentation Framework
+
+> Category: Standards | Version: 1.0 | Date: (fill in on init) | Status: Canonical
+
+The single source of truth for how documentation is written in this repository. Every document — feature PRDs, issue PRDs, QA reports, architecture docs, API references, guides — must conform to the standards defined here. If a document type is not covered, add a new section to this file rather than inventing a local convention.
+
+---
+
+## 1. Document Types
+
+| Type | Purpose | Location | Primary audience |
+|---|---|---|---|
+| **Issue IRD** | Implementation plan for a specific GitHub issue | `library/requirements/issues/issue-<###>-<title>/ird-issue-<###>-<title>.md` | Implementation engineer |
+| **Feature PRD** | Planned feature spec (forward or retroactive) | `library/requirements/features/feature-<###>-<title>/prd-feature-<###>-<title>.md` (or `prd-feature-<###>-<title>-ck-<clickupId>.md` if from ClickUp) | Implementation engineer |
+| **QA Report (tied)** | Audit of an implementation against its plan | The plan's own `reports/<date>-qa-report.md` subfolder | Team lead, author of the feature |
+| **QA Report (standalone)** | Audit not tied to a single plan | `library/qa/<domain>/<date>-qa-report.md` | Team lead, audit reviewer |
+| **Architecture Doc** | System design, data flows, component relationships | `library/knowledge-base/architecture/` | Senior engineers, architects |
+| **API Reference** | Endpoint-by-endpoint documentation with schemas | `library/knowledge-base/api/` | Frontend devs, API consumers |
+| **How-to Guide** | Runbooks for setup, testing, deploying, adding features | `library/knowledge-base/how-to-guides/` | New engineers, DevOps |
+| **Integration Doc** | Third-party service configuration and error handling | `library/knowledge-base/integrations/` | DevOps, engineers wiring services |
+| **UX/UI Standard** | Visual design language — tokens, components, patterns | `library/knowledge-base/design/` | Designers, frontend devs |
+| **Feature Doc** | Completed feature reference (post-ship) | `library/knowledge-base/features/` | Any engineer joining the project |
+| **Spec** | Feature-level handoff spec for a UI flow | `library/knowledge-base/specs/` | Frontend engineers |
+| **Product Brief** | Product vision, scope, roadmap | `library/knowledge-base/product/` | Team, stakeholders |
+| **Standards Doc** | Rules for writing documentation itself | `library/knowledge-base/standards/` | All contributors |
+| **Release Notes** | What changed in each release | `library/knowledge-base/releases/` | All team members |
+
+---
+
+## 2. Universal Document Header
+
+Every markdown file under `library/knowledge-base/` starts with:
+
+```markdown
+# <Document Title>
+
+> Category: <Type> | Version: <X.Y> | Date: <Month YYYY> | Status: <Active | Draft | Archived>
+
+<One-sentence description of what this document covers and who should read it.>
+
+**Related:**
+- [Link to related doc]
+- [Link to source code: `src/path/to/file.ts`]
+```
+
+- **Version** — starts at `1.0`; patch bumps (`1.0` → `1.1`) for additions, minor bumps (`1.x` → `2.0`) for reorganizations.
+- **Date** — current month/year on the last meaningful edit.
+- **Status** values:
+  - `Active` — current, should be kept up to date
+  - `Draft` — work in progress, not authoritative
+  - `Archived` — historical, no longer maintained
+  - `Canonical` — (for standards docs only) highest authority; overrides ad-hoc conventions
+
+Requirements-type docs (issue IRDs, feature PRDs, QA reports) use a different header format documented in their respective guides.
+
+---
+
+## 3. Filename Conventions
+
+| Document type | Folder + filename pattern | Example |
+|---|---|---|
+| Issue IRD | `issue-<###>-<title>/ird-issue-<###>-<title>.md` (with sibling `reports/`) | `issue-046-stale-cached-responses/ird-issue-046-stale-cached-responses.md` |
+| Feature PRD | `feature-<###>-<title>/prd-feature-<###>-<title>.md` (with sibling `reports/`) | `feature-007-user-profile-export/prd-feature-007-user-profile-export.md` |
+| Feature PRD (from ClickUp) | `feature-<###>-<title>/prd-feature-<###>-<title>-ck-<clickupId>.md` | `feature-007-user-profile-export/prd-feature-007-user-profile-export-ck-86c8wq2k1.md` |
+| QA report (tied to plan) | `<plan-folder>/reports/<date>-qa-report.md` | `feature-007-user-profile-export/reports/2026-04-26-qa-report.md` |
+| QA report (standalone) | `library/qa/<domain>/<date>-qa-report.md` | `library/qa/auth/2026-04-26-qa-report.md` |
+| Knowledge-base | `<domain>/<kebab-slug>.md` (no numeric prefix) | `architecture/authentication-flow.md` |
+
+**Numbering rules:**
+- `<###>` is **3-digit zero-padded** (`006`, `046`, `093`, `100`). 4+ digit natural width.
+- Issue numbers follow the GitHub issue number.
+- Feature numbers are repo-local sequential; take `max + 1` from existing folders (open + `completed/`).
+- Titles are lowercase kebab-case, ≤60 chars.
+- The optional ClickUp suffix `-ck-<clickupId>` goes on the **main file only**, never on the folder name.
+
+---
+
+## 4. Folder Location Rules
+
+| Folder | Meaning |
+|---|---|
+| `library/requirements/features/feature-<###>-<title>/` | Feature work in progress. |
+| `library/requirements/features/completed/feature-<###>-<title>/` | Feature has shipped. Move the entire folder (PRD + `reports/`). |
+| `library/requirements/issues/issue-<###>-<title>/` | Issue work in progress (GitHub issue OPEN). |
+| `library/requirements/issues/completed/issue-<###>-<title>/` | Issue has been resolved (GitHub issue CLOSED). Move the entire folder (IRD + `reports/`). Symmetric to features. |
+| `<plan-folder>/reports/` | QA reports tied to that specific feature/issue. Travel with the folder when it moves. |
+| `library/qa/<domain>/` | Standalone QA reports — broad audits not tied to a single plan. |
+
+Move folders when status changes. Never edit lifecycle state in frontmatter alone.
+
+---
+
+## 5. Writing Rules (all doc types)
+
+1. **Ground every claim in code.** Quote source with file path + line range; never paraphrase signatures.
+2. **One topic per document.** Split if a doc exceeds ~500 lines.
+3. **Progressive disclosure.** Open with "why this exists" and "who should read it"; deep details below.
+4. **Link out, don't duplicate.** If another doc covers a subtopic, link to it.
+5. **Diagrams use mermaid.** Prefer `flowchart TD` or `sequenceDiagram`. No explicit colors.
+6. **No time-sensitive language.** Avoid "currently", "recently", "as of". Use explicit dates.
+7. **No personal opinions.** Docs describe decisions and rationale, not preferences.
+
+---
+
+## 6. Cross-Linking Conventions
+
+- Use relative paths: `[title](../relative/path.md)`.
+- Link to code with file paths (and line numbers where useful): `` `src/routes/users.ts:42-80` ``.
+- PRDs and IRDs link to their related issues, features, and QA reports in a **Related** section at the end.
+- Knowledge-base docs link to the PRDs that drove them (when applicable) and to source code.
+
+---
+
+## 7. Diagram Rules
+
+- Mermaid preferred (renders everywhere GitHub does).
+- Use `flowchart TD` (top-down) for process flows; `sequenceDiagram` for temporal flows; `erDiagram` for data models.
+- Node IDs: no spaces (use `camelCase` or `under_scores`).
+- No explicit colors (breaks dark mode).
+- No `click` events.
+- Quote labels containing parentheses, brackets, or colons.
+
+---
+
+## 8. Versioning + Dates
+
+- **Versioning** is per-document, not repo-wide. Bump on meaningful content change.
+- **Dates** use the current month/year (from the system clock), not arbitrary timestamps.
+- Each document optionally ends with a **Changelog** section listing version bumps.
+
+---
+
+## 9. Ownership
+
+- Requirements docs (issue IRDs, feature PRDs) are owned by the implementation author. QA reports are owned by `quality-guardian`.
+- Knowledge-base docs are owned by the team collectively — anyone may edit with a PR.
+- Standards docs (this file included) require team consensus before changing.
+
+---
+
+## 10. Bootstrap — After `initialize`
+
+When `library-guardian initialize` seeds a repo:
+
+1. Replace the placeholder "(fill in on init)" in the header above with the current month/year.
+2. Replace any project-name placeholders in the seeded README files with your repo's actual name.
+3. Edit any section of this framework that doesn't match your team's conventions — then commit.
+4. Start using the agent: ingest issues, plan features, document architecture.
+
+---
+
+## Changelog
+
+- v1.0 — Initial template seeded by `library-guardian`. Customize per repo.

package/library/knowledge/public/README.md

@@ -0,0 +1,49 @@
+---
+ai_description: |
+  This folder contains customer-facing / end-user documentation.
+  Approved sub-folders: overview/, guides/, faqs/, and any domain
+  folder explicitly designated public by the team.
+  Do NOT file internal engineering docs, ADRs, pricing strategy, or
+  security-sensitive material here.
+  Write path: library/knowledge/public/<domain>/<kebab-slug>.md.
+  All files here may eventually be surfaced in the public help center
+  (Phase 2). Mark each doc with the standard knowledge-base header:
+  Category / Version / Date / Status.
+human_description: |
+  Customer-facing documentation. Content here may be published externally.
+  - overview/: what this product is, glossary, elevator pitch
+  - guides/: how-to guides written for users, not developers
+  - faqs/: frequently asked questions
+  Only add content here that you are comfortable sharing publicly.
+  Internal notes, pricing strategy, and architecture docs belong in
+  knowledge/private/ instead.
+---
+
+# Knowledge — Public
+
+Customer-facing documentation for **rflectr** by [Legion Code Inc.](https://github.com/legioncodeinc) Anything in this folder may eventually be published to the help center.
+
+## Documentation map
+
+**Start here:** [What is rflectr?](overview/what-is-rflectr.md)
+
+| Section | Docs |
+|---|---|
+| [Overview](overview/) | [What is rflectr?](overview/what-is-rflectr.md) |
+| [Guides](guides/) | [Providers](guides/providers.md) · [Claude Desktop](guides/claude-desktop.md) · [Codex](guides/codex.md) · [Gemini CLI](guides/gemini-cli.md) · [API Server](guides/api-server.md) · [AI Agents](guides/ai-agents.md) · [Model Compatibility](guides/model-compatibility.md) |
+| [FAQs](faqs/) | [Troubleshooting](faqs/troubleshooting.md) |
+
+## Approved sub-folders
+
+| Folder | Contents |
+|---|---|
+| `overview/` | What this product is, glossary, elevator pitch, high-level FAQs |
+| `guides/` | Step-by-step user guides (written for customers, not developers) |
+| `faqs/` | Frequently asked questions from customers |
+
+## What does NOT belong here
+
+- Internal architecture docs or ADRs
+- Pricing strategy or competitive analysis
+- Engineering standards
+- Anything you would not want a customer to read

package/library/knowledge/public/faqs/README.md

@@ -0,0 +1,7 @@
+# FAQs
+
+Common questions and fixes.
+
+| Doc | Covers |
+|---|---|
+| [troubleshooting.md](troubleshooting.md) | Launch issues with `rflectr claude` — the "Not logged in" prompt, placeholder keys, cloud-builtin providers, and `--trace`. |

package/library/knowledge/public/faqs/troubleshooting.md

@@ -0,0 +1,92 @@
+# Troubleshooting
+
+> Category: FAQ | Version: 1.0 | Date: June 2026 | Status: Active
+
+Common issues when launching **Claude Code** through `rflectr claude`. For Claude Desktop gateway issues, see the [Claude Desktop guide](../guides/claude-desktop.md). For agent/headless issues, see [AI Agents & automation](../guides/ai-agents.md).
+
+---
+
+## "Not logged in · Please run /login" after picking a model
+
+**What you see:** Claude Code starts and shows the right model in the status bar (e.g. `moonshotai/kimi-k2.6`), but sending a message returns `Not logged in · Please run /login`.
+
+**Common cause — you chose "No" on the API key prompt.** When Claude Code detects an `ANTHROPIC_API_KEY` in the session (rflectr sets this for your chosen provider), it may ask:
+
+```text
+Detected a custom API key in your environment
+Do you want to use this API key?
+  1. Yes
+  2. No (recommended)
+```
+
+If you pick **No**, Claude Code remembers that and refuses to use the key. rflectr is routing through your provider correctly — Claude Code is blocking the key you rejected. This is **not** a rflectr bug and doesn't mean your provider is misconfigured.
+
+**Fix — approve the key in Claude Code's config.** Claude Code stores your answer in `~/.claude.json` under `customApiKeyResponses`.
+
+1. Quit Claude Code.
+2. Open `~/.claude.json`.
+3. Find the key suffix shown in the prompt (the last part of the masked key, e.g. `iFYB03v8xy4E-xJEYpN8`).
+4. Move that suffix from `rejected` to `approved`:
+
+```json
+"customApiKeyResponses": {
+  "approved": ["anything", "iFYB03v8xy4E-xJEYpN8"],
+  "rejected": []
+}
+```
+
+5. Save and run `rflectr claude` again.
+
+> 💡 **Easier next time:** choose **Yes** when the prompt appears — Claude Code remembers approved keys and won't ask again.
+
+**If you use Claude Max / Pro elsewhere:** you may also have a real Anthropic key in your shell (`~/.zshrc`, etc.). That's fine for other tools. rflectr replaces `ANTHROPIC_API_KEY` in the Claude Code child process with your **provider** key (OpenCode, Nvidia, Groq, …). Pick **Yes** when launching through rflectr.
+
+---
+
+## Provider works in `rflectr models` but not in `providers list`
+
+Zen and Go are **cloud builtins** — they appear when you have an OpenCode API key, even if they aren't saved in `~/.rflectr/providers.json`. `rflectr providers list` shows them tagged `· cloud builtin`. Imported BYOK providers (Anthropic, Nvidia, Groq, …) come from the registry file.
+
+---
+
+## OpenCode import saved placeholder API keys
+
+If you ran `rflectr providers import` on an older build and see refresh failures for Anthropic (`anything`) or Vertex (`a`), those came from **OpenCode's config**, not Claude Desktop.
+
+**Current behavior:** import validates keys before saving to the keychain:
+
+- Placeholders like `anything`, `a`, `ollama` → **not saved** (models still imported).
+- Real keys → probed against the provider API before save.
+- Vertex / Bedrock / Azure → key not saved (gcloud / AWS auth).
+
+**To clean up an old placeholder:** re-run import (choose **Use imported** for each provider), or remove the provider and import again:
+
+```bash
+rflectr providers import
+```
+
+---
+
+## Use `--trace` for proxy / API errors
+
+If a model fails mid-session (not the login prompt above):
+
+```bash
+rflectr claude --trace
+```
+
+After exit, rflectr prints errors from `~/.rflectr/logs/claude-debug.log` (secrets redacted in the summary). The proxy also logs to `~/.rflectr/logs/proxy-debug.log` when `--trace` is set.
+
+---
+
+## Still stuck?
+
+1. `rflectr providers list` — confirm the provider is there and enabled.
+2. `rflectr claude --dry-run` — preview provider, model, and endpoint without launching.
+3. Open a GitHub issue with the provider name, model id, and (redacted) error text.
+
+---
+
+## Related guides
+
+- [Claude Desktop](../guides/claude-desktop.md) · [Codex](../guides/codex.md) · [AI Agents](../guides/ai-agents.md) · [Providers](../guides/providers.md)

package/library/knowledge/public/guides/README.md

@@ -0,0 +1,13 @@
+# Guides
+
+Step-by-step guides for each rflectr surface. New here? Read [What is rflectr?](../overview/what-is-rflectr.md) first.
+
+| Guide | Use it to… |
+|---|---|
+| [providers.md](providers.md) | See every provider, its base URL, and gotchas; add or import providers. |
+| [claude-desktop.md](claude-desktop.md) | Point Claude Desktop (Cowork + Code) at a local rflectr gateway, and revert cleanly. |
+| [codex.md](codex.md) | Run the OpenAI Codex CLI or desktop app on any registry model. |
+| [gemini-cli.md](gemini-cli.md) | Run the Google Gemini CLI on any registry model (experimental). |
+| [api-server.md](api-server.md) | Run the local Anthropic/OpenAI-compatible gateway (`rflectr server`). |
+| [ai-agents.md](ai-agents.md) | Drive rflectr from scripts, CI, and agents with boot flags and clean stdout. |
+| [model-compatibility.md](model-compatibility.md) | Understand why a model is hidden, and how to change that. |