**Moanote research memo update (holdout comparison, fictional teaching case)**
16 records (4 I, 6 R, 3 O, 1 N, 2 H), 14 unique participants (U01–U14). R2 = I2 and O2 = I3 are duplicates: 16 − 2 = 14. Q1 is a policy document, not a record or participant. Independent completions are per task: U06 (first team, R3) and U13 (v2.2 save, H1). Purposive sample; no rates estimated.

## 1. Keyboard save by version
| Version | Records/unique | Independent | Conclusion | Limits |
|---|---|---|---|---|
| v2.1 | I4, O1 / 2 | 0 | “저장 버튼으로 갈 때 순서가 화면 밖으로 넘어갔다” (order left the screen); “Tab 이동이 저장 버튼을 지나쳤다” (Tab skipped Save). Failure to save alone observed | Cause is a hypothesis. I4’s text gives no version; H1 classes it as v2.1 |
| v2.2 | H1 / 1 | 1 (U13) | “키보드로 저장까지 혼자 완료했다” (saved alone by keyboard) | One person. What changed and U13’s conditions are unknown |

U13 is a single v2.2 success. It does not erase the v2.1 observations, does not show v2.1 had no defect, and does not establish that v2.2 fixed anything.

## 2. Intended restriction vs. problem
- **Intended restriction**: U14, in a view-only role, could not enter the owner-only admin screen (H2). Q1 states this is intended permission, so it is not a defect.
- **Problem confirmed by observation**: v2.1 keyboard-save failure (I4, O1). Without reproduction, no root-cause-confirmed defect exists yet.
- **Unclassified**: invisible projects (I3, O2, R4). Q1 covers admin-screen access, not project-list visibility. U03 saw the project after an invite check, but whether the earlier state was an error or a proper restriction is unknown. H2 itself says it is unknown whether the invite problem has the same cause. Access problems as a whole are not declared normal permissions.

## 3. Earlier statements
- **Keep**: first-team “Next” confusion, 2 people, with counter-case U06 (I2, R2, O3, R3); upload dual coding (R1, R6); similar document names (I1, R5); R4 coded “visibility (cause unresolved)” (R4).
- **Narrow**: “only U06 completed independently” → per task, U06 and U13 (R3, H1); keyboard-save problem → v2.1 only (I4, O1); “cause was the invite setting” → U03’s own statement only (I3, O2).
- **Hold**: Tab-order cause (I4, O1); whether v2.2 improved (H1); outdated-guide hypothesis (N1); whether U14 and I3/R4 share a cause (H2, I3, R4); search-failure hypothesis (R4).

## 4. Next verification questions (proposals, not conducted)
1. Did the Save focus order change between v2.1 and v2.2? Check change records.
2. Using U04’s and U10’s procedure (type body, then Tab), can several keyboard users save alone in v2.2?
3. Proposal: ask support to check U03’s and U07’s invite state; separate the admin-screen limit (Q1) from list-visibility rules.
4. Did U14 understand from the screen why access was limited? (Not checked.)

## 5. Unknowns
Population rates; what changed in v2.2; U13’s input conditions; U03’s pre-change query and recording; what the re-invite changed; upload delay; whether U12 and U14 finished their tasks.