RFC / roadmap: from "maintained" to "effective" — interactive output, practice mode, instrumentation

[jbrecht]

Source: instructional-designer pedagogy review, docs/reviews/2026-06-13-pedagogy-review.md (Part 2, items #4, #7, #8 — the strategic bets). Design-doc / RFC required before any implementation.

This is a tracking + discussion issue for the three high-ceiling, low-immediate-feasibility directions. They share one thesis: tutorial-forge today optimizes "the video doesn't go stale" but cannot answer "did it teach?" These move the product from maintained to demonstrably effective. None should be built before an RFC design doc lands. They are grouped here (rather than as three separate issues) because they are interdependent — #4 and #7 both presuppose a chaptered web player, and #4 and #8 are the two learner-activity bets — and grouping keeps the near-term backlog (#35-#38) clean.

Each near-term item it builds on: chapters (#35) is the shared substrate for both the HTML player and instrumentation.

---

Bet A — Interactive HTML output with knowledge checks (review #4; High impact / Low feasibility)

A new HTML output target wrapping the rendered video with chapter navigation (from #35) plus authored knowledge-check questions between chapters — adding retrieval/generative practice, the thing linear video structurally cannot do. Note: HTML demos were an explicit v1 non-goal (tutorial-forge-spec.md:21); this proposes revisiting that as a complement, not a replacement. The timing manifest makes the chaptered player itself very feasible; the questions are the new authoring surface (and the bigger design question).

Bet B — Faded-practice "your turn" mode (review #8; High impact / Low feasibility)

Because a tutorial is already an executable Playwright spec, the same spec could generate a guided-practice mode: run the real app, prompt the learner to perform each step, validate with the same locators the demo uses. The spec is simultaneously the demonstration and the checker — a synergy no recording-based tool can match. Research-grade lift; highest learning ceiling.

Bet C — Effectiveness instrumentation (review #7; Medium impact / Low feasibility for core)

Once output ships chapter markers (#35) and an analytics-friendly player (Bet A), consumers can measure per-chapter drop-off, replays, completion — turning segment boundaries into a learning signal. Out of scope for the core MP4 encoder; the natural strategic destination once A is real.

---

What this issue is for

• Decide which of A/B/C (if any) tutorial-forge commits to, and in what order.
• Produce an RFC design doc (under docs/reviews/ or docs/rfcs/) for the chosen bet(s) before implementation, covering: authoring surface, output format, scope boundary vs. the MP4 pipeline, and the v1-non-goal revisit (tutorial-forge-spec.md:21).
• Spin out concrete implementation issues only after the RFC lands.

Decisions needed from maintainer (blocking)

1. Does the project's scope expand beyond video? Bets A and B require it (HTML player; live practice runner). This is a product-identity decision, not an engineering one — it reverses an explicit v1 non-goal.
2. Sequencing vs. near-term: confirm Chapters / segmenting: emit chapter markers from per-step manifest #35 (chapters) ships first as the shared substrate before any RFC work begins.