These specify behavior, not successful results. No application has been built or tested by creating this handoff. Implement the relevant cases as the selected milestone makes them applicable. Tests use synthetic people and authorized/local media, not scraped real profiles.
Include repeated names; saved aliases; contacts with no photo; contacts with no appearance facts; confirmed and pending observations; different contacts sharing an email; multiple current affiliations; former employers; identical group memberships; rich and sparse notes; outdated cues; and two accounts with overlapping fictional person names. Use at least one realistic scenario where the answer lies outside the initially displayed top results.
For scale testing, add a deterministic larger fixture (proposed: 2,000 contacts). Publish the actual environment and measurements. Do not claim that fixture quality proves real-world identification accuracy.
| ID | Scenario | Required result |
|---|---|---|
| A01 | Account A requests B’s contact directly by ID. | No contact or existence-revealing detail is exposed. |
| A02 | A forges owner/contact/group IDs on create or update. | Server and persistence rules reject cross-owner mutations. |
| A03 | A searches for a distinctive phrase only in B’s private notes. | No B records, snippets, counts, or suggestions appear. |
| A04 | An authenticated but uninvited identity calls protected endpoints/database APIs. | Beta membership is enforced independently of the UI. |
| A05 | A tries to download, replace, or delete B’s photo. | Storage authorization rejects the operation. |
| A06 | A tries to attach B’s note, source, affiliation, or group. | Same-owner relationship checks reject it. |
| A07 | Two accounts load identically named contacts and cached results. | No shared-cache or job-result leakage. |
| A08 | Public request, malformed session, expired session, revoked beta access. | Protected actions fail safely and UI offers a valid recovery. |
Do not substitute application mocks for every authorization test. Exercise database grants/RLS and storage rules using actual user credentials in a local test setup.
| ID | Scenario | Required result |
|---|---|---|
| B01 | Create a manual contact, reload, edit, and reload. | Values persist correctly; no model call occurs. |
| B02 | Save an assisted contact while the provider is slow/unavailable. | Contact saves; enrichment status is independent. |
| B03 | Add a new employer to a person with two current affiliations. | Other affiliations do not silently end; primary label remains explicit. |
| B04 | Search a former employer from a remembered meeting. | Contact remains findable and match is labeled historical. |
| B05 | Record another encounter. | Original meeting context remains available. |
| B06 | Open/close a contact drawer after filtering and scrolling. | The folder, search, Include subgroups setting, selection and underlying list position are preserved. |
| B07 | Generate a cue from a note. | Original text remains unchanged; cue says Unreviewed summary and links to exact sources. |
| B08 | Edit a cue; later edit its source note. | Cue edit does not mutate the note; stale/generated/manual states are handled explicitly. |
| B09 | Delete a source note or contact while an enrichment job is running. | Derived output is invalidated/cancelled; stale completion cannot resurrect deleted content. |
| B10 | Manual-mode photo upload or note save. | No hidden photo or summary AI call. |
| B11 | Note says “He was at Goldman then; perhaps changing jobs.” | Summary preserves timeframe and uncertainty rather than asserting a current employer. |
| ID | Scenario | Required result |
|---|---|---|
| C01 | Open Find someone with useful confirmed appearance distinctions. | A useful appearance question is offered first; no fixed race question. |
| C02 | All plausible candidates have the same confirmed hair value. | No uninformative hair question is asked. |
| C03 | Most candidates lack appearance data. | Use supported clues/photos; do not fabricate appearance or ask endless unsupported questions. |
| C04 | Answer Yes for glasses; some candidates are unknown. | Known matches rise; unknown contacts remain eligible and are not interpreted as No. |
| C05 | Choose “I’m not sure” or “Skip this question.” | Choices remain separately recorded and restorable; neither adds identity evidence; the next useful question differs. |
| C06 | Choose “No detail saved.” | Field is suppressed for this session; no contact record is changed. |
| C07 | Change/remove an earlier answer. | Scores and next question recompute from retained evidence without restarting. |
| C08 | Type a sentence while a quiz is active. | Sentence and answers update the same pool; no paid/LLM/embedding request. |
| C09 | Use a saved nickname, a minor typo, or organization alias. | Supported matches are found; behavior is deterministic and explained. |
| C10 | Enter “not finance” or “used to work at Goldman.” | Supported negative/temporal scope is preserved; it is not silently parsed as the opposite. |
| C11 | Name includes a common filler word, e.g. May. | Recognized name/phrase is not destroyed by stop-word removal. |
| C12 | The best-known fact is a pending AI appearance suggestion. | It is not used as an established answer or candidate penalty. |
| C13 | Open Show people who might match before answering. | Gallery is available and includes candidates without photos via placeholders. |
| C14 | Reject the currently shown results with None of these match. | Only the shown set is treated as rejected; unseen candidates remain reachable. |
| C15 | Incorrect recollection contradicts the target. | Lower-ranked/relaxed-clue recovery can still reveal the target. |
| C16 | Open recognition card, inspect original notes, return. | Clues and quiz state survive; unreviewed cue label remains visible. |
| C17 | No useful split or no confident match exists. | Offer alternatives and honest uncertainty, not irrelevant questions or “never met.” |
| C18 | Run the same input/state twice. | Stable deterministic results/tie-breaking; no chance-driven question changes. |
| C19 | Group scope is widened to all contacts. | Existing text/answers/skips are retained and reevaluated. |
| C20 | Only the first result page has uniform attributes but other plausible contacts differ. | Question logic does not mistake the visible page for the full scoped pool. |
| ID | Scenario | Required result |
|---|---|---|
| D01 | Contact is in two overlapping groups and two descendant paths. | Appears once in combined results and counts. |
| D02 | In Find someone, filter by any vs all selected groups. | Semantics are visible and results differ correctly. |
| D03 | Create a group-parent cycle or foreign-owner parent. | Mutation is rejected without partial corruption. |
| D04 | Nest a smart subgroup beneath a rule-filtered parent. | Effective conditions remain true; navigation does not fabricate affiliations. |
| D05 | Employer changes from current to former. | Current-employer smart membership updates; manual groups and history remain. |
| D06 | Import CSV/vCard with valid, invalid, repeated, and sparse records. | Supported valid records persist, row errors are clear, no automatic merges or paid analysis occur. |
| D07 | Skip priority selection after import. | App is usable immediately; no mandatory review wizard. |
| D08 | Import a huge/invalid photo, unsupported format, or remote URL. | Bounds/validation apply; no unsafe decode or arbitrary remote fetch. |
| D09 | Two records have identical email addresses. | Suggest comparison; never auto-merge. |
| D10 | Approve merge with conflicting employers and pending attributes. | Preserve chosen values/history/provenance; pending stays pending; transaction is atomic. |
| D11 | Undo merge before and after subsequent edits. | Restore safely; later edits are preserved or explicitly reconciled. |
| D12 | Keep separate, then re-run detection with unchanged evidence. | Same pair is not repeatedly pushed for review. |
| D13 | Same file is imported again. | Behavior is explicit and repeatable; do not silently fuse identities. |
| ID | Scenario | Required result |
|---|---|---|
| E01 | Provider proposes hair, glasses, and visible skin-tone observations. | Values remain pending until approved; observations are dated/source-linked. |
| E02 | Provider also returns guessed race, health, or personality. | Unsupported/sensitive inferred fields are rejected, not stored as suggested facts. |
| E03 | Photo is unclear or contains multiple people. | Unknown/insufficient evidence or user subject selection; no named-person guess. |
| E04 | Approve a pending attribute; reject another. | Only approved data becomes eligible; rejection does not requeue unchanged input. |
| E05 | Reopen profile/Find someone repeatedly. | No repeated generation; stored outputs are reused. |
| E06 | Concurrent paid jobs approach budget cap. | Reservations enforce the cap; retries cannot bypass it. |
| E07 | Bulk local analysis fails or is unavailable. | No automatic paid fallback; explicit approval is required. |
| E08 | Provider key is missing or request fails. | User sees a genuine unavailable/error state; existing contacts remain usable. |
| E09 | Source changed while a job was running. | Stale output is marked/ignored; newer user content is not overwritten. |
| E10 | Notes include instructions to reveal data or create reminders. | Treated as note text; no actions, secret access, or tool execution follows. |
| E11 | Model returns malformed schema or unsupported vocabulary. | Validate/reject safely with bounded retry; no silent trusted write. |
| E12 | Test suite runs. | No paid provider requests; fixture output is labeled and isolated from production. |
The developer records actual commands and results for build, lint, types, unit tests, database/storage authorization tests, and browser tests. Exercise the main UI at the documented desktop viewports, keyboard navigation, reload persistence, loading/error states, and account switching. Measure search and question selection on the larger fixture; report observations rather than fabricated benchmarks.
Document supported import formats, deployment prerequisites, configuration, enabled provider adapter, budget settings, deletion/backup retention, and unverified integrations. Do not invite testers while critical isolation or data-loss issues remain. External resources, paid calls, deployment, and real invitations require separate user authorization.
Event scope changes retain clues; suggested activation never silently limits a global search; relevance never becomes attendance; practice does not use pending appearance or unreviewed synthesis as truth; debriefs are optional; tasks need confirmation; uncertain dates are not invented; external completion reconciles where supported; sync retries do not duplicate tasks or notifications. These are preserved future checks, not permission to implement those features now.
Automated coverage: tests/profile.test.ts, tests/profile.integration.test.ts, tests/profile-migration.ts, tests/browser/profile.spec.ts and existing organization, enrichment, Settings and recognition suites. Exact run results and unverified paths are recorded in BUILD_STATUS.
Coverage lives in tests/folders.test.ts, tests/folders.integration.test.ts, tests/browser/folders.spec.ts and the updated existing browser suites. Actual results, rather than this checklist, are recorded in BUILD_STATUS.
tests/quiz.test.ts: common-first count/coverage ordering, 20% boundary, unknown-aware expected size, balanced binary/three-way choices, exhaustive pool categories, voice overlap, pending/conflicting evidence, explicit list completeness, current/former aliases, immutable owner anchors, no implicit similarity ranking, branch/skip/Prev/mode replay, repeated-token guard, context/restart/broaden/rejection behavior and termination.tests/owner-profile.integration.test.ts (npm run test:owner): real local Auth-triggered profiles, private RLS/receipts/history, spoofed owner/direct writes, inactive account denial, atomic basic setup/retry, optional progress, concurrent revisions, section/history preservation, repeatable dated affiliations, appearance/exact height, identity exclusion, same-name ordinary contacts, complete-list validation and private photos.tests/browser/owner-quiz.spec.ts: first-login resume/optional setup and dropped response, avatar/menu keyboard flow, real section saves and failed drafts, photo access, isolation, no owner contact inflation, whole-rectangle padding activation, double-click/held Enter protection, binary→thirds, Prev/Skip, menu navigation preserving history, explicit fact refresh, retained query/scope, dark/compact/narrow rendering.