# Authoring interview

The interview should feel like product design, not a schema questionnaire. Ask
one compact batch, use the request to prefill likely answers, and follow up only
when an unresolved choice changes the implementation.

## Questions that matter

1. **Suite promise** — Who is this for, what useful outcome does the complete
   Experience Suite promise, and why do its Practice Modes belong together?
2. **Mode map** — Which Practice Mode should be the featured entry point, what
   is the exact display order, and how should a member move among the modes?
   One mode is valid when no coherent second mode exists.
3. **Player and goal per mode** — What should one Attempt help the member
   practice, prove, or complete? What canonical name, concise instructions, and
   useful ready-to-practice defaults should every member receive?
4. **Attempt boundary per mode** — What starts one Attempt? What ends it? Can it
   be aborted? Is it repeatable or a one-time completion challenge?
5. **Input per mode** — What does the player do or submit? Is input manual,
   supplied by a connector, or both? A connector can be planned without giving
   the activity Station authority.
6. **Result per mode** — What measurements come out? Which one is the primary
   result? For each metric choose kind, direction, unit, and precision.
7. **Progression per mode** — Does ranked progression help? If yes, choose its metric,
   aggregation (including the rolling window for an average), minimum evidence,
   labels, and thresholds. Binary or one-time
   completion activities may correctly have no progression.
8. **Player experience per mode** — What should the full-screen activity look and feel
   like before, during, and after the Attempt? What must always be visible?
9. **Correction per mode** — Can accepted evidence be replaced or removed?
   Which stable identity is correctable, may a terminal Attempt reopen, and
   which Story Events or narration facts must retract or be superseded?
10. **Creator layer per mode** — Is a stream overlay useful? Which rare moments should be
   emitted as Story Events for OBS alignment and later editing?
11. **Coordination** — Does any mode support several participants? Define the
   participant limits, shared/independent/hybrid input topology, rounds, teams,
   ready/start flow, reconnect behavior, presets, and story-worthy outcomes.
12. **Narration** — Which committed broadcast facts may be spoken, by which
   roles, when should the director intentionally remain silent, how do cues
   expire or cancel after correction, and what happens when speech is absent?
13. **Proof per contribution** — Give one happy path plus meaningful edge cases such as invalid
   input, duplicate action, stale revision, abort, reconnect, or correction.

## Defaults to prefer

- A one-mode suite unless several modes make one honest, coherent promise.
- The featured mode first in the explicit display order.
- One atomic, repeatable Attempt per mode with explicit abort while active.
- One immutable package-owned default preset per mode, complete enough to open
  a real Attempt immediately after the Suite is added.
- Manual input first unless an existing connector contract is named.
- One clear primary metric; secondary metrics only when they help decisions or
  storytelling.
- Personal progression using `best` for peak performance, `latest` for a
  qualification state, or a short rolling `average` for consistency.
- No overlay and no Story Events unless they improve the live or edited story.
- No coordination or narration unless it materially improves the participant or
  audience experience; empty declarations are explicit and valid.
- Correction disabled with a reason for terminal one-shot inputs; otherwise use
  stable evidence keys and deterministic replay rather than mutable state.
- Three to five progression levels with thresholds clearly monotonic in the
  metric's direction.

## Brief-writing rules

- Use stable lowercase `activityId` values with letters, numbers, underscores.
- Declare every Practice Mode exactly once; the order must contain every mode
  exactly once and begin with the featured mode.
- Package IDs use a publisher-like namespace such as `dev.alex/reaction-time`.
- Describe product intent, not implementation files or model instructions.
- Acceptance scenarios must be observable enough to become deterministic
  fixtures.
- Put unresolved non-blocking ideas in `notes`; do not leave core Attempt or
  metric semantics ambiguous.
