---
name: project-management
description: Use when managing the Anxinyan project at /Users/wushumin/www/biyou/anxinyan, especially Git branch workflow, collaboration rules, commits, pre-submit checks, GitNexus detect-changes, release branch handling, or deciding where project-management rules belong.
---

# 安心验项目管理规范

Project root: `/Users/wushumin/www/biyou/anxinyan`.

Use the outer repository as the single source of truth for all project work. Do not create separate Git branch systems inside `server-api`, `admin-web`, `user-app`, or `work-app`.

Do not manage release artifacts in Git. Files under `releases/` and `releases_dev/`, including zip packages, APKs, and checksum files, are local delivery artifacts and must not be committed or pushed. Put production packages in `releases/` and test packages in `releases_dev/`.

Local development and the test server share the test database connection. Store the real host, username, and password only in ignored `.env` files or server environment variables. The shared test database name is `test_anxinyan`; never commit real database passwords to docs, skills, examples, or Git-tracked templates.

## Branch Model

- `master`: stable, release-ready mainline. Do not do daily development directly here.
- `develop`: integration branch for normal multi-person development.
- `feature/<scope>-<name>`: feature or improvement branches created from `develop`.
- `release/<version-or-date>`: release stabilization branches created from `develop`.
- `hotfix/<name>`: urgent production fixes created from `master`.

After repository initialization, keep the local checkout on `develop` for daily work.

## Standard Workflows

For normal work:

1. Start from updated `develop`.
2. Create a `feature/<scope>-<name>` branch.
3. Commit focused changes with clear Conventional Commits messages.
4. Open a merge request back to `develop`.
5. Include changed surfaces, verification commands, and risk notes in the merge request.

For releases:

1. Create `release/<version-or-date>` from `develop`.
2. Keep the release branch limited to release blockers, verification fixes, and docs.
3. Merge the verified release branch to `master`.
4. Merge `master` back into `develop`.

For hotfixes:

1. Create `hotfix/<name>` from `master`.
2. Fix only the production issue.
3. Merge to `master` for release.
4. Merge `master` back into `develop`.

## Required Checks

Before committing, run:

```bash
git status -sb
git diff --check
npx gitnexus detect-changes --scope all --repo anxinyan
```

Before changing code symbols, follow the repository `AGENTS.md` GitNexus rule: run upstream impact analysis for the target symbol and report the blast radius. Before committing any change, run GitNexus detect changes.

Use GitNexus with the branch workflow:

- Before changing unfamiliar code, use GitNexus query/context to locate the relevant flow.
- Before editing any function, class, or method, run upstream impact analysis for that symbol.
- Before committing, run detect-changes against the current diff; this remains a required check even when hooks are enabled.
- After commits, merges, branch checkouts, and rewrites, local hooks refresh the index with `npx gitnexus analyze --index-only --name anxinyan .`.

Enable the versioned lightweight hooks once per clone:

```bash
git config core.hooksPath scripts/git-hooks
```

The hook refresh is best-effort and non-blocking. Disable it temporarily with `GITNEXUS_AUTO_REFRESH=0` if needed. Manual refresh is available with:

```bash
./scripts/gitnexus-refresh.sh
```

For release packaging or deployment preparation, also follow the release checklist and packaging skill. At minimum, run the relevant backend smoke/audit scripts and frontend checks for the surfaces touched.

Production packages should stay under the ignored local `releases/` directory and use `https://api.anxinjianyan.com`. Test packages should stay under the ignored local `releases_dev/` directory and use `https://test.api.anxinjianyan.com`. Hand off both kinds of artifacts separately from Git branches.

For backend local/test validation, confirm `server-api/.env` is ignored before using real database credentials:

```bash
git check-ignore -v server-api/.env
```

Before committing environment-related documentation, scan tracked docs and examples to ensure no real `DB_PASSWORD` value is present.

## Documentation Source

The human-readable branch workflow is documented in:

```text
docs/development/branch-workflow.md
```

Keep this skill and that document aligned when branch rules change.