Roundtrip Radar

This skill audits application workflows for bugs, data-safety issues, performance problems, and data round-trip completeness. It operates in three primary steps plus two targeted entry points:

• Step 0 — Discover all workflows (run once, or when workflows change)
• Step 1 — Deep audit one workflow at a time (one prompt per workflow)
• Step 2 — Roll-up cross-cutting patterns across all audited workflows
• Trace — Audit a specific user journey described in natural language (see § Trace Command)
• Diff — Compare findings against the previous audit's ledger entries (see § Diff Command)

Usage

Trace Command

Targeted flow tracing — trace a specific user journey described in natural language.

Usage

/roundtrip-radar trace "Dashboard → Add Item → Photo → Save"
/roundtrip-radar trace "Settings, Export, CSV, Email"

How It Works

1. Parse the path — Split on →, ->, or , into discrete steps
2. Identify code locations — For each step, search for:
   • View names matching the step
   • Sheet triggers, navigation actions
   • Button labels, action handlers
3. Trace step by step — For each transition:
   • File and line number
   • State changes (sheet presentations, navigation, @State mutations)
   • Data transformations (what model fields are read/written)
4. Check for issues at each step:
   • Is data preserved between steps? (Round-trip completeness)
   • Are collections preserved or silently narrowed? (Collection narrowing)
   • Are there error paths that lose context? (Error handling)
   • Is the user's intent preserved? (Data safety)
   • Are there race conditions? (Concurrency)
5. Output — Issue Rating Table for findings + step-by-step trace with receipts

Output Format

Trace: Dashboard → Add Item → Photo → Save

| Step | Action | File | Lines | Data In | Data Out | Finding |
|------|--------|------|-------|---------|----------|---------|
| 1 | Dashboard tap "Add" | DashboardView.swift | 142-145 | — | activeSheet = .addItem | ok |
| 2 | Add Item sheet presents | AddItemView.swift | 1-50 | Item.draft | item.title, item.category | ok |
| 3 | Photo picker | PhotoPicker.swift | 23-89 | item.id | PhotoAttachment | ⚠️ orientation lost |
| 4 | Save item | ItemViewModel.swift | 112-134 | item + attachments | modelContext.save() | ok |

Issues Found:
| # | Finding | Urgency | Risk: Fix | Risk: No Fix | ROI | Blast Radius | Fix Effort | Status |

When to Use

• Debugging a specific user report — "When I add a photo and save, the orientation is wrong"
• Verifying a fix — Trace the exact path to confirm data flows correctly
• Pre-release spot check — Trace critical paths without a full audit

Diff Command

Compare findings against the previous roundtrip-radar audit — surface what regressed, what got fixed, and what's new since the last run.

Usage

/roundtrip-radar diff
/roundtrip-radar diff --since 2026-04-01
/roundtrip-radar diff --workflow Backup

Source of Truth

The diff reads from .radar-suite/ledger.yaml — the only authoritative cross-session store of roundtrip-radar findings. Per-workflow handoff YAMLs (.agents/ui-audit/roundtrip-radar-handoff.yaml) are overwritten each run, so they cannot serve as a diff baseline.

The "previous audit" is defined as the most recent ledger session entry with skill: roundtrip-radar that is strictly older than the current session. If no prior session exists, the diff command MUST refuse with:

"No prior roundtrip-radar audit found in .radar-suite/ledger.yaml. Run a workflow audit first to establish a baseline."

Do not invent a baseline. Do not fall back to memory or .agents/research/ markdown reports.

How It Works

1. Identify the baseline session — read .radar-suite/ledger.yaml, find the most recent prior session entry with skill: roundtrip-radar. With --since YYYY-MM-DD, use the latest entry on or after that date instead.
2. Identify the current session — either the in-progress session (if the user just ran an audit and is asking for the diff) or the most recent completed session.
3. Bucket every finding from the union of baseline + current into one of four categories by RS-NNN ID:
   • Fixed — present in baseline with status: open, present in current with status: fixed
   • Regressed — present in baseline with status: fixed, present in current with status: open (also flag if file_hash changed since the fix, per the Regression Detection protocol in radar-suite-core.md)
   • New — RS-NNN ID is in current but not baseline
   • Persistent — present in both with the same status (open or deferred)
4. Apply optional filters: --workflow [NAME] restricts to findings whose workflow field matches.

Output Format

Diff: 2026-04-15 → 2026-05-12 (27 days, 4 sessions)

✅ Fixed (3)
| RS-NNN | short_title | Workflow | Fixed in |
|--------|-------------|----------|----------|
| RS-042 | Backup drops attachment storage | Backup | 2026-04-22 |
...

🔴 Regressed (1)
| RS-NNN | short_title | Workflow | Was fixed | file_hash changed? |
|--------|-------------|----------|-----------|--------------------|
| RS-019 | CSV import loses Room field | CSV Import | 2026-04-18 | yes (CSVImportManager.swift) |

🆕 New (5)
| RS-NNN | short_title | Workflow | Urgency |
|--------|-------------|----------|---------|

📌 Persistent (12)
[collapsed by default; pass --verbose to expand]

When to Use

• Pre-PR review — confirm the changes in this PR didn't reintroduce any previously-fixed bug
• Post-release retrospective — what got fixed this release cycle, what slipped
• Suspecting a regression — --workflow [NAME] narrows to one user journey

Refusal cases

• No prior ledger session: refuse with the message above
• --since date is in the future: refuse with "Date is in the future; no audits to compare"
• --workflow [NAME] matches no findings in either baseline or current: print "No findings in workflow [NAME] across either session" (not a refusal — a legitimate empty result)

Skill Introduction (MANDATORY — run before anything else)

This section replaces radar-suite-core.md § Session Setup for the roundtrip-radar entry point. Do NOT also run core's 4-question Session Setup — its questions are consolidated below. All four setup questions go in ONE AskUserQuestion call on first invocation. Step 1's per-workflow flow reuses these answers and never re-asks them.

Question 1: "What's your experience level with Swift/SwiftUI?"

• Beginner — New to Swift. Plain language, analogies, define terms on first use.
• Intermediate — Comfortable with SwiftUI basics. Standard terms, explain non-obvious patterns.
• Experienced (Recommended) — Fluent with SwiftUI. Concise findings, no definitions.
• Senior/Expert — Deep expertise. Terse, file:line only, skip explanations.

Question 2: "How should fixes be handled?"

• Auto-fix safe items (Recommended) — Apply isolated, low-blast-radius fixes automatically. Present cross-cutting fixes and design decisions for approval first.
• Review first — Present all findings with ratings, then ask before making any changes. Fixes still happen — you just approve each wave first.
• **Batch