Deterministic wiki

Repowise can produce its wiki two ways. The model-written wiki prompts an LLM per page. The deterministic wiki renders every page from the parsed AST, the dependency graph, and git history, with no model in the loop at all.

Both produce a complete wiki. The deterministic one costs nothing and needs no API key, which makes it the right first run on a codebase you have not indexed before.

How to get it

repowise init --yes                        # keyless: deterministic wiki
repowise init --yes --docs deterministic   # the same thing, spelled out
repowise init --index-only                 # the older spelling, identical

--docs deterministic and --index-only are the same switch. The first is named for what it produces, the second for what it skips. --docs llm asks for the model-written wiki and needs a key; passing --docs llm together with --index-only is a usage error and exits 2.

You also land here without asking, in three cases:

• No provider is resolvable (no key set, no --provider, nothing in config).
• You answer No at the cost gate. The index you already built is kept and the deterministic wiki is rendered on top of it.
• The cost gate has no terminal to ask on. When stdin is not a TTY it never prompts, it auto-declines, which is what makes repowise init --yes safe to run from a script or an agent.

What it renders

Nearly the whole page set a model-written run produces:

The pages are honest about where they came from. Each one ends with a footer saying it was derived from structure, and the repo overview describes composition, entry points, clusters, and dependencies rather than what the project does end to end, because no template can derive intent from an AST.

What it costs

Nothing. No API key, no tokens, no outbound network calls on the generation pass. It is the same local computation that produces the graph, git, health, and dead-code layers, applied to page rendering.

What it lacks

Two things, and they are worth being clear about:

Model-written prose. A template can say that PaymentProcessor is called by six modules, sits in the checkout cluster, and has been bug-fixed four times this quarter. It cannot say why retries were made idempotent. That paragraph is what the model pass buys you.

Semantic search, until you configure an embedder. Full-text and symbol search work on a deterministic index. Concept search and the RAG behind get_answer need embeddings, and the embedder defaults to mock when no key is detected. The embedder is separate from the LLM provider, so you can add semantic search without ever generating a page with a model. See Environment variables.

Everything else, the dependency graph, git signals, hotspots, ownership, bus factor, code health, dead code, change risk, decision archaeology, and the MCP tools built on them, is identical either way. None of it was ever a model product.

Upgrading later

Both upgrades work in place on the index you already have. Neither re-indexes from scratch.

A slice at a time, with repowise generate:

repowise generate --path src/api        # one directory
repowise generate --coverage 20         # the most important 20% of pages
repowise generate --unwritten           # every page still a template

The whole wiki at once, with repowise update --full:

repowise update --full --provider anthropic

Semantic search, once an embedder is configured, with repowise reindex. That embeds the pages you have. No LLM calls, no page regeneration.

In the dashboard, the Docs view on a deterministic repo offers the generation job directly rather than showing you an empty page.

Related

• Auto-generated wiki, the model-written pass
• Quickstart, the keyless first run
• Indexing commands, init, update, generate