# Reviewer meeting — agenda (for me)
> **Audience.** Myself, before the meeting. Not shared with the
> reviewer (they have [`briefing.md`](briefing.md) and
> [`questions.md`](questions.md) instead).
>
> **Purpose.** Keep the conversation on the high-stakes items
> without slipping into detail-tour mode.
**Length:** ~60 min (default; willing to extend if conversation is
productive).
## Opening — 5 min
- **Thank-you** + ~30 s on why I value their time specifically
(Springborn/Bobenko background = best-positioned audience for
this material).
- **Confirm format**: they've read `briefing.md`? Yes → skip ahead.
No → take 3 min to walk through it together via the reviewer-hub
URL.
## §1 Architectural tour — 10 min
Goal: they leave §1 with a mental map of what's where.
1. Open .
2. Click through:
- Doxygen → `discrete_conformal_map_euclidean` (the canonical entry,
shows the named-parameter pattern + traits).
- `locked-vs-flexible.md` § Summary table.
- `dependencies.md` § TL;DR.
3. **Don't** demo running the test suite live unless they ask —
they can verify the green badges later.
**Cue to move on**: when they have no more "where is X?" questions.
## §2 The five questions — 30 min
Goal: get clear answers to as many of the 5 questions in
[`questions.md`](questions.md) as possible. Order matters:
1. **Q4 first** (CGAL submission strategy — single package vs five).
This sets the framing for the rest. ~5 min.
2. **Q1** (Phase 9c port-literal vs re-derive). ~5 min.
3. **Q2** (Phase 9b-analytic — is the 6× speedup worth ~2 weeks?).
May trigger longer math discussion; cap at 10 min and offer to
continue async.
4. **Q5** (GC-1 cross-validation co-authorship). ~5 min.
5. **Q3** (CP-Euclidean output_uv_map). ~5 min.
**Trap to avoid**: don't relitigate any of the already-made decisions
(e.g. Surface_mesh as default, Eigen as backend) unless they bring it
up under "anything you'd say no to". Move forward, not sideways.
## §3 The "no" question — 5 min
Last paragraph of [`questions.md`](questions.md): *"Is there one
architecture decision where you think 'no, that's the wrong call'?"*
Ask explicitly. Wait. Don't fill silence. Negative feedback at this
phase is the highest-value information of the entire meeting.
## §4 Wrap-up — 5 min
- **Summarise**: 1 sentence per Q1–Q5 answer.
- **Next steps**:
- Items they offered to help on (if any) → I'll send a follow-up
email within 48 h.
- Items they flagged as worth changing → I'll write a one-page
plan + send for sign-off before starting work.
- **Cadence**: do they want a periodic update? Once-a-quarter? When
hitting Phase 9c milestone?
- **Citation**: ask whether they want acknowledgement in the
CGAL submission's `THANKS.md`.
## Material I have ready (in tabs)
1.
2. (source)
3. Local terminal in the repo (for any "show me X" requests)
4. `doc/math/hyperideal-hessian-derivation.md` open in editor
(for Q2)
5. `doc/architecture/locked-vs-flexible.md` open at "Summary table"
6. This file, [`questions.md`](questions.md), and
[`briefing.md`](briefing.md) for backstop.
## After the meeting
- 30-min decompression — don't take notes during the meeting beyond
bullet-tracking of Q1–Q5 answers; write up a full memo in the 30 min
AFTER.
- Memo template:
```
Date: ____
Reviewer: ____
Duration: ____ min
Q1 answer: ____
Q2 answer: ____
Q3 answer: ____
Q4 answer: ____
Q5 answer: ____
"No" pointer: ____
Action items:
[ ] (within 48 h) ____
[ ] (within 2 wks) ____
[ ] (longer term) ____
Cadence agreed: ____
```
- Store the memo at `doc/reviewer/2026-XX-XX-meeting-notes.md`
(gitignored if confidential, otherwise committed).