references/stage-test.md

# Test mode

## Posture

Test to learn, not to prove the team was right. Do not coach participants into success, defend the concept, or translate confusion away.

## Prepare

State:

- hypothesis and critical assumption;
- participant/context rationale;
- task or realistic trigger;
- Solution Blackout or Concept Reveal status;
- success, failure, and inconclusive signals;
- observation and consent plan;
- what will change after each possible outcome.

Use comparison when it reveals a meaningful tradeoff or distinguishes live mechanisms. Apply the
same realistic trigger where practical, observe behavior rather than preference voting, and keep
the comparison to the fewest alternatives that could change the next decision.

In a mature ecosystem, test both the behavior and the intervention locus when either could change
the strategy—for example, becoming the destination versus bridging into an already accepted venue.
Spend scarce instrumentation on reciprocal, repeated, or consequential behavior rather than a
self-declared role, exposure, click, or other proxy unless that proxy is itself the pivotal unknown.

For coordination tests, deliberately include both true conflicts and legitimate shared work. Observe
false duplicate warnings, false blocking, stale-state recovery, and whether one accountable owner can
coexist with visible contributors; do not award success merely because the design suppresses all
parallel activity.

## Observe and capture

Record:

- behavior and sequence;
- hesitation, confusion, abandonment, and questions;
- workarounds and misuse;
- moments of unexpected value or indifference;
- context, interruptions, dependencies, and social dynamics;
- surprises, contradictions, and new needs;
- facilitator interventions that may have contaminated the result.

Ask neutral follow-ups: “What were you expecting there?” “What did you look for first?” “What would you do next?” Avoid “Did you like it?” as the primary learning question.

For opted-in test planning, use `participatory-workshops.md` and ask for one task, signal, or follow-up at a time. If the user proposes a leading or approval-seeking question, preserve it as `USER_PROVIDED`, explain the contamination risk plainly, and offer one behavior-first alternative without grading the user.

## Outcome contract

```yaml
hypothesis_status: supported | weakened | falsified | inconclusive
behavior_observed: []
new_evidence: []
new_unknowns: []
surprises: []
new_insights: []
assumptions_changed: []
limitations: []
recommended_next_mode: EMPATHIZE | DEFINE | IDEATE | PROTOTYPE | TEST | BUILD
```

“Supported” means supported within the tested context, not universally proven. Link each conclusion to evidence IDs.

## Backward iteration

- Return to Prototype for fidelity, interaction, or mechanism problems.
- Return to Ideate when the concept family is wrong or alternatives are needed.
- Return to Define when evidence contradicts the need/insight/frame.
- Return to Empathize when behavior or context was misunderstood.
- Proceed toward Build when the pivotal uncertainty is sufficiently reduced for the cost and reversibility.

Record why the mode changed. Backward movement is learning, not failure.