siesa-agents 2.1.78 → 2.1.80

package/siesa-agents/bmm/workflows/4-implementation/code-review/steps/step-06-jira-sync.md

@@ -0,0 +1,372 @@
+---
+name: 'step-06-jira-sync'
+description: 'Full content sync with Jira via Node.js scripts (markdown = source of truth)'
+
+# Path Definitions
+workflow_path: '{project-root}/_siesa-agents/bmm/workflows/4-implementation/code-review'
+
+# File References
+thisStepFile: '{workflow_path}/steps/step-06-jira-sync.md'
+nextStepFile: '{workflow_path}/steps/step-07-commit-push.md'
+workflowFile: '{project-root}/_siesa-agents/bmm/workflows/4-implementation/code-review/workflow.md'
+outputFile: '{output_folder}/review-{story_key}.md'
+storyFile: '{{story_path}}'
+
+# Infrastructure References
+tokensFile: '{project-root}/.claude/commands/get-features/tokens.json'
+oauthConfigFile: '{project-root}/.claude/commands/get-features/oauth-config.json'
+jiraConfigFile: '{project-root}/_bmad-output/jira_docs/project_config.yaml'
+storyTemplate: '{project-root}/_siesa-agents/sa/sync-epics-stories/data/templates/story-template.json'
+taskTemplate: '{project-root}/_siesa-agents/sa/sync-epics-stories/data/templates/task-template.json'
+jiraScripts: '{project-root}/_siesa-agents/scripts/jira'
+---
+
+# Step 6: Jira Full Content Sync
+
+## STEP GOAL:
+
+To synchronize the "Done" status with Jira by performing a **full content upsert**. The markdown story file is the **source of truth**. Description, subtasks, and subtask comments must be consistent between the markdown and Jira.
+
+## MANDATORY EXECUTION RULES:
+
+- 🛑 ONLY execute if `{{new_status}} == 'done'` (as determined in step-05-sync-sprint)
+- 🔒 **NEVER use MCP tools** for any Jira operation. MCP is disabled for this workflow.
+- 🔒 **NEVER write inline Node.js** for Jira API calls. Always use the existing scripts.
+- 🤫 Silent execution — display only brief status lines, no menus or prompts.
+- ✅ Scripts auto-discover OAuth tokens from `.claude/commands/get-features/tokens.json`
+- ✅ Scripts auto-discover project config from `_bmad-output/jira_docs/project_config.yaml`
+
+## JIRA API INTEGRATION
+
+All Jira interactions MUST use the **pre-built CLI scripts** located at `{jiraScripts}/`. These scripts handle OAuth refresh, config loading, and API calls automatically.
+
+### Available Scripts (`_siesa-agents/scripts/jira/`)
+
+| Script | Purpose | Example |
+|---|---|---|
+| `search.js` | Search issues via JQL | `node search.js --jql "project = PJIB AND issuetype = Epic" --fields "summary,status"` |
+| `create-issue.js` | Create issue (Epic, Story, Sub-task) | `node create-issue.js --type Epic --summary "Epic 3" --parent PJIB-99` |
+| `batch-create.js` | Create multiple issues from JSON | `node batch-create.js --file issues.json` |
+| `add-comment.js` | Add comment (auto-converts to ADF) | `node add-comment.js --issue PJIB-190 --body "## Sub-tasks\n- Item 1"` |
+| `get-issue.js` | Get issue details | `node get-issue.js --issue PJIB-190 --fields "summary,status"` |
+| `edit-issue.js` | Update issue fields | `node edit-issue.js --issue PJIB-190 --summary "New title"` |
+| `transition.js` | Transition issue status | `node transition.js --issue PJIB-190 --to done` |
+| `refresh-token.js` | Force OAuth token refresh | `node refresh-token.js` |
+
+🛑 **CRITICAL:** If a step says "Using Node.js, call..." — use the corresponding script above. Do NOT create temporary `.js` files or write inline `node -e` commands.
+
+## Sequence of Instructions
+
+### A. Guard Check
+
+If `{{new_status}} != 'done'`:
+- Output: `ℹ️ Story status is '{{new_status}}'. Skipping Jira sync.`
+- Update frontmatter of `{outputFile}`: `stepsCompleted: [1, 2, 3, 4, 5, 6]`
+- Immediately load, read, and execute `{nextStepFile}` without any further action.
+
+### B. Load Jira Configuration (Silent)
+
+1. Check if `{jiraConfigFile}` exists.
+   - If NOT exists: Output `⚠️ No Jira config found (project_config.yaml). Skipping Jira sync.` then proceed to Section G (log) then load `{nextStepFile}`.
+   - If exists: Read and extract `project_key`, `cloud_id`, `jira_url`.
+
+2. Refresh OAuth access token using inline Node.js:
+   - Read `{tokensFile}` → extract `refresh_token`
+   - Read `{oauthConfigFile}` → extract `client_id`, `client_secret`
+   - `POST https://auth.atlassian.com/oauth/token` with `grant_type: refresh_token`
+   - Save new `access_token` (and `refresh_token` if returned) back to `{tokensFile}`
+   - If refresh fails: Output `⚠️ OAuth token refresh failed. Skipping Jira sync.` then proceed to Section G (log) then load `{nextStepFile}`.
+
+Output: `🔄 Syncing story content with Jira...`
+
+### C. Story Resolution — Resolve or Create Jira Issue (Silent)
+
+**Goal:** Ensure the story exists in Jira and `{{jira_key}}` is set.
+
+#### Story File Structure — Exact Heading Mapping
+
+The story markdown file follows this exact structure. Use these headings to extract each field:
+
+| Variable | Exact Markdown Heading | Content to Extract |
+|---|---|---|
+| `{{story_title}}` | H1: `# Story X.Y: <title>` | Full title text after `# ` |
+| `{{story_id}}` | H1: `# Story X.Y: ...` | Numeric ID only (e.g., `1.2`) |
+| `{{status}}` | Plain line below H1: `Status: <value>` | Status value (e.g., `done`) |
+| `{{user_story}}` | `## Story` | All content until next `##` heading |
+| `{{acceptance_criteria}}` | `## Acceptance Criteria` | All content until next `##` heading |
+| `{{tasks_section}}` | `## Tasks / Subtasks` | All content until next `##` heading |
+| `{{completion_notes}}` | `## Dev Agent Record` → `### Completion Notes List` | Content of that subsection only |
+| `{{technical_debt}}` | `## Dev Agent Record` → `### Technical Debt` | Content of that subsection only |
+| `{{jira_key}}` | `## Jira Information` → `**Jira Issue Key:** [KEY](url)` | Key pattern (e.g., `PJIB-427`) |
+
+**IMPORTANT:** `## Dev Notes` contains detailed implementation documentation (often 200–700 lines). Do NOT read this section unless explicitly instructed. It is NOT included in the Jira description — only a reference link is added.
+
+#### Extraction Steps
+
+1. Read `{{story_path}}`. Parse the H1 line to extract `{{story_title}}` and `{{story_id}}`.
+2. Check if the `## Jira Information` section contains a `**Jira Issue Key:**` entry matching the key pattern `[A-Z]+-\d+`.
+
+3. **If key found locally:**
+   - Set `{{jira_key}}` from the local entry.
+   - Output: `✅ Story already in Jira: {{jira_key}}`
+
+4. **If key NOT found locally:**
+
+   a. **Remote search** (Node.js):
+   ```
+   POST https://api.atlassian.com/ex/jira/{{cloud_id}}/rest/api/3/search/jql
+   Body: { "jql": "project = \"{{project_key}}\" AND issuetype in (Story, Historia) AND summary ~ \"{{story_title}}\"", "maxResults": 5, "fields": ["id", "key", "summary"] }
+   ```
+   - If found: set `{{jira_key}}` = found key. Proceed to step c.
+
+   b. **If not found remotely — Create Story** (Node.js):
+
+   Extract the following (using the heading mapping table above):
+   - `{{user_story}}` → content of `## Story` section
+   - `{{acceptance_criteria}}` → content of `## Acceptance Criteria` section
+   - `{{completion_notes}}` → content of `### Completion Notes List` subsection (if exists, else empty)
+   - `{{parent_epic_key}}` → from the referenced parent epic file in `{epicsFolder}` (look for `[KEY-123]` in the epic that matches the story's Epic reference)
+
+   If `{{parent_epic_key}}` not resolvable: Output `⚠️ Parent Epic not synced. Story creation may fail.` and continue.
+
+   Build payload using `{storyTemplate}`:
+   ```
+   POST https://api.atlassian.com/ex/jira/{{cloud_id}}/rest/api/3/issue
+   Body: (inject {{story_id}}, {{story_title}}, {{user_story}}, {{acceptance_criteria}}, {{completion_notes}} as dev_notes, {{story_path}} as file_path, {{parent_epic_key}})
+   ```
+   - On success: set `{{jira_key}}` = new key.
+   - On failure: Output `❌ Story creation failed: {{error}}. Skipping Jira sync.` → proceed to Section G (log) then load `{nextStepFile}`.
+
+   c. **Persist key to story file** (immediately, whether found remotely or just created):
+
+   Append to `{{story_path}}` (only if `## Jira Information` section does not already exist):
+   ```markdown
+
+   ## Jira Information
+
+   **Jira Issue Key:** [{{jira_key}}]({{jira_url}}/browse/{{jira_key}})
+   **Jira URL:** {{jira_url}}/browse/{{jira_key}}
+   **Status:** Synced
+   ```
+
+---
+
+### D. Description Sync — Markdown is Source of Truth (Silent)
+
+**Goal:** Update the story description in Jira to match the current markdown content. Keep it concise — Jira descriptions are for team visibility, not full technical docs.
+
+#### What to Include in the Jira Description
+
+| Section | Source Heading | Include? |
+|---|---|---|
+| User Story | `## Story` | ✅ Full content |
+| Acceptance Criteria | `## Acceptance Criteria` | ✅ Full content |
+| Completion Notes | `## Dev Agent Record → ### Completion Notes List` | ✅ If exists |
+| Technical Debt | `## Dev Agent Record → ### Technical Debt` | ✅ If exists |
+| Dev Notes | `## Dev Notes` | ❌ Reference link only (too large) |
+| Tasks / Subtasks | `## Tasks / Subtasks` | ❌ Handled separately as Sub-tasks |
+
+1. Extract from `{{story_path}}` using the headings above:
+   - `{{user_story}}` → full content of `## Story` section
+   - `{{acceptance_criteria}}` → full content of `## Acceptance Criteria` section
+   - `{{completion_notes}}` → content of `### Completion Notes List` (empty string if missing)
+   - `{{technical_debt}}` → content of `### Technical Debt` (empty string if missing)
+
+2. Build description payload in **Atlassian Document Format (ADF)**:
+
+   ```json
+   {
+     "type": "doc", "version": 1,
+     "content": [
+       { "type": "heading", "attrs": { "level": 2 }, "content": [{ "type": "text", "text": "User Story" }] },
+       { "type": "paragraph", "content": [{ "type": "text", "text": "{{user_story}}" }] },
+       { "type": "heading", "attrs": { "level": 2 }, "content": [{ "type": "text", "text": "Acceptance Criteria" }] },
+       { "type": "paragraph", "content": [{ "type": "text", "text": "{{acceptance_criteria}}" }] },
+       { "type": "heading", "attrs": { "level": 2 }, "content": [{ "type": "text", "text": "Completion Notes" }] },
+       { "type": "paragraph", "content": [{ "type": "text", "text": "{{completion_notes}}" }] },
+       { "type": "heading", "attrs": { "level": 2 }, "content": [{ "type": "text", "text": "Technical Debt" }] },
+       { "type": "paragraph", "content": [{ "type": "text", "text": "{{technical_debt}}" }] },
+       { "type": "rule" },
+       { "type": "paragraph", "content": [
+           { "type": "text", "text": "📄 Source: " },
+           { "type": "text", "text": "{{story_path}}", "marks": [{ "type": "code" }] }
+         ]
+       }
+     ]
+   }
+   ```
+
+   **Rules:**
+   - Omit the `Completion Notes` block entirely if `{{completion_notes}}` is empty.
+   - Omit the `Technical Debt` block entirely if `{{technical_debt}}` is empty.
+   - Always include the `Source:` footer line.
+
+3. Update description in Jira (Node.js):
+   ```
+   PUT https://api.atlassian.com/ex/jira/{{cloud_id}}/rest/api/3/issue/{{jira_key}}
+   Body: { "fields": { "description": {{adf_description_payload}} } }
+   ```
+   - On success: Output `✅ Description synced → {{jira_key}}`
+   - On failure: Output `⚠️ Description update failed: {{error}}` — log and continue (non-blocking).
+
+---
+
+### E. Subtask Upsert — Create Missing, Verify Comments (Silent)
+
+**Goal:** Every level-1 task in the markdown must exist as a Jira Sub-task. Every Sub-task with nested bullets must have its comment. The markdown `## Synced Tasks` table is the local idempotency record.
+
+**HIERARCHY MAPPING:**
+```
+Markdown                         Jira
+────────────────────────         ───────────────────────────
+Story                        →   Story (issue)
+  └─ Level-1 task bullet     →   Sub-task (child of Story)
+       └─ Nested bullet(s)   →   Comment on that Sub-task
+```
+
+**E.1 — Preparation:**
+
+1. GET story from Jira (Node.js):
+   ```
+   GET https://api.atlassian.com/ex/jira/{{cloud_id}}/rest/api/3/issue/{{jira_key}}?fields=subtasks
+   ```
+   - Extract `existingJiraSubtasks` = array of `{ key, summary }` from `fields.subtasks`.
+   - Build `existingJiraSummaries` = normalized set of subtask summary strings.
+
+2. Read `## Synced Tasks` table from `{{story_path}}` → build `syncedTaskNames` set (task names already tracked locally).
+
+3. Parse the `## Tasks / Subtasks` section from `{{story_path}}` (content until the next `##` heading):
+   - **Level-1 bullets**: lines starting with `- [ ]` or `- [x]` at base indentation (no leading spaces). Each is a `task`. Extract text after the checkbox — strip `**Task N:** ` prefix and `(AC: ...)` suffix if present.
+   - **Nested bullets**: lines indented under a level-1 bullet (2+ leading spaces). Each is a `nested_item` of that task. Strip checkbox syntax, keep text only.
+   - Preserve original task text for summary matching against Jira.
+
+**E.2 — Loop: For Each Level-1 Task:**
+
+🛑 **CRITICAL:** Steps A → D are one atomic unit per task. Do NOT batch creations and then add comments separately.
+
+#### A. Already in `## Synced Tasks` table?
+
+- **YES** → extract `{{subtask_key}}` from the table row.
+  - If this task has nested bullets:
+    - Check existing comments: `GET https://api.atlassian.com/ex/jira/{{cloud_id}}/rest/api/3/issue/{{subtask_key}}/comment`
+    - If no comment with heading "Sub-tasks" exists → create comment (Step C below).
+    - If comment already exists → Output: `⏭️ Comment already present: {{subtask_key}}` — skip.
+  - Move to next task.
+
+#### B. NOT in `## Synced Tasks` — Resolve from Jira or Create
+
+- Check if task summary (formatted as `{{story_id}} - {{task_name}}`) is in `existingJiraSummaries`:
+  - **YES (exists in Jira but not tracked locally):**
+    - Find the key from `existingJiraSubtasks`.
+    - Set `{{subtask_key}}` = found key.
+    - Output: `🔗 Subtask already in Jira (untracked): {{subtask_key}}`
+  - **NO (missing in Jira):**
+    - Create Sub-task (Node.js):
+      ```
+      POST https://api.atlassian.com/ex/jira/{{cloud_id}}/rest/api/3/issue
+      Body: { "fields": { "issuetype": { "name": "Sub-task" }, "project": { "key": "{{project_key}}" }, "parent": { "key": "{{jira_key}}" }, "summary": "{{story_id}} - {{task_name}}" } }
+      ```
+    - On success: set `{{subtask_key}}` = new key. Output: `✅ Subtask created: {{subtask_key}} — {{task_name}}`
+    - On failure: log `❌ Subtask creation failed: {{task_name}} — {{error}}`. Skip steps C and D. Move to next task.
+
+#### C. Add Nested Bullets as Comment (MANDATORY if nested bullets exist)
+
+🛑 This step is **NOT optional** if the task has nested bullets.
+
+- Collect all nested bullets under this task. Strip checkbox syntax — keep text only.
+- Build ADF comment body:
+  ```json
+  {
+    "body": {
+      "type": "doc", "version": 1,
+      "content": [
+        { "type": "heading", "attrs": { "level": 3 }, "content": [{ "type": "text", "text": "Sub-tasks" }] },
+        { "type": "bulletList", "content": [
+            { "type": "listItem", "content": [{ "type": "paragraph", "content": [{ "type": "text", "text": "{{nested_bullet_text}}" }] }] }
+          ]
+        }
+      ]
+    }
+  }
+  ```
+  Build one `listItem` node per nested bullet.
+
+- POST comment (Node.js):
+  ```
+  POST https://api.atlassian.com/ex/jira/{{cloud_id}}/rest/api/3/issue/{{subtask_key}}/comment
+  ```
+- On success: Output `✅ Comment added: {{subtask_key}}`
+- On failure: log `⚠️ Comment failed: {{subtask_key}} — {{error}}` — non-blocking, continue.
+
+#### D. Immediate File Persistence
+
+Append or update the `## Synced Tasks` table in `{{story_path}}` (create header if missing):
+
+```markdown
+| {{task_name}} | [{{subtask_key}}]({{jira_url}}/browse/{{subtask_key}}) | Synced | {{date}} |
+```
+
+**Then move to the next level-1 task and repeat from step A.**
+
+**E.3 — Summary Output:**
+
+```
+✅ Subtask sync complete:
+   Created:          X subtasks
+   Already in Jira:  Y subtasks (linked)
+   Comments added:   Z
+   Comments skipped: W (already existed)
+   Failed:           V (see log)
+```
+
+---
+
+### F. Transition Story and All Subtasks to Done (Node.js, Silent)
+
+After content sync is confirmed (has `{{jira_key}}`):
+
+1. **Transition Parent Story:**
+   - Node.js: `GET https://api.atlassian.com/ex/jira/{{cloud_id}}/rest/api/3/issue/{{jira_key}}/transitions`
+   - Find transition where `to.statusCategory.key == "done"` (or name contains "Done"/"Listo"/"Finalizada")
+   - Node.js: `POST .../transitions` body: `{ "transition": { "id": "{{found_id}}" } }`
+   - Output: `✅ {{jira_key}} → Done`
+
+2. **Cascade: Transition all Subtasks:**
+   - Node.js: `GET .../issue/{{jira_key}}?fields=subtasks` → extract all subtask keys (includes newly created ones)
+   - For each subtask:
+     - `GET .../issue/{{subtask_key}}/transitions` → find "done" transition id
+     - `POST .../issue/{{subtask_key}}/transitions` body: `{ "transition": { "id": "{{found_id}}" } }`
+   - If any subtask transition fails: log `⚠️ Subtask {{subtask_key}} transition failed: {{error}}` and continue.
+   - Output: `✅ Subtasks → Done`
+
+3. **Update Markdown Tables in Story File:**
+   - Read `{{story_path}}`
+   - In `## Jira Information`: add column `| Jira State |` with value `| **Done** |`
+   - In `## Synced Tasks`: add column `| Jira State |` with value `| **Done** |` for each row
+   - Save file.
+
+---
+
+### G. Append Result to Output File
+
+Append to `{outputFile}`:
+
+```markdown
+## Jira Sync (Full Content Sync — Markdown Source of Truth)
+- **Story**: {{story_title}}
+- **Jira Key**: {{jira_key}}
+- **Story Resolution**: [Created / Found remotely / Found locally]
+- **Description Sync**: [Updated ✅ / Failed ⚠️]
+- **Subtasks Created**: X
+- **Subtasks Linked**: Y (already in Jira)
+- **Comments Added**: Z
+- **Story Transition**: Done ✅
+- **Subtasks Transitioned**: [N subtasks → Done ✅ / Failed: list]
+- **Infrastructure**: Node.js direct API (OAuth shared with get-features)
+```
+
+Update frontmatter of `{outputFile}`: `stepsCompleted: [1, 2, 3, 4, 5, 6]`
+
+Output: `✅ Jira sync complete. Proceeding to commit...`
+
+Then **immediately load, read, and execute `{nextStepFile}`** — no menu, no waiting for user input.

package/siesa-agents/bmm/workflows/4-implementation/code-review/steps/step-07-commit-push.md

@@ -0,0 +1,174 @@
+---
+name: 'step-07-commit-push'
+description: 'Safely commit and push verified code following centralized GitFlow guidelines'
+
+# Path Definitions
+workflow_path: '{project-root}/_siesa-agents/bmm/workflows/4-implementation/code-review'
+
+# File References
+thisStepFile: '{workflow_path}/steps/step-07-commit-push.md'
+workflowFile: '{project-root}/_siesa-agents/bmm/workflows/4-implementation/code-review/workflow.md'
+outputFile: '{output_folder}/review-{story_key}.md'
+
+# Data References
+sprint_status_file: '{implementation_artifacts}/sprint-status.yaml'
+
+# Centralized GitFlow Guidelines
+gitFlowGuide: '{project-root}/_siesa-agents/bmm/data/git-flow-siesa.md'
+---
+
+# Step 7: Commit & Push
+
+## STEP GOAL:
+
+To securely persist the verified and approved code changes to the repository following the **centralized GitFlow guidelines** defined in `{gitFlowGuide}`.
+
+## MANDATORY EXECUTION RULES:
+
+- 📖 **LOAD AND READ** `{gitFlowGuide}` before any Git operation
+- 🛑 ONLY execute if the story status is explicitly 'done' or 'completed'
+- 🌳 Ensure development branch follows the naming convention from the centralized guide
+- 📝 Commit messages must follow the standard from `{gitFlowGuide}` (Conventional Commits)
+
+## Sequence of Instructions
+
+### 1. Load GitFlow Guidelines
+
+<action>
+1. Load and read the entire file at `{gitFlowGuide}`.
+2. Extract and apply:
+   - **Commit Message Format**: From Section 3 (Conventional Commits)
+   - **Governance Rules**: From Section 4 (lowercase, protected branches)
+</action>
+
+### 2. Verification of Status
+
+**Goal**: Ensure we are authorized to push code.
+
+<action>
+1. Load `{sprint_status_file}`.
+2. Find the entry for `{{story_key}}` under `development_status`.
+3. Check if the value is `done` (or `completed`).
+</action>
+
+<check if="status != 'done' AND status != 'completed'">
+  <output>
+  ⚠️ **COMMIT ABORTED**: Story status is '{{status}}'.
+  Changes are only committed and pushed when the story is marked as 'done'.
+  </output>
+  <action>STOP execution. Do NOT run git commands.</action>
+</check>
+
+### 3. Branch Validation
+
+**Goal**: Ensure code is committed to the correct branch per GitFlow guidelines.
+
+<check if="status == 'done' OR status == 'completed'">
+
+  <action>
+  1. Run `git branch --show-current` to get `current_branch`.
+  2. Validate the branch follows the naming convention from `{gitFlowGuide}`:
+     - Pattern: `{parent}-{team}-{owner}-{rq}-{description}`
+     - Must be lowercase
+     - Must NOT be `main` or `develop` (protected branches)
+  </action>
+
+  <check if="current_branch == 'main' OR current_branch == 'develop'">
+      <output>
+      🛑 **COMMIT BLOCKED**: Cannot commit directly to protected branch '{{current_branch}}'.
+      Per GitFlow guidelines, please switch to your feature branch first.
+      </output>
+      <action>STOP execution.</action>
+  </check>
+
+  <check if="branch naming is valid">
+      <output>✅ Branch '{{current_branch}}' follows GitFlow naming convention.</output>
+  </check>
+
+</check>
+
+### 4. Git Operations
+
+**Goal**: Persist changes following commit standards from `{gitFlowGuide}`.
+
+<check if="status == 'done' OR status == 'completed'">
+
+  1. **Stage Changes**:
+     <action>Run command `git add .`</action>
+
+  2. **Construct Commit Message**:
+     <action>
+     Per Section 3 of `{gitFlowGuide}`, use Conventional Commits format:
+     - For features: `feat: {description}`
+     - For fixes: `fix: {description}`
+
+     Derive type from story context and construct message.
+     </action>
+
+  3. **User Confirmation**:
+     <output>
+     READY TO COMMIT:
+     - Branch: {{current_branch}}
+     - Message: "feat: implementation for story {{story_key}}"
+
+     Do you want to proceed with the commit and push?
+     </output>
+
+     <menu>
+        <item cmd="C" action="continue">Yes, Commit & Push</item>
+        <item cmd="M" action="exit">No, Cancel (Manual Handling)</item>
+     </menu>
+
+     <logic>
+       <if selection="M">
+          <output>🚫 Commit cancelled by user.</output>
+          <output>Changes are staged. You can now commit manually.</output>
+          <action>Update frontmatter of `{outputFile}`: `stepsCompleted: [1, 2, 3, 4, 5, 6, 7]`</action>
+          <action>EXIT</action>
+       </if>
+     </logic>
+
+  4. **Commit Changes**:
+     <action>Run command `git commit -m "feat: implementation for story {{story_key}}"`</action>
+     <check if="Commit failed (no changes?)">
+        <output>ℹ️ No changes to commit.</output>
+     </check>
+
+  5. **Push to Remote**:
+     <action>
+     1. Get current branch: `git branch --show-current`
+     2. Push: `git push origin {{current_branch}}`
+     </action>
+
+     <check if="Push failed">
+        <output>❌ **Push Failed**. Please check your network or permissions and try pushing manually.</output>
+     </check>
+     <check if="Push success">
+        <output>✅ **Success**: Code pushed to origin/{{current_branch}}.</output>
+     </check>
+
+</check>
+
+### 5. Final Logging
+
+<action>Append to `{outputFile}`:</action>
+<template-output>
+## Repository Sync
+- **Branch**: {{current_branch}}
+- **Commit**: [Performed/Skipped]
+- **Push**: [Performed/Skipped]
+- **GitFlow Compliance**: ✅ Verified against `{gitFlowGuide}`
+- **Status**: Workflow Completed Successfully
+</template-output>
+
+### 6. Workflow Completion
+
+<output>
+🎉 **Workflow Completed**
+The code review cycle for **{{story_key}}** is finished.
+All Git operations followed the centralized GitFlow guidelines.
+</output>
+
+<action>Update frontmatter of `{outputFile}`: `stepsCompleted: [1, 2, 3, 4, 5, 6, 7]`</action>
+
+<action>EXIT workflow.</action>

package/siesa-agents/bmm/workflows/4-implementation/code-review/workflow.md

@@ -0,0 +1,57 @@
+---
+name: code-review
+description: "Adversarial Senior Developer Code Review. Validates stories, checks git changes, enforces strict quality, and syncs status with Jira."
+web_bundle: true
+---
+
+# Code Review
+
+**Goal:** Perform an adversarial code review to validate implementation against story requirements, finding at least 3-10 specific issues, and synchronize status with project tracking.
+
+**Your Role:** In addition to your name, communication_style, and persona, you are an **Adversarial Senior Developer**. You verify claims against reality. You doubt everything until proven. You bring deep code quality expertise, while the user brings the implementation to be reviewed. Work together to perfect the code.
+
+## WORKFLOW ARCHITECTURE
+
+### Core Principles
+
+- **Micro-file Design**: Each step of the overall goal is a self contained instruction file that you will adhere too 1 file as directed at a time
+- **Just-In-Time Loading**: Only 1 current step file will be loaded, read, and executed to completion - never load future step files until told to do so
+- **Sequential Enforcement**: Sequence within the step files must be completed in order, no skipping or optimization allowed
+- **State Tracking**: Document progress in output file frontmatter using `stepsCompleted` array when a workflow produces a document
+- **Append-Only Building**: Build documents by appending content as directed to the output file
+
+### Step Processing Rules
+
+1. **READ COMPLETELY**: Always read the entire step file before taking any action
+2. **FOLLOW SEQUENCE**: Execute all numbered sections in order, never deviate
+3. **WAIT FOR INPUT**: If a menu is presented, halt and wait for user selection
+4. **CHECK CONTINUATION**: If the step has a menu with Continue as an option, only proceed to next step when user selects 'C' (Continue)
+5. **SAVE STATE**: Update `stepsCompleted` in frontmatter before loading next step
+6. **LOAD NEXT**: When directed, load, read entire file, then execute the next step file
+
+### Critical Rules (NO EXCEPTIONS)
+
+- 🛑 **NEVER** load multiple step files simultaneously
+- 📖 **ALWAYS** read entire step file before execution
+- 🚫 **NEVER** skip steps or optimize the sequence
+- 💾 **ALWAYS** update frontmatter of output files when writing the final output for a specific step
+- 🎯 **ALWAYS** follow the exact instructions in the step file
+- ⏸️ **ALWAYS** halt at menus and wait for user input
+- 📋 **NEVER** create mental todo lists from future steps
+
+---
+
+## INITIALIZATION SEQUENCE
+
+### 1. Module Configuration Loading
+
+Load and read full config from `{project-root}/_siesa-agents/bmm/config.yaml` and resolve:
+
+- `project_name`, `output_folder`, `user_name`, `communication_language`, `document_output_language`
+- `user_skill_level`, `planning_artifacts`, `implementation_artifacts`
+
+### 2. First Step EXECUTION
+
+Load, read the full file and then execute `{workflow_root}/steps/step-01-load-story.md` to begin the workflow.
+
+*(Note: `workflow_root` is `{project-root}/_siesa-agents/bmm/workflows/4-implementation/code-review`)*

package/siesa-agents/bmm/workflows/4-implementation/code-review/workflow_ext.md

@@ -1,11 +1,5 @@
 # MANDATORY RULE: CODE REVIEW WORKFLOW
 
-**TRIGGER:** Every time the user requests a CODE REVIEW, such as `/code-review`.
-
-**CONTEXT TO INJECT (apply throughout the entire workflow):**
-
-The following rules must be kept in memory and applied at the appropriate moment without altering the standard workflow flow:
-
 ## 1. During step-01-load-story: use the following definition for point 3. Discover Git Changes
 
 ### 3. Discover Git Changes
@@ -27,6 +21,7 @@ Sub-agents **must NOT be used** when the code review workflow is invoked directl
 
 - If invoked directly → follow the standard sequential workflow steps without spawning any sub-agents.
 - If invoked from quick-dev → sub-agents may be used as defined by the quick-dev orchestration.
+
 ---
 
 ## 3. During step-06-jira-sync: REPLACE entirely with Automated sa-jira-sync-api
@@ -219,3 +214,10 @@ node "{project_root}/_siesa-agents/observability/scripts/sa-emit.js" --event wor
 - If any `sa-emit` call fails, log the error and **continue the workflow normally**. Observability must never block the workflow.
 - Use the exact `{{story_key}}` value as resolved in step-01 (e.g., `1-1-user-authentication`).
 - Do NOT wait for user confirmation to execute these commands — they are silent background operations.
+
+Step-06 of the Siesa extension declares its own `nextStepFile` pointing to:
+```
+{project-root}/_siesa-agents/bmm/workflows/4-implementation/code-review/steps/step-07-commit-push.md
+```
+
+No additional redirect rule is needed — the wiring is handled by step-06's frontmatter. This section exists only for documentation clarity.

package/siesa-agents/bmm/workflows/4-implementation/correct-course/workflow_ext.md

@@ -1,11 +1,11 @@
 ## Step 1: Load Company Standards Context
 Load ALL the following company standards documents to understand the architectural constraints and preferences:
 
-1. LOAD the FULL @{project-root}/_bmad/bmm/workflows/3-solutioning/create-architecture/data/company-standards/technology-stack.md - Complete summary of frontend and backend stack
-2. LOAD the FULL @{project-root}/_bmad/bmm/workflows/3-solutioning/create-architecture/data/company-standards/architecture-patterns.md - Detailed folder structures (Frontend + Backend)
-3. LOAD the FULL @{project-root}/_bmad/bmm/workflows/3-solutioning/create-architecture/data/company-standards/backend-standards.md - .NET, EF Core, PostgreSQL, Testing standards
-4. LOAD the FULL @{project-root}/_bmad/bmm/workflows/3-solutioning/create-architecture/data/company-standards/frontend-standards.md - React, Vite, TanStack Router, Testing standards
-5. LOAD the FULL @{project-root}/_bmad/bmm/workflows/3-solutioning/create-architecture/data/company-standards/vite-config-standard.md - Vite configuration for Single-SPA and Module Federation
-6. LOAD the FULL @{project-root}/_bmad/bmm/workflows/3-solutioning/create-architecture/data/company-standards/database-conventions.md - PostgreSQL conventions (naming, schemas, mappings)
-7. LOAD the FULL @{project-root}/_bmad/bmm/workflows/3-solutioning/create-architecture/data/company-standards/technical-preferences-ux.md - Design system, colors, typography, accessibility 
-8. LOAD the FULL @{project-root}/_bmad/bmm/workflows/3-solutioning/create-architecture/data/company-standards/mastercrud-use-reference.md - MasterCrud is the highest-level orchestrator component in Siesa UI Kit. It coordinates data grids, forms, filters, and CRUD operations into a unified, configurable interface
+1. LOAD the FULL @{project-root}/_siesa-agents/bmm/workflows/3-solutioning/create-architecture/data/company-standards/technology-stack.md - Complete summary of frontend and backend stack
+2. LOAD the FULL @{project-root}/_siesa-agents/bmm/workflows/3-solutioning/create-architecture/data/company-standards/architecture-patterns.md - Detailed folder structures (Frontend + Backend)
+3. LOAD the FULL @{project-root}/_siesa-agents/bmm/workflows/3-solutioning/create-architecture/data/company-standards/backend-standards.md - .NET, EF Core, PostgreSQL, Testing standards
+4. LOAD the FULL @{project-root}/_siesa-agents/bmm/workflows/3-solutioning/create-architecture/data/company-standards/frontend-standards.md - React, Vite, TanStack Router, Testing standards
+5. LOAD the FULL @{project-root}/_siesa-agents/bmm/workflows/3-solutioning/create-architecture/data/company-standards/vite-config-standard.md - Vite configuration for Single-SPA and Module Federation
+6. LOAD the FULL @{project-root}/_siesa-agents/bmm/workflows/3-solutioning/create-architecture/data/company-standards/database-conventions.md - PostgreSQL conventions (naming, schemas, mappings)
+7. LOAD the FULL @{project-root}/_siesa-agents/bmm/workflows/3-solutioning/create-architecture/data/company-standards/technical-preferences-ux.md - Design system, colors, typography, accessibility 
+8. LOAD the FULL @{project-root}/_siesa-agents/bmm/workflows/3-solutioning/create-architecture/data/company-standards/mastercrud-use-reference.md - MasterCrud is the highest-level orchestrator component in Siesa UI Kit. It coordinates data grids, forms, filters, and CRUD operations into a unified, configurable interface