chapar-commit

name	chapar-commit
description	Prepare Chapar commits and pushes with the project's commit-splitting and message policy. Use whenever the user asks to commit, push, split commits, or prepare a PR branch.

Chapar Commit Workflow

Use this playbook before any Chapar commit or push.

Required Inspection

git status --short
git diff --stat
git diff
git log --oneline -8 --decorate

If the branch is not what the user intended, stop and ask or switch only if explicitly requested.

Split Rules

Create separate commits for separate review contexts:

• docs/comment-only changes
• behavior/config changes
• CI workflow changes
• release tooling changes
• buildcache policy changes
• project-local pi/agent workflow changes

Do not mix documentation/comment-only changes with behavior/config/CI changes unless inseparable. If inseparable, explain why in the commit body.

Commit Message Style

Use a short subject plus a body that explains:

• root cause or motivation
• why this approach was chosen
• constraints preserved
• validation performed

Avoid messages that only restate the diff.

Example:

Add Rocky 10 hpcsim release support

The hpcsim environment now targets Rocky 9 and Rocky 10 with one Spack-built GCC 15 compiler stack. Keeping the package policy in one manifest avoids review drift across per-OS directories while release-time scopes continue to isolate stores and module trees by OS.

The site-local roots and shared cache paths are loaded from ignored envs/hpcsim/hpcsim-site.env so cluster-specific mount points do not leak into tracked config.

Validation: bash -n envs/hpcsim/release.sh; git diff --check ...

Push Policy

• Do not amend or rewrite pushed history unless the user explicitly asks.
• If a bad commit split is discovered after push, prefer a corrective commit over force-pushing main.
• Use [skip ci] only when intentionally avoiding push-triggered workflows.
• For feature/playbook work, prefer a branch and PR over direct main push.

Final Check

git status --short
git log --oneline -3