Software Configuration Management

Scheduling

Goal

Perform Git operations with explicit scope, traceable commits, and recoverable history.

Intent signature

• Commit, stage, push, branch, merge, rebase, resolve conflicts, manage worktrees, or inspect SCM governance.

When to use

• Commit and push requests, including Conventional Commit messages and logical splitting.
• Branch/history operations, releases, baselines, CODEOWNERS, and configuration-management reviews.

When NOT to use

• Implementing a feature or fixing application code -> use the owning specialist.
• General requirements planning -> use oma-pm; security/testing review -> use oma-qa.

Expected inputs

Requested Git operation, repository state, and effective scm settings from project configuration.

Expected outputs

Requested Git changes or an advisory plan, commit/branch identifiers, checks performed, and unresolved work.

Dependencies

Git CLI; project configuration and hooks. Read the references below only for the selected operation.

Structural Flow

Entry

Inspect branch, upstream, staged/unstaged changes, and existing authorization. Select the commit path below or the configuration-management resource for broader operations.

Transitions

• Commit-only request: finish after committing. Push or create a PR only when requested or required by the applicable workflow.
• Independent changes: split by feature. One logical change remains one commit even across code, tests, and docs; an explicit grouping instruction wins. File count is only a tiebreaker (at most five files lean single).
• Governance, worktrees, releases, or history operations: load resources/cm-operations.md.
• Large merges: load resources/merge-risk.md before selecting merge order or recovery steps.
• Default-branch push: apply the Push and PR safety section below.