mr-wrapup

name	mr-wrapup
description	Wrap up a GitLab MR — build, deploy & verify on device(s), then generate/update the MR description with full documentation.

You are a wrap-up agent. The user wants to finalize an MR.

Optional arguments: $ARGUMENTS (MR number override, e.g. /mr-wrapup 71). If no argument is given, auto-detect the open MR for the current branch via glab mr view.

---

PHASE 1 — UNDERSTAND CHANGES

1. Run git log <base-branch>..HEAD --oneline to list all commits on this branch.
2. Run git diff <base-branch>..HEAD --stat to see which files changed.
3. Read the full diff (git diff <base-branch>..HEAD) to understand what was added, removed, or modified.
4. Run glab mr view [MR_NUMBER] to read the current MR title, description, and any review comments.
5. Identify the change categories present (schema, API, build tooling, tests, config, etc.) — only document sections that are actually relevant.

---

PHASE 2 — BUILD

1. Determine the build command from project context (e.g. echo ./build.sh | ./shell.sh for bartleby).
2. Run a release (stripped) build.
3. Locate the output binary (typically artifacts/<version>/aarch64/bartleby-aarch64 or target/aarch64-unknown-linux-gnu/release/<binary>).
4. If the build fails, stop here and report the errors — do not proceed to deploy.

---

PHASE 3 — DEPLOY & VERIFY

For each configured device:

1. Stop the service (systemctl stop <service>).
2. SCP the binary to the correct deploy path.
   • Note: some devices use a symlink target (e.g. bartleby.fix) — deploy to the real file, not the symlink.
   • Note: if the root filesystem is full, deploy to /mnt/media/usr/bin/ instead.
3. Start the service (systemctl start <service>).
4. Wait ~15 seconds for startup.
5. Check systemctl is-active <service> 3 times, ~10 seconds apart.
6. After each check, grab the last 5 journal lines (journalctl -u <service> -n 5 --no-pager) to confirm no crash loop or fatal errors.
7. Record: device IP, pass/fail for each of 3 checks, PID stability, any notable log lines.

If any device fails 2+ checks or shows a crash loop, stop and report before updating the MR.

---

PHASE 4 — PROJECT-SPECIFIC VERIFICATION

After confirming the service is healthy, run any project-specific sanity checks that are relevant to the changes:

• For database schema changes: query the relevant tables to confirm correct structure and data.
• For API changes: exercise the changed endpoints or methods if feasible via SSH.
• Document the actual output observed.

---

PHASE 5 — GENERATE MR DESCRIPTION

Write a comprehensive MR description. Only include sections that apply to the actual changes.

Structure

## Summary
One or two sentences: what this MR does and why.

## Motivation
Why was this change needed? What problem does it solve?
Skip if obvious from Summary.

## Schema  (if DB tables/indexes/triggers changed)
DDL with comments explaining the design decisions.
Explain the purpose of each constraint, index, and trigger.

## State Lifecycle  (if a state machine was introduced/changed)
ASCII diagram + table showing each state and the exact transition condition.

## Public API  (if public methods/functions were added or changed)
Table of new/changed methods with a one-line description each.

## Integration  (if application code in main.rs / entry point changed)
Prose describing where in the startup/shutdown flow new code runs.

## Legacy / Migration Handling  (if backwards compat or data migration logic was added)
Explain the one-time / idempotent logic and guards.

## Build Improvements  (if build tooling changed)
List the new gates (fmt, deny, clippy, etc.) and any dependency bumps with rationale.

## Sample Queries / Outputs  (for DB or observable outputs)
Show the actual commands and representative output for each meaningful case.

## Test Steps
- Unit test command (exact shell command)
- Integration test steps (stop → mutate → start → verify, with exact commands)
- Build & deploy commands (with correct paths for this build)

## Verification (YYYY-MM-DD)
Table of devices × 3 checks with active/failed status.
Note PID stability and any notable observations.
Notable log output if relevant.

Closes <JIRA-TICKET>

Rules for the description

• Use precise, technical language — no marketing fluff.
• Show actual observed output (real timestamps, real row data) not made-up examples.
• Every command must be copy-pasteable and use the correct paths for this build version.
• If a section doesn't apply, omit it entirely — don't write placeholder text.
• Keep the Closes <TICKET> line at the bottom.

---

PHASE 6 — UPDATE THE MR

1. Run glab mr update <MR_NUMBER> --description "$(cat <<'EOF' ... EOF)" with the generated description.
2. Confirm the update succeeded.
3. Print the MR URL.

---

DELIVERY CHECKLIST

Before finishing, confirm:

• Build succeeded (release binary, not debug)
• All devices passed 3/3 checks
• No crash loops or fatal errors observed
• MR description updated with accurate, copy-pasteable content
• Observed outputs in the description match what was actually seen on device
• Closes <TICKET> line present
• MR URL printed for the user

Permissions

Bash commands allowed except:

• git push --force (any form) - DENIED
• glab mr merge/close/delete - DENIED