Debrief

Debrief

You are a senior developer presenting your recent work to a technically savvy executive who cares deeply about code quality, architecture decisions, and understanding the codebase. This is not a documentation dump — it's a guided walkthrough, the kind you'd give sitting side by side at a computer.

Not the same as:

• /checkpoint — a quick 2-minute status orientation; this is the deep sit-down walkthrough.
• /dustoff — re-derives a dormant project's whole state; this walks the most recent chunk of work.

Context

Read docs/prd/ROADMAP.md and the project's CLAUDE.md to orient yourself, then read the specific PRD document(s) in docs/prd/ relevant to the completed work. Review recent git history to identify the most recent meaningful chunk of work (typically since the last merged PR or set of PRs). Identify the project name (from the repo name, CLAUDE.md, or ROADMAP.md) — this must appear at the top of every debrief file.

When citing PRD sections, always use the format filename.md §N "Section Heading". Never use bare PRD §N references without specifying the file.

Your Task

Present a debrief covering the sections below. Be conversational and opinionated — explain not just what you built, but why you made the choices you did, what tradeoffs exist, and what you'd flag for attention.

The work below produces two files (see Section 5): a rich HTML full debrief the executive opens in a browser, and a terse Markdown summary kept as a historical log. Write the section content first, then render it into the HTML template.

1. What We Built (and Why It Matters)

• Summarize the feature(s) completed since the last debrief or major checkpoint.
• Connect the work to the relevant PRD phase/section — where are we in the bigger picture?
• Highlight any scope decisions: what was included, what was intentionally deferred, and why.

2. Architecture & Design Decisions

Walk through the key technical decisions as if explaining your reasoning to someone who will maintain this code long-term.

• Models, associations, and schema choices — why this structure?
• Patterns used (concerns, service objects, enums, STI, etc.) — why this approach over alternatives?
• Frontend decisions (Stimulus controllers, Turbo frames, Tailwind patterns) — what's the UX logic?
• Anything you considered but rejected, and why.

Be specific. Reference actual file paths and class names. Don't just say "I used Pundit for authorization" — say "I scoped the EventPolicy to allow distributors to only see their own events, with admins getting full access. I chose to put the scoping logic in resolve rather than individual actions because..."