{
  "markdown": "<!-- markdownlint-disable MD033 MD041 -->\n\n# HWJ Wiki\n\nHWJ Wiki 是基于 OpenWiki 的个人工作流发行版。它保留上游 Wiki 生成引擎和完整\nGit 历史，并增加本地 LiteLLM（`localhost:4001`）、默认中文、\nPi/Codex/Antigravity 历史、豆包导出、隐私脱敏和项目踩坑索引。\n\n个人历史通过本地待处理队列分批整理：一次 `personal --init/--update` 会按\nPi、Codex、Antigravity、豆包轮询处理到 backlog 清空，但每次模型调用仍只\n接收一个约 100 条、80KB 的受控批次。每批通过质量门后立即确认；中断或网关\n故障时状态为 `partial`，重新运行会从最后成功批次继续。`--print` 在 partial\n时返回退出码 `2`，方便脚本区分“仍需续跑”和真正的 complete。\n\n个人模式先把脱敏历史提取成带 `stableKey`、`sourceRefs`、可信度和时效标记的\n结构化候选，再用严格限定的目标提示词交给原 OpenWiki Agent 合并。安全降级也\n只消费结构化候选，并执行同一套 OKF、索引、断链、去重、来源和敏感信息检查；\n降级页面进入独立复核队列，复核完成前不会误报 `complete`。个人候选提取默认关闭\n模型客户端的额外重试，由适配层统一控制分片和重试，避免网关抖动被多层重试放大；\n单次提取截止时间默认为 300000ms，也可通过\n`OPENWIKI_PERSONAL_EXTRACTION_TIMEOUT_MS` 调整；确实需要时可设置\n`OPENWIKI_PERSONAL_EXTRACTION_PROVIDER_RETRIES`（非负整数）。\n\n```bash\nnpm install --global hwj-wiki\nopenwiki code --update\nopenwiki personal --update\n```\n\n也可以安装 GitHub 开发版本：\n\n```bash\nnpm install --global github:hwj123hwj/hwj-wiki\n```\n\n没有显式 Provider 配置时会连接 `http://localhost:4001/v1`，默认模型为\n`coding`、默认语言为中文。显式 Provider、模型、语言和网关 Key 始终优先。\n个性化设计见[实现基线](./docs/openwiki_customization_plan.md)，上游同步见\n[同步说明](./docs/upstream-sync.md)。\n\n> 上游项目：[langchain-ai/openwiki](https://github.com/langchain-ai/openwiki)\n\n## OpenWiki upstream capabilities\n\n<div align=\"center\">\n\n<img alt=\"OpenWiki\" src=\"./static/openwiki-lockup.png\" width=\"620\">\n\n### The self-maintaining wiki. Built for agents, explored by humans.\n\n[![npm version](https://img.shields.io/npm/v/hwj-wiki.svg?style=flat&labelColor=030710&color=1A6FB5)](https://www.npmjs.com/package/hwj-wiki)\n[![downloads](https://img.shields.io/npm/dm/hwj-wiki.svg?style=flat&labelColor=030710&color=1A6FB5)](https://www.npmjs.com/package/hwj-wiki)\n[![Node](https://img.shields.io/node/v/hwj-wiki.svg?style=flat&labelColor=030710&color=1A6FB5)](https://nodejs.org)\n[![License: MIT](https://img.shields.io/badge/license-MIT-1A6FB5.svg?style=flat&labelColor=030710)](./LICENSE)\n[![Built with Deep Agents](https://img.shields.io/badge/built%20with-DeepAgents-1A6FB5.svg?style=flat&labelColor=030710)](https://github.com/langchain-ai/deepagentsjs)\n\n<a href=\"https://trendshift.io/repositories/70339?utm_source=trendshift-badge&amp;utm_medium=badge&amp;utm_campaign=badge-trendshift-70339\" target=\"_blank\" rel=\"noopener noreferrer\"><img src=\"https://trendshift.io/api/badge/trendshift/repositories/70339/daily\" alt=\"langchain-ai%2Fopenwiki | Trendshift\" width=\"250\" height=\"55\"/></a>\n\n</div>\n\nOpenWiki is a CLI that writes and maintains a wiki for your codebase or your personal knowledge. An agent reads your sources, synthesizes a linked Markdown wiki you own, and keeps it current on every change. It is built for agents to read as memory, and it ships an interactive visualizer for humans to explore.\n\n**OpenWiki gives you:**\n\n- **Agent-written docs** that stay accurate, generated by a [Deep Agents](https://github.com/langchain-ai/deepagentsjs) documentation agent.\n- **Two modes:** a `code` wiki for a repository, or a `personal` wiki for your own knowledge.\n- **Twelve model providers** out of the box, from OpenAI and Anthropic to Bedrock, Gemini, and any OpenAI-compatible gateway.\n- **Built-in connectors** for Custom MCP, internal system feeds, Notion, Slack, Gmail, X, Web Search, Hacker News, and local git repositories.\n- **An interactive visualizer** that turns any wiki into a live, explorable node graph.\n- **Self-updating** through GitHub Actions, GitLab CI, or Bitbucket Pipelines.\n- **Open Knowledge Format** ([OKF v0.1](https://github.com/GoogleCloudPlatform/knowledge-catalog/blob/main/okf/SPEC.md)) output with validated Mermaid diagrams.\n\n## 🎉 What's new\n\n- **Custom MCP connector:** point OpenWiki at any MCP server and pull its tools into a run, no bespoke integration required.\n- **LangSmith APAC region:** the LangSmith connector now works against APAC-hosted workspaces.\n- **OpenAI Responses API:** OpenAI-compatible providers can opt into the Responses API instead of Chat Completions.\n- **Provider-aware CI:** the generated self-update workflow now emits an env block matched to your configured provider, so scheduled runs work out of the box.\n\n## Quick start\n\nInstall the CLI:\n\n```sh\nnpm install -g hwj-wiki\n```\n\nGenerate a wiki for the current repository. The first run walks you through picking a provider, key, and model, then writes docs to `openwiki/`:\n\n```sh\nopenwiki --init\n```\n\nKeep it current automatically by adding a scheduled CI job that opens a docs PR on every change:\n\n- **GitHub Actions:** copy [`openwiki-update.yml`](./examples/openwiki-update.yml) into `.github/workflows/openwiki-update.yml`.\n- **GitLab CI:** copy [`openwiki-update.gitlab-ci.yml`](./examples/openwiki-update.gitlab-ci.yml) into `.gitlab-ci.yml` or include it from your pipeline.\n- **Bitbucket Pipelines:** copy [`openwiki-update.bitbucket-pipelines.yml`](./examples/openwiki-update.bitbucket-pipelines.yml) into `bitbucket-pipelines.yml`, then schedule the `openwiki-update` pipeline.\n\n> [!NOTE]\n> On Windows, install with a Node.js package manager (`npm install -g hwj-wiki` or `pnpm add -g hwj-wiki`). Installing with `bun` can fall back to compiling the `better-sqlite3` native dependency, which needs Visual Studio Build Tools with the Desktop development with C++ workload.\n\n## Two modes\n\nOpenWiki runs in one of two modes. Bare `openwiki`, `openwiki --init`, and `openwiki --update` default to **code** mode; add the `personal` positional (or `--mode personal`) for the personal brain.\n\n| Mode                 | Documents              | Writes to               | Get started                |\n| -------------------- | ---------------------- | ----------------------- | -------------------------- |\n| **Code** _(default)_ | The current repository | `openwiki/` in the repo | `openwiki --init`          |\n| **Personal**         | Your connected sources | `~/.openwiki/wiki`      | `openwiki personal --init` |\n\nBy default the CLI stays open after a run so you can send follow-up messages. Add `-p` / `--print` for a one-shot, non-interactive run that prints the final output and exits. `--init` and `--update` auto-exit on success in an interactive terminal, so the same command works one-shot or interactively.\n\n## Explore your wiki\n\nTurn any wiki into an interactive node graph with a live, side-by-side Markdown reader:\n\n```sh\nopenwiki visualize\n```\n\n<div align=\"center\">\n  <img alt=\"The OpenWiki visualizer: an interactive node graph beside a live Markdown reader.\" src=\"./static/visualizer.gif\" width=\"880\">\n</div>\n\nThis serves `./openwiki` on a local loopback address (`127.0.0.1`, never exposed on the network) and opens your browser to the graph. Edits to the wiki files are picked up automatically while the server runs. Pass a path to visualize a different directory, `--port <port>` to choose the port (it increments on conflict; default `4321`), and `--no-open` to leave the browser alone:\n\n```sh\nopenwiki visualize openwiki --port 4400 --no-open\n```\n\n> [!NOTE]\n> The page loads its graph, Markdown, and diagram libraries from a public CDN, so an internet connection is required even though the server itself is local. Press Ctrl-C to stop it.\n\n## Connect your sources\n\nIn `personal` mode, OpenWiki ingests knowledge from the tools you already use, synthesizing them into your local wiki. First-run onboarding offers setup for **local git repositories, the LLM Gateway, internal system feeds, Notion, Gmail, X/Twitter, Web Search, and Hacker News**.\n\nDuring an ingestion run, deterministic connector tools write raw data and manifests under `~/.openwiki/connectors/<connector>/raw/`, then source-specific agent runs synthesize the wiki under `~/.openwiki/wiki/`. You can configure the same connector more than once (for example one Web Search source for AI research and another for NBA news); OpenWiki stores them as separate instances like `web-search-1` and `web-search-2`.\n\n```sh\nopenwiki auth notion        # run a local browser OAuth flow for a provider\nopenwiki ingest all         # run every configured source\nopenwiki ingest web-search  # run one connector's sources\nopenwiki ingest gateway     # import the next Gateway archive page\nopenwiki ingest internal    # consume our local Gmail/Slack/Notion feed\n```\n\n### Internal system feeds (recommended for our infrastructure)\n\nGmail, Slack, and Notion do not need to be authorized in OpenWiki. Our own systems can append sanitized JSONL envelopes to `~/.openwiki/internal-sources/google.jsonl`, `slack.jsonl`, and `notion.jsonl`; OpenWiki reads them with a durable cursor and writes evidence under `~/.openwiki/connectors/internal/raw/`. The required envelope fields are `id`, `source`, `kind`, `text`, and ISO `timestamp`; optional `updatedAt`, `title`, `url`, `author`, and non-sensitive `metadata` are supported. Producers must redact credentials before writing.\n\nSet `OPENWIKI_INTERNAL_SOURCE_ROOT` to use another feed directory, or configure `~/.openwiki/connectors/internal/config.json` for additional source streams and limits. Run `openwiki ingest internal` after configuring an `internal` source instance in onboarding; the normal scheduled personal update then performs deterministic feed ingestion before wiki synthesis.\n\n<details>\n<summary><b>Connector details and OAuth</b></summary>\n\n<br/>\n\n- `git-repo` reads configured local repository paths and writes compact manifests.\n- `x` uses the X API directly with OAuth user-context credentials for home timeline, user posts, mentions, bookmarks, and list posts.\n- `notion` targets the hosted Notion MCP server, so authenticate through Notion OAuth rather than pasting a token.\n- `google` uses the Gmail API directly with OAuth user credentials to fetch recent mail.\n- `web-search` uses Tavily through LangChain and requires `TAVILY_API_KEY`.\n- `hackernews` uses the public Hacker News feed and search APIs, with no credentials required.\n- `gateway` reads the sanitized JSONL export from `/admin/archives/export`, stores raw connector data under `~/.openwiki/connectors/gateway/raw/`, and advances a durable cursor only after the raw page is written. It requires `OPENWIKI_GATEWAY_ADMIN_TOKEN` (the admin token is never put in connector config or generated wiki pages).\n- OpenWiki model requests are tagged as `hwj-wiki-agent`; the Gateway connector excludes that source by default and skips synthesis when no external archives remain, preventing recursive self-ingestion.\n\nFor a local Gateway, the default endpoint is `http://127.0.0.1:4001`. To use another endpoint, set `OPENWIKI_GATEWAY_URL` or write a connector config without the secret:\n\n```sh\nexport OPENWIKI_GATEWAY_URL=\"https://gateway.example.com\"\nexport OPENWIKI_GATEWAY_ADMIN_TOKEN=\"<admin-token>\"\nmkdir -p ~/.openwiki/connectors/gateway\ncat > ~/.openwiki/connectors/gateway/config.json <<'JSON'\n{\n  \"baseUrl\": \"https://gateway.example.com\",\n  \"adminTokenEnv\": \"OPENWIKI_GATEWAY_ADMIN_TOKEN\",\n  \"enabled\": true,\n  \"limit\": 100\n}\nJSON\nopenwiki ingest gateway\n```\n\nThe connector can be attached to OpenWiki's existing recurring ingestion schedule through personal-mode onboarding. Failed requests and malformed export pages keep the previous cursor so the next run retries the same page.\n\n`openwiki auth <provider>` runs a local browser OAuth flow, saves returned tokens into `~/.openwiki/.env`, creates connector config when possible, and discovers MCP tools for MCP-backed providers. Slack and Gmail require app client credentials to already be set in that file; Notion uses dynamic client registration for hosted MCP; X uses OAuth 2.0 with PKCE. `openwiki auth configure <provider>` and `openwiki auth tools <provider>` are advanced retry commands.\n\nConnector secrets are referenced by env var name and stored in `~/.openwiki/.env`; connector config files never contain raw secret values.\n\n**Slack OAuth tunnel.** `openwiki ngrok start` starts an ngrok tunnel with a random HTTPS forwarding URL, reads ngrok's local inspection API, appends `/callback`, and saves `OPENWIKI_HTTPS_OAUTH_REDIRECT_URI` automatically. Register the printed callback URL in Slack. With a fixed domain, run `openwiki ngrok start https://<your-ngrok-domain>`.\n\n</details>\n\n### LangSmith connector (code mode)\n\nThe connectors above feed a `personal` wiki. The **LangSmith** connector instead enriches a `code` wiki: it pulls recent LangSmith traces (tool calls, outcomes, and latency) for the projects you choose through the official LangSmith SDK, so a repository's docs reflect how its code actually behaves at runtime, not just what the source says.\n\nConfigure it during `openwiki --init` in `code` mode. From the source menu, add LangSmith, pick your workspace region (US or EU), and list the projects to document. OpenWiki writes a committed `openwiki/.langsmith.json` that names the workspaces and projects (never the key itself), so every teammate and CI run documents the same set. The API key is read from the environment:\n\n```sh\nOPENWIKI_LANGSMITH_API_KEY=\"<your-langsmith-key>\"\n```\n\nLocally the setup wizard saves this to `~/.openwiki/.env`. In CI, set it as a repository secret and export it for the run.\n\n> [!NOTE]\n> A LangSmith key is workspace- and region-bound. To document projects across more than one workspace, add an entry per workspace, each with its own key named `OPENWIKI_LANGSMITH_API_KEY_2`, `OPENWIKI_LANGSMITH_API_KEY_3`, and so on. The connector only talks to the official US (`api.smith.langchain.com`) and EU (`eu.api.smith.langchain.com`) hosts.\n\n## How it stays yours\n\nEverything OpenWiki writes is plain Markdown you own and version alongside your code.\n\n- **Agents read it as memory.** On each `code` run, OpenWiki maintains an `AGENTS.md` and `CLAUDE.md` at the repo root that point your coding agent at the wiki. It only rewrites its own `<!-- OPENWIKI:START -->…<!-- OPENWIKI:END -->` block and leaves the rest of each file untouched.\n- **You set the brief.** Repository-specific instructions live in `openwiki/INSTRUCTIONS.md`, a user-authored file OpenWiki reads for scope and priorities but never rewrites during normal runs.\n- **No-op runs are free.** After a run, OpenWiki snapshots the `openwiki/` directory and only records new metadata when something actually changed, so scheduled workflows never churn.\n- **Local, private config.** Provider choice, keys, and optional LangSmith tracing are saved to `~/.openwiki/.env` on your machine.\n\n## Open Knowledge Format\n\nOpenWiki emits [Google Open Knowledge Format (OKF) v0.1](https://github.com/GoogleCloudPlatform/knowledge-catalog/blob/main/okf/SPEC.md) bundles in both modes, so your wiki is portable to any OKF-aware tool.\n\n- Every concept document carries YAML front matter with a non-empty `type`; all other standard fields are optional.\n- Standard Markdown links between concept documents express their relationships.\n- `index.md` and `log.md` are reserved documents rather than concepts. The root index declares `okf_version: \"0.1\"`.\n- Valid `timestamp` values and producer-defined extension fields are preserved across updates and migrations.\n\n## Diagrams\n\nOpenWiki embeds **Mermaid** diagrams wherever they make a concept clearer than prose: sequence diagrams for runtime flows, ER diagrams for data models, state diagrams for lifecycles, and flowcharts for control flow. Diagrams are grounded in the inspected source, added where they add signal, and kept in sync on `--update`. No configuration is required.\n\nAfter each run, OpenWiki validates every `mermaid` fence. A diagram that fails validation is converted in place to a plain `text` fence with a short comment explaining why, so it degrades to readable text instead of a broken block. The next `--update` finds that comment and repairs the diagram, so quality recovers over successive runs.\n\n> [!TIP]\n> By default OpenWiki runs a lightweight, zero-dependency check that catches common breakages. For authoritative validation that matches exactly what GitHub renders, install the Mermaid parser wherever you run OpenWiki (for example in your scheduled workflow), and no broken diagram will ship:\n>\n> ```sh\n> npm install mermaid jsdom\n> ```\n\n## Model providers\n\nThe onboarding default is OpenAI with `gpt-5.6-terra`. Every provider includes preset model options plus support for custom model IDs, and stores its credentials in `~/.openwiki/.env`.\n\n| Provider                                                     | Credential                              |\n| ------------------------------------------------------------ | --------------------------------------- |\n| **OpenAI** _(default)_                                       | `OPENAI_API_KEY`                        |\n| **OpenAI (ChatGPT login)**                                   | Browser sign-in, uses your ChatGPT plan |\n| **Anthropic**                                                | `ANTHROPIC_API_KEY`                     |\n| **Gemini** (AI Studio)                                       | `GEMINI_API_KEY`                        |\n| **Gemini Enterprise** (Vertex AI)                            | Google ADC, keyless                     |\n| **AWS Bedrock**                                              | IAM credentials                         |\n| **GitHub Copilot**                                           | GitHub CLI session                      |\n| **OpenRouter**                                               | `OPENROUTER_API_KEY`                    |\n| **Nebius / Fireworks / Baseten / NVIDIA NIM**                | Provider API key                        |\n| **OpenAI-compatible** (LiteLLM, Ollama, LM Studio, gateways) | Base URL + key                          |\n\n<details>\n<summary><b>GitHub Copilot</b></summary>\n\n<br/>\n\nThe GitHub Copilot provider routes inference through the OpenAI-compatible Copilot API (`https://api.githubcopilot.com`), so teams can reuse an existing Copilot subscription instead of provisioning a separate inference key.\n\n1. Select `GitHub Copilot` during `openwiki --init`. If you have an active [GitHub CLI](https://cli.github.com) session, OpenWiki detects it and offers to reuse it. Otherwise, press <kbd>Tab</kbd> at the credential prompt to run `gh auth login` and sign in.\n2. Choose a model (for example `gpt-5.5`).\n\nOpenWiki leaves the token in the GitHub CLI's own credential store. For CI or another headless environment, set `COPILOT_API_KEY` to a GitHub **OAuth token**. Personal Access Tokens are rejected by the Copilot API for third-party integrations. The local config can stay token-free:\n\n```env\nOPENWIKI_PROVIDER=\"copilot\"\nOPENWIKI_MODEL_ID=\"gpt-5.5\"\n```\n\nIn CI, set the `COPILOT_API_KEY` repository secret and export `OPENWIKI_PROVIDER=copilot`.\n\n</details>\n\n<details>\n<summary><b>AWS Bedrock</b></summary>\n\n<br/>\n\nThe `bedrock` provider calls foundation models on AWS Bedrock using IAM credentials rather than a single vendor key:\n\n```bash\nOPENWIKI_PROVIDER=bedrock\nBEDROCK_AWS_ACCESS_KEY_ID=your-access-key-id\nBEDROCK_AWS_SECRET_ACCESS_KEY=your-secret-access-key\nBEDROCK_AWS_REGION=us-east-1\nOPENWIKI_MODEL_ID=anthropic.claude-sonnet-5\n```\n\nWhen explicit Bedrock credentials are not set, OpenWiki uses the AWS SDK default credential provider chain (OIDC/web identity, IAM roles, AWS profiles, ECS/EC2). The region resolves from `BEDROCK_AWS_REGION`, `AWS_REGION`, or `AWS_DEFAULT_REGION`. Available model IDs depend on which foundation models you have enabled in your account and region, so there is no preset list; paste the Bedrock model ID directly.\n\nSome newer models only accept on-demand invocation through a cross-region inference profile. If you see `ValidationException: Invocation of model ID ... with on-demand throughput isn't supported`, prefix the model ID with the profile's region code, for example `us.anthropic.claude-sonnet-5`. Your IAM policy then also needs `bedrock:InvokeModel` / `InvokeModelWithResponseStream` on both the `foundation-model` and `inference-profile` resource types.\n\n</details>\n\n<details>\n<summary><b>Gemini (AI Studio) and Gemini Enterprise (Vertex AI)</b></summary>\n\n<br/>\n\n**Gemini (AI Studio)** runs Google's Gemini models with a single API key:\n\n```bash\nOPENWIKI_PROVIDER=gemini\nGEMINI_API_KEY=your-ai-studio-key\n```\n\n**Gemini Enterprise** runs models from the Gemini Enterprise Model Garden (formerly Vertex AI): Google's Gemini/Gemma, Anthropic's Claude, and partner/open-weight models (Llama, Mistral, DeepSeek, Qwen). It routes each model ID to the right API surface automatically and uses no API key. Authentication happens with Google Application Default Credentials (ADC):\n\n- a service account key file via `GOOGLE_APPLICATION_CREDENTIALS=/path/to/key.json`,\n- user credentials from `gcloud auth application-default login`, or\n- workload identity when running on Google Cloud or in CI.\n\n```bash\nOPENWIKI_PROVIDER=gemini-enterprise\nGOOGLE_CLOUD_PROJECT=your-gcp-project\nGOOGLE_CLOUD_LOCATION=global   # optional, defaults to global\n```\n\nSet `OPENWIKI_MODEL_ID` to any Model Garden model. Gemini and Claude ship as presets; partner models are reached by pasting their ID (for example `publishers/meta/models/llama-3.3-70b-instruct-maas`). The credentials need Vertex AI access (`roles/aiplatform.user`), and the models must be enabled in the Model Garden. The `global` endpoint serves Gemini and Claude with the best availability; set `GOOGLE_CLOUD_LOCATION` to a regional endpoint for data residency, and always set it explicitly for region-specific partner (MaaS) models.\n\nFor CI, authenticate before the update job runs (for example with [`google-github-actions/auth`](https://github.com/google-github-actions/auth)) and set `OPENWIKI_PROVIDER=gemini-enterprise` and `GOOGLE_CLOUD_PROJECT` in the job environment.\n\n</details>\n\n<details>\n<summary><b>OpenAI (ChatGPT login)</b></summary>\n\n<br/>\n\nThe `openai-chatgpt` provider calls OpenAI's Codex backend using your ChatGPT subscription instead of a metered API key, drawing on your Plus/Pro/Team plan's included Codex usage. It serves the same model list as the `openai` provider.\n\n```bash\nOPENWIKI_PROVIDER=openai-chatgpt openwiki code --init\n# or\nOPENWIKI_PROVIDER=openai-chatgpt openwiki personal --init\n```\n\nThe wizard opens `https://auth.openai.com` in your browser (and prints the URL for headless/SSH use). After you sign in, OpenWiki captures the OAuth callback, shows the signed-in email and plan, and continues to model selection. It stores the access token, refresh token, expiry, account id, email, and plan in `~/.openwiki/.env`. These are managed for you and the access token is refreshed automatically, so you normally never edit them by hand. Treat the refresh token like a password.\n\n</details>\n\n<details>\n<summary><b>OpenAI-compatible endpoints (LiteLLM, Ollama, LM Studio, gateways)</b></summary>\n\n<br/>\n\nThe `openai-compatible` provider targets any OpenAI-compatible chat-completions endpoint via a required base URL. Set the model ID to whatever the endpoint exposes.\n\n```bash\n# Hosted gateway (for example Requesty, which fronts many upstream providers)\nOPENWIKI_PROVIDER=openai-compatible\nOPENAI_COMPATIBLE_API_KEY=your-gateway-key\nOPENAI_COMPATIBLE_BASE_URL=https://router.requesty.ai/v1\nOPENWIKI_MODEL_ID=openai/gpt-5.5\n```\n\n```bash\n# Ollama, after `ollama serve` and `ollama pull llama3.2`\nOPENWIKI_PROVIDER=openai-compatible\nOPENAI_COMPATIBLE_API_KEY=ollama\nOPENAI_COMPATIBLE_BASE_URL=http://localhost:11434/v1\nOPENWIKI_MODEL_ID=llama3.2\n```\n\n```bash\n# LM Studio, after starting the local server from the Developer tab\nOPENWIKI_PROVIDER=openai-compatible\nOPENAI_COMPATIBLE_API_KEY=lm-studio\nOPENAI_COMPATIBLE_BASE_URL=http://localhost:1234/v1\nOPENWIKI_MODEL_ID=your-loaded-model-id\n```\n\nSome local servers ignore the API key value, but OpenWiki still requires `OPENAI_COMPATIBLE_API_KEY` because the client expects one.\n\n</details>\n\n<details>\n<summary><b>Alternative base URLs, OpenRouter pinning, and retries</b></summary>\n\n<br/>\n\n**Alternative base URLs.** Route a provider at a self-hosted or proxied gateway by setting its base URL alongside its key: `ANTHROPIC_BASE_URL`, `OPENAI_BASE_URL`, `BASETEN_BASE_URL`, `FIREWORKS_BASE_URL`, `NVIDIA_BASE_URL`, or `COPILOT_BASE_URL`. The `openai` provider routes tool calls through the Responses API (`/v1/responses`), which is useful for gateways that expose it.\n\n```bash\nOPENWIKI_PROVIDER=anthropic\nANTHROPIC_API_KEY=your-key\nANTHROPIC_BASE_URL=https://your-gateway.example.com/anthropic\n```\n\n**OpenRouter provider pinning.** When OpenRouter serves a model through multiple upstreams, restrict routing with a provider or comma-separated allowlist:\n\n```bash\nOPENWIKI_PROVIDER=openrouter\nOPENROUTER_API_KEY=your-key\nOPENWIKI_OPENROUTER_PROVIDER_ONLY=Novita\n```\n\n**OpenRouter output-token cap.** By default no `max_tokens` is sent, so OpenRouter's credit pre-check budgets for the model's full advertised output ceiling — on a low credit balance every request can fail with a 402 error. Cap the per-request output explicitly with:\n\n```bash\nOPENWIKI_OPENROUTER_MAX_TOKENS=8192\n```\n\nA cap trades those hard 402 failures for possible truncation when a long wiki generation genuinely needs more output tokens, so prefer the largest value your balance allows.\n\n**Retry attempts.** OpenWiki uses LangChain's retry handling for transient provider errors. Override the retry count (default 3) with `OPENWIKI_PROVIDER_RETRY_ATTEMPTS=3` (a positive integer).\n\n</details>\n\n> [!NOTE]\n> If there is an inference provider or model you would like to see added, please open a PR.\n\n## Ignoring paths\n\nCreate a `.openwikiignore` file in the repository root to keep generated docs from reading or describing private, generated, or irrelevant paths. The syntax supports comments, blank lines, `*` and `**` globs, directory rules, and `!` negation:\n\n```gitignore\nsecrets/\n*.log\n!logs/keep.log\n```\n\nWhen `.openwikiignore` has active rules, OpenWiki filters filesystem discovery and restricts shell execute so ignored paths stay out of the run. This is a read boundary: ignored paths are never read, scanned, or reproduced in the docs. It does not guarantee a topic is never mentioned, since the agent may still infer an ignored area from other allowed evidence such as tests, the README, or commit messages.\n\n## Command reference\n\n```sh\nopenwiki                         # interactive chat, code mode, current repo\nopenwiki personal                # interactive chat, personal brain\nopenwiki \"generate docs\"         # start with an initial request\nopenwiki -p \"what can you do?\"   # one-shot, print, and exit\nopenwiki --init                  # initialize code docs (personal: openwiki personal --init)\nopenwiki --update                # update code docs (personal: openwiki personal --update)\nopenwiki visualize               # interactive graph + live reader\nopenwiki auth <provider>         # authenticate a connector (slack, gmail, x, notion)\nopenwiki ingest <source>         # run connector ingestion (all, or a connector/instance)\nopenwiki search <query>          # deterministic unified Markdown knowledge search\nopenwiki --help                  # full help\n```\n\n`openwiki search` searches the generated personal wiki plus configured Markdown roots. Use `--json` for HwjCode or other agents, and `--root PATH` for an external knowledge repository such as agent-lessons:\n\n```sh\n# Run from the hwj-wiki checkout, with agent-lessons beside it.\nOPENWIKI_AGENT_LESSONS_ROOT=\"$(cd ../agent-lessons && pwd -P)\" \\\nopenwiki search \"gateway archive\" --json --limit 10\n```\n\nThe search path is read-only and does not invoke a model. It skips connector `raw/` and private compiler-input directories, bounds file size, and redacts secret-like values from snippets.\n\nIn chat, `/api-key` updates the current provider key and `/langsmith-key` updates or clears LangSmith tracing credentials, both with masked prompts.\n\n## Telemetry\n\nOpenWiki collects anonymous, aggregate usage data to understand how the tool is used and improve it. Telemetry is on by default and easy to turn off.\n\n**Collected** on a single `openwiki_run` event, keyed by a random install ID in `~/.openwiki/install-id`: the command (init / update), the outcome (success / failure / no-op) with a coarse error category on failure (never the message), and at setup only, the brain mode, model provider, and configured connector names.\n\n**Never collected:** file contents, repository data or names, credentials, prompts, model output, connector payloads, error messages, file paths, URLs, model IDs, run duration, or your IP address. Interactive chat, `auth`, and `ingest` are not recorded. Scheduled/CI runs are tagged as anonymous reliability data under a shared CI identifier and never counted as installs.\n\nOpt out with either environment variable, or add the first line to `~/.openwiki/.env` to disable permanently:\n\n```sh\nexport OPENWIKI_TELEMETRY_DISABLED=1\nexport DO_NOT_TRACK=1   # cross-tool standard\n```\n\nTo see exactly what a run would send, add `--telemetry-file=<path>` to any run.\n\n## Contributing\n\nContributions are welcome. Please read [CONTRIBUTING.md](./CONTRIBUTING.md) before opening a PR. We intentionally keep PRs tightly scoped to one change each, and PRs that bundle unrelated changes may be closed with a request to split them.\n\n## License\n\n[MIT](./LICENSE)\n",
  "bytes": 29107,
  "sha": "57ad3f2e8673008d78037fa87f6a7e7386f7c5ec625657229396918f07c087f9",
  "repo_slug": "hwj123hwj/hwj-wiki",
  "fonte": "repo",
  "truncated": false,
  "api": "https://agentalog.com/api/listings/okf_hwj123hwj_hwj_wiki_openwiki_index_md_30ed2ef2/readme"
}