Project Commit

Core Rule

Commit only when the user asks for a commit. If the working tree contains unrelated changes, unclear ownership, failing checks, missing version updates for code changes, or an ambiguous commit scope/message, stop and ask the user before staging or committing.

Pre-Commit Workflow

1. Read AGENTS.md.
2. Inspect the working tree:
   • Run git status --short.
   • Review relevant diffs before deciding scope.
   • Identify files changed by the current task versus unrelated existing changes.
3. Resolve ambiguity:
   • Ask the user which files to include if scope is unclear.
   • Ask before including unrelated changes.
   • Ask before committing when verification fails or cannot be run.
4. Check release metadata for code changes:
   • Read the current local date.
   • Read docs/版本策略.md and confirm the major/minor/patch decision follows its historical and upgrade rules.
   • Ensure these describe the same major, minor, patch, and release date:
     • package.json version: major.minor.patch+yyyymmdd. pnpm-lock.yaml is not a release-version sync point.
     • src/apis/httpInstance.ts export sbVersion: Vmajor.minor.patch.yyyymmdd.
     • Release heading in docs/更新日志.md: ## 版本【Vmajor.minor.patch.yyyymmdd】.
   • If code changed and metadata is missing or inconsistent, update it before committing.
   • Pure documentation-only changes do not require version updates unless the user requests them or the docs are user-visible release content.
5. Verify before commit:
   • Run pnpm run lint, pnpm run typecheck, and pnpm run build; do not commit if a gate fails unless the user explicitly approves committing a known-broken state. Existing lint warnings may remain as historical technical debt.
   • Unless the user explicitly requests it in the current task, do not run pnpm run dev, pnpm run preview, or another project server; do not open or control a browser; and do not use screenshots, recordings, or pixel comparison as pre-commit verification. UI visual acceptance is performed manually by the user.
6. Choose a Conventional Commits message:
   • Format: type: subject.
   • Common types: feat, fix, docs, style, refactor, perf, test, build, ci, chore.
   • Prefer a concise Chinese subject for this Chinese project; use English only when a technical term or ecosystem convention is clearer.
   • Examples: feat: 添加屏蔽词投稿入口, fix: 修复移动端搜索弹窗溢出, docs: 更新 agent 工作说明.
   • Use type!: or a BREAKING CHANGE: body only for breaking changes.
7. Stage only intended files.
8. Run git status --short again to confirm staged scope.
9. Create the commit.
10. Final response should include the commit message, checks run, and any files intentionally left uncommitted.

Stop Conditions

• No explicit user request to commit.
• Unrelated changed files cannot be separated confidently.
• Version metadata is inconsistent after a code change.
• A pnpm quality gate fails and the user has not approved committing anyway.
• Commit message type or scope is unclear and cannot be inferred from the diff.