> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://cla-demo.postmansolutions.com/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://cla-demo.postmansolutions.com/_mcp/server.

# Development Process

---

\### Branching Strategy

* Begin all local development by pulling the latest `MAIN` branch.
* Create a new branch from `main` using a naming convention that reflects the purpose of the branch, prefixed with initials for easy identification.  Our convention is in the PR template for the repos.  It is `<initials>_<short_description>_<story_number>`.  Example: `jck_add_pr_template_538104`.
* Keep branches short-lived, ideally merging them back into `main` within a few days.

\### Commit Guidelines

* Use structured commit messages prefixed with the relevant **User Story or Bug ID** to ensure automatic linking in **Azure Boards** (e.g., `#12345 – Created custom class component for the text input to allow max length to be universally governed`).
* Keep commits small and focused to maintain a clear development history.

\### Syncing with `main`

* Before pushing changes to remote, ensure your branch is up to date with `main` by performing a rebase:

```base
  git pull --rebase origin main
```

* Resolve any merge conflicts locally, commit changes, rebase again, and then push changes.

---

\## Pull Request Best Practices

\### Creating a Pull Request

* Ensure your PR meets the following criteria before submission:
  * A **User Story or Bug** is linked to the PR (tracked in Azure Boards).
  * A screenshot of any UI changes is attached.
  * PR title follows the format: `[Team Name] | [User Story #] | [User Story Title]`.
  * Solution builds and runs locally without errors.
  * Unit tests are created and meet code coverage requirements.
  * All unit tests pass.
  * Linting issues are resolved.
  * Latest `main` branch changes are merged, and conflicts are resolved.
  * Updates are documented in the **User Story** for QA handoff.
  * Changes have been demonstrated to the QA team.

\### Responsibilities of PR Authors

* Ensure PRs are **small, incremental**, and **mergeable** at all times.
* Actively seek reviews from peers and promptly address feedback.
* Follow up to ensure PRs are reviewed and merged in a timely manner.

---

\## Code Review Expectations

\### Reviewer Responsibilities

* Conduct thorough reviews of every change in the PR.
* Verify that changes align with the acceptance criteria of the linked **User Story or Bug**.
* Ensure all checklist items in the PR template are met.
* Use "nit" prefix for minor style-related suggestions to avoid derailing the PR.
* At their discretion, reviewers may pull and run the code locally for complex changes, but testing is primarily handled via build pipelines, automation tests, and QA validation.

---

\## Merging Criteria

* PRs should only be merged once all criteria are met and at least one approved review is obtained.
* Merge small, tested, and reviewed PRs frequently to avoid large, complex changes.
* Use **fast-forward merges** where possible to maintain a linear history.