Every way it goes wrong

A pre-mortem over the whole import path, from sign-in to a window the researcher closed an hour ago. For each state: where it surfaces, the exact words, and what they can actually do about it. Enumerated from the shipped types — GoogleAPIOutcome, TeamsAPIOutcome, ArtifactAvailability, ImportRowState, ListOutcome, FetchOutcome, DownloadVerdict — not from imagination, so the gaps below are real gaps rather than unwritten cases.

Design artefact · 17 Aug 2026 · sibling of cloud-import-sidebar-progress.html · relates to docs/design-cloud-import.md §6

1 — Before a single row exists

Sign-in and listing. These are blanket states: the window has nothing to show, so it says one thing well instead of forty rows of nothing.

2 — Per row, at list time

A row exists. Two independent axes decide what it says: what the platform will serve (ArtifactAvailability) and what is already on this Mac (ImportRowState). The checkbox column carries a third distinction that is easy to collapse and expensive to lose: a dead checkbox means “there is a recording here and you cannot have it”; no checkbox means “there is nothing here”.

3 — At the moment of commit

4 — During the transfer

Every one of these is verified rather than trusted, because a download that lands and is wrong is worse than one that fails. DownloadVerdict.isRetryable already decides which offer a Retry.

5 — After the batch, while the window is still open

6 — After the window closes. This is the hole.

Everything above lives in the window. The researcher closes it — because it looks like it is working — and the entire vocabulary goes with it. What remains is a project row that knows only what is on disk.

Eight of the nine ⚠ rows in this document are one defect. Not missing error handling — the handling is unusually complete — but error handling with the lifetime of a window that the design actively encourages people to close.

7 — What each platform can send that the others cannot

9 — Reopening mid-batch: the window is a monitor, not a chooser

Reopening stays in File ▸ Import, which keeps the existing convention and reads the way the researcher thinks — “my Teams import”, not “the import window”. While a batch is in flight the platform that owns it is the only enabled item; the other two dim, which is how the menu explains the one-batch-at-a-time rule instead of letting a click destroy a running transfer.

Reopening already shows the live batch rather than a fresh sign-in — the store lives above the window and CloudImportWindow.task only lists if store.listing == nil. So there is no authentication dance to avoid; there is a store replacement to stop.

What the window is, in each mode

The menu item swaps verb, it does not just dim its neighbours. “Teams…” starts an import; during a batch the same position should read “Show Teams Import”. Same idiom as Turn On/Off Agent Access and the Hide/Show panel rows — this codebase already prefers a changed verb to an ambiguous one, and it removes the last doubt about what the click will do.

11 — What the batch leaves behind, and where “already imported” actually lives

The end of a batch is not a fresh open — it should be better than one

When the last transfer finishes the window becomes choosable again: checkboxes live, Import back, destination live. But it must not become amnesiac. A genuinely fresh open today would offer to re-download every file it just fetched, because no adapter derives local state — the “✓ Imported” a researcher sees comes from store.outcomes, which is in-memory and dies with the window.

“Can they re-download into a different project?” — yes, and it breaks the model

localState is a stored property of the row, but “already imported” is a property of (row, destination). The same recording is imported into IKEA with uxfriends and not into Ward handover — and the destination popup is right there in the footer, changeable at any moment. A row that reads Imported must go back to a live checkbox the instant the destination changes. A field set once by the adapter cannot express that, and no amount of refreshing it after a fetch will fix the shape.

Filename matching is the tempting answer and the wrong one

CloudDownloadNaming is deterministic, so “does destination/<name> exist?” looks like a free answer. It is a guess: the researcher renames files, two studies collide on a title, and a file restored from a backup is indistinguishable from one we fetched. The house rule is the exact key over the clever heuristic — and here the exact key is cheap, because we know the row id we downloaded.

One artefact answers four of the flagged rows. A small durable record inside the destination project — which cloud rows landed, when, from which platform and account, and which were asked for and did not arrive — supplies:

Do we need a hash?

Not for this. A hash identifies a file; the question is about a recording. “Did this project already receive cloud row X” is answered exactly by the record, with no file inspection at all — and byte-identical is only evidence for same-recording, never proof: two exports of one call can differ by a byte and be the same interview.

Record the hash anyway, because it is now free. §3's size sweep already calls files.get?fields=size; adding md5Checksum is the same round trip. The adapter's own comment says verification settled for size + magic bytes because “fetching metadata purely to hash would cost a round trip per row” — that objection expires the moment the sweep exists. So DownloadVerdict.hashMismatch, which is written and unreachable, becomes reachable at zero cost, and the record carries a hash for the day a question is worth a full read.

The rule: hash to verify what just arrived, size to recognise what is already there. One is a check on bytes we are receiving anyway; the other must not cost a gigabyte of reading every time someone opens a window.

And the harm being prevented is not wasted bandwidth. A duplicate import lands a second copy under the canonical name, the pipeline scans the folder, and one interview becomes two sessions with two participants — the same corruption as the Zoom rendition case, arriving by a different door.

The case that defeats all three layers: renamed and trimmed

The maintainer's own routine, stated 17 Aug 2026: “I often rename and trim manually downloaded videos before dragging and dropping into folders to process.” Download from Drive by hand → rename → trim → drag in. Then open cloud import and the same meeting is listed.

So this is a boundary, not a cost question. For files arriving by a route we do not mint keys for, the only usable signals are intrinsic to the media. No amount of bookkeeping on our side reaches them.

Measured, 17 Aug 2026 — and it removes half the answer

ffprobe over the five recordings this feature has actually fetched, plus the Teams file already in the same project:

Google writes no creation timestamp into its MP4s. Microsoft does. So the duration + creation-time pair works on Teams and collapses to duration alone on Meet — which is the platform this was being designed for. One ffprobe run, ten seconds, and it retires a plan that read as obviously correct.

The 99.9% case, stated 17 Aug 2026

“Download manually, rename to make a nice clean name, drop in a folder, process. Two days later, with more interviews, you go the file-importer route and we are smart enough to say ‘you got those already in this project’.”

Note what that rules out: the per-project record cannot help here. Those files never came through the importer, so there is no row id to have recorded. The record answers a different question — what we fetched, and what we were asked for and never got. For the case the researcher actually lives in, the duration scan is the entire answer, not a fallback.

What is actually being prevented: p2 and p3 are the same person

Not a wasted download. A false finding. Two copies of one interview become two sessions, two participants, and two sets of the same quotes — and the quote clustering then puts those identical quotes together, where agreement between two participants is exactly what a researcher reads as corroboration.

So the duplicate does not look like a mistake. It looks like a stronger result. Theme prevalence reads “4 of 6 participants” for something three of five said; the analysis page's signal-concentration metrics inherit the same inflation; and nothing anywhere is wrong-looking enough to prompt a check. This is the same class as every other hazard in this document — a defect whose output is indistinguishable from a good one — and it is the reason the guard is worth building before anything else on the media side.

Which settles how it presents: as .imported, not as a warning. When the durations match, the honest claim is simply this project already has this interview — the same status, the same ticked-and-dead checkbox, as a recording we fetched ourselves. No new state, no new words, no “are you sure?”. ImportRowState.imported gains its second producer and the researcher sees green on four of six.

Worth knowing, not solving here: the import window would be the only defence. The invariant is one interview, one participant, and it is a property of the study rather than of the importer — two same-content files landing by any route (two hand-drops, a restore, a colleague's copy) double a participant just as silently. Guarding at import is the cheap, early, well-placed catch; it is not the same as the pipeline holding the invariant. Separate conversation, but the assumption that this fix covers it would be wrong.

So the cheap half ships first and alone. A pure matcher — rows with durations against local media files with durations — plus one folder scan whenever the destination popup changes, feeding ImportRowState.imported, which is written, translated into 21 languages, and has never had a producer. No schema, no persistence, no privacy question. The record is a separate and larger thing for the jobs only it can do.

Trimming is out of scope, decided. “If the user bothers to trim the video — whatever.” Audio fingerprinting would solve it and is IP-protection technology: a dependency, a compute budget and a capability, for one cell of that table. A hand-trimmed Meet recording is unrecognisable, said once, and never reached for again.

One thing to check before wiring it: how close is the container's duration to the API's? Google's endTime − startTime is wall-clock between recording events; the container's is media length. They should agree closely and may not agree exactly, so the comparison wants a small tolerance — and the tolerance is free to widen, because a study's interviews differ by minutes, not seconds.

Whatever the signal, the response is a note — never a block

A researcher may legitimately want both — the trimmed working copy and the full original. So the finding is “this project may already contain this meeting”, naming the file it resembles, with the checkbox still live. A false positive that mentions costs a glance; a false positive that refuses costs them a recording and teaches them the feature is wrong about their own folder.

And the habit is itself a finding. Trimming before import is manual work done because there is nowhere else to do it. That is a different conversation from this document, but it is worth noticing that the duplicate hazard here is partly self-inflicted by a missing capability rather than by the import path.

And it belongs in the project, not in the app. The project folder is what the researcher owns, moves between machines and hands to a colleague — the same reasoning that puts re-identification keys under .bristlenose/ rather than in preferences. A record kept in app state would be right until the first time somebody opened the folder somewhere else.

Sizing it honestly: this is the largest single item in this document. It is a new persisted artefact with a schema, a migration story and a privacy question (it names meetings and platforms, so it is project-private and never rides along in an export). Everything else here is a guard, a disabled control or a word. Worth doing once, and worth not doing by accident as a side-effect of fixing the checkbox.

12 — The order I would fix them in