→ <link to ticket> - #<id> <title> → <link to ticket> - ... Migrations to run after merge: php artisan migrate php artisan db:seed --class=<seeder if any> Permission grants needed: <any role permission grants> Please review and merge to main when satisfied. After merge, kindly add a "Merged" comment and close this ticket. ``` Assignee on the PR-review ticket: **Ahmed Taha (id=11)** — he's the reviewer/merger, regardless of who wrote the code. Now open the GitHub PR itself: ```bash gh pr create --repo tahadeveloper/moon-erp \ --base main \ --head feature/<branch> \ --title "feat(<module>): <batch summary>" \ --body "$(cat <<'EOF' ## Summary <1-3 bullets — what this batch ships> ## Linked tickets - #<id> <one-line title> (closed: <link to ticket>) - #<id> <one-line title> (closed: <link to ticket>) - ... ## Files changed <count> files, +<lines>/-<lines>. ## Migration & seeders ```bash php artisan migrate php artisan db:seed --class=... ``` ## Permissions note <any role grants needed> ## Test plan - [x] <bullet per acceptance criterion> EOF )" ``` **Required in PR body:** - A `## Linked tickets` section with one bullet per ticket, each linking to the ticket on the support portal. - Each ticket bullet must show `(closed: <link>)` so Ahmed can verify the ticket discussion before approving. - A `## Test plan` section with one checkbox per acceptance criterion across all the linked tickets. ### Step E — After Ahmed merges the PR 1. Add a final comment on each **feature ticket**: `Merged in tahadeveloper/moon-erp#<PR>.` 2. Close the **PR-review ticket** (Ahmed usually does this himself when he merges, but verify and close it if he doesn't). 3. Local `prod` tree may still have the cherry-picked commits — they'll be replaced by the merged-to-main code on next auto-deploy. No action needed. --- ## 3. Frontend coupling Frontend lives on `hazemhamdytaha/moon-erp-angular` and is **not** part of Ahmed's review. Workflow: 1. Frontend changes go on a feature branch off `main`. 2. Push branch + open PR against your own `main`. 3. Merge yourself (no Ahmed review on frontend), but **link the backend PR in the frontend PR body** for the trail: ``` Backend: tahadeveloper/moon-erp#1 (merged) ``` --- ## 4. Local working tree vs canonical history The `/home/moonerpelbaset/moon_erp/` working tree on this server runs on the `prod` branch, which Ahmed's auto-deploy resets periodically. Anything cherry-picked locally for live testing **will be wiped** on the next deploy. **Rule:** Cherry-picks are temporary. The PR + merge to `main` is what actually persists. If the cherry-picks get wiped before the PR is merged, re-apply them with: ```bash cd /home/moonerpelbaset/moon_erp git cherry-pick <commit> <commit> php artisan route:clear && php artisan route:cache /scripts/restartsrv_apache_php_fpm ``` --- ## 5. Quick checklist (use before every backend PR) - [ ] Each backend change has a **feature ticket** on `https://moon-support.elbaset.com/...` **assigned to whoever will code it** (Hazem id=12 / Ahmed id=11) - [ ] Each commit message references the ticket ID in `[#N]` form - [ ] Each feature ticket has a comment with smoke-test output and is set to `resolved`/`closed` - [ ] GitHub PR body has `## Linked tickets` with bullets + links to each ticket - [ ] GitHub PR body has `## Test plan` checkboxes - [ ] GitHub PR body mentions migrations / seeders / permission grants that Ahmed needs to run after merge - [ ] **A separate "PR review" ticket exists on the support portal**, assigned to Ahmed, containing the PR link + bundled ticket list — this is Ahmed's entry point for the review - [ ] After merge: add `Merged in #<PR>` comment on each feature ticket + close the PR-review ticket --- ## 6. Example: completed PR #1 This is what "done right" looks like — pin it as the template: - **Tickets** (would have been created up-front, were created retroactively for this batch): - File result type — B1 - Culture & sensitivity — B2 - Histopathology — B3 - Histopath templates — B4 - **PR:** https://github.com/tahadeveloper/moon-erp/pull/1 - **Branch:** `feature/frontend-patches-new-result-types` → `main` - **Commits:** `b0bc33f04` (scaffolding) + `204fea0ad` (production-tested batch) - **Status:** merged to `main` Going forward, **tickets exist first**, then code, then PR

# Backend PR Workflow — Support Tickets ↔ GitHub PRs **Owner:** Hazem (FE) and Ahmed (BE) **Rule:** Every backend change must be traceable from a support ticket → code in PR → reviewable diff. Ahmed reviews the whole batch in one place, not piecemeal. --- ## 1. Why this workflow exists When Ahmed reviews backend code, he needs full context: - **What** changed (the diff in the PR) - **Why** it changed (the original ticket describing the problem / feature) - **How** it was tested (FE component, smoke test, screenshot) - **What's coupled** (FE work that depends on these endpoints, other tickets in the same batch) Without tickets attached to the PR, Ahmed has to re-discover the context from chat history or memory. With tickets attached, the PR is self-documenting. --- ## 2. Mandatory steps for every backend change ### Step A — Before starting backend work For each backend task, create a support ticket **first**: - **Workspace:** GT4 inc (ID:3) - **Project:** Moon-ERP (ID:12) - **Assignee = whoever will write the code.** - Hazem codes it → `assignee_id: 12` (Hazem Hamdy) - Ahmed codes it → `assignee_id: 11` (Ahmed Taha) - When Hazem codes BE himself, Ahmed only sees the **PR-review ticket** (Step D below) — he reviews, doesn't write. - **Description must include:** - Goal of the change (1-2 sentences) - Affected module (LIS, Accounting, HR, …) - Endpoints / models / migrations touched - Acceptance criteria (what FE expects to call, what response shape, error cases) - Linked FE work (which component / page consumes this) Save the ticket ID — you'll need it on the commit, in the PR, and in the close note. ### Step B — During backend implementation Local work happens on the `prod` working tree (so live testing on `moonui.elbaset.com` works), but the **canonical history** lives on a feature branch. 1. Make code changes locally (cherry-pick to `prod` for live testing if needed). 2. On `feature/` (off `main`), commit each ticket as a single commit: ``` feat(): [] ``` Example: ``` feat(lis): histopath subspecialty templates table + CRUD [#1701] ``` 3. Push the branch to `tahadeveloper/moon-erp`. ### Step C — After backend implementation lands locally 1. **Smoke-test the change** against the actual API: - `curl` the new endpoints - Use the FE component if it exists - Capture HTTP status + a snippet of the response 2. **Comment on the ticket** with the smoke-test evidence: ``` Tested locally. POST /api/lis/histopath-templates → 201 with body {…}. 17 seeded templates listed via GET → 200. Ready for review. ``` 3. **Close the ticket** with status `resolved` (or `closed` if Ahmed has already deployed the same code). ### Step D — Opening the PR When you have a batch of tickets ready (file/culture/histopath/templates was 4 tickets bundled into one PR), open one PR per logical batch: **Two artifacts are required at this step:** 1. **The GitHub PR** (the actual code diff Ahmed reviews) — see template below. 2. **A separate "PR review" ticket on the support portal** assigned to Ahmed. This is Ahmed's actionable to-do — he searches the portal, finds this one ticket, and from it he can jump to the GitHub PR and to every linked feature ticket. **This ticket is the entry point for the review — never assume Ahmed will hunt for the PR himself.** The PR-review ticket template (post in the support portal): ``` Title: Review PR # — Body: GitHub PR: https://github.com/tahadeveloper/moon-erp/pull/ Branch: feature/ → main This PR bundles the following feature tickets (all closed with smoke-test evidence): - # → <link to ticket> - #<id> <title> → <link to ticket> - ... Migrations to run after merge: php artisan migrate php artisan db:seed --class=<seeder if any> Permission grants needed: <any role permission grants> Please review and merge to main when satisfied. After merge, kindly add a "Merged" comment and close this ticket. ``` Assignee on the PR-review ticket: **Ahmed Taha (id=11)** — he's the reviewer/merger, regardless of who wrote the code. Now open the GitHub PR itself: ```bash gh pr create --repo tahadeveloper/moon-erp \ --base main \ --head feature/<branch> \ --title "feat(<module>): <batch summary>" \ --body "$(cat <<'EOF' ## Summary <1-3 bullets — what this batch ships> ## Linked tickets - #<id> <one-line title> (closed: <link to ticket>) - #<id> <one-line title> (closed: <link to ticket>) - ... ## Files changed <count> files, +<lines>/-<lines>. ## Migration & seeders ```bash php artisan migrate php artisan db:seed --class=... ``` ## Permissions note <any role grants needed> ## Test plan - [x] <bullet per acceptance criterion> EOF )" ``` **Required in PR body:** - A `## Linked tickets` section with one bullet per ticket, each linking to the ticket on the support portal. - Each ticket bullet must show `(closed: <link>)` so Ahmed can verify the ticket discussion before approving. - A `## Test plan` section with one checkbox per acceptance criterion across all the linked tickets. ### Step E — After Ahmed merges the PR 1. Add a final comment on each **feature ticket**: `Merged in tahadeveloper/moon-erp#<PR>.` 2. Close the **PR-review ticket** (Ahmed usually does this himself when he merges, but verify and close it if he doesn't). 3. Local `prod` tree may still have the cherry-picked commits — they'll be replaced by the merged-to-main code on next auto-deploy. No action needed. --- ## 3. Frontend coupling Frontend lives on `hazemhamdytaha/moon-erp-angular` and is **not** part of Ahmed's review. Workflow: 1. Frontend changes go on a feature branch off `main`. 2. Push branch + open PR against your own `main`. 3. Merge yourself (no Ahmed review on frontend), but **link the backend PR in the frontend PR body** for the trail: ``` Backend: tahadeveloper/moon-erp#1 (merged) ``` --- ## 4. Local working tree vs canonical history The `/home/moonerpelbaset/moon_erp/` working tree on this server runs on the `prod` branch, which Ahmed's auto-deploy resets periodically. Anything cherry-picked locally for live testing **will be wiped** on the next deploy. **Rule:** Cherry-picks are temporary. The PR + merge to `main` is what actually persists. If the cherry-picks get wiped before the PR is merged, re-apply them with: ```bash cd /home/moonerpelbaset/moon_erp git cherry-pick <commit> <commit> php artisan route:clear && php artisan route:cache /scripts/restartsrv_apache_php_fpm ``` --- ## 5. Quick checklist (use before every backend PR) - [ ] Each backend change has a **feature ticket** on `https://moon-support.elbaset.com/...` **assigned to whoever will code it** (Hazem id=12 / Ahmed id=11) - [ ] Each commit message references the ticket ID in `[#N]` form - [ ] Each feature ticket has a comment with smoke-test output and is set to `resolved`/`closed` - [ ] GitHub PR body has `## Linked tickets` with bullets + links to each ticket - [ ] GitHub PR body has `## Test plan` checkboxes - [ ] GitHub PR body mentions migrations / seeders / permission grants that Ahmed needs to run after merge - [ ] **A separate "PR review" ticket exists on the support portal**, assigned to Ahmed, containing the PR link + bundled ticket list — this is Ahmed's entry point for the review - [ ] After merge: add `Merged in #<PR>` comment on each feature ticket + close the PR-review ticket --- ## 6. Example: completed PR #1 This is what "done right" looks like — pin it as the template: - **Tickets** (would have been created up-front, were created retroactively for this batch): - File result type — B1 - Culture & sensitivity — B2 - Histopathology — B3 - Histopath templates — B4 - **PR:** https://github.com/tahadeveloper/moon-erp/pull/1 - **Branch:** `feature/frontend-patches-new-result-types` → `main` - **Commits:** `b0bc33f04` (scaffolding) + `204fea0ad` (production-tested batch) - **Status:** merged to `main` Going forward, **tickets exist first**, then code, then PR — not retroactively.