feat(wiki): add local authoring workflow

- add the docs/wiki submodule, local MkDocs build scripts, and a GitHub Pages workflow for wiki publishing
- add cargo wiki commands through xtask and document the local wiki lint/build flow in the README files
- add the CRIEW wiki authoring skill and record the rewritten wiki home page commit in the submodule pointer

Signed-off-by: Chen Miao <chenmiao.ku@gmail.com>

Author: ChenMiaoi

.cargo/config.toml

@@ -0,0 +1,2 @@
+[alias]
+wiki = "run --quiet -p xtask --"

.codex/skills/criew-wiki-authoring/SKILL.md

@@ -0,0 +1,81 @@
+---
+name: criew-wiki-authoring
+description: Write and revise pages under `docs/wiki` for the CRIEW GitHub wiki and its MkDocs-backed GitHub Pages site. Use when Codex needs to create, expand, reorganize, or review CRIEW wiki pages such as `Home.md`, `_Sidebar.md`, `_Footer.md`, or topic pages, and when the output or workflow must follow GitHub wiki conventions, the local MkDocs pipeline, and a pragmatic, kernel-documentation writing style.
+---
+
+# Criew Wiki Authoring
+
+## Overview
+
+Write CRIEW wiki pages as maintainer documentation.
+Treat `docs/wiki/` as the source GitHub wiki repository, and treat the published website as a derived MkDocs build driven from the main `CRIEW` repository.
+Keep the source compatible with both GitHub wiki rendering and the local Pages build pipeline, and prefer a direct, technical style over narrative or marketing copy.
+
+## Follow This Workflow
+
+1. Confirm the source of truth before writing.
+- Read the code, README, spec, config example, or architecture note that defines the behavior.
+- Prefer `README.md`, `README-zh.md`, `docs/architecture/design.md`, `docs/specs/`, and `docs/reference/config.example.toml` depending on the topic.
+- Do not invent commands, defaults, limitations, or workflows.
+
+2. Check the wiki context.
+- List the existing pages in `docs/wiki/` before creating or renaming a page.
+- Treat `docs/wiki/` as a separate Git repository. Use `git -C docs/wiki ...` when checking history or status.
+- Read `references/publish-workflow.md` before changing local preview, staging, or deployment behavior.
+- Keep `Home.md` as the landing page and update it when a new top-level page changes how readers enter the wiki.
+- Read `references/style-guide.md` for page rules.
+- Read `references/page-patterns.md` when choosing a page shape.
+
+3. Choose the smallest page that fits the job.
+- Use a short reference page for stable facts and concepts.
+- Use a workflow page for operator tasks with prerequisites and ordered steps.
+- Use a troubleshooting page for symptoms, likely causes, and recovery actions.
+- Split a page once it starts carrying more than one primary purpose.
+
+4. Draft in GitHub wiki form.
+- Use page names and filenames that are stable, literal, and easy to scan.
+- Prefer normal Markdown links such as `[Configuration](Configuration.md)` because they work in both GitHub wiki and MkDocs.
+- Treat `[[Page Name]]` and `[[Page Name|Link text]]` as compatibility syntax only. The local staging script rewrites them for MkDocs, but new content should not depend on that rewrite when a Markdown link is clear enough.
+- Use full GitHub URLs when linking from the wiki back into the main CRIEW repository, because the wiki is a separate repository.
+- Add `_Sidebar.md` or `_Footer.md` only when shared navigation or repeated context is materially useful.
+
+5. Check the publish path before finishing.
+- Local copy lint goes through `./scripts/wiki-lint.sh`.
+- Local preview and local build go through `./scripts/wiki-site.sh serve` and `./scripts/wiki-site.sh build`.
+- The staging step copies `docs/wiki/` into `target/wiki-docs/`, turns `Home.md` into the MkDocs `index.md`, excludes special wiki-only files such as `_Sidebar.md` and `_Footer.md`, and normalizes source-only links.
+- The published website is built from `mkdocs.yml` and deployed by `.github/workflows/wiki-pages.yml`.
+- The lint script requires `autocorrect`. If it is missing, the script downloads a local copy into `target/wiki-venv/bin/` and then reruns the check.
+- Treat a clean `./scripts/wiki-lint.sh` result as part of done for every wiki page this skill creates or edits.
+- Because `docs/wiki` is a submodule, the main repository deploys the pinned wiki commit, not the remote wiki repository's latest HEAD. A new wiki commit reaches GitHub Pages only after the CRIEW repository updates the `docs/wiki` submodule pointer.
+
+6. Draft in kernel-documentation style.
+- Lead with scope and purpose.
+- Prefer active voice, short sentences, and concrete nouns.
+- State prerequisites, constraints, and side effects before optional detail.
+- Prefer commands, paths, config keys, and observable outcomes over abstract explanation.
+- Avoid filler, advocacy, roadmap prose, and vague adjectives such as `simple`, `easy`, `powerful`, or `seamless`.
+- Name conditions directly when behavior depends on mode, configuration, or state.
+
+7. Review before finishing.
+- Verify commands, file paths, environment variables, config keys, and feature names against the repository.
+- Keep language consistent within the page. Match the page's existing language unless the user requests a change.
+- Check that headings are informative, examples are minimal, and links resolve to the intended wiki page or repository URL.
+- Run `./scripts/wiki-lint.sh` for every text change and revise the page until it passes. If the environment prevents the check, report that explicitly instead of assuming the page is clean.
+- When page structure or links changed, run `./scripts/wiki-site.sh build` if the environment allows it.
+
+## Apply These Page Rules
+
+- Start each page with a short paragraph that states what the page covers and when to use it.
+- Prefer headings such as `Prerequisites`, `Workflow`, `Configuration`, `Troubleshooting`, `Limitations`, and `See also` when they fit the content.
+- Keep heading depth shallow unless the page genuinely needs more structure.
+- Keep lists parallel and action-oriented.
+- Use fenced code blocks for commands, config fragments, and sample output.
+- Keep examples minimal but real.
+- Write copy that passes `autocorrect`; treat lint failures as defects that need wording changes before the page is considered complete.
+- Preserve CRIEW naming: use `CRIEW` for the project and `criew` for the binary, crate, config file, runtime directory, and environment variables.
+
+## Use The References
+
+- `references/style-guide.md`: GitHub wiki constraints, linking rules, and writing expectations.
+- `references/page-patterns.md`: Reusable page skeletons for `Home.md`, workflow pages, reference pages, and troubleshooting pages.
+- `references/publish-workflow.md`: The `docs/wiki -> MkDocs -> GitHub Pages` pipeline, local preview commands, and submodule publication constraints.

.codex/skills/criew-wiki-authoring/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "CRIEW Wiki"
+  short_description: "CRIEW GitHub wiki authoring guide"
+  default_prompt: "Use $criew-wiki-authoring to draft or revise pages under docs/wiki in the CRIEW GitHub wiki style."

.codex/skills/criew-wiki-authoring/references/page-patterns.md

@@ -0,0 +1,122 @@
+# CRIEW Wiki Page Patterns
+
+## Home Page
+
+Use this when editing `Home.md`.
+
+```md
+# CRIEW Wiki
+
+Briefly state what the wiki covers and who should read it.
+
+## Start here
+
+- [Install and setup](Install-and-Setup.md)
+- [Configuration](Configuration.md)
+- [Patch workflow](Patch-Workflow.md)
+- [Troubleshooting](Troubleshooting.md)
+
+## Topic map
+
+### User workflows
+
+- [Sync mail](Sync-Mail.md)
+- [Review and reply](Review-and-Reply.md)
+- [Apply patches](Apply-Patches.md)
+
+### Reference
+
+- [Configuration reference](Configuration-Reference.md)
+- [Key concepts](Key-Concepts.md)
+
+### Development
+
+- [CRIEW repository](https://github.com/ChenMiaoi/CRIEW)
+- [Contributor notes](Contributor-Notes.md)
+```
+
+## Workflow Page
+
+Use this for task-oriented pages.
+
+```md
+# Page Title
+
+State the task, operator, and expected outcome.
+
+## Prerequisites
+
+- Required environment, files, or state.
+
+## Workflow
+
+1. Run the first command or enter the first screen.
+2. Describe the expected result.
+3. Continue with the next observable step.
+
+## Verify the result
+
+- State what success looks like.
+
+## Troubleshooting
+
+- Common failure mode and the next action.
+
+## See also
+
+- [Related page](Related-Page.md)
+```
+
+## Reference Page
+
+Use this for concepts, settings, or stable behavior.
+
+```md
+# Page Title
+
+State the scope and the object being described.
+
+## Overview
+
+Brief definition or behavioral summary.
+
+## Fields or options
+
+- `key_name`: State meaning, accepted values, and important default behavior.
+
+## Constraints
+
+- State limits, invariants, or caveats.
+
+## Related behavior
+
+- Explain how this topic affects adjacent workflows.
+```
+
+## Troubleshooting Page
+
+Use this for failure-driven guidance.
+
+```md
+# Page Title
+
+State the symptom or failure class this page covers.
+
+## Symptoms
+
+- Observable error, UI state, or command output.
+
+## Likely causes
+
+- Most common cause first.
+
+## Recovery steps
+
+1. Verify the suspected cause.
+2. Apply the fix.
+3. Confirm recovery.
+
+## Escalation
+
+- State when the user should stop and inspect code, logs, or configuration in more detail.
+```

.codex/skills/criew-wiki-authoring/references/publish-workflow.md

@@ -0,0 +1,39 @@
+# CRIEW Wiki Publish Workflow
+
+## Pipeline
+
+The publication path is:
+
+`docs/wiki` source repo -> `scripts/prepare-wiki-site.py` staging -> `mkdocs.yml` build -> `.github/workflows/wiki-pages.yml` deploy -> GitHub Pages
+
+This means the source of truth stays in the GitHub wiki repository, while the published website is generated from the main `CRIEW` repository.
+
+## Local Commands
+
+- `./scripts/wiki-lint.sh`: Check wiki copy with `autocorrect`. If the command is missing, the script downloads a local copy into `target/wiki-venv/bin/`.
+- `./scripts/wiki-site.sh prepare`: Stage the wiki into `target/wiki-docs` without installing MkDocs.
+- `./scripts/wiki-site.sh serve`: Stage the wiki, install MkDocs into `target/wiki-venv`, and start a local preview server on `0.0.0.0:8000` by default. Override the bind address with `CRIEW_WIKI_DEV_ADDR`.
+- `./scripts/wiki-site.sh build`: Stage the wiki, install MkDocs into `target/wiki-venv`, and build `target/wiki-site`.
+
+Treat `./scripts/wiki-lint.sh` as mandatory for wiki content changes.
+Do not consider a new or edited wiki page complete until the copy passes the lint check, unless the environment prevents running the command and that limitation is reported.
+
+## What The Staging Step Does
+
+- Copy published wiki content from `docs/wiki/` into `target/wiki-docs/`.
+- Rewrite `Home.md` into the MkDocs landing page `index.md`.
+- Skip GitHub wiki helper files such as `_Sidebar.md` and `_Footer.md`.
+- Rewrite legacy `[[Page]]` wiki links into Markdown links that MkDocs can resolve.
+
+## CI And Deployment
+
+- `.github/workflows/wiki-pages.yml` runs `./scripts/wiki-lint.sh` before it builds the site on pull requests that touch the wiki publish pipeline.
+- The same workflow deploys to GitHub Pages on pushes to `develop`.
+- The workflow uploads the rendered site from `target/wiki-site`.
+- This CI step is the enforcement point for the same copy rules that the skill expects locally. Write pages to pass the lint check before handing the change off.
+
+## Submodule Constraint
+
+`docs/wiki` is a Git submodule in the main repository.
+That means the GitHub Pages deployment uses the wiki commit pinned by the main `CRIEW` repository.
+If the standalone wiki repository advances but the main repository does not update the `docs/wiki` gitlink, GitHub Pages will keep publishing the older pinned wiki snapshot.

.codex/skills/criew-wiki-authoring/references/style-guide.md

@@ -0,0 +1,55 @@
+# CRIEW Wiki Style Guide
+
+## GitHub Wiki Constraints
+
+- Treat `docs/wiki/` as the source wiki repository, not as a normal docs folder inside the main repo.
+- Treat the published website as a derived MkDocs build from the main `CRIEW` repository.
+- Keep `Home.md` as the landing page.
+- Use `_Sidebar.md` for shared navigation only when the page set is large enough to justify it.
+- Use `_Footer.md` only for short, repeated context such as related links or maintenance notes.
+- Prefer Markdown pages unless the existing page already uses another supported markup.
+- Avoid syntax that GitHub wikis do not support well, such as definition lists, table-of-contents directives, transclusion, or heavy indentation tricks.
+
+## Page Naming
+
+- Use stable, descriptive page names.
+- Keep filenames portable. Avoid characters that are awkward in URLs or file systems.
+- Match the filename to the page topic instead of using vague names such as `Notes` or `Misc`.
+- Rename pages only when the old name is clearly wrong or blocks navigation.
+
+## Linking Rules
+
+- Prefer standard Markdown links for internal page links, for example `[Configuration](Configuration.md)`.
+- Keep `[[Page Name]]` or `[[Page Name|Link text]]` only as compatibility syntax for older pages. `scripts/prepare-wiki-site.py` rewrites them during MkDocs staging.
+- Use normal Markdown links for external URLs.
+- Use full GitHub URLs when linking from the wiki to files, directories, issues, or pull requests in the main `CRIEW` repository.
+- Do not rely on repository-relative paths from the wiki back to the main repo. The wiki is a separate repository, so those links are easy to break.
+- Keep link text explicit. Prefer the destination's role over generic text such as `here` or `more`.
+
+## Writing Style
+
+- State what the page is for in the opening paragraph.
+- Prefer direct statements over explanation-first prose.
+- Put prerequisites before steps.
+- Put limitations and side effects near the action that triggers them.
+- Prefer one fact per sentence when the topic is operational.
+- Use active voice and imperative steps for procedures.
+- Avoid marketing tone, vision statements, and rhetorical fillers.
+- Avoid unexplained claims such as `fast`, `simple`, `robust`, or `advanced`.
+- Keep wording compatible with `autocorrect`. If lint flags a phrase, rewrite the sentence instead of suppressing the check.
+
+## Evidence And Accuracy
+
+- Verify commands, config keys, and paths against the current repository state.
+- Cite the real source in prose when the behavior comes from a spec, config example, or code path.
+- Call out assumptions explicitly if the repository does not prove them.
+- Prefer a small verified page over a broad speculative page.
+- Run `./scripts/wiki-lint.sh` after every copy edit and treat a clean result as required for completion. If the environment prevents the check, report that gap explicitly.
+
+## Page Maintenance
+
+- Update `Home.md` when a new page changes the top-level information architecture.
+- Merge or split pages when navigation starts to hide the main task flow.
+- Keep the lint path working: `./scripts/wiki-lint.sh` installs `autocorrect` on demand when the binary is missing.
+- Run `./scripts/wiki-site.sh build` after link or structure changes when the environment allows it.
+- Remove stale TODO text before finishing.

.github/workflows/wiki-pages.yml

@@ -0,0 +1,80 @@
+name: Wiki Pages
+
+on:
+  pull_request:
+    paths:
+      - .github/workflows/wiki-pages.yml
+      - .gitmodules
+      - docs/wiki
+      - docs/wiki-requirements.txt
+      - mkdocs.yml
+      - scripts/prepare-wiki-site.py
+      - scripts/wiki-lint.sh
+      - scripts/wiki-site.sh
+  push:
+    branches:
+      - develop
+    paths:
+      - .github/workflows/wiki-pages.yml
+      - .gitmodules
+      - docs/wiki
+      - docs/wiki-requirements.txt
+      - mkdocs.yml
+      - scripts/prepare-wiki-site.py
+      - scripts/wiki-lint.sh
+      - scripts/wiki-site.sh
+  workflow_dispatch:
+
+permissions:
+  contents: read
+
+concurrency:
+  group: wiki-pages
+  cancel-in-progress: true
+
+jobs:
+  build:
+    runs-on: ubuntu-latest
+
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v5
+        with:
+          fetch-depth: 0
+          submodules: recursive
+
+      - name: Setup Python
+        uses: actions/setup-python@v5
+        with:
+          python-version: '3.12'
+
+      - name: Configure GitHub Pages
+        uses: actions/configure-pages@v5
+
+      - name: Lint wiki copy
+        run: ./scripts/wiki-lint.sh
+
+      - name: Build wiki site
+        run: ./scripts/wiki-site.sh build
+
+      - name: Upload GitHub Pages artifact
+        uses: actions/upload-pages-artifact@v4
+        with:
+          path: target/wiki-site
+
+  deploy:
+    if: github.event_name == 'push' && github.ref == 'refs/heads/develop'
+    needs: build
+    runs-on: ubuntu-latest
+    permissions:
+      contents: read
+      pages: write
+      id-token: write
+    environment:
+      name: github-pages
+      url: ${{ steps.deployment.outputs.page_url }}
+
+    steps:
+      - name: Deploy to GitHub Pages
+        id: deployment
+        uses: actions/deploy-pages@v4

.gitmodules

@@ -1,3 +1,6 @@
 [submodule "vendor/b4"]
 	path = vendor/b4
 	url = https://github.com/mricon/b4.git
+[submodule "docs/wiki"]
+	path = docs/wiki
+	url = https://github.com/ChenMiaoi/CRIEW.wiki.git