Vime Code Review Preferences

Apply these lightweight review heuristics when changing vime code or documentation.

Preserve Ecosystem Project Descriptions

Treat ecosystem listings and third-party project introductions as curated content, including Ecosystem Built on slime in README.md and 基于 slime 构建的生态 in README_zh.md.

• Unless the user explicitly requests changes to this content, preserve project titles, emojis, wording, descriptive detail, links, ordering, and introductory/concluding prose.
• Release preparation, code refactors, general README cleanup, and preferences for brevity or consistent style do not authorize shortening, rewriting, standardizing, or reordering these sections.
• For an explicitly requested addition or correction, edit only the relevant entries and preserve unaffected descriptions in both language versions.

Prefer Direct APIs Over Thin Wrappers

• Remove helper layers that only rename a call, format one path, or forward arguments without owning meaningful behavior.
• Prefer calling the concrete reusable API directly, for example a *_to_path helper when the caller already knows the destination path.
• Keep a wrapper only if it owns a real boundary: compatibility, validation, nontrivial error policy, lifecycle management, metrics/logging semantics, async/retry behavior, or cross-module ownership.
• Avoid moving a redundant wrapper's body into another file just to preserve the wrapper shape. Inline the simple call at the natural ownership site.
• When removing a wrapper, search for sibling wrappers and nearby helpers with rg and delete confirmed dead functions in the same pass.
• Treat single-use convenience functions as suspicious when their only job is path formatting plus forwarding. Prefer the caller owning that one line.

Make Branches Explain Themselves

• Order conditionals by semantic precedence: special transport/lifecycle modes first, then explicit mode choices, then default paths.
• Prefer predicates that fully describe the branch, such as mode == "full" and transport == "disk", over a broad predicate followed by an assert that explains what the branch really meant.
• Use asserts as invariants for impossible states after validation, not as a substitute for clear branch conditions.

Keep Abstractions Honest

• Add an abstraction only when it removes real duplication, hides fragile mechanics, or clarifies ownership.
• When a review comment points out repeated indirection, look for a smaller public surface rather than adding another alias.
• Preserve existing behavior intentionally. If cleanup changes error handling, logging, or failure visibility, call that out in the final response.

Keep Runtime State Out of Args

• Treat args as configuration. Do not add ad hoc args._xxx attributes to pass actor handles, caches, recovery progress, current versions, or other runtime state between components. Renaming these to public attributes does not fix the ownership problem.
• Put live state on the component that owns its lifecycle. Pass dependencies explicitly, and use typed return values for startup plans or restoration results shared between components.
• Avoid replacing scattered temporary fields with a generic args.context bag. Keep each state object's responsibility and lifetime clear.
• Preserve existing custom hook signatures, call arguments, and return conventions when refactoring internal state. User implementations must not need new parameters merely to accommodate an internal cleanup.