` row.
## Page Structure
16. **4 tables in order:**
- Table 1: High level scope + Sprint Goals
- Table 2: Main sprint table (7 columns) + footer rows
- Table 3: Carryover (1 column — centered header + status-grouped rows)
- Table 4: Release updates (3 columns — header + RC rows)
17. **Test Artifacts underline** — `Test Artifacts:` gets the underline, **not** "High level scope". The high level scope header is just `High level scope` (no ``).
## Guardrails
18. **Always confirm** before pushing to Confluence
19. **Default to test page** (`{TEST_PAGE_ID}`) unless user explicitly says production
20. **Never overwrite** existing sprint sections — append new ones
21. **Sync Confluence after rule changes** — when a rule or template is updated, proactively offer to update the Confluence page to match the new rules
22. **Paginate all JIRA queries** — never assume a single API call returns all issues. Always paginate until fewer results than the limit are returned.
23. **Validate before pushing** — before confirming with the user, run the validation checks described in workflow step 8. If any check fails, fix the issue and re-validate before proceeding.
24. **Rules take precedence** — if any rule in this file contradicts the storage format template below, the rule takes precedence over the template.
25. **Never guess RC versions** — release candidate version numbers are not available in JIRA data. Always leave RC rows with placeholder text for the user to fill in manually.
---
## Footer Row Data
How to populate the three footer rows in Table 2 using JIRA API data.
### Issues added after sprint start
1. Call `jira_search` with JQL `sprint = {SPRINT_ID}`, fields `summary,status,created,resolutiondate`, limit 50, and `expand: "changelog"`
2. For each issue, find the changelog entry where `field = "Sprint"` and `to_id` contains the sprint ID (e.g. `{SPRINT_ID}`). This is when the issue was added.
3. Compare that changelog `created` timestamp against the sprint `start_date`
4. If the changelog date is **after** the sprint start date → issue was added after start
5. Split these issues by platform (iOS/Android) and place JIRA macros in the appropriate columns
### Story|Bugs completed outside of this sprint
1. From the same search results, check each issue's `resolutiondate`
2. If `resolutiondate` is **before** sprint `start_date` → completed before the sprint
3. If `resolutiondate` is **after** sprint `end_date` → completed after the sprint
4. Both cases = "completed outside of this sprint"
5. Split by platform and place in the appropriate columns
### Issues Removed from this sprint
- **Cannot be determined via API** on JIRA Server — the `sprint was` JQL history search is not supported
- Leave this row empty unless the user provides the data manually from the Sprint Retrospective report in the JIRA UI
---
## Carryover Data
How to determine "Stories & Bugs Not Completed" and their status at sprint close.
### Identifying carryover issues
**IMPORTANT: `resolutiondate` alone is NOT sufficient.** Many issues on [Company] JIRA Server use "Deployed" status without setting a formal JIRA resolution. These issues show `resolution = Unresolved` with no `resolutiondate`, even though they are functionally complete.
Use this two-step approach:
1. **Step 1 — Resolution date check:** Issues with `resolutiondate` **after** the sprint `end_date` → definitely carryover
2. **Step 2 — Unresolved status check:** Search for issues with `resolution = Unresolved` using JQL: `sprint = {SPRINT_ID} AND resolution = Unresolved`. For each of these, call `jira_jira_get_issue_dates` with `include_status_changes: true` to determine their status at sprint close:
- If the issue was in a **Done-category status** at sprint close (e.g. `Done`, `Deployed`, `Done Deploy Not Needed`, `Planned for Next Release`) → **completed** (not carryover)
- If the issue was in a **non-Done status** at sprint close (e.g. `QA`, `Dev`, `Pull Request`, `Blocked`, `In Definition`) → **carryover**
3. Combine results from both steps = all carryover issues
**Done-category statuses** (treat as completed at sprint close): `Done`, `Deployed`, `Done Deploy Not Needed`, `Planned for Next Release`
### Determining status at sprint close
1. For each carryover issue, call `jira_jira_get_issue_dates` with `include_status_changes: true` (reuse data from Step 2 if already fetched)
2. Look at the `status_changes` array and find which status the issue was in at the sprint `end_date`:
- Find the status entry where `entered_at` is before sprint end AND (`exited_at` is after sprint end OR `exited_at` is null)
3. Group carryover issues by their status at sprint close
### Carryover status labels
Use these labels based on the status found:
| Status at sprint close | Carryover label |
|----------------------|-----------------|
| `QA` | `With QA at end of sprint` |
| `Dev` / `Dev Ready` | `Card with DEV at end of sprint` |
| `Pull Request` | `Card with PR at end of sprint` |
| `Blocked` | `Blocked at end of sprint` |
| `In Definition` | `Card in Definition at end of sprint` |
---
## Storage Format Template
This is the exact Confluence storage format HTML for a sprint section. Replace placeholders in `{BRACES}` with actual values.
### Placeholders
| Placeholder | Source |
|-------------|--------|
| `{SPRINT_NAME}` | User-provided sprint identifier, e.g. `FY26Q3.5` |
| `{START_DATE}` | Format `DD/Mon/YY`, e.g. `04/Feb/26` |
| `{END_DATE}` | Format `DD/Mon/YY`, e.g. `25/Feb/26` |
| `{SPRINT_GOALS}` | From sprint object `goal` field |
| `{FEATURE_ROWS}` | Generated rows grouped by epic — see below |
| `{ADDED_AFTER_START_IOS}` | JIRA macros for iOS issues added after sprint start |
| `{ADDED_AFTER_START_ANDROID}` | JIRA macros for Android issues added after sprint start |
| `{COMPLETED_OUTSIDE_IOS}` | JIRA macros for iOS issues completed outside sprint |
| `{COMPLETED_OUTSIDE_ANDROID}` | JIRA macros for Android issues completed outside sprint |
| `{CARRYOVER_ROWS}` | Multiple `` rows grouped by status at sprint close |
| `{NEXT_SPRINT}` | Next sprint name, e.g. `FY26Q3.6` |
| `{RC_ROWS}` | Release candidate rows — left blank for user to fill in |
### JIRA Macro
Each issue reference uses this macro (replace `{KEY}`):
```xml
Company Jira{YOUR_JIRA_SERVER_ID}{KEY}
```
Multiple macros in one cell: separate with `
`.
### Full Template
```xml
Mobile App - Sprint {SPRINT_NAME} - {START_DATE} to {END_DATE}
Test Artifacts:
High level scope |
| Sprint Goals: {SPRINT_GOALS} |
| Squad Name |
App |
Features assigned |
iOS |
Android |
Geo |
Comments |
{FEATURE_ROWS}
| | | | | | |
| Issue added to sprint after start time |
| | {ADDED_AFTER_START_IOS} | {ADDED_AFTER_START_ANDROID} | | |
| Story|Bugs completed outside of this sprint |
| | {COMPLETED_OUTSIDE_IOS} | {COMPLETED_OUTSIDE_ANDROID} | | |
| Issues Removed from this sprint |
| | | | | |
| Stories & Bugs Not Completed and carried over to - Sprint {NEXT_SPRINT} |
{CARRYOVER_ROWS}
| Release updates in Sprint {SPRINT_NAME} |
PRT Defects |
Release Scope tickets |
{RC_ROWS}
```
### Feature Row Format
The first feature row includes Squad Name and App. All subsequent rows leave those empty.
**First row:**
```xml
| Mobile App |
[Company] |
{EPIC_NAME} |
{IOS_JIRA_MACROS separated by
} |
{ANDROID_JIRA_MACROS separated by
} |
|
|
```
**Subsequent rows:**
```xml
|
|
{EPIC_NAME} |
{IOS_JIRA_MACROS separated by
} |
{ANDROID_JIRA_MACROS separated by
} |
|
|
```
### Carryover Row Format
Each status group gets its own row. The label text and JIRA macros go in the same ` | `, separated by `
`.
```xml
|