Skip to main content

​
Overview

apps/drive is the canonical Tuturuuu Drive application. Production Drive traffic should use https://drive.tuturuuu.com/{wsId} instead of rendering the Drive explorer inside apps/web.
  • apps/drive owns the workspace shell, Drive explorer UI, local /verify-token handoff, and local app-session logout.
  • apps/web /{wsId}/drive remains a compatibility route. It checks manage_drive, preserves the query string, and redirects to the Drive app.
  • Drive uses local port 7817 and Portless host drive.tuturuuu.localhost.

​
Native mobile directory behavior

The mobile Drive screen uses the shared floating dock for search, view, sort, and permission-gated actions. Search temporarily occupies the shared search surface rather than adding a second search field to the directory body. Closing search clears its query and reloads the current directory. Directories retain their visible entries during refresh. Additional pages load when the viewport is within 400 logical pixels of the end, including directories that initially do not fill the viewport; the explicit load-more action remains available. Appended entries are deduplicated by name within the current directory. Workspace or account changes clear search, selection, and the previous directory. Late responses and signed-file actions cannot restore or open content from the previous account, workspace, or request generation. Definitive authorization failures clear displayed files; verification challenges and temporary failures retain the current view. This includes MFA_REQUIRED responses identified by the API error code even when the typed verification flag is absent; the challenge message remains visible, and a subsequent definitive denial still clears entries. Regression coverage: apps/mobile/test/features/drive/drive_page_test.dart.

​
API Ownership

Protected storage APIs remain centralized in apps/web:
  • apps/drive forwards /api/* traffic to apps/web.
  • Client Drive data flows must use @tuturuuu/internal-api helpers with TanStack Query.
  • Do not create direct Supabase browser reads or storage mutations in apps/drive.
  • apps/web storage routes authenticate normal web sessions and Drive app-session cookies through the shared storage route auth helper, then enforce manage_drive or the route-specific permission fallback.
When adding new Drive behavior, add the protected route in apps/web, expose it from packages/internal-api, and consume it from apps/drive.

​
CI/CD

Preview and production deployments use dedicated Vercel workflows:
  • .github/workflows/vercel-preview-drive.yaml
  • .github/workflows/vercel-production-drive.yaml
Both workflows are registered in tuturuuu.ts and use the shared ci-check.yml switchboard with affected-path gating. They require environment-scoped Vercel credentials:
  • preview environment: vercel-preview-drive
  • production environment: vercel-production-drive
  • project secret: VERCEL_DRIVE_PROJECT_ID
  • shared secrets: VERCEL_TOKEN and VERCEL_ORG_ID
The app-specific project secret should live in those GitHub Environments, not in workflow-level env.

​
Validation

Use these focused checks when changing Drive deployment wiring:
Run focused checks locally without app builds. Require the applicable lint, type-check, test, and real app-build workflows to pass in CI for the exact commit; do not run bun check or app builds on the shared machine.