[Release]: release up to v0.0.2

.cargo/config.toml

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

.codex/skills/criew-development/SKILL.md

@@ -0,0 +1,102 @@
+---
+name: criew-development
+description: Repository-specific workflow and coding rules for the CRIEW codebase. Use when modifying or reviewing CRIEW Rust code, TUI behavior, sync/IMAP/reply/patch workflows, migrations, tests, docs, or config, when code or workflow changes may require syncing `docs/wiki/`, and whenever the task must follow `docs/development/code-guildline.md` or `docs/development/code-guildline-cn.md`.
+---
+
+# Criew Development
+
+## Overview
+
+Follow the CRIEW repository's coding rules, architecture boundaries, and validation workflow.
+Read the repository docs first, then make focused changes that preserve the current mail, patch, and reply behavior.
+
+## Start With The Project Docs
+
+Read the relevant repository docs before editing code.
+
+- Read `docs/development/code-guildline.md` first for the canonical coding rules.
+- Read `docs/development/code-guildline-cn.md` when the user works in Chinese or explicitly asks for the Chinese guideline.
+- Read `README.md` or `README-zh.md` before changing user-visible behavior, install steps, naming, or operator workflow.
+- Read `docs/architecture/design.md` before changing architecture, module boundaries, sync flow, or data-model assumptions.
+- Read `docs/specs/reply-format-spec.md` before changing reply composition, quoting, headers, or send flow.
+- Read `docs/reference/config.example.toml` before changing config keys, defaults, or path semantics.
+
+Treat `docs/development/code-guildline.md` as the priority source when a local convention is unclear.
+Then follow tool-enforced rules and the existing style in the touched module.
+
+## Keep The CRIEW Boundaries
+
+Use the existing layer split unless the task explicitly asks for architectural rework.
+
+- Keep `src/app/` focused on use-case orchestration and CLI/TUI entry workflows.
+- Keep `src/domain/` focused on core models and business meaning.
+- Keep `src/infra/` focused on storage, config, IMAP, sendmail, `b4`, logging, and other external integrations.
+- Keep `src/ui/` focused on TUI state, rendering, input handling, and UI tests.
+- Keep database changes in `migrations/` and align schema changes with the Rust storage code in the same change.
+- Treat `vendor/b4/` as vendored third-party code; avoid editing it unless the task explicitly targets that dependency.
+
+Preserve the current naming set from the README:
+use `CRIEW` for the repository name and `criew` for the crate, CLI, config file, runtime directory, and environment variables.
+Do not reintroduce legacy Courier naming.
+
+## Apply The Coding Rules Directly
+
+Implement changes in the style required by `docs/development/code-guildline.md`.
+
+- Prefer descriptive, behavior-accurate names.
+- Encode units in names when the type system does not.
+- Use assertion-style names for booleans.
+- Keep one primary concept per file; split large files early.
+- Keep code readable from top to bottom, with high-level flow before helper detail.
+- Keep functions small and focused; reduce nesting with early returns.
+- Avoid ambiguous boolean arguments; prefer enums or small config structs.
+- Express invariants in types when practical.
+- Propagate fallible paths with `?`.
+- Keep visibility and lint suppression as narrow as possible.
+- Add `// SAFETY:` comments for every `unsafe` block and document `# Safety` on unsafe APIs.
+- Write comments only when they explain why, constraints, or design tradeoffs.
+
+## Use A Repository-Focused Workflow
+
+Follow this order unless the task is trivial.
+
+1. Locate the relevant module with `rg` and read the surrounding code before proposing changes.
+2. Confirm the user-visible behavior from the README or a spec doc when the change affects sync, reply, patch apply/export, config, or startup flow.
+3. Keep the change focused on one logical topic.
+4. Add or update regression tests when fixing a bug or changing observable behavior.
+5. Update docs when behavior, commands, config, or workflow changed, and explicitly decide whether `README.md`, `README-zh.md`, or `docs/wiki/` need updates.
+
+Prefer updating both `README.md` and `README-zh.md` when the change affects user-facing usage or setup.
+When operator workflow, troubleshooting guidance, configuration, or other stable user-facing behavior changed, review the relevant `docs/wiki/` pages and update them in the same task unless the user explicitly scopes wiki work out. Use `criew-wiki-authoring` for the wiki edit itself.
+Keep PR-sized changes focused and commit subjects aligned with the repository's Conventional Commit prefixes:
+`feat:`, `fix:`, `docs:`, `refactor:`, `test:`, `chore:`.
+When asked to create a commit in this repository, use `git commit -s`.
+The repository hook at `.githooks/commit-msg` and CI both validate the `Signed-off-by:` trailer.
+Simple commits may use only the subject line.
+For larger commits, add a body with bullet points that summarize the main changes.
+
+## Run The Required Validation
+
+Run the full repository validation set after non-trivial changes when the environment allows it.
+
+- Keep overall repository coverage at or above 70%.
+- Keep newly added code at or above 80% coverage.
+- Keep critical-component coverage at or above 85% for critical workflow code that the current change directly touches or materially expands. Treat sync, reply, patch, and other core user-facing workflow paths in scope as critical unless the task clearly falls outside those paths.
+- Do not add tests only to tick uncovered lines. Coverage work must defend a real behavior, regression, failure mode, or workflow contract that matters to users or operators.
+- Prefer behavior-driven regression tests over line-chasing. If a remaining gap is not worth a brittle or artificial test, leave it uncovered and report the tradeoff clearly.
+- Use `./scripts/check-coverage.sh` plus the generated summary report to verify the thresholds above, and review file-level or workflow-level reports for the in-scope critical components. Treat threshold regressions as incomplete work.
+
+- `cargo fmt --all -- --check`
+- `cargo clippy --all-targets --all-features -- -D warnings`
+- `cargo test --all-targets --all-features`
+- `./scripts/check-coverage.sh`
+
+If time or environment constraints prevent a command from running, report that clearly and avoid claiming full verification.
+
+## Pull The Right Context On Demand
+
+Load extra repository docs only when the task needs them.
+
+- Read `docs/milestones/mvp-milestones.md` and `docs/milestones/reply-mvp-milestones.md` for historical intent or rollout sequencing.
+- Read `docs/milestones/vim-mvp-milestones.md` and `docs/specs/code-preview-vim-prototype.md` for Vim-mode and code-preview behavior.
+- Read `src/ui/tui/tests.rs` before extending TUI behavior that already has test coverage.

.codex/skills/criew-development/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "CRIEW Development"
+  short_description: "CRIEW repo workflow, coding rules, and doc sync checks"
+  default_prompt: "Use $criew-development to make a focused CRIEW code or config change and assess required README/wiki updates."

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

@@ -0,0 +1,84 @@
+---
+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, when code or workflow changes require a wiki sync pass, 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.
+Use this skill not only for standalone wiki work, but also when a code or config change means the existing wiki may now be stale.
+
+## 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.
+- When paired with a code change, identify which existing wiki pages describe the changed behavior and either update them or explicitly confirm that no wiki page is affected.
+
+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.
+- If you commit inside `docs/wiki`, explicitly ask the user whether the main `CRIEW` repository should also commit the updated `docs/wiki` submodule pointer. Do not assume they want both commits automatically.
+
+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 wiki authoring and sync guide"
+  default_prompt: "Use $criew-wiki-authoring to draft, revise, or sync pages under docs/wiki after CRIEW behavior or workflow changes."

.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,43 @@
+# 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.
+
+When a wiki-only commit is created,
+the agent should not automatically create the matching main-repository commit.
+It should ask the user whether the current `CRIEW` repository also needs a commit that updates the pinned `docs/wiki` submodule pointer.