Architecture: trusted learning progress versus reward plugins

[evan188199-tech]

Context

Reading extension protocol v1 is deliberately narrow: a Python entry point receives a server-verified reading context and returns a bounded card, quiz, feedback, or browser_speech result. It does not provide persistent state, UI slots, migrations, or per-plugin storage.

#1368 / #1369 added account-scoped Reading records while explicitly excluding reward state. #992 also originally said reward mechanics should remain optional and plugin-based. #1657 now proposes a server-owned quiz-star watermark because the reward must be derived from server-graded answers, remain durable across retries, and appear in first-party Reading UI.

Decision needed

1. Should quiz completion/correctness watermarks be treated as first-party Reading progress, even if their “stars” presentation is kid-friendly?
2. If rewards must remain plugin-based, what minimum core primitives should upstream provide first: trusted learning events, plugin-scoped storage, or predefined UI slots?
3. Should feat(reading): add server-owned quiz star rewards (#1656) #1657 proceed as a bounded core feature, or be closed and redesigned on top of those primitives?

Recommendation

I would treat #1657 as bounded core progress rather than generic gamification: no XP, coins, streaks, leaderboards, or client-trusted score. The server derives the watermark from immutable graded evidence and only the first-party reader displays it.

If the preferred direction is plugin-based, I would close #1657 and split the work into: a neutral trusted-event/progress contract, isolated plugin storage, and a safe reward-summary UI slot. I would not try to solve the whole #380 Learning Experience Plugin SDK first.

cc @pancacake