Wiki

When you inherit an unfamiliar project, the slow part usually isn't writing code — it's working out what the project does, how the main flow runs, and how the modules fit together. The repository wiki has ZCode read through the codebase and turn that into a document you can consult whenever you need it.

It's an architecture guide to the codebase, not a product documentation site or a user manual. The catalog favors project identity, main execution paths, core modules and submodules, cross-process boundaries, data and state flow, configuration boundaries, extension points, and risk areas — rather than generic sections like "Installation" or "CI/CD". Every claim carries a source location you can click through to.

The wiki is generated and stored entirely locally, one per workspace.

Generating one

Open it from the Repo wiki icon next to the repo name at the top of the workspace file tree; it takes over the main work area. Before you've generated anything, a status card in the middle offers four settings:

Once you hit Generate wiki, the status bar walks through analyzing the codebase → generating the catalog → generating pages → saving.

You can start reading as soon as the catalog appears: finished pages open immediately, and pages still in the queue show a waiting state in the catalog. You can Stop at any point — pages already generated are kept, and the toolbar still offers regenerate and delete, so you're never stuck with a half-built wiki you can't read or continue. If any pages ultimately fail, the catalog shows how many.

Reading it

The view has two columns: open projects on the left, expanding into each project's catalog tree, and the page content on the right. The divider is draggable, the project list collapses entirely, and a narrow window or panel switches the layout to stacked.

The repo name sits at the top, and expanding Metadata below it reveals the branch, language, last updated time, commit ID, and page count — enough to confirm which version of the code this wiki reflects.

Each claim in the page body is annotated with a source location: a file path and line range that jumps straight to that file and line in your workspace. Mermaid diagrams follow the app theme and support zoom and full-size preview; a diagram that fails to render never blocks the rest of the page.

Keeping it current

You don't have to remember to update it. At the end of each turn, if the repo already has a wiki, ZCode checks whether the code actually changed — and only refreshes when it did.

To redo it yourself, use Regenerate in the toolbar. It reuses the model from last time by default, and you can switch models just for that run.

Delete wiki only clears the local content; you can regenerate at any point.

What it reads

Generation only reads files inside the current workspace, through a wiki-specific reading view that's independent of how other features scan files. The following never reach the model:

• The .git directory, build output, caches, and local runtime files
• Anything ignored by the root .gitignore
• Files whose names suggest secrets — containing token, secret, credential, or password (ordinary source files like tokenService.ts are not affected)
• Symlinks pointing outside the workspace

The model isn't handed a prepared list of files. It navigates the directory tree and reads what it needs, always within the boundaries above.

Limits

• Only one generation task can run per repository at a time.
• A repository keeps one language version. Regenerating in another language replaces the existing one; Chinese and English can't coexist.
• Individual pages can't be regenerated on their own, and no version history is kept.

Next steps