**Moanote v2.1 research memo (fictional teaching case)**
14 records (4 I, 6 R, 3 O, 1 N), 12 unique participants (U01–U12). R2 = I2 and O2 = I3 are duplicates: 14 − 2 = 12. D1–D3 are review notes, not records or participants. Only U06 (R3) is confirmed as an independent completion. Purposive sample; no rates estimated.

## 1. Confirmed scenes
- U02: “누르면 결제가 되는 줄 알았다” (thought pressing it would charge); finished after a colleague explained. U11 finished after the facilitator explained.
- U04 and U10 could not reach Save by Tab; someone else’s or the facilitator’s mouse saved.
- U03 and U07: projects invisible until invite check / re-invite.
- U05: “화면이 오래 멈춘 듯했다” (screen seemed frozen); U09 re-uploaded. U12 asked an admin.

## 2. Evidence table (records/unique · independent completion · counter-case)
| Theme | Records/unique | Independent | Counter-case |
|---|---|---|---|
| First-team “Next” | I2,R2,O3 / 2 | 0 | U06, R3: “혼자 끝냈다” (finished alone) |
| Keyboard save | I4,O1 / 2 | 0 | None in data |
| Project not visible | I3,O2,R4 / 2 | n/a | I3: “비슷한 이름의 다른 프로젝트는 계속 보였다”; R4: “검색이 느렸는지는 확인하지 않았다” |
| Upload (R1 dual-coded: performance + completion notice) | R1,R6 / 2 | Not recorded | R1: “작은 파일에서는 못 느꼈다” (small files fine) |
| Similar names | I1,R5 / 2 | Recovered alone via dates | I1: “대체로 찾는다” (mostly finds) |
| Invite guidance | N1 / 1 | Not recorded | Single case |

## 3. Disputed coding (observation vs. hypothesis)
**R4**: “동료 프로젝트가 안 보여 고객센터에 문의했다. 초대를 다시 받고 보이기 시작했다.”
- Observation: invisible → contacted support → visible after re-invite. Whether search was used or failed is not in the text.
- Hypothesis, reviewer 을 (invite/access): the sequence supports it; causation unconfirmed.
- Hypothesis, reviewer 갑 (search failure): no sentence directly supports it. “검색이 느렸는지는 확인하지 않았다” means speed unchecked, not evidence of failure. No vote: both stay unresolved, and R4 is coded “visibility (cause unresolved)”.

**R1**: “화면이 오래 멈춘 듯했다. 시간을 재지는 않았다” is an impression, so the delay is unknown. “업로드가 끝났는지 알려 주면 좋겠다” is a completion-notice request. Both codes kept.

**N1 alternative explanation**: invite confusion may come from an outdated guide rather than permissions. But “권한 자체가 잘못됐는지는 검사하지 않았다”, and the symptom (which button to press) differs from U03/U07, so N1 cannot explain invisible projects.

## 4. Priority verification questions (proposals; none conducted)
1. Can keyboard users reach and complete Save alone? Reproduce the Tab order; check whether a shortcut exists.
2. Does the plan text read as a charge? What differs for U06?
3. Is invisibility caused by invite state or search? Proposal: ask support to check U07’s invite state.
4. Measure completion time and completion indication for a 2,000-row upload.

## 5. Revised interpretations
- Records 13 → 14; participants 11 → 12.
- “Cause was the invite setting” now applies only to U03’s own statement; R4 shows sequence only.
- Upload: dual coding instead of a speed claim. Added an outdated-guide hypothesis for invites.

## 6. Unknowns
Population rates; U03’s pre-change query and recording; whether R4 used search; what the re-invite actually changed; upload delay and whether U09’s first upload failed; key-press counts and shortcut existence; whether U12 finished; search behavior with very many files.