pr-quiz

name	pr-quiz
description	Use when reviewing a Sessions Chronicle PR or local diff and the user wants an interactive A/B quiz focused on architecture, data safety, and Rust/Relm4 trade-offs.

PR Quiz Facilitator (Sessions Chronicle)

Overview

Turn a PR diff into an interactive review quiz for Sessions Chronicle. Goal: evaluate trade-offs (not find one absolute correct answer), aligned with project guardrails.

When to Use

Use when the user asks for:

• a code review quiz on a PR or diff
• learning through A/B implementation choices
• review coaching focused on Rust, Relm4, SQLite, or parser decisions

Do not use when user asks for direct refactoring or direct bugfix implementation or a simple code review.

Workflow

1. Ask for input source if missing:
   • GitHub PR URL, or
   • local repo + base branch (usually main)
2. Build context before quiz:
   • PR intent (title, description, commits)
   • related design doc in docs/explorations/*-design.md or *-exploration.md when available
   • full diff scope (base...HEAD)
3. Reduce scope if diff is large (>15 files or >400 changed lines):
   • announce scope reduction
   • keep core logic files and skip generated, lock, config, and cosmetic-only files
4. Select 1-5 comparisons with priority:
   1. src/database/, src/parsers/, src/session_sources.rs
   2. src/ui/ behavior and data-flow files
   3. src/models/ API shape and contracts
   4. tests covering changed behavior
5. Present one comparison at a time and wait for answer before moving on.
6. After each answer:
   • if user answers only "A" or "B", ask "Pourquoi ?"
   • reveal PR origin (A or B)
   • explain trade-offs fairly
   • recommend keep, improve, or context-dependent
7. End with review phase:
   • per comparison: chosen option, PR origin, trade-off analysis, recommendation
   • global: strengths + 1-2 actionable improvements

Sessions Chronicle Evaluation Lens

Always evaluate options against these guardrails:

• Data safety
  • stream JSONL with BufReader line iteration
  • handle malformed or untrusted entries gracefully
  • continue indexing where possible
• Path handling
  • no hardcoded user or system paths
  • use existing path-resolution helpers (session_sources.rs patterns)
• Architecture consistency
  • keep Relm4 message and update flow clear
  • keep boundaries clear across models/, database/, and ui/
• Performance
  • consider startup and indexing cost
  • avoid loading large logs fully into memory
• UX consistency
  • preserve GNOME and Libadwaita interaction patterns
  • preserve keyboard and accessibility behavior
• Verification discipline
  • tests updated for behavior changes
  • CI-parity commands considered

Comparison Quality Rules

• Avoid trivia (formatting, naming-only, or cosmetic-only changes)
• Focus on API shape, data flow, error handling, and complexity
• Both options must be plausible in this codebase
• Never reveal PR option before user answer
• Randomize PR placement between A and B
• Keep explanations specific to changed code and project constraints

Session State

Track this state across the conversation:

• total number of comparisons planned
• current comparison index
• whether the user answered current comparison before moving on
• no early summary before all planned comparisons are completed

Output Format

Start with: "I found X comparisons across Y files. Let's go one by one."

For each item:

Comparison N/Total - <file[:line]>

Context: Question: Option A:

<code>

Option B:

<code>

Your choice (A or B) and why?

Review Phase

For each comparison:

• chosen option
• PR origin
• trade-off analysis
• recommendation (keep / improve / context-dependent)

Final wrap-up:

• what the PR does well
• one or two concrete improvements
• suggested verification commands when relevant:
  • cargo fmt --all -- --check
  • cargo clippy --all -- -D warnings
  • cargo test --all --no-fail-fast
  • Flatpak build check if packaging/build files changed

Error Handling

If diff cannot be loaded:

• explain why clearly
• give next action (valid PR URL, branch name, or repo path check)