zudo-text

検索したい単語を入力

いつでも検索バーを開ける

Sync Access Recovery — CU-006 Native Check

This checklist covers the native macOS confirmation for a WebSocket-ticket access rejection. Run it only with a separately provisioned, non-bypassed test account and workspace. Deterministic contract coverage lives in tauri-app/renderer/sync-access-contract.test.tsx.

Fixture readiness

Native CU-006 is deferred until a suitable live fixture is available. No separately provisioned non-bypassed fixture or native run evidence was supplied for this task. The general developer test account is allowlisted and cannot demonstrate the server's HTTP 402 rejection; a pass with that account would not satisfy CU-006.

Before starting, confirm that the fixture:

  • Uses a dedicated non-production account and workspace that are not covered by developer entitlement bypasses.

  • Can receive the real POST /api/v1/workspaces/:id/ws-ticket subscription rejection while internet access remains available.

  • Has a safe, prearranged way to restore sync access after the rejection so recovery can be checked without changing production subscription or trial records.

  • Does not require purchasing access, changing a production entitlement row, or disabling an entitlement check.

If any prerequisite is missing, leave CU-006 marked deferred and record the missing fixture requirement. Do not substitute the allowlisted developer account or claim source tests as native verification.

Native steps

On a real macOS build, with the prepared fixture and internet available:

  1. Sign in with the fixture account and open its bound workspace. Record the app version, macOS version, and a pseudonymous fixture identifier.

  2. Create or edit a small note so there is a local change to retain. Confirm it is still present locally before triggering the access rejection.

  3. Trigger the fixture's prearranged subscription rejection. Confirm the app shows the subscription-specific sync explanation and a Retry action while the network is still available. The state must not be presented as Offline.

  4. Confirm the edited note remains available locally and is still pending; do not discard it or reset local app data.

  5. Restore access for the test fixture using its prearranged non-production procedure. Click Retry in the app.

  6. Confirm the rejection explanation clears after a successful ticket mint and WebSocket connection, then verify the pending note reaches the fixture workspace from another authorized client if one is available.

  7. Capture the access explanation, retained pending note, and recovered sync state. Save sanitized logs with the observed HTTP status and state transitions when available.

Redact bearer tokens, WebSocket tickets, session cookies, private note contents, email addresses, and other account secrets from screenshots and logs. Keep only the minimum evidence needed to show the fixture category, available network, rejection, pending local change, and recovery.

Evidence record

Record one outcome with the checklist:

  • Pass: all rejection, retention, and recovery observations above were made on the native app with the qualifying fixture; include sanitized screenshot/log locations and app/OS versions.

  • Deferred: a qualifying fixture was not available, its non-bypassed status could not be established, or the native run could not be performed; name the unmet prerequisite.

  • Fail: the qualifying native run contradicted an expected behavior; include sanitized evidence and keep the issue open for investigation.

Unit tests, a development-account run, a source inspection, or a test fixture that bypasses subscription enforcement are not a CU-006 native pass.